简介： 这是有关在 IBM SmartCloud Enterprise 中构建多租户应用程序的最佳实践的第 4 篇文章，介绍如何利用 IBM Tivoli Access Manager 来提供租户感知功能、保护应用程序资源以及提供单点登录功能。

当前，云平台和基于云的解决方案已经成为现实。越来越多的企业在利用宿主软件、解决方案和服务的优势，将非核心竞争业务外包出去，从而降低成本。在构建软件即服务（Saas）应用程序的过程中，作者使用 IBM Tivoli Access Manager 作为 IBM Cloud 中的共享组件来满足很多安全需求。本文描述 Tivoli Access Manager 在实现租户之间安全性方面所扮演的重要角色。

简介

多租户用于在单个、共享的应用程序环境中支持多个客户。为了进一步发挥规模经济的效益，也应当在单个、共享的 SaaS 交付平台中支持多个 SaaS 应用程序。Saas 交付平台本身变成了支持多租户，其租户又是多租户应用程序。在此类平台中，在应用程序与应用程序租户之间实施安全约束是一个关键需求，Tivoli Access Manager 能够扮演这个关键角色。图 1 展示了运行在 IBM Cloud 中的所有 Tivoli Access Manager 组件，以及它们与其他软件组件之间的关系。

图 1：在 IBM Cloud 生产环境中运行的 Tivoli Access Manager

具体来说：

Tivoli Access Manager WebSEAL Server：一个安全代理组件，它实现对 web 服务器的访问和集中管理 web 空间，将所有 web 服务器链接到一个逻辑 web 空间。

Apache Server：充当反向代理，将来自入站请求的负载分发给 Saas 应用程序。重写每个入站请求中的 URL，以匹配所请求资源的相关内部位置。

Tivoli Access Manager Policy Server：支持策略定义和基于策略的安全管理。例如，密码规则。

Tivoli Access Manager LDAP（Lightweight Directory Access Protocol）：目录服务器，用于存储已认证用户及其权限的相关信息。

租户管理服务器：用于管理跟某个 Saas 产品、订阅了该产品的公司和用户、产品中的版本或坐席数量、产品价格等有关的信息。

SaaS 应用程序服务器：特定于每个 Saas 应用程序的应用程序服务器集群。

垂直线代表防火墙配置。本图中的防火墙仿效用于公司内部网与互联网之间防火墙的传统非军事区（DMZ）设置。它们旨在增加额外的 IP 级访问控制。

Tivoli Access Manager for e-business 是一款成熟的产品，能够为企业 web 环境提供强壮的、基于策略的安全性。它涵盖任何安全管理解决方案都具有的要素，比如用户认证、访问权限控制、审计、单点登录、高可用性和日志记录。有很多介绍它的功能的优秀文章。在下面的场景中，主要关注特定于云和租户管理的领域。

粗粒度访问控制

一般来说，可以将应用程序资源（比如 URL http://www.mycompany.com/logo.gif）分类为 不受保护的或 受保护的。任何用户不需要认证就可以访问不受保护的资源。例如，不受保护的资源可以是静态图片、登录页面、注册页面、演示、市场营销资料等。

对于受保护的资源，用户只能在认证之后，确定了用户的一些细节信息（比如其角色、所属的组织或团队），才能访问这样的资源。例如，受保护的资源可以是用户配置文件、文档、邮件、应用程序小部件等。

在 Tivoli Access Manager Policy Server 中为了简化受保护资源与不受保护资源的规范，通常利用公共 URL 前缀对资源进行分组，来对所包含的资源进行分组保护。例如：

protect /secure

unprotect /public

这些规则很容易添加到 Tivoli Access Manager Policy Server，并由 Tivoli Access Manager WebSEAL 执行。

当 HTTP 请求到达时，WebSEAL 和 Policy Server 共同确定所请求资源是否受保护。如果是，WebSEAL 确保在允许请求到达每个应用程序前对用户进行了认证 - 例如，用户是否签订了该服务？是否提供了正确的密码？

WebSEAL 还用于为请求确定 租户上下文。租户上下文包含元数据来指定用户属于哪个租户，以便实施适当的限制。例如，租户 1 可能签订了应用程序 1 和 2，而租户 2 则签订了应用程序 2 和 3。租户上下文作为 HTTP 请求头部向下游（downstream）传播，将用户身份、角色、相关的租户身份和资格告知给下游服务器。Apache HTTP 服务器基于客户资格向适当的服务调度 HTTP 请求，从而实现粗粒度访问控制，为负载均衡和稳定性提供支持。

细粒度访问控制

应用程序可能需要强制实行附加的、更细粒度的控制，以进一步严格控制对受保护资源的访问。这些附加控制可能要基于用户角色和 / 或从租户上下文中获得的租户资格。例如，一个特定的用户可能有资格创建和编辑业务流程，但是没有资格部署该流程。另一个特定的用户可能被分配有管理角色，所以他可以删除同一账户其他成员创建的资产。

每个 SaaS 应用程序独特的登录页面

在 WebSEAL 中，可利用模板页面来自定义不同的认证相关页面。然而，对于多租户 SaaS 交付平台，WebSeal 所提供的自定义级别是不够的。想要为每个 Saas 应用程序提供不同的登录页面，或者甚至需要租户特定的登录页面该怎么办？我们可以采用简单 HTTP 重定向的解决方案。图 2 展示了整个方法。

图 2：WebSEAL 支持的每个 SaaS 应用程序的自定义登录页面

用户导航到 SaaS 应用程序登录页面（箭头 1）。接着，SaaS 应用程序登录页面使用 XMLHttpRequest（XHR）将凭据传递给 WebSEAL Login Service（箭头 2）。在 Saas 应用程序登录页面中，JavaScript 对响应（箭头 3）进行解析，以检测登录成功或者失败。

如果用户试图不是先登录而是直接访问受保护的页面（例如，采用书签或者利用链接），WebSEAL 服务器将会返回其默认登录页面。可对默认登录页面进行自定义，以将用户重定向到正确的 Saas 应用程序登录页面。

可以扩充这种一般方法，以支持附加页面执行适当的重定向 - 比如密码重置；重定向到为成功登录的用户提供的不同页面。

用于不同访问的 WebSEAL 集群

有一点需要注意，可对 WebSEAL 服务器进行配置，以便要么支持基本访问认证，要么支持基于表单的认证，但是二者不同时受支持。因此，我们需要部署多个 WebSEAL 服务器，一些用于基本访问认证，另一些用于基于表单的认证，这样就能够支持不同类型的客户访问，比如 Web 表单、移动访问、Eclipse 等。

这些 WebSEAL 服务器共享公共的 Tivoli Access Manager Policy Server，以 Apache 作为前端反向代理，该代理使用 Apache mod_rewrite模块将流量路由到正确的 WebSEAL 服务器：

• 如果请求具有基本访问头（即 HTTP:Authorization），它将请求转发给启用了基本访问的 WebSEAL。
• 否则，将请求转发给启用了基于表单功能的 WebSEAL。

前端反向代理服务器还处理 WebSEAL 服务器之间的负载均衡。

利用防火墙实现安全性

IBM Cloud 是公共云，这意味着在默认情况下，每个虚拟机是从世界的任何地方可达的。然而，我们不希望虚拟机可被直接访问；例如，运行我们数据库服务器的虚拟机应该只能被我们的应用程序服务器访问；前文中所描述的资产库应该只能被我们的 Saas 应用程序访问，等等。在增加这些额外层次的安全保护当中，防火墙扮演着重要的角色。

在 “Get started with the IBM SmartCloud Enterprise” 一文中（见 参考资料），作者解释了在虚拟机监控程序级别与虚拟机级别进行防火墙规则配置各自的优缺点。我们的环境是动态变化的，需要基于使用情况方便地增加或者移除虚拟机，所以我们采用 iptables 方法来定义适合于每个虚拟机的防火墙规则。

防火墙规则的简单场景

基本 OS 映像只为输入提供一个端口：端口 22，以便传入 SSH（Secure Shell）信息。然而，在虚拟机中安装应用程序后，您可能想要开放更多的端口，以便应用程序被访问到。例如，在图 3 中有两个应用程序；应用程序 1 通过 HTTP 端口 8081 进行访问，应用程序 2 通过 HTTP 端口 8082 进行访问。

图 3 ：防火墙规则示例

然而，您可能不想让这些端口开放给那些不通过适当访问控制的任何人。这就需要增加防火墙规则来实现额外的保护。

在运行应用程序 1 的虚拟机中（9.8.7.6），增加如下防火墙规则：

-A INPUT -s 1.2.3.4 -p tcp -m tcp -dport 8081 -j ACCEPT

这将开放端口 8081，但是仅可被虚拟机 1.2.3.4（Apache Server）访问。

同样，在运行应用程序 2 的虚拟机中（5.1.2.3），增加如下规则来开放端口 8082：

-A INPUT -s 1.2.3.4 -p tcp -m tcp -dport 8082 -j ACCEPT

现在，假设可通过端口 80 访问 Apache Server（1.2.3.4），那么您可以向 Apache Server 增加如下防火墙规则，来仅开放端口 80：

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

另一个通用的模式是，通过启用 loop-back 支持，允许虚拟机接受来自其自身的输入。例如，您可能想要在虚拟机上部署操作系统代理，以便它可以将其状态报告给 IBM Tivoli Enterprise Portal，本例中的代理可能需要连接到本地运行的服务。要启用此类 loop-back 支持，可增加如下防火墙规则：

- A INPUT -i lo -j ACCEPT

最后，一定要测试防火墙规则并正确保存。确保 iptables 在虚拟机重启时用新配置而不是默认设置进行初始化。可执行如下命令保存防火墙规则：

/sbin/service iptables save

通过采用认证和防火墙规则严格管理哪些人能够访问什么资源，就可以确保运行在公共 Internet 中的云解决方案的组成部分 —— 虚拟机 —— 的安全。

结束语

安全性是采用云技术的主要限制。本文展示了如何利用 IBM Tivoli Access Manager for e-business 之类的成熟产品来实现能够保护云资源和支持多租户架构的访问控制解决方案。IBM 还发布了红皮书：“Cloud Security Guidance IBM Recommendations for the Implementation of Cloud Security”，对确保云解决方案的安全提供了更深入的介绍。