英国国家网络安全中心：零信任架构设计原则（二）
4、零信任架构设计原则：使用策略来授权请求
每个对数据或服务的请求都应根据策略进行授权。
介绍
示例 - 策略授权的访问
这是一个用户访问服务或公司数据的简单理论示例，其中包含授权请求的策略。一个更深入的例子，扩展了授权过程中信号的使用，可以在下面的使用多个信号做出访问决策中找到。
用户建立与策略实施点的连接，这将调解他们与请求的服务或数据的连接。
该策略执行点会查询策略引擎的访问决定。在向执行点提供访问决定之前，策略引擎将根据访问策略评估请求。
如果访问请求被策略引擎接受，策略执行点就会允许该请求。如果它被策略引擎拒绝，则连接将被丢弃。
访问决策正在不断地实时评估。安全状态的变化可能需要终止连接或重新进行身份验证。
如何使用策略来授权请求取决于部署的零信任技术。例如，使用托管云服务的零信任与本地网络不同。
在某些方法中，使用的名称和术语可能与我们上面的示例略有不同。
持续评估
通过监控来自用户和设备的信号并对其进行持续评估来支持持续评估。如果对其安全性的信心下降，则可能会在授权继续访问服务和数据之前动态触发重新身份验证。
无论如何设计零信任架构，策略引擎或任何强制执行策略的组件都应仅在满足定义的严格策略时才允许连接。
保护策略引擎
必须高度信任任何执行访问策略的产品或服务，这一点很重要。应该确保架构的这些基本元素在设计时考虑了零信任。如果此组件遭到破坏，攻击者将可以控制谁有权访问数据或服务。
重要的是，对策略引擎的访问仅限于与受信任的策略实施点或提供信号的服务（例如用户身份服务）进行通信。它不应与不受信任的来源通信，例如未经身份验证的最终用户设备。
当策略引擎解析信号时，源应该来自相互认证的可信和已知实体。输入也应该在解析之前进行验证。这可确保策略引擎不会消耗任何恶意内容。如果您使用的策略引擎是托管服务，则安全解析信号的过程很可能是服务提供商的责任。
保护导入策略引擎的策略也很重要。限制谁可以将策略导入受信任用户以及能够审核和审查策略的能力是关键。
使用多个信号来做出访问决策
策略决策应考虑从历史信息和实时连接信息中获取的多个信号。总之，这些能够构建上下文，因此可以决定是否可以足够信任访问请求以继续。这些信号被输入到一个策略引擎中，因此它可以做出明智的访问决策。
使用多个信号来获得对访问请求的信心很重要，因为这将提供更多信息进行分析，并提供更大的信心，即请求者是真实的并且他们的设备处于良好的网络健康状态。
高影响力的操作，例如创建新的管理员级别用户，必须满足严格的策略要求才能被信任。而相对较低影响的操作，例如查看在线午餐菜单，则必须满足更宽松的政策要求。
示例 - 向策略引擎评估信号
下图描述了策略引擎如何评估多个信号的理论示例。信号和用户访问（通过策略执行点）由策略引擎持续评估。
根据对零信任的实施和使用的信号类型，细节可能会发生变化，但此处说明的原则应该是相同的。
购买零信任技术
在为零信任架构选择技术时，请评估它们支持的信号类型以及其他相关功能，以便与策略引擎兼容。
策略引擎可以评估的一些示例信号是：
用户的角色
用户的物理位置
认证因素
设备健康
一天中的时间
要访问的服务的价值
所要求的行动的风险
基于风险的引擎
一些策略引擎将允许创建基于风险的访问策略，可能会提示额外的信号以获得对连接的更多信心。
基于风险的策略引擎会考虑用户和设备的置信度，动态调整访问策略作为响应。例如，假设用户在正常工作时间之外首次尝试访问高价值服务。在这种情况下，策略引擎可能会要求用户提供用于身份验证的第二个因素。
其他注意事项
拒绝访问
当访问请求被拒绝时，请考虑如何通知用户。太多的信息可能会帮助攻击者，太少可能会挫败合法用户。
可能会指出存在身份验证错误，但不会通过说“该账户不存在”之类的内容来详细说明失败的原因。如果没有这些线索，攻击者要枚举认证信息就困难得多。
打破玻璃
如果出现对数据访问至关重要的紧急情况，可能需要制定一个允许建立连接的流程，即使无法满足访问策略也是如此。任何使用破玻璃程序的行为都应注意共享媒体，例如群组邮箱或共享聊天频道。这样就可以发现任何滥用凭据的行为并及时采取行动。
在这种情况下，需要谨慎管理风险以防止滥用此功能。例如，限制与紧急访问相关的风险，只允许从个人用户帐户、特定设备上、指定位置在有限的时间内进行此类访问，并且需要最低权限。
可用性
一旦定义了管理对数据和服务的访问控制的策略，应该评估可用性是否因错误地阻止合法访问请求而受到影响。
首次定义策略后，首先在一小段时间内记录并不拒绝访问，以确保策略按预期运行。在此评估期间，定期审核日志并在发生恶意尝试访问数据或服务时立即采取措施非常重要。
可能的情况是，需要一个过渡期，传统安全控制措施会主动阻止请求，同时正在衡量新违抗策略的有效性。
5、零信任架构设计原则：无处不在的认证和授权
假设网络是敌对的，验证和授权所有访问数据或服务的连接。
介绍
多因素
MFA是零信任架构的要求。
这并不意味着用户体验一定很差。在现代设备和平台上，可以通过良好的用户体验实现强大的MFA。例如，仅当用户和设备的信心下降时才触发 MFA。某些身份验证应用程序会在受信任的设备上提供推送通知，因此用户无需为键入代码或查找硬件令牌而烦恼。
值得注意的是，并非所有身份验证因素对用户都是可见的，其中一个因素可能是使用内置 FIDO2 （线上快速身份验证服务）平台身份验证器的加密支持的无密码登录。
可用性
重要的是，强身份验证不会妨碍服务的可用性。例如，仅当请求具有较高影响时才提示其他身份验证因素，例如请求敏感数据或特权操作，包括创建新用户。应考虑 SSO，以减少 MFA 的摩擦。
应考虑采用基于风险的方法来减轻额外身份验证因素造成的更大影响。在上面的示例中，如果用户的置信水平足够高，则可以避免其他因素。
无密码身份验证（例如 FIDO2）是一种理想的解决方案，因为它提供了强大的安全性和出色的用户体验。考虑实施无密码身份验证，以在用户所有服务中获得强大、一致和积极的用户体验。
服务到服务
服务之间的请求也需要进行身份验证。通常是使用 API 令牌、OAuth 2.0 或公钥基础设施 (PKI)等框架来实现的。
使用相互身份验证，因此用户可以确信通信的两个服务都是真实的。这是构建允许列表时的关键，以根据身份授权服务之间的连接。