【系统架构师案例题-知识点】可靠性与安全性设计
阅读这篇时可以按三个层次把握先理解系统为什么会失效、为什么会被攻击再理解不同设计手段各自保什么最后把这些概念翻译成案例题里的标准答法。一、先建立整体认识很多人学这一章时会把“可靠性”和“安全性”当成两堆互不相关的名词。其实它们都在回答同一个更大的问题系统出了问题时还能不能继续被正确、安全地使用。只不过两者关注的风险来源不同可靠性更关注故障、异常、组件失效、软件缺陷安全性更关注攻击、越权、泄露、篡改、滥用放到真实系统里看这两类问题几乎总是同时存在。支付系统最怕服务挂掉这属于可靠性问题支付系统也怕账户被盗刷、报文被篡改这属于安全性问题电商在大促时要防止服务雪崩这是可靠性问题电商在大促时也要防止恶意刷接口、撞库和越权这是安全性问题所以这一章真正要掌握的不是“术语定义”而是下面几类能力系统出故障时如何尽量不停机或尽快恢复一个方案出错后系统如何继续给出可信结果数据传输和存储时如何防止泄露和篡改用户访问系统时如何确认身份并控制权限二、可靠性到底在保什么1. 为什么可靠性会成为架构问题当系统只有一台机器、一个进程、一个数据库时很多问题还不明显。一旦系统规模扩大故障就会从偶发事件变成必然事件。常见场景包括机器宕机服务实例不可用网络抖动调用超时或重试风暴软件缺陷在特定条件下被触发外部依赖响应过慢拖垮主链路人工误操作导致配置错误或服务中断所以可靠性不是“系统永远不出错”而是系统在规定条件和规定时间内仍然能完成规定功能的能力。2. 常见指标怎么理解指标含义更直观的理解MTTF(Mean Time To Failure)平均无故障时间一次故障发生前系统平均能稳定运行多久MTTR(Mean Time To Repair)平均修复时间出故障后平均多久能修好MTBF(Mean Time Between Failures)平均故障间隔时间一次故障到下一次故障之间的平均间隔MTBF MTTF MTTR可用度A MTTF / (MTTF MTTR)系统从总体上有多少时间处于可正常服务状态怎么理解MTTF越大说明系统越不容易坏MTTR越小说明系统坏了也能更快恢复可用度越接近1系统整体越稳定在工程上提升可靠性往往不是只靠“少出故障”还要靠“出故障后尽快恢复”。3. 提高可靠性的常见思路思路典型手段解决什么问题冗余主备、双机、多副本、多路径某个部件坏了还能切走检错校验、超时检测、断言、心跳尽快发现异常容错恢复块、N 版本、冗余切换出错后仍能继续产出结果异常处理重试、降级、熔断、补偿把故障限制在可控范围监控与告警健康检查、日志、指标、链路追踪及时发现和定位问题一句话记忆可靠性设计既要考虑“怎么少出错”也要考虑“出了错怎么别扩大”。三、软件可靠性和硬件可靠性为什么不一样这是案例题高频对比点关键不是死记表格而是看清两者为什么不同。题目如果要求比较软硬件可靠性不要只背“软件不会老化”。更好的答法是硬件故障更多来自物理损耗软件故障更多来自设计和实现缺陷因此两者的失效规律、维修方式和预警特征都不同。1. 差异的根源硬件是物理实体会老化、磨损、损坏软件是逻辑实体本身不会像硬件那样因使用时间增长而自然磨损但软件中的缺陷会在特定条件下被触发。2. 常见对比维度硬件可靠性软件可靠性怎么理解失效率变化常呈浴盆曲线通常不因“用久了”自然升高软件没有物理磨损是否会闲置老化会不会只要介质不坏软件逻辑本身不会氧化维修后的状态更换零件可恢复改代码可能引入新缺陷软件维护本身也是风险源失效前征兆常有退化迹象往往突然触发软件 Bug 常在特定输入或并发条件下暴露四、恢复块与 N 版本程序设计1. 为什么要有软件容错有些系统不能接受“一错就停”。比如航空控制、工业控制、金融清算、关键监测系统一次错误结果可能就会造成非常高的代价。这时就会引出软件容错思路不是假设程序永远不会错而是承认它可能出错并提前设计好出错后的收敛方式。2. 恢复块怎么理解恢复块可以理解为“一个方案失败了就回退并尝试另一个方案”。它通常包含主块优先执行的版本后备块功能等价但实现不同的备选版本验证测试判断当前结果是否可接受异常处理所有版本都失败时的兜底措施它的典型流程是先执行主块用验证测试判断结果是否正确如果不正确则回退到执行前状态再执行后备块直到某个版本通过验证或最终走异常处理关键特征更像顺序重试依赖验证测试程序采用反向恢复思路实时性通常较差因为可能要多次尝试3. N 版本程序设计怎么理解N 版本程序设计可以理解为“让多个独立实现同时算再通过表决选结果”。它的核心做法是由多个团队独立开发多个功能等价的版本多个版本并行运行通过表决器选出多数一致的结果关键特征更像并行冗余依赖表决机制采用向前恢复思路实时性通常更好因为不需要一次次回退重试4. 两者怎么对比维度恢复块N 版本程序设计执行方式顺序尝试并行执行检测方法验证测试表决恢复策略反向恢复向前恢复资源开销相对较低相对较高实时性较差较好实现难点验证测试难设计多版本独立开发成本高5. 怎么考怎么答如果题干强调“单个方案失败后回退、换后备方案继续执行”优先想到恢复块如果题干强调“多个版本并行执行、最后投票选结果”优先想到 N 版本程序设计。答题时最好把“运行方式、检测方法、恢复策略、实时性”四个维度一起写出来这样更像标准答案。五、安全设计先看系统到底怕什么1. 安全不是“加密一下”这么简单很多人一提安全第一反应就是加密。但真实系统里的安全设计远不止如此。一个系统可能同时面临数据被偷看数据被篡改服务被打挂账号被冒用权限被越权提升操作过程无法追溯所以安全设计首先要回答的是系统最怕什么风险哪些资产最值得保护。2. CIA 三要素怎么理解要素含义更像什么风险机密性(Confidentiality)信息不被未授权访问数据泄露、窃听、拖库完整性(Integrity)信息不被非法篡改篡改报文、伪造数据、中间人攻击可用性(Availability)合法用户能正常使用系统DDoS、资源耗尽、恶意刷接口怎么理解机密性解决“别人不该看见却看见了”完整性解决“数据被偷偷改了”可用性解决“系统本该能用却被打挂了”3. 常见安全机制机制作用更像解决什么问题认证确认你是谁防止冒名登录授权确认你能做什么防止越权访问加密保护数据内容防止窃听和泄露审计记录谁做了什么便于追责与追踪访问控制对资源访问设置规则把权限真正落到系统里4. 安全设计原则怎么记更容易原则直观理解最小权限只给完成任务所需的最少权限纵深防御不把安全压在一层上要多层拦截默认拒绝没明确放行的默认不允许安全失败出问题时宁可拒绝服务也不要放开敏感数据公开设计安全不应依赖“别人不知道实现细节”六、加密、摘要、数字签名怎么分工1. 对称加密为什么常用于传输大量数据对称加密的特点是加密和解密使用同一个密钥。它的最大优势是快所以非常适合大量数据加密。算法特点工程上的常见判断AES主流对称加密标准实际系统最常见DES密钥太短已不安全3DES比 DES 强但更慢已逐步被 AES 取代2. AES 为什么常考因为它是现实工程里最典型的对称加密方案考试也喜欢围绕它出细节题。常见要点包括AES 分组大小固定为128 位也就是16 字节密钥长度可以是128 / 192 / 256位明文超过一个分组时需要分块处理最后一块不足时要填充工作模式决定分组之间如何组织前面几条是在说明 AES 这个算法本身的基本特征但真实系统里很少只加密“一个分组”。一旦数据超过 16 字节就会涉及“多个分组怎么串起来加密”的问题这就是为什么这里会继续讲工作模式。可以把它理解成AES 负责“单个分组怎么加密”工作模式负责“多个分组整体怎么组织、怎么加密以及是否顺便考虑防篡改”。工程上常见的理解方式是ECB(Electronic Codebook)这里Electronic可以理解成“电子方式的”Codebook可以理解成“密码本”。它的意思接近“每个明文分组都像拿去查同一本密码本独立变成密文”。因为每一块都是各算各的所以相同明文块会得到相同密文块容易暴露数据规律一般不推荐CBC(Cipher Block Chaining)这里Cipher是“密文/加密”Block是“分组”Chaining是“链接、串起来”。它的核心意思是“当前分组不要单独算而是和前一个分组串起来再加密”。这样就能避免ECB那种重复明文直接暴露重复密文的问题但要正确处理IVInitialization Vector初始化向量CTR(Counter Mode)这里Counter是“计数器”Mode是“模式”。它的做法可以理解成“不断递增计数器生成一串密钥流再和明文结合”所以它在使用体验上更像流式处理。它的好处是实现灵活、性能较好也更适合并行处理GCM(Galois/Counter Mode)这里Counter还是计数器模式前半部分Galois指的是伽罗瓦域上的数学运算主要用来做完整性校验。可以把它粗略理解成“CTR 模式 防篡改校验”。所以它不仅能加密还能校验数据有没有被改动也就是同时兼顾机密性和完整性因此现代系统里更常推荐3. 非对称加密解决什么问题非对称加密使用一对密钥通常是公钥和私钥。它最大的价值不是速度而是解决密钥分发难题。它的核心原理可以先这样理解这两个密钥是成对生成的数学上彼此关联但作用不同。你可以把公钥理解成“可以公开的锁”把私钥理解成“只有持有者自己保管的钥匙”。用公钥加密的数据原则上只能用对应的私钥解开用私钥处理过的数据可以用对应的公钥验证所以它和对称加密最大的区别在于对称加密最怕“双方怎么安全地提前共享同一个密钥”而非对称加密里公钥本来就是可以公开发给别人的真正需要保密的只有私钥。再往工程上翻译就是接收方先公开自己的公钥发送方用这个公钥加密一个临时会话密钥发给接收方只有持有私钥的接收方才能把这个会话密钥解出来后续双方再用这个会话密钥做对称加密传输大量数据这样就解决了“对称密钥一开始怎么安全送过去”的问题。这也是为什么非对称加密常用于密钥交换和身份建立而不常直接拿来加密大批量业务数据。算法特点RSA(Rivest-Shamir-Adleman)经典、常见、基于大数分解难题ECC(Elliptic Curve Cryptography)同等安全性下密钥更短、性能更好工程上的常见组合非对称加密负责安全交换会话密钥对称加密负责后续的大量数据传输。这也是 HTTPS/TLS 中最经典的分工。4. 哈希不是加密哈希的核心特点是把任意长度输入映射成固定长度摘要而且不可逆。它不是用来“保密”的而是用来做完整性校验、签名基础和密码存储等。算法说明MD5已不安全SHA-1已不推荐SHA-256目前更主流一个很重要的区分加密解决“别人看不懂”哈希解决“内容有没有变化”5. 数字签名到底保什么数字签名不是为了保密而是为了证明“这份内容确实是某人发的而且没被改过”。典型过程是发送方先对数据做摘要再用自己的私钥对摘要签名接收方用发送方公钥验证签名它通常提供三类保证完整性数据没有被篡改身份认证能确认发送方身份不可否认性发送方事后不能否认自己签过名七、访问控制模型怎么选1. 访问控制在解决什么问题认证只能说明“你是谁”并不能说明“你能不能做这件事”。真正把权限管起来靠的是访问控制模型。2. 常见模型模型特点更像什么场景DAC(Discretionary Access Control)自主访问控制资源拥有者自行决定授权个人文件共享、弱中心化场景MAC(Mandatory Access Control)强制访问控制系统基于安全标签强制控制军事、涉密、强等级保护场景RBAC(Role-Based Access Control)基于角色的访问控制通过角色组织权限企业系统、后台管理、SaaS 平台ABAC(Attribute-Based Access Control)基于属性的访问控制根据用户、资源、环境等属性动态决策复杂策略、细粒度控制、多租户场景3. RBAC 为什么最常考因为大多数业务系统里最自然的权限组织方式就是“用户 - 角色 - 权限”。例如管理员可以管理用户和系统配置审计员只能看日志和报表普通用户只能查看和操作自己的数据RBAC 的核心不是“直接给用户发一堆权限”而是先定义角色再把权限赋给角色再把用户关联到角色。这样更适合管理也更容易扩展。4. ABAC 为什么更灵活ABAC 不只看“你是谁”还可以看资源属于谁请求发生在什么时间和地点当前网络环境是否可信数据是否属于当前租户所以它更适合细粒度、动态化、安全规则复杂的系统但实现和治理成本也更高。八、怎么考怎么答1. 可靠性题题干如果强调“平均故障间隔时间、修复时间、可用度”通常是在考可靠性指标如果强调“主备切换、容错、监控、降级”通常是在考如何提升可靠性。2. 恢复块与 N 版本题题干如果出现“后备版本、验证测试、回退重试”优先想到恢复块如果出现“多个版本并行运行、表决器、多数投票”优先想到 N 版本程序设计。3. 安全机制题题干如果问“如何证明身份”写认证如果问“如何限制操作范围”写授权或访问控制如果问“如何防篡改”写完整性校验、摘要或数字签名如果问“如何防泄露”写加密。4. 加密方案题题干如果是“大量数据传输”优先想到对称加密如果重点是“安全分发密钥”或“建立信任”优先想到非对称加密如果重点是“校验内容是否被改”优先想到哈希或数字签名。九、答题模板1. 可靠性定义题可靠性是指软件系统在规定条件和规定时间内完成规定功能的能力。提高系统可靠性通常可采用冗余、检错、容错、异常处理和监控告警等手段。2. 软硬件可靠性对比题硬件可靠性受物理磨损和老化影响失效率通常呈浴盆曲线软件不存在物理磨损不会因闲置而老化但软件修改可能引入新的缺陷因此两者在失效规律和维护方式上存在明显差异。3. 恢复块 / N 版本题恢复块采用顺序执行和验证测试机制在主块失败后回退并尝试后备块属于反向恢复N 版本程序设计采用多个独立版本并行执行通过表决器输出结果属于向前恢复实时性通常更好但资源成本更高。4. 安全三要素题安全性通常从机密性、完整性和可用性三个方面考虑。机密性防止未授权访问完整性防止数据被非法篡改可用性保证合法用户能持续访问系统资源。5. 加密方案题对称加密适合大量数据加密非对称加密适合密钥交换和身份建立摘要算法适合完整性校验数字签名适合验证身份、完整性和不可否认性。工程上通常将多种机制组合使用而不是只依赖单一算法。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2557674.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!