【翻译】零信任架构准则(四)Authenticate and Authorise everywhere

通过策略匹配来授权一次请求

零信任架构的威力来自你定义的访问策略，用户的每个服务请求都应该根据策略进行授权，具体步骤如下：

1. 当用户进行一次访问时，用户试图与策略执行点建立连接，策略执行点主要负责转发他们的请求到内网的具体应用，相当于一个代理的作用。

2. 当策略执行点（PEP）收到用户访问的请求时，会解析用户携带的上下文，接着会向策略引擎（PE）发起访问鉴权。

3. 策略引擎会通过防护策略对这次请求进行评估，如果评估通过，则该请求会被策略执行点转发，如果评估拒绝，则连接将被丢弃。策略引擎（PE）会持续评估请求的安全状态，如果发现异常，则会终止用户连接或让用户进行增强认证（MFA，手机验证码等），当然你使用哪种策略模式取决于你的零信任产品的部署方式，例如使用托管云服务肯定不同于私有化部署。

保护策略引擎

零信任架构中最重要的组件就是PE和PEP，因此，你应该确保这些组件受到安全保护，如果这些组件遭到破坏，攻击者将能够控制谁有权访问哪些数据或服务，因为他们可以随意配置策略，这是非常可怕的。

其次，我们应该考虑策略引擎仅可以与可信的策略执行点进行通信，而策略执行点也需要和内网服务建立安全连接，确保用户设备是经过验证的，如果你使用的是托管云服务提供的策略引擎，那么解析signal的过程需要依托服务商的安全能力。

最后，配置策略时，我们需要做一些用户限制，不能随意让普通用户配置重要策略，为了方便溯源和审计，我们也需要记录用户的操作日志，当然如果确信某些服务的用户是真实可靠的，那么也可与基于身份构建一个白名单以授权服务之间的连接。

组合多个Signal做出决策

授权决策应该考虑多种信号，这些信号取决于用户访问过的历史信息和当前正在访问的实时信息。我们通过这些信息可以构建出用户上下文，并将这些Signal一同送入策略引擎，以便让策略引擎做出最明智的访问决策。常用的可以被策略引擎用于评估的一些Signal，如下所示：

• 用户的角色
• 用户的实际位置
• 认知因素
• 设备健康状况
• 访问的时间
• 要访问的服务敏感性
• 请求的操作通过后的后续风险值

拒绝访问与break glass

当发现用户的请求被拒绝的时候，我们应该考虑如何合理的通知用户，如果提供的信息过多可能会方便攻击者，信息太少可能会使合法的用户感到困惑。一般来说，我们应该指出用户存在的身份验证的错误，但不要详细说明失败原因类似于“该账户不存在”，如果没有这样的线索，攻击者很难枚举身份验证信息。

当然，如果用户访问业务时被阻断了，我们应该也要有一个保护措施，让用户迅速恢复上网，因为此时可能是用户至关重要的时候（用户签大单呢），因此，即使用户无法满足访问策略，我们也需要一个主动允许建立连接的流程。

任何break glass（译为：在必要时，没有获取某些信息权限的人可以快速获取信息的手段）程序的行为都应该迅速发起告警，例如群组邮箱或共享的聊天频道，这样会提醒运维同事及时采取行动，在这种情况需要仔细管理风险以滥用此功能。例如我们可以这样设计，仅允许从特定的设备上特定的账户从指定的位置进行此类访问，并且存在时间限制，且所需权限最低。其次，为了增加可用性，防止因误报而阻止了合法的用户请求，我们应该在首次定义策略时，采取短时间内记录而不是直接拒绝访问，在一段评估期间，我们定期审核日志，持续衡量策略的有效性（灰度），在此过渡期间我们可以采用传统的安全来阻止恶意请求。

多因子认证

MFA（多因子认证）是零信任架构验证的必要手段之一，这并不意味着用户体验一定很差，在现代设备和平台上，我们可以通过良好的用户体验来实现强大的MFA。例如，仅在对用户和设备的信心下降时，才会在一些用户设备上推送通知，这样用户就不会经常为键入代码或查找硬件令牌而烦恼。值得注意的是，并非所有的身份验证都是对用户感知的，例如，OAuth 2.0 和 Public Key Infrastructure.

翻译：zhihu于顾而言

Reference

zero-trust-architecture/4-Use-policies-to-authorise-requests.md at main · ukncsc/zero-trust-architecture · GitHub

zero-trust-architecture/5-Authenticate-and-Authorise-everywhere.md at main · ukncsc/zero-trust-architecture · GitHub