马上注册，结交更多数据大咖，获取更多知识干货，轻松玩转大数据
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
简介目的本文介绍了一些在保护 IBM cognos 10 BI 环境时需要考虑的最佳实践和准则。 本文的目标读者是负责设计 IBM Cognos 10 架构和/或开发项目的 IBM Cognos 10 BI 应用程序管理员。本文内容与最终用户无关，因为文中的大多数建议是由 IBM Cognos 管理员在交付给最终用户之前实施。 适用性本文中介绍的建议和实践不限于某个具体的平台或部署架构。文中的示例均基于 Windows 版本，但是，除非特别说明，所有描述都适用于封面上列出的产品（包括 Fix Pack (FP) 和 Refresh Pack (RP) 发行版）。 例外与除外责任尽管设计时尽可能适用于大多数安装，但某些描述可能不适用某些特定的环境。还要额外考虑一些内容，以确保本文给出的建议满足您的部署需求，并且符合您所在环境的安全策略。
保护 IBM Cognos 10 BI 环境指南IBM Cognos 10 产品提供了灵活多样的安全特性，可实现大多数（并非全部）安全环境下的集成。目前所成临的挑战是从对于测试和/或开发环境已经足够使用的稳定基础配置，转向完全的安全实现和集成。IBM Cognos 10 以开箱即用的方式提供了所需的一切内容。 以下章节将根据用来进行配置的工具分别讲解一些指南和建议。我们将讨论身份验证和授权主题，并提供一些可以遵循的最佳实践。 在开始之前，首先要清晰地定义需求，以下有一组需要在开始实施之前回答的有关 IBM Cognos 10 BI 的问题。 - 正在使用的是什么身份验证源？最常用的身份验证源是 LDAP 和 Active Directory，此外还有一些其他的身份验证源。请确保您能联系到相关资源以帮助您了解身份验证源的内容和结构，以及所需的技术信息，如服务器、端口和所需的凭证。遵循下列的最佳实践建议可能还需要另外一些具体信息。
- 您正在使用的是单个安全名称空间还是多个安全名称空间？根据需求的不同，可能会面临登录后将一个用户 “自动” 验证到多个名称空间的挑战。IBM Cognos 10 BI 不支持这样做，但可以使用 .NET 或 JavaScript 脚本技术来解决此问题。
- 用户是否会进行显式身份验证到 IBM Cognos BI，或是否要有基于其他安全层身份验证的某种 Single Sign-On (SSO)？如果需要从其他源到 IBM Cognos 10 的 SSO，则务必评估此特性是否最好具有或必须具有的特性。如果需要，那么在定义身份验证之前，先从技术上解决 SSO 的问题，因为 SSO 可能会对所需的名称空间或其配置有影响。尤其是 SSO 会影响调度，因为很多 SSO 凭证可能不适合用调度存储，因为它们可能会过期。这会导致提示用户输入用户名和密码，而用户并不知道这些，因为这是用于 SSO 的。
- 是否要使用验证到 IBM Cognos BI 10 的相同凭证来验证到查询数据库（用户直通）？这会是相当复杂且具有挑战性的设置，并且不是在所有的身份验证源和数据库组合下受支持的。看看使用已存储的数据库登录的替代方法是否可行，并注意这可能会影响身份验证，因为登录的记录必须在 IBM Cognos 10 BI 中妥善保存并保证安全。
- 需要什么等级的安全？该系统能从外部访问或只能从内部访问？如果系统能从外部访问，那么在托管 IBM Cognos 10 BI Gateway 的 Web 服务器上实现 Secure Socket Layer (SSL) 是我们推荐的最佳实践。一般来说，贵公司的安全策略会需要这么做以及其他一些额外的安全措施。这会对 IBM Cognos 10 BI 中的 SSL 配置造成影响。
- 这些数据对于内部/外部用户有多敏感？根据安全需求，您可能会想要更深入地查看加密临时文件和加密整个网络流量（甚至内部网络）。这也会对 IBM Cognos 10 BI 中的配置造成影响。
- IBM Cognos 10 BI 会与其他 IBM 产品，如 Lotus Connections、IBM Cognos TM1 或 IBM Cognos Planning 集成吗？如果事先不仔细规划，集成可能会改变安全性。在执行任何安实施之前，先与 IBM Cognos 代表讨论集成场景。
IBM Cognos 配置本节将会讨论与安全有关的设置与配置，这些均可在 IBM Cognos Configuration 中进行指定。通常是在安装后立即实施，而且这些都是之后将会介绍的后续任务的基础。 安全安装服务帐户 第一个影响安全的决定可能已经做出。很可能已经使用一个特别的帐户将 IBM Cognos 10 安装到您的平台上，该帐户可能有足够的文件系统权限来运行应用程序。但有可能环境中的策略要求使用特定的帐户运行应用程序。我们将此帐户称为服务帐户。 IBM Cognos 10 BI 其实就是一个 Java Web 应用程序，它部署在 Java 应用服务器，如 IBM WebSphere 之上。尽管 IBM Cognos 10 是开箱即用的，但是它是预先部署到 Apache Tomcat 上，它不是一个完整的 Java 应用服务器，而是一个子集。虽然是这样解释，但我们就将 Apache Tomcat 简称为应用服务器。 如果以开箱即用的方式在 Apache Tomcat 上使用 IBM Cognos 10 ，那么会有一个名为 cognosbootstrapservice.exe 的服务，它会启动 Apache Tomcat 并且可以在 IBM Cognos 10 BI Cognos Configuration 中进行配置。在 Windows 平台下，该服务注册为一个 Windows Service，默认由 Local System 帐户运行。在 UNIX/LINUX 平台下，此服务由该帐户调用 cogconfig.sh 启动脚本来运行。因此服务帐户就是运行应用服务器的帐户。 如果 IBM Cognos 10 BI 部署到不同的应用服务器下，那么该服务器会确定用来运行 IBM Cognos 10 BI 的帐户，因此该帐户就是服务帐户。 选择合适的服务帐户很重要，这是因为： - 该帐户会实例化托管 IBM Cognos 10 的 Java 运行时环境 (Java Runtime Environment, JRE) 和其他所有由 IBM Cognos 10 产生的进程，如 BiBusTKServerMain、CAM_LPSvr、BmtMDProviderMain 等。所有的 IBM Cognos 10 进程，无论是 Java 还是本机进程，均需要对 IBM Cognos 10 安装目录及子目录有不同级别的文件系统权限。
- 此帐户用于打印机访问。
- 如果在 Windows 平台下运行，该帐户将用于 SSO 与 IBM Cognos 10 之间的 Microsoft Kerberos 交互，也可能用于 Microsoft 数据库验证，如 SQL Server 或 Analysis Services。
- 将使用该帐户来创建临时文件和暂存文件。
- 当 IBM Cognos 10 被配置为将 Auditing 输出导入操作系统日志设备时，使用该帐户来与操作系统日志设备进行交互。
最佳实践是使用一个专门命名帐户，专门分配给 IBM Cognos 10 以执行安装（提供文件系统所有权）和 IBM Cognos 10 运行。安装帐户和服务帐户可以为不同帐户，但必须额外注意文件系统的权限。 在 Windows 平台下，使用的是已命名的域帐户户作为服务帐户，而不是 Local System 或 Network Service，该帐户必须在本机上进行身份验证，并且应该具有足够的文件系统权限，以及必须在 User Account Control 中进行适当的配置。根据对复杂特性的使用，如 Kerberos SSO、用户直通到 Microsoft 数据库以及登录到操作系统用户，可能还需要额外的 Windows 权限。 在 Linux/UNIX 平台下，服务帐户应该与安装帐户共享一个主组，以简化文件系统访问的问题。应该赋予服务帐户及其主组对安装目录及子目录具有完全权限，而对于 “其他” 的文件系统权限应该撤销。我们建议应该将安装目录及子目录的所有权只赋予安装所有者及共享的主组。 可在以下的 IBM Cognos 10 信息中心链接中找到关于服务帐户的信息。 临时文件 与大多数产品一样，IBM Cognos 10 BI 在普通报告函数中使用了临时文件。在默认情况下，临时文件写入磁盘上的临时文件夹中。默认的位置是 <COG_ROOT>/temp，其中 <COG_ROOT> 表示 IBM Cognos 10 BI 安装目录。而该目录可在 IBM Cognos Configuration 中配置。该属性名为 Temporary files location，并位于 Environment 小节下。为了限制对该目录下临时文件的访问，我们建议文件系统权限设置为只允许服务帐户对该目录有完全控制权限，拒绝所有其他帐户的访问。如果临时文件位置转移到 IBM Cognos 10 BI 安装目录之外，那么可能需要调整文件系统权限。 IBM Cognos 10 BI 还可以将用户会话文件保存到本地文件系统以减小 Content Manager 的负载。如果该特性已设置，那么为用户会话文件指定的位置应该只能由服务帐户进行访问。请记住，该特性只影响已安装的 Application Tier 组件实例。关于将用户会话文件保存到本地文件系统的更多信息，请参考以下的 IBM Cognos 10 信息中心链接。 加密临时文件 如果模型或最近查看的报告中包含敏感数据，那么处理这些生成的临时文件时，应该采取额外的措施。IBM Cognos 10 BI 能够加密这些临时文件，从而使这些文件不能被非授权用户访问。但不适用于用户会话文件。可以使用 IBM Cognos Configuration 来修改启用临时文件加密的属性。该属性名为 Encrypt temporary files? 并位于 Environment 小节下。应将该值设为 True 以启用该属性。所使用的加密方法是一个基于会话的密钥，使用的是已配置的保密密码。 Dispatcher Password 从 IBM Cognos BI 8.4 开始，就有一个 Dispatcher Password 属性，它必须与所有已安装的调度程序实例相匹配，其中包括 Application Tier 和 Content Manager 组件。密码的作用与其中的共享秘密一样，它可以防止不知道秘密的 Dispatcher 进入 IBM Cognos 10 BI 系统。作为最佳实践，最好修改 Application Tier 和 Content Manager 安装中的所有默认密码。可以使用 IBM Cognos Configuration 来修改设置 Dispatcher 密码的属性。该属性名为Dispatcher password，并位于 Environment 小节下。 内容存储数据库 内容存储数据库是 IBM Cognos 10 BI 系统的中央存储库。显然应该采取最高级别的预防措施来保证数据库可用并且受到恰当防护。IBM Cognos 10 BI Content Manager 组件通过单个数据库登录来处理对内容存储数据库的访问。登录是在 IBM Cognos Configuration 中指定，并以加密格式保存在 IBM Cognos 10 BI 主配置文件 <COG_ROOT>\configuration\cogstartup.xml 中。但是，如果可以从 IBM Cognos 10 BI 外部访问数据库，那么会破坏 IBM Cognos 10 BI 系统稳定性和安全性。尽管敏感数据会在内容存储库中以加密形式保存，但已保存的报表输出或其他默认情况下非敏感信息不会被加密，因此确保其他帐户在数据库层对 内容存储数据库无法进行读/写访问就非常重要。这必须在数据库层实现。关于详细情况，请咨询您的数据库管理员。 身份验证的概念IBM Cognos 10 BI 通过使用名为身份验证提供程序的小软件将身份验证推迟到外部身份验证源中。每个身份验证提供程序均附属于某一特定类型的身份验证源，如 LDAP、Microsoft Active Directory 或 SAP BW，并使用它来实现读取安全对象和处理身份验证过程的逻辑。最重要的是，很多身份验证提供程序还提供 SSO 支持。除了特殊类型的提供程序，每个身份验证提供程序还以 IBM Cognos 10 BI 名称空间 的形式公开从外部身份验证源读取的对象。对于单一 IBM Cognos 10 BI 系统，可以同时配置多个名称空间，因此，来自多个身份验证源的用户均可以访问 IBM Cognos 10 BI。 IBM Cognos 10 BI 中还有一个特殊的名称空间，称作 Cognos 名称空间。它不属于任何身验证源，仅包含组和角色，并不包含用户。Cognos 名称空间不可用于身份验证中，但可以用来为来自外部身份验证源的名称空间和定义身份验证的应用程序的安全对象提供逻辑映射层。管理员可以在 Cognos 名称空间中创建组和角色，并为 Cognos 名称空间中创建的对象分配诸如用户、组和角色等外部安全对象。身份验证概念将会在本文后续部分讨论。 外部名称空间和 Cognos 名称空间均可在 IBM Cognos Configuration 中配置。还有一些常用设置会影响身份验证，无论应用何种类型的名称空间。我们将从指定常见设置的最佳实践开始讨论。 休眠超时 休眠超时设置是用来指定从客户端到 IBM Cognos 10 BI 的验证会话超过多少秒会被认为过期。过期期限设置过短可能会导致更频繁的身份验证提示，设置较长的过期期限会增加用户在屏幕锁定保护设置不恰当情况下访问无人值守计算机上的浏览器的风险。但如果安装了 SSO，它将会在后台悄悄对用户进行验证，而不会造成任何负面影响。我们建议，无论何时均需要配置 SSO。休眠设置是在 IBM Cognos Configuration 中 Security > Authentication 小节下的 “Inactivity timeout in seconds” 属性进行设置。最佳实践是根据您的安全策略进行设置。一般来说设置为 900 秒或 15 分钟。这是默认值 3600 秒的四分之一，但它较好地平衡了每个活动会话的资源消耗和用户便利。 Passport 加密 成功的身份验证将会导致在 Content Manager 组件的内存中创建会话对象。这些会话对象将包含敏感的用户数据。如果需要，可以加密这些内存中对象，防止信息被恶意软件或其他内存读取程序访问。要启用加密，使用 IBM Cognos Configuration 将 “Security > Authentication” 小节下的 “Enable the encryption of passport credentials?” 属性设置为 True。请记住，这会对身份验证和其他需要访问用户凭证的操作的性能造成轻微的影响。最佳实践是保持禁用状态，除非您的安全策略有特别的要求。 会话共享 当单个工作站上的多个客户端（Framework Manager、Transformer、Planning 等）访问同一个 IBM Cognos 10 BI 系统，他们可能共享一个验证会话。虽然这有助于减少在 IBM Cognos10 中存在的并发活动会话数量，但它比单独管理每个客户端会话的安全性要低。另一方面，需要在单一工作站上实现多个客户端之间的 SSO。IBM Cognos Configuration 中要设置的属性是 “Security > Authentication” 小节下的 “Allow session information to be shared between client applications?”。该属性的默认值是 False，最佳实践是将其保持为 False，除非一台工作站上有多个客户端应用程序，则需要 SSO。 限制对 IBM Cognos Connection 的访问 当为身份验证配置一个名称空间时，表示来自底层验证源的所有用户都能通过 IBM Cognos BI 验证并访问 IBM Cognos Connection。然而，并不一定总是这样，因为可能需要限制对已配置身份验证源中包含的所有用户子集的访问权。在 IBM Cognos 10 BI 中，这可以通过利用 IBM Cognos Configuration 中 “Security > Authentication” 小节下的 “Restrict access to members of the built-in namespace” 属性设置来实现。如果该属性设置为True，那么对于非 Cognos 名称空间用户的所有直接和间接访问都会被拒绝。Cognos 名称空间是内置的名称空间，用来将外部验证源的用户、组和角色映射到已定义应用程序特定的安全模型中。关于 Cognos 的更多信息，请参考 “身份验证概念和最佳实践” 小节。通过将用户所在的外部名称空间的用户或组/角色分配到 Cognos 名称空间中的组或角色，该用户就能隐式成为 Cognos 名称空间成员。 举例：用户 Robert Smith 和 Marla Spears 已经在 LDAP 源中定义，该源已配置为 IBM Cognos 10 的 LDAP 名称空间。在 Cognos 名称空间中 给 Robert 分配给了 Consumers 角色，然而未在 Cognos 名称空间给 Marla 分配任何组或角色。如果 “Restrict access to members of the built-in namespace?” 属性设置为 True，那么 Robert 将能够通过 IBM Cognos 10 验证，并可以访问 Cognos Connection，但 Marla 不可以，因为她不属于 Cognos 名称空间的任何组或角色。 自动更新的可信任凭证 IBM Cognos 10 中有个新的特性，可以让 IBM Cognos 10 BI “自动” 更新存储的凭证，用于调度。该特性可以在 IBM Cognos Configuration 中 “Security > Authentication” 小节下的 “Automatically renew trusted credential” 属性设置。要了解该设置的影响，需要看一些细节内容。 当用户创建一个可信凭证，使用调度保存，或提供给运行报表而非保存凭证的用户时，会创建一个对象，它包含了当前进行验证用户的所有名称空间的凭证。结果由于一个用户可以在一个会话中，通过多个名称空间进行验证，可信凭证可能包含多组凭证，每个名称空间一个。会话进行验证的第一个空间称为主名称空间。 可信凭证很特别，因为存储它的名称空间凭证必须随时可用，而不依赖于任何时间戳。这就将如 Kerberos 令牌或 SAP 令牌这样的 SSO 凭据排除在外，因为它们会在很短的时间后过期并变得不可用。因此适合的可信凭据一般是包含用户名和密码的键值对。但是，对于基于 SSO 的 IBM Cognos 10 BI 身份验证，没有可存储在可信凭证中的可用名称空间密码。因此，该特性只对基本身份验证起作用，用户可以在登录屏幕中输入用户名和密码。这种情况下，系统将会在所有可信凭据中查找该用户，并且用刚输入的凭据更新他们。 当该属性设置为 Primary namespace only（默认值），这意味着仅用一个凭证更新可信凭证，然而 All namespaces 值表示会更新当前通过身份验证的所有名称空间的凭证。最佳实践是，如果名称空间的验证不是由 SSO 进行，那么将它设置为 Primary namespace only 值，否则设置为 Off 值。 名称空间 特定于名称空间类型的指南： LDAP 惟一标识符 一旦用户通过验证获取 IBM Cognos Connection 门户的访问权，就会将名为 CAMID 的用户帐户引用存放在内容存储数据库中。该 CAMID 主要是由映射到 IBM Cognos Configuration 小节下用于定义名称空间的 Unique identifier属性的值组成的。在默认情况下，该属性映射到 dn（可区分名称）。所有的 LDAP 服务器均会使用 dn 属性填充每个条目，这将会确保无论 LDAP 服务器类型如何，总有一个基于惟一标识符的属性。然而，这种做法无法确保用户帐户是真正惟一的。考虑以下场景， Company ABC 公司购买了 IBM Cognos 10 BI 并根据用户需要成功设计出产品。使用了一个 LDAP 名称空间连接到企业目录服务器。由于历史原因，默认的 IBM Cognos 10 BI LDAP 配置基于 Sun One Directory Server，因此它们在 Unique identifier 属性的值设置为 dn。北美区销售副总裁 John Q. Smith 经常使用 IBM Cognos 10 BI，并将其敏感数据和可预测报告存放在 IBM Cognos Connection 门户的 “My Folders” 部分。根据企业命名惯例 ”姓氏，首字母"，他的网络用户帐户为 SMITHJ，创建在 North America 用户文件夹下。它会为 John Q. Smith 分配如下的 dn： uid=SMITHJ, cn=North America, dc=Company ABC, dc=com 到目前为止，一切正常。但是，现在 John Q. Smith 决定跳槽到别的公司，因此从企业 LDAP 层级中删除他的用户帐户。几个月后雇佣了一名初级经理 John X. Smith。根据 ABC 公司的命名惯例，John X. Smith 使用 SMITHJ 网络帐户，因为它是可用状态。这会赋予 John X. Smith 一个如下的 dn： uid=SMITHJ, cn=North America, dc=Company ABC, dc=com 当 John X. Smith 登录到 IBM Cognos Connection 并且第一次在 “My Folders” 中保存报告时，他发现他的文件夹中塞满了包含敏感数据的报告。之所以发生这样的事，是因为基于属性的惟一标识符随着时间变化，变得不再具有惟一性，如以上示例所示。确保这种场景不会发生的惟一方法是，对惟一识别符使用一个属性，该属性能为从 LDAP 服务器中读取的每个条目提供全局惟一值。 大多数 LDAP 服务器都提供这样的属性，一般作为操作属性 的一部分。操作属性是只读的，而且只能由 LDAP 服务器维护。有些 LDAP 浏览器不会默认显示，需要显式启动读取/显示。查看您的 LDAP 服务器文档，了解哪个属性用作某个条目的全局惟一标识符。一些示例是由 IBM Tivoli LDAP 使用的 ibm-entryuuid，当通过一个 LDAP 源访问时 Active Directory 使用的 objectGUID 或 Sun One Directory 服务器使用的 nsuniqueid。 LDAP 名称空间的最佳实践是使用全局惟一的属性作为惟一标识符属性。 当然，ABC 公司如果有稳定的安全基础架构，那就不会允许创建两个 SMITHJ 帐户（至少不会用相同的内部惟一标识符），但是实现这样简单的配置更改将会为您的部署添加额外的安全层。 请注意：必须在将身份验证应用到 IBM Cognos Connection 门户和/或允许用户访问 IBM Cognos 10 BI 之前修改属性映射。如果属性映射是事后的行为，并且稍后修改，所有对象安全将是无效的，而且用户也无法看到自己的个人内容。这是因为设置更改后，会为每一个基于新的属性登录进入的用户创建一个新的 CAMID，用作惟一标识符，因此必然在内容存储库中创建一个新的用户帐户。值得注意的是所使用的属性必须是可用于所有对象，如组、文件夹和用户。如果选中的属性只对用户有效，那么当管理名称空间时，一些对象就不会出现在 IBM Cognos Connection 中。 LDAP 连接 IBM Cognos 10 BI LDAP 验证提供程序在连接处理和用于绑定到 LDAP 服务器的凭证可以多种方式进行配置。目前这些方法仍处于实验之中，看哪一种实现起来效果最好。 提供程序主要采用两种类型的连接，一种是遍历式的搜索，另一种是与用户会话动作相关的搜索。 遍历连接可以使用提供的绑定凭证建立，然后池化并重用。默认的池大小是 20，连接直到产品停止后才会关闭。为了配置池的大小和该类型提供程序的连接丢弃是否会造成影响，可以在 IBM Cognos Configuration 中 “Security > Authentication” 小节下名称空间的 “Advanced properties” 中设置 minimumLDAPPoolSize 和 maximumLDAPPoolSize。如果这两个属性均设置为 0，连接就不会被池化而且会在使用后立即关闭。 对于用户会话连接，使用用户登录时提供的用户凭证来绑定提供程序，除非 “Use bind credentials for search” 属性设置为 true。 这会导致使用 “Bind user DN and password” 属性中指定的值。那些连接会一直保持连接状态，直到用户会话结束。如果想要最大限度减少连接的使用，可以在 “Advanced properties” 中指定 unbindLDAPHandleAfterUse 属性，将该值设置为 true。结合使用这些高级属性可以使 LDAP 服务器的开放连接达到最小数。 大量客户量（同时登录用户超过 50 个）的最佳实践是使用 unbindLDAPHandleAfterUse 属性，并保持池的大小不变，因为 20 个连接不会对 LDAP 服务器造成大的影响。如果您的策略要求保持最小的开放连接数，那么就禁用查找池。 Microsoft Active Directory 在配置 Microsoft Active Directory (AD) 名称空间时，可以利用基于 Microsoft DNS 的定位服务，它可以在故障转移场景中找到可用的域控制器。它允许不为 AD 名称空间的 Host and port 属性中的主机指定特定的域控制器名称或 IP 地址，而是域的 DNS 别名，如 domain.company.com。这可以让 DNS 服务在所有情况下返回可用的域控制器，因此，这也被认为是客户端采用的最佳实践。 密码学IBM Cognos 10 BI 采用 Public Key Infrastructure (PKI) 概念来实现加密以及支持加密 HTTP 通信的 Secure Socket Layer (SSL) 协议的基础。其细节内容已超出本文档范围，但要对默认设置做些修改，才能满足基本的安全需求，并符合最佳实践。 标识 每个已安装的实例（包括在所支持的平台上单个目录安装的一个或多个组件）均有一个 IBM Cognos 10 BI 标识。因此甚至在同一台机器上的两个不同目录中的两个安装实例，也被认为是不同的实体。当用来加密 IBM Cognos 10 BI 中已保存的或临时数据的当密码术（用在 IBM Cognos 10 BI 中加密保存、临时或暂存数据）起作用时，这些就是相关的。标识的概念源自于 X.509 标准，是由 Distinguished Name 来定义， 它由 IBM Cognos Configuration 中Security > Cryptography > Cognos > Identity name 小节下的 “Server common name”、“Organization name” 和 “Country or region code” 所组成。需要修改这些字段的默认值，从而保证每个安装均拥有一个不同的标识。当 IBM Cognos 10 BI 的内部通信切换到 SSL 时，这非常重要，但通常最佳实践是定义这些属性。 最佳实践是指定一个惟一的 “Server common name” 属性。该值应该是服务器完全认可的 Domain Name System (DNS) 名称。对于在一台主机上安装多个实例并共享 DNS 名称的情况，在每个设置中调整 Organization name 属性以区分各个实例。 CA 服务密码 PKI 的一个核心元素是 Certifying Authority (CA)，它表示信任的根，发布并且签署证书，从而批准其他条目的标识。IBM Cognos 10 BI 包含其自身的 CA 服务，它位于 Content Manager 组件中，在默认情况下，用来签署 IBM Cognos 10 BI 所使用的证书。这对于客户端不返回共同的 CA 服务或安全需求允许使用应用程序特定的 CA 的安装来说，非常灵活。 第一次在任何已安装的实例上保存配置时，会要求 CA 服务为特定的已安装实例签署证书，从而批准实例的身份。这对于只有可信的实例才能访问 CA 服务的 IBM Cognos 10 BI 部署的集成和安全来说，非常重要。这就是为何内置 CA 服务要受密码保护的原因。密码在 IBM Cognos Configuration 中 “Security > Cryptography > Cognos” 下的 “Certificate Authority settings” 小节的 Password 属性中设置。 最佳实践是修改密码的默认值。为此，要在进行第一次保存之前，在 Content Manager 安装组件的配置中指定新密码。然后在初次保存各个安装配置之前调整其他所有实例的密码。 Keystore 密码 证书存储在名为 key stores 的特定文件中。文件为二进制格式，并根据访问它们所需的密码进行加密。IBM Cognos 10 BI 对每个实例使用三组不同的键对和关联证书，一个用于加密，一个用于签署，另一个用于 Certifying Authority。为此颁发的每个键对和证书都保存在单独的密钥库中，并受密码保护。 每个证书在 IBM Cognos Configuration 中 “Security > Cryptography > Cognos” 之下都有一个单独的小节保存各自设置。密钥库密码是在 <key purpose> password 属性中指定，其中 <key purpose> 是 Signing key store、Encryption key store 或 Certificate Authority key store 其中一项。 最佳实践是在首次保存实例的配置之前修改密钥库密码的默认值。 Cognos 应用程序防火墙Cognos Application Firewall (CAF) 是用来补充已有的 IBM Cognos 10 BI 安全基础架构的工具。应用程序防火墙作为 IBM Cognos 10 BI Dispatcher 的智能代理，确保发送给它的 HTTP 和 XML 请求能安全处理，并且发送给外部客户端或服务的输出响应进行适当解码并安全。 这里的安全指的是会威胁系统安全的参数数据、HTTP POST 数据和恶意请求。最常见的恶意数据形式有缓冲区溢出、跨站点脚本攻击（XSS 链接），或者是对有效页面进行脚本注入、重定向到其他网站或 SQL 注入，或者是基于会话标识符或基于 cookie 的攻击。Cognos Application Firewall 能够充分保护 IBM Cognos 10 BI 免受这些攻击，并确保只处理有效的参数和数据。 Cognos 应用程序防火墙是由 IBM Cognos Configuration 中 “Security > IBM Cognos Application Firewall” 小节下的设置所控制。如果要启用 CAF，那么 “Enable CAF validation?” 属性必须设置为 True。 由于它对整个系统安全和稳定至关重要，最佳实践是千万不要在产品环境中禁用 CAF。 有效域或主机 CAF 配置中最重要的属性是允许重新定向或允许获取数据的有效域或主机的列表。这指的是诸如在仪表板显示来自外部 URL 的摘要、包含来自外部服务器的图片、集成 IBM Cognos TM1 Contributor 或重定向到 Lotus Connection 主机以创建 Activity 这样的功能。 以上提到的每个场景都需要在有效域中加入一个条目，用于 CAF。CAF 将用来访问外部（到 IBM Cognos 10 BI）资源的 URL 和有效域或主机列表进行比较，若发现匹配时，才会将请求发送到外部资源。显式允许的主机名或与域后缀列表通常被称为 white-list。CAF 会阻止 white-list 中不存在的 URL。可以在 NetBIOS 表示法中指定主机名（例如，“MyServer”）或使用通配符指定域后缀（例如，*.domain.com）以允许来自特定域的所有主机。 逗号分隔符列表是在 IBM Cognos Configuration 中 “Security > IBM Cognos Application Firewall > Valid domains or hosts” 属性之下指定。 最佳实践是尽可能显式列出主机名并只在可信网络中使用更通用的域说明符。
IBM Cognos 连接在 IBM Cognos 10 BI 中，IBM Cognos Connection 门户是用来配置和管理所有关于授权的安全相关设置。先是为受保护的特性和函数定义哪个外部身份验证源生成的外部安全对象，如用户、组和角色，并为应用程序内容（如数据包、报告和仪表板）定义对象安全。 IBM Cognos 10 信息中心拥有大量关于此领域的具体信息，因此我们只介绍一些基本知识，并介绍一些额外的建议，对已有的文档增加价值。 授权概念和最佳实践理解 IBM Cognos 10 BI 授权的第一步是理解其中涉及的对象。简而言之，授权是通过定义以层级关系组织保存在内容存储库中的可保护对象和功能而起作用。对象的层级关系是在首次启动 IBMCognos 10 BI 时进行初始化，使用默认对象和权限创建并预填充内容存储库表格。其中的对象为 Cognos 名称空间，其中添加了预定义的角色和内置对象，如 Everyone 组和 Anonymous 用户。 请参考以下的 IBM Cognos 10 信息中心链接，获得有关初始的内置对象和预定义角色的更多信息。 默认的权限，与其他组权限一样，定义使用何种类型的名称空间访问用户、组或角色，包括 Cognos 名称空间，必须是受保护的对象或函数。在初始化时，Cognos 名称空间中没有任何从外部安全对象到权限的设置。授权只是根据来自 Cognos 名称空间的对象定义的。这对于实现关于授权的最佳实践来说，其实是个很好的出发点，因为该方法非常灵活，而且易于管理，是想要获得的最佳实践。 初始的访问权限可在以下的 IBM Cognos 10 信息中心链接中能够找到： 说得详细一点，首先通过为权限分配用户、组和角色来定义授权，进而再为安全对象（如报告、调度、安全的函数或能力）定义。由于用户只能来自于外部名称空间，因此 Cognos 名称空间不支持用户（内置匿名用户除外），管理员需要显式或隐式将用户分配给安全的 Cognos 对象。隐式是指分配用户成员的组或角色。 如果在权限中显式引用用户，那么权限就依赖于用户来源的名称空间。如果名称空间变得不可用，或者用户的惟一标识符发生变化，那么该引用就失效了。这就是用户的惟一标识符应该基于身份验证源的某个全局惟一属性，而不是基于依赖结构的信息的原因。对于 LDAP 服务器来说，DN 实际上是某一条目的路径。如果用户在 LDAP 对象层级中的位置发生变化，该路径就会变化，如果该用户是通过 DN（默认值）在 Cognos 中进行识别，那么用户的 Cognos 惟一标识符就会改变，权限就会失效。遵循上述的惟一标识符的最佳实践，特别是 LDAP 名称空间，要防止出现这样的情况。Active Directory 就很安全，因为 objectGUID 不依赖于结构化的信息。此场景下也可适用于隐式引用，因为外部组或角色引用的语句也是 true，IBM Cognos 10 BI 通过其惟一标识符来识别它们。 另一个挑战是可能需要修改底层的身份验证源。现在可以在测试环境中使用 LDAP，在生产环境中使用 Active Directory 实例。这意味着在这种情况下，来自外部名称空间的对象被直接分配给了权限和函数，对于那些名称空间的引用也会失效，因为不同的名称空间会为对象分配不同的惟一标识符。 为了应对这项挑战，有一个关于制授权的最佳实践，权限、功能和安全函数只对来自 Cognos 名称空间的组和角色进行引用。这意味着只用 Cognos 名称空间中创建的组和角色来定义权限。例如，为了让某一组用户使用 IBM Cognos 10 Studio，可以使用 Cognos 名称空间中的一个预定义角色或专门显式创建一个新角色并将该角色指定给相应的功能。尽管在 Cognos 名称空间中创建多个新的组或用户看上去可能有些麻烦，但实际上这大大增值。原因有， - 权限中用到的对象的所有引用都保存未曾使用的状态，即使被引用的角色/组的成员发生改变。
- Cognos 名称空间的内容可能在部署过程中被迁移到其他 IBM Cognos 10 系统中。
- 从外部空间到 Cognos 名称空间项的创建或分配可以通过 IBM Cognos 10 SDK 自动化完成。
考虑以下这个简单的示例， 在测试环境中开发一个项目，该项目使用简单的 LDAPA 提供程序，并带有一些测试用户。项目团队创建授权，从而该项目特定的组和角色对象可添加到 Cognos 名称空间中，忽略或删除默认的 Cognos 名称空间项。下一步他们将来自 LDAP 提供程序的用户和组分配给新的项目特定的 Cognos 名称空间对象项，接下来根据新的 Cognos 名称空间对象为工作室功能、数据包访问甚至是 IBM Cognos Framework Manager 安全过滤器（它是内置于模型中用于查询数据的）定义权限。 当在测试环境下完成开发时，将由数据包、报告等内容组成的 IBM Cognos 10 应用程序部署到预生产环境中，该环境使用 Active Directory，并且有着上千个用户。这意味着会添加不同的用户，并且对外部名称空间对象已有的引用会失效。 尽管如此，由于项目遵循最佳实践，权限中具有所有的引用，功能和安全函数只对 Cognos 名称空间中的组和角色起作用，因此可以将 IBM Cognos 10 应用程序导出到包含 Cognos 名称空间的部署中。这可以将所有的权限保留到目标环境中，只要调整 Active Directory 中的用户和组与 Cognos 名称空间中定义的角色和组的对应关系即可。其余未发生变化的内容不需要重新定义，或只需调整权限。 这大大节省了实践，并保证了项目的灵活性。另外，如果在 Active Directory 中定义了组来保存用户，并仅仅把 AD 组分配给 Cognos 名称空间组和角色，那么甚至可以在 AD 中而不是 Cognos 中管理部分认证。 对于某些客户端来说，这非常重要，因为标识管理集成或访问管理过程可能已经设置好了。 用户、组和角色用户维护 IBM Cognos 10 BI 将用户配置文件及相关内容存储在内容存储数据库中。在用户很多的环境中，这可能会占用很大空间。从身份验证源中删除用户，在很多公司都是常见的现象， 那么为什么要在内容存储中保存过期的用户配置信息和内容呢？ 以下最佳实践假设在从身份验证源删除用户帐户 之前 就从 IBM Cognos 10 BI 中删除了用户的配置信息。 - 使用 Directory Administrator 角色成员的 userid 登录 IBM Cognos Connection。
- 单击 Launch > IBM Cognos Administration。
- 在 IBM Cognos Administration 中，选择 Security 选项卡。
- 单击要包含要删除用户帐户的名称空间。
- 找到要删除配置信息的用户。如果名称空间层级很深并且/或者不知道用户帐户位置，就使用 Search 功能。查找图标是一个放大镜，在右上方。
- 在 Actions 列，单击 More... 链接。
- 单击 Delete this user's profile 链接删除配置信息。
- 单击 OK 确定删除用户配置信息。
在大多数环境中，主动删除用户帐户可能不太现实。幸运的是，IBM Cognos 10 BI 提供了一种机制可以同步内容存储中保存的配置信息与关于用户帐户的底层外部名称空间。 - 以对 IBM Cognos 10 具有管理员访问权限的用户登录到所有的名称空间中，这将会被认证/检查。
- 在 IBM Cognos Connection 中选择 Launch > IBM Cognos Administration。
- 选择 Configuration 选项卡并单击左侧菜单中的 Content Administration。
- 单击 New Content Maintenance 按钮的向下箭头并选择 New Consistency Check 链接。
- 输入名称和可选的描述信息并且/或者屏幕提示，然后单击 Next。
- 选择外部名称空间进行一致性检查，然后单击 Next。用户必须通过所有选中名称空间的验证，以便提高效率。此时如果未通过任其一个名称空间的验证，将会把该名称空间从任务中剔除。
- 选择 Save and run 仅执行一次任务，Save and schedule 安排稍后执行或者循环执行的间隔时间，或者 Save only 不执行任务，然后单击 Finish。
- 如果选择执行一次，那么指定一个执行维护任务的时间，然后选择 Find only 或 Find and fix 所有选中名称空间中不一致的地方。根据之前所述，这需要用户现在运行的任务通过所有名称空间的验证。单击 Run 启动任务，然后在出现的对话框中选中 “View the details of the content maintenance task after closing the dialog” 选项。这会前进至一个页面，该页面可以通过单击右上方的 Refresh 来刷新，直到状态变成成功或失败。所有关于特定用户的信息将会显示在该页面的列表中。
- 如果选择了安排此任务执行，将会保存一个新的调度，以及基于当前验证的可信凭证。该可信凭证将会包含所有当时通过验证的名称空间。指定执行的时间间隔和时间，并选择 Find only 或 Find and fix 作为使用模式。
该任务会执行一个一致性检查以验证存储在内容存储数据库中的用户配置信息是否与外部名称空间同步。如果在外部身份验证源中找不到任何用户，而在内容存储中已有配置信息，将会记录一条消息，说明该帐户已经不再外部身份验证源中。如果选中了 Find and Fix 模式，将会从内容存储中删除用户配置信息。 最佳实践是安排一个内容存储维护任务，至少一个月执行一次这项操作，以避免浪费内容存储中的空间。 关于该主题的更多信息，可查阅以下 IBM Cognos 10 信息中心的 IBM Cognos 10 BI 管理和安全指南： 角色/组命名 要组织 Cognos 名称空间中的角色在大规模部署中非常繁琐，为了减轻这项负担，我们建议创建文件夹对角色进行逻辑分组。接着这些文件夹名称可以采用角色的 search path 的一部分。search path 指的是描述内容存储对象层级中对象位置的路径。例如，可以创建两个文件夹，在每个文件夹中，可以创建一个角色，而角色名可以是一样的。例如，在 Cognos 名称空间中创建两个文件夹，一个名为 Roles East，另一个名为 Roles West。在每个文件夹中，创建一个名为 Data Administrators 的角色。 Directory > Cognos > Roles East > Data Administrators
Directory > Cognos > Roles West > Data Administrators 允许两个角色名称相同，是因为父文件夹的名称会成为每个对象的查找路径的一部分。同时，对于 Cognos 名称空间中的对象，这些对象的内部 ID ，即 CAMID，也包含查找路径的一部分。 CAMID(":Roles East ata Administrators")
CAMID(":Roles Westata Administrators") 尽管这种类型的命名约定有效，而且 IBM Cognos 10 BI 也支持，但不推荐这么做。这种技术可能导致在定义权限或对象安全时出错，因为当在成员列表中显示时，对象看上去是一样的。如果运用安全的人不知道这两个组不同，对某个对象的访问批准或拒绝就可能出错。如以下例子所示，IBM Cognos Connection 没有提供额外的信息，无法一眼看出哪个角色对象属于哪个文件夹。 例 1：IBM Cognos Connection 中的角色成员列表显示两个成员具有相同的名称，无法一眼分辨出来![]() 如果部署过程中确实需要创建相同名称的角色，使用工具提示可以分清二者。只要将鼠标移到省略号（…）上，就可以显示对象的完整路径，如下所示。 例 2：IBM Cognos Connection 中的角色成员列表再次显示名称一样的成员，但工具提示通过显示查找路径显示了上下文信息![]() 应该设置命名约定以避免为角色和/或组取同样的名称。常见的做法是为各个条目添加前缀，如 “R_” 表示角色，“G_” 表示组，如果需要，再加上其他前缀以表示其来自哪里。例如，“R_HR_Approver” 和 “R_Marketing_Approver” 可以是来自不同查找路径，甚至是相同路径的角色。 在以上有前缀的例子中，就能分辨出这两者。 权限IBM Cognos 10 信息中心提供大量关于权限及其用法的详细信息。理解其中的概念非常重要，可以避免走很多弯路。 拒绝优先级 您可以批准或拒绝对某一项的访问。被拒绝的访问具有比被批准的访问更高的优先级。因此，当您拒绝特定的用户、组或角色访问某一项时，您可以替换其他批准访问此项的策略，如果批准和拒绝权限相冲突，那么访问就会被拒绝。例如，有一个用户属于两个组。一个组允许访问某个报告，另一个组拒绝访问该报告。那么此用户对报告的访问就会被拒绝。 最佳实践是，只有在确实需要的情况下才拒绝访问。一般情况下，管理员最好显式批准权限，而不是拒绝权限。 只通过显式覆盖方法来消除继承关系 从父项获取访问权限。如果没有显式定义访问权限，此条目会从父项获取访问权限。您可以替换/覆盖这项功能，通过为子项显式定义权限权限来消除这种父项权限的继承关系。 其他作为子对象的对象能够从其父对象中获得权限。这样的例子有报告规范和报告输出。这些对象可通过使用 IBM Cognos 10 SDK 进行操作，但无法使用 IBM Cognos Connection 为这些对象设置权限。 删除预定义的组和角色 如果在 Cognos 名称空间中删除预定义的组或角色，那么基于它的访问权限也会被删除。在 IBM Cognos 10 中，您可以通过在 Cognos 名称空间中创建一个具有同样名称的新组或角色来还原它们，它们会具有相同的内部 ID (CAMID)。对于外部组或角色（通过身份验证提供程序从外部身份验证源读取的），查看以下身份验证提供程序如何处理这些情况。一般来说，无法重新创建基于 ID 的访问权限，但如果是基于名称的，则可以重新创建。使用 DN 属性作为惟一标识符的 LDAP 名称空间就是一个例子，该标识符只是个字符串。但是，如前所述，它能具有对用户配置信息进行多余访问的风险，所以这不是最佳实践，因此，一般情况下可以使用删除组和角色的语句。除非您确信不再使用组和角色，否则一定不要删除它们。分配给该组或角色的权限就会全部丢失。 能力在 IBM Cognos 10 BI 中，有很多安全的函数和特性可以通过将权限分配给相应的能力来控制。IBM Cognos 10 信息中心的以下链接中包含了更多关于安全的函数和特性的信息。阅读其中的描述并充分理解在安全设计中允许对特性或能力的访问造成的影响非常重要。这比仅从各种角色和能力中删除 Everyone 组要复杂得多。 内容存储数据库初始化之后，就设置了默认权限，支持启动开箱即用的基本配置。IBM Cognos 10 信息中心中提供关于初始的内容存储对象和权限文档： 但是，初始的权限不一定反映出您设计的最佳设置，也不一定实现任何许可模型或兼容性。它们只是可以使用的一个配置示例。要有效地运用一种安全策略，必须仔细看看各种能力并修改默认的权限。请参考以下 IBM Cognos 10 信息中心的链接，以获取关于安全设置的更多信息： 能力不仅存在于通用层，数据包层也有。使用这项特性来控制 IBM Cognos 10 工作室对数据包以及数据源的访问。 作为最佳实践，先在 Cognos 名称空间中定义对象，然后只把 Cognos 名称空间角色/组分配给能力。 数据源凭证自从 IBM Cognos 10 BI 起就开始有新特性，如果批准对管理自己的数据源 能力的访问，用户就可以凭借此特性管理自己的数据库凭证。这可以将维护或管理大量已存储登录的责任从 IBM Cognos 10 管理员身上分担出来，让用户能管理自己的凭据。 作为最佳实践，决定是否在实现数据源之前授权用户完成此任务。原因是，是否允许用户管理自己的登录，然后管理员定义静态登录，这会重写所有用户保存的凭证，并消除报告和/或调度。这很难查找，而且要花费很大的精力来修复。所以在开始实现之前最好先做好决定。
| 
/1 
发表于 2014-10-23 13:13:35
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
赞
踩
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜