次の方法で共有

Microsoft BHOLD Suite 概念ガイド

  • [アーティクル]

Microsoft Identity Manager 2016 (MIM) を使うことにより、ユーザー ID とそれに関連付けられている資格情報のライフサイクル全体を管理できます。 ID を同期し、証明書とパスワードを一元的に管理し、異種システムにユーザーをプロビジョニングするように構成できます。 IT 組織は、MIM を使うことで、ID の作成から使用停止までの管理に使うプロセスを定義して自動化できます。

Microsoft BHOLD Suite は、ロールベースのアクセス制御を追加することで、MIM のこれらの機能を拡張します。 BHOLD を使うと、ユーザー ロールを定義し、機密データやアプリケーションへのアクセスを制御できます。 これらのロールに基づいて適切なアクセスが許可されます。 BHOLD Suite に含まれるサービスとツールを使うと、組織内のロール間の関係を簡単にモデル化できます。 BHOLD は、ロールを権限にマップし、ロールの定義および関連付けられている権限がユーザーに正しく適用されることを検証します。 これらの機能は MIM と完全に統合されており、エンド ユーザーと IT スタッフに同様のシームレスなエクスペリエンスを提供します。

このガイドは BHOLD Suite が MIM とどのように連携するかを理解するのに役立ち、次の内容で構成されます。

  • ロールベースのアクセス制御
  • 構成証明
  • レポート
  • Access Management Connector

BHOLD は、新しいデプロイには推奨されません。 Microsoft Entra ID では、BHOLD 構成証明キャンペーン機能に代わるアクセス レビューと、アクセス割り当て機能に代わるエンタイトルメント管理が提供されるようになりました。

ロールベースのアクセス制御

データとアプリケーションへのユーザー アクセスを制御する最も一般的な方法は、随意アクセス制御 (DAC) を使うものです。 最も一般的な実装では、すべての重要なオブジェクトに特定の所有者がいます。 所有者は、個々の ID またはグループ メンバーシップに基づいて、オブジェクトに対する他のユーザーのアクセスを許可または拒否できます。 実際には、DAC を使うと、通常、組織の体制を反映したもの、機能グループを表すもの (ジョブの種類やプロジェクトの割り当てなど)、より一時的な目的でリンクされたユーザーとデバイスのその場限りのコレクションで構成されるものなど、多種多様なセキュリティ グループが作成されます。 組織の拡大に伴い、これらのグループのメンバーシップの管理はますます困難になります。 たとえば、ある従業員が別のプロジェクトに移る場合は、プロジェクト資産へのアクセス制御に使われるグループを手動で更新する必要があります。 このような場合、プロジェクトのセキュリティや生産性を損なう可能性のあるミスが発生することは珍しくありません。

MIM には、グループと配布リストのメンバーシップの自動制御を提供することによってこの問題を軽減するのに役立つ機能が含まれています。 ただし、必ずしも構造化された方法で相互に関係していないグループの急増に固有の複雑さには対応していません。

このような増加を抑える方法の 1 つは、ロールベースのアクセス制御 (RBAC) を展開することです。 RBAC は DAC に代わるものではありません。 RBAC は、DAC を基にして、それにユーザーと IT リソースを分類するためのフレームワークを提供することにより構築されています。 これにより、それらの間の関係と、その分類に応じた適切なアクセス権を明示できます。 たとえば、ユーザーの役職とプロジェクトの割り当てを指定する属性をユーザーに割り当てることで、ユーザーのジョブに必要なツールと、特定のプロジェクトの作業に必要なデータへのアクセスを、ユーザーに許可することができます。 ユーザーが別のジョブとプロジェクト割り当てを担当する場合は、ユーザーの役職とプロジェクトを指定する属性を変更すると、前の役職だけに必要だったリソースへのアクセスが自動的にブロックされます。

ロールは階層的に他のロールに含めることができるので (たとえば、営業マネージャーと営業担当者のロールを、より一般的な営業のロールに含めることができます)、特定のロールに適切な権限を割り当てながら、より包括的なロールを共有する全ユーザーに対して適切な権限を提供することも簡単にできます。 たとえば、病院では、すべての医療従事者に患者の記録を見る権限を付与する一方で、患者の処方箋を入力する権限は医師 (医療ロールのサブロール) のみに付与することができます。 同様に、事務ロールに属しているユーザーには、請求業務 (事務ロールのサブロール) 以外での患者記録へのアクセスを禁止し、病院が提供したサービスについて患者に請求するために必要な患者記録の部分へのアクセスは許可することができます。

RBAC のもう 1 つの利点は、職務の分離 (SoD) を定義して適用する機能です。 これにより、同じユーザーが持ってはならないアクセス許可を付与するロールの組み合わせを定義できます。たとえば、ユーザーに支払いの開始を許可するロールと支払いの承認を許可するロールを 1 人のユーザーに割り当てられないようにすることができます。 RBAC は、ユーザーごとにポリシーを効果的な実装を評価する必要なしに、そのようなポリシーを自動的に適用する機能を提供します。

BHOLD のロール モデル オブジェクト

BHOLD Suite では、組織内のロールを指定して編成し、ユーザーをロールにマップし、適切なアクセス許可をロールにマップすることができます。 この体制はロール モデルと呼ばれ、含まれる次の 5 種類のオブジェクトを結び付けています。

  • 組織単位
  • ユーザー
  • ロール
  • アクセス許可
  • アプリケーション

組織単位

組織単位 (OrgUnit) は、BHOLD ロール モデルでユーザーを編成する主要手段です。 すべてのユーザーは、少なくとも 1 つの OrgUnit に属している必要があります (実際、ユーザーが BHOLD で最後の組織単位から削除されると、ユーザーのデータ レコードが BHOLD データベースから削除されます)。

重要

BHOLD ロール モデルの組織単位を、Active Directory Domain Services (AD DS) の組織単位と混同しないでください。 通常、BHOLD の組織単位の体制は、ネットワーク インフラストラクチャの要件ではなく、組織および業務上のポリシーに基づいています。

必ず必要なわけではありませんが、ほとんどの場合、実際の組織の階層構造を表すために、BHOLD では次のような組織単位の体制が作成されます。

サンプル組織図

このサンプルでは、ロール モデルは会社全体に対する組織単位 (社長は組織単位の一部ではないため、社長によって表されます) であるか、または BHOLD ルート組織単位 (常に存在します) をその目的に使うことができます。 副社長を頂点とする会社の部門を表す OrgUnit が、会社組織単位に配置されます。 次に、マーケティングおよび営業の部門長に対応する組織単位がマーケティングと営業の組織単位に追加され、地域の営業マネージャーを表す組織単位が東部地域営業マネージャーの組織単位に配置されます。 他のユーザーを管理しない営業担当者は、東部地域営業マネージャーの組織単位のメンバーになります。 ユーザーは任意のレベルの組織単位のメンバーになることができることに注意してください。 たとえば、マネージャーではない副社長直属の管理アシスタントは、副社長の組織単位のメンバーになります。

組織単位は、組織体制を表すだけでなく、プロジェクトや専門化などの機能条件に従って、ユーザーや他の組織単位をグループ化するために使うこともできます。 次の図では、顧客の種類に従って営業担当者をグループ化するために組織単位を使う方法を示します。

サンプル プロジェクト organization

この例では、各営業担当者は 2 つの組織単位に属しています。1 つは組織の管理体制内での担当者の位置を表し、もう 1 つは担当者の顧客ベース (小売または企業) を表します。 各組織単位には異なるロールを割り当てることができ、各ロールには組織の IT リソースにアクセスするための異なるアクセス許可を割り当てることができます。 さらに、ロールは親組織単位から継承することができ、ユーザーへのロール反映プロセスが簡単になります。 一方で、特定のロールが継承されるのを禁止して、特定のロールを適切な組織単位のみと関連付けることができます。

OrgUnits は、BHOLD Core Web ポータルを使用して BHOLD Suite で作成できます。

ユーザー

前述のように、すべてのユーザーは少なくとも 1 つの組織単位 (OrgUnit) に属していなければなりません。 組織単位はユーザーをロールと関連付ける主要なメカニズムなので、ほとんどの組織では、ロールとユーザーの関連付けを容易にするため、特定のユーザーは複数の OrgUnit に属します。 ただし、場合によっては、ユーザーが属している OrgUnit とは別に、ロールをユーザーと関連付けることが必要になることがあります。 したがって、ユーザーにロールを直接割り当てることも、ユーザーが属している OrgUnit からロールを取得することもできます。

ユーザーが組織内でアクティブでない場合は (たとえば、病気で休職中のとき)、ユーザーを一時的に停止することができ、ユーザーはロール モデルから削除されることなくすべてのアクセス許可を取り消されます。 ユーザーが復職したら再びアクティブにして、ユーザーのロールによって付与されるすべてのアクセス許可を元に戻すことができます。

ユーザーのオブジェクトは、BHOLD Core Web ポータルを介して BHOLD で個別に作成することも、FIM 同期サービスと共に Access Management Connector を使用して、Active Directory Domain Servicesや人事アプリケーションなどのソースからユーザー情報をインポートすることもできます。

FIM 同期サービスを使わずに BHOLD でユーザーを直接作成できます。 これは、運用環境またはテスト環境でロールをモデル化するときに役立ちます。 また、外部のユーザー (下請業者の従業員など) にロールを割り当てることで、従業員データベースに追加することなく IT リソースへのアクセスを許可することもできます。ただし、このようなユーザーは、BHOLD のセルフサービス機能を使うことはできません。

ロール

前に説明したように、ロールベースのアクセス制御 (RBAC) モデルでは、アクセス許可は個々のユーザーではなくロールに関連付けられます。 これにより、ユーザーごとにアクセス許可を付与または禁止するのではなく、ユーザーのロールを変更することによって、ユーザーの職務遂行に必要なアクセス許可を各ユーザーに付与できます。 つまり、アクセス許可の割り当てに IT 部門が関わる必要はなく、業務の管理の一部として行うことができます。 異なるシステムにアクセスするための複数のアクセス許可を 1 つのロールに直接またはサブロールを使って集約でき、IT 部門がユーザーのアクセス許可の管理に関与する必要性がさらに減ります。

ロールは RBAC モデル自体の機能であることに注意してください。通常、対象アプリケーションにロールをプロビジョニングすることはありません。 これにより、ロールを使うように、または変化するビジネス モデルのニーズに合わせてロールの定義を変更するように設計されていない既存アプリケーションでも、アプリケーション自体を変更することなく、RBAC を使うことができます。 対象アプリケーションがロールを使うように設計されている場合は、アプリケーション固有のロールをアクセス許可として扱うことにより、BHOLD ロール モデルのロールを、アプリケーションの対応するロールに関連付けることができます。

BHOLD では、主に 2 つの方法でユーザーにロールを割り当てることができます。

  • ユーザーがメンバーである組織単位にロールを割り当てます
  • ユーザーにロールを直接割り当てます

必要に応じて、親組織単位に割り当てられているロールを、そのメンバーの組織単位によって継承できます。 ロールを組織単位に割り当てるとき、または継承するときに、ロールを有効ロールまたは提案ロールとして指定できます。 有効ロールの場合は、組織単位内のすべてのユーザーにそのロールが割り当てられます。 提案ロールの場合は、ユーザーまたは組織単位のメンバーに対してロールを有効にするには、ユーザーまたは組織単位メンバーごとにロールをアクティブ化する必要があります。 このようにすると、組織単位のすべてのロールをすべてのメンバーに自動的に割り当てるのではなく、組織単位に関連付けられているロールのサブセットをユーザーに割り当てることができます。 さらに、ロールには開始日と終了日を設定でき、組織単位内でロールを有効にできるユーザーの割合に制限を設けることができます。

次の図は、個々のユーザーに BHOLD のロールを割り当てる方法を示したものです。

ロールの割り当て

この図では、ロール A は継承可能なロールとして組織単位に割り当てられているので、その組織単位内のメンバー組織単位とすべてのユーザーによって継承されます。 ロール B は、提案ロールとして組織単位に割り当てられています。 組織単位内のユーザーにロールのアクセス許可を承認するには、先にロールをアクティブ化する必要があります。 ロール C は有効ロールなので、組織単位内のすべてのユーザーにそのアクセス許可が直ちに適用されます。 ロール D はユーザーに直接リンクされているので、そのアクセス許可はそのユーザーにすぐに適用されます。

さらに、ユーザーの属性に基づいて、ロールをユーザーに対してアクティブにすることができます。 詳しくは、後の属性ベースの承認に関する説明をご覧ください。

アクセス許可

BHOLD のアクセス許可は、対象アプリケーションからインポートされる承認に対応します。 つまり、アプリケーションで動作するように BHOLD を構成すると、BHOLD はロールにリンクできる承認の一覧を受け取ります。 たとえば、Active Directory Domain Services (AD DS) をアプリケーションとして BHOLD に追加すると、BHOLD はロールにリンクできるセキュリティ グループのリストを BHOLD のアクセス許可として受け取ります。

アクセス許可はアプリケーションに固有です。 BHOLD は単一の統合されたアクセス許可のビューを提供するので、アクセス許可をロールと関連付けるために、ロール マネージャーがアクセス許可の実装の詳細を理解する必要はありません。 実際には、アクセス許可の適用方法はシステムによって異なる場合があります。 FIM 同期サービスからアプリケーションに対するアプリケーション固有のコネクタにより、ユーザーのアクセス許可の変更がそのアプリケーションに提供される方法が決まります。

アプリケーション

BHOLD は、外部アプリケーションにロールベースのアクセス制御 (RBAC) を適用するための方法を実装しています。 つまり、アプリケーションからのユーザーとアクセス許可で BHOLD をプロビジョニングすると、BHOLD は、ロールをユーザーに割り当て、アクセス許可をロールにリンクすることにより、アクセス許可とユーザーを関連付けることができます。 その後、アプリケーションのバックグラウンド プロセスは、BHOLD でのロール/アクセス許可のマッピングに基づいて、適切なアクセス許可をそのユーザーにマップできます。

BHOLD Suite のロール モデルの作成

ロール モデルの作成を助けるため、BHOLD Suite には、使いやすくて包括的なツールである Model Generator が用意されています。

Model Generator を使う前に、Model Generator がロール モデルの作成に使うオブジェクトを定義する一連のファイルを作成する必要があります。 これらのファイルを作成する方法については、Microsoft BHOLD Suite のテクニカル リファレンスをご覧ください。

BHOLD Model Generator を使うときは最初に、これらのファイルをインポートして基本的な構成要素を Model Generator に読み込みます。 ファイルが正常に読み込まれた後は、ロールのクラスの作成に Model Generator が使う条件を指定できます。

  • ユーザーが属する OrgUnit (組織単位) に基づいてユーザーに割り当てられるメンバーシップ ロール
  • BHOLD データベース内のユーザーの属性に基づいてユーザーに割り当てられる属性ロール
  • 組織単位にリンクされているが特定のユーザーに対してアクティブ化する必要がある提案ロール
  • インポートされたファイルで所有者が指定されていない組織単位とロールに対する制御をユーザーに付与する所有権ロール

重要

ファイルをアップロードするとき、[Retain Existing Model]\(既存のモデルを維持する\) チェック ボックスはテスト環境でのみオンにしてください。 運用環境では、Model Generator を使って初期ロール モデルを作成する必要があります。 Model Generator を使って BHOLD データベース内の既存のロール モデルを変更することはできません。

Model Generator がロール モデルのロールを作成した後は、ロール モデルを XML ファイルの形式で BHOLD データベースにエクスポートできます。

BHOLD の高度な機能

前のセクションでは、BHOLD でのロールベースのアクセス制御 (RBAC) の基本的な機能について説明しました。 このセクションでは、組織での RBAC の実装のセキュリティと柔軟性を高める BHOLD のその他の機能の概要を説明します。 このセクションでは、BHOLD の以下の機能の概要を示します。

  • カーディナリティ
  • 職務の分離
  • コンテキスト適応性のあるアクセス許可
  • 属性ベースの承認
  • 柔軟な属性の種類

カーディナリティ

"カーディナリティ" とは、2 つのエンティティが相互に関連できる回数を制限するように設計されているビジネス ルールの実装のことです。 BHOLD の場合、カーディナリティ ルールはロール、アクセス許可、ユーザーに対して設定できます。

以下の値を制限するようにロールを構成できます。

  • 提案ロールをアクティブ化できるユーザーの最大数
  • ロールにリンクできるサブロールの最大数
  • ロールにリンクできるアクセス許可の最大数

以下の値を制限するようにアクセス許可を構成できます。

  • アクセス許可にリンクできるロールの最大数
  • アクセス許可を付与できるユーザーの最大数

以下の値を制限するようにユーザーを構成できます。

  • ユーザーにリンクできるロールの最大数
  • ロールの割り当てによってユーザーに割り当てることのできるアクセス許可の最大数

職務の分離

職務の分離 (SoD) は、1 人の人間がすべてを行うべきではない複数のアクションを実行する権限が 1 人に付与されるのを防ぐためのビジネス原則です。 たとえば、1 人の従業員が支払いの要求と支払いの承認の両方を行うべきではありません。 SoD の原則を使うことにより、従業員のエラーまたは違反行為によるリスクを最小限に抑える抑制と均衡のシステムを実装できます。

BHOLD では、両立しないアクセス許可を定義できるようにすることで SoD が実装されています。 これらのアクセス許可を定義すると、BHOLD は、両立しないアクセス許可に (直接リンクまたは継承により) リンクされているロールが作成されるのを防ぎ、組み合わされると両立しないアクセス許可を (直接リンクまたは継承により) 付与するようになる複数のロールがユーザーに割り当てられるのを防ぐことによって、SoD を適用します。 必要に応じて、競合をオーバーライドすることができます。

コンテキスト適応性のあるアクセス許可

オブジェクト属性に基づいて自動的に変更できるアクセス許可を作成すると、管理する必要があるアクセス許可の総数を減らすことができます。 コンテキスト適応性のあるアクセス許可 (CAP) を使うと、アクセス許可に関連付けられたアプリケーションによってアクセス許可が適用される方法を変更する式を、アクセス許可属性として定義できます。 たとえば、ユーザーが正社員または契約社員どちらの組織単位に属しているかに基づき、(フォルダーのアクセス制御リストに関連付けられているセキュリティ グループにより) ファイル フォルダーへのアクセス許可を変更する式を作成できます。 ユーザーが別の組織単位に移動した場合、新しいアクセス許可が自動的に適用されて、古いアクセス許可は非アクティブ化されます。

CAP の式では、アプリケーション、アクセス許可、組織単位、およびユーザーに適用されている属性の値を照会できます。

属性ベースの承認

組織単位にリンクされているロールが組織単位内の特定のユーザーに対してアクティブ化されるかどうかを制御する方法の 1 つは、属性ベースの承認 (ABA) を使うことです。 ABA を使うと、ユーザーの属性に基づく特定のルールが満たされているときにのみ、ロールを自動的にアクティブ化できます。 たとえば、ユーザーの役職が ABA ルールの役職と一致する場合にのみユーザーに対してアクティブになるロールを組織単位にリンクできます。 これにより、ユーザーに対する提案ロールを手動でアクティブ化する必要がなくなります。 代わりに、ロールの ABA ルールを満たす属性値を持つ組織単位内のすべてのユーザーについてロールをアクティブにできます。 ルールを組み合わせて、ユーザーの属性がロールに対して指定されているすべての ABA ルールを満たす場合にのみ、ロールがアクティブ化されるようにすることができます。

ABA ルール テストの結果はカーディナリティの設定によって制限されることに注意することが重要です。 たとえば、ルールのカーディナリティ設定で、あるロールに割り当てることができるユーザーは 2 人までと指定されている場合、ABA ルールで 4 人のユーザーにロールがアクティブになると、ABA テストに合格した最初の 2 人のユーザーに対してのみ、ロールがアクティブ化されます。

柔軟な属性の種類

BHOLD の属性システムは、高い拡張性を備えています。 ユーザー、組織単位、ロールなどのオブジェクトに新しい属性の種類を定義できます。 属性には、整数、ブール値 (はい/いいえ)、英数字、日付、時刻、メール アドレスなどの値を定義できます。 属性は、単一の値または値のリストとして指定できます。

構成証明

BHOLD Suite のツールを使って、個々のユーザーがビジネス タスクを遂行するための適切なアクセス許可を付与されていることを確認できます。 管理者は、BHOLD 構成証明モジュールによって提供されるポータルを使用して、構成証明プロセスを設計および管理できます。

構成証明プロセスはキャンペーンによって実施され、キャンペーンのスチュワードは担当するユーザーが BHOLD で管理されたアプリケーションへの適切なアクセス権とアプリケーション内での正しいアクセス許可を持っていることを確認する機会と手段を提供されます。 キャンペーンを監視し、キャンペーンが正しく実施されていることを確認する、キャンペーンの所有者が指定されます。 キャンペーンは、1 回だけまたは定期的に行われるように作成できます。

通常、キャンペーンのスチュワードはマネージャーであり、自分の組織単位に属しているユーザーのアクセス権の構成証明を行います。 スチュワードは、ユーザー属性に基づいてキャンペーンの構成証明対象ユーザーに対して自動的に選択することも、キャンペーンの構成証明対象ユーザーをスチュワードにマップするファイルに列記することで定義することもできます。

キャンペーンが開始されると、BHOLD はキャンペーン スチュワードと所有者にメール通知メッセージを送信した後、キャンペーンの進行状況を確認できる通知を定期的に送信します。 スチュワードは、表示されるキャンペーン ポータルで、担当するユーザーとそれらのユーザーに割り当てられているロールの一覧を見ることができます。 スチュワードは、一覧の各ユーザーを担当しているかどうかを確認し、アクセス権を承認または拒否できます。

キャンペーンの所有者もポータルを使ってキャンペーンの進行状況を監視でき、キャンペーンの過程で実行されたアクションをキャンペーン所有者が分析できるようにキャンペーンのアクティビティがログに記録されます。

レポート

BHOLD Reporting モジュールを使うと、さまざまなレポートでロール モデルの情報を表示できます。 BHOLD Reporting モジュールには、広範な組み込みレポートのセットと、基本レポートおよび高度なカスタム レポートの作成に使うことができるウィザードが含まれています。 レポートを実行するときは、すぐに結果を表示したり、Microsoft Excel (.xlsx) ファイルに結果を保存したりできます。 Microsoft Excel 2000、Microsoft Excel 2002、または Microsoft Excel 2003 を使ってこのファイルを表示するには、Word、Excel、および PowerPoint ファイル形式用の Microsoft Office 互換機能パックをダウンロードしてインストールできます。

BHOLD Reporting モジュールは、主に、現在のロール情報に基づくレポートを作成するために使います。 ID 情報の変更を監査するためのレポートを生成するには、Forefront Identity Manager 2010 R2 に、System Center Service Manager Data Warehouse に実装されている FIM Service 用のレポート機能があります。 FIM のレポートについて詳しくは、Forefront Identity Management のテクニカル ライブラリで Forefront Identity Manager 2010 および Forefront Identity Manager 2010 R2 のドキュメントをご覧ください。

組み込みレポートでは次のカテゴリの情報が表示されます。

  • 管理
  • 構成証明
  • コントロール
  • 内向きのアクセスの制御
  • ログの記録
  • モデル
  • 統計
  • ワークフロー

レポートを作成してこれらのカテゴリに追加したり、独自のカテゴリを定義してカスタム レポートや組み込みレポートを配置したりすることができます。

レポートを作成するときは、ウィザードに従って次のパラメーターを指定します。

  • 名前、説明、カテゴリ、用途、対象ユーザーなどの識別情報
  • レポートに表示するフィールド
  • 分析対象の項目を指定するクエリ
  • 行の並べ替え順序
  • レポートをセクションに分割するために使うフィールド
  • レポートで返される要素を絞り込むためのフィルター

ウィザードの各ステージでは、それまでに定義したレポートをプレビューでき、パラメーターを追加指定する必要がない場合は保存できます。 また、前の手順に戻り、指定したパラメーターを変更することもできます。

Access Management Connector

BHOLD Suite の Access Management Connector モジュールは、BHOLD へのデータの初期同期と実行中同期の両方をサポートします。 Access Management Connector は FIM 同期サービスと連携して、BHOLD Core データベース、MIM メタバース、ターゲット アプリケーションと ID ストアの間でデータを移動します。

以前のバージョンの BHOLD では、MIM と中間 BHOLD データベース テーブルの間のデータ フローを制御するために複数の MA が必要でした。 BHOLD Suite SP1 の Access Management Connector では、BHOLD と MIM の間でデータを直接転送する管理エージェント (MA) を MIM で定義できます。

次のステップ