确保云安全访问的五大步骤

现如今，云计算可以说正在推动着新的安全服务呈现爆炸似增长，但并不是每家企业都能够同样挖掘到，并充分利用这一趋势。尽管身份即服务(IDaaS)和云计算正在改变着中小型企业的市场竞争游戏规则，而那些财富1000强的企业鉴于其自身庞大的规模和复杂性的热特点，使得这些已经创建了多年的老字号企业难以彻底的超越其边界安全。他们的客户群可能已经覆盖了全局范围，但其基础设施架构是如此的复杂——因此，确保这些基础设施架构的安全是最为重要的——毕竟，这些公司并不具备将其导航到新的服务层的敏捷性。

既然规模较小的企业可以很容易地将他们的身份基础设施实施外包，但为什么对于大型企业而言，想要迁移到云服务就变得如此的困难呢?今天，当涉及到应用程序和安全时，规模可观的大型企业正面临着两种不同的发展趋势。首先，他们需要负责为更多的来自不同地理位置、采用更多不同的设备、提供比以往任何时候都更多的应用程序的安全访问。第二，身份数据源的数量和表现的多样性——LDAP、AD、SQL、API——也正在以相同的速率疯狂增长，而这种疯狂增长的速率可谓是指数级的。

如此多的异质性正推动着传统的身份识别和访问管理(IAM)超出了突破点的边界，而此时，确保访问的安全性正变得越来越重要，而鉴于当前身份系统的复杂性和高度分散的特点，这一点也越来越难以保证。所有这一切带来了一个经典的n-squared的问题，即许多企业正试图通过很多的硬编码以便将许多不同的数据来源连接起来，每个都有自己的安全协议和数据访问要求。其所导致的结果是：成本昂贵的定制部署和更大的复杂性。



不同的数据存储和应用程序之间的自定义编码连接的成本可能是非常昂贵的。

好消息是：在跨Web和云应用程序的安全性和单点登录(SSO)领域，这个n到n的问题正推动着诸如安全断言标记语言(SAML，SecurityAssertionMarkupLanguage)、OAuth和OpenID连接等联盟标准的快速普及应用。但是，许多企业发现，较之访问一些“抽象”的身份提供者的简单的联盟要求，部署联盟标准的要求更多。



虽然联盟标准汇集整合了对于身份提供商的访问，但身份集成整合往往需要为您的身份提供商提供有凝聚力的观点，以匹配使用应用程序的需要。

为了促成这个解决方案的操作，需要某种形式的智能规范化和身份数据的整合。对于那些并非是待开发部署，其身份信息是存在于一个独特的、有效验证状态的已经成立多年的大企业而言，是一个很大的挑战。

在理想的状态下，身份提供者应该能够为身份验证请求调用一个单一的标准化的身份验证。但大多数财富1000强企业都正在处理分散的身份基础设施的问题，其中身份数据信息和属性是分散在不同的身份数据存储的。身份提供者的目的并非是要跨数据孤岛或理清协议差异来找到用户和用户重叠(虽然有产品做到了这一点)。其需要一个统一的，标准化的身份视图，以便可以验证用户，并发出相应的指令，连接这些用户到网络或在安全边界以外基于云的应用程序。

但是，对于大多数大型企业而言，跨多种不同的分布式架构提出一个全局性的用户视野并不是一个快速或简单的任务。您所需要的是某种形式的集成层，其也可以联合您企业的身份来源——如同SAML和其他联盟成员访问协议本身一样。所有这些数据源必须是联合的，因为每一个都包含需要从现有数据中进行协调的属性或身份信息片段。毕竟，在过去，没有财富1000强公司曾开始过他们在这方面的业务。



在联合层集成和协调身份。

并非要在所有这些复杂性之上强加一个独特的集中式系统，一个联合您身份数据源的整合应能够提供整个系统的合理化观点，所有用以响应新的需求和机会所需要的灵活性。通过整合跨数据孤岛的身份数据和属性，这种联合身份层建立并维护了一个全局性的用户列表，能够跨所有企业系统实施动态策划，然后映射数据，以满足各个消费应用程序的独特要求。

借助一个联合身份层，您的身份提供者可以对身份实施一种理性的，普遍的验证，同时每个用户对于其自己的数据都有存储维护自主权。当然，任何变更都将需要自动同步，并最好尽可能接近实时的自动同步。通过跟踪所有用户及其相关身份信息，包括多个或重叠的用户名，这个联合身份层可以帮助实现所有应用程序的快速，准确的身份验证和授权。

如下，是当企业在建立联合身份层时牢牢记住的几项基本步骤。

1、盘点当前的数据源，并提取和统一元数据

构建一个身份集成整合层的第一步是要对于您企业所有的终端有一个充分的了解。您需要对所有您企业正扩展访问的用户存储进行盘点，同时要了解每款应用程序在底层是如何与这些存储交互的，包括其如何验证和收集授权信息，以及它们发送了哪些查询，它们期望哪类层次结构。一旦这一步完成了，您的整合层就可以开始了解数据的关系了(例如，在存储中是否有相同的用户，以及这些重复帐户将如何进行协调)，使其能够跨整个企业的每一个应用程序以所需要的方式提供完整的身份信息。

大型企业往往跨存储库阵列存储身份和属性信息，每个使用不同的协议和数据模型。一款智能联合身份系统则应能弥合这些不同的系统，以创建一个通用对象模型。这样的系统必须能够发现并提取元数据，或身份信息，并让每个数据源映射该信息到一个共同的命名。这是能够让关联身份信息和由应用程序消耗的格式代表唯一身份信息的关键。如果跨整个数据源没有用户的重叠，所有身份的一个集合通常是足够的。如果相同用户位于多个数据源，则需要关联逻辑以连接这些常见的帐户，使它们在虚拟视图仅代表一次。

2、聚合和关联身份信息，以建立一个独特的参考列表

当大型企业在尝试迁移到云服务时，他们所面临的其中一个主要挑战不仅仅是多个用户存储的问题，而是跨越这些存储的用户重叠的问题。这是建立联盟身份的一个主要障碍。理想的身份验证的基础是一份单一的全局用户列表，其中每个用户只有一个账号，而没有跨所有那些用户可能散落的不同地方的多个不同的列表。您会希望所有的用户属性位于同一个逻辑位置进行授权。

解决方案是创建一个包含了所有用户配置文件信息的单一列表，而做到这一点的最佳方式则是通过整合跨所有身份存储的身份信息。一旦您的库存盘点完成了之后，您可以从您的后端开始提取模式，然后关联相同的用户以创建一份全局名单。

对于最灵活的系统，映射所有的身份模式到一个共同的命名结构，并跨身份筒仓关联相同的用户帐户是必不可少的，以便使得中全局用户列表中没有重复的身份。在用户位于多个数据源的情况下，系统应该保持链接到本地身份标识符。这使得在认证过程中，系统的认证检查功能更有效——这是加快认证过程，促成单点登录的关键步骤。而不是执行一个耗时的，需要对所有的数据源执行循环搜索的过程，系统只需检查用户存储有帐户的这些库。

3、加入身份来创建全局配置文件

一旦创建了全局列表，您可以通过加入操作所有本地帐户的属性，以丰富用户的配置文件。不同的应用需要一个用户身份信息的不同方面，所以重要的是要结合所有来源的认证和授权到一个全局配置。通过联合所有的身份来源，您可以加入这些方面以形成一个全局配置，使得身份提供者能够很容易地访问，封装打包到安全指令，用于消费应用程序。

对于具有重叠身份的每个用户，集成层应该能够从原始身份源和包括它们的全局配置文件提取所有属性。证书应保存在原始数据源，而身份相关确保具有类似名称的用户不会被授予不当授权。

4、合理化群组

不必在多个源进行搜索，以找到群组和成员，身份提供者应该只需要搜索集成层以检查群组成员，超速登录和访问。如果您企业的现有群组足以满足今天强制执行的政策，当您在部署联合身份层时不应该重做任何工作。这层应该虚拟化现有的群组，通过翻译和DN(专有名称)进行自动重映射。

当基于群组成员进行授权时，联合身份层应该能够合理化和汇总现有的群组，如果需要的话，扁平化嵌套组，甚至跨多个数据源的群组成员执行计算动态。其也应该让您计算“成员”的价值，定义群组和用户的条目本身之间的关系。

5、缓存速度和可扩展性造成的视图

一种高级的身份集成整合层位于您企业当前目录基础设施及其所访问的应用程序之间，从后端隔离变化。该层需要高度的可用性，可扩展性和快速的交付——有时甚至比底层的后端更快，以便为所有用户提供对于应用程序快速和可靠的访问，无论这些应用程序位于何处;是如何存储的。

这样的一个层也应该能够提供一个基于您企业的部署要求和环境的持久性高速缓存的选择，所以输入、查询、或建模视图均可以缓存，以实现更高的性能和可用性，实时的或基于一个预定安排。物化层次视图的持久性意味着查询性能将不再受到复杂的连接和跨多个数据源的搜索所限制。



一份关于联合身份层在联合设计中适应的架构建议

借助一个联合身份层，大型企业可以在简化其身份基础设施的同时，关心其现有的投资，使其更容易为自己的身份供应商提供信息，并安全地兑现联合的承诺。但这一层还提供了一个灵活的基础设施和架构模式，超越了联合所带来的直接挑战，使得许多其他的用例，如Web访问管理认证、为高度安全性要求数据的细粒度授权或应用程序、完整的客户档案、更快的应用部署，甚至并购整合变得更容易。构建一个身份整合层可以解决联盟的挑战，同时使企业能够解决未来可能出现的任何新的挑战。