综观组织在IAM面临的常见挑战，以及在新一年实施稳健策略的建议。
译自 10 Best Practices for Building a Robust IAM Strategy in 2024，作者 Gary Archer。
对大多数组织来说，身份和访问管理(IAM)的主要焦点是保护对数字服务的访问。这使得用户和应用程序能够根据组织的业务规则正确地访问受保护的数据。如果安全性配置错误，可能会导致数据泄露。在某些情况下，这可能会造成声誉受损或巨额罚款。
IAM有时被认为是软件工程的一个复杂领域。然而，如果做好IAM，它可以提供关键的功能来赋能组织及其员工。IAM在支持现代、可扩展和可移植的架构方面也发挥着重要作用。让我们来看看组织面临的一些常见IAM挑战和实现可靠IAM策略的建议。
软件首先关注人。在启动现代身份和访问管理或刷新现有实现时，首先组建一个具有以下四个关键角色的团队。每个成员都应该是战略思考者，理想情况下拥有一些IAM知识或经验。
这些不是全职角色。而是把他们看作是在提出解决方案时需要通知的人。凭借其独特的背景，这些专家可以就诸如技术成本、优先级、必须满足的行业特定法规或如何设计友好可靠的登录用户体验等问题提供建议。业务支持尤其重要，以确保身份计划有赞助者。
人们经常认为引入身份和访问管理体系结构会对应用程序产生重大影响，但这并不一定是如此。与其急于技术实现，不如首先关注设计思维。组织可以咨询身份专家，但最终必须做出自己的架构决策。
身份团队应该制定一个或多个高层文档。这也可能包括当前应用程序和API的清单，总结良好或不良的安全行为。这通常需要跨部门对话，以获取各利益相关者的意见。结果摘要应明确需要改进的地方和业务效益。
审核现有安全态势和创建这些文档的成本只是少量的，不会对正在进行的业务交付造成不利影响。文档的一些关键目标应该是明确需求、识别风险和规划一些任务。文档应该对下一代安全架构将启用的功能进行“大胆思考”。
IAM框架的主要要求是保护数据。虽然数据通常存储在数据库中，但必须以受控的方式向用户公开数据。如今，这通常是通过API完成的，API允许不同类型的客户端访问相同的数据。API必须基于用户属性应用业务规则，然后才允许访问数据。因此，您的安全基础是API消息凭证，它在特定上下文中标识用户及其权限。因此，记录一些需要消息凭证的端到端流程:
您的下一代安全体系结构应遵循零信任方法，并保护来自外部和内部客户端对所有API的调用。使用不可伪造的API消息凭证向API传递安全值，以防止被更改。锁定消息凭证，使其权限尽可能小。
保护数字服务中数据的现代API优先方法是使用OAuth 2.0授权框架。这是在2012年引入的，当时API、JavaScript Web应用和移动应用相对较新。
OAuth以API消息凭证(访问令牌)及其在端到端流中的使用为中心。访问令牌由称为授权服务器的组件发出。访问令牌包含安全值，并使用不可伪造的JSON Web令牌(JWT)格式来保护其完整性。API仅接受由授权服务器发出的JWT。返回给应用程序的访问令牌启用了最小权限的API访问，而不是总是授予用户的全部特权。这里显示了一个简化的端到端安全流程:
自OAuth 2.0引入以来，已经创建了许多其他映射到组织特定安全用例的安全规范。其中许多规范非常复杂，需要大量努力才能实现。授权服务器由不断为新标准添加支持的安全专家提供。授权服务器可以视为组织托管在自己API旁边的专家API。
OAuth的更微妙的好处在于其可扩展性。从应用程序和API中外化了困难的安全性。通过重新配置授权服务器而无需更改代码，通常可以实现增强的安全性。OAuth使用的安全设计模式对组织中的许多人来说都是简单易学的。它们还在讨论身份话题时提供了一个通用的安全词汇。
许多授权服务器对标准的支持非常有限。因此，身份团队应明智地选择授权服务器，为组织提供最新的、经得起未来考验的安全功能。
IAM的早期决策之一是决定要针对用户帐户存储哪些数据。将现有用户的核心身份属性迁移到授权服务器的用户管理API是常见的做法。通过这样做，许多核心身份问题，如GDPR、用户入职和退役以及凭据存储，可以在一个地方处理。
下面的示例显示了将用户属性可能迁移到现有用户身份数据的一种方法。避免迁移经常变更的细粒度业务权限。最好将这些存储在业务数据中，以帮助确保API和授权服务器可以独立部署。
此外，要为未来的用户设计。授权服务器将提供开箱即用的自助注册管理选项。一个基本选项是允许用户填写表格，然后提供对电子邮件地址的所有权证明。
更一般地说，该过程是对用户进行身份验证，然后创建用户帐户记录。在某些用例中，管理员可能需要预配用户。这也可以使用授权服务器的用户管理API来自动化。
在实现API安全之前，要为一个或多个API设计访问令牌的有效负载。这应该使用范围和声明来锁定令牌。在下面的示例中，使用“sales”范围来限制访问令牌的特权，仅用于销售上下文。还应该可以将来自任何数据源的用户属性作为访问令牌声明进行发布。
示例:使用“sales”范围来限制访问令牌的特权，仅用于销售上下文。
以可扩展的方式设计访问令牌。保持范围相当高级，以便它们适用于多个API。这种“访问令牌合同”应保持稳定。在使用许多细粒度权限的系统中，避免向访问令牌颁发所有权限，以消除访问令牌版本控制的需要。
在一些较旧的架构中，用户会登录到一个大型应用程序，并在许多业务领域中使用cookie。泄露的消息凭证具有用户的全部特权。相反，OAuth推动了一种设计，其中对API的访问范围受业务领域的限制。然后使用单点登录导航到不同业务域的应用程序。这种设计提供了更好的安全性，并有助于确保更模块化的代码库，多个团队可以共同工作。
最后，JWT访问令牌旨在用于API。互联网客户端应该接收保密的访问令牌，不会泄露敏感数据。实现这一点的首选方法是使用幻影令牌模式，其中API网关接收保密令牌，然后将JWT访问令牌转发到API。
基于密码的登录曾经是主流选项，但它们有许多安全弱点和糟糕的用户登录体验。像 passkeys 这样的现代替代方案很快就会成为标准，它结合了强大的加密与简单的用户体验。passkeys 还可以使用与基于密码的登录相同的帐户恢复选项。
授权服务器使您可以为用户提供多种登录方式。这使您可以向用户呈现额外的选项，例如使用外部身份提供商或数字钱包进行登录。在需要时，您应该能够使用授权服务器的SDK实现定制的身份验证方法和屏幕。
在更改用户的身份验证方法时，关键是API继续在访问令牌中接收现有的用户标识，以便正确更新业务数据。始终解析登录到同一用户帐户的过程称为帐户链接，这也是授权服务器提供的另一项功能。
至少，组织需要选择一个API网关、一个授权服务器，并且API需要使用JWT库。但并非所有授权服务器都具有相同的功能。常见的情况是刚开始使用然后发现您无法颁发正确的访问令牌，或者某种身份验证类型存在可靠性问题。
在IAM之旅的早期阶段，您应该关注可移植的实现，以保持组织的身份选项的开放性。根据您的设计选择授权服务器。使用可移植的代码可以让您以后切换到一个更好的授权服务器，而无需使任何已完成的设计或编码工作无效。
另一个关键的设计因素应该是后端托管的可移植性和功能。像Kubernetes这样的云原生平台提供领先的基础设施安全性，可与OAuth结合使用来进一步保护数据。一种用于优化性能的流行部署是在集装箱化的API旁边运行集装箱化的授权服务器。
最后，确保您的IAM解决方案和整体架构可以扩展到多个区域。在某些行业，您可能需要满足用户事务存储在用户家乡区域的法规要求。IAM设计应当有助于实现这一点。一种选择是在访问令牌中包含区域声明，以允许API网关可靠地将API请求路由到用户的区域。
要集成OAuth，一种有用的方法是选择一些强大的开发人员来创建演示应用和演示API。这些很容易在旗舰应用中更改而不引入风险。后来，它们可以用作其他团队的参考实现。
从本质上讲，API和前端客户端的OAuth实现代码非常简单。API使用JWT验证库来验证访问令牌，之后API使用访问令牌中的声明实现授权。客户端运行一个 code flow 来重定向到授权服务器，用户在那里进行身份验证。在这两种情况下，只需要很少的代码。
技术负责人应该评审技术选择，以确保它们是可移植的。避免使用一些授权服务器提供商提供的非标准流程。还要避免供应商锁定，其中使用的库只适用于一个特定的授权服务器。如果采用API或Web安全框架，请确保它们支持您将使用的OAuth标准。
开发人员还必须遵循API、Web应用和移动应用的独立最佳实践。例如，安全专家建议基于浏览器的应用程序使用最新的、最强大的cookie作为API消息凭证，而不是将访问令牌暴露给JavaScript。开发人员应该运行一个遵循这些实践的安全本地设置，以便广泛理解安全性，并消除任何可靠性问题。
需要做一些工作来确保高效的开发设置，以免阻碍业务交付。开发人员运行单个“正在开发的组件”的设置通常效果最好。例如，API开发人员可以使用模拟访问令牌进行测试，Web开发人员可以只运行一个前端应用，其cookie由已部署的令牌处理API发出。
尽管OAuth集成的基础很简单，但它也是一个高度分布式的体系结构。开发人员必须使用OAuth协议消息(包括错误响应)来工作。实现必须使用可靠的错误处理和日志记录，以便应用程序能够弹性地处理过期和配置错误。
另外，要考虑可见性和控制。合规利益相关者可能希望查看经过审核的身份事件，授权服务器应该发布这些事件。此外，对特别敏感数据的API访问进行审计设计。在某些设置中，权限管理系统可以启用额外的安全行为，例如在运行时更改授权行为。
在组织的部署管道的多个阶段(如开发、暂存和生产)都必须管理授权服务器。这包括具有新配置设置的升级以及处理任何生产事故。规划快速问题解决对于这个关键组件来说至关重要。
身份和访问管理是一个基于关注点分离理念的架构主题。稳健的IAM策略需要设计思维和可靠的工程。这些成分将有助于支持一个现代的、可扩展的体系结构。基于令牌的体系结构支持许多当前和未来的安全连接，这对业务有利。
从设计开始，然后选择和部署安全组件。还要避免过早承诺供应商解决方案。然后，规划任务并遵循迭代方法来实现您的IAM策略。在集成过程中，评审结果并确保您的技术选择满足业务需求。
在Curity，我们为组织产生了许多基于标准的身份资源。在设计IAM策略时，您可以阅读我们的在线资源以了解安全设计模式，而与您选择的IAM解决方案提供商无关。