Практика работы с IBM Cognos: Обеспечение безопасности среды IBM Cognos 10 BI

Характер документа: практические рекомендации; продукт(ы): IBM Cognos 10 BI; область интересов: безопасность; версия: 1.1

Набор проверенных методов и рекомендаций, которых следует придерживаться при защите среды IBM Cognos 10 BI.

Введение

Назначение

Настоящий документ содержит набор проверенных методов и рекомендаций, которых следует придерживаться при защите среды IBM Cognos 10 BI.

Целевую аудиторию этого документа составляют администраторы приложений IBM Cognos 10 BI, ответственные за проектирование архитектуры IBM Cognos 10 и/или разработку проектов. Его содержание не рассчитано на конечного пользователя, так как большинство рекомендаций должно выполняться администраторами IBM Cognos до начала работы конечных пользователей.

Область применения

Рекомендации и методы, описанные в настоящем документе, не относятся ни к какой конкретной платформе и не зависят от архитектуры развертывания. Примеры основаны на установке Windows, но если явно не указано иное, все утверждения справедливы для продуктов, перечисленных на титульном листе (включая версии Fix Pack (FP) и Refresh Pack(RP)).

Исключения

Хотя документ носит общий характер и применим к большинству установок, некоторые утверждения могут относиться не ко всем ситуациям. Необходимо убедиться, что приведенные здесь рекомендации соответствуют требованиям, предъявляемым к конкретному случаю развертывания, и соблюдать все правила безопасности, применимые к конкретной среде.


Рекомендации по обеспечению безопасности среды BI IBM Cognos 10

Продукты 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 может повлиять на планирование, так как многие учетные данные единого входа не подходят для хранения с регламентом, так как они могут иметь определенный срок действия. Это ведет к тому, что пользователям будет предлагаться ввести имя пользователя и пароль, которых они могут не знать, так как работают через единый вход.
  • Должны ли те же учетные данные, которые применяются для проверки подлинности в IBM Cognos BI 10, использоваться также и для аутентификации в базе данных запросов (опосредованная аутентификация)? Это может оказаться сложной задачей и поддерживается не для всех комбинаций источника аутентификации и баз данных. Оцените, возможны ли альтернативы с использованием хранимых паролей доступа к базе данных, но помните, что это может иметь последствия для авторизации, так как в IBM Cognos 10 BI эти пароли необходимо поддерживать и надлежащим образом защищать.
  • Каков необходимый уровень безопасности? Доступна ли система извне, или только внутренне? Если система доступна извне, то на Web-сервере, на котором размещается IBM Cognos 10 BI Gateway, рекомендуется реализовать протокол Secure Socket Layer (SSL). Политика безопасности вашей компании, скорее всего, потребует этой, а возможно и других дополнительных мер. Это повлияет на конфигурацию SSL в IBM Cognos 10 BI.
  • Насколько конфиденциальны данные внутренних/внешних пользователей? В зависимости от требований безопасности может понадобиться шифрование временных файлов и всего сетевого трафика, даже внутреннего. Опять же, эти меры влияют на конфигурацию установки 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 позволяет всем этим управлять. Практические рекомендации, приведенные в настоящем документе, относятся к общим случаям применения. Документы по более конкретным темам попробуйте поискать на Web-сайте IBM developerWorks по адресу: http://www.ibm.com/developerworks/data/library/cognos/cognosprovenpractices.html.


Конфигурация IBM Cognos

Этот раздел посвящен настройке и элементам конфигурации, относящимся к безопасности, которые содержатся в IBM Cognos Configuration. Обычно эти настройки реализуются сразу после установки и составляют основу для решения последующих задач, которые будут рассмотрены ниже.

Безопасная установка

Служебная учетная запись

Первое решение, относящееся к безопасности, возможно, уже принято. IBM Cognos 10 мог быть установлен на платформе с использованием определенной учетной записи, и эта учетная запись имеет достаточно привилегий в файловой системе для запуска приложения. Однако вполне возможно, что правила или среда потребуют, чтобы для запуска приложения использовалась определенная учетная запись. Мы будем называть ее служебной учетной записью.

IBM Cognos 10 BI ― это по большей части Web-приложение Java, развернутое на сервере приложений Java, таком как IBM WebSphere. Однако IBM Cognos 10 изначально предустановлен на Apache Tomcat, а это не полноценный сервер приложений Java. Но в этой статье мы будем называть Apache Tomcat сервером приложений.

Если IBM Cognos 10 выполняется вне Apache Tomcat, то существует служба 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, и следовательно, служебную учетную запись.

Важно правильно выбрать служебную учетную запись, так как:

  • она создает экземпляр Java Runtime Environment (JRE), в котором размещаются IBM Cognos 10 и все остальные процессы, порожденные IBM Cognos 10, такие как BiBusTKServerMain, CAM_LPSvr, BmtMDProviderMain и др. Все процессы IBM Cognos 10, которые представляют собой Java-процессы или процессы, зависящие от платформы, требуют привилегий файловой системы различных уровней для каталога установки IBM Cognos 10 и его подкаталогов;
  • эта учетная запись используется для доступа к принтеру;
  • при работе на платформах Windows данная учетная запись используется для взаимодействия с Microsoft Kerberos, требуемым для единого входа IBM Cognos 10 и, возможно, для проверки подлинности в базах данных 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 по следующей ссылке:

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.inst_cr_winux.10.1.0.doc/inst_cr_winux_id3223ConfigureAUserAccountForCognos8.html#ConfigureAUserAccountForCognos8

Временные файлы

Как и большинство программных продуктов, при выполнении обычных функций отчетности 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 Content. Если эта функция включена, место, указанное для размещения файлов сеансов пользователей, должно быть доступно только для служебной учетной записи. Имейте в виду, что эта функция влияет только на установленные экземпляры компонентов Application Tier. Дополнительные сведения о сохранении файлов сеансов пользователя в локальной файловой системе можно найти в информационном центре IBM Cognos 10 по следующей ссылке:

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id281asg_content_manager.html#asg_content_manager

Шифрование временных файлов

Если модели или недавно просмотренные отчеты содержат конфиденциальные данные, то при работе с создаваемыми временными файлами следует принимать дополнительные меры предосторожности. В IBM Cognos 10 BI есть возможность шифрования этих временных файлов во избежание их несанкционированного чтения. Однако это не относится к файлам сеансов пользователей. Свойство, позволяющее шифровать временные файлы, можно изменить с помощью IBM Cognos Configuration. Это свойство называется Encrypt temporary files и находится в разделе Environment. Чтобы включить эту функцию, ему нужно присвоить значение True. Применяемый способ шифрования основан на зависящем от сеанса ключе, который предоставляется для настроенного шифра конфиденциальности.

Пароли Dispatcher

Начиная с версии 8.4 IBM Cognos BI содержит свойство пароля Dispatcher, который должен быть единым для всех установленных экземпляров Dispatcher, включая установки, содержащие только компоненты Application Tier и Content Manager. Пароль действует аналогично общему секрету в том смысле, что он предотвращает доступ к системе IBM Cognos 10 BI тех диспетчеров, которые не знают секрет. Рекомендуется изменить этот пароль по умолчанию во всех установках Application Tier и Content Manager. Свойство задания пароля Dispatcher можно изменять с помощью IBM Cognos Configuration. Это свойство называется Dispatcher password и находится в разделе Environment.

База данных Content Store

База данных Content Store ― это центральное хранилище данных системы IBM Cognos 10 BI. Очевидно, что следует принять максимальные меры предосторожности, чтобы база данных была доступна и надлежащим образом защищена. Доступом к базе данных Content Store управляет компонент Content Manager IBM Cognos 10 BI через единый вход в базу данных. Детали входа указаны в IBM Cognos Configuration и хранятся в зашифрованном виде в основном файле конфигурации IBM Cognos 10 BI <COG_ROOT>\configuration\cogstartup.xml. Однако если база данных доступна из-за пределов IBM Cognos 10 BI, это ставит под угрозу стабильность и безопасность системы IBM Cognos 10 BI. Хотя конфиденциальные данные хранятся в Content Store в зашифрованном виде, сохраненные результаты отчетов и другая информация, которая может не быть конфиденциальной, по умолчанию не шифруется, так что важно гарантировать, что никакие другие учетные записи не смогут получить доступ для чтения и записи содержимого базы данных Content Store. Это должно быть реализовано на уровне базы данных. За подробной информацией обращайтесь к администратору базы данных.

Концепции аутентификации

Аутентификацию IBM Cognos 10 BI поручает внешнему источнику аутентификации посредством программного обеспечения, называемого поставщиком услуг идентификации. Каждый поставщик услуг идентификации прикреплен к источнику аутентификации определенного типа, такому как LDAP, Microsoft Active Directory или SAP BW, и реализует логику чтения объектов безопасности и управления процессом аутентификации на основе этой логики. Кроме того, многие поставщики услуг аутентификации обеспечивают поддержку единого входа. За исключением особых случаев, каждый поставщик услуг аутентификации предоставляет IBM Cognos 10 BI объекты, считанные из внешнего источника аутентификации, в виде пространства имен. Для одной системы IBM Cognos 10 BI можно настроить одновременно несколько пространств имен, так что доступ к IBM Cognos 10 BI могут получать пользователи разных источников аутентификации.

В IBM Cognos BI 10 есть специальное пространство имен Cognos. Оно не связано ни с каким источником аутентификации и не может содержать пользователей, а только группы и роли. Пространство имен Cognos недоступно для проверки подлинности, а используется для предоставления уровня логического отображения объектов безопасности из пространства имен, относящегося к внешнему источнику аутентификации, на объекты авторизации, определенные приложением. Администратор создает группы и роли в пространстве имен Cognos и присваивает внешние объекты безопасности, такие как пользователи, группы и роли, тем объектам, которые созданы в пространстве имен Cognos. Концепция авторизации рассматривается в этом документе ниже.

Внешние пространства имен и пространство имен Cognos настраиваются в IBM Cognos Configuration. Существуют также некоторые общие параметры настройки, которые влияют на аутентификации и применяются независимо от типа пространства имен. Начнем описание общих параметров с некоторых практических рекомендаций.

Таймаут бездействия

Параметр таймаута бездействия определяет, через сколько секунд бездействия сеанс работы авторизованного пользователя с IBM Cognos 10 BI будет считается истекшим. Более короткий таймаут ведет к более частым запросам на аутентификацию, а более длинный увеличивает риск того, что кто-то получит доступ к браузеру на оставленной без присмотра рабочей станции, если отсутствует экран защитной блокировки. Однако если настроен единый вход, аутентификация пользователя будет производиться автоматически в фоновом режиме без каких-либо негативных последствий. Рекомендуется по возможности настроить единый вход. Таймаут бездействия устанавливается в IBM Cognos Configuration посредством параметра Inactivity timeout in seconds в разделе Security > Authentication. Рекомендуется настроить его в соответствии с политикой безопасности организации. Хорошей отправной точкой является значение 900 с, или 15 мин. Это четверть значения по умолчанию в 3600 с, но оно обеспечивает хороший компромисс между потреблением ресурсов для каждого активного сеанса и удобством для пользователей.

Шифрование паспорта

Успешная аутентификация приводит к созданию объектов сеанса в памяти компонента Content Manager. Эти объекты содержат конфиденциальные данные пользователей. Если требуется, можно зашифровать их в памяти для предотвращения доступа к информации со стороны вредоносных программ или других объектов, считывающих данные из памяти. Чтобы включить шифрование, используйте IBM Cognos Configuration для установки значения True параметра Enable the encryption of passport credentials? в разделе Security > Authentication. Имейте в виду, что это окажет некоторое незначительное влияние на скорость выполнение аутентификации и других операций, требующих доступа к учетным данным пользователей. Рекомендуется оставить эту функцию выключенной, если она явно не требуется политикой безопасности.

Общие сеансы

Когда несколько клиентов (Framework Manager, Transformer, Planning и т.д.) на одной рабочей станции обращаются к одной и той же системе IBM Cognos 10 BI, они могут пользоваться одним общим сеансом авторизации. Это помогает сократить количество одновременных активных сеансов в IBM Cognos 10, но потенциально менее безопасно, чем отдельные управляемые сеансы для каждого клиента. С другой стороны, это требуется для обеспечения единого входа для нескольких клиентов на одной рабочей станции. Это свойство задается в IBM Cognos Configuration с помощью параметра Allow session information to be shared between client applications? в разделе Security > Authentication. Значение этого параметра по умолчанию False, и лучше всего оставить его таковым, если нет нескольких клиентских приложений на одной рабочей станции, для которых желателен единый вход.

Ограничение доступа к IBM Cognos Connection

Если пространство имен настроено для аутентификации, подразумевается, что все пользователи из базового источника аутентификации должны иметь возможность входить в IBM Cognos BI и обращаться к IBM Cognos Connection. Однако это не всегда правильно, поскольку может существовать ограничение на доступ для подмножества всех пользователей из соответствующего источника аутентификации. В IBM Cognos 10 BI это можно сделать с помощью параметра конфигурации Restrict access to members of the built-in namespace в разделе Security > Authentication IBM Cognos Configuration. Если этому параметру присвоить значение True, то любому пользователю, который не входит, прямо или косвенно, в пространство имен Cognos, будет отказано в доступе. Встроенное пространство имен Cognos используется для отображения пользователей, групп и ролей из внешних источников аутентификации на определенную модель безопасности, зависящую от приложения. Подробнее пространство имен Cognos рассматривается в разделе "Концепции авторизации и практические рекомендации". Если пользователь или группа/роль из внешнего пространства имен назначается членом группы или роли в пространстве имен Cognos, он(а) неявно становится членом пространства имен Cognos.

Пример. Пользователи Роберт Смит и Марла Спирс определены в источнике LDAP, который настроен в качестве пространства имен LDAP IBM Cognos 10. В пространстве имен Cognos Роберту назначена роль Заказчики, а Марла не отнесена ни к какой группе или роли. Если параметру Restrict access to members of the built-in namespace? присвоено значение True, Роберт сможет войти в IBM Cognos 10 и получить доступ к Cognos Connection, а Марла ― нет, потому что она не является членом какой-либо группы или роли в пространстве имен Cognos.

Автоматическое возобновление достоверных учетных данных

В IBM Cognos 10 появилась новая функция, которая позволяет IBM Cognos 10 BI автоматически обновлять хранящиеся учетные данные для регламентов. Эту функцию можно настроить в IBM Cognos Configuration посредством параметра Automatically renew trusted credential в разделе Security > Authentication. Чтобы понять значение этого параметра, нужно несколько углубиться в детали.

Когда пользователь создает достоверные учетные данные для сохранения с регламентом или для передачи другому пользователю, который будет применять их для выполнения отчетов вместо того, кто сохранил эти учетные данные, создается объект, содержащий учетные данные для всех пространств имен, в которых пользователь аутентифицирован в настоящее время. В результате, так как в течение одного сеанса один пользователь может быть аутентифицирован в нескольких пространствах имен, достоверные учетные данные могут состоять из нескольких наборов учетных данных, по одному для каждого пространства имен. Первое пространство имен, для которого выполнена аутентификация сеанса, называется первичным пространством имен.

Достоверные учетные данные специализированы, потому что учетные данные пространства имен, в котором они хранятся, должны использоваться в любое время, независимо от какой бы то ни было метки времени. Это исключает билеты SSO, такие как SAP маркеры Kerberos или маркеры SAP, так как через некоторое короткое время срок их действия истекает, и они становятся непригодным для использования. Поэтому подходящие достоверные учетные данные обычно представляют собой пару, состоящую из имени пользователя и пароля. Однако в целях аутентификации IBM Cognos 10 BI на основе SSO для этого пространства имен не существует пароля, который может храниться в достоверных учетных данных. Таким образом, эта функция будет работать только для базовой аутентификации, когда пользователь указывает имя пользователя и пароль на экране входа в систему. В этом случае система просматривает все достоверные учетные данные этого пользователя и заменяет их учетными данными, которые он только что ввел.

Если для этого свойства указано значение Primary namespace only (значение по умолчанию), то будут обновлены достоверные учетные данные только одного набора учетных данных, а если указано значение All namespaces ― учетные данные для всех пространств имен, достоверных на текущий момент. Рекомендуется установить значение Primary namespace only, если аутентификация для пространства имен осуществляется не путем единого входа; в противном случае лучше установить значение Off.

Пространства имен

Некоторые рекомендации относятся к определенным типам пространств имен.

Уникальный идентификатор LDAP

После того как пользователь прошел аутентификацию и получил доступ к порталу IBM Cognos Connection, в базе данных Content Store сохраняется ссылка на учетную запись пользователя, называемая CAMID. В состав CAMID входит значение, возвращаемое атрибутом, соответствующим параметру определения пространства имен Unique identifier раздела Security > Authentication IBM Cognos Configuration. По умолчанию этот параметр устанавливается равным dn (Distinguished Name). Во всех серверах LDAP для каждой одиночной записи будет указан этот атрибут dn, что гарантирует, что независимо от типа сервера LDAP всегда существует атрибут, на котором может быть основан уникальный идентификатор. Однако эта практика не гарантирует, что учетные записи пользователя действительно уникальны. Рассмотрим следующий сценарий.

Компания ABC приобрела IBM Cognos 10 BI и успешно установила этот продукт для своей базы пользователей. Для подключения к корпоративному серверу каталога используется пространство имен LDAP. Исторически конфигурация по умолчанию пространства имен LDAP IBM Cognos 10 BI основана на Sun One Directory Server, так что значение параметра Unique identifier установлено равным dn. Вице-президент ABC по продажам в Северной Америке Джон Q. Смит часто пользуется IBM Cognos 10 BI и хранит конфиденциальные данные о продажах и прогнозы в своем разделе My Folders портала IBM Cognos Connection. Согласно корпоративному соглашению об именах "фамилия, имя", ему присвоена сетевая учетная запись пользователя SMITHJ, которая находится в пользовательской папке North America. Это означает, что dn Джона Q. Смита будет:

uid=SMITHJ, cn=North America, dc=Company ABC, dc=com

Некоторое время все шло хорошо. Но вот Джон Q. Смит решил перейти в другую компанию, и его учетная запись была удалена из корпоративной иерархии LDAP. Спустя несколько месяцев в компанию пришел младший менеджер Джон X. Смит. Опять, в силу соглашения об именах компании ABC Джон X. Смит получает сетевую учетную запись SMITHJ, так как она свободна. Это приводит к тому, что dn Джона Х. Смита будет:

uid=SMITHJ, cn=North America, dc=Company ABC, dc=com

Когда Джон Смит X. входит в IBM Cognos Connection и собирается сохранить свой первый отчет в разделе My Folders, он замечает, что его папка заполнена отчетами, содержащими конфиденциальные данные. Это произошло потому, что уникальный идентификатор основан на атрибуте, который может не оставаться уникальным с течением времени, как видно из приведенного примера. Единственный способ избежать такой ситуации - использовать атрибут с уникальным идентификатором, который гарантирует глобально уникальные значения для каждой записи, считываемой с сервера LDAP.

Большинство серверов LDAP обеспечивают такой атрибут, часто в составе операционных атрибутов. Операционные атрибуты доступны только для чтения и поддерживается только на сервере LDAP. Некоторые браузеры LDAP не показывают их по умолчанию и требуют явного действия для их чтения/отображения. Обратитесь к документации своего сервера LDAP, чтобы узнать, какой атрибут используется в качестве глобально уникального идентификатора записи. Например, IBM Tivoli LDAP использует ibm-entryuuid, Active Directory при обращении как к источнику LDAP использует objectGUID, а сервер Sun One Directory использует nsuniqueid.

Для параметра Unique identifier пространства имен LDAP рекомендуется применять этот глобально уникальный атрибут.

Конечно, надежная инфраструктура безопасности, построенная в компании ABC, не позволила бы создать две учетные записи SMITHJ (по крайней мере, с одним и тем же внутренним уникальным идентификатором), но и это простое изменение конфигурации добавит дополнительный уровень безопасности в вашу систему.

Примечание. Отображение атрибута должно быть изменено до авторизации на портале IBM Cognos Connection или/или предоставления пользователям доступа к IBM Cognos 10 BI. Если изменить отображение атрибута позже, все параметры безопасности объектов будут аннулированы, и пользователи не увидят своей информации. Дело в том, что после изменения этого параметра для каждого пользователя, входящего в систему с новым атрибутом уникального идентификатора, создается новый CAMID, так что в Content Store, по сути, создается новая учетная записи пользователя. Важно также помнить, что используемый атрибут должен быть доступным для всех объектов, таких как группы, папки и пользователи. Если выбранный атрибут существует только для пользователей, то при администрировании имен в IBM Cognos Connection некоторые объекты отображаться не будут.

LDAP-соединения

Источник услуг аутентификации LDAP IBM Cognos 10 BI можно настроить разными способами с точки зрения управления соединением и учетными данными, используемыми для связи с LDAP-сервером. В настоящее время многие из этих методов исследуются на предмет оптимальной реализации.

По существу, источник использует два типа соединений, для операций поиска и для операций, связанных с действиями пользовательского сеанса.

Соединения для операций поиска создаются с применением учетных данных связи, помещаются в пул и, следовательно, используются повторно. Размер пула по умолчанию составляет 20, и соединения не закрываются до тех пор, пока работа продукта не будет остановлена. Чтобы настроить размер пула и повлиять на то, будут ли соединения удаляться для источника данного типа, можно указать значения параметров minimumLDAPPoolSize и maximumLDAPPoolSize в группе Advanced properties определения пространства имен раздела Security > Authentication IBM Cognos Configuration. Если оба параметра установить в 0, соединения не будут помещаться в пул и будут закрываться сразу же после использования.

В случае соединений пользовательского сеанса учетные данные пользователя, введенные при входе, применяются для связи с источником, если параметру Use bind credentials for search не присвоено значение true. Это значение приведет к использованию вместо этого значений, указанных в параметре Bind user DN and password. Эти соединения остаются до завершения пользовательского сеанса. Если нужно минимизировать использование соединения, можно задать параметр unbindLDAPHandleAfterUse в группе Advanced properties, присвоив ему значение true. С помощью этих дополнительных параметров можно добиться минимального количества открытых соединений с LDAP-сервером.

Для крупных баз пользователей (свыше 50 одновременно работающих пользователей) рекомендуется использовать параметр unbindLDAPHandleAfterUse и оставить пул без изменений, так как 20 открытых соединений не окажут заметного влияния на LDAP-сервер. Если ваши правила требуют поддержания минимального количества открытых соединений, отключите пул поисковых соединений.

Microsoft Active Directory

При настройке имен Microsoft Active Directory (AD) можно использовать службу локатора на основе Microsoft DNS, которая позволяет находить доступный контроллер домена в сценариях аварийного переключения. В этом случае можно не указывать имя или IP-адрес контроллера домена узла в параметре Host and port пространства имен AD, а указать DNS-псевдоним домена, такой как domain.company.com. Это позволит службе DNS во всех ситуациях находить доступный контроллер домена и считается лучшим решением, которое используют многие клиенты.

Шифрование

Для шифрования и в качестве основы для поддержки протокола Secure Socket Layer (SSL) для шифрованных HTTP-соединений IBM Cognos 10 BI использует концепции Public Key Infrastructure (PKI). Детали выходят за рамки темы этого документа, но чтобы реализовать базовые требования безопасности и придерживаться практических рекомендаций, следует изменить значения по умолчанию некоторых параметров.

Идентичность

Каждый установленный экземпляр, то есть один или несколько компонентов, установленных в одном каталоге на поддерживаемой платформе, имеет идентифицирующую его учетную запись в IBM Cognos 10 BI. Так что даже два установленных экземпляра в двух разных каталогах одной и той же машины считаются разными сущностями. Это важно при шифровании сохраненных, временных или передаваемых данных в IBM Cognos 10 BI. Идентифицирующая учетная запись, концепция которой основана на стандарте X.509, называется Distinguished Name и состоит из полей Server common name, Organization name и Country or region code в разделе Security > Cryptography > Cognos > Identity name IBM Cognos Configuration. Значения этих полей по умолчанию нужно изменить, чтобы у каждой установки была своя идентичность. Это важнее всего тогда, когда внутренняя связь IBM Cognos 10 BI переводится на SSL, но и в целом считается полезным определить эти поля.

Рекомендуется указать уникальный параметр Server common name. Его значение должно быть полным допустимым именем сервера Domain Name System (DNS). Если на одной машине установлено несколько экземпляров с общим именем DNS, то чтобы различать экземпляры, настройте параметр Organization name в каждой конфигурации.

Пароль CA Service

Один из центральных элементов PKI ― Certifying Authority (CA) ― служит основой доверительных отношений и выдает и подписывает сертификаты, удостоверяя таким образом идентичность других объектов. В IBM Cognos 10 BI есть своя собственная служба СА, которая расположена в компоненте Content Manager и по умолчанию используется для подписи сертификатов, применяемых IBM Cognos 10 BI. Это имеет смысл для установок, где клиент не работает с корпоративными службами CA или требования по безопасности допускают использование специальных CA для конкретных приложений.

Когда конфигурация на любом установленном экземпляре сохраняется в первый раз, служба СА подписывает некоторые сертификаты для данного конкретного установленного экземпляра, подтверждая его идентичность. Поэтому для целостности и безопасности установки IBM Cognos 10 BI крайне важно, чтобы доступ к службе СА имели только достоверные экземпляры. Вот почему встроенная служба CA защищена паролем. Этот пароль указывается в IBM Cognos Configuration, в параметре Password раздела Certificate Authority settings меню Security > Cryptography > Cognos.

Рекомендуется изменить этот пароль по умолчанию. Для этого, прежде чем сохранить конфигурацию установки компонента Content Manager в первый раз, задайте в этой конфигурации новый пароль. Впоследствии задавайте новый пароль для всех экземпляров перед первым сохранением конфигурации каждой установки.

Пароли хранилищ ключей

Сертификаты хранятся в специальных файлах, называемых хранилищами ключей. Файлы в двоичном формате шифруются на основе пароля, который требуется для получения доступа к ним. IBM Cognos 10 BI использует три разных пары ключей и соответствующих сертификата для каждого экземпляра, одну для шифрования, одну для подписи и одну для Certifying Authority. Каждая пара ключей и сертификат, выданный для нее, содержатся в отдельном хранилище ключей, которое защищено паролем.

Каждый сертификат имеет собственные настройки в отдельном разделе IBM Cognos Configuration Security > Cryptography > Cognos. Пароли хранилищ ключей указаны в параметре <key purpose> password, где <key purpose> - это одно из хранилищ ключей подписи, шифрования или Certificate Authority.

Перед первым сохранением конфигурации экземпляра рекомендуется заменить значения по умолчанию паролей хранилищ ключей.

Cognos Application Firewall

Cognos Application Firewall (CAF)- это инструмент, дополняющий существующую инфраструктуру безопасности IBM Cognos 10 BI. Он действует как интеллектуальный прокси-сервер для IBM Cognos 10 BI Dispatcher и гарантирует, что адресованные ему входящие HTTP- и XML-запросы безопасны для обработки и исходящие ответы внешним клиентам или службам правильно закодированы и безопасны.

Безопасность в данном контексте относится к направляемым в продукт данным параметров, данным HTTP POST и вредоносным запросам, ставящим под угрозу безопасность системы. Наиболее распространенными формами вредоносных данных являются попытки переполнения буфера, атаки типа межсайтовых сценариев (XSS-ссылки), передаваемые путем внедрения в действительные страницы, переадресации на другие Web-сайты или SQL-инъекций, и атаки на основе идентификатора сеанса или cookie-файла. Cognos Application Firewall надежно защищает IBM Cognos 10 BI от этих атак, и в целом обрабатываются только проверенные параметры и данные.

Cognos Application Firewall управляется параметрами, которые настраиваются в разделе Security > IBM Cognos Application Firewall IBM Cognos Configuration. Чтобы CAF был включен, параметр Enable CAF validation? должен иметь значение True.

Ввиду его огромного вклада в общую безопасность и стабильность системы в производственной среде CAF никогда не рекомендуется отключать.

Допустимые домены или узлы

Наиболее важным параметром конфигурации CAF является список допустимых доменов или узлов, куда данные можно переадресовывать или откуда их можно получать. Это относится к таким функциям, как отображение на информационной панели канала из внешнего URL-адреса, включение фотографий с внешних серверов, интеграция IBM Cognos TM1 Contributor или переадресация в узел Lotus Connection для создания Activity.

Для каждого из перечисленных сценариев требуется добавление записи в список допустимых доменов или узлов CAF. CAF проверяет URL-адрес, используемый для доступа к внешнему (относительно IBM Cognos 10 BI) ресурсу, по списку допустимых доменов или узлов и отправляет запрос на внешний ресурс, только если совпадение найдено. Этот список явно разрешенных узлов имен или суффиксов доменов, к которым разрешен доступ, часто называют белым списком. Любой URL-адрес, который не включен в белый список, будет заблокирован CAF. Можно указать имя узла в нотации NetBIOS (например, MyServer) или суффиксы доменов с использованием шаблонов (например, *.domain.com), чтобы разрешить все узлы из определенного домена.

Список значений, разделенных запятыми, содержится в параметре Security > IBM Cognos Application Firewall > Valid domains or hosts IBM Cognos Configuration.

Рекомендуется по возможности явно указать имена узлов, а более общие суффиксы указателей доменов использовать только в доверенных сетях.


IBM Cognos Connection

Портал IBM Cognos Connection в IBM Cognos 10 BI ― это место, где указываются и администрируются почти все параметры безопасности, связанные с авторизацией. Сначала определяется, каким внешним объектам безопасности, таким как пользователи, группы и роли, которые поступают из внешнего источника аутентификации, будут назначены защищенные функции и возможности, а также определяется степень безопасности объектов для материалов приложения, таких как пакеты, отчеты и информационные панели.

В информационном центре IBM Cognos 10 имеется значительное количество информации о деталях и особенностях в этой области, поэтому мы будем отсылать туда за основами и приведем только дополнительные рекомендации, которые добавляют ценности тому, что уже документировано.

Концепция авторизации и практические рекомендации

Первым шагом к пониманию принципов авторизации IBM Cognos 10 BI является знание участвующих объектов. Вкратце, авторизация работает путем определения разрешений для защищаемых объектов и функций, организованных в иерархию, которая хранится в Content Store. Эта иерархия объектов инициализируется при первом запуске IBM Cognos 10 BI, когда таблицы Content Store создаются и заполняются объектами по умолчанию и разрешениями для них. В число этих объектов входит пространство имен Cognos, куда добавляются предопределенные роли и встроенные объекты, такие как группа Everyone и пользователь Anonymous.

В информационном центре IBM Cognos 10 есть дополнительная информация о первоначальных встроенных объектах и предопределенных ролях:

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16486asg_builtin_entries.html#asg_builtin_entries

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16550PredefinedEntries.html#PredefinedEntries

Разрешения по умолчанию, как и любой другой набор разрешений, определяют тип доступа пользователей, групп или ролей из любого пространства имен, включая пространство имен Cognos, к защищаемым объектам или функциям. После инициализации внешним объектам безопасности больше не выдается никаких разрешений в пространстве имен Cognos. Авторизация определяется только на основе объектов из пространства имен Cognos. На самом деле это хорошая отправная точка для реализации практических рекомендаций по авторизации, так как это наиболее гибкий и управляемый подход к использованию и, следовательно, наилучшая практика.

Первоначальные разрешения доступа можно найти в информационном центре IBM Cognos 10:

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id49368asg_contentmamager_hierarchy.html#asg_contentmamager_hierarchy

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id53448asg_bux_access_permissions.html#asg_bux_access_permissions

Авторизация определяется как назначение разрешений для пользователей, групп и ролей, которые в свою очередь определяются для защищаемых объектов, таких как отчеты, регламент, защищенные функции или возможности. Так как пользователи могут приходить только из внешних пространств имен, пространство имен Cognos не поддерживает пользователей (за исключением встроенного пользователя Anonymous), и администратор должен прямо или косвенно назначить пользователей защищаемых объектов Cognos. Под косвенным назначением имеется в виду назначение для групп или ролей, членом которых является пользователь.

Если в разрешении пользователь указывается явно, это разрешение зависит от пространства имен, к которому относится пользователь. Если пространство имен становится недоступным, или изменился уникальный идентификатор пользователя, эта связь будет аннулирована. Это одна из причин, по которым уникальный идентификатор пользователя должен основываться на некотором глобально уникальном атрибуте источника аутентификации, а не на структурно зависимой информации. Для серверов LDAP DN, по существу, представляет собой путь к записи. Если пользователь перемещается в иерархии объектов LDAP, то путь изменяется, и если он идентифицируется в Cognos по DN (который используется по умолчанию), то его уникальный идентификатор в Cognos будет изменен, и разрешения будут аннулированы. Следуя практическим рекомендациям по выбору уникальных идентификаторов, которые приведены выше, в частности для пространств имен LDAP, вы избежите этого. Active Directory безопасен, поскольку objectGUID не зависит от структурной информации. Этот сценарий применим и к неявным ссылкам: так как то же утверждение справедливо и для внешних ссылок на группы или роли, они идентифицируются своим уникальным идентификатором в IBM Cognos 10 BI.

Еще одна проблема заключается в том, что не исключено, что базовый источник аутентификации может измениться. Если для тестовой среды использовался LDAP, то в производственной может использоваться экземпляр Active Directory. Это означает, что объектам из внешних пространств имен были непосредственно назначены разрешения и функции, и ссылки на эти пространства имен будут нарушены, потому что в другом пространстве имен этим объектам будут назначены другие уникальные идентификаторы.

Для смягчения этих проблем существует простое правило в отношении авторизации - все ссылки в разрешениях, возможностях и защищенных функциях следует давать только на группы и роли из пространства имен Cognos. Это означает, что для определения разрешений должны использоваться только группы и роли, созданные в пространстве имен Cognos. Например, чтобы разрешить определенной группе пользователей работать в IBM Cognos 10 Studio, нужно либо воспользоваться одной из предопределенных ролей из пространства имен Cognos, либо явно создать для этой цели новую роль и предоставить этой роли соответствующую возможность. Хотя создание нескольких новых групп или ролей в пространстве имен Cognos может показаться обременительным, на самом деле это очень полезно. И вот почему:

  • все ссылки на объекты, используемые в разрешениях, останутся неизменными даже при смене членов группы/роли;
  • содержание пространства имен Cognos можно переносить в другие системы IBM Cognos 10;
  • процесс создания или назначения внешних объектов записям пространства имен Cognos можно автоматизировать с помощью IBM Cognos 10 SDK.

Рассмотрим простой пример.

Проект разрабатывается в тестовой среде с использованием простого источника LDAP с некоторыми тестовыми пользователями. Проектная группа установила разрешения так, что несколько относящихся к проекту объектов групп и ролей оказались добавленными к пространству имен Cognos взамен или помимо записей имен Cognos по умолчанию. На следующем этапе они назначили пользователей и группы из источника LDAP новым записям объектов пространства имен Cognos, связанным с проектом, и впоследствии определили разрешения для возможностей studio, доступа к пакетам и даже фильтров безопасности IBM Cognos Framework Manager (фильтры, которые встроены в модель запроса данных), основанные на новых объектах пространства имен Cognos.

После завершения разработки в тестовой среде приложение IBM Cognos 10, состоящее из пакетов, отчетов и т.д., развертывается в подготовительной среде, где используется Active Directory с многими тысячами пользователей. Это означает, что должны быть добавлены другие пользователи, и существующие ссылки на объекты внешнего пространства имен будут нарушены.

Однако поскольку проект следовал практическим рекомендациям, и все ссылки в разрешениях, возможностях и защищенных функциях делались только на группы и роли из пространства имен Cognos, удалось легко экспортировать приложение IBM Cognos 10 в установку, содержащую пространство имен Cognos. Это позволит сохранить все разрешения, и в целевой среде останется только настроить назначение пользователей и групп из Active Directory для ролей и групп, определенных в пространстве имен Cognos. Все остальное останется неизменным без необходимости изменять или настраивать хоть одно разрешение. Это сэкономит много времени и сохранит гибкость проекта. Кроме того, если они определили группы в своем Active Directory так, чтобы сохранить пользователей и только назначить группы AD группам и ролям пространства имен Cognos, они смогут даже частично управлять авторизацией в AD, а не в Cognos. Для некоторых клиентов это важно ввиду уже существующей интеграции управления идентичностью или имеющихся процессов управления доступом.

Пользователи, группы и роли

Обслуживание пользователей

IBM Cognos 10 BI хранит профили пользователей и их информацию в базе данных Content Store. В среде, где много пользователей, они могут занимать довольно много места. В большинстве компаний пользователи периодически удаляются из источников аутентификации, так зачем же держать в Content Store устаревшие профили и информацию?

Следующие рекомендации предполагают, что профиль пользователя удаляется из IBM Cognos 10 BI до удаления учетной записи пользователя из источника аутентификации.

  • Войдите в IBM Cognos Connection через учетную запись пользователя с ролью Directory Administrator.
  • Выберите Launch > IBM Cognos Administration.
  • В IBM Cognos Administration перейдите на вкладку Security.
  • Щелкните на пространстве имен, содержащем учетную запись пользователя, намеченную к удалению.
  • Найдите пользователя, профиль которого необходимо удалить. Если иерархия пространства имен глубока и/или местоположение учетной записи пользователя неизвестно, примените функцию Search. В правом верхнем углу появится значок поиска в виде лупы.
  • В столбце Actions нажмите на ссылку More....
  • Удалите профиль, нажав на ссылку Delete this user's profile.
  • Нажмите кнопку ОК, чтобы подтвердить удаление профиля пользователя.

В большинстве систем активное удаление учетной записи пользователя невозможно. К счастью IBM Cognos 10 BI обеспечивает механизм для синхронизации профилей, содержащихся в Content Store, с соответствующими внешними пространствами в отношении учетных записей пользователей.

  • Как пользователь с административным доступом к 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 в правом верхнем углу, пока состояние не изменится на succeeded (успешно) или failed (неудачно). На этой странице будут отображаться любые сообщения о конкретных пользователях.
  • Если выбран вариант запуска по расписанию, новое расписание будет сохранено вместе с доверенными учетными данными на основе текущей аутентификации. Достоверные учетные данные будут включать все пространства имен, в которых пользователь аутентифицирован на данный момент. Укажите интервал и время запуска и выберите режим использования: Find only (только найти) или Find and fix (найти и исправить).

Задача выполнит проверку целостности, чтобы убедиться, что профили пользователей, хранящиеся в базе данных Content Store, синхронизированы с пользователями из внешних пространств имен. Если какие-то пользователи не найдены во внешнем источнике аутентификации, и для них имеется профиль в Content Store, будет выдано сообщение о том, что учетная запись в источнике внешней аутентификации больше не существует. Если был выбран режим Find and Fix, профиль пользователя будет удален из Content Store.

Для экономии пространства Content Store рекомендуется планировать задачу обслуживания Content Store на выполнение этого действия, по крайней мере, один месяц.

Дополнительные сведения по этой теме можно найти в Руководстве по администрированию и безопасности IBM Cognos 10 BI в Информационном центре IBM Cognos 10:

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id8165content_store_maint.html#content_store_maint

Присвоение имен группам и ролям

Чтобы лучше организовать роли в пространстве имен Cognos, которое в большой системе может стать перенаселенным, рекомендуется создавать папки для логического разделения ролей. Имена этих папок будут составлять часть пути поиска роли. Путь поиска ― это путь, описывающий местоположение объекта в иерархии Content Store. Например, можно создать две папки, и в каждой из них могут находиться роли с одинаковыми именами. Для иллюстрации, в пространстве имен Cognos созданы две папки, одна с именем Roles East, а другая ― Roles West. В каждой папке создана роль Data Administrators.

Directory > Cognos > Roles East > Data Administrators
Directory > Cognos > Roles West > Data Administrators

Две роли с одним и тем же именем допустимы, потому что имя родительской папки становится частью пути поиска для каждого объекта. В то же время для объектов в пространстве имен Cognos внутренний идентификатор этих объектов, именуемый CAMID, также содержит часть пути поиска.

CAMID(":Roles East:Data Administrators")
CAMID(":Roles West:Data Administrators")

Хотя такое соглашение об именах работает и поддерживается в IBM Cognos 10 BI, этот подход не рекомендуется. Он может легко привести к ошибкам при определении разрешений или безопасности для объектов, так как при отображении в списке членов объекты кажутся одинаковыми. Если тот, кто занимается безопасностью, не знает о двух отдельных группах, он может ошибочно предоставить доступ к объекту или отказать в нем. На следующем рисунке показан пример этого, поскольку IBM Cognos Connection не предоставляет дополнительного контекста, который позволял бы с первого взгляда определить, объект с какой ролью принадлежит к той или иной папке.

Рисунок 1. Список членов роли IBM Cognos Connection, содержащий двух членов с одним и тем же именем, неразличимых на первый взгляд
Рисунок 1. Список членов роли IBM Cognos Connection, содержащий двух членов с одним и тем же именем, неразличимых на первый взгляд

Если необходимо создать роли с одним и тем же именем, их можно различать с помощью всплывающей подсказки. Как видно на следующем рисунке, этот инструмент позволяет отображать полный путь к объекту, когда пользователь помещает курсор мыши над многоточием (...).

Рисунок 2. Список членов роли в IBM Cognos Connection, содержащий двух членов с одним и тем же именем, но всплывающая подсказка обеспечивает контекст, показывая путь поиска
Рисунок 2. Список членов роли в IBM Cognos Connection, содержащий двух членов с одним и тем же именем, но всплывающая подсказка обеспечивает контекст, показывая путь поиска

Во избежание дублирования имен ролей или групп следует принять соглашение об именах. Обычно записи снабжаются префиксом типа "R_" для роли и "G_" для группы, а также, если требуется, дополнительными префиксами для указания источника. Например, R_HR_Approver и R_Marketing_Approver могут быть двумя ролями с разными путями поиска или даже с одним и тем же путем. Префикс в приведенном выше примере позволяет различать их.

Разрешения

Информационный центр IBM Cognos 10 содержит достаточно сведений о разрешениях и их использовании. Важно понять описанные там идеи, чтобы избежать ловушек.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id15131AccessPermissions.html#AccessPermissions

Запрет имеет приоритет

Доступ к записи можно предоставить или запретить. Запрет доступа имеет приоритет над предоставлением доступа. Поэтому если запретить определенным пользователям, группам или ролям доступ к записи, но изменить другие правила безопасности, которые предоставляют доступ к этой записи, запрет и разрешение вступают в конфликт, и доступ к записи будет всегда запрещен. Например, пусть пользователь принадлежит к двум группам. Одной группе разрешен доступ к отчету, а другой доступ к тому же отчету запрещен. Тогда пользователю будет отказано в доступе к этому отчету.

Рекомендуется запрещать доступ только тогда, когда это действительно необходимо. Как правило, лучше явно предоставлять разрешения, чем запрещать.

Нарушение наследования путем явного переопределения

Разрешение доступа передается от родительских записей. Если права доступа не определены явно, запись перенимает разрешения у своей родительской записи. Это можно изменить/переопределить и, таким образом, нарушить наследование родительских разрешений путем явного определения разрешений для дочерней записи.

Объекты, которые существуют только как потомки других объектов, всегда получают разрешения от своих родителей. Примерами таких объектов служат спецификации и результаты отчета. Этими объектами можно манипулировать с помощью SDK IBM Cognos 10, но для них нельзя устанавливать разрешения с помощью IBM Cognos Connection.

Удаление стандартных групп и ролей

При удалении из пространства имен Cognos стандартной группы или роли удаляются и основанные на них права доступа. В IBM Cognos 10 их можно восстановить, создав новую группу или роль в пространстве имен Cognos точно с таким же именем, что приведет к созданию такого же внутреннего идентификатора (CAMID). Для внешних групп или ролей (которые считываются из внешних источников аутентификации через поставщика услуг аутентификации) следует проверить, как поставщик поступает в таких ситуациях. Как правило, если права доступа основаны на идентификаторах, их восстановить нельзя, а если на именах, то можно. Примером может служить пространство имен LDAP с использованием атрибута DN в качестве уникального идентификатора, состоящего из одной строки. Однако, как говорилось выше, это несет с собой риск нежелательного доступа к профилям пользователей и не рекомендуется, так что заявление об удалении групп и ролей нужно считать общеприменимым правилом. Не удаляйте группы или роли, если вы не абсолютно уверены, что они вам больше не нужны. Будут потеряны все права, назначенные группе или роли.

Возможности

В IBM Cognos 10 BI много защищенных функций, которые находятся под контролем прав, назначенных соответствующим возможностям. Информация о защищенных функциях и возможностях содержится в Информационном центре IBM Cognos 10 по следующей ссылке. Важно прочесть описания и полностью понять последствия разрешения доступа к функции или возможности для структуры безопасности. Вероятно, можно сделать больше, чем просто удалить группу Everyone из различных ролей и возможностей.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id15670ReportNetSecuredFunctionsandFeatures.html#ReportNetSecuredFunctionsandFeatures

После инициализации базы данных Content Store устанавливаются разрешения по умолчанию, которые позволяют начать с готовой стандартной конфигурации. Первоначальные объекты и разрешения Content Store описаны в Информационном центре IBM Cognos 10 по следующей ссылке:

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id49368asg_contentmamager_hierarchy.html#asg_contentmamager_hierarchy

Однако первоначальные разрешения не всегда отражают оптимальные настройки для конкретной системы и не обеспечивают никакой модели лицензирования или соблюдение таковой. Это просто пример конфигурации, который можно использовать. Для эффективного применения политики безопасности необходимо рассмотреть различные возможности и изменить разрешения по умолчанию. По следующей ссылке в Информационном центре IBM Cognos 10 приведены дополнительные сведения о выборе параметров безопасности:

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16676SpecifySecuritySettingsAfterInstallation.html#SpecifySecuritySettingsAfterInstallation

Возможности существуют не только на общем уровне, но и на уровне пакета. Эту функцию можно использовать для управления доступом посредством IBM Cognos 10 studios для пакетов и, следовательно, для источников данных.

Рекомендуется начать с определения объектов в пространстве имен Cognos и только после этого назначать возможностям имена ролей и групп.

Учетные данные источника данных

В версии IBM Cognos BI 10 появилась новая функция, с помощью которой пользователи могут управлять своими собственными учетными данными базы данных, если им предоставлен доступ к возможности Manage own data source. Это может снять с администратора IBM Cognos 10 бремя поддержки или администрирования большого количества хранимых учетных данных и побудить пользователей следить за своими собственными учетными данными.

Рекомендуется решить, хотите ли вы предоставить своим пользователям такую возможность, до реализации источников данных. Причина в том, что если пользователям было разрешено управлять своими учетными данными, а позднее администратор решает перейти на статический вход, то все сохраненные пользователями учетные данные будут переписаны, а это может нарушить отчеты и/или план-графики. Найти такие места будет сложно, и на исправление придется затратить значительные усилия. Так что это решение лучшее принимать до начала реализации проекта.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=831920
ArticleTitle=Практика работы с IBM Cognos: Обеспечение безопасности среды IBM Cognos 10 BI
publish-date=08272012