读软件开发安全之道：概念、设计与实施02经典原则-CSDN博客

本文链接：https://blog.csdn.net/lyingSeven/article/details/141261336

1. CIA原则

1.1. 软件安全都构建在信息安全的三大基本原则之上，即机密性(confidentiality)、完整性(integrity)和可用性(availability)

1.2. 双方交换的数据

1.2.1. 从技术上看，端点之间的数据交换本身就会削弱交互的机密性
1.2.2. 隐藏通信数据量的一种方法是让端点始终交换恒定数量的数据
1.2.3. 在实际流量较低的时候，则让端点发送虚拟数据包(dummy packet)来维持恒定的数据量

1.3. 授权是CIA各项原则中都固有的元素，它规定数据只能由合法的人员进行访问、修改，数据可用性也只能交由合法人员进行管理

1.4. 机密性和完整性定义为防止未经授权地泄露或篡改信息的行为原则

1.5. 可用性则会受到授权管理员的控制

1.6. 它们只有作为一个整体时才能有效地保护数据资产

2. 机密性

2.1. 不会泄露信息

2.2. 只允许已授权的数据访问

2.3. 维护机密性意味着按照一种仅授权者可读的方式来保护隐私信息

2.4. 必须认真判断哪些信息属于隐私信息

2.4.1. 最安全的做法是把所有从外部收集到的信息都默认为隐私信息，直到有明确的策略来进行界定，并且解释清楚为什么可以对这样的设计方法进行适度的松绑
2.4.2. 一位终端用户可能会理所当然地希望他们的数据是隐私数据（即使这些信息被泄露也无伤大雅），除非他们明确告知某些数据并非隐私
2.4.3. 人们可能会把敏感数据输入不同用途的文本字段中
2.4.4. 信息的收集、处理和保存有可能需要满足各类法律法规的要求，而很多人往往对这些法律法规一无所知
2.4.5. 我们不仅应该明确说出访问规则，还应该解释这些规则背后的主观判断。

2.5. 机密性泄露也有一个频谱

2.5.1. 完全的信息泄露是指攻击者获取到了完整的数据集，其中包括元数据
2.5.2. 这个频谱的另一端则是程度相当轻微的信息泄露，比如内部错误消息或者其他不会造成什么后果的信息被泄露了出去
2.5.3. 所有泄露受保护数据详情的行为，在某种程度上都属于机密性遭到破坏的情形

2.6. 去匿名化(denonymization)或者重标识(reidentification)

3. 完整性

3.1. 准确维护数据

3.2. 不允许未经授权的数据修改或者删除

3.3. 完整性就是指数据的真实性和准确性，其宗旨是防止数据被随意删改

3.4. 除了通过技术手段防止数据遭到未经授权的篡改，一份准确的数据来源记录（包括最初数据源，以及之后授权的数据源变更）也是相当重要、强大的完整性保障

3.5. 保存重要数据的版本并且记录它们的来源，这本身就是防止篡改攻击的典型手段

3.6. 执行增量备份是一种理想的攻击预防手段，因为增量数据保存简单，同时又以一系列快照的形式翔实地记录了哪些数据执行过变更，以及它们在何时执行过变更

3.7. 篡改包括很多不同的方式，并不一定是修改存储设备当中的数据

3.7.1. 篡改可能发生在客户端一侧
3.7.2. 可能发生在客户端和服务器之间
3.7.3. 手段包括欺骗其中某一方修改数据，也包括在页面上修改脚本

3.8. 虽然永久丢失的数据也属于不可用的数据，但是这类数据一般会被认为属于完整性受到彻底破坏的情况

4. 可用性

4.1. 保障数据的可用性

4.2. 不允许出现严重延迟或者未经授权的数据访问关闭

4.3. 针对可用性的攻击是网络世界无法回避的现实问题，也是最难防御的攻击方式之一

4.4. 攻击者向服务器发送过量的数据，通过看似合法的手段占用海量服务资源，导致服务资源耗竭

4.5. 匿名的拒绝服务(Denial of Service，DoS)攻击（一般都是为了索取赎金）几乎可以威胁到一切互联网服务，所以防御这类攻击是非常艰巨的挑战

4.5.1. 需要利用有能力承受大量负载的基础设施来承载大规模的服务，同时维护系统的灵活性，确保在事件发生时基础设施能够迅速实现迁移

4.6. 攻击者创建的恶意请求可以触发错误，导致崩溃或者无限循环，最终破坏服务器的服务

4.7. 其他的攻击方式可以导致应用的存储、计算或者通信出现超载，或者使用破坏缓存有效性的模式，这些都可以导致相当严重的问题

5. 黄金标准

5.1. gold standard

5.2. 如果CIA是安全系统的目标，那么黄金标准描述的就是达到这个目标的方式

5.3. Aurum是黄金的意思，因此黄金的化学符号就是Au

5.4. 主体是指一切通过了可靠认证的实体，包括一个人、一家企业或单位、一个政府实体，以及一个应用、服务、设备或者其他有权执行操作的对象

5.5. 认证(authentication)

5.5.1. 用高度可靠的方式来判断主体的身份
5.5.2. 认证的过程，是指通过可靠的方式来建立主体证书可靠性的过程

5.6. 授权(authorization)

5.6.1. 仅允许通过认证的主体执行操作
5.6.2. 认证后的主体在执行数据访问时，也会受到授权结果的限制
- 5.6.2.1. 授权会根据预先设定的规则允许或拒绝用户的行为
5.6.3. 真正兑现授权决策的唯一方法，是确保使用系统的主体都是正常通过认证的主体

5.7. 审计(auditing)

5.7.1. 为主体所执行的操作维护一份可靠的记录，以便进行监控
5.7.2. 如果一项服务保留了一个安全日志，而这个日志可以准确地记录主体执行的操作（包括那些因为授权失败而没有成功执行的操作），那么接下来管理员可以执行审计来对系统的操作进行监控，确保所有操作都是合理的
5.7.3. 如果希望实现强大的安全性，准确的审计日志至关重要，因为它们提供了对真实事件的可靠记录
5.7.4. 详细的日志可以为我们提供一份历史记录，揭示发生异常情况或者可疑事件时的准确情况
5.7.5. 审计则负责提供可靠的日志，记录谁、何时执行了什么操作，再由技术人员定期审查违规行为，并保留追究违规者责任的权利

5.8. 黄金标准充当的是一种实现机制，旨在对CIA提供保护

5.9. 安全设计方案应该明确地把认证和授权这两者分开，因为把认证和授权结合在一起往往会导致混乱

5.9.1. 如果能够把两者明确地分开，审计追踪工作也会变得更加清晰

6. 认证

6.1. 认证的目的是，根据能够证明主体真实身份的证书，测试该主体的真实身份与其所声称的身份是否一致

6.2. 认证服务也可能会使用一种更强形式的证书，譬如数字签名或者挑战码

6.3. 数字签名是一种更加理想的认证形式，因为数字签名可以让主体在不泄露密码的情况下证明自己掌握密钥

6.4. 证书提供的认证信息

6.4.1. 所知之事(something you know)：如密码
6.4.2. 所有之物(something you have)：如安全令牌
6.4.3. 自身属性(something you are)：即生物特征（如指纹、虹膜等）
6.4.4. 所处之地(somewhere you are)：经过验证的所在地，如与安全场所中私有网络建立的连接

6.5. 你的所知之事可能泄露，你的所有之物可能失窃，你的所处之地有很多方法可以加以操纵，就连你的自身属性都有可能被伪造（甚至如果遭到盗用，我们连修改都很困难）

6.6. 用户使用两项认证要素总比使用一项认证要素要好

6.7. 只要条件允许，我们就应该依靠现成、可靠的认证服务，而不应该动辄“自力更生”

6.8. 认证的过程应该包括对证书进行校验，并给出认证通过或者认证失败的响应消息

6.8.1. 不要采用认证“部分成功”的做法，这样等于在暗示黑客可通过不断试错来破解密码
6.8.2. 如果希望降低暴力破解密码的风险，常见的做法是让认证密码从根本上很难通过计算破解，或者在认证流程中引入一些延迟
6.8.3. 一般来说，认证模块会给主体颁发一个令牌，主体在认证中使用令牌即可，这样就可以避免后续被要求执行完整的认证过程

6.9. 安全绑定认证实体后可以用两种基本方式进行入侵

6.9.1. 攻击者可以盗用受害者的身份
6.9.2. 接受认证的主体也有可能与其他人相勾结，把自己的身份信息泄露给别人，甚至把自己的身份强加给别人
- 6.9.2.1. 几个人分享同一个付费订阅的节目就属于这种入侵方式

7. 授权

7.1. 各类系统会通过业务逻辑、访问控制列表或者其他正式的访问策略来实现授权功能

7.2. 匿名授权（即不进行认证的授权）适用的场合可以说寥寥无几

7.2.1. 根据时间设置访问限制（比如，仅允许员工在工作时间访问数据库）也是匿名授权的一个示例

7.3. 应该通过一项单一的要素来实施授权，不要让授权代码散布在整个代码库中，否则这会是运维和审计人员的一场噩梦

7.3.1. 应该依靠某一项公共框架来唯一地提供访问授权

7.4. 授权机制远比传统操作系统提供的简单读/写访问控制要细致得多

7.4.1. 人们可以设计更加强大的授权机制，以便在不损失重要功能的前提下对访问进行限制，提升安全性
7.4.2. 基于属性的访问控制(Attribute-based Access Control，ABAC)
7.4.3. 基于策略的访问控制(Policy-based Access Control，PBAC)
7.4.4. 基于角色的访问控制(Role-based Access Control，RBAC)可以在认证和授权之间建立起一座桥梁
- 7.4.4.1. RBAC会根据分配给认证主体的角色(role)来提供访问授权，这样就可以通过统一的框架简化访问控制
- 7.4.4.2. RBAC并不会为每个人单独定义访问权限，而会根据每个人的职责指定一个或者多个角色，从而为人们自动分配相关联的唯一权限
- 7.4.4.3. 在更高级的RBAC模型中，一个人可以拥有多个角色，人们可以为不同的访问主动选择使用不同的角色