读数据安全架构设计与实践02安全架构基础(下)

1. 架构

1.1. 架构是一种在方案设计、系统实现、产品部署、安全改进等项目活动中所必需的思维模式、通用语言和沟通桥梁

1.2. 架构所要提供的正是类似于“图纸”这样一种东西

1.3. 架构是系统中所有元素以及元素间关系的集合

1.4. 架构由元素和关系组成

• 1.4.1. 架构就是系统中包含了哪些元素，这些元素之间的关系是什么样的

• 1.4.2. 元素往往也称为组件或逻辑模块

  • 1.4.2.1. “组件”的时候，表示这是一个独立存在的元素，是一个基本的功能单元

  • 1.4.2.2. 逻辑模块，表示一个抽象的逻辑单元，往往并不独立存在，而是依附、融入或横跨在多个组件上

1.5. 概念架构​

• 1.5.1. Conceptual Architecture

• 1.5.2. 在产品的早期，或者需要向上汇报的时候，通常会使用概念架构，以尽可能简化、抽象的方式，传达产品的概念或理念

• 1.5.3. 概念架构仅涉及基本的定义（组件和组件之间的关系）​，不涉及接口细节等内容

1.6. 逻辑架构

• 1.6.1. 在产品需求逐步明确后，通常会用到逻辑架构，体现出业务逻辑模块及之间的关系

1.7. 物理架构

• 1.7.1. 在产品发布或部署时，需要用到物理架构，体现具体的组件及部署位置

1.8. 架构关注的问题

• 1.8.1. 是否提供预期的功能

  • 1.8.1.1. 对于产品功能，需要对功能模块、组件进行分割与组装，且保障模块及组件之间的高内聚低耦合

• 1.8.2. 质量是否过关，且没有副作用

  • 1.8.2.1. 性能（在预期的用户量/并发数条件下，产品功能能否满足用户正常使用的需要）​

  • 1.8.2.2. 安全性（防止黑客攻击、入侵，导致服务器不可用、数据被篡改、数据泄露等安全事件，以及确保安全相关的法律合规）​

  • 1.8.2.3. 扩展性（在用户规模大幅增长时，能否通过扩容解决问题）​

  • 1.8.2.4. 可维护性（日常运维是否尽可能自动化，降低运维人员投入，如软件更新、数据更新、日志清理、证书/License到期提醒等）​

2. 安全架构

2.1. 安全是产品的质量属性，安全的目标是保障产品里信息资产的保密性（Confidentiality）​、完整性（Integrity）和可用性（Availability）​，简记为CIA

2.2. 安全架构是架构在安全性这个方向上的细分领域

• 2.2.1. 安全架构是架构在安全性这个方向上的细分领域，其他的细分领域如运维架构、数据库架构等

2.3. 安全架构师的职责就是对该产品的安全性进行评估

2.4. 保密性

• 2.4.1. 保密性：保障信息资产不被未授权的用户访问或泄露

• 2.4.2. The Thing

  • 2.4.2.1. 1945年苏联送给美国大使馆的一枚精制美国国徽名为“The Thing”​（被译为“金唇”​）​，里面就藏着一个窃听器，被悬挂在大使馆长达8年之久，让苏联获知大量美国情报

  • 2.4.2.2. “The Thing”窃听器之所以没有被美国特工检测出来，是因为使用了一种当时非常先进的被动式调谐的无线电技术，窃听器本身不需要电源，不发射电磁波，只接受外面定向发射过来的电磁波，并在调谐后反射回去

  • 2.4.2.3. 就超出当时美国特工的知识范围了，美国的反窃听设备没有检测到任何无线电信号，于是这枚国徽顺利地通过了检测

• 2.4.3. 海底光缆窃听

• 2.4.4. 使用嗅探工具（sniffer）嗅探网络流量

• 2.4.5. 射频辐射

• 2.4.6. 黑客攻击导致的数据泄露

2.5. 完整性

• 2.5.1. 完整性：保障信息资产不会未经授权而被篡改

• 2.5.2. 主机感染病毒或木马

• 2.5.3. 操作系统内核文件被替换

• 2.5.4. 网站被入侵后，内容被篡改

• 2.5.5. 网络劫持篡改

  • 2.5.5.1. HTTP网页中加塞的广告

• 2.5.6. 应用层越权操作

• 2.5.7. 文件下载被替换

2.6. 可用性

• 2.6.1. 可用性：保障已授权用户合法访问信息资产的权利

• 2.6.2. DDoS或CC攻击，导致网络拥塞、主机资源耗尽，从而网站无法打开

• 2.6.3. 冲区溢出导致服务异常中止

2.7. 可追溯性

• 2.7.1. 可审计性

• 2.7.2. 在发生影响数据保密性、完整性、可用性的安全事件之后，可基于记录的日志追踪溯源，复盘事件发生的全过程，找到导致事件发生的根本原因，加以改进

• 2.7.3. 追溯也不是最终的目的，通过追溯与改进，最终的目的还是保障数据的保密性、完整性、可用性

2.8. 产品安全架构

• 2.8.1. 构建产品安全质量属性的主要组成部分以及它们之间的关系

• 2.8.2. 产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品，构建*第一道防线

2.9. 安全技术体系架构

• 2.9.1. 构建安全技术体系的主要组成部分以及它们之间的关系

• 2.9.2. 安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各产品的安全防御能力，构建*第二道防线

2.10. 审计架构

• 2.10.1. 独立的审计部门或其所能提供的风险发现能力，但审计的范围是包括安全风险在内的所有风险，构建*第三道防线

2.11. 安全架构从应用层扩展到空间立体，覆盖物理和环境层、网络和通信层、设备和主机层、应用和数据层

3. 安全架构5A方法论

3.1. 身份认证

• 3.1.1. Authentication

• 3.1.2. 用户主体是谁？

  • 3.1.2.1. 主体的范围不局限于用户，将其扩展到所有人员（用户/员工/合作伙伴/访客等）​、设备、系统

3.2. 授权

• 3.2.1. Authorization

• 3.2.2. 授予某些用户主体允许或拒绝访问客体的权限

3.3. 访问控制

• 3.3.1. Access Control

• 3.3.2. 控制措施以及是否放行的执行者

  • 3.3.2.1. 访问控制的依据是授权，查询授权表或者基于设定的权限规则，拥有访问权限才允许继续访问

• 3.3.3. 用户首先需要通过身份认证，也就是要让系统知道用户是谁

• 3.3.4. 用户需要具备访问目标资产的权限

• 3.3.5. 访问控制模块会基于授权以及事先设定的访问控制规则，判断是否放行

• 3.3.6. 在访问资产之前，须经过必要的资产保护措施，如数据解密、加密传输、脱敏展示、防攻击以及防批量拉取措施、隐私保护等

3.4. 可审计

• 3.4.1. Auditable

• 3.4.2. 形成可供追溯的操作日志

  • 3.4.2.1. 指可供追溯的操作审计记录（操作日志记录等）​，没有直接体现在上述主线中，但会覆盖到每一个模块

• 3.4.3. 身份认证方面：SSO系统需要记录用户的登录时间、源IP地址、用户ID、访问的目标应用

• 3.4.4. 授权方面：需要记录权限申请流程的每个审批环节的时间、IP地址、用户ID、理由、通过或驳回权限申请的动作

• 3.4.5. 访问控制方面：访问控制执行的结果是放行或驳回，通常来说，需要记录所有的驳回动作，以及对敏感资产的每一个请求及动作，便于追溯

• 3.4.6. 资产保护方面：记录用户访问的资产（特别是敏感资产）及操作（查询、添加、修改、删除等）​

3.5. 资产保护

• 3.5.1. Asset Protection

• 3.5.2. 资产的保密性、完整性、可用性保障

• 3.5.3. 数据：即信息资产，包括结构化数据（数据库、缓存、Key-Value存储系统等）​、非结构化数据（文档、图片、音频、视频等）​，不仅包括存储的数据，也包括使用、传输、流转中的数据

• 3.5.4. 资源：网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等

  • 3.5.4.1. DDoS攻击会占满网络带宽资源或主机计算资源，导致业务不可用

  • 3.5.4.2. 病毒、木马会造成主机计算资源破坏或权限被外部控制，或造成攻击范围扩大，数据泄露等严重后果

3.6. CIA是安全的目标，自然也是安全架构要达成的目标

• 3.6.1. 身份认证、授权、访问控制、审计、资产保护均是为了达成这个目标而采取的技术手段

• 3.6.2. CIA是目标，安全架构5A是手段

• 3.6.3. 安全架构5A只是为了达成CIA而采取的技术性手段，并不能完全保证达到CIA这个目标