[CISSP] [8] 安全模型,设计和能力的原则
开源软件（Open Source Software, OSS）
优点：
-
透明性高
开源软件的源代码对公众开放，安全专家和用户可以检查其实现，验证是否存在安全隐患。 -
社区驱动的漏洞发现
有大量开发者和安全研究人员参与代码审查，可以更快发现和修复漏洞。 -
可定制性强
用户可以根据自身需求修改源代码，更好地满足特定的安全策略或需求。 -
降低供应链信任风险
用户可以自行构建和验证软件，降低对第三方厂商的完全信任需求。
缺点：
-
不保证质量与维护
开源项目的维护可能不稳定，开发者流动性大，一些项目存在无维护风险。 -
缺乏正式支持
与商业闭源软件相比，开源软件通常缺少标准化的技术支持服务。 -
可能被篡改
如果使用未验证的来源或构建方式，容易被插入恶意代码。
闭源软件（Closed Source Software）
优点：
-
官方支持和维护
通常由厂商提供正式的技术支持和长期维护，适合企业级使用。 -
统一的安全控制策略
安全更新由厂商集中发布，便于一致性管理。 -
商业责任保障
商业合同中可纳入安全责任、补丁及时性等约定。
缺点：
-
不可审查源码
安全研究人员无法查看其内部实现，需完全信任厂商。 -
潜在后门风险
若厂商不遵守安全开发流程，可能存在隐性漏洞或后门，用户难以发现。 -
依赖供应商
安全修复速度依赖厂商响应速度，可能导致滞后风险。
“默认安全配置”（Secure Defaults 或 Default Secure Configuration）是 CISSP 第八章中一个非常重要的安全设计原则，在实际系统设计、安全架构和产品评估中经常被考查。
默认安全配置（Secure Defaults）
定义：
默认安全配置是指系统或软件在初始安装或部署时，应该采用最安全的默认设置，即：
- 默认开启必要的安全机制
- 默认关闭不必要的服务或功能
- 默认使用强加密和身份验证配置
为什么重要：
-
减少人为错误风险
很多安全事件是因为管理员未及时关闭默认账户、开放端口、或禁用不安全功能。 -
提升初始安全性
即使用户未手动配置，系统也应默认提供一定程度的防护。 -
防止“即装即漏洞”
若默认配置不安全，如默认密码“admin/admin”，系统在未配置前即存在风险。
安全配置的关键要素：
| 项目 | 安全默认做法 |
|---|---|
| 用户账户 | 禁用或删除默认账户，强制创建新账户 |
| 密码策略 | 默认启用强密码策略（复杂度、长度、过期） |
| 服务 | 默认关闭非必要服务和端口 |
| 权限 | 默认使用最小权限原则 |
| 网络访问 | 默认限制外部访问（如关闭公网接口） |
| 加密 | 默认启用加密（如 HTTPS、TLS 1.2 以上） |
| 日志记录 | 默认启用审计和日志功能 |
“失效安全”（Fail-Safe 或 Fail-Secure）也是 CISSP 第八章中的核心安全设计原则之一，主要强调在系统出现故障或异常情况下，应该优先保证系统安全性，而不是可用性。
失效安全（Fail-Safe / Fail-Secure）
定义：
失效安全是一种安全设计策略，指的是当系统发生故障、异常、或组件失效时，系统应自动切换到最安全的状态，防止进一步的破坏或未经授权的访问。
两种常见形式：
| 类型 | 说明 | 示例 |
|---|---|---|
| Fail-Safe | 失效后默认拒绝访问，优先保护数据和资源 | 门禁系统断电后门上锁 |
| Fail-Open | 失效后默认允许访问，优先保持可用性 | 防火系统失效时默认开放网络通信 |
注意：Fail-Open 在某些高可用场景下可接受，但不推荐用于高安全性系统。
实例解析：
-
门禁系统
- Fail-Safe：断电后门锁上，防止未授权人员进入（安全优先）
- Fail-Open：断电后门打开，方便疏散（生命安全优先）
-
防火墙或入侵检测系统
- Fail-Safe：系统异常时自动封锁外部流量（防止攻击）
- Fail-Open：系统异常时继续放行流量（可用性优先，但存在风险）
与其他原则的关系：
- 与默认安全配置类似，失效安全强调“在最坏情况下仍然默认保护系统”。
- 与最小权限原则配合使用可以有效减少失效造成的攻击面。
- 属于系统弹性设计中的核心部分。
KISS 原则（Keep It Simple, Stupid）是 CISSP 安全架构设计中一个非常经典且重要的原则，中文常翻译为“保持简单，傻瓜式设计”或“保持简单，别搞复杂”。
KISS 原则（Keep It Simple, Stupid）
定义：
KISS 原则主张在系统设计中应尽可能保持结构、流程和实现的简洁明了，因为复杂性是安全的敌人。
- 简洁的系统更容易理解、维护和审查
- 简洁的代码更少出错，更不容易隐藏漏洞
- 简洁的架构更容易验证和实施安全控制
KISS 在信息安全中的应用：
| 场景 | KISS 实现方式 |
|---|---|
| 安全架构设计 | 只引入必要的组件，避免过度堆叠技术层 |
| 访问控制系统 | 使用清晰的权限层级模型，避免嵌套混乱 |
| 加密方案 | 使用标准、成熟算法，避免自创复杂加密逻辑 |
| 审计和日志系统 | 结构清晰，便于分析，不堆砌无用数据 |
| 编码实践 | 代码模块化、无冗余逻辑、接口清晰 |
“分段防火墙”通常指的是在网络架构中结合网络分段（Segmentation）技术部署的防火墙策略，用于实现不同网络区域之间的安全隔离和访问控制。这是企业级安全设计中的核心组件，尤其是在 分区/分段/分控（Zone/Segment/Control） 的模型中非常常见。
分段防火墙(ISFW)
定义：
分段防火墙（Segmented Firewall） 是指在网络被分为多个逻辑或物理子网（如 VLAN、子网、DMZ、用户区域、服务器区域等）之后，在这些子网之间部署的防火墙，以控制跨分段流量的通信权限。
它的目标是：
- 最小化信任，阻止不必要的通信路径
- 隔离关键资产，减小攻击面
- 增强访问控制粒度，使策略更灵活且有针对性
常见部署场景
| 区域 | 分段目标 | 防火墙策略示例 |
|---|---|---|
| 用户网络 ↔ 服务器区 | 阻止用户直接访问核心数据库 | 限制端口，仅允许业务流量（如 443） |
| 办公网 ↔ 生产网络 | 控制横向访问 | 拒绝大多数流量，仅允许特定管理连接 |
| DMZ ↔ 内部网络 | 防止攻击者通过 DMZ 入侵内部 | 从内网发起访问可控，DMZ 不可主动连接内网 |
| 分布式数据中心 ↔ 云端 | 精细化访问控制 | 按应用、服务、身份分段 |
多因子身份认证(MFA)
定义：
MFA 是指用户在访问系统时，必须提供两个或以上“不同类型”的认证因子，以增强身份验证的安全性。
认证因子类别
| 类型 | 描述 | 示例 |
|---|---|---|
| 知道的东西 | Something you know | 密码、PIN码、安全问题 |
| 拥有的东西 | Something you have | 手机、硬件令牌、短信验证码 |
| 属于你的 | Something you are | 指纹、面部识别、虹膜、声音 |
MFA 必须来自至少两个不同类别，例如密码（知道）+ 手机验证码（拥有）
MFA 与其他认证方式的对比
| 认证方式 | 安全性 | 便捷性 | 是否推荐用于敏感系统 |
|---|---|---|---|
| 单因素认证（如密码） | 低 | 高 | 否 |
| 双因素认证（2FA） | 中 | 中 | 是 |
| 多因素认证（MFA） | 高 | 适中 | 是（强烈推荐） |
常见 MFA 实施方式
- TOTP（时间同步一次性密码）：如 Google Authenticator、Authy
- 短信验证码 / 邮件验证码（不推荐，容易被拦截）
- 推送确认：如 Microsoft Authenticator、Duo
- 硬件令牌：如 YubiKey、RSA SecureID
- 生物识别：指纹、人脸、声纹等
- 基于 FIDO2/WebAuthn 的无密码认证：逐步替代传统 MFA 的方向
身份和访问管理(IAM)
IAM（Identity and Access Management） 是指一组用于标识用户身份、验证身份真实性、分配访问权限，并管理这些权限的技术、策略和流程。
IAM 的核心组成模块
| 模块 | 描述 |
|---|---|
| 身份识别（Identification） | 唯一标识用户或实体（如用户名、ID） |
| 身份验证（Authentication） | 验证用户是否为其声称的身份（如密码、生物识别、MFA） |
| 授权（Authorization） | 决定用户是否有权限访问特定资源（如访问控制模型） |
| 审计与监控（Accountability） | 记录和追踪用户行为，确保用户对其行为负责（如日志、审计） |
访问控制模型
IAM 的授权过程依赖于访问控制模型：
| 模型 | 描述 | 示例 |
|---|---|---|
| DAC（自主访问控制） | 资源所有者决定谁可以访问 | Windows 文件权限 |
| MAC（强制访问控制） | 基于标签/等级进行严格控制 | 军事系统、安全级别访问 |
| RBAC（基于角色的访问控制） | 根据用户角色授予权限 | HR 有查看员工资料权限 |
| ABAC（基于属性的访问控制） | 基于用户、资源、环境等属性灵活授权 | “若用户是经理且时间是工作日” |
| PBAC（基于策略的访问控制） | 基于策略语言进行动态授权 | 用于云平台、微服务 |
常见 IAM 技术组件
| 组件/技术 | 功能 |
|---|---|
| SSO（单点登录） | 用户登录一次即可访问多个系统 |
| LDAP | 目录服务，常用于存储用户账户信息 |
| Active Directory（AD） | 微软的目录服务和身份管理平台 |
| Federation（身份联合） | 在组织之间共享认证凭证（如 SAML, OAuth） |
| IAM 平台 | 如 Okta、Ping Identity、Azure AD 等 |
气隙（Air Gap）
定义：
气隙是一种将计算机系统或网络物理隔离的安全策略，即该系统与其他系统（如互联网或企业内网）之间没有任何物理或逻辑连接。
简而言之：断网运行，完全隔离。
气隙的主要目的
| 目的 | 说明 |
|---|---|
| 防止远程攻击 | 没有网络接口就无法从远程攻击 |
| 保护敏感数据 | 如国家秘密、军事情报、金融核心数据等 |
| 防止数据泄露 | 无法通过网络传输数据，阻止外泄通道 |
| 增强物理安全控制 | 必须物理访问设备，增加攻击成本 |
典型应用场景
| 行业 / 场景 | 说明 |
|---|---|
| 军事系统 | 高机密作战系统、情报分析终端 |
| 国家基础设施（ICS/SCADA） | 电力、水利、核电控制系统 |
| 金融行业 | 清算核心系统、风控引擎 |
| 科研机构 / 实验室 | 保密研究项目、加密研究 |
| 加密钱包 / 冷钱包 | 数字货币私钥存储于“气隙”设备中 |
如何实现气隙隔离
| 控制点 | 措施示例 |
|---|---|
| 网络连接 | 禁用网卡、无线网、蓝牙、USB 网卡等 |
| 物理接口 | 禁用 USB、光驱、SD 卡槽，使用封条或胶封 |
| 操作系统 | 禁用自动运行、日志审计强化 |
| 数据转移控制 | 严格使用加密介质（如特定 U 盘，需审批） |
气隙系统的风险与挑战
虽然气隙安全性强，但并非不可突破，且存在管理挑战：
| 风险类别 | 说明 |
|---|---|
| “跨气隙攻击” | 攻击者通过 USB、恶意外设、甚至电磁波、声音传播信息等手段绕过气隙 |
| 操作繁琐 | 需要手动传输文件，效率低 |
| 更新困难 | 系统补丁、安全策略无法自动同步，需人工操作 |
| 依赖人为控制 | 安全策略靠制度+人为执行，容易被忽视或违反 |
真实案例：
- Stuxnet 病毒：成功感染了伊朗核设施气隙控制系统，通过 USB 间接入侵
隐私设计（PbD）
定义：
隐私设计（Privacy by Design，PbD） 是由安娜·卡瓦科（Ann Cavoukian）提出的隐私保护框架，旨在将隐私考虑嵌入到产品和服务的设计中，从规划阶段开始就保护用户隐私。
该原则强调通过以下方式实现隐私保护：
- 从一开始就设计隐私：隐私保护应是设计的一部分，而不是附加的安全措施。
- 默认隐私设置：系统默认配置应最大程度地保护个人隐私。
- 将隐私视为一种隐性权利：尊重和保障用户隐私。
PbD 的七个核心原则
PbD 的核心原则包括以下七个：
| 原则 | 描述 |
|---|---|
| 1. 积极隐私（Proactive not Reactive） | 隐私保护应是主动设计，而非事后补救。我们应预测隐私风险并采取措施应对。 |
| 2. 隐私作为默认设置（Privacy as the Default Setting） | 在没有明确选择时，系统默认应最大化保护隐私，确保最小的数据收集。 |
| 3. 隐私设计完整性（Privacy by Design） | 隐私应在技术设计、流程和程序中集成，而不是附加的。 |
| 4. 完整的功能性（Full Functionality — Positive-Sum, not Zero-Sum） | 隐私保护与其他功能（如安全性、可用性）应协调，互不妥协。 |
| 5. 安全性（End-to-End Security — Full Lifecycle Protection） | 在整个生命周期中保护个人数据，包括存储、传输和删除。 |
| 6. 可视化和可控性（Visibility and Transparency） | 用户应有明确的隐私政策，并且他们应能清楚地看到隐私设置和数据使用情况。 |
| 7. 用户的隐私权（Respect for User Privacy） | 给用户充分控制个人数据的权利，并以透明、尊重的方式处理数据。 |
PbD 的实施方式
实施Privacy by Design时，可以采取以下措施来确保隐私得到保护：
1. 数据最小化（Data Minimization）
- 仅收集和处理必要的数据。
- 使用数据匿名化、加密等方法，减少存储敏感数据的风险。
2. 数据加密与安全存储
- 对所有存储的个人数据进行加密，确保数据在传输过程中也保持加密。
- 利用 端到端加密（E2EE） 确保数据在整个生命周期中始终受到保护。
3. 强制执行最小权限原则
- 设计和部署系统时，确保最小权限访问，即用户和员工只应访问其工作所需的数据。
4. 透明度和用户控制
- 提供用户清晰、透明的隐私政策，让用户能够方便地管理和查看他们的数据。
- 提供隐私控制面板，让用户可以轻松地更新偏好设置或删除数据。
5. 增强审计和日志记录
- 对所有访问、修改、删除数据的操作进行审计和日志记录，确保可以追踪隐私违规行为。
6. 应急响应与合规性监控
- 确保系统设计中包括了隐私保护事件的快速响应机制。
- 定期审查隐私合规性和数据保护措施，确保其符合GDPR等法规要求。
TCB（可信任计算基）
定义：
TCB（Trusted Computing Base） 是指实现安全功能的所有硬件、固件和软件组件的集合，构成了一个系统的“可信任”部分。它保证了系统的安全性，例如防止恶意软件的入侵、数据泄露等。
TCB 可以看作是实现系统安全策略的最小可信组件集，任何一个不可信的部分都会削弱系统的整体安全性。
TCB 的核心组成部分
1. 硬件
- CPU：负责处理指令和控制系统的核心部分。
- 内存：存储数据和程序，确保数据不会被未经授权访问。
- 硬件安全模块（HSM）：专门用于加密操作的硬件，用于密钥管理、身份验证等。
固件
- BIOS/UEFI：在操作系统启动之前负责加载操作系统和管理硬件资源的程序。可信的固件对于启动过程中保护系统至关重要。
- 引导程序（Bootloader）：启动操作系统时加载和验证系统核心（内核）。
操作系统和核心服务
- 内核（Kernel）：操作系统的核心，控制系统的资源和调度任务。内核中的漏洞或不安全代码可能直接影响 TCB 的安全性。
- 安全模块：包括认证、加密、访问控制等子系统，用于确保系统的完整性和保密性。
认证和安全协议
- 用户身份验证：例如多因素认证（MFA），密码学算法等安全协议。
- 加密服务：确保数据传输和存储中的机密性。
TCB 的目标与作用
1. 保护机密性
- TCB 保障数据、信息和资源不被未经授权的访问。
2. 防止篡改与攻击
- 通过验证代码的完整性，防止恶意软件的注入与篡改。
3. 实现可验证性
- 可信任计算基确保每个组件都经过验证，保证操作系统或应用程序在预期的安全环境中运行。
4. 增强系统可信度
- 确保计算机系统的功能运行不受攻击，并且在面临外部威胁时能够提供安全性保障。
可信计算与 TCB 的关系
可信计算（Trusted Computing）是一个广泛的概念，它包括一系列技术、协议和标准，旨在通过硬件、软件和操作系统的共同协作来增强计算环境的安全性。TCB 是可信计算的基础，它是系统可信计算环境的核心。
1. TCB 与 TPM
- TPM（Trusted Platform Module） 是一个硬件安全模块，它是实现可信计算和保护 TCB 的关键组件。TPM 可用于生成和存储加密密钥，提供硬件级的安全性。
2. TCB 与 Attestation
- Attestation（认证） 是确保计算机系统的安全性和可信性的一种方法。通过 Attestation，可以验证系统是否在受信任的环境中运行。TCB 是这种认证的基础。
TCB 的评估和管理
TCB 的安全性与完整性对整个计算环境的可信度至关重要。以下是评估和管理 TCB 的常见方法：
1. 最小化 TCB 规模
- 为了降低攻击面，确保 TCB 仅包含最基本、最必要的组件，避免不必要的模块增加系统复杂性和潜在风险。
2. 安全审计与验证
- 对 TCB 组件进行定期的安全审计和验证，检查是否存在漏洞或不符合安全标准的组件。
3. 及时补丁和更新
- TCB 组件（包括硬件、固件、操作系统）必须及时应用安全补丁和更新，以防范已知的攻击和漏洞。
4. 完整性保护
- 使用技术（如加密哈希、签名验证等）确保 TCB 组件在整个生命周期中保持完整性，防止篡改。
Meltdown 和 Spectre 是两种影响现代处理器架构的严重安全漏洞，它们利用了硬件层面的缺陷，可以使攻击者在不应有权限的情况下访问内存内容。它们暴露了处理器的预测执行特性，并被认为是现代计算机系统安全的重大威胁。下面我们来详细介绍这两种漏洞，以及它们对内存保护和计算安全的影响。
Meltdown（熔断）
1. 概述
- Meltdown 是在 2018 年 1 月发现的一个安全漏洞，影响了几乎所有的Intel处理器。它利用了出错执行（Out-of-Order Execution）和内存隔离的设计缺陷，使得攻击者能够绕过系统的内存保护机制，直接访问操作系统内核空间的敏感数据。
2. 漏洞原理
- Meltdown 漏洞通过绕过操作系统和硬件的内存保护机制，使得攻击者能够访问受保护的内核内存。攻击者能够通过合法的用户进程代码，利用处理器的推测执行特性，访问并窃取其他进程的数据。
- 推测执行：当处理器遇到可能会阻塞的指令时，它会预测指令的结果并继续执行，以提高性能。如果推测执行的结果是错误的，处理器会丢弃结果。然而，即使错误的推测执行结果被丢弃，处理器会在缓存中保留这些信息。
- 攻击者可以通过缓存侧信道攻击，读取这些被丢弃的数据。
3. 影响
- Meltdown 主要影响 Intel 处理器，尤其是2008年之后的处理器系列（包括部分Core、Xeon、Atom等）。AMD 处理器和大多数ARM 处理器不受影响。
- 攻击者能够从应用程序层（例如浏览器或恶意代码）绕过内存隔离访问内核级别的敏感数据，包括密码、加密密钥等。
4. 防御措施
- 操作系统修复：许多操作系统（如 Linux、Windows）发布了内核隔离补丁，以保护内核空间的内存不被普通用户空间进程访问。这通过修改操作系统内核的页面表（page tables）和虚拟内存管理来实现。
- 硬件修复：新发布的处理器版本加入了硬件支持，用于修复 Meltdown 漏洞。
Spectre（幽灵）
1. 概述
- Spectre 是与 Meltdown 同时发现的另一个漏洞，影响了几乎所有现代的处理器（包括 Intel、AMD 和 ARM）。它通过推测执行漏洞，允许攻击者读取不应被访问的内存内容，包括其他进程的数据。
2. 漏洞原理
- Spectre 漏洞利用了处理器的分支预测机制。分支预测是现代处理器中用于提高指令执行效率的技术，通过预测程序代码中的条件跳转（例如 if/else）来提前执行指令。
- Spectre 利用分支预测中的不正确预测，迫使处理器执行不应该执行的指令，进而在缓存中泄露数据。虽然错误的预测执行会被丢弃，但数据仍然可能通过缓存侧信道被攻击者读取。
3. 影响
- Spectre 攻击不仅影响 Intel 处理器，还影响其他厂商的处理器，包括 AMD 和 ARM 处理器。
- Spectre 的漏洞比 Meltdown 更为广泛，因为它影响所有使用预测执行技术的处理器。它不依赖于操作系统层面的漏洞，而是通过物理硬件层面的问题进行攻击。
4. 防御措施
- 操作系统补丁：操作系统和应用程序必须进行代码更新以防止 Spectre 攻击，尤其是禁用或修补分支预测功能。具体的解决方法包括对不可信的分支预测进行限制和延迟执行。
- 硬件改进：部分新的处理器引入了硬件级别的分支预测修复，通过改变预测执行和缓存机制来减少攻击面。