之前写了几篇存稿，过了几个月也没有时间去接起来完结掉，干脆就不接了。看看外面甲乙方都宣传的天花乱坠，独独安全架构始终没有存在感。2002年、2003年的安全架构书籍中记载的理念，过了20年依旧没有很好的落地。我看倒不如也来漫谈一下如何建设安全架构，刷刷存在感。且当我是胡言乱语不作数。

分协作和治理两块。简单介绍总结一下。

1. 协作

一般来说，要确保各自的职责范围，建立相应的协作流程，通过一定的同步机制降低部门间的信息差。对专项形成一定的虚拟团队等。安全架构组负责承担团队内外的设计需求，例如安全治理团队和风险管理团队的需求（有些团队可能会把安全治理的一部分职责放到架构中去。理论上如果能够形成单独的团队效果应该会更好）。并交由平台组实施，通过运营组交付给最终客户。安全架构将承担着承上启下的作用。完成方案的设计，使其符合Policy Design，找出gap，使用某种符合的pattern或者model，最终给出平台的System Approach。

平台是支撑持续交付的必要条件之一，除此之外在面对业务方的时候，并不能仅仅通过【当时】上下文了解，还应该建设长期对业务深入了解的机制。

• 平台

  对外的持续交付将由此逐步推进团队内平台化建设。由此形成安全能力的交付平台。小规模的安全平台可以从承担研发运维，稍大些的团队可以囊括到安全运营日常工作中的需求。但这并不是说搞几个安全运维工程师和安全研发就是安全平台了。平台一定是要有平台级，系统化的产品的。内化策略、流程和风险管理到平台，通过接口整合系统并输出自助式服务能力。

• 业务

  安全对业务场景的深入将催生相关的专职人员，在制定综合性解决方案前一定需要足够多的关于业务的上下文。而这些业务背景需要更加系统化，能够互相关联。例如合约、钱包、现货之间存在哪些共用的，一方的变化是怎么样影响到另一方，安全的控制措施是否产生连锁反应等。那无论是信息安全BP，还是BISO，都可以起到深入业务共建的角色。形式上可以通过参与架构委员会，成为单独条线的业务安全接口人，以此来获得更多的有效信息。尤其是在业务迭代较快的情况下。

2. 治理

安全治理的原则从安全默认到安全左移，其实也无非是时间和空间的关系。最终的效果就变成了默认安全左移的纵深防御，能够尽量提前自己的安全设计，并使其落地。但由于基础设施的IAC化，无论是Infra还是应用都能获得动态的资源变更，因此发布频率也将越来越高。这也导致要求安全运营需要更快的自动化响应，在发现和处置之间尽量的缩短时间，以及避免不必要的步骤。近些年来，检测及响应领域出现了X-DR，X-SPM，安全运营出现了X-SOAR，攻击模拟等新的产品。对内通过管理资产并进行保护（PDRR-P），对外形成风险管理面（PDRR-D）。并通过安全运营使其自动化，通过攻击模拟验证系统架构（防御及设计流程）的强度。这应该是较为常见的一种防御模式。

在这个过程中，我通常还会关注框架的融合（以某种方式整合安全属性到企业架构中去）、基础设施的变化以及业务特性（例如web3业务，以及混合多云比较头疼）、信息保护和数据安全。下面分别简单的总结一下。

• 框架融合

  无论是安全架构还是企业架构都已经形成了自己的方法论，闻名遐迩的有TOGAF，风险管理的有Octave，安全有SABSA，O-ESA等等，那怎么样把领域内的框架和企业架构框架融合到一起在做安全设计的时候就显得非常重要，因为后续的解决方案都应该遵守这个规则/框架去实施。

• 云与Web3

  云和云原生依旧是未来的趋势所在，或者说是资源虚拟化及动态调度。虽然不一定选择公有云，但一定是具备弹性能力的。我有几个明显的感受变化，一是当自己使用云但企业使用IDc的时候，二是当企业开始使用云的时候，之后当企业使用混合云，混合多云的时候。这是完全不一样的心理感觉。云上的安全防护毫无疑问是企业会主动关注的，但作为云厂商提供的安全产品却通常比较简陋，而且租户缺乏一定自主性，同时又会默认依赖/信任云厂商。但作为安全从业者，又觉得云厂商做安全有一种都想做，但又做的不太好。对于租户来说，只是获取了资源。对于云来说，都是厂商的生产网。结合Web3来说，去中心化的业务运行在中心化的云上，可能因为合规，可能因为供应链危机导致账号面临关停。云上虽然提供了弹性，但资产却不完全是自己的。而对于Web3来说，如果是去中心化的链或者发布的合约，基本上意味着一旦出现了安全事故，无法像传统安全那样获得快速的修复和止损，更不用说资产的追回。纵观过去一年，有多少项目遭受了灭顶之灾。而web3项目在基础架构的设计上又和传统安全没有太大的区别。这也是我把这一小段取名云与web3的原因之一。务必要去深入了解业务以及基础设施。

• 信息保护与数据安全

  数据安全可以是一种技术能力，也可以是想要做到的目标。最近看到不少数据安全类的文章分享，不过大多数都是从DSMM或数据生命周期出发的。不过以架构视角看看corp侧的信息保护和数据安全。不同于site/生产环境，corp的数据更为分散，场景更为复杂。例如生产网的数据可以很快的去划定好等级，类别。因为key和value的格式较为固定，也能够很容易的建立起检测机制。但办公环境就比较难以实现。例如在site环境里去匹配一个身份证号，和在办公网环境里面去检测一个身份证号是差别较大的。不具备固定的pattern，可能存在于邮件，可能存在于wiki，可能存在于文档。分布过于复杂。这就意味着需要不同的系统和工具来支撑发现。可以通过对文档进行强制主动标记的方式，结合固定点的DLP进行防护，见上图（修改自微软的数据保护框架）。之前有一篇将终端安全的文章，细节就不在此赘述了。隐私保护主要在人，关注在人产生的数据中的敏感部分。数据保护关注在数据，可以是PII、金融数据、也可以是其他敏感数据（隐私保护和数据保护为了便于理解在此都被划为信息保护了，不一定对）。而这一切都需要数据安全提供技术支撑，通过隔离，加密，水印，脱敏，Token化等技术达到数据“安全”的目的。不过我现在已经不像最开始的时候，期待通过对数据治理实现数据安全。而是在此之外，综合基础安全/应用安全解决方案来实现数据安全。当然还有一个点要提，综合性的解决方案，绝对不是综合某一家厂商的不同产品或解决方案。

如果安全架构组在团队内的可见性较低，多数是因为没有建立有效的合作流程，才导致无论对内的输出以及对外的输出都遇到较大的阻力，以及信息差。当然这个并不完全是安全架构组Leader能够左右的，甚至是安全负责人也无法决定的。在可见性较低的时候，团队的存在意义就会受到质疑，自我怀疑。

而作为安全架构师，看过了狗屎一样的设计，也一次次遇到过瓶颈。也愈发感觉到顶层设计的重要性。就像我最开始意识到数据的价值之后，期待通过自动化运营来发现并反向push解决这个问题，实际更需要通过架构设计从源头杜绝。类似的还有，当要开防火墙的那个需求来了，才想着去看系统设计的案例多不胜数。反向建设固然能接飞盘博眼球，但累的还是狗。