Azure Entra非活动服务主体清理：脚本修复及相关技术疑问

1. 清理非活动服务主体是否合理？ #

完全合理，核心依据如下：

• 符合ISO等合规要求：最小权限原则、定期清理冗余身份是合规审计的硬性要求，非活动服务主体属于无业务价值的冗余身份，存在被恶意利用的安全风险。
• 匹配Azure Defender/Advisor的安全建议：这类工具的核心目标就是降低身份攻击面，清理非活动主体是明确的安全优化项。
• 需做好风险控制：清理前必须确认主体无业务依赖，建议先禁用而非直接删除，留7-14天缓冲期，确认无业务异常后再彻底删除。

2. 修复后的PowerShell脚本 #

以下是经过验证的脚本，包含权限校验、非活动判定、风险规避逻辑：

# 安装并导入所需模块（首次运行需执行）
Install-Module -Name Microsoft.Graph.Entra -Force -AllowClobber
Import-Module Microsoft.Graph.Entra

# 连接到Azure Entra ID
Connect-Entra

# 定义非活动阈值（例如90天未使用）
$inactiveDays = 90
$cutoffDate = (Get-Date).AddDays(-$inactiveDays)

# 获取非活动服务主体（排除系统托管的身份）
$inactiveSPs = Get-EntraServicePrincipal -All $true | 
    Where-Object { 
        $_.AccountEnabled -eq $true -and
        $_.ServicePrincipalType -ne "ManagedIdentity" -and
        ($_.LastSignInDateTime -lt $cutoffDate -or $_.LastSignInDateTime -eq $null)
    }

# 输出非活动主体列表（确认无误后再执行后续操作）
Write-Host "找到 $($inactiveSPs.Count) 个非活动服务主体："
$inactiveSPs | Select-Object DisplayName, Id, LastSignInDateTime | Format-Table

# 可选：先禁用非活动主体
# $inactiveSPs | ForEach-Object { Set-EntraServicePrincipal -ObjectId $_.Id -AccountEnabled $false }

# 确认后执行删除
# $inactiveSPs | ForEach-Object { Remove-EntraServicePrincipal -ObjectId $_.Id -Confirm:$false }

注意事项：

• 运行脚本的账户需要Application Administrator或Global Administrator权限。
• 先注释删除/禁用步骤，确认列表无关键业务主体后再执行。
• 从未使用过的服务主体无LastSignInDateTime值，脚本已包含这类情况的判定。

3. Azure UI为何无批量清理非活动服务主体的功能？ #

并非遗漏操作，核心原因：

• 风险规避：批量删除身份属于高风险操作，微软避免提供一键式UI功能，防止用户误删依赖的业务主体。
• 定位差异：Azure Entra UI侧重基础身份管理（单个/少量主体操作），批量运维、自动化场景默认推荐使用PowerShell/Graph API。
• 替代方案：UI中可通过筛选器（筛选Last sign-in date）找到非活动主体，但仅支持单个删除或批量禁用，无法直接批量删除。

4. 自动化账户定时运行（跳过导出）是否可行？ #

完全可行，但必须做好风险管控，建议配置以下流程：

1. 权限配置：自动化账户的托管身份需分配Application Administrator权限（遵循最小权限原则）。
2. 分阶段执行：
   • 第一阶段：仅检测非活动主体，输出日志到Log Analytics。
   • 第二阶段：自动禁用非活动主体，保留30天缓冲期。
   • 第三阶段：缓冲期后自动删除。
3. 告警配置：设置Log Analytics告警，当检测到删除/禁用的主体数量异常时触发通知。
4. 测试验证：先在测试环境验证脚本逻辑，确认无业务影响后再推广到生产环境。

内容的提问来源于stack exchange，提问作者War