什么是安全架构《二》

前言

其实距离第一篇安全架构的文章 https://iami.xyz/Security-Architecture-Review/ 也有一段时间了。上一篇主要从安全架构师的主要职责浅显的谈了下所需的相关能力。不过认知总是随着经历不断的发生变化。今天就再浅显的从每一项具体内容去浅显的写一写什么是安全架构的第二篇——具体相关的解决方案。你也可以在以前一篇文章里看到过关于设计解决方案摸索到一套流程。不一定都适用，权做经验之谈。

新视角

一般来说，甲方企业的构成基本脱离不开这种模式（忽略图有点丑…）。人员划分在合规，技术，运营三块，领域主要关注在基础安全，应用安全和数据安全。当然根据组织架构的不同，团队构成也不甚相同。有的是按照技术视角去划分不同的团队，分出来基础安全团队，应用安全团队和数据安全团队。当然不可否认近几年开始把安全运维，可信计算等有关基础设施的全部划归到基础安全团队了。也有的是按照运营视角去做，这取决于企业内部安全建设的成熟度。但少有以合规视角去划分团队结构的，不过每每有合规性的工作却是需要涉及到整个安全的大团队。当然除此之外也有企业是直接以PDR这种时间线去划分，成立安全技术团队，安全检测团队和安全响应团队。

总的来说都是根据企业自身情况评估，对技术的需求，人员的预算来划分整个安全的组织架构。至于安全是挂在运维下，还是运维挂在安全下，都需要记住，安全和运维/研发都不是对立面，分工不同，互相协作罢了。至于矛盾纠纷，也当尽量不能阻碍业务发展，但基线策略（基线策略的制定如果已经有了，就按财年review/修订，如果没有就会同各大部门负责人协同初版，逐级报至技术委员会或者CTO/CSO审批）一般不容商量。

// 画这个图是因为安全技术领域也是有不少交叉的，尤其是甲方。同时也希望做技术的能以运营的视角想想对方在技术领域的工作，做运营的能够了解到技术人在不同领域的技术。另外无论是基础安全，应用安全还是数据安全，不同企业在不同领域的布局肯定也是不一样的，这就涉及到了怎么样去避免划分时的归属歧义，否则应用安全的人觉得他应该hold，但是基础安全的人又觉得你吃了我的蛋糕。同时数据安全心里还在想着我怎么插不进去。

解决方案

在《什么是安全架构：一》里面主要是讲了成为一个安全架构师的需要具备的知识并简单介绍了解决方案和架构评审两块，其实总的来说架构评审也是为了输出一定的解决方案。至于Deployment，Operation，Administration分给谁来做则是另外一回事了。

插个小故事。年前某个技术负责人说他对架构的定义是指在企业内部的三到五年内选用某种框架这才算作是架构，例如采用SOA，还是微服务。而像其他种种均不能算作架构。当然各人的理解不同，大小各异，不需要去争执。做应用安全架构的就不用考虑网络安全架构了吗？做数据安全架构的不结合网络安全和应用架构了吗？

安全合规

就我之前的接触来说，技术人往往不会把合规作为考虑的第一步。而且面对监管，似乎也有着许多方法可以搪塞而过（堡垒机不加电，防火墙不安装等）。但是对于业务来说，来自监管的压力能够短时间的削弱或者摧毁一家企业。某红书，某刻下架，某币交易所退出的背后也是因为触犯了监管的条例。同样针对数据中心的建立，合规也确实首当其冲。尤其是金融行业的信息安全，已经做成了一个生态，网联银联，CFCA, BCTC等等都有自己的立足之地。合规对于金融企业可以说是生死线，因此在这里算作First Line。但是由于我合规方面的经验并不是很丰富，所以浅显的说一下注意点。（不仅包括合规，还包括公司内部确保安全的相关策略类） 属于一个&关系。合规&合规才行，1-n里面的一个不合规都会导致“与”关系的失败。

• 需要申请相应的资质（ISP专线，网站备案，支付牌照，银行专线等等）
• 采购的产品是否具备相应的资质，比如FIPS认证，国密认证，ISO27K认证等等。
• 是否具备相应符合规章制度的策略或流程 （用户信息收集的范围和告知，日志的收集审计策略，VPN、堡垒机的高可用以及切换，灾备中心，数据分类分级有没有做到等等）
• 是否需要通过相关的资质认证：UPDSS， PCI-DSS等

另外就是安全审计其实也是合规的一部分，在不同的标准里都针对审计做出了要求，分角色分时间的去进行审计记录。让合规团队也能参与到一定的技术里面，不过这可能只是一个好的想法，实际落地有待考虑。

技术安全

这一块不仅包含技术，还应该包含技术运营。技术决定了防御质量，运营决定了用户体验。安全防御也需要看你怎么能够在HLD（High-Level Design)和LLD(Low-Level Design)之间的权衡，一个问题有不同的解决方案，怎么样实施才能够满足不同角色的需求？

一个是不同领域涉及的安全知识，另一个是安全领域涉及的不同知识。比如你做网络的架构设计时怎么考虑到安全上的一些防护点属于第一种，你在部署安全设备的时候怎么考虑到网络的问题是第二种。有些拗口，其实就是领域的交叉。而在机房的建设中，从提供主机到提供平台到承载应用，以及流程的自动化，监控，告警，等等无一不需要考虑。

画龙-整体设计

主要关注三块去做，基础安全，应用安全和数据安全去做。应用安全可参考之前的那篇文章暂时不在此处赘述，数据安全方面的观点暂时没有很大的长进，但稍微会简要讲下。另以下各部分的思考主要来自DC建设过程中的思考，均是为了抛砖引玉，所以也并不会列到十分细节的地步。

基础安全

基础安全虽然听起来像是很基础的样子，但其实一点也不基础。需要有很多的经验才能hold住。 涉及了方方面面，网络安全，主机安全，密码学，安全运维等等。基础安全技术涉及的点肯定很多，但是在做安全架构的时候，技术往往又只是其中的一个点。并不是一个技术就能解决了安全威胁。所以这里要介绍代表了相应技术的安全产品承载了哪些相应功能，以及在配合过程中的坑坑点点。以前在基础安全的经历中，大多是base在自研产品和已有的基础设施之上去做，网络，机器等等都是现成的，所以和目前的经历还是有不少差异的。

设计的过程可以考虑的原则有很多，这些概念你首先要能分清是什么，怎么用，在什么时候用，影响有哪些，怎么缓解或解决，损失是不是我能接受的。例如不是所有的企业在架构设计之初就采用零信任，零信任听起来是零，做起来则是一条链，确保一条可信链路。构建可信的终端环境，各个应用间做到充分的通讯加密和服务鉴权。一切过程都能够最小化原则和Security By Default。你的办公网基础设施和生产网基础设施也不一定要放在一起。至于放在office还是idc就是另外一回事了。不同的过程又要遵循不同的策略。

怎么从high-level design 到 low-level design ? 基础安全层面的策略制定能否被认可和推行，组织架构上的问题又怎么办？越是基础的东西越需要慎重考虑。而且不同的工作模式也会有不同的阻力。相较于之前公司内部跨团队以及集团内跨BU的沟通，到现在公司的不同团队以及和集成商，供应商，实施方之间沟通，效率和方式也会有所不同。诚然像某位前同事所言，在外面很多企业里没有相应的价值观约束，安全做起事来倒是很费劲。所幸金融企业对安全的重视程度还是蛮高的。

安全产品有软硬件之别，因此在部署上会稍有差异。在基础安全的防护上，至少需要考虑接入模式，布线方式，容灾策略，运营策略等相关部分。每一部分既有HLD也有LLD，也可以把所有HLD，LLD分别串在一起。例如，waf的接入模式，是反向代理还是透明网桥，容灾设计等等这都属于是HLD，至于哪个口，什么线，哪个连交换机，哪个连F5这个是LLD。以下简单的列一些考虑点。

• 接入模式（这一块需要考虑的很多，毕竟怎么把安全产品——软硬件以侵入或非侵入的形式布局到你的基础设施中即很技术，又依赖经验。HA怎么做，多活Active/Active还是主备Active/Standby ？ 认证怎么做，用密码还是证书，MFA呢？ 哪些机器和系统放DMZ？管理放MGMT，数据库在HRZ还是HRZ-DB，或者？ 应用上影响到session的传递吗？重试会有多少次？安全域的划分参考业务设计了吗？技术使用哪种虚拟化技术vmware sphere， OpenStack？ 物理机有没有DLP，操作系统用什么版本，加固做哪些，又要固化哪些package？ Root CA要打进去吗？扫描系统所在的位置需要对全网段放开还是每个zone都放一套？license和预算呢？日志收集系统怎么建，考虑到数据量增长了吗，es/splunk有哪些查询优化的方式？数据查询时的审计怎么做？）
• 布线方式（旁路，串联，单独采购bypass switch设备还是自己的switch，一个设备Internal IP和External IP分可以几个？准备用光口还是网口? 设备的网口能断电透传，光口还可以吗？机器和交换机是否都需要Bound?，交换机的部署模式，Active-Active对其他设备的依赖和影响，流量是透明经过网桥还是 mirror traffic。 内存又会怎么样？诸如此类。）
• 容灾策略（多一套网络链路还是多一套冷备机器？监控怎么做可以实现自动切流？新的灾备中心？应急启动流程，怎么执行？业务持续性保障的策略？）
• 运营策略（敏感数据有审计流程吗？遵循权限分离原则了吗？加密机的LMK怎么保管？保险箱自身的安全设计呢？又有哪些手段去确保可信链根节点的可信？划分多少人力资源在设备维护上面，根据业务，还是设备来划分？）
• 验收测试（网络链路的冗余测试，安全考虑HA后之外的链路冗余是否还需要安全参与？安全设备对应的相应功能是否会定期做攻击性验证？验收测试怎么确保基础设施安全，有无遗留后门？各种设备账户清除，物理机，虚拟机，交换机。）

除此之外还应该着重考虑连通性和访问控制相关的问题，访问控制一般多在网络上做，除此之外还有主机上的端口控制，登录控制。物理上有多级门禁卡，钥匙+密码等等。但并不影响你使用各种概念，威胁建模，3A，Security By Default 等等。你可以设计security matrix rule去规划各个zone对应role的访问rule。而且需要考虑连通性的验证，人——（设备-应用-数据）之间的连通，正常情况下以及“逃生通道”。以下简单的列举了一些需要思考的问题。

• 路由器的链路链接，冗余测试?
• 是否具有断电透传功能，是否有必要冗余出来一条单独的线路？
• 是否采用ilo，带外通过网口还是光口？
• 安全域怎么划分，网段怎么划分，大段还是小段，和你的安全域设计的理念冲突吗，要综合业务吗？
• Internet怎么连? dc间怎么连 ? corp怎么连？需要拉了几家的专线？
• DMZ是不是还需要Firewall（一般来说金融行业或者银行在过检的时候可能会看到有这个要求)
• loadbalance能不能直替代FW，充当流量入口？ failover怎么办？

当然要能看到除了网络访问上的连通性，还要看到一些逻辑上的，例如用户访问数据这种。一般我会根据列举的一些检查项去考虑。

访问	考虑项1	考虑项2	考虑项3
人-设备	权限（访问控制)	审计（行为控制）	…
设备-应用	功能(路由，检测，阻断)	性能（降级/熔断/断电透传）	…
应用-数据	业务（商业价值)	存储（数据价值）	….

//这一段写的并不是很满意，略显粗糙。希望以后能够补充的更为完善。

至于实施部分，则需要至少理清三块（尽量）： 看透要做的事情，看清要用的技术，看准要用的人。不一定需要事无巨细，但需要做好项目管理。进度追踪，问题反馈，适当去push。。做事的方式是怎么样的，大家是否喜欢PUSH或者被PUSH，Owner意识，OwnerShip听起来都比较扯淡，但干活的时候确实比较容易体现。如果是整个解决方案的实施在BU内，或者集团内是怎么样一个流程，如果是交由第三方集成商或者供应商又是怎么样一个流程，在信息共享上的粒度，控制等等。 （我可能是个很礼貌的甲方了）

应用安全

pass ，请参考之前的文章。

数据安全

数据安全需要贯穿人-基础设施-应用-数据， 全生命周期的去考虑这种。但在数据中心建设的过程中更多的以policy的形式出现，去约束各个控制域。因为我之前经历过DSMM的培训，所以大部分的安全观点也都是以DSMM为主产生的。但目前来看，考虑数据安全的话也会从三个周期单独去考虑，然后再综合到一起。即从基础设施，应用全生命周期，数据的安全三个层面去考虑，放在一起才能算的上是全生命周期。反过来看的话，数据安全并不能孤立存在，需要在每个环节依托不同的基础设施和策略去完善。

基础设施层的数据安全之前并没怎么过多的接触过，尤其是生产网基础设施的数据安全，不过对于办公网这种终端套件的话也算是稍有经验。目前来看，加解密工作设计过程结合HSM去做，HSM本身结合安全策略去做，内部PKI体系的设计构建，生产网和办公网是不是要分两套，服务器硬件DLP模块，施工人员的账号权限管控等等，如何更好的确认根节点的可信，其实很多内容在基础安全里面也是有提到过的。至于应用层和数据层的数据安全来说，暂时没有多大的改变，可能一部分就是应用层的经验主要还是在采集前的合规和采集中的传输以及采集后的存储使用销毁等过程，之前做过的一些类似工作可能就是数据收集，表数据清洗等等，现在的话就是多了些通讯加密，IAM设计相关。而数据层的数据安全在之前工作中接触到的相对多一些，多以数据分类分级，打标，脱敏，权限控制，日志审计，容灾备份以及检测和分析之类的形式出现。现在的话就是存储加解密。整体来说，仍有很多的提升空间。顺带一提美团应急安全响应中心有篇数据安全的文章，还是很不错的。

点睛——目标性的查缺补漏

整体的安全架构搭建完毕，根据木桶的短板理论，细节上仍会需要修修补补。不过这个阶段更多的就是目标性以及阶段性的定制化了，比如此时你可能需要考虑邮件安全的一些解决方案，证书，加解密，DLP，代理以及认证等相关的解决方案了。根据Corp和Site的部署位置，已有的工具等，去做出针对性的定制。这个基本上都是后话了，暂时不做详细介绍。

后记

我曾不止一次说，学习架构的一个好方法就是多看大厂的线上架构。看不全，就看一个系统的架构。从系统到产品到业务线、平台、中台等。回首第一篇，谈及架构之时似乎是高屋建瓴，但其实又缺少了几分烟火气。然而正是前人筚路蓝缕，才能以启山林。不可否认的是，阿里拥有着深厚的知识宝藏。站在巨人肩膀之上，自然是能忘得更远。不过平台带来的优势也正是他的缺陷。你在大道上行走，却看不到铺路的过程。而正是如此，在你亲自去做的时候，你可能无法顾及到方方面面。这一次我有幸参与到数据中心的构建过程，才知道0-1背后的辛苦。幸运的是招我的老板拥有着对安全的另一番见解，虽然他并不是专攻安全领域的，但也一样十分认同全生命周期的安全治理。或许过一段时间回头来看这篇文章，又会觉得比较浅显。但是无论浅显与否，整理并记录当时的收获都是一件有价值的事情。

看了下，又是拖拖拉拉，修修补补写了2周

2020/11/07 update： 这是第一篇 什么是安全架构