分布式多云时代的身份集成

云计算是有史以来最具变革性的技术之一。它允许具有Internet连接的任何人从任何地方访问应用程序和数据，同时为任何规模的组织提供按需，弹性和可扩展的IT基础架构。由于这些好处和其他好处，云的采用仍在继续。

同时，云还放大了一些现有的IT挑战。其中最主要的是身份管理。有几个原因。例如，大多数公司使用多个云提供商以及其现有的本地IT基础架构。众所周知，这些多云环境要求组织管理每个提供商使用的不同身份系统。此外，本地遗留应用程序通常会硬编码到特定的身份解决方案，这使得它们很难迁移到另一个平台。

由于使用了众多身份孤岛，因此安全管理员在管理所有身份孤岛的能力方面正迅速接近悬崖。

身份挑战潜伏在表面之下。

这不是一个孤立的挑战。根据IBM 最近进行的一项调查，目前有85％的组织使用多云环境。同一项研究还发现，到2021年，有98％的组织希望在多云环境中运营。这意味着几乎每家公司都将或将在不久的将来努力管理多个身份系统。

但是，这些身份孤岛只是冰山一角。对于许多公司而言，以下是一些潜伏在表面上的棘手挑战：

一对一的遗留应用程序集成：具有在本地运行的遗留应用程序的公司通常为每个应用程序使用单独的身份解决方案。这些较旧的身份系统（例如CA SiteMinder，Oracle Access Manager等）已与应用程序紧密集成。这意味着，除非准备好重写应用程序，否则公司通常会被锁定使用过时的身份技术，这是非常昂贵且耗时的。

同时，重写应用程序以使用更新的身份管理系统通常意味着锁定到另一个专有平台。与其在每个应用程序和身份系统之间进行一对一的集成，不如使用抽象层来实现一对多的集成，并且无需每次都重写应用程序。

手动工作：如果没有更好的选择，许多组织将不得不手动设置和维护云身份系统。由于典型的公司使用Amazon Web Services（AWS），Google Cloud Platform（GCP）和Microsoft Azure的某种组合，每个都有自己的身份系统，因此这些操作通常会失败。当与管理遗留应用程序结合使用时，这可能会导致混乱和挫败感。

甚至增加员工也无法充分解决该问题，因为拥有数百或数千名员工的大型组织每天都会生成身份添加，更改和删除。跨系统，云和组织的复杂性太大，以至于无法手动管理此熵。

多云问题：同时，每个云服务提供商都要求组织使用其自己的内置标识域。即使已经采用身份即服务（IDaaS）平台进行云身份认证的公司，也必须仍使用来自AWS，Azure和GCP的内置身份域。使事情变得复杂的是，某些软件即服务应用程序（例如Microsoft Office 365）要求企业使用专有的身份管理系统（在本例中为Azure AD）。

旧版生命周期终止：由于云计算在董事会和预算中处于优先地位，许多传统身份管理供应商降低了投资的优先级，并终止了对“旧版”本地软件的支持。成千上万的企业仍然依靠这些产品来保护核心业务应用程序，并且无法轻易地从核心产品中迁移出来—主要是因为传统遗留身份域的现代化历来需要数个季度甚至数年的复杂迁移计划，执行和验证。对于许多企业而言，成本和复杂性太大。

身份集成成功之路入门。

1.调整您的身份和云策略-然后进行集成。在考虑采用多云时，您应该仔细考虑身份需要如何工作以支持采用和迁移到您使用的云。如果要使用多云，请避免与任何会导致锁定的单一身份系统集成。取而代之的是与与多个身份系统一起使用的抽象层集成，使您可以自由选择适合您不断发展的云战略的最佳解决方案。

2.来自身份系统的抽象策略。为避免使用身份系统锁定应用程序，请确保从任何特定的身份系统中提取访问策略。在多个身份系统和云之间使用一致的访问策略模型可确保只有合适的用户才能访问合适的应用程序和数据，无论这些应用程序和数据在哪个平台上运行。尽可能利用SAML，SCIM和OAuth之类的标准实现互操作性，并注意适用于策略定义和管理的新兴标准。

3.采用零接触和零代码集成。如果需要将现有应用程序的代码更改，则将云身份与应用程序集成可能是一项艰巨的工程挑战。通常，最初编写该应用程序的开发人员不再在身边，这使得重新布线（以及测试和重新部署）应用程序既危险又耗时。您还需要掌握旧式身份系统的API，其中许多已过时并已达到使用寿命。

取而代之的是采用零接触集成模型，避免接触现有应用。另外，使用抽象方法将零代码替换为基于配置的零代码集成模型。这样可以节省大量的应用程序人工操作，以与现代云身份系统一起使用，从而更轻松快捷地迁移到多云世界。

尽管身份孤岛扩展源于并部署在本地企业IT基础架构中，但多云现象正在将其放大。可以使用抽象层方法来解决这一问题并创建从生命周期终止迁移到现代身份管理系统的桥梁。通过建立身份结构，孤岛可以以一对一的方式连接，而不是像过去那样以一对一的方式连接。