简述常见的几种信任模型：开发人员应该知道的零信任模型
简述常见的几种信任模型：开发人员应该知道的零信任模型实现持续验证的一个关键策略是零信任网络访问（ZTNA）——一种强制零信任策略的解决方案。ZTNA 可以实现最小特权原则（PLP），这样用户或服务帐户只能在需要时访问资源。这种网络策略最大限度地降低网络安全风险，保护组织免受来自内部和外部的威胁。持续验证是零信任的一个关键方面——它意味着不存在隐式可信任设备、凭据或区域。有几个要素对于各种资产的持续验证来说是必不可少的，包括基于风险的有条件访问（维护用户体验）和易于应用的动态安全策略（考虑到合规性需求）。在零信任模型出现之前，企业使用防火墙和虚拟专用网（VPN）等技术来控制对网络和应用程序的访问。这些解决方案的问题是，一旦连接通过了安全检查，它就是隐式可信任的，并且可以对网络进行开放的访问。不管是合法用户还是攻击者都可以访问敏感数据和关键任务资源。为了降低这种威胁的可能性，企业实现了多个复杂的安全层来检测和阻止攻击，但攻击者仍然可以绕过这些防
什么是零信任模型零信任安全模型是一种设计和实现安全 IT 系统的方法。零信任背后的基本概念是“从不信任，总是需要验证”。这意味着用户、设备和连接在默认情况下永远不受信任，即使他们在连接到公司网络或之前已经通过身份验证。
现代 IT 环境由许多互相连接的组件组成，包括内部服务器、基于云的服务、移动设备、边缘位置和物联网（IoT）设备。传统的安全模型保护所谓的“网络边界”，在这种复杂的环境中是无效的。
攻击者可以破坏用户凭证并访问防火墙后的内部系统。
它们还可以访问部署在组织之外的云资源或物联网资源。零信任模型在受保护资产周围建立微型边界，并使用相互认证、设备身份和完整性验证、基于严格的用户授权访问应用程序和服务等安全机制。
为什么零信任模型很重要在零信任模型出现之前，企业使用防火墙和虚拟专用网（VPN）等技术来控制对网络和应用程序的访问。这些解决方案的问题是，一旦连接通过了安全检查，它就是隐式可信任的，并且可以对网络进行开放的访问。不管是合法用户还是攻击者都可以访问敏感数据和关键任务资源。
为了降低这种威胁的可能性，企业实现了多个复杂的安全层来检测和阻止攻击，但攻击者仍然可以绕过这些防御。零信任模型根据细粒度访问策略和当前安全上下文选择性地允许用户访问允许他们访问的特定资源，从而解决了开放网络的访问问题。
实现零信任安全模型需要将以下原则纳入组织的安全策略中。
持续的验证持续验证是零信任的一个关键方面——它意味着不存在隐式可信任设备、凭据或区域。有几个要素对于各种资产的持续验证来说是必不可少的，包括基于风险的有条件访问（维护用户体验）和易于应用的动态安全策略（考虑到合规性需求）。
实现持续验证的一个关键策略是零信任网络访问（ZTNA）——一种强制零信任策略的解决方案。ZTNA 可以实现最小特权原则（PLP），这样用户或服务帐户只能在需要时访问资源。这种网络策略最大限度地降低网络安全风险，保护组织免受来自内部和外部的威胁。
微分割零信任网络需要实现微分割来创建多个保护区域，而不是单一的安全边界。这种方法有助于分别保护网络的不同部分，一个受损区域不会威胁到网络的其他部分。
最小特权访问最小特权原则是零信任的关键，它向每个用户或实体授予最小必要的访问权限，防止暴露于敏感的网络区域中。最小权限原则要求谨慎管理用户权限。
设备访问控制设备访问控制为用户访问控制提供了补充，确保设备无法通过适当的授权访问网络。零信任系统必须监控试图访问网络的设备，以减少攻击表面积。
内网漫游预防内网漫游是指攻击者在网络的不同部分之间移动。即使已知攻击者的初始入口点，要检测他们也极具挑战性，因为他们可能已经移动到网络的任何部分。
零信任解决方案对网络进行分割，限制内网漫游和渗透，确保隔离被泄露的帐户或设备能够消除威胁。
执行分割的实际组件可能是 ZTNA、集成了零信任策略的下一代防火墙（NGFW）或云安全访问代理（CASB，一种附加在云资源上的小型防火墙）。这些工具可以从多个维度对网络进行分割——例如应用程序分割、环境分割、过程分割和基于用户的分割。
零信任的应用场景和好处多年来，零信任模型一直是一个既定的标准，但它仍在经历规范化的过程，以帮助企业应对不断变化的威胁环境。数字化转型的普及和网络威胁的增长促使许多企业采用或改进他们的零信任策略。
零信任安全模型对所有的组织来说都是有好处的，对于使用混合或多云部署模型、非托管设备、遗留系统或软件即服务（SaaS）应用程序的组织来说尤为如此。在这些环境中，组织拥有可控范围之外的资源，或者可能与组织的安全政策和实践不兼容——零信任可以帮助在这些系统周围建立安全边界。
零信任模型对于及时检测和应对常见威胁来说也至关重要，例如：
- 勒索软件攻击是一种带有双重目的的威胁，它既执行恶意代码也会破坏身份。
- 内部威胁——这种风险随着远程访问和外部用户的增加而增加。
- 供应链攻击——由远程特权用户和非托管端点设备构成的风险。
实现零信任有助于组织解决 SOC（安全运营中心）或安全分析师技能缺失等问题。零信任模型支持在混合环境中大规模设置安全策略，并使用自动化来检测和应对威胁，减少了手动工作和安全团队的工作量。
它有助于最大限度地减少安全机制对用户体验的影响，同时强制遵守法规和行业标准。零信任的另一个优势是，在面对快速演变的威胁时加强组织的安全策略。
由于业务、安全和数字化条件的不同，每个组织都面临着独特的挑战。零信任是一种可调整的策略，可以满足不同组织的特定安全需求。
零信任参考架构向零信任模型过渡可能是一个非常复杂的过程。谷歌和微软是两个实现了大规模零信任的企业，它们创建了参考架构，可供业内其他组织效仿。
谷歌 BeyondCorpBeyondCorp是谷歌的零信任实现，建立在谷歌的长期经验之上，结合了社区的想法和最佳实践。BeyondCorp 将访问控制安全层从单体外围转移到网络个体用户，允许远程 Worker 从任意位置安全地访问网络，而无需使用传统的 VPN。
BeyondCorp 提供了一系列最佳实践和概念，可以帮助其他组织实现零信任模型。它也是一种商业解决方案，可用于在组织中实现零信任。商用解决方案叫作 BeyondCorp Enterprise（取代之前的 BeyondCorp Remote Access）。
新版 BeyondCorp 为 Chrome 添加了零信任特性。除了在托管终端设备上部署代理外，企业还可以通过浏览器扩展 BeyondCorp 架构。Chrome 的更新包括威胁保护和嵌入式数据功能，有助于防止意外或恶意数据泄露、恶意软件感染以及其他形式的网络和设备泄露。
BeyondCorp Enterprise 提供了连续认证特性，定期对设备、用户和应用程序之间的所有交互进行认证。企业可以创建并实施访问控制策略，持续地验证认证数据，包括用户身份、设备数据和 IP 地址，一旦出现违反策略，将立即取消其访问。
第三方安全供应商可以利用 BeyondCorp 联盟计划为这个新平台开发零信任产品。例如，终端安全供应商Tanium提供了与 BeyondCorp Enterprise 的集成平台，允许两种产品交换安全信息，为组织提供更高的环境可见性。
微软零信任模型微软公布了其内部零信任模型的实现细节。这种零信任实现解决方案专注于企业范围内的企业服务，例如微软 Office 和业务线（LOB）应用程序。
它适用于运行在 Windows、Android、Mac 或 iPhone 上的设备，云移动设备管理服务微软 Intune 负责管理这些移动设备。
微软的零信任模型包括四个阶段。
- 身份验证——微软通过对远程访问请求要求进行双重身份验证来保护网络。过去使用智能卡进行验证，现在使用 Azure Authenticator 来实现移动设备验证，未来计划消除密码机制，支持全面的生物特征认证。
- 设备运行状况验证——微软使用 Intune 注册新用户设备。设备健康策略指示哪些设备是健康的，或者在访问主要的生产应用程序（如 SharePoint、Exchange 和 Teams）之前需要加以管理（测试和修补漏洞）。对于某些场景，微软通过虚拟 Windows 应用程序和桌面为非托管设备提供支持。
- 访问验证——任何对微软服务的访问尝试都必须经过基于身份、设备健康状况、总体安全上下文（例如一天中的时间和用户的位置）和来自微软智能安全图的其他数据的验证。这里的创新之处在于，微软可以对访问进行验证，无论用户是直接访问公司网络、通过 VPN 访问，还是通过网络访问资源。
- 服务验证——微软提出了一种未来的机制来验证服务，确保在允许用户与服务交互之前它们是健康的。这一特性目前处于规划阶段。
零信任模型将安全责任从网络转移到了应用程序。应用程序本身具有验证细粒度策略的能力，并确保每个用户准确地访问允许他们访问的功能和数据。
在零信任环境中，开发人员不能仅仅依靠简单的 API 令牌进行身份验证和授权，他们必须全面了解如何在考虑到当前安全上下文的情况下保护请求者与应用程序的每一步交互。
零信任环境中的应用程序需求在零信任安全模型中开发应用程序时，开发人员需要：
- 评估会话的整体上下文，以确定总体风险。
- 确定零信任验证的关键因素——用户的身份、发出请求的设备的状态、正在使用的应用程序功能以及请求试图访问的数据。
- 确保每个请求（即使它们来自网络外围）都应用了安全策略。
- 应用额外的安全措施，如多因子身份验证、功能限制和强制合规性控制。
- 确保在应用程序生命周期的所有阶段仅基于白名单授予访问权限——换句话说，只有在显式允许的情况下才授予访问权限。
第一步到第三步通常是通过特定 ZTNA 工具的 API 来实现的，如 Perimeter81 或 CrowdStrike Zero Trust。
第 4 步通常通过 Auth0 或 Okta 等身份验证解决方案来实现。在大型组织中，Azure Active Directory 等企业身份识别服务起到了补充作用，或者直接取代了这些服务。
第 5 步是在应用程序层实现的——这是应用程序开发人员对零信任模型的主要贡献。
持续测试零信任需求仅仅实现上述的措施是不够的，我们还需要测试和验证应用程序是否正确地实现了身份验证、授权和强数据加密。这就要求：
在开发的早期阶段对代码进行静态分析，确保每个用户交互都适当调用了零信任和身份验证/授权组件。
在测试、UAT 和生产环境中对应用程序进行动态分析，并测试用户请求是否收到了适当的安全措施。
执行模糊测试和渗透测试，找出并消除开发生命周期中引入的漏洞——例如缺少身份验证或不正确的安全策略应用。
管理第三方风险零信任框架还需要对第三方开源和专有组件的安全性进行验证。开发人员来需要了解他们的项目中使用了哪些组件、它们带来了怎样的风险和漏洞，以及如何应用更新和修复。
软件组合分析（SCA）解决方案可用于获取软件项目中使用的开源组件的可见性，包括数千个传递性依赖项。对于每个开源库，这些工具都可以识别出其安全弱点，指出其代码质量问题，还可以警告组织对可能造成法律问题的许可进行限制。关于软件组合分析的更多信息可以参考这个指南。
第三方组件并不是唯一的风险来源。开发团队必须监视整个软件供应链，包括开发环境、持续集成（CI）系统、部署系统和 Staging 环境、容器存储库，以及将代码从开发阶段带到生产环境所涉及的任何其他元素。
安全性左移开发人员必须从一开始就将安全性纳入到他们的设计和代码库中。这是将隐式信任转变为显式身份验证、强身份识别和访问控制的最佳方式。这就是为什么转向 DevSecOps——开发人员、安全团队和运营人员之间的密切合作——是对实现零信任模型的支持。
DevSecOps 团队可以在软件交付生命周期的所有阶段实现零信任需求。内置在零信任框架中的应用程序可以在外围控制失效时保护敏感数据和功能。例如，即使防火墙、入侵防御系统（IPS）和数据丢失预防（DLP）工具出现配置错误、故障或被攻击者破坏，应用程序也会尽最大努力保护其资产。
为了确保应用程序和后端系统一直处于被保护和运行的状态，仍然需要在每次部署后进行持续的漏洞扫描。
总结现在开发人员的职责远远超过了以前——他们也被期望成为安全专家。企业开始意识到最能防止再次出现安全漏洞的人是具有安全意识的开发人员，他们从软件项目启动的第一天就开始实现安全编码实践。这是一个很重大的责任，但对开发人员来说也是一个很大的机会，他们可以在向客户交付价值的过程中扮演更核心的角色。
我希望本文能够帮助开发人员开发他们的安全智能模型，并帮他们带上“零信任眼镜”——通过零信任模型的透镜来观察代码和软件架构。这不仅可以帮助他们开发出更安全的应用程序，而且还可以提高他们“说到做到”的能力——在现代安全环境中有效地沟通和理解目标和策略。
作者简介：
Gilad David Maayan 是一名技术作家，他曾与 SAP、Imperva、Samsung NEXT、NetApp 和 Check Point 等 150 多家技术公司合作，为开发人员和 IT 领导层提供技术解决方案，产出技术和思想领导力内容。
原文链接：
What Developers Must Know About Zero Trust
