cognos ibm 收购
目的
本文档提供了一组行之有效的实践和准则，在保护IBM Cognos 10 BI环境时将考虑这些准则。
本文的目标读者是IBM Cognos 10 BI应用程序管理员，他们将负责设计IBM Cognos 10架构和/或开发项目。 这些内容与最终用户无关，因为大多数建议都需要由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身份验证，还是应基于某种来自其他安全层的身份验证进行某种形式的单一登录（SSO）？ 如果需要从另一个来源到IBM Cognos 10的SSO，请确保您评估这是一项不错的功能还是必须具备的功能。 如果需要，则在定义授权之前先从技术上解决SSO难题，因为SSO可能会影响所需的名称空间或其配置。 特别是SSO可能会影响计划，因为许多SSO凭据可能会过期，因此可能不适合与计划一起存储。 这会导致提示用户输入用户名和密码，因为他们习惯于SSO，所以他们可能不知道这些用户名和密码。
- 是否还应该使用用于认证IBM Cognos BI 10的相同凭据来认证查询数据库（用户传递）？ 这可能是一个复杂且具有挑战性的设置，并且在身份验证源和数据库的所有组合中均不受支持。 评估使用存储的数据库登录名的替代方案是否可行，但是请注意，这可能会对授权产生影响，因为登录名必须在IBM Cognos 10 BI中维护并正确保护。
- 需要什么级别的安全性？ 该系统是外部访问还是内部访问？ 如果系统可以从外部访问，则建议的最佳实践是在托管IBM Cognos 10 BI Gateway的Web服务器上实现安全套接字层（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 10 BI相关。 显然有很多安全方面需要考虑，但是好消息是所有这些都可以在IBM Cognos 10 BI中处理。 本文档中列出的最佳实践建议涉及一般适用性。 有关更多特定主题，请尝试在位于http://www.ibm.com/developerworks/data/library/cognos/cognosprovenpractices.html的 IBM developerWorks网站上研究文档。
IBM Cognos配置
本部分将讨论IBM Cognos Configuration中指定的与安全性相关的设置和配置项目。 这些通常在安装后立即实施，并为以后介绍的后续任务提供基础。
安全安装
服务帐号
影响安全性的第一个决定可能已经做出。 可能是使用特定帐户将IBM Cognos 10安装到您的平台上的，并且该帐户可能具有足够的文件系统特权来运行该应用程序。 但是，策略或环境可能会要求使用特定帐户来运行应用程序。 我们将该帐户称为“ 服务帐户” 。
IBM Cognos 10 BI在大多数情况下是一个Java Web应用程序，该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服务，默认情况下由本地系统帐户运行。 在UNIX / LINUX平台上，该服务由调用cogconfig.sh启动脚本的帐户运行。 因此，服务帐户是运行应用程序服务器的帐户。
如果将IBM Cognos 10 BI部署到其他应用程序服务器，通常该服务器将确定用于运行IBM Cognos 10 BI的帐户，因此是服务帐户。
选择适当的服务帐户很重要，因为：
- 该帐户将实例化托管IBM Cognos 10以及由IBM Cognos 10产生的所有其他进程（如BiBusTKServerMain ， CAM_LPSvr ， BmtMDProviderMain等）的Java运行时环境（JRE）。 所有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平台上，必须允许该帐户在计算机上进行身份验证，并且应具有足够的文件系统特权，并且必须在“用户帐户控制”中正确配置。 根据对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中进行配置。 该属性名为“ 临时文件位置” ，它位于“ 环境”部分下。 为了限制对在此目录中找到的临时文件的访问，建议将文件系统权限设置为仅允许“服务帐户”对目录的完全控制，而所有其他帐户都应被拒绝访问。 如果将临时文件位置移至IBM Cognos 10 BI安装目录之外的目录，则可能需要调整文件系统许可权。
IBM Cognos 10 BI还可以将用户会话文件保存到本地文件系统，以帮助减少Content Manager上的负载。 如果配置了此功能，则只能由服务帐户访问为用户会话文件指定的位置。 请记住，此功能仅影响Application Tier组件的已安装实例。 有关将用户会话文件保存到本地文件系统的更多信息，请参阅IBM Cognos 10信息中心中的以下链接。
加密临时文件
如果模型或最近查看的报告包含敏感数据，则在处理生成的这些临时文件时应格外小心。 IBM Cognos 10 BI提供了对这些临时文件进行加密的功能，因此未经授权的使用者无法查看它们。 但是，这不适用于用户会话文件。 可以使用IBM Cognos Configuration修改启用临时文件加密的属性。 该属性名为加密临时文件吗？ 并且位于“ 环境”部分下。 该值应设置为True以启用此功能。 应用的加密基于基于会话的密钥，该密钥被馈送到已配置的机密性密码。
调度员密码
从IBM Cognos BI 8.4开始，有一个Dispatcher密码属性，该属性必须在所有已安装的Dispatcher实例之间匹配，包括仅安装Application Tier和Content Manager组件。 该密码的作用类似于共享机密，因为它可以防止不知道机密的分派器加入IBM Cognos 10 BI系统。 作为最佳实践，应在所有Application Tier和Content Manager安装中将此密码更改为默认密码。 可以使用IBM Cognos Configuration修改用于设置分派器密码的属性。 该属性名为分派器密码 ，它位于“ 环境”部分下。
内容存储数据库
内容存储数据库是IBM Cognos 10 BI系统的中央存储库。 显而易见，应采取最大的预防措施以确保数据库可用并得到适当保护。 IBM Cognos 10 BI Content Manager组件通过单个数据库登录来处理对Content Store数据库的访问。 该登录在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中设置不活动超时 。 作为最佳做法，应根据您的安全策略进行设置。 一个好的起点是900秒或15分钟。 这是默认值3600秒的四分之一，但它代表了每个活动会话的资源消耗与用户便利之间的良好权衡。
护照加密
成功的身份验证将导致在Content Manager组件的内存中创建会话对象。 这些会话对象将包含敏感的用户数据。 如果需要，可以对这些内存对象进行加密，以防止恶意软件或其他内存读取器对信息的访问。 要启用加密，请使用IBM Cognos Configuration来设置“ 启用护照凭证的加密？”。 位于“ 安全性”>“身份验证”部分中的“ True”属性。 请记住，这将对身份验证和其他需要访问用户凭据的操作的性能产生轻微影响。 作为最佳实践，除非您的安全策略明确要求，否则请禁用此功能。
会话共享
当单个工作站上的多个客户端（Framework Manager，Transformer，Planning等）访问同一IBM Cognos 10 BI系统时，它们可能共享经过身份验证的会话。 尽管这有助于减少IBM Cognos 10中存在的并发活动会话的数量，但它的安全性可能比为每个客户端分别管理会话的安全性低。 另一方面，这是在单个工作站上的多个客户端之间实现SSO所必需的。 在IBM Cognos Configuration中设置的属性是“ 允许在客户端应用程序之间共享会话信息？”。 在安全>身份验证部分下。 此属性的默认值为False ，最佳实践是将其保留为False，除非单个工作站上需要多个SSO的客户端应用程序。
限制对IBM Cognos Connection的访问
配置名称空间用于身份验证后，意味着来自基础身份验证源的所有用户都应能够向IBM Cognos BI进行身份验证并访问IBM Cognos Connection。 但是，情况并非总是如此，因为可能需要限制对已配置的身份验证源中包含的所有用户的子集的访问。 在IBM Cognos 10 BI中，这可以通过利用配置属性“ 限制对 IBM Cognos Configuration中的安全性>身份验证”下的内置名称空间成员的访问来实现。 如果将此属性设置为True ，则将直接或间接拒绝不属于Cognos名称空间成员的任何用户的访问。 Cognos命名空间是内置的命名空间，用于将用户，组和角色从外部身份验证源映射到已定义的特定于应用程序的安全模型。 有关Cognos命名空间的更多信息，请参考标题为“授权概念和最佳实践”的部分。 通过将用户所属的外部名称空间中的用户或组/角色分配给Cognos名称空间中的组或角色，用户将隐式成为Cognos名称空间的成员。
示例：用户Robert Smith和Marla Spears是在LDAP源中定义的，该LDAP源被配置为IBM Cognos 10的LDAP名称空间。Robert被分配给Cognos名称空间中的Consumers角色，而Marla没有被分配给IBM Cognos 10中的任何组或角色。 Cognos命名空间。 是否限制访问内置命名空间的成员？ 如果属性设置为True，Robert将能够通过IBM Cognos 10进行身份验证并可以访问Cognos Connection，但Marla不会，因为她不是Cognos命名空间中任何组或角色的成员。
自动更新可信凭证
从IBM Cognos 10开始，有一项新功能，该功能允许IBM Cognos 10 BI“自动”更新计划的存储凭证。 可以在IBM Cognos Configuration中通过“ 安全性”>“身份验证”部分下的“ 自动更新受信任的凭证”属性来设置此功能。 要了解此设置的影响，我们需要查看一些细节。
当用户创建要与时间表一起保存的可信凭据或将其提供给其他用户以供他们用于运行报表而不是用户保存凭据时，就会创建一个对象，其中包含该用户所有命名空间的凭据目前已验证到。 结果，由于单个用户可以在单个会话中向多个名称空间进行身份验证，因此受信任的凭据可能包含多组凭据，每个名称空间一组。 会话经过身份验证的第一个名称空间称为主名称空间 。
受信任的凭证很特殊，因为它存储的名称空间凭证必须在任何时候都可以使用，而不取决于任何时间戳。 这排除了SSO票证，例如Kerberos令牌或SAP令牌，因为它们将在短时间后过期并变得不可用。 因此，合适的可信凭证通常是由用户名和密码组成的一对。 但是，对于对IBM Cognos 10 BI的基于SSO的身份验证，没有可供命名空间使用的密码，该密码可以存储到受信任的凭证中。 因此，当用户向登录屏幕提供用户名和密码时，此功能仅适用于基本身份验证。 在这种情况下，系统将查看该用户的所有可信凭据，并使用他们刚刚输入的凭据对其进行更新。
当该属性设置为“ 仅主要名称空间” （默认值）时，这意味着将仅使用单个凭据更新受信任的凭据，而“ 所有名称空间”的值表示将更新当前认证为的所有名称空间的凭据。 最佳实践是仅在不通过SSO对名称空间进行身份验证的情况下，才将其设置为Primary名称空间的值，否则应将其设置为Off的值。
命名空间
有一些特定于名称空间类型的准则：
LDAP唯一标识符
在对用户进行身份验证以访问IBM Cognos Connection门户后，将称为CAMID的用户帐户参考存储在Content Store数据库中。 该CAMID部分由从属性返回的值组成，该属性映射到IBM Cognos Configuration中“ 安全性”>“身份验证”部分下用于命名空间定义的唯一标识符属性。 默认情况下，此属性映射到dn （专有名称）。 所有LDAP服务器都将为每个单个条目填充此dn属性，因此这可确保不管LDAP服务器的类型如何，始终有一个属性可作为唯一标识符的基础。 但是，这种做法不能确保用户帐户是唯一的。 考虑以下情况，
公司ABC购买了IBM Cognos 10 BI，并已成功将产品推广到他们的用户群。 LDAP名称空间用于连接到公司目录服务器。 历史上，默认的IBM Cognos 10 BI LDAP名称空间配置基于Sun One Directory Server，因此其“唯一标识符”属性的值设置为dn。 北美销售副总裁John Q. Smith是IBM Cognos 10 BI的常客，并且一直将敏感的销售和预测报告存储在IBM Cognos Connection门户的“我的文件夹”部分中。 使用“姓氏，名字首字母”的公司命名约定，他的网络用户帐户是SMITHJ，并且在北美用户文件夹中创建。 这使John Q. Smith获得了dn的信息：
uid = SMITHJ，cn =北美，dc =公司ABC，dc = com
到目前为止，一切照旧。 但是，John Q. Smith决定在另一家公司任职，因此他的用户帐户已从公司LDAP层次结构中删除。 几个月后，雇用了入门级经理John X. Smith。 再次使用ABC公司的命名约定，John X. Smith获得了SMITHJ的网络帐户，因为该帐户可用。 这使John X. Smith获得了dn的信息：
uid = SMITHJ，cn =北美，dc =公司ABC，dc = com
当John X. Smith登录到IBM Cognos Connection并第一次将报告保存到“我的文件夹”时，他注意到他的文件夹中充满了包含敏感数据的报告。 发生这种情况的原因是因为唯一标识符基于随时间推移可能不是唯一的属性，如前面的示例所示。 确保不发生这种情况的唯一方法是对唯一标识符使用属性，该属性为从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，从而实质上在Content Store中创建了一个新的用户帐户。 同样重要的是要注意，所使用的属性必须是可用于所有对象（例如组，文件夹和用户） 的属性 。 如果所选属性仅对用户存在，则在管理名称空间时某些对象将不会出现在IBM Cognos Connection中。
LDAP连接
可以通过多种方式配置IBM Cognos 10 BI LDAP身份验证提供程序，以了解连接处理和用于绑定到LDAP服务器的凭证。 目前，这些方法中的许多方法仍在研究中，以了解如何最好地实施。
实质上，提供程序使用两种类型的连接，一种用于查找搜索，一种用于与用户会话操作相关的搜索。
查找连接将使用提供的绑定凭据建立，并被合并并因此被重用。 默认池大小为20，直到产品停止，连接才会关闭。 要配置池大小并影响是否为该类型的提供程序删除连接，可以在IBM Cognos Configuration中“ 安全性”>“身份验证”部分下的名称空间定义的“ 高级”属性中指定minimumLDAPPoolSize和maximumLDAPPoolSize 。 如果两个属性都设置为0 ，则连接不会被合并，并且在使用后将立即关闭。
对于用户会话连接，除非将“ 将绑定凭证用于搜索”属性设置为true，否则登录时提供的用户凭证将用于绑定到提供程序。 这将触发使用“ 绑定用户DN和密码”属性中指定的值。 这些连接将保持连接状态，直到用户会话结束。 如果要最小化连接使用，可以在“ 高级”属性中指定属性unbindLDAPHandleAfterUse并将其设置为true 。 将这些高级属性一起使用，可以实现与LDAP服务器的最少开放连接。
对于较大的用户群（超过50个同时登录的用户），最佳实践是使用unbindLDAPHandleAfterUse属性，并使池保持不变，因为20个连接不会对LDAP服务器造成明显影响。 如果您的策略要求将打开的连接数保持在最低水平，请禁用查找连接池。
Microsoft活动目录
配置Microsoft Active Directory（AD）名称空间时，可以利用基于Microsoft DNS的定位器服务，该服务允许在故障转移方案中找到可用的域控制器。 这样一来，您就可以不在AD名称空间的“ 主机和端口”属性中为主机指定特定的域控制器名称或IP地址，而不必为域的DNS别名（例如domain.company.com）指定主机 。 这将使DNS服务在所有情况下都能返回可用的域控制器，因此，被认为是许多客户端已采用的最佳实践。
密码学
IBM Cognos 10 BI利用公钥基础结构（PKI）概念来实现加密，以及支持用于加密HTTP通信的安全套接字层（SSL）协议的基础。 具体细节不在本文档的讨论范围之内，但是应将某些设置从默认值更改为实现基本安全要求并遵守最佳实践。
身分识别
每个安装的实例（指的是将一个或多个已安装的组件安装到支持的平台上的单个目录中）具有IBM Cognos 10 BI的标识。 因此，即使同一框上两个单独目录上的两个已安装实例也被视为不同实体。 当使用加密来加密IBM Cognos 10 BI中保存的临时或临时数据的加密法起作用时，这一点就很重要。 该身份的概念起源于X.509标准，由IBM Cognos Configuration的“ 安全性”>“密码学”>“ Cognos”>“身份名称”部分中的“ 服务器公用名” ，“ 组织名称”和“ 国家或地区代码 ”字段组成，由“ 专有名称”定义。 这些字段应更改为默认值，以确保每个安装都具有不同的标识。 This is most important when the internal communication for IBM Cognos 10 BI will be switched to SSL but in general it is a Best Practice to define those properties.
Best Practice is to specify a unique Server common name property. The value should be the server's fully qualified Domain Name System (DNS) name. In the case of multiple installed instances on a single host which share a DNS name, adjust the Organization name property in each configuration to distinguish the instances.
CA Service password
One of the central elements of a PKI is the Certifying Authority (CA) which represents the root of trust and issues and signs certificates thus approving the identity of other entities. IBM Cognos 10 BI contains it's own CA service located within the Content Manager component and, by default, will be used to sign the certificates used by IBM Cognos 10 BI. This is meant for installations where the client does not run corporate CA services or the security requirements allow using an application specific CA to be feasible.
When saving configuration on any installed instance for the first time, the CA service will be asked to sign some certificates for that particular installed instance, approving the instance's identity. It is therefore crucial for the integrity and security of the IBM Cognos 10 BI deployment that only trusted instances have access to the CA service. This is why the built-in CA service is protected by a password. This password is specified in IBM Cognos Configuration in the Password property of the Certificate Authority settings section under Security > Cryptography > Cognos .
The Best Practice is to change this password from the default. To do that, specify a new password in the configuration of the Content Manager install component before saving the configuration for the first time. Subsequently adjust the password for all other instances before initial save of configuration on each install.
Keystore Passwords
Certificates are stored in special files called key stores . The files are in a binary format and they are encrypted based on a password required to access them. IBM Cognos 10 BI uses three different key-pairs and correlating certificates on each instance, one for encryption, one for signing and one for the Certifying Authority. Each key-pair and the certificate issued for it are held in a separate key store, which is protected by a password.
Each certificate has it's own settings in a separate section in IBM Cognos Configuration under Security > Cryptography > Cognos . The key store passwords are specified in the <key purpose> password property where <key purpose> is one of Signing key store , Encryption key store or Certificate Authority key store .
It is considered a Best Practice to change the key store passwords from their defaults before first saving configuration for the instance.
Cognos Application Firewall
The Cognos Application Firewall (CAF) is a tool designed to supplement the existing IBM Cognos 10 BI security infrastructure. This application firewall acts as a smart proxy for the IBM Cognos 10 BI Dispatcher and ensures that incoming HTTP and XML requests sent to it are safe to be handled and that outgoing responses to external clients or services are properly encoded and safe.
Safe in this context refers to parameter data, HTTP POST data and malicious requests being sent to the product aiming to compromise the system's security. The most common forms of malicious data are buffer overflows, cross-site scripting attacks (XSS links), either through script injection in valid pages, redirection to other web sites or SQL injections, and session identifier or cookie based attacks. The Cognos Application Firewall will reliably secure IBM Cognos 10 BI against those and ensure only validated parameters and data in general is processed.
The Cognos Application Firewall is controlled by settings made in IBM Cognos Configuration under Security > IBM Cognos Application Firewall . The Enable CAF validation? property must be set to True for CAF to be enabled.
Due to it's critical contribution to overall system security and stability, the Best Practice is to never disable CAF in a production environment.
Valid Domains or Hosts
The most important property of CAF configuration is the list of valid domains or hosts to allow re-direction to or to allow pulling data from. This refers to functionality such as displaying a feed on a dashboard from an external URL, including pictures from external servers, integrating IBM Cognos TM1 Contributor or redirecting to a Lotus Connection host to create an Activity.
Each of the scenarios mentioned above requires an entry to be added to the list of valid domains or hosts for the CAF. The CAF will compare the URL used to access an external (to IBM Cognos 10 BI) resource with the list of valid domains or hosts and only if a match is found, the request will be sent to the external resource. This list of explicitly allowed host names or domain suffixes to which access is allowed is often referred to as a white-list . Any URL that is not on the white-list would be blocked by CAF. One can specify a host name in NetBIOS notation (eg “MyServer”) or specify domain suffixes using wild cards (eg *.domain.com) to allow all hosts from a specific domain.
The comma separated list is specified in IBM Cognos Configuration under the Security > IBM Cognos Application Firewall > Valid domains or hosts property.
The Best Practice is to explicitly name the hosts if possible and use more general domain suffix specifiers in trusted networks only.
IBM Cognos Connection
In IBM Cognos 10 BI the IBM Cognos Connection portal is where almost all security related settings regarding authorization must be specified and managed. This starts with defining which external security objects such as users, groups and roles that are brought in from an external authentication source will be assigned to secured features and functions as well as defining object security for application content such as packages, reports and dashboards.
The IBM Cognos 10 Information Center has a considerable amount of information about details and specifics in this area, which is why we will refer to there for the basics and only describe additional recommendations which add value over what's already documented.
Authorization Concepts and Best Practice
The first step in understanding authorization for IBM Cognos 10 BI is to understand the objects involved. In simple words, authorization works by defining permissions for securable objects and functions organized in a hierarchy kept in Content Store. This hierarchy of objects is initialized upon the first start of IBM Cognos 10 BI when the Content Store tables are created and pre-populated with the default objects and permissions to them. Among those objects is the Cognos namespace to which predefined roles and built-in objects such as the Everyone group and the Anonymous user are added.
Refer to the following IBM Cognos 10 Information Center links below for more information on the initial built-in objects and predefined roles.
The default permissions, like any other set of permissions, define what type of access users, groups or roles from any namespace, including the Cognos namespace, has to the secured object or function. Upon initialization, there are no assignments for external security objects to any permissions in the Cognos namespace. The authorization is defined based only on objects from the Cognos namespace. This is actually a good starting point for implementing the Best Practice about authorization since this the most flexible and manageable approach to use and therefore the Best Practice to strive for.
The initial access permissions can be found at the following IBM Cognos 10 Information Center links,
To elaborate, one defines authorization by assigning users, groups and roles to permissions which in turn are defined for a securable object such as a report, a schedule, a secured function or a capability. Since users can only originate from external namespaces, the Cognos namespace doesn't support users (with the exception of the built-in Anonymous user), an administrator would have to assign users to the securable Cognos objects explicitly or implicitly. Implicitly refers to assigning groups or roles the user is a member of.
If in a permission a user is referenced explicitly, this permission is dependant on the namespace the user originates from. If the namespace becomes unavailable or the user's unique identifier changes, this reference will be broken. This is one of the reasons why the unique identifier of a user should be based on some globally unique attribute from the authentication source and not on structurally dependant information. For LDAP servers, the DN is actually a path to the entry. If the user is moved around in the LDAP object hierarchy, that path changes and if the user was identified in Cognos by the DN (which is the default), the user's unique identifier to Cognos would be changed and permissions will be broken. By following the Best Practice for unique identifiers that mentioned above, in particular for LDAP namespaces, you will be shielded from this. Active Directory is safe since the objectGUID is not dependant on structural information. The scenario applies to implicit references as well, since the same statement holds true for external group or role references, they are identified by their unique identifier to IBM Cognos 10 BI.
Another challenge is that it is possible that the underlying authentication source might need to change. Where today an LDAP might be used for the test environment, in production an Active Directory instance may be used. This means that in this case objects from the external namespaces have been assigned to permissions and functions directly, and the references to the those namespaces will be broken as well because a different namespace will assign different unique identifiers to the objects.
To alleviate these challenges there is a simple Best Practice for authorization - All references in permissions, capabilities and secured functions should only be made to groups and roles from the Cognos namespace. This means only groups and roles created in the Cognos namespace should be used to define permissions. For example, to allow a certain set of users to use an IBM Cognos 10 Studio, one would either use one of the predefined roles from the Cognos namespace or create a new role explicitly for this purpose and assign this role to the corresponding capability. While this might appear cumbersome to create multiple new groups or roles in the Cognos namespace it actually adds great value. The reasons for this are,
- All references to objects used in permissions will remain intact even if the members of the role/group referred to will change.
- The contents of the Cognos namespace can be migrated via deployments to other IBM Cognos 10 Systems.
- The creation or assignment of external objects to Cognos namespace entries can be automated through the IBM Cognos 10 SDK.
Consider a simple example,
A project is developed in a test environment using a simple LDAP provider with some test users. The project team sets up authorization so that several project-specific group and role objects get added to the Cognos namespace, ignoring or deleting the default Cognos namespace entries. In the next step they assign users and groups from the LDAP provider to the new project-specific Cognos namespace objects entries and subsequently define permissions for studio capabilities, package access and even IBM Cognos Framework Manager security filters (filters which are built into the model for querying the data), based on the new Cognos namespace objects.
When the development has been completed in the test environment, the IBM Cognos 10 application consisting of packages, reports, etc., is deployed to the pre-production environment which uses Active Directory with many thousands of users. This implies that different users will need to be added and existing references to external namespace objects will be broken.
However, since the project followed the Best Practice by having all references in permissions, capabilities and secured functions made only to groups and roles from the Cognos namespace, they can export the IBM Cognos 10 application into a deployment that includes the Cognos namespace. This will preserve all permissions and in the target environment the only thing left to do is adjust the assignments of users and groups from the Active Directory to the roles and groups defined in the Cognos namespace. All the rest remain intact with no need to re-define or adjust a single permission. This is a great time-saver and keeps the project flexible. In addition, if they define groups in their Active Directory to hold the users and only assign those AD groups to the Cognos namespace groups and roles, they can even manage part of the authorization in AD rather than in Cognos. For some clients this is important since identity management integration or access management processes might be in place already.
Users, Groups and Roles
User Maintenance
IBM Cognos 10 BI stores its user profiles, and their associated content, in the Content Store database. In an environment where there are many users, this could potentially consume quite a bit of space. Users being removed from authentication sources, is an everyday occurrence at most companies, so why keep outdated user profiles and content in the Content Store?
The following Best Practice assumes that the user's profile is deleted in IBM Cognos 10 BI prior to removing the user account from the authentication source.
- Login to IBM Cognos Connection with a userid that is a member of the Directory Administrator role.
- Click Launch > IBM Cognos Administration .
- In IBM Cognos Administration select the Security tab.
- Click on the namespace containing the user account to be deleted.
- Locate the user whose profile needs to be deleted. Use the Search feature if the namespace hierarchy is deep and/or the location of the user account is unknown. The search icon is a magnifying glass and is in the upper right.
- In the Actions column, click the More... link.
- Click on the Delete this user's profile link to delete the profile.
- Click OK to confirm the deletion of the user profile.
In most environments, the ability to pro-actively delete a user account may not be a reality. Fortunately, IBM Cognos 10 BI provides a mechanism to synchronize the set of profiles held in Content Store with the underlying external namespaces regarding user accounts.
- As a user with administrative access to IBM Cognos 10, log in to all namespaces which shall be verified/checked.
- From IBM Cognos Connection, select Launch > IBM Cognos Administration .
- Select the Configuration tab and click on Content Administration in the left menu.
- Click on the down arrow on the New Content Maintenance button and select the New Consistency Check link.
- Enter a name and optional description and/or screen tip then click Next.
- Select the external namespace(s) to be verified by the consistency check and click Next. The user must be authenticated to all selected namespaces, for the task to work effectively. Missing authentication to a namespace at this point will exclude the namespace from the task.
- Choose Save and run once to execute the task only one time, Save and schedule to schedule the execution of the task for later and possibly in reoccurring intervals or Save only to not run the task and click Finish.
- If chosen to run once, specify a time to execute the maintenance task and then choose to either Find only or Find and fix any inconsistencies for the selected namespaces. As mentioned earlier, this requires that the user running the task right now is authenticated to all the selected namespaces. Click Run to start the task, then in the upcoming dialogue don't forget to check the View the details of the content maintenance task after closing the dialog option. This will forward to a page which can be refreshed by clicking Refresh in the upper right until the status changes to succeeded or failed. Any messages regarding specific users will be displayed in the list on this page.
- If chosen to schedule the task, a new schedule will be saved along with trusted credentials based on the current authentication. The trusted credentials will include all of the namespaces currently authenticated to. Specify the interval and time of execution and select either Find only or Find and fix as the mode to use.
The task will run a consistency check to verify that the user profiles stored in Content Store database are in sync with the users in the external namespace(s). If any users cannot be located in the external authentication source and they have an existing profile in Content Store, a message will be logged stating that the account no longer exists in the external authentication source. If the Find and Fix mode has been selected, the user profile will be deleted from the Content Store.
It is considered a Best Practice to schedule a Content Store maintenance task performing this action at least one a month to avoid wasting space in the Content Store.
More information on this topic can be found in the IBM Cognos 10 BI Administration and Security Guide located in the IBM Cognos 10 Information Center at,
Role/Group Naming
To help organize roles in the Cognos namespace, which can become very abundant in a large deployment, it is recommended to create folders to allow for a logical separation of the roles. These folder names then assume part of the search path of the role. The search path refers to the path describing the location of the object in the Content Store object hierarchy. For example, two folders could be created and within each of these folders, a role could be created and the name of the role can be the same. To illustrate, two folders were created within the Cognos namespace, one called Roles East and the other Roles West . In each folder, a role called Data Administrators was created.
Directory > Cognos > Roles East > Data Administrators
Directory > Cognos > Roles West > Data Administrators
Two roles with the same name were permitted because the name of the parent folder becomes part of the search path for each object. At the same time, for objects in the Cognos namespace the internal ID of those objects, referred to as the CAMID, contains part of the search path as well.
CAMID(":Roles East:Data Administrators")
CAMID(":Roles West:Data Administrators")
Although this type of naming convention works and is supported within IBM Cognos 10 BI, it is not a recommended approach. This technique can easily lead to mistakes when defining permissions or object security as the objects appear to be the same when displayed in the list of members. If the person applying security was not aware of the two distinct groups, incorrect access could be granted or denied to an object. The following illustration shows an example of this, since there is no additional context provided by IBM Cognos Connection to properly identify, at a glance, which role object belongs to which folder.
Illustration 1: A member list of a role in IBM Cognos Connection showing two members with the same name which are not distinguishable at first glance
If the deployment absolutely requires roles of the same name to be created, using a tool tip can help identify which role is which. Then by simply hovering the mouse over the ellipsis (…) the tool tip will display the full path to the object as can be seen in the following illustration.
Illustration 2: A member list of a role in IBM Cognos Connection showing again two identically named members but the tooltip provides context by showing the search path
A naming convention should be established to avoid duplicate naming for roles and/or groups. A common practice is to prefix the entries with something like “R_” for role, “G_” for group and add additional prefixes to indicate where they come from if required. For example, “R_HR_Approver” and “R_Marketing_Approver” could be two roles from different search path or even the same path. In the example above the prefix enables to distinguish them.
权限
The IBM Cognos 10 Information Center provides sufficient detail about permissions and their use. It is important to understand the concepts described there to avoid traps.
Deny takes precedence
You can grant access or deny access to entries. Denied access has precedence over granted access. Therefore when you deny specific users, groups or roles access to an entry but you replace other security policies that grant access to the entry, the grant and deny permissions are in conflict and access to the entry is always denied. For example, a user belongs to two groups. One group has access granted to a report and the other group has access denied to the same report. Access to this report is denied for the user.
As a Best Practice, deny access only when it is really required. Typically, it is a better administrative practice to explicitly grant permissions than to deny them.
Breaking inheritance by explicit override only
Access permissions are acquired from parent entries. If access permissions are not defined explicitly, the entry acquires permissions from its parent entry. You can replace/override this functionality and thus break the inheritance of parent permissions by explicitly defining permissions for the child entry.
Objects that exist only as children of other objects always acquire permissions from their parents. Examples of such objects are report specifications and report outputs. These objects can be manipulated using the IBM Cognos 10 SDK but you cannot set permissions for those objects using IBM Cognos Connection.
Deleting predefined groups and roles
When you delete a predefined group or role from the Cognos namespace, access permissions based on it are also deleted. In IBM Cognos 10 you can restore them by creating a new group or role in the Cognos namespace with the exact same name which will lead to the same internal ID (CAMID). For external groups or roles (those read from an external authentication source through the authentication provider) check how your authentication provider deals with such situations. Typically, you cannot recreate access permissions if they are based on IDs but you can if they are based on names. An example for this would be an LDAP namespace using the DN attribute for unique identifier which is only a string. However, as pointed out before, this bears the risk of unwanted access to user profiles as well and is not a Best Practice so the statement about deleting groups and roles should be considered generally applicable. Don't remove groups or roles unless you're absolutely sure you don't need them any longer. All permissions assigned to the group or role will be lost.
能力
In IBM Cognos 10 BI there are many secured functions and features which are controlled by assigning permissions to corresponding capabilities. The following link in the IBM Cognos 10 Information Center contains more information on secured functions and features. It is important to read the descriptions provided and fully understand the impact of allowing access to a feature or capability for your security design. There's probably more to it than simply removing the Everyone group from various roles and capabilities.
After the initialization of the Content Store database default permissions are set which allow for a basic out of the box configuration to start. The initial Content Store objects and permissions are documented in the IBM Cognos 10 information Center at,
However, the initial permissions don't always reflect the optimal setup for your design nor do they implement any licensing model or compliance to such. They are simply an example of a configuration that could be used. To effectively apply a security policy, one must revisit various capabilities and modify the default permissions. Refer to the following link in the IBM Cognos 10 Information Center for more information on specifying security settings,
Capabilities not only exist at general level but at package level as well. Use this feature to control access by the IBM Cognos 10 studios to packages and consequently data sources.
As a Best Practice, start with defining your objects in the Cognos namespace and only then assign Cognos namespace roles/groups to capabilities.
Data Source Credentials
As of IBM Cognos 10 BI, there is a new feature whereby users can manage their own database credentials if granted access to the Manage own data source signons capability. This can remove the onus of maintaining or managing a large number of stored signons from the IBM Cognos 10 administrator and empower users to maintain their own credentials.
As a Best Practice, decide on whether you want to empower your users to do this before implementing data sources. The reason is that if users were allowed to manage their signons and at a later point an administrator defines a static signon, this will overwrite any user saved credentials thus potentially breaking reports and/or schedules. This can be tricky to find and can take a significant effort to remedy. As a result this is a decision best made before starting implementation.
翻译自: https://www.ibm.com/developerworks/data/library/cognos/security/cognos_bi_platform/page602.html
cognos ibm 收购
扫一扫
3429
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
