确保云安全访访问的五大步骤
时间：2020-09-19 07:54:48 来源：达达文档网 本文已影响 人 
打开文本图片集
现如今，云计算可以说正在推动着新的安全服务呈现爆炸似增长，但并不是每家公司都能够同样挖掘到，并充分利用这一趋势。尽管身份认证服务（IDaaS）和云计算正在改变着中小型公司的市场竞争游戏规则，而那些世界百强公司鉴于其自身庞大的规模和复杂性的特点，使得这些已经创建了多年的老字号公司难以彻底的超越其边界安全。他们的客户群可能已经覆盖到全球范围，但其基础设施架构是如此的复杂。因此，确保这些基础设施架构的安全是最为重要的。
既然规模较小的公司可以很容易地将他们的基础设施实施外包，但为什么对于大型公司而言，想要迁移到云服务就变得如此困难呢？今天，当涉及到应用程序和安全时，规模可观的大型公司正面临着两种不同的发展趋势。第一，他们需要负责为更多的来自不同地理位置、采用更多不同的设备提供比以往任何时候都更多的应用程序的安全访问。第二，身份数据源的数量和表现的多样性——LDAP、AD、SQL、API也正在以相同的速率疯狂增长，而这种疯狂增长的速率往往是指数级的。
如此多的异质性正推动着传统的身份识别和访问管理（IAM）超出了突破点的边界。而此时，确保访问的安全性正变得越来越重要，而鉴于当前身份系统的复杂性和高度分散的特点，这一点也越来越难以保证。所有这一切带来了一个经典的n-squared的问题，即许多公司正试图通过很多的硬编码以便将许多不同的数据来源连接起来，每个都有自己的安全协议和数据访问要求。导致的结果是成本昂贵的定制部署和更大的复杂性（如图1）。
然而，在跨Web和云应用程序的安全性和单点登录（ss0）领域，这个问题正推动着诸如安全断言标记语言（SAML，Security Assertion Markup Language）、0Auth和OpenID连接等联盟标准的快速普及应用。但是，许多公司发现，较之访问一些“抽象”的身份提供者的简单的联盟要求，部署联盟标准的要求更多
虽然联盟标准汇集整合了对于身份提供商的访问，但身份集成整合往往需要为您的身份提供商提供有凝聚力的观点，以匹配使用应用程序的需要。为了促成这个解决方案的操作，需要某种形式的智能规范化和身份数据的整合。对于那些并非是待开发部署，其身份信息是存在于一个独特的、有效验证状态的大公司而言，是一个很大的挑战。
在理想的状态下，身份提供者应该能够为身份验证请求调用一个单N.标准化的身份验证。但大多数公司都正在处理身份基础设施的问题，其中身份数据信息和属性是分散在不同的身份数据源里的。身份提供者的目的并非是要跨数据源或理清协议差异来找到用户和用户重叠。其需要一个统一的、标准化的身份视图，以便可以验证用户，并发出相应的指令，连接这些用户到网络或在安全边界以外基于云的应用程序。
但是，对于大多数大型公司而言，跨多种不同的分布式架构提出一个全局性的用户视野并不是一个简单的任务。您所需要的是某种形式的集成层，其也可以联合您公司的身份来源—如同SAML和其他联盟成员访问协议本身一样。所有这些数据源必须是联合的，因为每一个都包含需要从现有数据中进行协调的属性或身份信息片段（如图3）。毕竟，在过去没有一家公司曾开始过他们在这方面的业务。
但并非要在所有这些复杂性之上强加一个独特的集中式系统，一个联合您身份数据源的整合应能够提供整个系统的合理化观点，所有用以响应新的需求和机会所需要的灵活性。通过整合跨数据源的身份数据和属性，这种联合身份层建立并维护了一个全局性的用户列表，能够跨所有公司系统实施动态策划，然后映射数据，以满足各个消费应用程序的独特要求。
借助一个联合身份层，您的身份提供者可以对身份实施一种理性的、普遍的验证，同时每个用户对于其自己的数据都有存储维护自主权。当然，任何变更都将需要自动同步，并最好尽可能接近实时的自动同步。通过跟踪所有用户及其相关身份信息，包括多个或重叠的用户名，这个联合身份层可以帮助实现所有应用程序的快速、准确的身份验证和授权。下面介绍当公司在建立联合身份层时注意的五项基本步骤。
1.盘点当前的数据源，并提取和统一元数据
构建一个身份集成整合层的第一步是要对于您公司所有的终端有一个充分的了解。您需要对所有您公司正扩展访问的用户存储进行盘点，同时要了解每款应用程序在底层是如何与这些存储交互的，包括其如何验证和收集授权信息，以及它们发送了哪些查询，它们期望哪类层次结构。一旦这一步完成了，您的整合层就可以开始了解数据的关系了（例如，在存储中是否有相同的用户，以及这些重复账户将如何进行协调），使其能够在整个公司的每一个应用程序以所需要的方式提供完整的身份信息。
大型公司往往跨存储库阵列存储身份和属性信息，且每个使用不同的协议和数据模型。一款智能联合身份系统则应能弥合这些不同的系统，以创建一个通用对象模型。这样的系统必须能够发现并提取元数据或身份信息，并让每个数据源映射该信息到一个共同的命名。这是能够让关联身份信息和由应用程序消耗的格式代表唯一身份信息的关键。如果跨整个数据源没有用户的重叠，所有身份的一个集合通常是足够的。如果相同用户位于多个数据源，则需要关联逻辑以连接这些常见的账户，使它们在虚拟视图仅代表一次。
2.聚合和关联身份信息，以建立一个独特的参考列表
当大型公司在尝试迁移到云服务时，他们所面临的其中一个主要挑战不但是多个用户存储的问题，而且是跨越这些存储的用户重叠的问题。这是建立联盟身份的一个主要障碍。理想的身份验证的基础是一份单一的全局用户列表，其中每个用户只有一个账号，而没有那些用户可能散落的不同地方的多个不同的列表。您会希望所有的用户属性位于同一个逻辑位置进行授权。
以上问题解决方案是创建一个包含了所有用户配置文件信息的单一列表，而做到这一点的最佳方式则是通过整合所有身份存储的身份信息。一旦您的库存盘点完成了之后，您可以从后端开始提取模式，然后关联相同的用户以创建一份全局名单。
对于最灵活的系统，映射所有的身份模式到一个共同的命名结构，以便全局用户列表中没有重复的身份。在用户位于多个数据源的情况下，系统应该保持链接到本地身份标识符。这使得在认证过程中，系统的认证检查功能更有效——这是加快认证过程，促成单点登录的关键步骤。而不是执行一个耗时的、需要对所有的数据源执行循环搜索的过程，系统只需检查用户存储有账户的那些库。
3.加入身份来创建全局配置文件
—旦创建了全局列表，您可以通过加入操作所有本地账户的属性，以丰富用户的配置文件。不同的应用需要一个用户身份信息的不同方面，所以重要的是要结合所有来源的认证和授权到一个全局配置。通过联合所有的身份来源，您可以加入这些方面以形成一个全局配置，使得身份提供者能够很容易地访问，封装打包到安全指令，用于消费应用程序。
对于具有重叠身份的每个用户，集成层应该能够从原始身份源和包括它们的全局配置文件提取所有属性。证书应保存在原始数据源，确保具有类似名称的用户不会被授予相当的授权。
4.合理化群组
不必在多个源进行搜索，以找到群组和成员，身份提供者应该只需要搜索集成层以检查群组成员，快速登录和访问。如果您公司的现有群组足以满足今天强制执行的需求，当您在部署联合身份层时就不应该再做任何工作。这层应该虚拟化现有的群组，通过翻译和DN（专有名称）进行自动重映射。
当基于群组成员进行授权时，联合身份层应该能够合理化和汇总现有的群组，如果需要的话，扁平化嵌套组，甚至跨多个数据源的群组成员执行计算动态。其也应该让您计算“成员”的价值，定义群组和用户的本身之间的关系。
5.缓存速度和可扩展性造成的视图
一种高级的身份集成整合层位于您公司当前目录基础设施及其所访问的应用程序之间，从后端隔离变化。该层需要高度的可用性、可扩展性和快速的交付——有时甚至比底层的后端更快，以便为所有用户提供对于应用程序快速和可靠的访问。
这样的一个层也应该能够提供一个基于您公司的部署要求和环境的持久性高速缓存的选择，所以输入、查询或建模视图均可以缓存，以实现更高的性能和可用性，实时的或基于一个预定安排。简化层次视图的持久性意味着查询性能将不再受到复杂的连接和跨多个数据源的搜索所限制。
借助一个联合身份层（如图4），大型公司可以在简化其身份基础设施的同时，关注其现有的投资，使其更容易为自己的身份供应商提供信息，并安全地兑现联合的承诺。但这一层还提供了_一个灵活的基础设施和架构模式，超越了联合所带来的直接挑战，使得许多其他的用例，如web访问管理认证、为高度安全性要求数据的细粒度授权或应用程序、完整的客户档案、更快的应用部署，甚至并购整合变得更容易。构建一个身份整合层可以解决联盟的挑战，同时使公司能够解决未来可能出现的任何新的挑战。
