1 、微软为何要做零信任
微软一直致力于给用户带来更好的产品体验,在业务敏捷性上为用户增加价值。在安全能力上,微软也一直在不断迭代发展,不过整体而言,其安全能力主要还是作为Azure云平台、Windows操作系统、Office等产品的补充和完善,用于提升产品的附加值,暂时并未提供独立的安全产品或从服务的视角或思维切入安全领域。比如微软近期发布的Windows 365,Cloud PC云端操作系统,在安全防护上,微软基于“零信任”原则,凭借自身云端的能力,从初始设计上就确保了产品的安全性,当然其目的仍然是让用户对Windows 365产品感到安心。微软认为,零信任安全战略应该贯穿于组织的架构、技术选型、运营流程以及组织的整体文化和员工的思维方式。
在数字化转型时代,云服务,移动计算,物联网的应用越来越多,微软意识到一个企业如果仍然依赖于本地防火墙和VPN,仅从组织的物理位置决定安全策略,会缺乏对内部安全风险的可见性,无法及时提供端到端的安全覆盖,也就会对其产品的安全性带来风险和挑战。同时,攻击者开始利用钓鱼攻击、身份凭证窃取等一系列针对身份的攻击方式,突破传统网络安全边界,让安全工程师疲于奔命。因此,微软认为需要新的安全模型,该模型可以有效地适应现代IT环境的复杂性。在假定出现了信息泄露的情况下,只要有请求发起就需要进行验证,无论该请求出自何处,需要访问什么资源。这样可保护位于任何位置的用户、设备、应用程序和数据等资产,这就是微软使用零信任的初衷。零信任并非不信任一切事物,而是采用一种更加智慧、聪明的信任方式。因为,一切商业的逻辑——信息流转都不能否认信任的存在。没有信任,一切都无从谈起。
2、 微软网络安全参考架构MCRA
除了微软各产品中对安全的描述,微软的网络安全能力主要集中在微软网络安全参考架构 (Microsoft Cybersecurity Reference Architectures,MCRA) 中进行了介绍。在MCRA中描述了微软的网络安全能力是如何利用微软各类安全服务、安全产品与微软各平台(例如 Microsoft 365 和 Microsoft Azure)、第三方应用(例如 ServiceNow 和 Salesforce)和第三方平台(例如 Amazon Web Services (AWS) 以及 Google Cloud Platform (GCP))集成的。值得一提的是,整个MCRA都是以零信任原则进行设计。如下图所示:
从图中我们可以看出微软多年来一直在网络安全研究与开发方面进行了大量投资,以确保产品和服务的安全,并为其客户提供保护资产所需的能力。
整个微软网络安全能力架构采用了零信任原则进行设计,分别在身份与访问、安全运营、设备合规性管控、多云和跨云平台管理、软件即服务(SaaS)的云原生安全控制、物联网与运营管理,信息保护等功能上进行细化和落地。
此外,在MCRA中微软还对零信任基本概念,零信任快速现代化计划 (Rapid Modernization Plan,RaMP),安全运营和关键计划(例如,防御人为操作的勒索软件、保护特权访问和超越VPN 形态的用户访问等)的其他关键信息进行了介绍。
3、 微软零信任的二十年发展历史
我们已经能从MCRA中看出微软在安全领域的持续投入,如果追寻零信任在微软的发展历程,可以看到近20年的历史。一路走来,虽然零信任理念已经发展了许久,但直到最近才被主流逐渐认可和采用。
在这个过程中,微软理解零信任战略形成了两个主要的思想流派:网络派和身份派。
网络派——通过划分更小的网段,并在允许访问资源之前测量设备的信任度,来增强网络访问控制能力。虽然该方法富有吸引力,但复杂性较高。
身份派——Jericho论坛倡导的另一种方法,通过建立身份边界来实现资源访问,从网络为中心转移到了数据资产为中心。
微软在云转型过程中,融合了网络和身份模型两种技术方法实践零信任。
在这个过程中,微软将零信任安全模型应用于自身实践,微软员工访问企业技术资源和服务也需要零信任安全模型来进行隔离和限制。微软也是在几年前就开展了零信任的建设,涉及多方面的技术和多个部门,并将在未来几年持续投入,旨在未来两到三年内完全实现的零信任目标。
由于篇幅的原因,本文对微软零信任的分析解读主要针对身份和零信任用户访问(Identity and Zero Trust User Access)这一范围,并不包含MCRA中其它应用零信任原则所涉及的内容。
4 、微软零信任安全架构的基本概念
4.1零信任的指导原则
作为零信任起源Jericho论坛主办机构The Open Group所发布白皮书《零信任核心原则》(Zero Trust Core Principles)的参与方,微软认可Jericho论坛的零信任理念“从不信任,始终验证”。据此,微软提出了自己零信任原则:
- 进行显式验证(Verify Explicitly)
所有可用的数据访问点都必须进行身份验证和授权,包括用户身份识别,位置、设备的健康情况判断,服务或工作负载,数据分类分级标签和异常行为检测。
- 使用最小权限访问(Use Least Privileged Access)
通过及时(Just-in-time, JIT)和足够(Just-enough-access, JEA)的访问权限、基于风险的自适性策略以及数据保护来有效限制用户的访问,以帮助保护数据并且保障生产力。
- 假定数据泄露(Assume Breach)
需持续监测与感知网络、用户、设备和应用程序,来切分其访问控制权限,缩小数据泄露的波及范围并防止横向移动。同时还需验证所有会话,均为端对端加密,通过安全可视化的分析手段,进而驱动威胁探测和加强安全防护。
每个访问请求在授予访问之前都应进行完全身份验证、授权和加密。应用微分段和最小特权访问原则最大限度地减少了横向迁移。利用丰富的智能和分析进行检测并及时响应异常情况。
4.2 零信任访问控制机制
零信任访问机制的关键组成部分有三个:信息源、决策引擎、策略执行。
Ø 信息源:收集用户、设备的安全状态信息、风险信息、行为信息等。
Ø 决策引擎:基于信号源的信息对信任持续评估,做出访问策略的调整。
Ø 策略执行:对访问请求做出最终的操作决定。
4.3 零信任架构组成要素
微软认为无论何种用户或应用程序环境,都必须提供对其资源的安全访问能力。在允许访问前,都要评估用户的位置、角色定义、设备的运行状态、服务类型以及请求访问的数据类别等。并且,最终使用策略消息传递和策略自动实施的方法,在安全性与最佳用户体验之间找到平衡点。
零信任理念应扩展到整个数字资产,作为集成安全性理念和端到端策略,是对6个基本元素的安全防护:身份,设备,应用程序,数据,网络和基础设施,来实现零信任。这6个要素本身既是策略评估所需的信息源,也是实施控制的抓手,并且还是需要被保护的关键资源。每一项在零信任架构中所起到的作用如下:
Ø 身份
身份(无论是人员、设备、应用还是进程)是资源访问的入口,是零信任的基础。当身份尝试访问资源时,系统需要对其进行强身份验证,确保该身份是合理且合规的,同时保证遵循最小权限访问原则。
Ø 设备
身份获得对资源的访问权限,各类设备即会产生通信的数据流,无形中暴露了一个巨大的攻击面。为了降低设备风险,系统需要持续对其运行状况监控,维护其合规性。
Ø 应用
应用程序和API提供了数据访问接口。为了确保不同的身份在不同的应用中具备适当的访问权限,需要实现基于跨应用的实时分析,完成访问控制、异常行为监视、用户操作审核以及安全配置选项验证等。
Ø 数据
数据是安全的核心,应被分类、标记和加密,并基于这些属性有条件的访问。
Ø 网络
建立可信、可靠的网络链路是数据访问的重要环节。网络代理可以提供“可信通道”、端到端的数据加密、实时监控、分析,威胁防护,防止攻击者在网络中横向移动。
Ø 基础设施
建立安全的基础设施(无论是本地服务器、云端的虚拟机、容器还是微服务)是减少风险的有效措施。可以通过对基础设施的版本评估、实时访问权限配置,攻击/异常行为持续监测,恶意行为自动阻断与危险行为标记等方式,采取防护措施。
5 、微软零信任安全架构模型及相关组件
5.1抽象架构模型
零信任架构(Zero Trust Architecture,ZTA)是微软基于“零信任指导原则”的企业安全战略架构,核心是保护资源的安全性,通过细分资源访问控制防止非法访问和横向移动。简化的微软零信任架构如下图所示。
图中的访问主体是身份(Identities)和设备(Devices)。
访问资源是数据(Data)、应用(Apps)、基础架构(Infrastructure)——容器、微服务以及底层操作系统和固件等、网络(Network)。
架构的核心是安全策略执行点(Security Policy Enforcement),在其它微软零信任的架构图中也称为安全策略引擎(Security Policy Engine(s)),可提供实时策略评估。该引擎通过分析信号并应用组织策略和威胁情报来提供保护。在授予对数据、应用程序、基础设施和网络的访问权限之前,它可确保身份得到验证和验证,并且设备是安全的。此外,它提供持续地全面地应用可见性与分析以及自动化。
访问主体和访问资源这6个对象也是微软零信任安全架构的6个基本元素。如果再参考上述微软MCRA中功能组件与零信任架构组成的关系,可以发现架构中的每个组成都有相应的产品/服务/解决方案与之对应,分析如下:
Ø 身份安全组件:Azure Active Directory(Azure AD)、Microsoft Defender for Identity提供身份认证(MFAPasswordless)和保护。
Ø 设备安全组件:Microsoft Endpoint Manager、Microsoft Defender for Endpoint。
Ø 应用安全组件:Microsoft Cloud App Security、GitHub Advanced Security。
Ø 数据安全组件:Microsoft Information Protection完成数据治理,数据分级分类。
Ø 网络安全组件:Microsoft Azure提供的Azure AD App Proxy、Azure ExpressRoute。
Ø 基础设施安全组件:云安全态势管理的Azure Security Center、云原生的SOC(SIEM、SOAR、UEBA)Azure Sentinel。
Ø 核心的安全策略引擎Security Policy Enforcement对应的是:Azure AD Conditional Access,由它来形成统一安全管控评估决策。
5.2 零信任用户访问场景参考组件
在零信任用户访问场景下,用户通过Conditional Access来访问资源的组件概述如下。我们可以更加清晰地看到微软是如何通过其已有的产品/服务搭建起一个完整的零信任用户访问架构的。
第一步是收集身份、设备的安全态势信息(风险判定)。
身份信息通过Azure AD Identity Protection,Azure ATP和Cloud App Security结合微软自建的威胁情报库来监控和分析网络中的用户活动和信息。使用基于非对称密钥的用户身份验证(Passwordless,无密码方式)Hello for Business和Azure MFA完成多因子的用户鉴别。
设备信息通过Microsoft Defender ATP进行基于风险的漏洞管理和评估,判断是否是受控设备,是否满足设备合规性要求。再通过Intune完成设备管理。
第二步是内置于 Azure Active Directory的Conditional Access在收到初次访问请求后,会基于用户和设备的风险状况进行策略评估,调整已有的访问策略。当用户暂不满足信任要求时,会通知用户再次进行多因子认证。
第三步通过多因子认证后,授予用户相应的访问权限。访问应用、云基础设施、数据(文档)等。为了保护暂不支持零信任的资产,微软提供了Azure AD App Proxy来作为支撑。
在整个过程中是暗含持续地信息监测,但这对于用户来说,在访问过程中是全程无感的。
5.3 用于微软自身的零信任
在微软内部,当前主要确定了四个核心场景来帮助实现零信任。这些场景下的解决方案满足强身份认证、受控设备管理和设备健康监测、非受控设备的替代访问以及应用程序健康监测的安全性要求。核心场景有:
场景1:应用程序和服务可以做多因子身份认证和监测设备运行状况。
场景2:员工可以将设备注册到设备管理系统中,该系统会强制执行设备运行状况监测以控制其对公司资源的访问。
场景3:公司员工和商务客户在使用非受控设备时可以安全地访问公司资源。
场景4:对资源的访问仅限于执行指定功能所需的最小权限。
微软最初实施零信任的侧重点是整个企业(包括员工、合作伙伴和供应商)中使用的通用企业服务。其零信任实施针对的是微软员工在iOS、Android、MacOS和Windows等平台上日常使用的核心应用程序集(例如,Office应用程序、业务线的应用程序)。随着发展,重点已经扩展到企业内使用的所有应用程序。任何访问公司资源的所有受控或个人设备都必须通过设备管理系统进行管理。
下图是微软为实现零信任的简化零信任架构。包含用于设备管理和设备安全策略配置的 Intune、用于设备健康监测的Azure Active Directory (Azure AD) Access Conditions以及用于用户和设备清单的 Azure AD。
该系统通过将设备配置要求推送到受控设备,与Intune 配合使用。然后设备会生成一份安全程度声明,该声明存储在Azure AD中。当设备用户请求访问资源时,设备运行状况将作为与Azure AD进行身份鉴别交换的一部分来进行认证。
6、 微软零信任安全架构部署与成熟度模型
6.1 确定工作规划优先级
在具体零信任模型实践中,微软向用户建议首先确定零信任工作的优先级,以最大限度地提高安全投资回报 (ROI)。
1.调整组织战略和团队
企业组织的首要任务应该是让所有技术团队达成共识,并建立一个符合业务需求的单一细分策略。
2.与上一步同步开展,构建基于身份的边界
企业组织应采用多因子身份验证或无密码身份控制,以更好地保护身份安全。并迅速制定分阶段计划,以衡量(并强制执行)访问资源的用户和设备的信任度,最终鉴别所访问的每个资源的信任度。
微软对于安全边界的理解是,边界需求一直都存在,只是其形式随着时间而不断演变。从一开始的物理边界保护资产,到网络边界进行资产隔离,再到目前基于身份和访问管理,通过身份鉴别和授权来保护资产免受威胁。
3.细化网络边界(微分段)、网络安全策略
6.2 实施部署(能力要求)
对于企业组织后续创建、部署与微软产品和服务集成的零信任解决方案,以及在开发应用程序时遵循零信任最佳做法的指导。微软建议从身份安全入手,因为身份是零信任战略成功的核心。微软围绕身份,设备,应用,数据,基础设施,网络,可见性、自动化和业务流程编排几个方面(可以理解为微软的零信任支柱)的安全性目标要求,来评估部署采用何种微软的安全产品来实现零信任,这样才能够减少或防止数据因上述几方面的缺陷所导致的威胁和侵害。
6.2.1 身份
整个身份安全都依赖于微软的Azure Active Directory (AD)套件。基本安全性要求有以下三项:
1. 统一云端身份与本地身份
同步Azure AD与本地身份系统,维护统一权威身份源,并使用强身份认证。
2. 按条件访问策略,执行受限访问
分析用户、设备和位置等信息,以自动执行决策并强制实施资源的访问策略。
3. 通过分析提高可见性
通过在Azure中或使用所选的SIEM系统存储和分析来自Azure AD的日志。
改进性要求也有3:
1. 身份和访问权限通过身份治理进行管理。
2. 实时分析用户、设备、位置和行为,以确定风险并提供持续保护。
3. 集成来自其他安全解决方案的威胁信号,以改进检测、保护和响应。
6.2.2 设备
在实施端到端零信任框架保护设备时,基本安全性要求有:
1. 在云身份提供商处完成设备注册。
充分了解访问资源的所有设备和接入点的安全性。
2. 访问权限仅授予受云管理且合规的设备。
设置合规性要求以确保设备在授予访问权限之前满足最低安全要求。此外,为不合规的设备设置补丁规则。
3. 对自有或受控设备实施数据防泄漏 (DLP) 策略
改进性要求有:
1. 使用设备威胁检测监控设备风险。
使用统一的设备管理平台达到管理的一致性。并使用SIEM管理设备日志和事件。
2. 基于设备风险进行访问控制。
通过集成Microsoft Defender for Endpoint 或其它第三方数据,作为设备合规性策略和设备条件访问规则的信息源,来检测设备风险。
6.2.3 应用
在实施零信任方法来管理和监控应用程序时,基本安全性要求有:
1. 监测应用程序的活动,保持对其可见性。
微软会利用Microsoft Cloud App Security实现对应用或API的监测。
2. 监控影子IT系统的使用。
3. 通过实施策略自动保护敏感信息和活动。
创建策略检测云环境中的风险、违规行为或可疑数据点和活动。监控安全趋势、查看安全威胁并生成自定义报告和告警信息。
改进性要求:
1. 为所有应用部署自适应访问和会话控制。
确保所有应用程序都使用最低权限访问并进行持续验证。
2. 加强对网络威胁和流氓应用的防范。
利用Cloud App Security 的 UEBA 和机器学习 (ML) 功能,检测威胁并在整个云环境中运行高级威胁检测。调整异常检测的策略。
3. 评估云环境的安全状况
6.2.4 数据
在为数据实施端到端零信任框架时,基本性要求有:
1. 数据需加密
通过加密保护最敏感的数据,无论是静态或传输中,以限制对敏感的内容的访问。
2. 自动对数据进行打标、分级分类。
改进型要求:
1. 使用机器学习模型增强数据分级分类和打标。
2. 访问决策由云安全策略引擎管理。
3. 基于数据标签和内容检查的DLP策略防止数据泄漏。
6.2.5 基础设施
在实施端到端零信任框架来管理和监控的基础设施前,需满足最低要求。而在此之上才有基本性要求为:
1. 监控工作负载并就异常行为发出警报。
建立了用于监控和发出警报的规则
2. 每个工作负载都分配了一个应用程序标识,并做到配置和部署的一致性。
3. 对资源的访问使用即时JIT管理权限来加强防御。
改进性要求:
1. 阻止未经授权的基础设施部署,并发出告警信息。
2. 实现可跨基础设施的多维度可见性和基础设施基于角色的访问控制。
3. 针对每个基础设施实施分段。
6.2.6 网络
在实施端到端零信任框架来保护网络安全时,需达到的基本要求为:
1. 网络分段。
使用软件定义的微边界进行网络分段。
2. 威胁防护。
针对已知威胁,对HTTP/S流量的端点使用Azure Web 应用程序防火墙 (WAF)来进行防护。而对所有端点都在网络传输层,使用基于威胁情报的Azure防火墙进行过滤。
3. 加密用户到应用程序的内部流量。
改进目标:
1. 网络分段。
完全分布式的云微边界和更深的微分段。
2. 威胁防护。
基于机器学习的威胁防护和基于上下文的信息过滤。
3. 加密。
对所有流量都进行加密。
6.2.7 可见性、自动化和编排
在为可见性、自动化和编排实施端到端零信任框架时,基础性要求:
1. 启用Microsoft 威胁防护(MTP)来实现安全可见性。
2. 启用自动化的信息分析。
改进性目标:
1. 启用额外的保护和检测控制控件,提高安全可见性和协调响应的能力。
6.3 微软零信任成熟度模型
首先,微软认为“零信任”是一个持续进化的系统工程,而不是一蹴而就能达到某种最终结果的。为了实施完整的零信任模型,作为一个集成的安全理念和端到端战略贯穿于整个组织业务,并将其扩展到整个组织的资产。微软建议从问题开始,首先明确有哪些用户身份,需要访问哪些应用、服务和数据,以及如何访问;其次需要明确用户访问资源所需要满足的条件、属性、状态;系统如何通过安全控制策略来实现上述条件;最后如何确保能够执行这些策略。
微软利用帮助客户保护其企业组织以及实施自身零信任模型方面的经验,基于上述提到的6个基本元素,总结开发了以下成熟度模型,帮助企业组织评估自身零信任现状,制定实施零信任的方案计划,分阶段实施零信任模型。
同时,微软也开发了零信任评估工具来帮助用户确定在零信任实施过程中所处的阶段,并针对零信任的关键节点提供下一步实施计划和部署指南。
6.3.1 传统阶段
如果企业组织尚未开展零信任,通常处于以下状态:
- 具有静态规则和某些 SSO 的本地标识。
- 设备合规性、云环境和登录的可见性有限。
- 扁平的网络基础设施导致较大的风险暴露。
6.3.2 中期阶段
在此阶段,企业组织已经开始实施零信任,并在以下几个关键领域取得进展:
- 利用混合标识和定制化的访问策略限制对数据、应用和网络的访问。
- 设备已注册并符合IT安全策略。
- 开始细分网络,针对云威胁的保护措施已就位。
- 分析各类信息源用于评估用户行为并主动识别威胁。
6.3.3理想阶段
处于理想阶段的企业组织在安全性方面做出了很大改进:
- 已使用通过实时分析动态访问应用程序、工作负载、网络和数据的云端的身份体系。
- 数据访问的决策由云安全策略引擎管理,数据共享过程会被加密及追踪。
- 应用网络微分段和加密技术。
- 实施自动威胁检测和响应。
基于以上的模型阶段分割,微软认为一个企业可以对比自身的情况,规划安全路线图,平衡企业短期安全需求与长期安全战略间的一致性。
6.3.4 其它关键能力
基于能力成熟度模型,微软建议企业评估自身所处的零信任阶段,仍从身份、设备、应用程序、数据、基础结构和网络这6个要素进行建设,规划实施来提高企业的安全能力,以便更有效地全局部署零信任安全模型。同时,微软认为以下各项对于弥补重要的企业能力和资源差距都至关重要:
1. 强身份认证。确保强大的多重身份认证和会话风险检测作为访问策略的支柱,以最大限度地降低身份泄露的风险。
2. 基于策略的自适应访问。为资源定义可接受的访问策略,并借助统一的安全策略引擎实施这些策略,该引擎需要具备治理和洞察差异的能力。
3. 网络微分段。使用软件定义的微边界,从简单的集中式网络外围环境转向全面覆盖的分布式网络分段。
4. 自动化编排。使用自动告警和补救方面的工具和技术,以缩短企业应对攻击的响应时间(MTTR)。
5. 情报和人工智能。利用云智能和所有可用信息进行实时检测分析。
6. 数据分类和保护。发现、分类、保护和监控敏感数据,以最大限度地减少恶意或意外泄露的风险。
7、 结语
虽然企业最终都会部署集成零信任安全模型,在保护数字资产上发挥极大的功效,但微软认为零信任安全的实施是一个长期持续的过程。实施的每一个阶段都可以帮助企业降低风险,建立整个数字资产内的信任体系,但这需要分阶段,根据当前的零信任成熟度、可用资源和优先级,有的放矢,对相应领域进行投入和变革。同时确保每项短期和长期的投入都与当前业务需求保持一致。
参考文献与相关阅读:
1. 微软《零信任成熟度模型》
https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWJJdT
2. Implementing a Zero Trust security model at Microsoft
https://www.microsoft.com/en-us/insidetrack/implementing-a-zero-trust-security-model-at-microsoft#printpdf
3. Microsoft Security Zero Trust Adoption Report
https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWJJdU
4. The Open Group《零信任核心原则》白皮书
https://mp.weixin.qq.com/s/v3JrEkT20fXZoonjKnBDcQ
5. NIST《零信任架构》
https://mp.weixin.qq.com/s/uoFCnfBn_RCYubfK_MnhMA
本文来自安全内参
版权归原作者所有,如若转载,请注明出处:https://www.ciocso.com/article/12122.html