1、分布式系统安全概述:分布式系统定义与挑战、安全目标(CIA三元组)、常见威胁模型
1.1 什么是分布式系统?
先聊聊定义。分布式系统,说白了就是一群独立的计算机,通过网络连接起来,对外表现得像一台超级计算机。
你想想看,用户点个按钮,背后可能是一百台机器在协同工作。我早年做电商系统时,就遇到过这种场景——用户下单,订单服务、库存服务、支付服务、通知服务,各跑各的机器上。嗯,这就是典型的分布式。
但问题来了。机器多了,网络复杂了,安全就变成了大麻烦。
1.2 分布式系统面临的挑战
我个人习惯把挑战归纳为三类:
- 网络不可靠:消息可能丢、可能延迟、可能乱序。我在项目中遇到过,一个支付请求因为网络抖动,重复发送了三次,结果用户被扣了三笔钱。这就是典型的分布式难题。
- 节点不可信:你没法保证每台机器都是“好人”。有些节点可能被攻破,有些可能是恶意节点。
- 数据一致性:多副本同步时,怎么保证大家看到的数据是一样的?这问题比你想的复杂得多。
⚠️ 避坑指南
我曾经在一个金融项目中,因为忽略了时钟同步问题,导致两个节点的日志时间戳差了3秒。排查问题时,光对齐时间就花了两天。记住:分布式系统里,时间不是绝对的。
我曾经在一个金融项目中,因为忽略了时钟同步问题,导致两个节点的日志时间戳差了3秒。排查问题时,光对齐时间就花了两天。记住:分布式系统里,时间不是绝对的。
1.3 安全目标:CIA三元组
做安全的,CIA三元组是基本功。我每次做架构评审,都会拿这三条来卡一下。
| 目标 | 英文 | 解释 | 我的经验 |
|---|---|---|---|
| 机密性 | Confidentiality | 数据只能被授权的人看到 | 传输层加密是基础,但别忘了内存中的数据也可能被偷 |
| 完整性 | Integrity | 数据在传输和存储中不被篡改 | 我见过有人只做加密不做签名,结果中间人改了数据都不知道 |
| 可用性 | Availability | 系统在需要时能正常服务 | DDoS攻击就是冲着这个来的 |
💡 核心观点
CIA不是选择题,是必答题。三个目标都要满足,缺一个都不行。
CIA不是选择题,是必答题。三个目标都要满足,缺一个都不行。
1.4 常见威胁模型
威胁模型,说白了就是“谁会攻击我们?怎么攻击?”我习惯把威胁分成几个层次:
1.4.1 网络层威胁
- 中间人攻击:攻击者截获通信数据。我建议所有内部通信都用TLS,别嫌麻烦。
- DDoS攻击:用海量请求打垮你的服务。我经历过一次,流量直接飙到正常值的100倍,那叫一个酸爽。
- DNS劫持:把用户引导到假服务器上。
1.4.2 节点层威胁
- 节点被攻破:攻击者拿到了一台机器的控制权。
- 拜占庭故障:节点不仅出错,还故意发送错误信息。这在区块链系统里特别常见。
- 资源耗尽:恶意节点消耗大量CPU、内存,让正常服务无法运行。
1.4.3 数据层威胁
- 数据泄露:敏感信息被偷走。我建议所有存储数据都要加密,包括数据库里的。
- 数据篡改:攻击者修改了你的数据。日志审计在这里就很重要了。
- 重放攻击:攻击者把之前合法的请求重新发一遍。加个时间戳和nonce就能防住。
🔧 实用技巧
做威胁建模时,我习惯用STRIDE模型(欺骗、篡改、抵赖、信息泄露、拒绝服务、权限提升)。每个字母对应一类威胁,挨个过一遍,基本不会漏。
做威胁建模时,我习惯用STRIDE模型(欺骗、篡改、抵赖、信息泄露、拒绝服务、权限提升)。每个字母对应一类威胁,挨个过一遍,基本不会漏。
1.5 一个真实案例
我参与过一个分布式存储系统的安全设计。当时有个场景:用户上传文件,系统自动复制到三个节点上。
问题来了——如果其中一个节点被攻破,攻击者修改了文件内容,用户下载时怎么知道文件被改了?
解决方案其实不复杂:
- 上传时计算文件的哈希值,存到另一个可信节点上
- 下载时重新计算哈希,对比一下
- 如果不一致,就从其他节点重新获取
你看,这就是CIA里的完整性在实践中的应用。嗯,说起来简单,但真正落地时,要考虑的东西就多了——哈希存哪里?怎么保证哈希本身不被篡改?节点间怎么同步?
1.6 小结
这一章我们聊了分布式系统的定义、挑战、安全目标和常见威胁。说白了,分布式安全就是一场博弈——攻击者想尽办法搞破坏,我们想尽办法防住。
我个人觉得,做分布式安全,心态上要接受一个事实:没有绝对的安全。我们能做的,是让攻击的成本远大于收益。下一章,我们会深入聊聊认证和授权机制,那是分布式安全的第一道防线。