2020年7月，TOG（The Open Group）联合SABSA，正式发布中文版指南《安全架构实践的公理》（其英文版发布于2019年7月），其中20条安全架构实践公理如下：
公理1：业务风险驱动安全
安全架构应通过最大化收益和最小化损失来支持业务目标。
必须牢记的是，组织资产并不是为了被保护而存在，它们的存在是为了创造价值。而利用资产创造价值，通常意味着使该资产面临风险。这正是矛盾之处。
为了提供最优架构，安全架构师不仅要从防止负面结果的角度来看待它们对组织的贡献，还要从促成积极结果的角度来看待它们。
如果安全架构无法支撑组织利用其资产来完成业务工作，则该安全架构可能被边缘化和显得无用。
安全架构应基于业务风险驱动，并且应该是对这些风险进行适当响应。
公理2：场景
不要虚构场景，否则后果自负。专为一种场景而设计的安全系统或解决方案，并不总是可以有效地在另一种场景中工作。
这并不是反对重用，可重用的基于组件的架构有很多好处。但是，如果为了节省时间和精力，将安全系统重用于不同的用例，则需要针对这两个用例之间的差异，进行新的风险分析。
该指南还专门针对系统设计中的一个常见错误——访问控制过程的身份识别、身份验证、授权过程的混淆，进行了澄清。
公理3：范围
明确定义安全架构的范围很重要。在这方面，系统收益（SOI）的概念很有用（如ISO/IEC/IEEE 42010：2011中所定义）。
公理4：情报
安全系统应利用情报来主导响应活动。通过威胁情报，既可以了解对手的意图、能力、攻击方式，也可以了解自身的漏洞情况。
建议对潜在威胁场景进行建模分析，来实现最佳效果。
公理5：信任
安全架构应该保障系统可以准确建模业务实体关系中存在的信任的性质、类型、级别、复杂性。
信任是人际关系的特征。但我们可能要给非人员对象以信任。当这样做时，其实是在说，我们可以信任操作这类对象的人员，或可被操作这类对象的人员所信任。因此，一个可信的系统是指我们信任参与系统生命周期过程的人员。
信任从来都不是二进制，而是一个很长的灰度连续体，很少有黑色或白色。
“信任”和“被信任”不是镜像关系。
即使是最复杂的信任关系，也可以自顶向下分析成一系列简单的单向信任关系。通过严格执行此项分析，可以将任何业务关系分解为简单且独立的单向信任组件。
公理6：整体分析
安全需求应与其它的功能性需求和非功能性需求集成在一起。安全需求通常被描述为非功能需求（NFR），并且不应将其与其他功能需求或非功能需求分离。只有将所有需求都视为SOI（系统收益）整体风险的一部分时，安全架构才能有效工作。
架构通常被视为不同视角的一系列观点。这些观点通常被称为架构域。例如：业务架构域、应用架构域、信息架构域、数据架构域、服务管理架构域、技术架构域。就像看一座被群峰环绕的山谷，远近高低的观点各不同。
而安全架构域是从另一个视角来看的另一种观点，但与其它视角有很大不同，因为它是一个跨领域的域，必须以整体的方式解决所有其它域的安全和风险管理问题。因为风险无法分为孤立的架构域，所以安全架构师必须同时从所有视角看到山谷，即拥有可以随意旋转的全息视图。
公理7：简洁性
系统和服务应在保证功能性的前提下尽可能简洁。
复杂是安全的敌人，必须在保持整体性的同时，将其简化为子结构进行管理。安全架构将会受益于面向服务的架构（SOA）方法，在这种方法中，我们看到了“一切即服务”（EaaS）。服务的性能对于实现顶级业务绩效目标至关重要。
任何架构类型的主要目标之一就是管理复杂性。必须通过自上而下的分解来分解高度复杂的SOI（系统收益），从最高级别的业务目标开始，并创建逐渐简化的SOI层次，并对其逐层解决。
高度复杂的系统，倾向于表现出涌现性。涌现性的示例包括：两个或多个进程争用同一系统资源时发生死锁；网络在超出容量后的流量拥塞。
系统安全漏洞主要来自两个来源：设计错误和涌现性。两者不相同，不应混淆。涌现性是系统工程的一种现象，并非一开始就被设计出来。复杂性本身就是导致出现这一现象的原因。
公理8：重用
在可行的情况下，尽可能重用受信任的系统开发实践和系统组件。
安全架构师不应从零开始，不要重新发明轮子。从通用框架和参考架构开始，并针对特定的场景进行定制，始终是效率更高的方法。
框架示例包括：
NIST网络安全框架（CSF）：是150多个RFI响应和许多利益相关方会议的产物。
ISO 27000系列：是用于组织和监控企业安全机制的一组控件和过程。
ISO 31000-2018：定义了一个周期性的风险管理流程。
SABSA平衡风险模型：提供了定义风险相关组件的组织结构。
公理9：弹性
安全系统应在受到胁迫时依然正常运行。
架构的弹性不仅仅是设备，还必须包括人员和流程。
弹性的关键特征是计划内的系统降级——通过控制将系统降级，而非由于无法控制导致故障。
良好的弹性设计的一个例子，是在大容量云服务数据中心中使用混沌工程。混沌工程通过在时间敏感的在线服务中，不断进行故障自动转移测试，来验证系统弹性。
公理10：过程驱动
安全开发过程应使用清晰的生命周期，来解决要求的时间跨度，并引入利益相关方。
战略：安全架构的目标是支持组织的长期的业务战略。安全架构本身是一项战略活动，需要长期的投资和管理层的支持。
战术：安全架构是通过一系列步骤开发和实施的：利用变更项目从而使长期愿景变为现实。
运营：安全架构提供技术、工具、流程来确保日常的安全，并对业务运营提供风险管理。
公理11：优化冲突解决
安全应通过平衡业务风险，来优化解决利益相关方的冲突。
利益相关方的关注通常会发生冲突。安全架构的作用之一是以最佳方式解决这些冲突，在功能需求和其他非功能需求与安全需求之间取得平衡。这些利益冲突可能非常复杂，源于安全架构的跨复杂领域的性质。
公理12：清晰的沟通
安全应使用有利于业务和技术利益相关方之间进行有效沟通的通用术语。
安全架构师必须至少会两种“语言”，能熟练使用业务涉众的语言（“业务术语”）和技术人员的知识（“技术术语”）。
公理13：易用性
安全系统应该尽可能对用户透明且易于使用。
不易使用或导致生产受到影响/破坏的安全控制措施，通常会被忽略、禁用、废除，导致资源容易受到攻击，从而失去了控制措施的价值。而被绕过或未被使用的安全系统将毫无价值。
可用性差的经典示例，是密码的使用。另一个示例是Web浏览器使用PKI证书对网站进行验证。
公理14：安全设计
安全性应依赖于经过验证的特定控制措施，而非隐藏。
每本安全书籍都强烈建议不要使用“通过隐藏构建安全性”。其实通常被否定的，是希望安全漏洞不被发现的侥幸心理。
安全不应依赖于暗箱操作或其它晦涩的形式，而应依赖于经过验证的特定控制。就像密码学的安全性，应取决于对加密密钥的保护，而非加密算法。
公理15：优先级
使用较强的保护机制来保护较弱的机制，而非相反。
最重要的事物不应依赖于不重要的事物。
公理16：设备主权
所有设备均应能够在不受信任的网络上保持其安全策略。
保护机制通常位于本地或靠近被保护的资源更有效。这使得防护机制更容易随受保护资源一起迁移。
物联网设备的市场壁垒，使得设备主权原则难以适用。安全架构师必须面对这一挑战。不可能强迫市场将高级安全性集成到IoT设备中，因为这是一种市场驱动的现象，受成本和收益的感知驱动，但是设计整体集成的分层方式将改善一定程度的安全性。
公理17：纵深防御
通过分层防御可以获得更高的安全性。
纵深防御是一种传统方法，它通过在攻击路径上应用多层或多级安全性，来最大程度地保护每个资源。
为了使纵深防御有效，各层之间必须彼此独立，各层应该由不同类型的控制措施组成，而非多层使用同一类型的控制。
当控制措施失效时，选择失效而开放，还是失效而关闭，取决于资源的敏感性和它所支持的服务的需求。在此领域，有限状态机（FSM）建模可用于探索系统可能进入的所有可能状态。
公理18：最小特权
主体（人员、事物、流程等）应仅被授予执行其授权任务所需的权限。
部署最小特权系统和服务的能力，在一定程度上取决于可以执行细粒度访问控制的技术和流程。细粒度的访问控制，要求以一种方式捕获或存储有关资源或资产以及最终用户的元数据，以便访问控制系统可以通过它来做出有关资源的访问决策。
职责分离也是从纵深防御中衍生出来的一种特殊形式的最小特权。
公理19：访问管理
访问控制包括三种不同的操作过程：
识别：识别并区分主体；
认证：验证主体的身份；
授权：授予主体适当的访问权限。
公理20：通信安全
设备和应用程序应使用开放、安全的协议进行通信。
在当今过度连接的世界中，无法假设未加密的传输具有任何级别的安全性。
最重要的一点是，无论加密服务是否已打开并处于最佳运行状态，网络服务都无法向应用服务发出信号。因为网络无法理解应用程序的数据结构。
规则很简单：网络需要网络安全服务来保护。应用程序需要应用安全服务来保护。
通信安全架构是一门复杂的学科。它必须在通信设备之间采用敌对环境，并且必须同时满足应用程序层安全性和网络层安全性。
参考：
《网络安全架构：安全架构实践的公理》
安全内参是个很好的安全类技术网站，大家可以关注一下：安全内参官网