读数据安全架构设计与实践08安全技术体系架构(上)

1. 安全技术体系架构

1.1. 基础的网络架构、DNS、资产及配置管理数据库（CMDB）等，构成了通用的基础设施

1.2. SSO（Single Sign On，单点登录系统）​、KMS（Key Management Service，密钥管理系统）​、权限管理系统、统一日志平台、数据服务等，构成了安全组件与支持系统

1.3. 抗DDoS、HIDS（Host-based Intrusion Detection System，基于主机的入侵检测系统）​、WAF及CC防御等，构成了安全防御基础设施

1.4. 跳板机、自动化运维平台、数据传输系统等，构成了安全运维基础设施

2. 建设性思维

2.1. 安全体系建设没有捷径，需要从最基础的地方开始建设，做好基本功，步步为营，层层设防

2.2. 跟企业的业务特点、文化风格、安全目标都有关系

• 2.2.1. 有些企业是安慰式防御体系建设（没有专业的安全人员，花钱买各种设备，部署后基本就不管了）​、以救火为主的防御性建设（缺乏安全管理和安全技术体系，也没有体系化建设的想法，等出了问题再去解决问题）​

2.3. 以检测为主的防御性建设

• 2.3.1. 产品开发与发布过程基本没有流程控制或只有很弱的流程控制，默许产品带着风险发布，安全体系主要采用“检测-响应-恢复”模型，建设各类入侵检测系统，要求出问题时能够及时发现，检测系统告警时触发应急响应，安全团队和业务团队一起恢复业务

2.4. 以预防为主的安全生命周期建设

• 2.4.1. 主要采用SDL（安全开发生命周期）方法论，将安全要素与检查点嵌入产品的项目管理流程中，将风险控制在发布前，产品不允许带着风险发布

3. 安全产品和技术的演化

3.1. 安全产品是将安全架构理念变成安全实践的成果

3.2. 老三样

• 3.2.1. 防病毒：主机层的资产保护

• 3.2.2. 主机入侵检测：也对应主机层的资产保

• 3.2.3. 防火墙：对应网络层的访问控制

3.3. 网络层延伸

• 3.3.1. 发展出网络接入认证、NAC（网络准入控制）等产品或解决方案

• 3.3.2. 威胁通过网络进入，数据通过网络泄露

• 3.3.2.1. 对流量进行审计和数据挖掘，可帮助我们主动发现风险和安全事件

• 3.3.3. 商业竞争与利益的冲突，让一部分人不择手段，通过DDoS等攻击方式打压竞争对手，也让网络成为商业竞争的战场

• 3.3.3.1. DDoS与抗DDoS，此消彼长

3.4. 主机层延伸

• 3.4.1. 随着业务量的迅猛增长，自动化运维、大数据传输，成为安全运维新需求

• 3.4.2. 黑客频繁进入企业内网，HIDS（基于主机的入侵检测系统）走上舞台

3.5. 应用层延伸

• 3.5.1. 过去“以网络为中心”​，使用防火墙针对应用执行访问控制，让很多业务忽视了身份认证、授权、资产保护等要素

• 3.5.2. 统一接入网关的引入，并与SSO、授权管理等系统联动，可以让业务聚焦在业务本身，不用过多关注安全即可解决部分安全问题

• 3.5.3. WAF与接入网关集成，可以让保护范围覆盖到全部对外开放的业务，拦截SQL注入、XSS、上传WebShell等黑客攻击

• 3.5.4. 有了统一的接入网关之后，HTTPS流量也能正常解密，可以建立基于大数据的流量分析系统（离线的流量分析或实时的流量分析）​，用于数据建模、入侵行为告警等

• 3.5.5. KMS（密钥管理系统）的引入，可以让加密更加安全，即使黑客拿到业务的代码和数据，都无法解密

3.6. 安全新技术

• 3.6.1. 人工智能

• 3.6.1.1. 人工智能（AI）可以用来学习、完善安全防护规则，或执行辅助防御

• 3.6.1.2. 生物识别方面的人工智能技术可用于身份认证领域，如人脸识别

• 3.6.1.3. 人工智能技术还可以用于完善风控系统，例如当检测到某个访问请求来自黑产团伙时，就可以拒绝其访问（应用层访问控制）​

• 3.6.2. 大数据

• 3.6.2.1. 大数据不仅可以用于事件挖掘与审计，还可以用于为黑产、诈骗、僵尸网络、傀儡肉鸡、盗版源建立数据库，作为风控系统的决策依据，用于访问控制

• 3.6.2.2. 建立物联网终端IP库，如果正常情况下这些IP不应该访问业务，在防御系统中就可以直接阻断掉，因为访问过来的流量实际上是被黑产控制的

• 3.6.3. 云计算

• 3.6.3.1. Overlay（虚拟网，云上虚拟机所在的网络环境）和Underlay（底层承载网络）的隔离、租户隔离、安全域、云上防御，以及它们与传统数据中心的路由与访问控制关系（如何隔离或如何访问）等

• 3.6.3.2. 有安全产品利用云计算技术构建安全能力

4. 一个维度

4.1. 身份认证（Authentication）

4.2. 授权（Authorization）

4.3. 访问控制（Acccess Control）

4.4. 可审计（Auditable）

4.5. 资产保护（Asset Protection）

5. 二维模型

5.1. 安全技术体系架构就是安全技术体系的主要组成部分及组成部分之间的关系

5.2. 各种基础设施与安全产品，包括安全防御基础设施、安全工具和技术、安全组件与支持系统等，共同构建了安全技术体系

5.3. 增加一个维度（网络分层）

• 5.3.1. 应用和数据层

• 5.3.2. 设备和主机层

• 5.3.3. 网络和通信层

• 5.3.4. 物理和环境层

5.4. 如果维度超过2个，则架构模型看起来将异常复杂（实际上也超过2个了，还有如数据生命周期、产品生命周期等等）​，更多维度难以表达也不容易理解

5.5. 横向为安全架构的5个核心元素，纵向为网络分层

5.6. 跟安全有关的基础设施，包括IT通用基础设施（如基础网络）​、安全防御基础设施（抗DDoS、HIDS、WAF等）​、安全运维基础设施等

5.7. 安全工具和技术，包括为发现风险而采用的扫描、检测工具，或安全改进所需要的各种技术（加密、脱敏、HTTPS等）​

5.8. 安全组件与支持系统，如SSO、KMS、运维平台、第三方日志系统等

6. 风险管理的三道防线

6.1. 第一道防线

• 6.1.1. 业务部门对风险负主要责任，需要考虑从源头控制风险

• 6.1.2. 业务主管是业务风险的第一责任人，出了事件之后，首先应该问责的就是业务主管

6.2. 第二道防线

• 6.2.1. 风险管理部门作为专业能力中心，提供整体的风险控制方案

• 6.2.2. 针对各领域风险的风险管理部门

• 6.2.3. 需要该风险领域内的专业知识，以及从事该专业领域的人员

• 6.2.4. 建立和完善数据安全政策文件体系

• 6.2.4.1. 制定其所在领域内的政策总纲、管理规定、标准、规范，供各业务遵循，提供专业性风险评估与指导，并对各业务的风险现状进行度量和监督，整体把控风险

• 6.2.5. 管理内外安全合规、认证测评、渗透测试

• 6.2.6. 协助建立/完善通用的基础设施，包括但不限于：较少的网络安全域划分与简洁的访问控制策略（借鉴无边界网络理念）​、CMDB、统一接入网关等

• 6.2.7. 建立并完善安全相关的安全防御基础设施（抗DDoS/HIDS/WAF等）​、安全运维基础设施（跳板机/运维平台/数据传输平台等）​、安全支撑系统（SSO/日志/应用网关）​、风险识别工具（如扫描器）​、运营工具（风险度量等）​

• 6.2.8. 建立并完善安全组件与支持系统，包括但不限于：SSO、权限管理、KMS、日志系统等

• 6.2.9. 完善各种安全工具和技术，包括但不限于：扫描、大数据分析（网关可作为流量输入）等

• 6.2.10. 考虑建设数据中台，将数据作为生产力，并统一执行安全管理

• 6.2.11. 例行开展扫描、检测活动，为风险数据化运营提供数据，执行风险规避措施

• 6.2.12. 风险管理、事件管理与应急响应

6.3. 第三道防线

• 6.3.1. 独立的审计

• 6.3.2. 承担审计职责的部门（如审计部）​，以及外部审计机构、测评机构等

• 6.3.3. 审计的工作是独立的，不受第一道防线、第二道防线所在的部门制约，会独立履行职责，识别第一道防线、第二道防线中包括战略、管理政策、流程、人员、技术等各领域的风险

• 6.3.4. 不仅包括业务自身的风险，对管理文件、技术规范、控制措施覆盖不到位的地方，也会提出改进意见，促进安全风险防控体系的不断完善

• 6.3.5. 识别的风险包括各领域的风险，安全风险、隐私合规风险只是其中的一部分

• 6.3.6. 审计报告作为第一道防线、第二道防线执行风险改进的输入

• 6.3.7. 业务部门（第一道防线）主动预防风险，各风险管理部门（第二道防线）从外部加以指导，并采取流程控制、风险评估、监督、度量等活动，帮助业务降低风险

• 6.3.8. 审计部门充分暴露问题，向风险管理委员会（或董事会）汇报，对第一道防线、第二道防线进行纠偏

6.4. 自身安全，不惧怕环境不安全

6.5. 环境安全，让其可以信赖，自身可以适度放松

6.6. 保障业务应用的安全也是这样，适当的分工协作，将一部分安全在产品自身完成，一部分安全交给基础设施完成