📚 课程目录第2章网络安全基础

2、网络安全基础：CIA三元组、身份认证、授权、审计、不可否认性

网络安全的核心目标并非单一的技术指标，而是围绕信息与系统的机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）展开，即CIA三元组。在此基础上，身份认证（Authentication）、授权（Authorization）、审计（Audit）与不可否认性（Non-repudiation）构成了支撑CIA落地的四大支柱。理解这些基础概念及其相互关系，是分析一切网络威胁、设计安全架构的起点。本章将深入剖析这些核心要素，并结合实际场景说明其应用与常见误区。

上图展示了CIA三元组与四大支撑机制之间的逻辑关系。CIA是安全目标，而身份认证、授权、审计与不可否认性则是达成这些目标的具体手段。例如，身份认证是确保机密性的第一道门，审计是维护完整性的重要工具，而不可否认性则直接服务于责任追溯。下面我们将逐一深入探讨。

2.1 CIA三元组：安全目标的基石

核心原理

CIA三元组是信息安全领域最基础、最核心的安全模型，它定义了组织保护数据和信息系统所需达成的三个核心目标：

机密性（Confidentiality）：确保信息仅被授权的人员、实体或进程访问。其核心是防止未授权的信息泄露。常见的实现手段包括数据加密（静态与传输中）、访问控制列表（ACL）、最小权限原则等。
完整性（Integrity）：确保信息的准确性、一致性和可信赖性。它要求数据在存储或传输过程中未被未授权修改、删除或重放。实现手段包括哈希算法（如SHA-256）、数字签名、消息认证码（MAC）以及数据库事务的ACID属性。
可用性（Availability）：确保授权用户在需要时能够及时、可靠地访问信息和系统资源。其对立面是拒绝服务（DoS）攻击。保障可用性涉及冗余设计、负载均衡、灾难恢复计划以及DDoS防护措施。

判断方法或操作流程

在实际安全评估中，判断一个系统是否满足CIA要求，通常采用以下流程：

资产识别与分类：明确需要保护的数据资产（如客户PII、源代码、财务数据），并依据敏感度进行分级（公开、内部、机密、绝密）。
威胁建模：针对每类资产，分析可能破坏CIA的威胁源（如黑客、内部人员、自然灾害）。
控制措施映射：将现有的安全控制（技术、管理、物理）映射到CIA的每个维度，检查是否存在覆盖盲区。
残余风险分析：评估在现有控制下，CIA被破坏的可能性及影响程度，确定是否可接受。

案例拆解：勒索软件攻击下的CIA权衡

某企业遭遇勒索软件攻击，攻击者加密了核心数据库（破坏完整性），并威胁若不支付赎金就公开数据（破坏机密性）。同时，业务系统因数据无法读取而瘫痪（破坏可用性）。在此场景下，安全团队的应急响应优先级通常是：先恢复可用性（业务连续性），再通过备份验证完整性，最后评估机密性泄露风险。这体现了CIA并非平衡，而是需要根据业务影响进行动态决策。

常见误区或总结复盘

误区：认为CIA是三个独立的目标，可以孤立实现。实际上，它们之间存在张力。例如，过强的加密（机密性）可能导致性能下降，影响可用性；严格的完整性校验（如频繁的哈希比对）可能拖慢系统响应。安全设计必须寻求三者的平衡点。

CIA维度	典型威胁	核心防护技术	失败后果示例
机密性	数据泄露、窃听	AES-256加密、DLP	客户隐私数据被公开售卖
完整性	数据篡改、SQL注入	数字签名、WAF	银行转账金额被篡改
可用性	DDoS、硬件故障	负载均衡、冗余集群	电商平台大促期间宕机

2.2 身份认证：验证“你是谁”

核心原理

身份认证是确认用户、设备或进程所声称身份的过程。它基于三类因素：所知（Something you know），如密码、PIN码；所有（Something you have），如智能卡、手机令牌；固有（Something you are），如指纹、虹膜。多因素认证（MFA）要求组合至少两种不同类别的因素，以显著提升安全性。

判断方法或操作流程

设计一个健壮的认证方案，需遵循以下步骤：

风险分级：根据系统敏感度决定认证强度。普通论坛可用密码，网银则必须MFA。
选择协议：基于Web应用优先采用OAuth 2.0 + OIDC；企业内部服务可使用Kerberos或LDAP。
会话管理：认证成功后，需安全地管理会话令牌（），设置合理的过期时间，防止会话固定攻击。
凭据保护：密码存储必须使用加盐哈希（如bcrypt、scrypt），严禁明文或MD5存储。

案例拆解：钓鱼攻击如何绕过认证

攻击者搭建了一个仿冒公司VPN入口的钓鱼页面。员工输入了用户名、密码以及手机收到的动态验证码（2FA）。攻击者实时将这些信息转发到真实VPN站点，完成登录。此案例说明，即使部署了MFA，若用户缺乏安全意识，仍可能被“中间人攻击”绕过。因此，认证不仅是技术问题，更是管理与培训问题。

常见误区或总结复盘

经验：不要将所有认证压力集中在入口。实施“风险自适应认证”——当用户行为异常（如异地登录、新设备）时，动态追加额外的认证步骤，比静态的强密码策略更有效。

2.3 授权：控制“你能做什么”

核心原理

授权发生在身份认证成功之后，决定已认证的主体（用户/进程）可以访问哪些资源以及执行哪些操作（读、写、执行、删除）。核心原则是最小权限：只授予完成工作所必需的最小权限。常见的访问控制模型包括：

DAC（自主访问控制）：资源所有者自行决定权限分配，如Linux文件权限。
MAC（强制访问控制）：系统根据安全标签（如绝密、机密）强制控制，常用于军事领域。
RBAC（基于角色的访问控制）：权限与角色绑定，用户被赋予角色，简化了权限管理，是企业应用最广泛的模型。
ABAC（基于属性的访问控制）：基于用户、资源、环境属性的动态策略，如“仅允许在工作时间访问财务系统”。

判断方法或操作流程

实施授权的关键步骤：

定义资源与操作：明确系统内所有可被访问的对象（文件、API、数据库表）及其操作类型。
角色与权限矩阵设计：创建角色（如管理员、审计员、普通员工），并绘制角色-权限矩阵。
权限分配与复审：定期审查用户权限，及时回收离职员工或转岗员工的旧权限。

案例拆解：云环境下的权限失控

某公司开发人员在云存储桶（如AWS S3）上设置了“公共读”权限，以便分享测试数据。由于该桶同时存储了生产环境备份文件，导致敏感数据被公网爬取。此案例的根源在于授权配置错误，而非认证被攻破。使用云服务时，必须遵循“默认拒绝”策略，并利用云厂商提供的访问分析工具（如IAM Access Analyzer）持续监控。

常见误区或总结复盘

误区：将授权与认证混为一谈。认证通过不代表可以访问所有资源。一个用户成功登录后，若授权系统存在缺陷（如水平越权漏洞），他可以通过修改URL中的ID参数访问其他用户的订单信息。这是Web应用中最常见的安全漏洞之一。

2.4 审计与不可否认性：事后追溯与责任认定

核心原理

审计（Audit）是记录、监控和分析系统活动日志的过程，旨在发现安全事件、追踪违规行为并为改进提供依据。审计日志应包含：时间戳、用户ID、源IP、操作类型、操作对象及结果。

不可否认性（Non-repudiation）是防止实体否认其已执行的动作。它依赖于数字签名技术：发送方使用私钥对消息摘要进行签名，接收方使用公钥验证签名。由于私钥仅发送方持有，因此发送方无法否认发送过该消息。这与手写签名在法律上具有同等效力。

判断方法或操作流程

构建有效的审计与不可否认机制：

日志完整性保护：使用区块链或WORM（一次写多次读）存储，防止日志被篡改。
时钟同步：确保所有系统时间同步（NTP），否则日志无法作为法律证据。
数字签名流程：对关键交易（如电子合同、转账指令）生成哈希值，并用私钥加密生成签名，附随数据一同发送。

案例拆解：电子合同纠纷中的不可否认性

供应商A与采购商B签订电子采购合同。A使用自己的私钥对合同PDF进行签名，并将签名文件发送给B。后A否认曾发送过该版本合同。B将签名文件、A的数字证书提交至仲裁机构。仲裁机构使用A的公钥成功验证了签名，且哈希比对确认文件未被修改，从而认定A的否认无效。此案例中，数字签名提供了强不可否认性，而审计日志则记录了合同发送的时间、IP等元数据，作为辅助证据。

常见误区或总结复盘

经验：审计日志的价值在于“事后分析”。很多企业在遭受攻击后才发现日志被攻击者清除。建议将日志实时同步至远程日志服务器或SIEM平台，并设置严格的访问权限。对于不可否认性，需注意私钥的保管安全，若私钥泄露，则不可否认性失效。

机制	目的	关键技术	典型应用
审计	记录与监控	日志管理、SIEM	安全事件调查、合规检查
不可否认性	责任认定	数字签名、PKI	电子合同、金融交易

综上所述，CIA三元组定义了安全目标，而身份认证、授权、审计与不可否认性则是实现这些目标的具体技术与管理手段。它们相互依存：没有可靠的认证，授权便无从谈起；没有审计，无法验证CIA是否被破坏；没有不可否认性，事后追责便缺乏依据。在实际工作中，安全人员需要将这六大要素视为一个有机整体，结合业务场景进行系统化设计，才能构建出真正有效的网络安全防线。