Microsoft BHOLD Suite の概念ガイド

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

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

このガイドは、BHOLD Suite と MIM の連携方法を理解するのに役立ち、次のトピックについて説明します。

• ロールベースのアクセス制御
• 証明書
• レポーティング
• アクセス管理コネクター

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

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

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

MIM には、グループと配布リストのメンバーシップを自動的に制御することで、この問題を軽減するのに役立つ機能が含まれています。 しかし、これは、必ずしも構造化された方法で相互に関連しているとは限らない増殖するグループの本質的な複雑さに対処するものではありません。

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

ロールは階層的な方法でロール内に含めることができるため (たとえば、営業マネージャーと営業担当者のロールは、より一般的な営業ロールに含めることができます)、特定のロールに適切な権限を割り当てることは簡単ですが、より包括的なロールを共有するすべてのユーザーにも適切な権限を与えることができます。 たとえば、病院では、すべての医療担当者に患者の記録を表示する権限を付与できますが、医師 (医療の役割のサブロール) にのみ、患者の処方箋を入力する権利を与えることができました。 同様に、事務的な役割に属するユーザーは、課金係 (事務的役割のサブロール) を除き、患者レコードへのアクセスを拒否される可能性があります。このユーザーは、病院が提供するサービスに対して患者に請求するために必要な患者レコードのそれらの部分へのアクセスを許可できます。

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

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

BHOLD Suite を使用すると、組織内のロールを指定して整理したり、ユーザーをロールにマップしたり、適切なアクセス許可をロールにマップしたりできます。 この構造はロール モデルと呼ばれ、次の 5 種類のオブジェクトが含まれており、接続されます。

• 組織単位
• ユーザー
• 役割
• 権限
• アプリケーション

組織単位

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

必須ではありませんが、ほとんどの場合、組織単位は BHOLD で構成され、次のような実際の組織の階層構造を表します。

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

組織構造を表すだけでなく、組織単位を使用して、プロジェクトや特殊化などの機能基準に従ってユーザーや他の組織単位をグループ化することもできます。 次の図は、組織単位を使用して、顧客の種類に応じて販売員をグループ化する方法を示しています。

この例では、各販売員は 2 つの組織単位に属します。1 つは組織の管理構造におけるアソシエイトの位置を表し、もう 1 つはアソシエイトの顧客ベース (小売または企業) を表します。 組織単位ごとに異なるロールを割り当てることができ、組織の IT リソースにアクセスするための異なるアクセス許可を割り当てることができます。 さらに、ロールを親組織単位から継承できるため、ロールをユーザーに伝達するプロセスが簡略化されます。 一方、特定のロールが継承されないようにして、特定のロールが適切な組織単位にのみ関連付けられるようにすることができます。

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

ユーザー

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

組織内でユーザーがアクティブでない場合（例えば、医療休暇中）、ユーザーのアクセスを一時停止できます。これにより、そのユーザーのすべてのアクセス権が、役割モデルからユーザーを削除せずに取り消されます。 職務に戻ると、ユーザーを再アクティブ化し、ユーザーのロールによって付与されたすべてのアクセス許可が復元されます。

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

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

役割

前述のように、ロールベースのアクセス制御 (RBAC) モデルでは、アクセス許可は個々のユーザーではなくロールに関連付けられます。 これにより、ユーザーのアクセス許可を個別に付与または拒否するのではなく、ユーザーのロールを変更することで、ユーザーの職務を実行するために必要なアクセス許可を各ユーザーに付与できます。 その結果、アクセス許可の割り当てには IT 部門の参加は不要になり、代わりにビジネスの管理の一環として実行できます。 ロールは、直接、またはサブロールを使用して、異なるシステムにアクセスするためのアクセス許可を集約できるため、ユーザーのアクセス許可の管理に 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 が用意されています。

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

BHOLD モデル ジェネレーターを使用する最初の手順では、これらのファイルをインポートして、基本的な構成要素をモデル ジェネレーターに読み込みます。 ファイルが正常に読み込まれたら、モデル ジェネレーターがロールのいくつかのクラスを作成するために使用する条件を指定できます。

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

モデル ジェネレーターがロール モデルでこれらのロールを作成した後、ロール モデルを XML ファイルの形式で BHOLD データベースにエクスポートできます。

高度な BHOLD 機能

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

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

カーディナリティ

カーディナリティ とは、2 つのエンティティが相互に関連付けられる回数を制限するように設計されたビジネス ルールの実装を指します。 BHOLD の場合、ロール、アクセス許可、およびユーザーのカーディナリティ ルールを確立できます。

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

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

以下を制限するアクセス許可を構成できます。

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

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

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

職務の分離

職務の分離 (SoD) は、個人が 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 回または定期的に作成できます。

通常、キャンペーンのスチュワードは、マネージャーが担当する 1 つ以上の組織単位に属するユーザーのアクセス権を証明するマネージャーになります。 スチュワードは、ユーザー属性に基づいてキャンペーンで構成証明されるユーザーに対して自動的に選択できます。または、キャンペーンのスチュワードを定義するには、キャンペーンで構成証明されているすべてのユーザーをスチュワードにマップするファイルにリストすることができます。

キャンペーンが開始されると、BHOLD はキャンペーンのスチュワードと所有者に電子メール通知メッセージを送信し、キャンペーンの進行状況を維持するために定期的なリマインダーを送信します。 スチュワードは、担当するユーザーの一覧と、それらのユーザーに割り当てられているロールを表示できるキャンペーン ポータルに誘導されます。 その後、スチュワードは、リストされている各ユーザーに対して自分が責任を負うかどうかを確認し、一覧表示されている各ユーザーのアクセス権を承認または拒否できます。

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

レポーティング

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

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

組み込みレポートの対象となるカテゴリは次のとおりです。

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

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

レポートを作成すると、ウィザードで次のパラメーターを指定する手順が実行されます。

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

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

アクセス管理コネクタ

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 の間で直接データ転送を提供する MIM の管理エージェント (MA) を定義できます。

次のステップ

• BHOLD インストール ガイド
• BHOLD 開発者向けリファレンス
• BHOLD バージョン履歴