VSTS中PAT的管控与治理相关技术问询

作为在企业级Azure DevOps（原VSTS）环境摸爬滚打了几年的老鸟，我来分享下我们团队和了解到的同行应对PAT管控问题的经验，刚好你的三个问题都是安全团队最关心的点：

我们团队是结合以下几个方案获得安全团队认可的，同时也了解到不少同行的做法：

• 强制PAT生命周期管理：在组织设置里把PAT的最长有效期设为90天，要求用户定期轮换，同时禁止创建永久有效的PAT。这直接缩短了令牌泄露后的风险窗口，安全团队对这个措施接受度极高。
• 用Azure AD条件访问加固：配置条件访问策略，限制PAT只能从企业内网IP段生成和使用，并且要求用户启用MFA才能创建PAT。这一步把外网滥用的可能性降到了几乎为零。
• 服务主体替代个人PAT：对于外部工具集成（比如CI/CD工具、第三方监控），完全摒弃个人PAT，改用专门的服务主体，给它分配最小必要权限。这种“非个人化”的身份方式，就算泄露也只会影响特定业务，不会牵连用户的个人权限，安全团队非常青睐。
• 关于微软反馈：确实有大量企业向微软反馈过PAT管控的痛点，Azure DevOps后续推出的PAT权限范围细化、审计日志、创建限制等功能，都是基于这些反馈迭代的。
• 其他企业的极端做法：有些高安全要求的金融、军工企业，会把PAT创建流程纳入内部审批系统——用户必须提交工单，说明PAT的用途、有效期、权限范围，经安全团队审核通过后才能生成。虽然流程繁琐，但完全满足合规要求。

直接禁用所有用户创建PAT的选项在早期VSTS里确实没有，但现在Azure DevOps已经有成熟的解决方案：

• 官方内置的限制功能：在组织设置 -> 安全性 -> 个人访问令牌 -> 「限制创建」模块，你可以指定仅允许特定用户/组创建PAT，其他所有用户都会被禁止。比如只把安全管理员和DevOps运维组加入允许列表，普通用户就没法自己创建PAT了。这个功能是微软后来针对企业需求加的，建议优先用这个。
• Azure AD条件访问兜底：如果内置功能满足不了更严格的要求，可以用Azure AD条件访问创建“阻止”策略：
  1. 选择「云应用或操作」，找到「Azure DevOps - 创建个人访问令牌」这个特定操作；
  2. 设置策略为“阻止访问”，同时排除你指定的管理员组；
  3. 这样所有不在排除列表里的用户，都没法通过任何途径创建PAT。

Azure DevOps界面确实没有提供查看所有用户PAT的入口，但可以通过API或脚本实现，前提是你有组织级管理员权限（比如Project Collection Administrator角色）：

• REST API方式：调用GET https://vssps.dev.azure.com/{你的组织名}/_apis/tokens/pats?api-version=7.1-preview.1端点，返回的JSON里包含所有PAT的名称、过期时间、创建者、权限范围等信息。
• PowerShell脚本示例：

  # 替换为你的组织名和管理员PAT
  $orgName = "your-organization-name"
  $adminPAT = "your-admin-personal-access-token"
  
  $headers = @{Authorization = "Basic " + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$adminPAT"))}
  $pats = Invoke-RestMethod -Uri "https://vssps.dev.azure.com/$orgName/_apis/tokens/pats?api-version=7.1-preview.1" -Headers $headers -Method Get
  
  # 格式化输出关键信息
  $pats.value | Select-Object displayName, validTo, createdBy, scope | Format-Table -AutoSize
  

• Azure CLI方式：如果你习惯用CLI，可以先登录az login，然后执行az devops pat list --org https://dev.azure.com/$orgName，同样能返回全组织的PAT列表。

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