最终用户计算安全——特权访问控制

Posted 2022-09-20 dotNET跨平台

   本篇算是系列的第二篇，之前写了一篇关于勒索软件攻击的，坦白说写这样的文很费脑子，而且喜欢看的读者估计也不多…不过我觉得整理一下思路，对于通过最终用户计算产品或方案来提升组织安全还是有很大的意义的。所以一边喝着清茶吃着月饼，一边还是花了些时间画图写文，篇幅不短，希望您看完之后觉得有用，顺手点个赞～

   虽然聊到安全的话题比较晦涩，不是那么的酷炫，但随着IT技术渗透到工作生活的方方面面，安全其实和每个人又都息息相关。特别是IT从业者，不论是对自己设备和系统，还是对更广阔的数据中心基础架构和云平台，管理（监视、维护和操作）是我们每天都要对IT系统做的事情。与此同时，管理也引入了可能存在的最大的风险——因为执行这些工作需要对非常广泛的系统和应用进行必要的特权访问。而攻击者知道，一旦获得管理权限，就足以访问要针对的大多数甚至全部的信息数据。所以，管理的安全是安全领域中最为关键的部分之一。

   这也可以通过常见的攻击链得到印证。如上图，通过对最终用户行为、使用的端点设备以及对IoT（和OT）系统的攻击，大多都是为了后续攻击特权，而一旦拿到特权之后，就进入了造成损失的后续环节。

特权访问管理

   我们在聊管理安全的时候，基本上会有这样的共识，不能因为安全风险而因噎废食，放弃管理以及管理效率。而是应该寻求满足管理需求的同时，降低风险。也就是对特权访问进行有效的控制。具体做法可以包含三部分：

   限制范围——规定管理操作所需要的最小权限（JEA，Just Enough Access）。而不是由于管理角色一次对多个或所有系统拥有权限。

   限定时间——规定何时需要提供所需的特权（JIT，Just In Time）。而不是在所有时间内提供系统的权限。

   缓解剩余风险——结合预防和检测控制来降低风险。有非常多的最佳实践可以在各个环节提前预防和可被检测到风险。

   记忆起来其实很容易，跟“双规”的描述很像：规定时间，规定范围，缓解风险。那有哪些做法是比较推荐的呢？一起来看看特权访问管理里的建议。

   1、最大限度减少管理员数量

   每个管理账户都是潜在的攻击目标，因此减少管理权限账户数量能够有效的减小攻击面，降低整个组织面对的风险。人们总是会为需要访问资源谋求获得更高的管理权限，随着时间推移往往特权账户会不断增长。最佳做法是为涉及业务连续的系统分配两个账户，每一个特权账户的设置都应提供理由及使用审批流程，定期审核查看每个特权组成员身份和理由，及时关闭或禁用不需要的特权账户。

   2、管理特殊的特权账户

   确保所有的特权账户处于组织的管理策略之下。对于云服务，以Azure为例，不应使用类似MSA的账户，只有依托Azure AD等标识平台才能够确保组织的管理策略和政策法规遵从得到遵守。需要注意因为使用服务而建立的服务账户，以及为了项目建设和云平台迁移使用的供应商账户。服务账户往往绕开了需要定期更新的密码管理策略，因此需要加强隔离，限制其范围并做好全面的监控。供应商账户应在项目交付时即予以禁用，在确认项目上线之后进行删除。

   3、分离日常工作账户和特权账户

   大部分对特权账户的攻击，都是从获得日常工作账户信息开始的——因为日常工作账户难免使用工作效率工具，例如电子邮件、文件共享、访问网站等等。最基本的做法是工作账户不能用于特权访问。实际上，在Windows系统里，很久以前就提供了UAC用户访问控制来限制使用管理账号凭据直接对系统进行有风险的操作。当然，如果更进一步，在工作账户使用的系统上（例如桌面环境）根本不出现特权账户是更加安全的做法。这样即使工作账户所在系统被攻击，攻击者也无法获知特权账户信息或窃取特权账户凭据。基本的做法可以使用浏览器隐私模式打开特权访问、不保存特权账户密码、不使用特权账户在本机登录等等。更好的做法是利用VDI之类的远程访问系统，通过SSO实现特权访问，这样本地就不会有任何特权访问的信息。

   4、减少常设特权访问权限

   没有永远安全的系统。永久的特权会给攻击者更多基于时间的机会。尽管我们已经熟知通过限制登录尝试来阻止攻击者对标识的暴力破解，但仍不能避免攻击者通过其他途径获得提升权限的凭据。因此，如果系统能够支持JIT的特权授予，例如Azure AD的PIM或第三方IDM方案，应尽快启用，使得特权访问能够基于管理策略和审批工作流来获得。特权访问应尽可能的基于角色，而不应不受控制的粒度细化、出现大量自定义权限。应尽可能使用内置角色，并对特权账户进行生命周期管理。

   另一方面，启用MFA多因素认证是安全的良好做法。但应准备好紧急访问的特权账户机制，以避免正常管理访问方式不可用的情况发生。该账户不应与任何个体用户账户关联，并切不关联到任何个人信息（例如电话、分配到人的令牌或其他凭据），且应该启用强身份验证。应从基于电话的MFA和条件访问策略中排除至少一个紧急访问账户，避免电话系统或条件访问出现问题时仍可访问。同时，应安全的保存账户凭据，例如将密码分开保存到安全的位置（是不是想起了大片里发射核导弹要同时插入两把钥匙？），监视登录并审核日志，以及定期验证账户。

   5、增强特权账户验证

   对所有关键影响管理员启用无密码或多因子验证。密码已经无法可靠的保护账户，因此依次可以考虑使用无密码登录（比如生物验证、Windows Hello）、验证应用App和多因子验证来保护特权账户登录。

   基于零信任的管理策略，需对所有特权访问启用条件访问。这篇文章并不打算展开讨论零信任，但基于设备完整度要求以及指定工作网络发起访问等，都是常见的条件访问策略。可通过已经比较成熟的统一端点管理（UEM）系统和面向端点的防御（例如Defender ATP）等提供保障。

    6、使用特权访问工作站

   广义上应该叫做特权访问设备。鉴于很多生产力应用基于PC，所以看到的设备作为特权访问工作站会多一些。我们的主题是最终用户计算方面的特权访问控制，因此特权访问工作站（PAW，Privileged Access Workstation）会是接下来讨论的重点。

特权访问控制

   参照微软文档的建议，按照不同的安全需求，对组织数据资产的访问可以大致分为三类，下表显示了部分配置上的差异（更完整的可参考特权访问控制实现）。

配置文件	企业	专用	特权
端点管理	是	是	是
拒绝BYOD设备注册	不	是	是
应用端点管理安全基线	是	是	是
Defender for Endpoint	是*	是	是
通过Autopilot加入个人设备	是*	是*	不
限制为经批准的URL	允许大多数	允许大多数	拒绝默认值
删除管理员权限		是	是
应用程序执行限制		审核->强制	是
仅由端点管理安装应用		是	是

   简单来说这三种设备角色的定义可以如下简述：

   企业设备。该托管角色适用于家庭用户、小型企业用户、一般开发用户及希望维持最低安全标准的组织。对应的配置文件允许用户运行任何应用程序并浏览任何网站，但需要部署反恶意软件及终结点检测和响应（EDR，Endpoint Detect & Response）方案。它提供了一种安全的方式来处理数据，以及使用电子邮件和Web浏览等工作效率工具。

   专用设备。该托管角色表明组织向安全迈出重要一步，删除了自管理工作站的功能，并限制只能运行由授权管理员安装的那些应用程序（程序文件和用户配置文件）。专用设备用户需要一个更加受控的环境，同时仍兼顾简单地使用电子邮件和Wen浏览等工作效率工具，但不需要也不允许更改或调试设备的操作系统、安装更改驱动程序或类似功能、随意安装应用程序等。

   特权访问工作站。该托管角色为极其敏感所需最高安全配置设计。一旦使用特权访问的帐户遭到入侵，将对组织或生产产生重要影响。特权访问工作站（PAW）配置包括安全控制及策略。控制和测略限制了本地管理访问和生产效率工具，已将攻击面降低为仅执行敏感作业任务的绝对要求。因此PAW设备变得更难入侵（例如限制电子邮件和Web浏览，减少了钓鱼攻击的最常见向量）。PAW设备会启用凭据防护、设备防护、应用防护和攻击防护保护系统，并将所有本地存储都进行加密。除了特定允许的Web流量，其他的默认都将被拒绝。

   好了，我们现在有了纵向维度的区分，再来看看横向维度的区分。实际上大多组织从用户的端点设备访问应用和数据的时候，会有这么几个环节：用于发起访问的设备，用于登录和验证权限的帐户，为了避免直接访问或解决连接的中介，以及最终访问资源的界面。我们结合两个维度来看一看示意图。

   因此，对特权访问进行控制也同样需要考虑如下四个方面：

   设备——特权用户（如和IT管理员）登录的设备可以授予攻击者特权访问权限

   帐户——他们用于登录的帐户（通常通过窃取密码或会话令牌，但也可能发生其他攻击）

   中介——处理帐户凭据或其他敏感元素，如VPN、特权身份管理/特权访问管理（PIM/PAM）解决方案、应用程序代理、RDP/SSH跳板服务器等。

   接口——资源的用户界面也可以直接受到攻击，试图获得特权访问

   这样，就能够对不同访问需求在不同环节上的要求有着非常清晰的定义。为什么需要这样做呢？让我们看看从普通用户访问到特权访问之间可能造成的攻击路径。

   如上图，普通用户和特权帐户都需要访问组织的关键业务资产。如果没有针对特权帐户做额外的保护，一旦普通用户访问受到攻击，攻击就容易在多个方面横向扩展到特权帐户，例如基于普通用户帐户发起的对标识系统的攻击、基于普通用户帐户获得的权限提升等，最终导致更多更高价值目标的损失。

   可以看到，对于端到端四个主要环节（设备、帐户、中介和接口）进行特权访问防护，能够有效地防止对特权访问各环节的直接攻击，也能够有效地防止从普通用户攻击轻易的提升为具有特权访问的攻击。一方面特权访问保护增加了攻击难度和攻击成本，一方面也降低了威胁程度和风险损失。   

特权访问工作站

    我们已经从比较理论的角度讨论了对特权访问进行防护的重要性，也将关注的重点转移到了特权访问工作站（PAW）。可以看到，特权访问工作站的关注点与最终用户计算实际紧密相关。那么结合企业统一设备管理和安全的远程访问，对特权访问工作站的安全提升有多大的帮助呢？

   在开始讨论这一话题之前，我们需要明确一点，特权访问工作站从定义上，除了可以是硬件之外（适合进行端点管理），也可以是基于虚拟化的虚拟机（适合使用VDI等远程安全访问），还可以是两者结合的特权访问方式。

安全原则

   不如来看一个基于Workspace ONE体系的特权访问体系架构。在该体系架构中应用了如下的安全原则：

   减少攻击面;已考虑通过使用威胁检测和情报来减少攻击面。这是通过使用微分段和分布式防火墙保护边缘和应用，并使用条件访问策略根据用户、位置或设备状态提供安全控制来实现的。

   已应用最小特权原则，因此我们可以为用户提供对应用程序的访问权限，这些应用程序仅是执行其工作所需的。在完成必要的合规性检查和身份验证之前，每个用户都被标识为威胁。

   清洁源原则已应用于工作站。使用已知的操作系统 （OS） 内部版本、修补程序级别和控制应用程序集以及安全基准和策略，意味着我们正在降低访问应用程序的设备的安全风险。

   监控和威胁响应; 持续检查设备状态和漏洞扫描已包含在架构中，使用智能来提供对威胁的自动响应。

   应用程序安全级别用于定义应用程序访问权限。可以向用户提供一个完整的应用程序集，可以访问非常高/高安全性的应用程序或有限的应用程序集和中/低安全性应用程序。根据设备是托管设备还是非托管设备，用户可以访问完整或受限的应用程序集。

   缓解横向遍历已自始至终被设计出来;例如，有权访问低风险应用程序的用户无法横向遍历以访问高风险应用程序。这是通过使用不同的区域、不同的虚拟桌面/应用程序环境以及保护区域之间的流量来实现的。此原则允许将体系结构蓝图用于具有不同安全级别的不同层用户，从 IT 管理员到第三方访问权限。

   条件访问是体系结构的基本元素，用于初始连接中确定是否允许设备访问以及可以访问哪个级别的应用程序。

架构概述

   特权访问工作站的架构设计为使用区域来保护流量和访问，满足了一个区域的安全要求，流量才被允许进入下一区域。

   体系架构包含以下几个逻辑区域：

• 设备——类似前文的设备环节

• 入口区域——尽管没有直接对应，但这一区域会进行帐户的验证和授权

• 中间区域——类似前文的中介环节

• 安全区域——类似前文的接口环节

   我们来看一个非常常见的示例：远程的用户，通过传统上认为比较安全的VPN（入口区域）连接到组织内网，然后经过例如基于AD验证的网站等（安全区域）访问组织的应用和数据。可以发现，这种方式无法对特权访问进行有效的标识隔离，也无法防御一旦用户收到攻击之后对更高访问权限的威胁。

   经过疫情的考验，越来越多的组织开始支持远程工作方式或混合工作方式。通过应用虚拟桌面体系，实现了数据不落地的安全远程访问。在这个体系中，有效地阻止了从用户端点发起的攻击轻易进入组织网络。但这就足够吗？显然，这个架构还不足以阻止普通用户被攻陷后对特权访问的攻击。

   如果将特权访问进行明确的区分，就能有效的识别和隔离特权访问与普通访问了。那么如何自动识别基于不同设备、或者基于相同设备不同环境（例如网络位置）的访问呢？这就需要对访问进行条件控制。

   除了条件访问控制，还需要确保划分开的普通访问与特权访问之间无法轻易的“打通”，即确保网络上的隔离。

   对于基础架构本身，也需要提供足够的保护，推荐的做法是在不同目的的组件，例如连接组件、管理组件和业务组件之间也进行微分段隔离。这样可以避免对底层架构的攻击——以勒索攻击为例，现在不仅仅针对文档进行加密勒索，也出现了利用虚拟化层未修复漏洞或错误配置，对虚拟磁盘进行的加密攻击。

   现在，架构上已经进行了充分的加强以防御对特权访问的攻击。但对于更加严格的安全要求，可能仍然是不够的。例如，我们仍需要在中间区域和安全区域之间进行严格的隔离；除了纳管设备，仍需要对非纳管设备（例如BYOD）进行防御。

    因此，使用“两跳”的方式在远程访问到任务桌面之后，再通过远程访问运行应用，中间区域到安全区域的隔离就得以实现了。同时，如果需要的话也可以对非纳管设备进行更加精细化的管理，细分访问场景的条件及对应的访问安全策略。例如，当访问发起时如果处于组织内部网络，则允许使用基于证书（CBA）的验证，而访问如果处于外部网络，则要求使用多因素验证等。

   对于非纳管设备，除了常见的准入条件，还可基于第三方的安全检查（例如OPSWAT）作为准入控制。在实施了更为严格的网络隔离和特权访问划分之后，还可以在特权访问架构上增加其他的控制。例如，对于中间区域和安全区域使用不同的标识系统，利用类似活动目录域的单向信任进行标识隔离；也可以在条件访问控制环节使用异构标识或云标识（如Azure AD等），加上单点登录（SSO）来避免标识过早暴露；还可以集成基于云的智能服务和受信任网络以及病毒和威胁防范体系（如Carbon Black）来为端点防护和准入提供更加全面的保护，例如集成移动威胁检测（MTD）、端点检测及修复（EDR）等。

   好了，到现在为止，一个比较严格的特权访问架构初具雏形。我们再来回顾一下各区域的划分和防护手段的使用。

   在入口区域，可以针对访问的端点设备启用组件：统一端点管理、单次访问控制（MFA/OTA）和集成第三方标识系统（身份提供程序，IDP）。此外还可以增加 Workspace ONE智能服务聚合统一端点管理 UEM和访问控制 Access的数据，以及来自Carbon Black Cloud的数据，以评估用户和设备的风险数据、实现自动响应并通知条件访问。当然，如果不包括本地部署，也可以考虑集成Azure AD的条件访问、多因素验证等云服务等。

   除了启用多因素验证、基于网络范围的安全策略、基于证书的身份验证（CBA，支持可回退或不可回退移动单点登录）、基于设备合规性（任何平台）甚至基于风险评分的策略，还可为身份验证会话确定时间长度，即以前我们提到的 JIT，以便限制特权访问凭据不受限制使用。

   在中间区域，组织可以为最为敏感的应用和数据启用仅纳管设备通过托管虚拟桌面进行访问，也可以将普通办公访问也置于虚拟桌面保护之下，而通过基于身份验证和条件访问控制来区别普通访问和特权访问。此时，特权资源和非特权资源通过各自独立的虚拟桌面和虚拟应用集合进行区分。

   通过可驻留在DMZ的统一访问网关（UAG），访问可大幅缩减范围，例如减少需要暴露的IP和端口，利用UAG充当L7的代理等。从而大幅降低暴露的受攻击范围。

   而基于虚拟桌面、虚拟应用的安全远程访问体系，可为构筑在传统安全架构上的业务系统提供更加贴近现代移动互联网环境的安全管理能力。基于身份的分布式防火墙以及无代理病毒防护，以及基于标准化和快速制备的能力，能够确保这一访问架构的安全性和快速自愈能力。

   在安全区域，可以如同中间区域一样，使用标准化，强制实施最小安全特权原则的安全远程访问方式。同时，利用统一访问网关可实现基于第三方SAML的访问控制和基于True SSO的单点登录。用户使用特权访问的时候甚至可以不必使用传统基于密码的登录，实现“无密码”的访问安全。

   同时，如果对安全区的访问架构使用专门的活动目录，在攻击者尝试进行标识攻击时会更加难以获得特权标识。这可以通过为虚拟桌面和虚拟应用配置双向信任、单向信任甚至配置不受信任的域来实现。

   如同中间区域一样，安全区域也可以通过动态环境管理（DEM）组件实现更加复杂的，基于用户角色、访问设备和位置的条件策略。这些策略可以实现强制的应用程序拒绝和允许列表（黑白名单）、使用标准用户帐户但在需要时为特定应用或进程提供集中控制的权限提升以及在会话间保留Windows系统和应用程序的配置信息等。

   除了我们介绍的借助Workspace ONE的这个架构例子，基于Microsoft或者第三方的方案或方案组合也可以参考这样的架构模型，进行特权访问控制的构筑和实现。不论特权访问工作站是否基于Windows操作系统，基于Windows系统的传统和现代管理方式，特权访问实现的参考配置选项都可以作为特权访问工作站管理的标准和依据。

传统访问模型与现代访问模型

   关于特权访问控制的讨论已近尾声。在最后还想花一点时间介绍传统与现代企业访问模型的差异。

   以微软的架构为例，传统访问模型是基于AD活动目录层模型的。零层（T0）是整个架构最为核心的基础，包括例如AD的域控制器（DC）、证书服务（CA）、网络服务（DNS等）等。一层（T1）包括成员服务器，即加入到域进行统一安全和配置管理的各类服务器，如应用服务、数据服务等。二层（T2）是各种服务端点，例如PC、打印机、各种终端等等。 

   很显然，在移动化互联网化的背景下，依靠持续可靠的、到活动目录的网络连接，以及来自互联网的各种环境的访问是传统访问模型难以支持的。所以需要将传统模型转进为现代模型。这包括以下的几个变化：

• 第 0 层范围扩展

  第 0 层扩展为控制平面并解决访问控制的所有方面，包括网络（其中唯一/最佳访问控制选项），例如旧版 OT 选项

• 第 1 层拆分

  为了提高清晰度和可操作性，第 1 层现在分为以下几个方面：

  • 管理平面 - 适用于企业范围的 IT 管理函数

  • 数据/工作负荷平面 – 用于每工作负荷管理，有时由 IT 人员执行，有时由业务部门执行此拆分可确保重点用于保护具有高内部业务价值但技术控制有限的业务关键系统和管理角色。此外，这种拆分更适合开发人员和 DevOps 模型，而过于注重经典基础结构角色。

• 第 2 层拆分为了确保应用程序访问以及各种合作伙伴和客户模型的覆盖范围，第 2 层分为以下几个方面：

  • 用户访问 - 包括所有 B2B、B2C 和公共访问方案

  • 应用访问 - 以适应 API 访问路径和生成的攻击面    

   如上图，虽然是一张比较平面的示意图，请尝试将各个平面层叠起来观察。完成传统访问模型到现代访问模型的这一转变之后，可以看到核心的数据/工作负荷平面被管理平面所管理，并处于扩展的控制平面的控制下。而对资产的访问被分为用户访问、应用访问及特权访问，从而实现了面向更复杂、更多种类的组织数据和应用的安全访问保护。

   至此，关于最终用户计算领域的特权访问控制的讨论就告一段落了。感谢您花费时间看完，如果文中涉及的架构建议和方案最佳时间能够给您提升特权访问安全提供参考，就算没有白写这么一大篇了。

参考链接：

[1] 特权访问管理：https://docs.microsoft.com/zh-cn/security/compass/critical-impact-accounts?WT.mc_id=Azure-MVP-33253

[2] 特权访问控制实现：https://docs.microsoft.com/zh-cn/security/compass/privileged-access-deployment?WT.mc_id=Azure-MVP-33253

[3] 特权访问—设备：https://docs.microsoft.com/security/compass/privileged-access-devices?WT.mc_id=Azure-MVP-33253

[4] 特权访问—帐户：https://docs.microsoft.com/security/compass/privileged-access-accounts?WT.mc_id=Azure-MVP-33253

[5] 特权访问—中介：https://docs.microsoft.com/zh-cn/security/compass/privileged-access-intermediaries?WT.mc_id=Azure-MVP-33253

[6] 特权访问—接口：https://docs.microsoft.com/security/compass/privileged-access-interfaces?WT.mc_id=Azure-MVP-33253

[7] 特权访问保护：https://docs.microsoft.com/zh-cn/security/compass/overview?WT.mc_id=Azure-MVP-33253

[8] 特权访问体系架构：https://techzone.vmware.com/resource/privileged-access-workstation

[9] 特权访问实现：https://docs.microsoft.com/zh-cn/security/compass/privileged-access-deployment?WT.mc_id=Azure-MVP-33253

[10] 企业访问：https://docs.microsoft.com/zh-cn/security/compass/privileged-access-access-model?WT.mc_id=Azure-MVP-33253

(不想复制粘贴链接还可以点击阅读原文，博客文章链接正常）