【翻译】零信任架构准则(五)Don't trust any network

将监控重点放在用户，设备和服务上

全面监控必不可少，因为设备和服务更容易受到网络攻击。在零信任架构中，随着设备，服务和用户行为的持续评估，我们的监控策略很可能发生改变。我们应该持续进行监控，并将用户流量通过安全传输（相互验证的TLS）定期导出到指定组件去分析，比如说用户访问的行为，是否是正常工作时间或正常工作地（发生异常很有可能是攻击者）。了解我们的服务，并了解用户与服务之间的交互也很重要，我们在监控中，观察设备，用户和服务正在执行哪些操作以及它们正在访问哪些数据，观察并验证它们是否按照你的预期执行。

如果我们使用的是自带设备（BYOD）或者是访客设备，那么我们将无法完全监控所有目标，在这种情况下，我们可以使用移动设备管理（MDM）和移动应用程序管理（MAM）解决方案，以此来提高对此类设备的安全性信心，具体可参照BYOD安全指南（BYOD guidance）。

不要相信任何网络，包括你自己的

零信任网络将网络视为敌对，我们必须主动构建并维护对用户，设备和服务的可信值。我们不要信任设备与其访问的服务之间的任何网络，这包括本地网络。为了防止这些攻击，我们应该采用两种方式，一种是安全加固，类似于使用安全传输等手段，这将有效防止DNS欺骗，中间人和未经请求的入站连接等攻击；第二种是使用私有协议封装，类似于隧道传输。

在零信任架构中，设备会通过浏览器访问互联网（IA场景），那么网络流量一定不会通过隧道返回到监控的中心点，因此设备需要做一些传统的web浏览器的安全防护，比如说恶意域名，未经授权的协议，恶意URL和网络钓鱼检测等等。如果你不能使用设备安全功能强制执行互联网策略，那你必须通过托管云来路由互联网流量。

选择专为零信任设计的服务

在选择零信任架构的组件或服务时，我们应该倾向内置支持零信任的服务，如果是遗留的服务（不在处于积极开发或支持的服务），可能需要额外的组件来实现零信任，这可能会增加管理开销并导致服务可用性的问题，因此，请确保你有足够的资源来解决这个问题，具体可参阅Obsolete products guidance。

不要重复发明轮子，由于成本，复杂性和出错的可能性，我们应该避免自己开发基础设施，我们应该尽可能使用基于标准的技术，这将具有可扩展性和移植性，一个很好的例子是身份验证和授权的通用标准允许服务和身份提供者之间进行互操作（OpenID Connect,OAuth 2.0or SAML）。

最后总结-零信任架构7项关键元素

Who is connecting?

知道连接的一方的身份。身份的特定的、细粒度的本质是零信任和零信任交换的基石——不仅对人，也对设备、可连接的东西和工作负载。这些实体必须提供一个有效的身份来区分自己，以便通过正确的控件集访问允许的资源，并应阻止所有其他访问权限。

What is the access context?

身份给了零信任一个谁在联系，他们的角色和责任的想法，但缺乏围绕联系的上下文。身份最初被认为是基于是否经过身份验证的初始实体提供“是”或“否”的二进制输出的能力。现在，我们必须将谁正在连接的细节与该连接的上下文联系起来，这允许对最小特权零信任的额外控制。就像你的Netflix登录让你访问Netflix一样，是关于你的东西——年龄、位置、兴趣、观看历史等——让Netflix推荐你最感兴趣的节目。

Where is the connection going?

验证过程的第一个要素以最初的身份评估结束。下一个元素需要理解被请求的资源：应用程序。这个应用程序需要被识别，是的，但是它的功能、位置、已知的风险或问题，以及与访问请求者的身份的关系也必须被评估。重要考虑的例子包括该应用程序是否已知，以及该应用程序是否在互联网上公开。这些条件将决定如何将申请提交到零信任过程的控制和执行阶段。确定哪个启动器可以连接到哪个目标服务，这最终是零信任解决方案的验证和控制阶段的结果。零信任服务不是防火墙，这意味着它们既不是传递的，也不是静态的。因此，所实施的策略必须不是一个简单的定义。

Assess risk

在生活中，我们都是根据上次表演的结果来评判的。零信任也是如此。前面的元素只和最新的评估一样好。该解决方案必须通过动态风险评分来考虑企业的风险容忍度。后续和正在进行的风险评估必须根据一组信号进行动态计算，以确保评分根据新的发展进行更新。这种风险随后引入决策引擎，以确定是否应该授予持续的访问权限。

Prevent compromise

查看流量和云应用程序使用情况的能力，可以有效消除隐藏在加密流量中的僵尸网络和恶意软件等恶意内容。由于大量连接互联网的流量被加密，未经检就允许这些流量使用服务是有风险的。检查外部和内部应用程序访问是至关重要的，因为这两个流量都可能是加密的。为了通过内部通信来抵御威胁，企业必须能够大规模地进行内部流量解密。

Prevent data loss

检查面向互联网、SaaS或内部应用程序的流量的能力对于识别和防止敏感数据的丢失非常重要。对于互联网来说，用例是显而易见的，中间人解密检查和API扫描都必须确保敏感数据不会泄露或渗透到未经授权的云服务。但是，同样的保护也应该扩展到内部应用程序访问。此功能适用于管理设备和非管理设备，在考虑物联网/OT设备和工作负载通信时也很重要。

Enforce policy

遵循验证和控制阶段，并结合对动态风险评估的理解，我们到达了执行点。执行并不像传统的安全解决方案那样，集中在专用设备的网络上。要素1中的授权决定和要素2中的评估都会影响到我们当前阶段的执行。必须不断地、统一地实施政策执行（永不信任，始终验证）。只有当策略保持不变，平等地应用于服务，那么无论执行点的位置如何，都能实现统一的管控。

Reference

zero-trust-architecture/6-Focus-your-monitoring-on-users-devices-and-services.md at main · ukncsc/zero-trust-architecture · GitHub

zero-trust-architecture/7-Don't-trust-any-network-including-your-own.md at main · ukncsc/zero-trust-architecture · GitHub

https://www.zscaler.com/resources/ebooks/seven-elements-of-highly-successful-zta.pdf

7 Key Elements of Highly Successful Zero Trust Architecture (zscaler.com)