環境内のアプリケーションへのアクセスを管理するための組織のポリシーを定義する

Microsoft Entra ID を使用してアクセスを管理する 1 つ以上のアプリケーションを特定したら、アクセス権を持つ必要があるユーザーを決定するための組織のポリシーと、システムが提供する必要があるその他の制約を書き留めます。

スコープ内のアプリケーションとそのロールを選択する

コンプライアンス要件またはリスク管理計画がある組織には、機密性の高いアプリケーションまたはビジネス クリティカルなアプリケーションがあります。 このアプリケーションが環境内の既存のアプリケーションである場合は、このアプリケーションにアクセスする必要があるユーザーのアクセス ポリシーを既に文書化している可能性があります。 そうでない場合は、コンプライアンス チームやリスク管理チームなど、さまざまな利害関係者と相談して、アクセスの決定を自動化するために使用されているポリシーがシナリオに適していることを確認する必要があります。

1. 各アプリケーションが提供するロールとアクセス許可を収集します。 ロール "User" のみを使用するアプリケーションなど、一部のアプリケーションでは、1 つのロールしかない場合があります。 より複雑なアプリケーションでは、Microsoft Entra ID を通じて管理される複数のロールが表示される場合があります。 通常、これらのアプリケーションのロールは、そのロールを持つユーザーがアプリ内で持つアクセス権に広範な制約を適用します。 たとえば、管理者ペルソナを使用するアプリケーションには、"User" と "Administrator" という 2 つのロールがある場合があります。 他のアプリケーションもまた、きめ細かなロールの確認のためにグループ メンバーシップまたは要求に依存する可能性があります。これは、フェデレーション SSO プロトコルを使用して発行されたか、またはセキュリティ グループ メンバーシップとして AD に書き込まれたプロビジョニングまたは要求で Microsoft Entra ID からアプリケーションに提供できます。 最後に、Microsoft Entra ID に表示されないアプリケーション固有のロールが存在する可能性があります。もしかすると、Microsoft Entra ID での管理者の定義を許可せず、代わりに独自の承認規則を利用して管理者を識別するアプリケーションかもしれません。 SAP Cloud Identity Services で割り当てに使用できるロールは、1 つ (ユーザー) のみです。

   Note

   プロビジョニングをサポートする Microsoft Entra ID アプリケーション ギャラリーのアプリケーションを使用している場合、プロビジョニングが構成された後に、Microsoft Entra ID によって定義されたロールがアプリケーションにインポートされ、アプリケーションのロールを使用してアプリケーション マニフェストが自動的に更新される場合があります。

2. Microsoft Entra ID で管理されるメンバーシップを持つロールとグループを選びます。 多くの場合、コンプライアンスとリスク管理の要件に基づいて、組織は、機密情報への特権アクセスまたはアクセスを許可するアプリケーション ロールまたはグループに優先順位を付けます。

アプリケーションへのアクセスに関する前提条件とその他の制約を使用して組織のポリシーを定義する

このセクションでは、アプリケーションへのアクセスを決定するために使用する予定の組織ポリシーを記述します。 たとえば次のように、これを表としてスプレッドシートに記録できます

既に組織のロールの定義がある場合は、組織のロールを移行する方法に関するページを参照してください。

1. アプリケーションへのアクセス権を付与される前に、ユーザーが満たす必要がある前提条件、標準があるかどうかを特定します。 たとえば、通常の状況では、フルタイムの従業員、または特定の部門またはコスト センターの従業員のみが、特定の部門のアプリケーションへのアクセスを許可される必要があります。 また、1 人以上の追加承認者が必要なアクセス権を要求する他の部署のユーザー用にエンタイトルメント管理ポリシーが必要になる場合もあります。 承認の段階が複数あると、ユーザーがアクセス権を取得するプロセス全体が遅くなる可能性がある一方で、これらの追加の段階により、アクセス要求の適切さが確認され、決定に責任を負うことができるようになります。 たとえば、従業員によるアクセス要求には、2 段階の承認が必要な場合があります。1 番目は要求元のユーザーのマネージャー、2 番目はアプリケーションに保持されているデータを管理しているいずれかのリソース所有者によるものです。

2. アクセスが承認されたユーザーが、アクセス権を持つ期間と、そのアクセス権が取り消されるタイミングを決定します。 多くのアプリケーションでは、組織に所属しなくなるまで、ユーザーは無期限にアクセスを保持します。 状況によっては、アクセスが特定のプロジェクトまたはマイルストーンに関連付けられていて、プロジェクトが終了すると、アクセス権が自動的に削除されることがあります。 または、ポリシーを介してアプリケーションを使用しているユーザーが少ない場合は、そのポリシーを介したすべてのユーザーのアクセスを四半期ごとまたは年ごとにレビューするように構成し、定期的に監視されるようにすることができます。

3. 組織が既に組織のロール モデルを使ってアクセスを管理している場合は、その組織のロール モデルを Microsoft Entra ID に導入することを計画してください。 ユーザーのプロパティ (役職や部署など) に基づいてアクセス権を割り当てる 組織ロール が定義されている場合があります。 これらのプロセスにより、事前に決定されたプロジェクトの終了日がない場合でも、アクセスが不要になったときに最終的にユーザーがアクセス権を失うようにすることができます。

4. 職務の分離の制約があるかどうかを調べてください。 たとえば、Western Sales と Eastern Sales という 2 つのアプリ ロールを持つアプリケーションがあるとして、ユーザーが一度に 1 つの販売区域しか担当できないようにしたい場合があります。 アプリケーションに互換性のないアプリ ロールのペアの一覧を含めて、ユーザーが 1 つのロールを持っている場合、2 つ目のロールを要求できないようにします。

5. アプリケーションにアクセスするための適切な条件付きアクセス ポリシーを選択します。 アプリケーションを分析し、同じユーザーに対して同じリソース要件があるアプリケーションにそれらをグループ化することをお勧めします。 これが ID ガバナンスのために Microsoft Entra ID ガバナンスと統合する最初のフェデレーション SSO アプリケーションである場合は、多要素認証 (MFA) や場所ベースのアクセスの要件など、制約を示すための新しい条件付きアクセス ポリシーを作成することが必要になることがあります。 使用条件に同意する必要があるユーザーを構成できます。 条件付きアクセス ポリシーを定義する方法に関する考慮事項については、条件付きアクセスのデプロイの計画に関するページを参照してください。

6. 条件の例外を処理する方法を決定します。 たとえば、通常、アプリケーションは指定された従業員のみが利用できますが、監査人またはベンダーが特定のプロジェクトに一時的にアクセスする必要がある場合があります。 または、出張中の従業員が、組織がその場所に存在しないために通常はブロックされている場所からのアクセスを必要とする場合があります。 このような状況では、異なる段階、異なる制限期間、または異なる承認者がいる承認のためのエンタイトルメント管理ポリシーを選択することもできます。 Microsoft Entra テナントにゲスト ユーザーとしてサインインしているベンダーにはマネージャーがいない場合があるため、代わりに、組織のスポンサー、リソース所有者、またはセキュリティ責任者によってアクセス要求が承認される可能性があります。

アクセス権を持つ必要があるユーザーの組織ポリシーが利害関係者によってレビューされているため、Microsoft Entra ID のアプリケーションと統合を開始できます。 このようにして、後の手順で、Microsoft Entra ID ガバナンスにおいてアクセスのために組織が承認したポリシーをデプロイする準備が整います。

次のステップ

• アプリケーションと Microsoft Entra ID の統合
• カバナンス ポリシーをデプロイする