Shadow Account 有两种含义：Entra B2B 里故意建的 AD 影子账号，和 IAM 管不到的孤儿凭据

Shadow Account（影子账户）这个词在两类完全不同的语境里出现。一类是 Entra ID B2B 访客接入本地 AD 时，脚本故意创建、有命名规则的 AD 账号；另一类是 IAM 生命周期管不到、没人认领的凭据——个人 API key、外包建的云身份、共享脚本里的 token。前者是设计产物，后者是治理漏洞。下面就分开写。

一、定义与边界

按 NHIMG 词汇表及 Dark Reading、JumpCloud 的用法，shadow account 指用于干活、但不受组织正常身份生命周期管控的身份。它可能没有经过审批的 MFA、没有日志、没有保留期、没有吊销流程，实质上形成一条平行的信任通道（parallel trust zone）。

关键区分不在于这个身份是人还是机器（NHI），而在于它是否落在正常控制面（control plane）之外。所以它和两类东西不同：

• 规范配置的 break-glass 应急账户——仍然被监控，有使用记录。
• 经过正式审批的例外——仍然有归属和时间限制。

最常见的误用是把任何"不方便的遗留旧凭据"都叫成 shadow account。判断依据是：这个身份是否被正式审批、被监控、可被吊销。

二、典型例子

• 开发在已审批的服务账号失去权限后，自己建个人 API key 让流水线继续跑。
• 外包/合同工因企业账号权限不够，另建一个云身份访问生产数据。
• 集成团队把凭据放进共享脚本或配置文件，绕过 secrets manager。
• 运维组为周末变更维护一个从未 review 的应急账户，密码不轮换，也不记录理由。
• 第三方自动化工具拿到的不是集中治理的身份，而是本地临时签发的 token。
• Shadow SaaS account：SaaS 里匹配不到组织任何已知身份的用户账号，常见为个人邮箱、外部协作者、无归属人的服务账号。绕过 SSO/MFA 和自动离职销号，可在人员离职后长期存活，而很多 SaaS 根本不记录用户操作。
• 服务器本地账号、数据库直连账号：为绕过集中管控而创建，权限过宽、凭据不轮换。

三、风险与审计盲区

shadow account 会同时破坏 NHI 的核心控制项：归属、监控、轮换、吊销、证据留存。身份一旦落在治理之外，出事时无法确信"访问能否被追踪、权限能否快速移除"。

具体表现：

• 事故响应者面对日志盲点、归属不明、离职销号延迟。
• 零信任假设被削弱——信任被授予了一个从未真正纳入控制模型的身份。
• NHI 数量常是人类身份的 25x–50x（NHIMG 引用数据）。

框架映射上，它对应 OWASP Non-Human Identity Top 10 的 NHI-01（未纳管身份规避生命周期与归属控制）、NIST CSF 2.0 PR.AC-4（权限须被授权、复核、可追踪），以及 NIST SP 800-207 的持续验证要求——shadow account 恰好绕过这一条。

代表案例是 CircleCI（2022-12-22）：第三方系统环境变量、密钥、token 泄露；事后企业无法确定被盗密钥是否已被用于攻击云账户，因为无法盘点这些密钥的归属与使用。

四、发现与治理

扩大发现范围

不要只看已纳管端点和 IdP。同时扫：云基础设施（SaaS/PaaS/IaaS）里的未纳管身份；用 secrets detection 扫 Git、日志、文件和容器；审计 Google Workspace/M365/Slack 里的 OAuth/SAML 集成；接 PAM 把未纳管特权纳入治理；用 ITDR 识别与可疑身份相关的行为和认证请求。

本机账号可以先做粗比对（需自行验证）：

# /etc/shadow 中存在、但 getent passwd 中查不到的名字
comm -23
- Dark Reading "Shadow Identities"：
- JumpCloud shadow SaaS accounts：
- Azure-Samples/B2B-to-AD-Sync：
- 深思影子系统：