《设计一种云级别身份认证结构》由会员分享，可在线阅读，更多相关《设计一种云级别身份认证结构（10页珍藏版）》请在金锄头文库上搜索。
1、设计一种云级别身份认证结构这篇文章首先发表在puter杂志上，现在由InfoQ与IEEE计算机学会联合为您呈现。在最近的IT记忆里，云迅速成为了最具爆发力的势力之一。它提供更高的可靠性、更好的灵活度、更低的成本和更简单的部署。云有着无可否认的潜力，能够让所有的用户和各行业受益。然而，尽管前景远大，云仍然还很年轻。许多企业仍然对在全范围内采用云来处理关键工作表示担心。最常被提起的不愿意迁移到云端的理由就是对安全的担心。特别是管理用户和访问云端的权限对于组织来说是一个很大的安全方面的疑虑，也是一个棘手的问题。在云端的身份管理格外的困难，因为身份本身具有跨界的特点，而且身份管理会同时在架构上和组织上
2、产生影响。许多业者害怕使用云会把自己暴露给可能的攻击和数据破坏。另外，很多公司并没有充分的条件来在企业级别和云端管理身份认证，因为他们缺乏灵活的身份管理来囊括两种领域。云计算：提高可伸缩性的标准云计算让人们可以便利地、随时可得地通过网络访问一个可配置计算资源共享池网络、服务器、存储、应用以及服务，这些都可以迅速地准备和发布，只需要很少的管理工作或与服务提供商之间的互动（请参照此）。它让组织能够在不投资新的基础设施、不培训新员工或购买新的软件许可权的同时即时地增加处理能力或新增功能。云计算涵盖任何在互联网上实时扩展现有IT能力的所有基于订购的服务1。公开云通常是指软件即服务（SaaS）应用，像是
3、Salesforce.所提供的，还有基础设施即服务（IaaS），像亚马逊网络服务（AWS）。私有云则是指特定组织专有，并在自身场地部署、常隐藏在防火墙之后的应用或者平台。性能的可伸缩性当人们考虑可伸缩性的时候，大多数的人都会立即想到一个系统如何处理大规模事物、每秒的浮点操作等等。云端的一个关键特色是它能够通过增减计算能力来满足变化的需求，提供有弹性的可伸缩性。比如，当很紧急地需要大规模计算能力的时候，在Amazon Elastic pute Cloud（EC2）上可以非常快地升级一个应用，让它使用更大的虚拟机。把这个概念再延伸一点，采用能够支持近乎无限规模运算的N+1的体系结构，新的云端应用在
4、设计上支持线性地向外扩展。因为便于开发者的广泛使用，也因为有着令人印象深刻的效果，云计算获得了令人瞩目的成长。比如，Force.Salesfore.的云计算平台现在每季度要处理超过一百亿个事物，其中超过半数是通过它的API来完成（请参照此），而Twitter则每天处理三十亿次来自API的请求2。而互联网预计在不远的未来仍将显著增长：AT&T预测到2015年互联网流量将增加五十倍3。集成和管理可伸缩性一个与规模相关的不那么引人注意的挑战是关于组织能以什么样的速度来部署、集成并长期管理一个系统。当系统导致摩擦时比如说在管理任务中，这会造成系统可伸缩性上的障碍，对于身份管理来说尤其是这样。如果把基础
5、设施定义为企业内产生IT能力的共通硬件、软件以及网络服务，身份管理基础设施包括了在整个企业内使用的目录服务、身份和访问管理服务、网络代理以及验证系统。今天很多企业都努力想要搭建一个能够在云架构下工作，并可以按云的方式优雅地升级的身份基础设施。要能够升级来满足云端的架构与成长需要，系统架构师必须专注于对身份的优化管理和整合。对许多企业来说身份管理是一个采用云的关键性的瓶颈。架构师明白他们的眼光必须超越云可伸缩性的基本性能层面，还要去设计一个能够让身份的管理和整合也具备伸缩性的战略。一种云级别的身份结构通过不同的技术、标准和用例可以获得跨越原本分别管理的安全领域的身份信息的可迁移性，让一个领域的用
6、户可以安全地无缝访问另一个领域的数据和系统，而不需要多余的用户管理。借此联邦身份就把多种元素和领域交织在一起，就像织布一样。过去公司把网络身份存储在目录和数据库里。随着互联网的成长和云端应用的出现，他们发现需要在传统网络以外来管理身份。今天网络管理员必须管理企业和云端应用的多个账户。这种重复劳动增加了工作量，并由于管理员必须要管理多个用户身份和密码导致了安全上的隐患。与外界伙伴与承包商的合作也要求公司向外来者开放网络边界。为了保证这么多信息资产与数据的安全，企业必须无缝地采用身份管理来连接到云端。要实现成功的云端身份管理，业者必须保证身份符合云端独特的架构需要，把身份看作一种会整合、抽象、扩展
7、的结构，把身份当作IaaS交付，就像它所支持的云平台一样。身份必须符合云端需求身份概念层次结构的五个领域必须有所发展来实现云级别的身份结构：访问控制和授权；验证、联邦和单点登录（SSO）；用户XX管理和准备；审计和合规；以及云平台架构需求。访问控制和授权同时管理自身场地部署的和云端部署的应用是一个复杂的任务。在云端，没有防火墙的保护，即使对于二进制访问来说，也无法依靠网络边界来控制。今天很多用户在私有网络之外，通过互联网来访问SaaS，不需要通过公司网络。这样授权就必须进化成为分布式模型来支持网络防火墙外的用户。深度授权这个概念在三个层次上说明了授权策略变化中的粒度。第一个层次是粗粒度的访问控
8、制策略，监管用户对应用或资源的访问。第二个层次更加细粒度，在数据级别来控制访问往往通过URL。第三个层次是最细的粒度层次，控制对函数和视图的访问，有时又被称为“赋权”（entitlements）。任何可伸缩的授权模型都必须反映对应多级别粒度或深度的需求，此需求与可伸缩性紧密结合粒度越高，授权事务的量就越大。另一个升级访问控制的关键是对访问分组。在大型机上最早的访问控制方式是基于手动维护的访问控制列表（ACLs）。访问控制列表最初工作得很好，因为没有很多人使用大型机，但随着用户基数的扩大，它们变得难以操作，导致了用户组的出现。用户组访问控制可伸缩性很好，但还是需要手动地管理组成员。这又导致了使用
9、规则来决定成员和访问的动态用户组管理的出现。现在，组织使用基于角色的访问控制（RBAC）取代了用户组来反映企业的成员结构，使用基于属性的访问控制（ABAC）来处理动态许可。在云端，这些属性和角色成员都从操作系统被解耦，可以通过联邦来分布到各个系统。授权可以用分布式、联邦式的模型来解决升级问题。通过把授权过程分解成为其核心的策略元素管理、决策与实施，有可能让各个技术与组织领域组成面向授权的联邦。策略管理点、策略决策点与策略实施点必须分布在分散的地点，特别是要横跨整个云端。身份决策点提供身份数据以进行授权规则评估，还可以应用安全确认标记语言（SAML）断言语句或使用现在的HTTP头和未来的OAut
10、h 2.0。例如，OAuth利用代理的信托模型，达到把用户身份数据从用户凭证抽象出来这样一个很好的效果，还支持授权的令牌化，不过它确实需要一个理解OAuth的赋权实施架构。无论使用哪种技术，这些授权决策必须在很短时间内完成才能支持巨大的流量。验证、联邦和单点登录联邦的概念在防火墙内更为常见一些，也许最好的例子就是无所不在的微软Windows系统的域模型。企业可以定义不同组织间防火墙内信托模型，允许由本地域代理的验证通过Kerberos获得远程域的信任，这样可以把多个Windows域连接在一起，让登录对于终端用户透明。更新的联邦模型超越了私有的微软方式，放弃了Kerberos，使用一种基于XML
11、的开放标准SAML来在安全领域之间也就是说在身份提供者和服务提供者之间，交换验证和授权数据，实现了互联网上的单点登录。对于联邦和单点登录来说存在的问题是，已经过去了十来年，SAML的采用还没有超过企业应用的百分之十，很明显是由于基础设施软件的超高成本。用户XX管理与准备现在的应用，即使是那些采用了联邦方式的应用，都需要一个本地账号来做用户身份管理。挑战在于管理用户的数据，尤其一些常规的变更像密码重置和XX注册等。有了对应云端的用户管理，每个应用都会以不同方式管理用户，而且通常这种管理进行在应用的内部；用户管理API既不一致也不标准。理想情况下，开发者将使用在用户XX准备领域与SAML类似的服务
12、准备标记语言（SPML），但是实际上现在只有很少几个SPML实现。没有联邦用户XX准备API来实现本地XX的自动同步，SAML的采用就还会受到局限。另外，还缺少对SAML的个人化属性、会话上下文或即时用户XX准备的整合支持。由于缺少广泛应用的用户目录模式定义，很难构建一般用途的管理工具。审计和合规在云端审计方面的一个关键挑战是要克服SaaS应用的用户访问缺乏可见性的问题。使用公开的互联网而不是公司网络使用户脱离了网络监控工具的可控范围。和多数企业网络不同，云端是随处可访问的。然而，监管的要求是随着司法系统变化的，复杂而且时常相互矛盾。行业需要框架来对应所有的司法需要，身份管理正处在这样一个框架
13、的中心，因为很多监管都是以用户隐私和访问作为核心问题。云平台的架构需求云带来了新的架构和平台，需要服务提供者添加身份相关性。特别是，很多云服务提供者通过像是KVM或其他来自与VMware或Xen的一些托管的管理程序来提供存储或数据库服务，但这些IaaS现在还不能把身份和访问管理也作为服务来提供。虽然有着很高的使用率，但虚拟化平台无法消化使用前云计算时代网络服务器插件和代理的网络访问管理（WAM）带来的固定成本。WAM和插件之间的紧耦合已经被证明很脆弱，而虚拟云平台的“爆炸性的”、高弹性的性质使插件模型失去了可行性。行业需要一个基于代理的方法，不会加重虚拟化网络和应用服务器的负担。对于SaaS应
14、用的情形来说，整合身份管理这个工作包括实施访问控制和支持审计两方面内容。这是个挑战，而这挑战来自多租户模型，以及底层基础设施由SaaS提供者拥有并运行这样一个事实。这个事实使得为每个应用实例安装专用代理或插件变得不可能。而且，对于多数SaaS应用，收集审计日志是有问题的，因为往往它们和其他租户的数据是混杂在一起的。在某些情形下，审计的细节不够解答关键取证问题。需要一个松耦合的、非侵略性的身份管理平台来从SaaS应用本身上游施行策略。身份必须整合、扩展并抽象两个云级别身份结构的核心分别是单对多的集成模型，和通过网络效应来获得利益的延伸。另外还有对通过外化和全局采用开放标准来抽象身份的需要。身份集
15、成要集成身份基础设施和应用就需要进化成为一种中枢辐射模型。现在每个应用都要求一个不同的用户XX，可是在单对单的基础上建立联邦身份连接没有可伸缩性。唯一获得可伸缩性的方法是变换成单对多模型，在每个应用里保存多个用户身份。这个问题可以在数学上进行分解，如图1a所示，一个用户在应用中使用单独凭证的单对单模型可以被表示成凭证数量=（用户数量应用数量）。一个组织的应用的集成可以表示为数量=（公司集成应用的数量）。在图中，这些等式以线性增长，意味着对每一个建立的新连接或部署的应用，都在凭证数量或所需集成工作量上有一个对应的增长，同时增加用户和应用数量则导致指数增长。图1.集成身份基础设施和应用需要改变（a
16、）单对单模型，其中凭证数量=（用户数量应用数量），而采用（b）单对多模型，其中凭证数量=（用户数量+应用数量）。比如说，设想有一个企业，拥有一万名用户（包括顾客、雇员和合作伙伴），他们会访问十五个应用。在单对单模型下，需要十五万个用户凭证（密码）。每年通过呼叫帮助中心重置一次密码就会产生到四百五十万美元的年管理费用。假设十五个应用的软件许可证、部署、集成以及维护的费用都一样，为五万美元每连接，集成费用就是七十五万美元。虽然单对单模型可能在小规模下能够正常工作，但它是不可持续的。多数从单对单架构起步的复杂系统都变成了更具伸缩性的单对多模型。比如股票市场的交易中心和结算中心，它们都需要使用中枢辐射模型连接几百万用户和事务；同样的，像Expedia这样的旅游预订系统也提供了单对多模型来连接旅行者和很多航线。要在联邦身份结构下升级连接的数量并控
