🕶️
安全架构要参:构建企业适用的安全架构
  • 声明
  • 序言
  • 第一部分:闲话安全工作
    • 1. 一些基本观点
    • 2. 认识业务
    • 3. 认识组织架构
    • 4. 阴与阳
  • 第二部分:浅谈安全架构
    • 5. 认识架构
    • 6. 认识企业安全
    • 7. 安全架构基础
    • 8. 解决方案
  • 第三部分:具体实施内容
    • 9. 持续服务
    • 10. 成为安全架构师
  • 附录A: 推荐阅读
  • 附录B: 案例
由 GitBook 提供支持
在本页
  • 定义
  • 安全治理
  • 安全框架
  • 行业标准与最佳实践
  • 上云与云上

这有帮助吗?

  1. 第二部分:浅谈安全架构

6. 认识企业安全

不谋万世者,不足谋一时;不谋全局者,不足谋一域。[1]

本章先简单介绍安全及威胁的特性,其后针对安全治理进行介绍。包含治理范围,设计原则以及技术范畴、合规范畴、管理范畴、运营范畴等相关领域。通过安全治理为企业架构增加安全性,从而构建安全,可靠,高性能并满足成本控制的架构系统。

定义

在各方面不同方式[2]为企业架构提供安全特性并通过各种机制确保流程[3]正常。

安全特性

  • 机密性(Confidentiality):确保数据在传输和存储时的机密性,避免未经授权的用户有意或无意地泄露数据。

  • 完整性(Integrity)):确保数据在传输或存储的生命周期内,始终保持正确性和一致性。

  • 可用性(Availability):确保用户在需要通过信息系统进行操作时,数据和服务必须保持可用并满足需求。

除CIA之外还有3A[4], 认证——识别信息用户的身份,并记录访问和使用信息;授权——根据实际需求给予实体授予适当的权限,一般采用最小权限;计帐——记录用户与系统间的交互数据。

威胁分类

  • 欺骗

  • 篡改

  • 否认

  • 信息暴露

  • 拒绝服务

  • 提升权限

安全治理

在不同领域通过技术、运营、管理的方式确保使企业架构具有安全特性[5]。

治理领域(Scope[6])

主要包含以下几点,另建议参考AWS,Azure等云厂商关注方向[7]。

  • 合规(Compliance)

  • 数据保护(Data Protection)

  • 基础设施(Infrastructure[8])

  • 身份认证和访问管理(IAM)

  • 应用和服务[9](Application and Service)

驱动力[10]

基于事件的驱动往往意味着风险已经成为现实

1. 监管驱动

执法必严,违法必究;

2. 事件驱动[11]

吃一堑,长一智;

3. 价值驱动[12]

未雨绸缪,上策;

安全设计原则

  • 适应业务目标[13]

  • 为攻击者设计

  • 最低容忍[14]

  • 最小化攻击面 [15]

  • 强身份认证与权限管理

  • 弹性设计[16]

  • 安全左移[17]

  • 纵深防御[18]

  • 默认安全

  • 安全内生[19]

  • 让系统容易使用以及自动化[20]

  • 平衡投资[21]

合规范畴[22]

法务部门对接相关行政机关,转交给到对应合规部门[23],随之根据行政法规,判断是否需要作出相应的调整去满足合规需求。例如是采购具备资质的乙方厂商的安全产品,或者使用指定的加密算法等。从分类上讲一般可划分为地域性的和行业性的:

1. 地域性合规

  • 国际合规

  • 本地化合规[24]

  • 区域合规[25]

2. 行业性合规[26]

金融,医疗,保险,汽车等不同行业面临的行业合规标准也是不尽相同的。

技术范畴

技术是解决问题的第一生产力[27]

  • 入侵检测和防御(Intrusion Detection and Protection):例如入侵检测、文件完整性保护、威胁情报、态势感知等,以及对流量进行清洗(包含四层及七层流量清洗[28])等;

  • 集中化的日志管理(Centralized Log Collection):例如Splunk、ELK等;

  • 统一身份认证及权限管理(Identity and Access Management):例如AD、SSO、MFA、FIDO等;

  • 持续扫描及监控(Continuous Scanning and Monitoring):例如针对文件、网络、主机、存储、应用、代码等资产[29]进行持续性的扫描及监控;

  • 根信任(Root of Trust):例如根密钥,随机数生成器,硬件加密模块,金杯体系;

  • 公钥基础设施(Public-Key Infrastructure)

  • 数据防泄漏(Data Leak Protection):例如针对邮件、流量、文档;

  • 安全开发套件(Security SDK):例如加密套件、过滤器等;

  • 运行时防护(Runtime Protection):例如容器层级、应用层级;

  • 创新技术的探索性应用:例如Web3.0、AI、Blockchain、创新沙盒等;

运营范畴[30]

持续性维护及优化需要实现的安全目标

在持续的运营过程中交付安全能力并发现新的问题,以下尝试通过一种非技术的角度[31]来介绍部分运营内容。

1.生命周期管理

包含对实体的申请、创建、分发、更新、轮换、吊销、删除等操作

  • 证书

  • 密钥

  • 数据

  • 漏洞

  • 补丁

  • 账户

  • 权限

  • 许可证

  • 敏感信件(代表着纸媒所载的敏感信息)[32]

2.值守

7x24遵循SOP的监控与响应

  • 监控

  • 检测

  • 告警

  • 应急响应

3.演练

日常熟练紧急事件下的处置流程

  • 攻防对抗

  • 灾难演练

4.日常[33]

日常工作自动化

以下按照能自动或自助与否进行划分,简单列出部分工作内容:

  • 同类产品部署

  • 主机/应用/网络扫描等

  • 规则提取以及数据检测

  • 自助服务[34]

  • 培训

  • 咨询[35]

  • 技术支持

  • 系统管理及维护

  • 编写一些制度,策略,SOP

管理范畴

资源需要得到合理的安排[36]

  • 策略管理[37]

  • 风险管理

  • 生态运营[38]

  • 项目管理

  • 成本管理

  • 文档管理[39]

  • 资产管理[40]

  • 流程管理[41]

安全框架

SABSA[42]

SABSA框架是基于风险和业务驱动,具体内容依赖标准化组织。[43]

O-ESA

O-ESA框架由OpenGroup维护,概述了企业安全体系结构的基本概念。

NIST CyberSecurity Framework

MLPS(等级保护[45])

国内用于系统防御能力级别的合规检测框架

行业标准与最佳实践

行业标准提供了一种概念性的规范,企业依照自身实际情况实施形成最佳实践。设计企业安全架构时应当持续关注行业内最佳实践,一般像AWS、Azure、Google、阿里等都会定期发布或者更新相关白皮书。例如AWS Well-Architected Framework[47]:

以及Microsoft Cybersecurity Reference Architectures[48]:

上云与云上

讨论云

上云[49]必然是趋势,对于一些行业却因为合规原因无法使用。CSP[50]固然能够提供基础设施层面的默认安全,但对于应用、服务、权限以及数据层面的威胁仍需要时刻关注平台安全。期待密码学的发展能够为租户带来更高的数据安全体验。

讨论云原生[51]

云上将快速敏捷的持续交付作为云原生的目标,其中所涉及的流程及基础设施整体如果同安全能力[52]不相匹配,只会导致暴露更多更被动的攻击面。


[1] 不乏许多企业并无任何安全意识,更别提谋一域安全,乃至全局安全。

[2] 包含不限于技术层面、流程层面、管理层面、运营层面等。

[3] 例如:数据流转,应用发布,业务上线等等

[4] Authentication,Authorization,Accounting。当然也有5A说法。

[5] 安保也算,虽然是是行政或者物业管。

[6] 从技术视角来看,即包含基础安全,应用安全,数据安全等领域。

[7] 注意区分和所在企业的基础设施差距。

[8] 存储、计算、网络等。

[9] 需主动关注对应的供应链安全。

[10] 责任共担模型

[11] 亡羊补牢,未为晚矣。

[12] 资产就是价值集合,包含不限于商誉、业务、数据、IT设施等。

[13] Information Security as the Enabler of Business.

[14] 具备基线Baseline以及基准Bechmark。

[15] 梳理已知资产使其符合最低容忍能够有效降低风险;例最小化权限。

[16] Resilience design.

[17] 远至供应链,近至研发流程。即便概念已经是二十余年前提出,但至今仍未实际大范围落地。

[18] 采用分层、分级的方式。例从逻辑架构到实际系统架构、从概念架构映射到具体场景、从High-Level Design到Low-Level都应该考虑到安全特性。

[19] 可译成英文Security by Origin。

[20] 低侵入性、低性能损耗、易于运营、易于持续维护等。

[21] 投资资源(预算、人力、)到不同领域(技术、合规、运营等)的生命周期管理中。

[22] 合规有时是企业生存下去的底线,例如P2P清退、虚拟货币交易所的清退、金融牌照的申请更新等,目前安全负责人已经需要承担企业信息安全事故引起的法律责任。

[23] 不一定隶属同一个安全条线。

[24] 企业业务所在国家。

[25] 地方性合规。例如中国《数据安全法》、《个人信息保护法》(PIPL),以及地方性的《上海市数据条例》、《深圳经济特区数据条例》、《贵州市大数据安全保障条例》等。

[26] 还可以划分为常规检查和临时检查。

[27] 安全技术承接管理团队、合规、研发等团队的需求并输出解决方案。

[28] 例如DDOS防护。

[29] The Resources of Vaule.

[30] 向自动化、精细化(场景化)、智能化的发展道阻且长。

[31] 这里并没有打算从生产网和办公网以及相关安全技术的角度进行介绍。

[32] 例如经由行政部门柜台办理所得用于下载证书及私钥的两码的纸质文件。

[33] daily basis.

[34] 一种portal或者本地化工具,例如证书申请、Make me admin、软件库等。

[35] 可以优化流程,将常见问题整理出咨询模板。

[36] 技术、运营、预算、人员管理等等

[37] 策略管理具有生命周期特性,之所以未放入运营范畴中,是因为策略更具管理性。

[38] 生态其实意味着背后的平台价值、平台利益。

[39] 包含具体的策略、制度、规范、指南、标准操作手册、事件处置流程等文档。类比Well-Architected应当做到Well-Documented.

[40] The resources of values. 需要识别出所有具备价值的资产以及存在的潜在风险。

[41] 流程的制定来自不同的部门,需要遵守常规流程并设置特殊流程。例如行政流程人员离职完成之后应当立即启动IT流程清理遗留权限,保留关键数据等。

[42] https://sabsacourses.com/wp-content/uploads/2021/02/TSI-R101-SABSA-Matrices-2018-Release-Notes.pdf

[43] https://www.secrss.com/articles/19750

[47] 关注行业最佳实践时不应仅止步于安全范围

[48] https://docs.microsoft.com/en-us/security/cybersecurity-reference-architecture/mcra

[49] 意味着采用云计算技术对底层资源实现弹性调度,但并不意味着使用CSP的服务,也可以是自建。

[50] Cloud Service Provider

[52] 目前有针对云原生提出安全切面的概念

上一页5. 认识架构下一页7. 安全架构基础

最后更新于3年前

这有帮助吗?

[44] 图片出自 第45页

[45]

[46]

[51]

http://www.diva-portal.org/smash/get/diva2:1031560/FULLTEXT02.pdf
http://www.gov.cn/gzdt/2007-07/24/content_694380.htm
https://pdf.dfcfw.com/pdf/H3_AP202107301506980769_1.pdf?1627652267000.pdf
https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition
图6-2【44】
图 6-3
图 6-4[46]
图 6-5
图 6-6