特权访问

特权访问管理可建立控制措施，以保护云环境中的管理凭据和高影响作。 与具有静态管理员组的传统本地模型不同，新式云平台需要动态、有时间限制的权限分配、持续监视和实时访问，以解决快速基础结构更改和扩展的攻击面，包括凭据盗窃、特权升级和横向移动。 实施这些控制的组织强制实施最低特权和零信任原则，同时保持运营敏捷性，而忽视这些措施的组织将面临未检测到的凭据泄露和不受限制的管理访问，从而导致租户范围的违规。

下面是 Privileged Access 安全域的四个核心支柱。

保护用户标识： 通过集中式标识管理、强大的多重身份验证、生命周期管理、特权访问工作站和紧急访问规划，为所有用户帐户（尤其是特权帐户）建立安全性。

相关控件：

• IM-1：使用集中式标识和身份验证系统
• IM-2：保护标识和身份验证系统
• IM-5：使用单一登录（SSO）进行应用程序访问
• IM-6：使用强身份验证控制
• IM-7：根据条件限制资源访问

保护应用程序和机密： 通过自动化服务器/服务身份验证安全地管理非人类标识，以及 API 密钥和证书的安全机密管理。

相关控件：

• IM-3：安全地自动管理应用程序标识
• IM-4：对服务器和服务进行身份验证
• IM-8：限制凭据和机密的公开

安全访问： 通过时间限制权限、条件访问策略以及云提供商支持的受控外部访问强制实施最低特权和足够管理。

相关控件：

• PA-1：分离和限制特权/管理用户
• PA-2：避免对用户帐户和权限进行长期访问
• PA-3：管理标识和权利生命周期
• PA-5：设置紧急访问
• PA-6：使用特权访问工作站
• PA-7：遵循足够的管理（最低特权）原则
• PA-8：确定云提供商支持的访问过程

监视和管理： 通过定期访问评审、用户权限对帐、异常情况检测和审核日志记录保持持续监督，以确保适当的权限和及时吊销。

相关控件：

• PA-4：定期查看和协调用户访问
• LT-2：为标识和访问管理启用威胁检测

PA-1：隔离并限制高特权/管理员用户

Azure Policy： 请参阅 Azure 内置策略定义：PA-1。

安全原则

确定所有高业务影响帐户，并限制跨控制平面、管理平面和数据工作负荷平面的特权管理帐户数，以最大程度地减少受攻击凭据的攻击面和爆炸半径。

待缓解风险

• 从超特权帐户进行未经授权的访问 攻击者利用具有过多权限的高特权帐户来获得对关键云资源（例如管理控制台、API 或敏感数据存储）的未经授权的访问。 如果没有分离，单个遭到入侵的管理员帐户可以向攻击者提供无限制的访问权限，以修改 IAM 策略、部署恶意工作负荷或跨整个租户外泄数据。
• 通过泄露的管理凭据提升权限 攻击者利用泄露的特权凭据升级访问，从而控制云租户或关键基础结构。 在管理帐户不隔离的环境中，可以使用被盗的凭据来操纵角色分配、创建新的特权帐户或禁用安全控制，从而导致租户范围的安全漏洞。
• 从过时或未受监视的特权帐户进行持久访问 攻击者利用过时或不受监视的特权帐户来维护持久访问，在初始入侵后逃避检测。 在角色更改或项目完成后保持活动状态的管理员帐户为攻击者提供长期访问以调用 API 或修改资源，从而增加长期违规的风险。

MITRE ATT&CK

• 初始访问 （TA0001） 有效帐户：云帐户（T1078.004）：破坏高特权帐户以向云控制台或 API 进行身份验证，并使用被盗管理员凭据访问关键资源。
• 特权提升 （TA0004） 滥用提升控制机制：云基础结构（T1548.005）：利用无范围限制的特权帐户通过修改 IAM 策略提升访问权限，从而获得对租户范围的控制。
• 持久性（TA0003） 帐户操控：附加云角色（T1098.001）：更改特权帐户以添加持久角色，以维持对云资源的长期访问。

PA-1.1：限制和限制Microsoft Entra 中的高特权/管理用户

限制高特权管理帐户可以防止未经授权的租户范围访问，并减少由于凭据泄露而可能导致的影响范围。 具有过度全局管理员的组织面临违规风险增加，攻击者可以纵 IAM 策略、部署恶意工作负荷或跨所有资源外泄数据。 将这些帐户仅限于关键人员使用，实施最小权限原则并减少攻击面。

对云标识管理角色实施以下限制：

• 确定关键内置角色 Microsoft Entra ID 中最重要的 内置角色 是全局管理员和特权角色管理员，因为分配给这些角色的用户可以委托管理员角色，直接或间接地读取和修改云环境中的每个资源。

• 评估自定义角色权限 查看标识管理系统中的自定义角色，了解需要根据业务需求 管理的 特权权限，并应用与内置特权角色相同的限制。

• 将限制扩展到云标识系统之外 将本地标识系统、安全工具和系统管理工具中的特权帐户限制为对业务关键资产（例如 Active Directory 域控制器、安全监视系统和配置管理工具）的管理访问权限，因为这些管理系统遭到入侵，攻击者能够将这些帐户武器化，以便横向移动到云资源。

PA-1.2: 在 Azure 资源级别上限制和约束高权限/管理用户

限制资源级别的特权角色可防止未经授权的访问云资源，并跨订阅和资源组强制实施最低特权。 订阅范围内过多的所有者或参与者分配，能让攻击者在初始入侵后操纵资源、修改安全控制或提升权限。 限制这些分配可减少影响范围，并确保管理访问权限与运营责任一致。

对云资源级管理角色应用以下限制：

• 限制关键的内置资源角色 Azure 具有授予广泛权限 的内置角色 （所有者授予完全访问权限，包括角色分配）;参与者授予完整的资源管理;用户访问管理员启用用户访问管理），需要与租户级特权角色相同的限制。

• 管理自定义资源角色 使用从业务需求分配的特权权限在资源级别查看和限制自定义角色，确保它们不会无意中通过权限组合授予过多的访问权限。

• 控制计费和订阅管理角色 对于具有企业协议的客户，可以限制 Azure 成本管理和计费管理角色（帐户所有者、企业管理员、部门管理员），因为他们可以直接或间接管理订阅、创建/删除订阅以及管理其他管理员。

实现示例

挑战： 金融服务组织发现跨标识和资源层的过度特权访问： Microsoft Entra ID 中的 47 个全局管理员帐户（大多数未使用 6 个月以上）和 89 个在 Azure 订阅范围内具有所有者角色的用户，创建大规模攻击面并违反最低特权原则。

Solution:

• 审核和减少 Entra 特权角色： 对所有全局管理员和特权角色管理员分配进行全面审核，确定每个帐户的业务理由，并将 47 个全局管理员减少到 8 个符合运营需求。
• 在 Entra 中实现特定于角色的分配： 根据实际作业功能将用户从全局管理员转换到特定角色（用户管理员、安全管理员、合规性管理员），Microsoft Entra 内置角色强制实施精细权限。
• 减少 Azure 订阅范围分配： 审核 了 Azure 基于角色的访问控制（RBAC） 级别的所有所有者和参与者角色分配，通过根据团队职责将角色范围限定为特定资源组，将订阅范围所有者分配从 89 减少到 12。
• 实现资源组范围： 将开发团队从订阅级参与者过渡到资源组级参与者或特定内置角色（虚拟机参与者、存储帐户参与者）与实际需求相匹配。
• 建立统一治理： 创建审批工作流，要求执行团队和安全团队在 Entra 和 Azure 资源级别对新的特权角色分配进行审批，并进行季度访问评审，以及对于超过批准范围的分配提供自动警报。

结果： 组织大幅减少了标识和资源层的特权帐户攻击面，消除了过时的管理访问权限，并建立了可持续治理，从而防止在租户和订阅级别出现特权爬行。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5 AC-2（1）、AC-2（7）、AC-5、AC-6（1）、AC-6（5）
• PCI-DSS v4 7.2.2、7.2.4、8.2.2
• CIS 控制 v8.1 5.4、6.7、6.8
• NIST CSF v2.0 PR.AC-4、PR.AA-1
• ISO 27001：2022 A.5.15、A.5.18、A.8.2
• SOC 2 CC6.1、CC6.2

PA-2：避免对用户帐户和权限进行长期访问

Azure Policy： 请参阅 Azure 内置策略定义：PA-2。

安全原则

实现按需特权访问机制，分配临时的、有时间限制的权限，而不是长期有效的特权，以防止恶意用户或未经授权的用户在凭据泄露或内部人员行为后利用持续启用的管理访问。

待缓解风险

• 从永久性特权帐户进行未经授权的访问 高特权角色使攻击者能够滥用泄露的凭据，以便未经授权的访问云资源，例如调用 API 来泄露数据或部署恶意工作负荷，利用始终开启的权限，而无需临时限制。
• 通过泄露的凭据提升权限 具有持续提升角色的已泄露帐户允许攻击者通过修改 IAM 策略（例如分配租户范围的管理角色）来提升特权，从而利用缺少有限的访问权限来控制订阅或资源。
• 从过时的访问中长期暴露 任务完成后未撤销的角色会创建延长的暴露窗口，允许攻击者利用过时凭据进行未经授权的访问，例如，由于遗忘或权限未管理，从存储帐户中提取数据。

MITRE ATT&CK

• 初始访问 （TA0001） 有效帐户：云帐户（T1078.004）：破坏具有高特权角色的帐户，以向云管理控制台或 API 进行身份验证，使用持久性凭据访问资源，且不受时间限制。
• 特权提升 （TA0004） 滥用提升控制机制：云基础结构（T1548.005）：利用持久性特权角色通过修改 IAM 策略来升级访问权限，利用始终启用的权限来获得对订阅的未经授权的控制。
• 持久性（TA0003） 账户操作：附加云角色（T1098.001）：通过向被入侵账户添加高级权限角色，修改角色分配以保持持续访问，并利用访问时间缺乏限制。

PA-2.1：使用即时控制进行 Azure 资源访问

适时特权访问可防止导致凭据泄露后未经授权访问的持久管理权限。 具有站立特权角色的组织面临扩展的暴露窗口，攻击者可以在没有时间限制的情况下利用数据外泄、特权提升或横向移动的始终开启权限。 实现 JIT 访问可确保权限自动过期、限制爆破半径和减少攻击面。

通过以下方法启用实时访问：

• 部署特权身份管理 使用 Microsoft Entra Privileged Identity Management（PIM） 启用对 Azure 资源和 Microsoft Entra ID 的实时（JIT）特权访问，使用户能够获得临时权限来执行特权任务。这些权限是自动过期的，从而防止权限过期后出现未经授权的访问，并在发现可疑活动时生成安全警报。

• 配置符合条件的角色分配 管理员通过 PIM 将符合条件的角色分配给用户或组，指定谁可以请求特权角色并定义激活要求，包括审批工作流、MFA 要求和时限持续时间（通常为 1-8 小时）。

• 建立激活工作流 需要特权访问时，用户通过 Azure 门户或 PIM API 请求角色激活，提供理由和时间范围，审批者根据策略审查请求，并授予或拒绝访问权限，而 PIM 记录所有作以进行审核。

• 实现自动过期 访问在激活期结束时自动过期，或者用户可以在任务完成时提前手动停用，确保特权权限不会在作需求之外保持活动状态。

• 为虚拟机访问启用 JIT 将 Azure Bastion 与 来自 Microsoft Defender for Cloud 的 JIT VM 访问权限一起使用，将入站流量限制到敏感虚拟机的管理端口，仅在用户需要时授予访问权限，并在时间过期时自动撤销访问权限。

实现示例

挑战 一家全球零售公司在订阅范围内拥有 156 个具有固定所有者和贡献者角色的用户，尽管管理需求不频繁，该访问仍保持 24/7 活跃状态。

Solution

• 为 Azure 资源实现 PIM 将所有永久所有者和参与者角色分配转换为 PIM 中的合格角色，要求用户仅在执行具有 4 小时时间限制激活的管理任务时激活角色。
• 配置审批工作流 为需要资源所有者和安全团队审批的所有者角色激活建立多阶段审批，并对所有特权访问请求执行自动 MFA 和理由要求。
• 启用 JIT VM 访问 使用 Azure Bastion 部署，并结合云防护的 JIT 控制来限制对生产虚拟机的 RDP/SSH 访问，只有通过已批准的时间限制请求才能访问，从而消除持久性管理端口的暴露风险。

结果 组织消除了持久性特权访问，从长期管理权限中大幅减少攻击面，并建立了自动过期机制，防止忘记提升的访问权限。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5 AC-2（1）、AC-5、AC-6（2）、AC-6（5）、AC-16
• PCI-DSS v4 7.2.2、7.2.5、8.2.8
• CIS 控制 v8.1 5.4 和 6.8
• NIST CSF v2.0 PR.AC-4、PR.AA-1
• ISO 27001：2022 A.5.15、A.5.18、A.8.2
• SOC 2 CC6.1、CC6.3

PA-3：管理身份和权限生命周期

安全原则

使用自动化过程或技术控制来管理完整的标识和访问生命周期，包括请求、评审、审批、预配和取消预配，确保权限与业务需求保持一致，并在不再需要时撤销。

待缓解风险

• 由于权限过多而导致未经授权的访问 标识授予的访问权限比所需权限多，违反了最低特权，并增加了攻击面。
• 来自非托管帐户的陈旧或孤立的访问 权限在不再需要后仍然保留，或者用户离开后帐户仍保持活跃，从而可能被利用。
• 来自配置不当或未受监视的访问的内部威胁 授权用户因配置不当的策略或缺乏监督而误用权限，包括绕过审批流程。
• 不符合法规标准 未能强制实施最低特权、访问审核或及时取消预配，导致违反 GDPR、HIPAA、SOC 2 或 ISO 27001 等标准。
• 访问管理中的人为错误 手动流程导致权限授予不正确、取消预配被忽略或审批链配置错误。
• 缺乏可审核性和可追溯性 缺少适当的日志记录和文档，妨碍跟踪访问请求、审批或预配，从而延迟违规检测。

MITRE ATT&CK

• 初始访问（TA0001） 利用有效帐户（T1078.004），利用已泄露或过时的云凭据向 API 或管理控制台进行身份验证，从而允许对云资源进行未经授权的访问。
• 特权提升（TA0004） 通过利用配置错误的 RBAC 策略或过度的权限从资源组角色中指派高级角色，以滥用权限提升控制机制（T1548.005）。
• 持久性（TA0003） 通过修改 IAM 策略或禁用 MFA 来操控帐户（T1098.001），嵌入持久访问，允许攻击者保留对云资源的未经授权的控制。
• 使用超特权帐户从云存储（T1530）访问数据，以枚举和检索存储存储桶或数据库的敏感数据（TA0010）。
• 防御逃避（TA0005） 通过禁用云审核日志记录或使用高特权帐户进行监视来损害防御（T1562.001），从而隐藏恶意作，例如资源修改。

PA-3.1：管理标识和权限生命周期

自动标识生命周期管理可防止孤立的帐户、未调用的权限，以及角色更改或员工离职后保留的过多访问权限。 依赖于手动访问管理的组织面临延迟的取消预配、不一致的审批流程和缺乏可审核性，从而造成安全漏洞，其中未经授权的用户利用过时凭据进行数据外泄或特权提升。 实现自动化工作流可确保通过一致的请求、审批、预配和过期流程，访问符合当前业务需求。

通过以下方法建立自动化标识和访问生命周期管理：

• 规划访问管理目标和范围 通过标识需要访问管理的 Azure 资源组来定义访问需求，包括特定角色（例如所有者、参与者）和用户或工作负荷标识，从而为治理和审批工作流建立边界。

• 分配职责 指定全局管理员、标识治理管理员或目录所有者来管理 权利管理和 访问包，委派给审阅和批准特定 Azure 资源组的访问请求的资源所有者或项目经理。

• 为访问请求工作流设置权利管理 在 Microsoft Entra 管理中心中创建目录，以组织相关资源和访问包，添加具有其角色（例如参与者、读者）的特定 Azure 资源组作为目录资源，然后定义访问包，指定用户可以请求哪些 Azure 资源组角色以及访问持续时间和审批要求。

• 配置访问策略 允许用户通过 Microsoft Entra My Access 门户请求访问权限，使用指定的审批者（例如资源所有者、经理）设置单阶段或多阶段审批工作流，为自动吊销定义访问到期日期或时间限制访问权限，以及为请求提交、审批、拒绝和即将到期配置警报。

• 处理和查看访问请求 用户通过“我的访问”门户提交对 Azure 资源组角色的访问请求，触发已配置的工作流，以通知指定的审批者和日志请求详细信息，而审批者根据用户角色、请求的访问权限和理由评估请求，并在批准或拒绝具有记录的理由之前请求澄清。

• 自动预配和取消预配访问权限 批准后，Microsoft Entra 会自动为具有直接访问权限的指定资源组向用户分配请求的 Azure 角色，并在每个访问包策略达到预定义到期日期时强制自动吊销，同时允许管理员或资源所有者在过期前更改用户角色或项目时手动删除访问权限。

• 检测和调整权限大小过大 使用 Microsoft Entra 权限管理 可识别跨多云基础结构分配给用户和工作负荷标识的未使用和过多的权限，自动调整权限大小并持续监视以防止特权爬行。

实现示例

挑战 一家拥有 40 个国家/地区的 8,500 名员工的跨国公司在手动访问预配方面苦苦挣扎，每个请求需要 3-5 个工作日，从而造成运营延迟，并累积了 450 多个来自有主动特权访问权限的离职员工的孤立帐户。

Solution

• 实现权利管理 已部署 Microsoft Entra ID 权利管理 ，其中包含所有 Azure 资源组的访问包、为请求建立自动化工作流、多阶段审批和具有自动过期时间的访问。
• 配置生命周期工作流 创建了自动化 加入者/调动者/离职者 工作流，触发新员工的自动预配、角色更改时的访问权限更新，并在终止时立即移除预配，包括从所有访问包和特权组中删除。
• 部署权限管理 实现了持续监视，可检测跨多云基础结构未使用的权限、自动调整过度预配的角色大小，并生成需要评审的特权警报。

结果 组织将访问预配时间从 3-5 天缩短到 2 小时以下，通过自动取消预配消除了所有孤立帐户，并通过完整的审批线索文档实现了 100 个% 访问请求可审核性。

严重性级别

应该有。

控件映射

• NIST SP 800-53 Rev.5 AC-2、AC-2（1）、AC-2（3）、AC-2（4）、IA-4
• PCI-DSS v4 7.2.2、7.2.4、8.1.3、8.1.4
• CIS 控件 v8.1 5.1 、5.2、5.3、6.1
• NIST CSF v2.0 PR.AA-3，PR.AC-1，PR.AC-4
• ISO 27001：2022 A.5.15、A.5.16、A.5.17、A.5.18
• SOC 2 CC6.1、CC6.2、CC6.3

PA-4：定期查看和协调用户访问

Azure Policy： 请参阅 Azure 内置策略定义：PA-4。

安全原则

定期审核特权帐户权利，以验证访问权限是否与授权管理功能保持一致，确保遵守最低特权原则。

待缓解风险

• 由于权限过多而导致未经授权的访问 标识授予的访问权限比所需权限多，违反了最低特权，并增加了攻击面。
• 来自非托管帐户的陈旧或孤立的访问 权限在不再需要后仍然保留，或者用户离开后帐户仍保持活跃，从而可能被利用。
• 来自配置不当或未受监视的访问的内部威胁 授权用户因配置不当的策略或缺乏监督而误用权限，包括绕过审批流程。
• 不符合法规标准 未能强制实施最低特权、访问审核或及时取消预配，导致违反 GDPR、HIPAA、SOC 2 或 ISO 27001 等标准。
• 访问管理中的人为错误 手动流程导致权限授予不正确、取消预配被忽略或审批链配置错误。
• 缺乏可审核性和可追溯性 缺少适当的日志记录和文档，妨碍跟踪访问请求、审批或预配，从而延迟违规检测。

MITRE ATT&CK

• 初始访问（TA0001） 利用有效帐户（T1078.004），利用已泄露或过时的云凭据（例如超特权服务帐户）向 API 或管理控制台进行身份验证，从而允许对云资源进行未经授权的访问，而无需触发警报。
• 权限提升（TA0004） 通过利用配置错误的 RBAC 策略或过度的权限，通过从资源组角色分配诸如租户范围管理访问权限等提升角色来滥用提升控制机制（T1548.005）。
• 持久性（TA0003） 通过修改 IAM 策略或禁用 MFA 来操控账户（T1098.001），嵌入持久访问，使攻击者能够对云资源（如存储或计算）进行未经授权的控制。
• 数据泄漏（TA0010） 使用超特权帐户从云存储（T1530）中枚举并检索存储桶或数据库中的敏感数据，利用未撤销或验证不当的权限。
• 防御逃避（TA0005） 通过使用高特权帐户禁用云审核日志或监控来削弱防御（T1562.001），从而掩盖诸如资源修改或数据访问等恶意活动。

PA-4.1：定期查看和协调用户访问

查看Microsoft Azure 中的所有特权帐户和访问权限，包括 Azure 租户、Azure 服务、虚拟机（VM）/基础结构即服务（IaaS）、CI/CD 流程和企业管理和安全工具。

使用 Microsoft Entra ID 访问评审 来评估 Microsoft Entra 角色、Azure 资源访问角色、组成员身份以及对企业应用程序的访问权限。 Microsoft Entra ID 报告提供日志，用于标识失效的帐户或指定时间段内未使用的帐户。

此外，可以将Microsoft Entra Privileged Identity Management （PIM）配置为在为特定角色创建过多的管理员帐户时发送警报，并检测过时或配置错误的管理员帐户。

规划访问评审范围和目标 根据安全要求和法规需求确定哪些 Azure 资源（例如订阅、资源组、VM）和Microsoft Entra 角色（例如全局管理员、用户管理员）需要评审、建立评审频率（例如每月、季度）。

分配评审职责 指定资源所有者、安全团队或角色管理员进行评审，确保审阅者在 PIM 中具有适当的权限。

在 Microsoft Entra PIM 中设置访问评审 通过选择要评审的特定Microsoft Entra 角色、指定审阅者（个人、组所有者或自我评审）以及设置评审参数（包括持续时间和重复）来创建 Entra 角色的访问评审。 对于 Azure 资源，请选择订阅或资源组，选择 Azure 资源角色（例如所有者、参与者）进行评估、分配审阅者，以及配置评审设置，包括开始日期/结束日期和重复周期。

进行访问评审 审阅者根据作业职能或项目需求评估用户是否仍需要分配Microsoft Entra 角色，评估用户是否需要继续访问特定的 Azure 资源和角色，并验证是否符合当前职责，并要求用户或审阅者提供维护访问权限的理由，以确保记录决策。

根据评审结果采取行动，通过撤销不再需要角色或访问权限的用户来删除不必要的访问权限，同时利用 Microsoft Entra ID 报告和 PIM，识别出近期无活动的帐户，并删除其角色或将其停用。 还可以利用 PIM 功能增强对帐，检测过多的角色分配，并自动执行预定义计划的持续评审。

实现示例

挑战 一家拥有 650 个特权帐户的科技公司在年度审核中发现，89 个帐户（14 个%）在 180 天内未使用，尽管用户更改为非管理角色，但 34 个帐户仍保留了提升的权限。

Solution

• 实施季度访问评审 已为具有季度定期计划的所有 Azure 订阅和 Entra 角色部署Microsoft Entra PIM 访问评审 ，将资源所有者分配为主要审阅者和安全团队作为辅助审阅者进行监督。
• 启用自动检测 为过多的角色分配（>8 名全局管理员）和 90 天未使用的帐户配置 PIM 警报，并与 Microsoft Sentinel 集成，以便实时通知安全运营中心。
• 建立修正工作流 创建了标准化响应过程，要求审阅者提供维护访问权限的理由或立即撤销不必要的权限，并自动上报过度评审到治理团队。

结果 组织识别并删除了 89 个过时帐户和适当大小的 34 个超预配帐户，将全局管理员计数从 12 个减少到 6 个，并实现了 100 个% 季度审查完成率，并记录了理由。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5 AC-2（3）、AC-2（7）、AC-6（7）、IA-4
• PCI-DSS v4 7.2.4、8.1.4、8.2.6
• CIS 控件 v8.1 5.3 、5.4、6.2
• NIST CSF v2.0 PR.AA-3, PR.AC-6, DE.CM-3
• ISO 27001：2022 A.5.18、A.8.2、A.8.3
• SOC 2 CC6.1、CC6.2、CC6.3

PA-5：设置紧急访问

安全原则

设置紧急访问，以确保在紧急情况下不会意外被锁定在您的关键云基础设施之外。 应很少使用紧急访问帐户，如果遭到入侵，则可能会非常有害，但当需要这些帐户时，其可用性对于方案至关重要。

待缓解风险

• 云租户管理中的管理锁定 因为 MFA 故障、联合身份验证中断或账户泄露/删除导致所有特权账户被封锁而无法访问云租户，进而无法更新 IAM 策略或管理资源。
• 未经授权访问高特权帐户 弱安全凭据或对紧急帐户的不受限制的访问使攻击者能够向云管理控制台或 API 进行身份验证，从而促进特权提升或数据外泄。
• 通过滥用的紧急访问进行内部威胁 绕过标准控制的紧急帐户被授权人员用于非紧急任务，风险是凭据泄露或未经授权的访问。
• 紧急访问缺乏可审核性 紧急帐户活动的日志记录或监视不足可防止检测未经授权的使用，从而延迟事件响应。
• 未经测试的紧急帐户的操作失败 未经过测试、且凭据过时或 IAM 绑定配置错误的紧急账户在危机期间无法正常运作，阻碍访问恢复并加剧锁定问题。

MITRE ATT&CK

• 初始访问 （TA0001） - 有效帐户：云帐户（T1078.004） 利用特权较高的紧急访问帐户对云管理控制台或 API 进行身份验证，利用不安全的存储凭据。
• 特权提升 （TA0004） - 滥用提升控制机制：云基础结构（T1548.005） 利用具有过多 IAM 角色的超特权紧急帐户升级访问，允许攻击者修改策略或分配租户级管理权限。
• 持久性 （TA0003） - 帐户操作：额外的云凭据（T1098.001） 修改紧急帐户配置（例如添加持久性角色或禁用 MFA），以维护未经授权的访问。
• 防御逃避（TA0005）- 损害防御：禁用或修改云日志（T1562.008） 使用紧急帐户在云环境中禁用审核日志或监控，从而隐藏恶意行为。
• 凭据访问 （TA0006） - 窃取应用程序访问令牌 （T1528） 窃取不安全存储的紧急帐户凭据以向云服务进行身份验证。

PA-5.1：设置紧急访问

紧急访问帐户（“break-glass”帐户）防止在 MFA 故障、联合身份验证中断或管理帐户被泄露时发生完全的管理权限锁定。 如果没有这些帐户，组织可能会在正常身份验证路径失败时失去租户访问权限。 实施紧急访问可确保业务连续性，同时通过受控凭据管理、监视和测试维护安全性。

通过以下结构化方法建立紧急访问帐户：

• 创建紧急访问帐户 使用描述性名称（例如 EmergencyAccess01、BreakGlass02）配置至少两个仅限云的帐户（未联合），并在 Microsoft Entra ID 中具有全局管理员角色，这些帐户明确标识其用途，确保帐户未分配给特定个人，并且专用于紧急方案。

• 使用双重控制保护凭据 生成至少 32 个字符的强随机生成的密码（配置为永不过期），通过将凭据拆分为存储在不同安全物理位置（例如不同站点上的防火隔离器）中的多个部分来实现双重控制机制，这些密码只能由经授权的 C 级管理人员或安全领导访问，记录需要多人批准的检索过程。

• 配置条件访问排除项 从所有 条件访问策略 和 MFA 要求中排除至少一个紧急帐户，以确保在服务中断期间访问，同时（可选）使用存储在安全位置的 FIDO2 安全密钥 保护第二个帐户，确保凭据多样性防范单点身份验证失败。

• 启用全面的监视和警报 配置 Azure Monitor 或 Microsoft Sentinel 以分析 Microsoft Entra ID 登录和审核日志、创建针对任何紧急帐户身份验证或配置更改触发的实时警报（电子邮件和短信），并建立需要立即安全团队通知和所有紧急帐户使用情况的理由文档的事件响应过程。

• 建立测试和维护程序。每季度测试紧急帐户访问权限，以验证其功能；每隔 90 天更新凭据，或在影响授权用户的人员变动后立即更新凭据；对授权管理员进行培训，包括关于紧急访问程序的使用，包括凭据检索和事件记录；维护书面化的运行手册，记录紧急访问的完整过程，以确保合规性和操作准备状态。

实现示例

挑战 一家跨国金融服务组织经历了影响其混合标识基础结构的联合中断，发现他们没有Microsoft Entra ID 的正常运行的紧急访问路径。 所有 15 名全局管理员都依赖于联合身份验证，使组织在事件发生期间完全被锁定，要求Microsoft支持升级，在停机 6 小时后重新获得访问权限。

Solution

• 创建紧急访问帐户 在 Microsoft Entra ID 中预配了两个仅限云的紧急访问帐户（EmergencyAccess01@contoso.onmicrosoft.com， BreakGlass02@contoso.onmicrosoft.com该帐户具有永久的全局管理员角色分配），确保帐户未从本地 Active Directory 联合或同步，以消除对联合基础结构的依赖。

• 通过双重控制实现无密码身份验证 使用 FIDO2 密钥身份验证 和 BreakGlass02 配置了 EmergencyAccess01，并配置了 基于证书的凭据多样性身份验证 ，将 FIDO2 安全密钥存储在总部和灾难恢复站点的两个单独的防火隔离箱中，而证书私钥保留在硬件安全模块上，但只有 C 级管理人员才能访问，且具有紧急响应过程中记录的双重授权要求。

• 从战略上配置条件访问排除项 为 EmergencyAccess01 创建了命名位置排除策略，使其免受所有条件访问策略（包括 MFA 要求）的豁免，而 BreakGlass02 仍受网络钓鱼防护 MFA 要求的约束，提供平衡的安全方法，确保在任何身份验证服务中断期间至少一个帐户保证访问。

• 为紧急帐户活动部署 Azure Monitor 警报 配置 了 Log Analytics 工作区 ，使用自定义警报规则查询 SigninLogs 以获取紧急帐户对象 ID，触发关键严重性警报（Sev 0），并立即向安全运营中心、CISO 和 IT 主管发出短信通知，并在紧急帐户进行身份验证时使用警报查询： SigninLogs | project UserId | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff" 每 5 分钟评估一次。

• 建立季度验证和测试流程，创建了记录的季度演练计划，要求指定的安全团队成员从安全存储中检索凭据，使用紧急帐户进行身份验证，通过Microsoft Graph API查询用户列表，记录在事件日志中，并立即通知安全团队以触发事后审查，从而验证警报功能和凭据可访问性。凭据轮换每90天进行一次，且在影响授权人员变动后立即执行。

结果 组织成功建立了能在整体联盟基础设施故障中仍能存活的弹性紧急访问能力，在 5 分钟内通过自动警报检测到 100% 的紧急帐户身份验证，成功执行了四次季度验证演练，平均凭据检索时间为 12 分钟，并在 12 个月内保持零未经授权使用紧急帐户的情况，并对所有测试活动提供了全面的审核线索。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5 AC-2、CP-2、CP-9、IR-4、IA-4
• PCI-DSS v4 8.2.8、8.6.1、12.10.1
• CIS 控件 v8.1 5.4 、6.5、17.9
• NIST CSF v2.0 PR.IP-10, RS.CO-3, RS.RP-1
• ISO 27001：2022 A.5.24、A.5.29、A.17.1
• SOC 2 CC6.1、CC7.4、CC9.1

PA-6：使用特权访问解决方案

安全原则

安全隔离的特权访问解决方案对于敏感角色（如管理员、开发人员和关键服务操作员）的安全性至关重要。

待缓解风险

• 通过恶意软件或网络钓鱼在管理工作站上攻陷凭据 攻击者在未加固的工作站上部署键盘记录器、网络钓鱼页或内存抓取恶意软件，以捕获特权凭据，比如 API 令牌或密码，从而允许未经授权地访问云管理控制台或 API。 例如，模拟云门户登录页或非 PAW 设备上的特洛伊木马的网络钓鱼攻击可以提取管理员凭据，允许攻击者调用 API 调用、修改 IAM 策略或外泄数据。
• 通过不安全的工作站配置提升权限 攻击者利用本地管理员权限、未修补的漏洞或管理工作站上的弱应用程序控制来提升权限，操控 IAM 角色或访问令牌。 例如，没有 AppLocker 策略的工作站可能会允许恶意脚本执行，使攻击者能够从用户级别提升到租户范围的管理访问权限，从而损害虚拟机或存储等资源。
• 通过不安全的远程连接进行未经授权的访问 攻击者以公开的 RDP/SSH 终结点或不安全的协议为目标，以拦截管理员会话或执行暴力攻击，从而访问云资源。 通过公共 IP 进行直接连接可能会发生会话劫持或凭据填充，从而允许攻击者执行未经授权的命令或从虚拟机或数据库提取数据。
• 非 PAW 设备上的内部威胁因滥用特权访问授权管理员滥用固定特权访问或绕过控制，使用个人设备，这样做会有凭据暴露给恶意软件或者违反策略的风险。 例如，在 BYOD 设备上执行特权任务的管理员可能会无意中将凭据泄露给间谍软件，从而启用未经授权的 IAM 更改或数据访问，违反了最低特权原则。
• 管理工作站上的恶意软件传播和持久性 攻击者在未加固的工作站上部署持久性恶意软件（如勒索软件或后门），以泄露数据或转向云资源。 在没有受限执行的情况下，泄露的管理员设备可能会使恶意软件操控 IAM 配置或部署恶意工作负载，利用过时的软件来维持长期访问。
• 特权工作站活动的可审核性和可跟踪性不足 工作站上的特权会话或 IAM作的日志记录不足可防止检测未经授权的访问，从而延迟事件响应。 不受监视的管理员活动（如控制台登录或 API 调用）由于日志保留期有限（例如 30 天），妨碍了取证分析，使攻击者能够在云环境中未被检测到地运行。

MITRE ATT&CK

• 凭据访问 （TA0006） 通过密钥记录器、网络钓鱼或内存窃取恶意软件（T1552.001）从未加固的管理工作站窃取凭据（例如密码、API令牌），使用捕获的凭据对云管理控制台或API进行认证，以便进行未经授权的访问。
• 特权提升（TA0004） 利用非 PAW 设备上的本地管理员权限或未修补的漏洞来提升特权（T1068），操控 IAM 角色或访问令牌以获得租户级别的管理访问权限，例如修改云资源策略。
• 初始访问（TA0001） 针对云资源上暴露的RDP/SSH终结点进行暴力破解或会话拦截（T1133），使用通过不安全的远程连接获得的已妥协管理员会话来执行命令或访问敏感数据。
• 持久性 （TA0003） 通过在未分片工作站（T1547.001）上部署恶意软件或后门来建立持久访问，从而保持对管理员设备的控制，以重复访问云 IAM 配置或部署恶意工作负荷。
• 防御逃避（TA0005） 通过在非 PAW 设备上利用受损的管理员帐户禁用云日志或监控服务（T1562.008），通过隐藏审核记录来掩盖未经授权的 IAM 变更或资源操作。

PA-6.1：使用特权访问解决方案

特权访问工作站（PAWs）提供强化的隔离环境，防止凭据被盗，防止管理设备上的恶意软件、网络钓鱼和未经授权的访问。 如果没有 PAW，使用标准工作站或个人设备的管理员会将特权凭据公开给 keylogger、内存擦除恶意软件和会话劫持，从而使攻击者能够入侵云租户。 通过设备加固、强身份验证和安全远程访问来实现特权访问工作站（PAW），可确保管理操作免受基于终端的攻击。

通过以下结构化方法部署特权访问工作站：

预配和配置强化的 PAW 设备 将专用 Windows 设备部署为 PAW（物理工作站或 Azure VM），将其注册 到 Microsoft Intune 进行集中管理，应用 Microsoft Defender for Endpoint 安全基线 以删除本地管理员权限、使用 BitLocker 强制实施设备加密以及配置 Windows Defender 应用程序控制（WDAC） 或 AppLocker 策略 仅将应用程序执行限制为已批准的管理工具（Azure 门户、PowerShell、Azure CLI、Visual Studio Code）。

实现设备符合性和应用程序控制 配置 Intune 设备配置文件，强制实施安全策略，包括禁用的本地管理员帐户、非活动 5 分钟后强制锁定、阻止可移动存储设备和受限Microsoft应用商店安装、部署 公司门户应用 以实现托管应用程序交付，确保只有批准的工具到达 PAW，同时通过 Microsoft Defender for Cloud Apps 集成阻止个人应用程序和消费者云服务。

启用威胁检测和监视 将所有 PAW 上的 Microsoft Defender for Endpoint 集成，用于实时行为监视，以检测凭据盗窃尝试、可疑进程执行和恶意软件活动、配置 攻击面减少规则 ，阻止 Office 宏、基于脚本的恶意软件和凭据转储工具，以及自动警报触发安全团队通知，以获取需要立即调查的高严重性威胁。

强制实施标识和访问控制 创建 Microsoft Entra 条件访问策略，要求对所有特权帐户在从 PAW 访问 Azure 门户和 Microsoft 365 时，通过抗网络钓鱼的多因素认证（FIDO2 安全密钥或基于证书的认证）进行认证。实施基于设备的筛选器，独占限制访问仅限于 Entra 加入或符合 Intune 要求的 PAW，同时阻止 BYOD 情况。启用 Microsoft Entra Privileged Identity Management (PIM) 的实时角色激活，要求在授予时间限制的管理权限之前进行审批和提供理由。

为云资源部署安全远程访问 在虚拟网络中将 Azure Bastion 预配为完全平台托管的 PaaS 服务，以便通过 Web 浏览器通过 Web 浏览器直接通过 Azure VM 建立 RDP/SSH 连接，而无需公开公共 IP，将 SSH 私钥存储为 Azure Key Vault 中的机密，其中基于 Entra ID 的访问策略将密钥使用限制为授权的 PAW 设备，配置 网络安全组（NSG） 通过源 IP 范围和协议限制 Bastion 流量，并与 Azure Monitor 集成，以针对配置更改或未经授权的访问尝试发出警报。

建立 PAW 使用策略和培训 记录所有特权作（包括 Azure 门户访问、PowerShell 管理和基础结构更改）的强制 PAW 使用要求，禁止通过技术控制和策略强制实施从非 PAW 设备使用特权帐户、培训 PAW 访问过程、批准的工具使用情况和事件报告协议，并进行季度合规性评审，以验证遵守仅限 PAW 的管理访问权限。

实现示例

挑战 医疗保健组织发现 23 名管理员使用具有不受限制的本地管理员权限的个人笔记本电脑和标准公司工作站来管理包含受保护运行状况信息的生产 Azure 资源，在不使用终结点保护、应用程序控制或活动监视的情况下向恶意软件和网络钓鱼攻击公开特权凭据，从而创建 HIPAA 合规性风险，并启用潜在的凭据盗窃。

Solution

• 部署专用 PAW 基础结构 预配了 25 个专用 Windows 11 企业版设备，这些设备作为 PAWs 在 Microsoft Intune 中注册，采用严格的设备符合性策略。应用 Microsoft Defender for Endpoint 安全基线，移除所有本地管理员权限，启用 BitLocker 全磁盘加密及 TPM 保护，配置 Windows Defender 应用程序控制（WDAC），仅将批准的管理工具（Azure 门户、PowerShell 7、Azure CLI、Visual Studio Code、Microsoft远程桌面）加入允许列表，阻止所有其他应用程序执行，包含 Office 生产力套件和 Web 浏览器，但应用程序防护模式下的 Edge 除外。

• 实现全面的设备强化 配置的 Intune 设备配置文件强制实施安全策略，包括强制使用 Windows Hello 身份验证的 5 分钟屏幕锁定、阻止使用 USB 存储设备和外部媒体、禁用摄像头和麦克风访问、预防本地凭据缓存、部署用于托管应用交付的公司门户，将安装限制为已批准的管理工具，并集成 Microsoft Defender for Cloud Apps，通过网络流量检查阻止访问消费者云存储服务（Dropbox、个人 OneDrive、Gmail）。

• 启用高级威胁防护 在所有 PAW 上集成 Microsoft Defender for Endpoint，通过攻击面减少规则阻止 Office 宏、脚本威胁、凭证窃取工具（Mimikatz）和可疑进程注入，并配置终端检测和响应（EDR），针对高严重性威胁实现自动调查和修正。启用防篡改功能以防止安全控制禁用，建立安全运营中心（SOC），并针对关键 PAW 安全事件设置 15 分钟响应的 SLA 警报。

• 强制实施防钓鱼身份验证 创建了 Microsoft Entra 条件访问策略，要求对从 PAWs 访问 Azure 门户和 Microsoft 365 的所有特权帐户进行 FIDO2 安全密钥身份验证，实现了设备符合性筛选器，仅允许以符合安全状况的 Intune 托管 PAW 进行访问，阻止了旧式身份验证协议（基本身份验证、POP3、IMAP），启用了需要审批工作流的 Microsoft Entra PIM，并且为所有者和参与者角色设置了 4 小时限时激活，强制提供理由文档。

• 部署安全的远程访问基础结构 在所有生产虚拟网络中预配了 Azure Bastion 的标准 SKU，支持基于浏览器的 RDP/SSH 访问 Azure 虚拟机而无需公开公共 IP，将 SSH 私钥使用具有 HSM 保护的 Azure Key Vault Premium 和基于 Entra ID 的访问策略存储起来，限制密钥使用仅限于特定的 PAW 设备标识，配置 NSG 限制从公司网络和 PAW 子网上授权源 IP 范围到 Bastion 子网的流量，并通过警报规则集成 Azure Monitor，以在 Bastion 配置更改、未经授权的访问尝试或会话超过 8 小时时触发警报。

• 建立强制性 PAW 使用治理 记录并强制实施零容忍政策，禁止通过条件访问阻止从非 PAW 设备使用特权帐户，通过实践研讨会培训 23 名管理员，涵盖 PAW 访问程序、FIDO2 密钥使用、批准的工具限制和事件报告协议，通过季度合规性审核和自动化的 Intune 报告验证 100% 的特权操作均来自合规的 PAW，并为政策违规行为建立需立即调查和纠正的高级别升级措施。

结果 组织消除了 23 个不安全的管理设备中的凭据泄露风险，在 6 个月内实现了 100% 的 PAW 特权访问采用，跨 25 台设备实现零安全基线违规，成功阻止了由 Defender for Endpoint 检测到的 12 次网络钓鱼尝试，通过自动阻止凭据盗窃工具以及防钓鱼身份验证和设备强化，特权帐户入侵风险减少了 87%，并实现了针对所有特权操作的管理访问控制的 HIPAA 合规性，提供了完整的审核线索。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5 AC-2、AC-3、AC-6、IA-2、IA-5、IA-8、SI-4
• PCI-DSS v4 2.2.1、7.2.5、8.2.8、8.4.2
• CIS 控件 v8.1 4.1 、5.4、6.3、6.4
• NIST CSF v2.0 PR.AC-7, PR.PT-3, DE.CM-1
• ISO 27001：2022 A.5.15、A.8.5、A.8.16
• SOC 2 CC6.1、CC6.6、CC6.7

PA-7：遵循足够的管理（最低特权）原则

Azure Policy： 请参阅 Azure 内置策略定义：PA-7。

安全原则

遵循适度管理（最低特权）原则，在细粒度级别管理权限。 使用基于角色的访问控制（RBAC）等功能通过角色分配管理资源访问。

待缓解风险

• 由于权限过多而导致未经授权的访问 攻击者利用权限超出其角色所需的权限的超特权帐户，从而允许对敏感云资源（如存储帐户、虚拟机或数据库）进行未经授权的访问。 在云环境中，权限过多通常由广泛的角色分配（例如，在订阅范围内授予所有者而不是参与者）导致，允许攻击者执行数据外泄、资源删除或 IAM 策略修改等作。 例如，对存储帐户具有不必要的写入访问权限的用户可以提取机密数据或部署恶意内容，并放大攻击面。
• 权限升级，来自配置错误的角色分配 攻击者利用配置不当或过度宽松的角色分配来提升特权，从而对云资源或整个租户进行未经授权的控制。 如果没有精细的 RBAC 策略，具有看似低特权角色（例如资源组范围内的读取者）的用户可能会利用继承的权限或角色配置错误来为自己分配更高的特权，例如订阅级别的所有者。 这可能会导致整个租户系统的妥协，使攻击者能够篡改 IAM 配置、部署恶意负载或禁用安全控制措施。
• 来自不受限制访问的内部威胁 授权用户有意或无意地滥用广泛的访问权限来执行未经授权的操作，例如修改关键资源或访问敏感数据。 在云平台中，具有授予过多权限（例如跨多个资源组的贡献者）角色的内部人员可以更改虚拟机配置、从数据库中提取数据或中断服务，而不会被检测到。 缺乏最小权限的实施使得此类行动能够绕过标准监督，从而增加数据泄露或操作中断的风险。
• 跨云资源的横向移动 攻击者利用超特权帐户横向跨云资源移动，在破坏单个帐户后访问不相关的系统或数据。 在云租户中，被攻陷的账户如果拥有授予对多个资源组（例如在订阅范围内担任参与者）访问权限的角色，攻击者就可以从一个资源（例如虚拟机）转向另一个资源（例如存储帐户），从而扩大他们的影响。 当角色分配缺少特定于资源的范围时，这种风险会加剧，使攻击者能够枚举和利用互连的资源。

MITRE ATT&CK

• 初始访问 （TA0001） 有效帐户：云帐户（T1078.004）：通过破坏具有广泛 RBAC 角色（例如订阅范围内的所有者）的过度授权帐户，来向云管理控制台或 API 进行身份验证，使攻击者能够在未被检测的情况下访问敏感资源（如存储帐户或虚拟机）。
• 特权提升 （TA0004） 滥用提升控制机制：云基础结构（T1548.005）：利用权限过大的错误配置 RBAC 角色来提升特权，例如修改 IAM 策略以从资源组范围分配租户范围的管理角色，从而授予对云资源的未经授权的控制。
• 持久性（TA0003） 帐户操控：额外云角色（T1098.001）：修改 RBAC 角色分配，将持续性高特权角色添加到已泄露的帐户中，使攻击者能够通过未经授权的角色绑定维护对云资源（如数据库或计算实例）的访问权限。
• 外泄 （TA0010） 来自云存储的数据（T1530）：使用具有过度宽松 RBAC 角色的帐户从云存储帐户访问和提取敏感数据，使攻击者能够枚举和下载存储存储桶中的机密文件，因为权限范围不明确。
• 防御逃避（TA0005） 损害防御：禁用或修改云日志（T1562.008）：使用具有过多权限的 RBAC 帐户禁用审计日志记录或监控服务，通过抑制云原生审计追踪隐藏恶意活动，例如资源修改或 IAM 更改。

PA-7.1：使用 Azure RBAC 管理 Azure 资源访问

使用 Azure 基于角色的访问控制（Azure RBAC）通过角色分配管理 Azure 资源访问。 通过 RBAC，您可以为用户、群组、服务主体和托管身份分配角色。 某些资源有预定义的内置角色，可以通过 Azure CLI、Azure PowerShell 和 Azure 门户等工具来列出或查询这些角色。

通过 Azure RBAC 分配给资源的权限应始终限于角色所需的权限。 有限特权将补充 Microsoft Entra ID 特权身份管理 (PIM) 的按需 (JIT) 方法，这些特权应定期进行审查。 如果需要，还可以使用 PIM 定义时间限制分配，这是角色分配中的条件，用户只能在指定的开始日期和结束日期内激活角色。

注意：使用 Azure 内置角色分配权限，并仅在需要时创建自定义角色。

实现示例

挑战 一家软件公司在订阅范围内授予了 145 名开发人员所有者角色，为方便起见，提供了过多的权限，允许数据库删除、网络安全组修改和 IAM 策略更改远远超出开发需求。

Solution

• 实现最小权限 RBAC 我们分析了实际的权限需求，并将开发人员重新分配到具有特定范围和精细权限的自定义角色，以限制他们对资源组的访问（应用服务的读取/写入权限，Key Vault 为只读，禁止访问网络或 IAM 资源）。
• 为有限时间任务部署 PIM 配置了 Microsoft Entra PIM 以满足对提升访问权限的需求，要求开发人员在 4 小时的时间窗口内，经过理由和批准后激活贡献者角色，将现有的所有者常规分配替换为按需访问。
• 建立 RBAC 治理 使用 PIM 访问评审创建对所有角色分配的自动每月评审，要求资源所有者证明继续访问是正当的，并自动标记比安全组评审的资源组范围更广的角色分配。

结果 组织将 145 个现有所有者分配减少到 0，限制开发人员对 23 个作用域资源组的访问权限，其中自定义角色平均具有 8 个权限，而之前的所有者权限超过 100 个，并在第一季度通过受限访问阻止了意外删除的 3 个生产环境。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5 AC-2、AC-3、AC-5、AC-6、AC-6（1）、AC-6（2）
• PCI-DSS v4 7.2.1、7.2.2、7.2.3、8.2.2
• CIS 控件 v8.1 3.3、5.4、6.1、6.8
• NIST CSF v2.0 PR.AC-4、PR.AC-7、PR.AA-1
• ISO 27001：2022 A.5.15、A.5.18、A.8.2、A.8.3
• SOC 2 CC6.1、CC6.3、CC6.7

PA-8：确定云提供商支持的访问过程

安全原则

建立审批流程和访问路径，用于通过安全通道请求和批准供应商支持请求和临时访问数据。

待缓解风险

• 通过云提供商支持进行未经授权的数据访问 云提供商的风险支持人员在没有明确同意的情况下访问客户数据存储，在诊断或维护作期间可能会利用特权凭据。
• 通过供应商访问进行内部威胁利用 恶意或疏忽云供应商内部人员可能滥用特权访问权限，从而导致客户租户内的数据泄露或未经授权的修改。
• 不透明访问操作缺乏可见性 对数据访问事件缺乏可见性，阻碍可追溯性和问责性，这可能会侵蚀信任并违反审核要求。
• 权限提升过多 云提供商的风险支持工程师获得过于广泛的访问范围，超过了最低特权原则，并增加了云资源中的攻击面。
• 法规不符合审核要求 不受控制的数据访问违反了数据保护框架（例如 GDPR、HIPAA、CCPA），因此由于访问治理不力而面临不合规处罚的风险。
• 支持作期间的数据泄露 在支持活动（如远程桌面会话或日志分析）期间可能泄露或不当处理敏感数据，而无需客户治理。

MITRE ATT&CK

• 有效帐户 （T1078.004） 利用泄露或滥用的云帐户凭据（例如支持人员凭据）访问云环境中的客户数据，绕过标准身份验证控制。
• 帐户操作（T1098.001） 向云身份服务或应用程序添加未经授权的凭据（如密钥或令牌），以便在支持操作期间持续访问客户资源。
• 暴力破解 （T1110） 反复尝试猜测云帐户凭据（例如支持工程师使用的凭据），以在故障排除活动期间未经授权访问客户数据。
• 窃取应用程序访问令牌 （T1528） 窃取支持人员用于与客户云资源交互的访问令牌，从而促进租户内未经授权的数据访问或横向移动。
• OS 凭据转储 （T1003.006） 内部人员通过临时提升的访问权限，从云标识服务中提取凭据，从而能够同步敏感身份数据，以实现持久访问。

PA-8.1：使用 Azure 客户密码箱

客户密码箱 为Microsoft支持工程师数据访问提供显式审批控制，确保客户在故障排除期间维护对谁访问其云资源的治理。 如果没有密码箱，支持工程师可以在未经明确同意的情况下访问客户数据，从而造成合规性风险并减少供应商访问活动的可见性。 实施密码箱可确保每个支持数据访问请求都需要客户批准、维护审核线索和法规合规性。

通过以下过程实现客户密码箱：

• 启用锁箱 全局管理员通过 Azure 门户的管理模块在租户级别启用客户锁箱，这要求租户下的所有订阅和资源拥有 Azure 支持计划（开发人员级别或更高）。

• 启动支持请求 用户在 Azure 门户中为工作负荷问题打开支持票证， Microsoft 支持工程师会查看票证，并确定是否需要超出标准故障排除工具的数据访问。

• 请求提升的访问权限 如果标准工具无法解决问题，工程师会通过 Just-In-Time （JIT） 访问服务请求提升的权限，为直接数据访问（例如虚拟机远程桌面）创建密码箱请求，以指定用途、持续时间和资源。

• 通知指定的审批者 指定的审批者（订阅所有者、全局管理员或 Azure 客户锁箱审批者）将收到包含请求详细信息以及通往锁箱功能页的链接的电子邮件通知。此外，可以为不支持电子邮件的账户或服务主体配置备用的电子邮件通知。

• 审核并批准或拒绝 审批者登录 Azure 门户，查看并审核请求与关联的支持票证，四天内批准或拒绝，批准将访问权限授予有限时间（默认值：8 小时），拒绝或过期将阻止访问。

实现示例

挑战 由于法规要求，金融服务组织需要对Microsoft支持数据访问进行显式审批控制，但缺乏对支持工程师访问请求和合规性审核审批工作流的可见性。

Solution

• 启用客户密码箱 对于需要全局管理员批准的所有订阅，在租户级别激活 客户密码箱 ，使用指定的订阅所有者和 Azure 客户密码箱审批者建立记录的审批过程，并接收针对所有数据访问请求的自动电子邮件通知。
• 配置审批工作流 为所有需要审批者强制性理由文档的密码箱请求建立了 4 天的评审窗口，为服务主体配置备用电子邮件通知，并为时间敏感的支持场景实施紧急处理流程。
• 实现监视和审核日志记录 集成客户密码箱审批事件， Microsoft Sentinel 为安全团队生成实时警报，从而为监管报告启用所有支持访问请求、审批决策和访问持续时间的综合审核线索。

结果 该组织实现了 Microsoft 支持数据访问的 100% 显式批准，平均审批延迟为 2 小时，在 6 个月内维持了 47 个密码箱请求的完整审计记录，并拒绝了 3 个不符合审批标准的请求，展示了治理控制能力。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5 AC-2、AC-3、AC-6（2）、AU-6、CA-3
• PCI-DSS v4 8.2.2、10.2.2、12.8.2、12.8.5
• CIS 控件 v8.1 5.4 、6.8、8.2、8.11
• NIST CSF v2.0 PR.AC-4, PR.PT-2, DE.AE-3
• ISO 27001：2022 A.5.19、A.5.20、A.5.23、A.8.2
• SOC 2 CC6.3、CC6.7、CC7.2