0x00 前言
本来准备新开几篇再介绍下安全架构，恰逢前几个月也看了一些框架。所以决定还是先总结一下，等待日后空了再针对不同层面各写几篇。本篇受限于个人经验，篇幅之间难免有些片面，读者仍需多多思考。看图说话吧↓
0x01 从企业架构谈起
我准备先从企业架构谈起，了解企业虽然不是做安全的开始，但却决定了做到什么程度。
- TOGAF提供了一套从商业架构到IT架构的通用方法论。ITIL提供了对信息技术基础架构的落地指导，ITSM则是用于指导IT的服务管理框架。
- TOGAF中提供了BDAT的四层架构，在这里我把T作为Infrastructure层。
- 对于一些产品在IAAS和PAAS中的定义其实是相对的，例如DB可以是PAAS的部分，也可以是SAAS的，当然对于金融企业来说，一般要求是On-Prem的。另外除去合规，私有云也可以搭建在公有云基础设施。这里的IAAS，PAAS，公私有均是以其业务性质定义的。
- 交付服务需要注重Customer Centricity（可信的、可持续的、更快的、交付服务，维护Customer之间的关系酌情考虑），在企业安全工作中曾经也应该借鉴这种思路，无论是内外部业务都应该有一个持续交付业务的态度。
- 在IAAS到SAAS的过程中，CSP能够提供的功能越来越多，我们自己管理的越来越少。但IAAS中并不仅仅涉及到基础安全，也应该要求数据安全针对HW/SW，存储、数据库的等日常中的一些场景进行定制化防御。
- GRC往往是产品再外部面临到第一层问题，也是驱动内部IT架构做出改变的动力。
- 在业务架构中，策略，运营，技术缺一不可。
- 所谓架构，就是一些符合种种规则的框架，然后对新的业务提供约束。业务可以是对外的，也可以是对内的。对于安全部门，直接的业务客户就是企业内部的其他部门。
0x02 再看安全架构
- 驱动企业针对安全作出改变的有以下几个方面： 合规，公共安全，商誉，金融安全。对于企业来说，业务直接面临的就是来自监管合规方面的压力，以及内部的风险管理的压力。从业务驱动着IT作出变化，从而影响业务也发生改变。在政策和合规上，显而易见的决定了业务形态。
- 此处将IT架构中的安全治理简单分为三层，分别是基础安全，应用安全，数据安全。但同时需要注意办公网的业务系统不一定部署在Office，DC内部也不一定仅是生产(site)业务,在远程办公的情况下，可能还会不部署办公网（Corp）业务。
- CIS在Infrastructure层面提供了最为精准的Control Set。 ISMS是ISO27001中的一部分提供了信息安全管理的指导框架。
- 类似日志和监控这种基础运维层面的东西，还真不一定是安全团队在leader，当然也不仅限于基础安全，应用也需要记录日志并做监控，这是通用的需求。类似的还有审计，账户管理，认证集成。
- 从纵向看一个应用的落地过程，业务拆分进行拆分，可以从处理顺序做，也可以从业务类型去做应用设计。设计完成后的应用，采用某种系统架构，此处指的是具体采用的具体组件，例如Nginx，Tomcat，lvs，网关等等，此后根据系统架构，申请对应的VM直接部署到对应的数据中心里去。当然云化后的部署方式又会流畅不少。
- 系统架构中的一些TAL，CAL，CAS，DAL在大部分企业里应该是不具备的…..
- 安全运营，安全管理，安全技术是做安全的三个方面，我们需要能够提供相应的策略，标准，以及指南，标准操作流程给到外部。在这个过程中，应该能够实现一定的自动化。尤其是在运营过程。
这里提供了TOGAF中针对架构处理的一个指南，具体可以参考TOGAF的框架详情。
- 确定范围，明确目标。经过一系列的输入和步骤得到相应的输出。
- 评估需要的资源或者资源池。我们的目标是交付一个服务出去，这个服务也可以是产品，可以是实物。评估完所需，通过不同的方式完成目标，可以是商业采购，可以是内部消化，可以是外包研发，也可以是让厂商去做等等。
- 明确利益相关者（Stakeholder），接口人（Point of Contact），发展路径（Roadmap）
- 确定好日常沟通的计划，做好项目管理，在Scrum会议里快速迭代。
- 设计架构需要确定高可用，可扩展，容量评估(Capability Assessment)等方面的工作。
- 在做不同层次的事情时需要考虑的架构是不一样的，例如基础安全中的WAF和堡垒机，主要关注在物理架构和系统架构层面进行设计和部署。如果是KMS、CA这种则需要考虑的是应用架构和系统架构，然后对应到Zone和VM以及各种基础设施，例如LB，DB等。 以上还是局限在安全部门提供的服务中，如果是在SDLC中针对PD团队提供的架构设计进行系统间的依赖分析之类，此时关注的又有些不同。
0x03 协作与组织架构
并不全，之前在本地生活和阿里集团安全之间的经历以及目前在China 和Global之间的交互不尽相同。
- 左图一般是企业中常见的对安全职能部门的划分，当具备集团概念的时候，安全职能部门就进化的相对完整一些。
- 在CRO线，CTO线，和CSO线绝对是有所不同的。
- 技术中心内的部门间协作，以及一级部门之间的工作协调是不是需要统一的收口？例如通过Devops采集来自技术中心内外的需求。
- KPI设定去约束人，OKR约束个人对项目的目标。Scrum管理这个项目的快速迭代。
- 找到利益相关者，然后往对应的资源池请求资源，消费资源。缺PMO要PMO，缺研发要研发，厂商做，外包做，自己做等等
- 找到项目接口人，统一调度相关的资源，追踪项目的进度。
- 领导/经理应具有leadership，真正的能激励和鼓舞团队，而不是PUA。同时做好向上管理，要不然下面累的不行，做出来的东西没被认可就尴尬了。
- 领导的视角其实有效，应该能够做到Support下面做出成果。可量化的成果对于大家都是有益的，企业中多方协作往往能达成共赢的局面，但大家遇到更多的情况是撕逼甩锅抢功劳。
- 态度永远是第一位的，技术其次，但是技术视野和深度才能决定能做成什么样。责人之心责己，但也要远离傻逼。
- 金融安全相关的三道防线要求，其实并不是很容易体现在组织架构中，而是有种类似贯穿了不同部门的虚拟防线概念
- 大型的企业都会去做自己的安全研究，把安全技术落地的前提下进行产品研发，然后内部推广，在不是造轮子的前提下形成Core Product
- 不同企业性质不一样，导致其安全需求建设也是不一样的。来自企业内外部的不同压力驱动着一件事情。
- 屁股决定脑袋，做好自己的份内工作。终身学习是自己的事情，跟企业关系不大，能借光也行，借不到也无所谓。
- 语言和沟通其实是个很重要的软实力，选择好自己的技能点，培养自己的技能树吧，别长歪了。
0x04 总结
在企业/企业安全演进过程中，我们发现问题，提出了解决方案，又会遇到新的问题提出新的解决方案。但最重要的是我们要拥有对未知或者未接触的领域能够快速学习并发现问题以及提出解决方案的能力。企业安全中搞管理也好，搞安全技术也好，安全运营也罢，都是一场耐力赛。☯️
本篇又是2月而成，另本站所有文章均系原创，如若转载需经过本人授权同意