为什么 IGA 项目失败的频率高于本应出现的水平
身份治理与管理(IGA)已经存在了足够长的时间,按理说失败率应该很低。相关概念早已成熟,主流平台也已经十分成熟,曾经实施过这类项目的人也不在少数。然而,项目依然频繁超支、超期,偏离最初的范围,或者最终交付一个"能用",但并不完全适合该组织的解决方案。
失败的原因往往集中在一组熟悉的主题上。
高管的支持经常被提及,而且确实重要。如果没有高层的坚定承诺,一旦预算收紧或优先事项发生变化,项目就很容易被削减。
项目目标是另一个常见的罪魁祸首:要么目标设定得过于雄心勃勃,超出了技术在现实中能够交付的能力,要么从一开始就从未精确到可衡量的程度。
当规划被牺牲、只为尽快向利益相关者展示成果时,交付时间就会延后。当评估由供应商演示驱动,而不是基于文档化的需求时,技术选型就会出错。人们很容易被功能丰富的平台吸引,后来才发现自己真正需要的功能,恰恰是那些需要最多定制的功能。当需求在实施过程中发生变化,或者从一开始就低估了配置和集成所需的工作量时,成本就会超支。
这些都是真实存在的问题,而且都已经被详细讨论过。但有一种失败模式往往悄悄潜伏在其他几种问题背后,却远未受到应有的关注——项目从未真正确定过,它究竟是为谁而建的。
在陷入困境的大多数 IGA 项目中,至少有一部分问题可以追溯到项目早期对用户类型、身份类型和访问场景所做的假设——而这些假设最终被证明是错误的。
解决办法并不复杂,但确实需要自律。这意味着,在项目开始时,首先要完整地描绘出你的身份全景图——不是技术,不是集成,也不是工作流程,而只是你的治理项目需要覆盖的人和身份。其余的一切都由此而来。
本文接下来的部分将解释如何构建这幅身份全景图,以及为什么这样做所带来的差异,远远大于大多数组织的预期。
那么,你正在考虑身份治理
技术本身很少是 IGA 项目陷入困境的原因:根本原因几乎总是从产品出发,而不是先理解自己的人员。
无论你是被要求评估一个 IGA 平台,还是已经身处项目中途、事情正变得复杂,你可能已经注意到,技术通常不是最难的部分。
IGA 平台(用于控制谁能访问什么、自动化入职和离职流程、并确保有人定期审查这些访问权限的软件)已经成熟、被充分理解,且能力广泛。大多数主流平台都能毫不费力地处理核心用例。
那么,为什么这么多 IGA 项目会超出预算、耗时超出预期,或者最终得到一个并不完全合适的解决方案?
根据我们的经验,几乎总能追溯到同一个根本原因:组织一开始选择的是产品,而不是先去理解自己的人员。
在评估任何一家供应商之前,你能做的最有价值的事情,就是弄清楚究竟是谁在你的组织中工作,以及他们与身份之间的关系是什么样的。
事情并不像"员工入职、员工离职"那么简单
从表面上看,IGA 听起来很直白。有人加入公司,就获得账户;有人离开公司,这些账户就被禁用。在此期间,有人定期检查大家是否仍然需要自己拥有的权限。
而在大多数组织中,现实要混乱得多。想想在项目推进过程中往往会浮现出来的一些问题:
承包商和中介派遣人员的情况如何——他们会出现在你的 HR 系统中吗?如果不会,IGA 平台从哪里获取他们的信息?
那些需要访问特定系统的第三方供应商呢?他们是如何入职的,又由谁来管理他们的生命周期?
你是否有员工同时在多个法人实体或地区工作,并且在每个实体中可能担任不同的角色?
是否存在需要与人类用户一同治理的服务账户、共享账户或机器身份?
那些处于敏感岗位的用户呢——高管、财务团队、IT 管理员——他们可能需要更严格的控制或不同的审批流程?
你的任何一个用户画像所拥有的访问权限,是否是监管机构或审计人员会专门问及的,而这是否会改变这些权限需要被审查或记录的方式?
权限应该永久有效,还是有些权限,尤其是敏感权限,应该只在有限的时间内有效?
以上这些都不是边缘情况。在任何规模超过几百人的组织中,它们都是常态。而如果你所选择的 IGA 平台从未针对这些情况接受过评估,你迟早会以艰难的方式发现这一点——通常就在实施阶段,而那时改变方向的代价已经很高。
用户画像登场
在身份治理的语境中,一个用户画像指的是一类独特的用户,其身份生命周期、访问需求或数据来源与其他类型有着实质性的不同:它指的不是具体的个人,而是人的类型。
有一种技术,几十年来一直是结构化系统分析的一部分,最初借鉴自软件工程,非常适合解决这个问题。它有不同的名字——用户画像、参与者、身份原型——但其思路很简单。
在定义一个系统需要做什么之前,首先要定义这个系统需要服务的所有不同类型的人(以及非人类对象)。
根据我们的经验,一个中等规模的组织通常会识别出三十到五十种不同的身份用户画像。对于医疗、教育或零售行业的组织,这个数字很容易翻倍。
一些例子可以让这一点更加具体:
一名通过 HR 系统入职的正式员工,拥有标准的入职流程、直属经理审批,以及一套明确定义的默认基础访问权限。
一名通过中介机构招募的承包商,其记录存放在电子表格或供应商门户中,而非 HR 系统里,并且可能同时为多家客户工作。
一名有固定期限合作关系的学生或实习生,其访问权限需要在实习结束时干净利落地失效。
一名持有特权 IT 账户的用户,该账户需要更高级别的审查、职责分离控制,以及可能采用即时(just-in-time)访问,而非常驻权限。
一种非人类身份,例如应用服务账户或 API 集成,它拥有权限、需要被治理,并且当然不会去填写一份自助访问申请表。
每一种用户画像与你的 IGA 平台的交互方式都会各不相同。有些会从源系统自动完成入职。有些则需要手动流程或替代数据源。有些需要专门的审批链;另一些则需要按计划让访问权限过期。
这为何对平台选型如此重要
一旦你有了用户画像清单,需求几乎就会自己写出来。
你不再问"这个平台支持入职/岗位变动/离职流程吗?"(所有平台都会说支持),而是开始问更具体得多的问题:
它能否从 HRIS、电子表格、LDAP 和 SCIM 端点等多个来源摄取身份数据,并将其协调为单一的身份记录?
它能否通过一个独立的入职工作流,来处理那些根本没有 HR 记录的身份?
它能否为不同类型的用户应用不同的治理策略,使你的承包商拥有 90 天一次的访问审查周期,而你的特权用户则是每月一次?
当有人更换角色时,它能否计算出差异,并在无需人工干预、也不产生孤立权限的情况下,配置或撤销相应的权限?
当有人积累了一组构成风险的访问权限组合时,即便每一项单独的权限在授予时看起来都无害,它能否发出警示?它能否向审计人员展示,每个用户画像的访问权限是为何、由谁批准的,并且审查频率与该画像所带来的风险相匹配?
一个设计良好的 IGA 平台应当能够处理上述所有内容。用户画像梳理这项工作会告诉你,这些能力中哪些对你的组织而言是真正关键的,哪些只是锦上添花。
它还会告诉你,在评估供应商时应该要求对方演示什么。你不必坐着看一遍通用的产品演示,而是可以把一组用户画像交给供应商,请他们具体展示其平台是如何处理每一种画像的。
用户画像梳理这项工作,把供应商评估从一场功能对比,变成了一场真正的能力测试。当你要求的是一个具体场景而不是一种笼统的能力时,想要掩盖差距就困难得多。
好的实践是什么样的
当你看到一个配置良好的 IGA 部署时,基于用户画像的思路会清晰地体现在架构之中。不同类型的身份流经不同的入职路径。访问权限根据角色和上下文来分配,而不是依靠人工维护的名单。当某人的情况发生变化时(晋升、调动、合同延长),平台会自动做出响应。
访问审查的范围划定得很智能:合适的人在与风险等级相匹配的频率下,审查合适的权限。当审查人员发现某项不应存在的权限时,移除操作是自动且可审计的。当急需访问权限时,存在一套留下清晰记录的申请-审批工作流。
敏感的访问组合(比如既能发起采购订单、又能审批该订单的能力)会被主动识别出来,而不是等到审计时才被发现。例外情况在监督下进行管理,而不是悄悄地不断累积。
这一切都不需要什么特别新奇的平台。它所需要的,只是有人在项目早期花时间去理解组织实际拥有哪些类型的人和身份,并围绕这些类型来设计解决方案。
这一回报会体现在访问权限触及业务的每一个角落:权限的流转更快,因为不再需要人工干预;权限更准确,因为它们与上下文相关联,而不是依赖静态名单;合规也不再是一场手忙脚乱,因为证据是在工作发生的同时被捕获的,而不是事后重建的。
实际的额外收益
除了让你的 IGA 项目更有可能成功之外,用户画像梳理这项工作还有几个有用的附带效果。
它同样对其他项目有益。身份几乎触及组织中的一切。在评估特权账户管理(PAM)解决方案、终端管理工具,或者任何需要了解你的用户是谁、他们在做什么的其他系统时,你的用户画像清单同样有用。
它让与利益相关者的沟通更容易。当你可以指着"承包商画像"或"特权管理员画像",而不是去描述一个抽象的技术需求时,对话就变得更加具体。业务方利益相关者理解用户画像的方式,往往比理解权限模式(entitlement schema)要直观得多。
它为项目治理提供了一份天然的输入材料。如果你使用 RACI(负责、批准、咨询、知情)矩阵来管理项目职责,你的用户画像清单就为此提供了原始素材。每一个用户画像背后,都有一位业务负责人、一位技术责任人,以及一组需要被咨询、被告知或直接参与其中的利益相关者。
Netwrix Identity Manager 这类平台的用武之地
这一切都不是推迟选择平台的理由。恰恰相反,它是选择一个按照你的用户画像清单的运作方式来设计、而非与之背道而驰的平台的理由。
Netwrix Identity Manager 在同一套模型下治理内部、外部、访客、技术、物联网(IoT)以及 AI 智能体身份。因此,一名从电子表格中招募来的承包商、一个 HR 部门从未听说过的服务账户、一个自行配置访问权限的 AI 智能体,以及一名通过 HR 数据源入职的正式员工,都会获得同样的生命周期管理规范,而不是四种各自为政的临时应对方案。第三方身份和非人类身份拥有各自专属的生命周期路径,包括按计划到期的限时访问,而不是在合同或任期结束后仍然滞留。接入新系统同样不需要一个定制化的集成项目:标准连接器开箱即用地覆盖 AD、LDAP、SQL、CSV 和 SCIM,并为你环境中更特殊的需求提供高级连接器和通用 API。
角色管理的运作方式也是如此。你可以按用户画像来定义角色和策略模型,而不是对所有人采用同一套策略;角色挖掘(role mining)则利用机器学习来分析实际的访问模式、发现角色结构,并随着使用方式的变化持续更新模型,因此它反映的不只是模型构建那一天的组织架构图。
风险管理这一侧也是为同样的现实而构建的。策略引擎能够检测并防止职责分离(SoD)冲突,持续监控则会在孤立账户和异常情况出现在审计报告之前——而不是之后——就将其标记出来。
这一切都不能取代用户画像梳理这项工作。恰恰相反,正是它使得从设计到实施的快速推进成为可能:每一种身份都按照其自身的条件被定义和治理,而不是被强行塞进单一通道,再靠例外情况来修修补补以求"凑合"。其结果是更低的风险、更快的实施速度,以及更低的成本。
总结
身份治理平台已经成熟且能力全面。通常导致项目陷入困境的,并不是技术本身。真正导致项目陷入困境的,是从一个产品出发,然后事后再试图把组织的现实硬塞进这个产品里。
另一种做法(先识别你的身份用户画像,用它们来定义需求,再依据这些需求去评估各个平台)一旦被描述出来,听起来显而易见。但在实践中,这种做法却出奇地罕见,而它所填补的空白是相当可观的。
它不需要专门的工具,也不需要深厚的技术知识。它需要的是时间、好的问题,以及从流程早期阶段就愿意让来自业务各个部门的合适人员参与进来的意愿。
把用户画像做对,项目的其余部分就会顺畅得多。把它们做错,或者干脆跳过这一步,你可能会发现自己需要事后去改造一个解决方案,以适应一个在购买时你并未完全理解的问题。
你的身份管理项目遇到问题了吗?我们可以帮助你理解自己的用户画像,以及 Netwrix Identity Manager 如何能让你的项目取得成功。立即申请演示。
分享到
了解更多
关于作者
