身份可见性是现代身份安全的建设起点。Verizon年度《数据泄露调查报告》等多项数据泄露研究显示，被盗用、滥用的凭证是目前数据泄露事件中最常见的初始访问向量之一。本文将介绍IAM领域中身份可见性的定义、云与多云环境提升身份可见性难度的原因、身份可见性工具的核心能力，以及搭建实用身份可见性体系的方法。
Part01
明确身份可见性定义
身份可见性指的是企业能够全面掌握环境内所有身份、每个身份的可访问范围，以及这些访问权限在运行时的实际使用情况。它整合资产清单、权限映射、行为遥测三类数据，形成持续更新的全局视图，而非定期生成的静态快照。 身份可见性的核心是区分策略意图与实际执行的差异。IAM平台承载的是策略意图，即哪些主体应该拥有访问权限、访问需满足哪些条件、权限有效期多长。应用和基础设施层反映的是实际执行情况，即哪些凭证完成了认证、哪些权限被实际调用、访问通过哪些路径完成。 两层之间的空隙就是“身份暗物质”的藏身之处，包括本地应用账号、嵌入式服务凭证、老旧认证流程，以及从未接入中央身份提供商（IdP）的集成组件。正是这些隐藏的攻击面，让身份可见性从行政流程问题变成了实打实的安全问题。
Part02
身份可见性成IAM核心挑战
身份暗物质并非孤立的边缘案例，而是过去十年SaaS普及、云迁移、自动化建设过程中普遍产生的副产品。当企业新增系统的速度超过身份体系的承载能力时，登记在案的权限与实际存在的权限之间的缺口就会越来越大。
身份攻击面持续扩张
攻击者已经开始利用这一缺口。现在多数入侵活动不再投放端点防护工具可直接检测的恶意软件，而是先盗用合法凭证，在凭证原有权限范围内开展活动。攻击者后续的操作行为与正常运维活动高度相似，传统检测工具很难识别。
四大因素驱动攻击面增长
凭证入侵：钓鱼攻击、令牌窃取、会话劫持等攻击手段产生的认证事件，与IdP日志中记录的正常用户行为高度相似。 机器与非人类身份：在云资源占比高的环境中，服务账号、API密钥、工作负载凭证的数量往往超过员工账号，且多数没有设置有效期。 应用本地账号：未接入单点登录（SSO）的系统自行完成认证，这类账号永远不会出现在集中访问审计的范围内。 Agentic AI工作负载：自主Agent凭借委托权限跨多个系统执行操作，其运行速度和产生的操作量，是人工审计完全无法跟上的。
传统IAM报表存在短板
多数IAM报表只统计配置信息，包括用户组成员关系、角色分配、权限目录等。这类数据只能说明哪些权限被授予，无法验证应用是否实际执行了权限策略、账号是否仍有对应的负责人、权限在过去一年内是否被使用过。 身份治理平台通常也只统计已接入的应用数据，不会独立验证覆盖范围。如果某个应用从未接入治理平台，就不会出现在报表中，企业很容易将这种“未统计”误认为“已合规”。
Part03
IAM身份可见性依托三大概念落地
IAM身份可见性的核心原则是验证而非假设，要实现有效验证，需要三个核心能力支撑：准确的身份清单、清晰的访问关系映射、持续的上下文风险分析。
梳理身份与权限映射关系
身份清单列出所有访问主体，权限映射说明每个主体可执行的操作，访问关系则跨系统连接两者，反映真实的有效权限，而非纸面的名义权限。 实际有效权限往往比规划的范围更广。某个用户仅被分配了普通应用角色，却可能通过嵌套用户组、共享服务账号、云账号间的信任关系继承管理员权限。访问关系映射可以暴露这些链式权限路径，而攻击者正是利用这类路径开展横向移动。
开展持续身份发现
相比资产盘点，发现工作要解决的问题更难：环境中有哪些从未被登记的身份？持续发现能力直接从应用和基础设施层拉取身份数据，找出集中IAM平台从未记录的本地账号、嵌入式凭证、认证方式。 上下文分析会将发现的问题转化为优先级清单。拥有测试系统只读权限的休眠账号属于低风险噪音；若自动化凭证设置为永不过期，持有生产环境写权限，既无指定负责人也未启用MFA，对应的风险等级会大幅升高。
Part04
多云环境加剧身份可见性难度
身份数据一旦跨云服务商边界，上下文信息就会碎片化。云环境身份可见性难，并不是因为云平台缺少日志能力，而是每个云平台的身份建模逻辑不同，且没有任何一个平台能记录其他平台内的身份活动。
跨云与SaaS需统一权限模型归一化
每个平台都有自己的权限描述体系。多云身份可见性建设的核心，就是对这些不同的权限体系做归一化处理，让同一个身份在所有接入环境中的活动都可以被追踪。
四类身份模型需归一化
AWS：通过角色、基于身份与资源的策略、跨账号角色假设规则，定义访问主体可触达的资源范围。 Azure/Entra ID：通过目录主体、Azure RBAC角色分配、已授权的应用权限（委托范围与应用范围）定义访问能力。 Google Cloud：通过服务账号、IAM绑定规则定义权限，权限可沿组织、文件夹、项目的层级结构继承。 SaaS应用：采用自有管理员层级、自定义角色、本地账号体系，这类身份数据不会同步到中央IdP。 如果不做归一化处理，安全团队需要逐个平台单独审计，很容易漏掉跨平台的连接关系：联邦信任、跨账号角色假设、共享凭证，这些都可以让一个云环境内的身份在另一个云环境内执行操作。云环境中的横向移动通常沿这类IAM信任路径展开，而非传统网络路径。
云环境管控平面身份需重点防护
机器身份是非人类身份的子集，在云环境中往往占所有访问主体的大多数。这类身份由CI/CD流水线、Terraform执行任务、编排工具等基础设施自动化流程创建，不会触发HR体系中的员工入职、调岗、离职流程，因此通常无法纳入为员工搭建的生命周期管控体系。 管控平面身份需要重点关注。这类身份负责配置基础设施本身，一旦对应的自动化凭证被盗，攻击者可以创建新的访问权限、修改日志配置，甚至关闭用于检测攻击的安全管控措施。企业应对所有非人类身份参照人类账号标准落实治理要求：明确指定负责人、标注用途、设置过期或轮换周期、纳入持续监控范围。
Part05
身份可见性与情报平台为专用工具
实现大规模人类与机器身份监控，需要依靠身份可见性与情报平台（IVIP）。这类工具品类的出现，是因为原有身份治理、云安全态势管理、检测类工具都只能解决部分身份可见性问题。不同厂商的产品从不同架构角度切入该领域。
主流IVIP产品路线各有侧重
以下列表仅作示例，并非完整名录，也不代表性能排名。各产品的能力集存在重叠且会快速迭代，企业需要结合自身环境与需求评估。请注意，本页面由Orchid Security发布，该厂商也在列表中。
Orchid Security：直接从应用和基础设施层发现身份、权限、认证流程，而非仅依赖IAM配置数据，可将收集的遥测数据转化为满足审计要求的合规证据，重点解决应用层盲区问题。 Veza：以可观测性为核心的访问图谱产品，可映射数据系统、云平台、SaaS应用中的有效权限，重点聚焦权限关系分析。 SailPoint：以治理为核心的身份安全平台，聚焦企业级生命周期管理、权限认证流程、策略执行。 Saviynt：融合治理与云权限管理能力，整合身份治理与管理（IGA）工作流与云基础设施权限管理（CIEM）分析能力。 Silverfort：提供运行时认证可见性与执行能力，可覆盖难以接入现代SSO的老旧系统、非托管系统。 Semperis：以安全态势为核心的Active Directory与Entra ID防护产品，重点聚焦配置加固、攻击路径分析、灾备恢复。 CrowdStrike Falcon Identity Protection：以检测为核心的身份威胁检测与响应（ITDR）产品，与端点、工作负载遥测数据深度打通。
统一身份清单为基础能力
无论产品采用哪种架构，基础能力要求是一致的：建立一份权威身份清单，归并IdP、云平台、应用、基础设施中的所有身份，再映射身份之间的有效访问关系。 检验这份清单有效性的标准，是它是否包含那些从未被登记的身份。如果平台仅读取IAM配置数据，只会复现IAM体系本身已有的盲区。只有具备应用层发现能力，才能产出真正完整的身份清单，而非片面的报表。
结合行为分析检测风险
只有清单没有分析，只会拉长问题列表，不会提升环境安全性。检测质量取决于行为基线：在判断异常之前，首先要掌握每个身份的正常使用模式。
四类分析能力需重点评估
行为基线构建：区分同一凭证下的常规自动化活动与异常权限使用行为。 攻击路径分析：结合权限配置、可达性、运行时上下文，判断某个配置错误是否可被攻击者利用。 技术点映射：将发现的问题对齐MITRE ATT&CK中的身份相关技术，例如有效账号（T1078），帮助分析人员判断攻击者行为逻辑，而非仅处理孤立告警。 处置路由：将问题连同处置所需的证据直接发送给对应负责团队，而非推送到公共工单队列。
Part06
身份可见性打通现有身份安全体系
身份可见性与情报能力不是替代现有安全工具的新层，而是可观测层，让企业已有的身份安全投入可被验证。
打通IAM、IGA、PAM与运营链路
IAM平台通常覆盖两个阶段的工作：设计阶段，覆盖生命周期管理、策略配置、权限发放；运行阶段，覆盖认证与授权执行。可见性平台同时观测两个阶段的状态，反馈两者之间的差异。 这些反馈数据会以不同形式输出给相邻的安全系统：IGA系统可获得证据，证明权限认证流程反映的是真实访问情况；特权访问管理（PAM）系统可发现未纳入金库管控的特权账号；安全运营团队可获得身份上下文信息，在事件调查时缩短时间线还原的耗时，无需分析人员在多个控制台之间手动拼接事件。
身份情报支撑零信任落地
NIST SP 800-207中定义的零信任架构要求持续验证，而持续验证的前提是持续观测。访问决策的质量，取决于决策依据的信号质量：会话上下文、凭证类型、历史行为、目标系统的敏感等级。 身份情报可以提供这些信号，同时也能反向发现策略未落地的问题，例如仍在接受老旧认证协议的应用、未启用MFA的管理员账号等。
Part07
身份可见性建设分阶段推进
优先级划分是决定身份可见性项目成败的关键。成熟企业通常将身份可见性建设视为逐步成熟的过程：从人工静态治理，到自动化持续管控，最终实现跨应用与基础设施的行为可观测。
优先梳理高风险身份
云环境中普遍存在权限蔓延问题，往往是因为部署阶段为了提效配置了过于宽泛的IAM策略，上线后从未做权限裁剪。建设初期应该优先覆盖过度权限与暴露面重合的场景。 首批优先处置的目标包括：拥有生产环境写权限但无负责人的服务账号、未启用MFA就可认证的管理员账号、从未轮换过的凭证、离职员工的休眠账号。这些问题都是具体可修复、有明确负责人的，解决这些问题可以为后续更大范围的项目建立信任基础。
按阶段推进体系建设
推进顺序非常重要，因为发现工作会产生大量问题，如果没有配套的处置路径，就会造成告警疲劳。
六步落地流程清晰可执行
范围定义：识别核心关键应用与云账号，这类资产一旦发生身份泄露，将造成最严重的损失。 直接发现：从这些应用与基础设施层直接拉取身份与权限数据，而非仅从IdP获取数据。 有效权限映射：梳理嵌套组、信任关系、继承权限，还原身份的真实访问能力。 负责人分配：为所有账号（包括非人类账号）指定明确的人类负责人，设置审计日期或过期时间。 行为监控：建立正常使用行为基线，对权限使用、认证模式的异常行为发出告警。 证据自动化：从实时遥测数据中自动生成合规材料，无需每次审计周期手动整理表格。 项目落地的时间线会根据环境复杂度、应用数量、应用负责人的配合度存在较大差异。
参考来源：
Identity Visibility in 2026: The Foundation of Identity Security
https://thehackernews.com/2026/09/identity-visibility-in-2026-foundation.html