Day16-01｜4.1.1 信息安全的概念：从保护数据到保障系统可信运行

本文对应《系统架构设计师教程（第2版）》第4章“信息安全技术基础知识”4.1.1“信息安全的概念”。信息安全是高级系统架构设计师必须贯穿理解的基础主题，它并非安全产品的简单堆叠，而是围绕信息和系统的机密性、完整性、可用性、真实性、不可否认性与可控性建立风险管理体系。

一、学习目标

完成本节后，应能够：

1. 解释信息安全的基本含义、目标和保护对象；
2. 掌握机密性、完整性、可用性等核心安全属性；
3. 区分安全威胁、脆弱性、风险和安全措施；
4. 从技术、管理、人员和制度角度设计纵深防御体系；
5. 在案例和论文中把安全要求落实到架构、流程和运行控制。

二、什么是信息安全

信息安全是保护信息及其处理、存储、传输和使用过程，使其免受未经授权的访问、使用、披露、修改、破坏、丢失和拒绝服务，并保证信息系统能够按照预期目标持续、可信地运行。

这里的“信息”不只是数据库中的字段，也包括纸质资料、文件、源代码、配置、日志、密钥、接口消息、业务规则和人员知识；“系统”也不只是服务器，还包括终端、网络、应用、平台、人员、流程、组织和外部依赖。

三、信息安全的核心属性

1. 机密性

机密性是指信息只能被经过授权的主体访问和使用，防止信息泄露给无权主体。例如工资、病历、客户身份证号、源代码和商业合同不能被不相关人员查看。机密性措施包括身份认证、访问控制、加密、脱敏、密钥管理、网络隔离和数据防泄漏。

机密性不是“所有数据都加密”这么简单。架构师需要先进行数据分类分级，明确谁在什么场景下需要什么粒度的数据，再决定存储、传输、展示、导出和备份保护方式。权限过大、共享链接长期有效、日志包含敏感字段和测试环境复制生产数据，都是常见泄露途径。

2. 完整性

完整性是指信息在存储、传输和处理过程中没有被未经授权地修改、删除或破坏，并且修改能够被发现和追溯。例如订单金额、审批结论、财务凭证、库存数量和日志不能被无痕篡改。

完整性可以通过数字签名、消息认证码、哈希校验、数据库约束、事务、版本控制、审批和不可抵赖日志保障。业务系统还要控制状态转换，不能允许用户直接把订单从“待支付”修改为“已完成”。完整性不仅是技术问题，也依赖职责分离、操作规程和审计。

3. 可用性

可用性是指授权用户在需要时能够及时访问信息和使用系统。停机、网络中断、资源耗尽、勒索软件、恶意流量和单点故障都会影响可用性。

可用性设计包括冗余、集群、负载均衡、备份、容灾、限流、熔断、降级、监控和应急预案。架构师要根据业务重要性定义恢复时间目标（RTO）和恢复点目标（RPO）。支付、政务、医疗和生产系统可能要求更高的连续性，普通内部查询系统则可以接受更长恢复时间。

可用性与机密性、完整性可能存在冲突。严格的认证和加密可能增加访问延迟，异地灾备可能扩大数据暴露面，强一致控制可能影响高并发。安全架构需要根据风险和业务目标进行权衡。

4. 真实性与可鉴别性

真实性关注信息来源和通信主体是否真实，确保系统知道“是谁发来的、数据是否来自可信来源”。可鉴别性关注用户、设备、服务和消息是否能够被识别。统一身份、多因素认证、数字证书、设备指纹和签名可以支持真实性判断。

5. 不可否认性

不可否认性是指参与者不能否认已经发生的操作或承诺，例如合同签署、付款审批、电子申报和关键配置变更。数字签名、可信时间戳、完整审计日志、审批记录和密钥保护可以建立证据链。

6. 可控性与可审计性

可控性要求系统能够按照授权和制度控制信息使用；可审计性要求能够记录、检查和还原安全相关活动。日志必须包含主体、对象、动作、时间、结果和来源，并防止被普通管理员随意删除或修改。

四、安全威胁、脆弱性、风险与措施

安全分析中容易混淆四个概念。威胁是可能造成损害的潜在因素，如黑客攻击、恶意软件、内部滥用、误操作、自然灾害和供应链风险；脆弱性是系统自身存在的弱点，如弱密码、未修复漏洞、权限过大、配置错误和缺少备份；风险是威胁利用脆弱性后造成损失的可能性和影响；安全措施是降低可能性或影响的控制手段。

可以用下面的关系理解：

威胁 × 脆弱性 → 安全事件 → 影响 → 风险

例如，攻击者是威胁因素，公网接口缺少鉴权是脆弱性，未授权调用是安全事件，客户数据泄露是影响，最终形成业务、法律和声誉风险。防护不能只针对攻击者，也要修复接口鉴权、数据权限和审计缺失等脆弱性。

风险评估通常考虑资产价值、威胁可能性、脆弱性程度和影响范围。高价值、高暴露和高影响系统应采用更强保护；低风险系统不应无限增加复杂控制。安全架构应服务于风险降低，而不是追求产品数量。

五、纵深防御思想

纵深防御是指不依赖单一安全措施，而是在身份、终端、网络、应用、数据、运维和管理多个层面设置相互补充的防线。某一层控制失效时，其他层仍能发现、阻断或降低影响。

纵深防御不是把所有措施无条件叠加，而是根据业务边界和风险等级安排控制。系统内部也不能天然信任，服务之间需要鉴权和最小权限；外部流量需要验证，内部管理员同样需要审计。

六、安全管理与技术防护的关系

技术措施解决“系统能否控制和检测”，管理措施解决“组织是否要求、谁负责以及如何持续执行”。没有制度和人员责任，安全产品可能无人维护；没有技术落地，制度就容易停留在纸面。

安全管理包括安全策略、组织职责、资产管理、风险评估、人员管理、供应商管理、变更管理、事件响应、业务连续性和合规审计。人员入职、转岗和离职都应有账号与权限流程；开发、测试和生产环境要隔离；外包人员访问要有合同、范围和期限；安全事件要有发现、分级、处置、取证、恢复和复盘。

七、身份、访问控制和最小权限

身份认证解决“你是谁”，授权解决“你能做什么”，审计解决“你做了什么”。三者不能混为一谈。登录成功不代表可以访问所有数据，拥有菜单权限不代表可以修改所有状态。

访问控制可以使用自主访问控制、强制访问控制、基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）。RBAC适合岗位和职责相对稳定的组织，ABAC可以结合部门、区域、数据密级、时间、设备和风险动态判断。高风险操作可以要求二次认证、双人复核或审批。

最小权限要求主体只获得完成工作所需的最小功能、数据和时间范围。权限要有申请、审批、授予、使用、复核和回收生命周期。服务账号、API密钥和管理员账号也需要负责人、有效期、轮换和审计，不能因为是“系统账号”就长期拥有全部权限。

八、安全架构设计的基本流程

安全架构可以按以下过程开展：识别业务目标和资产；进行数据分类分级；分析威胁、脆弱性和风险；提出安全需求；设计身份、网络、应用、数据和运维控制；验证安全措施有效性；上线后持续监控和改进。

安全需求应可验证。例如“敏感数据需要保护”过于笼统，可以细化为“敏感字段在存储和传输中加密”“导出需要审批并记录”“离职账号在规定时间内禁用”“关键操作日志保存指定期限”“核心服务达到目标可用性”。可验证需求才能进入测试和验收。

九、案例分析：政务数据共享平台安全设计

某政务数据共享平台需要为多个部门提供人口、法人、证照和办件数据。建设方提出“各部门直接访问共享数据库，方便查询”。请分析问题并给出方案。

直接开放数据库会造成权限粒度粗、数据责任不清、结构耦合、越权查询、敏感数据扩散和审计困难。建议建立数据目录和共享服务，以接口或受控数据集提供最小必要字段；明确人口、法人和证照数据的权威部门；调用方需要进行身份认证、用途授权和范围控制；敏感字段脱敏或加密；接口支持限流、审计、调用期限和异常告警；对高风险数据访问采用审批或二次确认；建立数据质量反馈、撤销授权和调用对账机制；共享平台与业务库隔离，避免查询冲击核心交易；保留调用主体、时间、事项、字段和结果记录；当接口或数据库故障时提供降级和应急服务。

该方案体现了机密性、完整性、可用性、可审计性和最小权限，而不是简单地增加防火墙。

十、综合知识练习

选择题1

下列属于信息安全完整性要求的是（ ）。

A. 只有授权人能够查看工资数据 B. 订单金额修改必须留痕且不能被无痕篡改 C. 系统发生故障后能够恢复 D. 用户登录需要验证码

答案：B。解析：完整性关注数据未经授权的修改、删除和破坏，以及修改是否可发现、可追溯。

选择题2

下列最符合最小权限原则的是（ ）。

A. 所有员工使用管理员账号 B. 服务账号永久拥有全部数据库权限 C. 用户只访问完成职责所需的组织和字段 D. 生产密钥写在代码仓库中

答案：C。解析：最小权限同时约束功能、数据、范围和时间。

简答题

请区分威胁、脆弱性和风险，并各举一个例子。

参考答案：威胁是可能造成损害的因素，如攻击者、恶意软件或自然灾害；脆弱性是系统自身的弱点，如接口无鉴权、弱密码或缺少备份；风险是威胁利用脆弱性后造成损失的可能性和影响。例如攻击者是威胁，公网接口无鉴权是脆弱性，未授权读取客户数据并造成泄露就是由二者共同形成的安全风险。

十一、论文素材与今日复盘

论文可写：“在架构设计阶段，我以业务资产和风险为起点，而不是简单叠加安全产品。首先对数据进行分类分级，识别机密性、完整性和可用性要求；随后通过统一身份、最小权限、网络分区、接口鉴权、数据加密、密钥管理、备份容灾和安全审计建立纵深防御。对关键操作实行职责分离和人工复核，对账号和密钥实施全生命周期管理，并通过监控、应急响应和定期复盘保证安全控制持续有效。”

今日复盘：信息安全保护的是信息和系统的可信运行；机密性、完整性、可用性是核心属性，真实性、不可否认性和可审计性是重要补充；安全设计要从风险出发，采用纵深防御、最小权限和持续治理。下一篇进入 4.1.2 信息存储安全。