事实上，离第一个安全架构的文章还有一段时间。上篇文章主要从安全架构师的主要职责浅显地谈到了所需的相关能力。然而，随着经验的不断变化，认知总是在不断变化。今天，我们将从每一个具体的内容中简单地写出什么是安全架构的第二篇文章——具体的相关解决方案。你也可以在之前的文章中看到一套关于设计解决方案的探索过程。不一定都适用，谈经验。

一般而言，甲方企业的构成基本上离不开这种模式(忽略图有点丑…)。人员分为合规、技术和运营三部分，领域主要关注基本安全、应用安全和数据安全。当然，团队结构根据组织结构不同而不同。有的从技术角度划分不同的团队，分为基本安全团队、应用安全团队和数据安全团队。当然，不可否认的是，近年来安全运营和可信计算等相关基础设施都被划分为基本安全团队。还有一些是从运营的角度来做，这取决于企业内部安全建设的成熟度。但是很少有人从合规的角度来划分团队结构，但每一项合规的工作都需要涉及整个安全大团队。当然，除此之外，还有一些企业直接按照PDR的时间线来划分，成立安全技术团队，安全检测团队和安全响应团队。

一般来说，整个安全组织结构是根据企业自身情况进行评估、技术需求和人员预算来划分的。至于安全是挂在运营维护下还是挂在运营维护下，需要记住安全与运营维护/R&D不是对立面，分工不同，相互合作。至于矛盾和纠纷，尽量不要阻碍业务发展，但是如果基线策略(基线策略的制定已经存在，就按照财年review/修订，如果没有，就和各大部门负责人合作初版，逐步报到技术委员会或CTO/CSO审批)。

绘制此图是因为安全技术领域也有许多交叉，特别是甲方。还希望做技术的人能从操作的角度思考对方在技术领域的工作，做操作的人能了解到技术人员在不同领域的技术。此外，不管是基本安全、应用安全还是数据安全，不同企业在不同领域的布局肯定也不一样，这就涉及到如何避免划分时的归属歧义，否则应用安全的人认为他应该hold，但基本安全的人认为你吃了我的蛋糕。与此同时，数据安全心里还在想我怎么插不进去。