目次


ロール・ベース・セキュリティーを使用したダイナミックレポーティングの概念に関して

Comments

1. はじめに

IBM Cognos 8 BIは、全社規模でレポート作成や分析、スコアカード作成やイベント通知を可能にするビジネス・インテリジェンス製品です。
また、IBM Cognos 8 BIは単一のWebサービス・アーキテクチャー上に構築されており、企業内のあらゆるレベルからウェブ・ブラウザ経由で簡単にアクセスしてレポートの作成や情報の分析を行うことができます。上記に加えて、ロール・ベース・セキュリティーを利用することで、単一のフォーマット(レポート)からユーザーの職種や役割に応じて内容を変えて表示するダイナミックなレポートを作成することが可能です(図1)。

図1. 従来のレポート(左)とIBM Cognos 8 BIのダイナミックなレポート(右)の比較イメージ
図1. 従来のレポート(左)とIBM Cognos 8 BIのダイナミックなレポート(右)の比較イメージ
図1. 従来のレポート(左)とIBM Cognos 8 BIのダイナミックなレポート(右)の比較イメージ

なお、文中では企業体などで職位や職種ごとの役割に応じて情報にセキュリティーをかけることをロール・ベース・セキュリティーと表現しています。この機能にて、前述のように、単一レポートを複数の用途に利用することができます。

上記の利点には以下が挙げられます。

  • 全社的なコンセプトの共有
  • レポート作成およびメンテナンスの簡便化(同じレポートフォーマットとデータソースを共有するため)
  • データ・インテグリティー
  • データソース側のメンテナンスの簡便化(レポート自体に直にデータを保存しないため)

本稿では、架空の会社Great Outdoors社をモデルに、IBM Cognos 8 BIを利用して、社内での職位や職種に応じて、同一のレポートを表示させてもコンフィデンシャルな人事関係の情報へのアクセスを制限する方法を述べています。

次項より、ロール・ベース・セキュリティーを使用したダイナミックなレポートの作成方法を論じます。

2. ロール・ベース・セキュリティー実装のために利用するIBM Cognos 8 BIの機能

IBM Cognos 8 BIの以下の機能を利用してロール・ベース・セキュリティーの実装を行います。

  • 認証プロバイダーの設定
  • グループと役割を利用したセキュリティー管理
  • パラメーター・マップ
  • クエリー・フィルタリング
  • ダイナミック・フィルタリング
  • OpenLDAPを使用したIBM Cognos 8 BIの認証設定

以下に各機能の概要を記載します。

  1. 認証プロバイダーの設定
    IBM Cognos 8 BIでは、認証プロバイダーによってユーザー認証を管理します。ここでは認証プロバイダーとしてOpenLDAPを使用し、IBM Cognos Configurationにて、OpenLDAPを外部ネームスペースとして認証プロバイダーに設定します。
  2. グループと役割を利用したセキュリティー管理
    不特定のコンピュータで使用できる配布可能なグループや役割が必要な場合、認証プロバイダーで必要なグループや役割を作成し、各々に権限を付与します。
  3. パラメーター・マップ
    Framework Manager上で使われるルックアップテーブルのようなもので、2項目間で値の対応関係の定義が必要な場合に利用されます。以下でOpenLDAP内のアカウント名とデータソース内の従業員コードとの対応付けのために使用しています。
  4. クエリー・フィルタリング
    クエリーサブジェクトに対して適用させるフィルタです。ログオンユーザーごとに表示を変える場合など、動的な条件に合致した結果を返すために利用されます。
  5. ダイナミック・フィルタリング
    ログオンしたユーザーの職種や役割によって表示される値を変換するために、データアイテムの式に設定する条件です。
  6. OpenLDAPを使用したIBM Cognos 8 BIの認証設定
    OpenLDAPを外部ネームスペースとして設定し、その中のユーザー情報を利用してIBM Cognos 8 BI側にセキュリティーをかけるための設定です。詳細はDeveloper Works「OpenLDAPを使用したIBM Cognos 8 BIの認証設定方法」をご参照下さい。

3.サンプル・ケース

この章では、本稿で利用するサンプル・ケースについて説明します。
架空の会社Great Outdoors社をモデルに作成された一連のサンプルは、製品の機能と、製品を利用する際の技術的および技術以外のビジネス的なベストプラクティスの説明を行うために、IBM Cognos 8 BIに含まれています。ロール・ベース・セキュリティーに基づいて表示情報を変化させるダイナミック・レポートの作成方法をサンプルパッケージの一つである「Great Outdoors Warehouse」を利用して説明します(図2)。

サンプル・ケース概要

  • 社員(ユーザー)の氏名や部署はOpenLDAP内に保存されている。
  • 給与などのデータはデータソースに保存されている。
  • Great Outdoors社内で人事関係の情報へのアクセスを制限しOpenLDAPに部門毎のアカウントやグループを登録する。
  • アジア太平洋の人事部門には、6人の社員が所属し、内2人は役員としてデータに対して人事情報およびコンフィデンシャル情報に対して、フルアクセス権を所有する。
  • 人事部門の社員は、自国の人事情報のみにアクセスが可能。しかし、給料、ボーナスなどのコンフィデンシャルな人事情報は役員のみがアクセス可能なようにセキュリティーを設定する。
  • 人事部門以外の社員には、自分の人事情報のみにアクセス権限を付与する。
  • OpenLDAPをLDAP V3 に準拠するディレクトリサーバーとしてセキュリティーの設定に利用する。
図2. IBM Cognos 8 BIの機能とサンプル・ケースの概要
図2. IBM Cognos 8 BIの機能とサンプル・ケースの概要
図2. IBM Cognos 8 BIの機能とサンプル・ケースの概要

4. ロール・ベース・セキュリティーの設定手順

4.1. 手順の概要

この章では、前章で説明したサンプル・ケースを用いて、ロール・ベース・セキュリティーを実装する具体的な手順を説明します。手順の概要は以下の通りです。

4.2 OpenLDAPのエントリをIBM Cognos 8 BIのセッション・パラメーターにマッピングする
4.3 OpenLDAPのアカウントやグループをネームスペース「Cognos」のグループや役割に登録する
4.4 Framework Managerのパラメーター・マップを設定する
4.5 Framework Managerで、条件付きクエリー・フィルタを作成する
4.6 Report Authoringにて、ダイナミック・レポートを作成する

次に、それぞれの手順の詳細について説明していきます。

4.2. OpenLDAPのエントリをIBM Cognos 8 BIのセッション・パラメーターにマッピングする

サンプルパッケージ「Great Outdoors Warehouse」のデータソースに合わせて、OpenLDAP上にアジア太平洋の人事部門のグループ「Human Resources: Go Asia Pacific」が登録され、また、人事部門メンバーのアカウントが、このグループの「uniqueMember」として登録されているとします(図3)。

図3. OpenLDAP:アジア太平洋の人事部門のメンバーとして登録されているユーザー
図3. OpenLDAP:アジア太平洋の人事部門のメンバーとして登録されているユーザー
図3. OpenLDAP:アジア太平洋の人事部門のメンバーとして登録されているユーザー

なお、デフォルトの設定では、OpenLDAPはユーザーIDに対して「inetorgperson.schema」を利用します。このスキーマでは、「departmentNumber」や「employeeNumber」などのエントリを登録することが可能です(図4)。

図4. LDAP Browser:OpenLDAPのエントリー
図4. LDAP Browser:OpenLDAPのエントリー
図4. LDAP Browser:OpenLDAPのエントリー

OpenLDAPに登録されたエントリーをIBM Cognos 8 BIで使用するには、IBM Cognos Configuration上、OpenLDAP用に作成された外部ネームスペース(例:「LDAP_NS」)で、プロパティーの設定を行う必要があります。
今回のサンプル・ケースでは、図5のIBM Cognos Configuration→「セキュリティー」→「認証」→「外部ネームスペース名」→「グループマッピング(詳細)」欄の「groupOfUniqueNames」と「uniqueMember」で設定を行います。OpenLDAPに登録されたクループ及びグループのメンバー情報はこの設定でIBM Cognos 8 BI内のセキュリティーにマッピングされることになります。
また、OpenLDAPのcnエントリーは、「外部ネームスペース名」→「アカウントマッピング(詳細)」欄で設定することが可能です。各プロパティーの項目値はご利用のOpenLDAPで設定されているスキーマのエントリーに合わせて行って下さい。例えば、図5の様に「givenname」、「userPassword」、「mail」、「cn」などのエントリーをアカウントマッピングのプロパティーとして設定することができます。

図5. IBM Cognos Configuration:外部ネームスペース「LDAP_NS」の設定
図5. IBM Cognos Configuration:外部ネームスペース「LDAP_NS」の設定
図5. IBM Cognos Configuration:外部ネームスペース「LDAP_NS」の設定

その他、「departementNumber」や「employeeNumber」など、アカウントマッピングのプロパティー設定に無いエントリーは、IBM Cognos Configuration内でカスタムプロパティーとして登録することが可能です。「アカウントマッピング(詳細)」欄→「カスタムプロパティー」をクリックしてウィンドウを開き、ここでOpenLDAPのエントリーを登録します(図6)。

図6. IBM Cognos Configuration:カスタムプロパティーの値を入力するウィンドウ
図6. IBM Cognos Configuration:カスタムプロパティーの値を入力するウィンドウ
図6. IBM Cognos Configuration:カスタムプロパティーの値を入力するウィンドウ

4.3. OpenLDAPのアカウントやグループをネームスペース「Cognos」のグループや役割に登録する

より簡単にセキュリティー設定を管理するにはネームスペース「Cognos」のデフォールトグループや役割を利用されることをお奨めします。
作業内容としては、IBM Cognos Administrationの「セキュリティー」タブ→「ユーザー、グループ、及び役割」でOpenLDAPのアカウントやグループをネームスペース「Cognos」のグループや役割に登録を行います。
OpenLDAPにて「groupOfUniqueNames」として登録した各々のエントリーは、外部ネームスペース「LDAP_NS」のオブジェクトクラスのエントリーにマッピングされています。OpenLDAP上のグループをネームスペース「Cognos」のグループや役割に追加した時に、そのグループの「uniqueMember」は同ネームスペースのグループや役割のメンバーになります。
今回のサンプル・ケースでは、ネームスペース「Cognos」の「使用者」の役割にアジア太平洋の人事部門であるOpenLDAP上のグループ「Human Resources: Go Asia Pacific」を追加します(図7)。

図7. IBM Cognos Administration:OpenLDAPエントリー「groupOfUniqueNames」をネームスペース「Cognos」の役割に追加する
図7. IBM Cognos Administration:OpenLDAPエントリー「groupOfUniqueNames」をネームスペース「Cognos」の役割に追加する
図7. IBM Cognos Administration:OpenLDAPエントリー「groupOfUniqueNames」をネームスペース「Cognos」の役割に追加する

4.4. Framework Managerのパラメーター・マップを設定する

パラメーター・マップはキーバリュー・ペアーの形式としてデータソースのルックアップテーブルのようにFramework Managerでは2列で表わされます。
Framework Managerが正しく値を扱うためには、パラメーター・マップのキーはユニークなキーで登録されている必要があります。また、その値には「“(クォーテーション・マーク)」を含めないように登録しなければなりません。 実際にパラメーター・マップを作成するには、Framework Managerの「Project Viewer」→「Parameter Map」を右クリックし、「Create」→「Parameter Map」を選択します(図8)。

図8. Framework Manager:パラメーター・マップを作成する方法
図8. Framework Manager:パラメーター・マップを作成する方法
図8. Framework Manager:パラメーター・マップを作成する方法

次に、図9の様に「Parameter Map」を選択して表示される「Parameter Map Definition」の画面で、パラメーター・マップのキー及び値を登録します。
新しいキーを登録するには、「New Key」ボタンをクリックします。「Edit」や「Delete」ボタンで既に登録されたキーを編集や削除することもできます。登録されたキーと値を全て削除するには「Clear Map」ボタンを使用します。
「Export File」ボタンにて、登録されたキーと値をCSVファイルに出力することが可能です。作成されたCSVファイルをテキストエディターなどで編集した後に「Import File」ボタンで、このCSVファイルの内容をパラメーター・マップに挿入することもできます。
今回のサンプル・ケースでは、OpenLDAPに登録されているユーザーのログオンアカウントをデータベースに登録された「ユーザー名」および「従業員キー」に一致させるために、「All_EmpKey」の名称でパラメーター・マップをFramework Manager上に作成します。

図9. Framework Manager:Parameter Map Definitionにて、全てユーザーアカウントと「従業員キー」のマップをキーバリュー・ペアーの形式で登録する
図9. Framework Manager:Parameter Map Definitionにて、全てユーザーアカウントと「従業員キー」のマップをキーバリュー・ペアーの形式で登録する
図9. Framework Manager:Parameter Map Definitionにて、全てユーザーアカウントと「従業員キー」のマップをキーバリュー・ペアーの形式で登録する

4.5. Framework Managerで、条件付きクエリー・フィルタを作成する

ログオンしたユーザーに対して、そのユーザーがアクセスを許可されたデータのみにアクセスできるような制限を設定するには、クエリーサブジェクトに対して、以下のようなフィルターを適用します。

 
[ビジネス ビュー].[クエリーアイテム] = #sq($ALL_EmpKey{$account.personalInfo.userName})#

Query Subject Definitionの「Test」タブよりクエリーサブジェクトを実行した際に、前述の式にある「ALL_EmpKey」に一致したアカウント名の値がフィルタ句に変換されることによって、クエリーはそのユーザーに関連するデータのみを返すことができます。
フィルタを設定していない場合、Framework Manager上のクエリーサブジェクト「従業員 (職位/部門別)」に対してクエリーを実行すると、図10のように、クエリーは全てのユーザーに関連したレコードを返します。

図10. Framework Manager:フィルタを使用しない場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果
図10. Framework Manager:フィルタを使用しない場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果
図10. Framework Manager:フィルタを使用しない場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果

一方、「従業員キー」フィールドに対して前述のフィルタを設定した後に、一般社員「ayamada」のアカウントでFramework Managerにログオンして同じクエリーサブジェクトに対してクエリーを実行すると、クエリーは一般社員:山田明美に関連したレコードのみを返します(図11)。

従業員キーアカウント名ユーザー名Position
4032ayamada山田明美一般社員

なお、Query Subject Definition内の「Filter」タブ→「Filter Definition」にて、「Expression Definition」に登録したフィルター句で使用されているパラメーターの解決は、「Tips」のボックスで確認することができます(図12)。

図11. Framework Manager:「従業員キー」フィールドに対して、フィルターを設定した場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果(一般社員:山田明美にアクセス許可されたレコードのみが返される。)
図11. Framework Manager:「従業員キー」フィールドに対して、フィルターを設定した場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果(一般社員:山田明美にアクセス許可されたレコードのみが返される。)
図11. Framework Manager:「従業員キー」フィールドに対して、フィルターを設定した場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果(一般社員:山田明美にアクセス許可されたレコードのみが返される。)
図12. Framework Manager:#sq($ALL_EmpKey{$account.personalInfo.userName})#を使用するフィルターの設定
図12. Framework Manager:#sq($ALL_EmpKey{$account.personalInfo.userName})#を使用するフィルターの設定
図12. Framework Manager:#sq($ALL_EmpKey{$account.personalInfo.userName})#を使用するフィルターの設定

次に、1つのフィルターに複数のフィルター条件を指定する方法を説明します。Query Subject Definitionの「Filter」タブ→フィルターのプロパティーで設定することができます。注意点としては、このプロパティーでは「if..then..else」や「case..」文は複数のデータアイテムに対して条件指定ができないため、今回のケースでは使用することができません。従って、同じような条件を「and」と「or」のSQL文に変換することが必要になります。
例えば、人事部門のメンバーの場合そのユーザーの国の全ての人事情報にアクセスすることが可能ですが、 人事部門以外のユーザーは本人の人事情報にしかアクセスできません。このようなセキュリティー上のアクセス制限をするには、以下の「if文」を利用することで実現することができます。

If ログオンユーザーのグループ = nonHR then 「従業員キー」 = EmpKey
Else [国コード] = Country_Code

ログオンユーザーのグループが「nonHR」の場合、フィルターにパラメーター・マップから「従業員キー」を設定し、それ以外の場合には、「国コード」を利用するように設定します。(図13、14)
今回のケースは「and…or」SQL文で表現するので、以下のように設定することになります。

(ログオンユーザーグループ = nonHR and 「従業員キー」 = EmpKey)
or (ログオンユーザーグループ <> nonHR and [国コード] = Country_Code)

実際には、クエリー・フィルターに以下の式を設定しています。

(#sq($HR_Country{$account.personalInfo.userName})# ='nonHR'
 and
[ビジネス ビュー].[従業員 (地域別)].[従業員キー] = #sq($ALL_EmpKey{$account.personalInfo.userName})#)
or
(#sq($HR_Country{$account.personalInfo.userName})# <>'nonHR'
and [ビジネス ビュー].[従業員 (地域別)].[国コード]  = #sq($HR_Country{$account.personalInfo.userName})#)
図13. Framework Manager:ログオンユーザーが人事部門の社員以外の場合、「nonHR」を「国コード」に設定するパラメーター・マップの設定
図13. Framework Manager:ログオンユーザーが人事部門の社員以外の場合、「nonHR」を「国コード」に設定するパラメーター・マップの設定
図13. Framework Manager:ログオンユーザーが人事部門の社員以外の場合、「nonHR」を「国コード」に設定するパラメーター・マップの設定
図14. Framework Manager:ユーザーのログオンアカウントと「従業員キー」をリンクさせるパラメーター・マップップの設定
図14. Framework Manager:ユーザーのログオンアカウントと「従業員キー」をリンクさせるパラメーター・マップップの設定
図14. Framework Manager:ユーザーのログオンアカウントと「従業員キー」をリンクさせるパラメーター・マップップの設定

サンプルパッケージ「Great Outdoors Warehouse」では、図15、図16のように設定されています、クエリーサブジェクト「従業員 (職位/部門別)」に複数条件のフィルターが設定されています。

図15. Framework Manager:複数のフィルター条件は「and..or」SQL文で設定する(「ayamada」でログオンした場合)
図15. Framework Manager:複数のフィルター条件は「and..or」SQL文で設定する(「ayamada」でログオンした場合)
図15. Framework Manager:複数のフィルター条件は「and..or」SQL文で設定する(「ayamada」でログオンした場合)
図16. Framework Manager:複数のフィルター条件は「and..or」SQL文で設定する(「dtanaka」でログオンした場合)
図16. Framework Manager:複数のフィルター条件は「and..or」SQL文で設定する(「dtanaka」でログオンした場合)
図16. Framework Manager:複数のフィルター条件は「and..or」SQL文で設定する(「dtanaka」でログオンした場合)

一般社員「ayamada」のアカウントでFramework Managerにログオンした場合、クエリーは「山田 明美」がアクセス許可されたレコードのみを返します(図17)。人事部門のメンバーかつ、人事担当副社長(人事部門役員)のアカウント「dtanaka」でアクセスする場合、クエリーはアクセス許可されている「日本」の全てのレコードを返します(図18)。

従業員キーアカウント名ユーザー名Position
4032ayamada山田明美一般社員
4960dtanaka田中大地人事担当副社長
図17. Framework Manager:一般社員「ayamada」でログオンした場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果
図17. Framework Manager:一般社員「ayamada」でログオンした場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果
図17. Framework Manager:一般社員「ayamada」でログオンした場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果
図18. Framework Manager:人事担当副社長(人事部門役員)「dtanaka」でログオンした場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果
図18. Framework Manager:人事担当副社長(人事部門役員)「dtanaka」でログオンした場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果
図18. Framework Manager:人事担当副社長(人事部門役員)「dtanaka」でログオンした場合のクエリーサブジェクト「従業員 (職位/部門別)」のクエリー結果

クエリーの動作確認後、Framework Managerにて作成したモデルをCognosのポータルであるCognos Connectionにパッケージとして発行します。次章では発行されたパッケージを元にReport Authoringにてレポートを作成する方法を述べています。

4.6. Report Authoringにて、ダイナミック・レポートを作成する

ここからReport Authoringを利用したダイナミック・レポートの作成に入ります。Framework Manager上で設定したパッケージに対するセッション・パラメーターおよびパラメーター・マップを利用してダイナミックなレポートを実現させます。
実際にセッション・パラメーターやパラメーター・マップの値をレポートで表示するには、Report Authoring→「クエリー」内の「データアイテム式」として設定します。なお、パラメーターのシンタックスはFramework Managerで使用したシンタックスと同じです。Report Authoringでダイナミック・レポートを作成するには、パラメーターをデータアイテムの式やフィルターの式などで使用します。

図19. Report Authoring:セッション・パラメーターの設定をデータアイテム式で行う方法
図19. Report Authoring:セッション・パラメーターの設定をデータアイテム式で行う方法
図19. Report Authoring:セッション・パラメーターの設定をデータアイテム式で行う方法

今回のサンプル・ケースでは、職種の「職位コード」は役員の場合、2000より小さく設定されています。(図20)

図20. Framework Manager:パラメーター・マップップ「PositionCode」に設定されている「職位コード」の一覧
図20. Framework Manager:パラメーター・マップップ「PositionCode」に設定されている「職位コード」の一覧
図20. Framework Manager:パラメーター・マップップ「PositionCode」に設定されている「職位コード」の一覧

ログオンユーザーの職種を表示するには、以下のデータアイテム式で取得することが可能です。

セッション・パラメーターのログオンアカウント情報:「#sq($account.personalInfo.userName)#」
パラメーター・マップの職位コード:「#$PositionCode{$account.personalInfo.userName}#」

図21. Report Authoring:「職位コード」のパラメーター・マップを使用したデータアイテム式の設定方法
図21. Report Authoring:「職位コード」のパラメーター・マップを使用したデータアイテム式の設定方法
図21. Report Authoring:「職位コード」のパラメーター・マップを使用したデータアイテム式の設定方法

ログオンしたユーザーの職種や役割によって、表示された「データアイテム」の値を変換するには、データアイテムの式に複数条件を設定することで実現できます。
今回のサンプル・ケースでは、Framework Managerにて人事部門以外のメンバーの場合はクエリーから自分のレコードのみが返されますが、人事部門のメンバーであれば自国のすべての人事情報に関するレコードが返されるように設定しています。
但し、同じ人事部門のメンバーでも、役員以外はコンフィデンシャルの情報を見られないように、以下の「データアイテム式」を使用することで適宜「※※※※」で表示データにマスクをかけることも可能です。(下記は「給与」に「※※※※」でマスクをかける方法)

if ((#$PositionCode{$account.personalInfo.userName}# <2000)
or (#$account.parameters.employeeNumber# = [従業員概要 (クエリー)].[従業員 (職位/部門別)].[従業員キー]))
 then
('US$ ' + cast([従業員概要 (クエリー)].[従業員概要ファクト].[給与],varchar(10)))
else ('※※※※')

この方法で、役員以外のユーザーの場合、コンフィデンシャルなデータとして職位最低/最高給与および給与としてレポートに表示されるデータを 「※※※※」でマスクします(図22)。

図22. Report Authoring:役員以外の人事部門ユーザーユーザーの場合、職位最低/最高給与および給与データを 「※※※※」にマスクするデータアイテムの式の設定方法
図22. Report Authoring:役員以外の人事部門ユーザーユーザーの場合、職位最低/最高給与および給与データを 「※※※※」にマスクするデータアイテムの式の設定方法
図22. Report Authoring:役員以外の人事部門ユーザーユーザーの場合、職位最低/最高給与および給与データを 「※※※※」にマスクするデータアイテムの式の設定方法

上記のようにデータアイテムの式を設定したレポートを実行すると、ログオンしたユーザーの職種や役割によって、表示される情報をコントロールすることが可能です。

従業員キーアカウント名ユーザー名Position
4032ayamada山田 明美一般社員
4744akato加藤 愛実人事担当者
4960dtanaka田中 大地人事担当副社長

例えば、図23のように、一般社員「ayamada」のユーザーアカウントを使用してレポートを実行した場合、ユーザー本人の「山田明美」のみの情報だけが表示されています。人事担当者(人事部門メンバー)「akato」のユーザーアカウントを使用する場合、「日本」のすべてのユーザーの人事情報が表示されていますが、本人以外の職位最低/最高給与および給与のデータはコンフィデンシャルな情報として「※※※※」のようにマスクされています(図24)。人事担当副社長(人事部門役員)の「dtanaka」のユーザーアカウントを使用してレポートを実行する場合、図25のように、すべての日本のユーザーの人事情報がマスクされることなく表示されます。

図23. Cognos Viewer:一般社員「ayamada」アカウントでレポートを実行した結果
図23. Cognos Viewer:一般社員「ayamada」アカウントでレポートを実行した結果
図23. Cognos Viewer:一般社員「ayamada」アカウントでレポートを実行した結果
図24. Cognos Viewer:人事担当者(人事部門メンバー)「akato」アカウントでレポートを実行した結果
図24. Cognos Viewer:人事担当者(人事部門メンバー)「akato」アカウントでレポートを実行した結果
図24. Cognos Viewer:人事担当者(人事部門メンバー)「akato」アカウントでレポートを実行した結果
図25. Cognos Viewer:人事担当副社長(人事部門役員)「dtanaka」アカウントでレポートを実行した結
図25. Cognos Viewer:人事担当副社長(人事部門役員)「dtanaka」アカウントでレポートを実行した結
図25. Cognos Viewer:人事担当副社長(人事部門役員)「dtanaka」アカウントでレポートを実行した結

5. 注意事項

本稿記載の際にはサンプル・ケースを利用しているため、比較的少ないデータ量でテストを行っております。フィルターの設定方法によってはレポート表示の際にパフォーマンスが悪化する可能性もあります。

6. 終わりに

異なるユーザーの職種や役割に合わせて表示する情報をコントロールするロール・ベース・セキュリティーの実装方法をご紹介しました。OpenLDAPは外部ネームスペースとして設定されると、その中に登録されているユーザーアカウントおよびグループはネームスペース「Cognos」のグループや役割に登録されます。これを利用して、パッケージやレポートなどの各オブジェクトのセキュリティー権限の設定しました。
Framework Managerにてセッション・パラメーターやパラメーター・マップを設定し、そのパラメーターをクエリーに対するフィルターとして利用することでデータへのアクセスを制限する設定を行いました。
その他、Report Studioで該当のセッション・パラメーターやパラメーター・マップを利用して表示するデータをコントロールするダイナミック・レポートを作成しました。
これにより、OpenLDAPに登録されたユーザー情報に基づいて、ログオンしたユーザーの職種や役割により、企業情報へのアクセス・コントロールが実現され、同時に、パッケージへのアクセス権限、クエリーのフィルター条件やレポートに表示された情報もコントロールできます。 ツールの共有化やセキュリティーの概念の踏襲といった「全社的なコンセプトの共有」と「データ・インテグリティー」、レポート書式の単一化による「メンテナンスの簡便化」が図られます。

なお、Cognos10.1においても本稿の内容は有効です。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=549393
ArticleTitle=ロール・ベース・セキュリティーを使用したダイナミックレポーティングの概念に関して
publish-date=10142010