次の方法で共有


フェーズ 1: 大規模に管理するフレームワークを実装する

Microsoft Entra Permissions Management 操作参照ガイドのこのセクションでは、効果的にアクセス許可を委任し、大規模に管理するために考慮する必要があるチェックとアクションについて説明します。

委任された管理モデルを定義する

推奨される所有者: 情報セキュリティ アーキテクチャ

Microsoft Entra Permissions Management 管理者を定義する

Microsoft Entra Permissions Management の運用を開始するには、製品のアクセス許可を委任し、キー設定を構成し、組織の構成を作成および管理する 2 人から 5 人のアクセス許可管理管理者を選任します。

重要

Microsoft Entra Permissions Management は、有効なメール アドレスを持つユーザーに依存しています。 Permissions Management の管理者は、メールボックスが有効なアカウントを持っていることをお勧めします。

必要なタスクを実行するには、指定された管理者に Microsoft Entra ID の Permissions Management の管理者ロールを割り当てます。 Privileged Identity Management (PIM) を使用して、ロールを恒久的に割り当てるのではなく、管理者に Just-In-Time (JIT) アクセスを提供することをお勧めします。

フォルダー構造の定義と管理

Permissions Management では、フォルダーは認可システムのグループです。 組織の委任戦略に基づいてフォルダーを作成することをお勧めします。 たとえば、組織がチームに基づいて委任する場合は、次のフォルダーを作成します。

  • 運用財務
  • 運用インフラストラクチャ
  • 生産前研究開発

効果的なフォルダー構造により、大規模なアクセス許可を簡単に委任でき、認可システムの所有者に肯定的な製品エクスペリエンスが提供されます。

環境を効率化するには、「認可システムを整理するためのフォルダー作成」を参照してください。

Microsoft Entra セキュリティ グループを作成してアクセス許可を委任する

Microsoft Entra Permissions Management には、Microsoft Entra ID セキュリティ グループを使用してさまざまな認可システムにアクセス許可を付与するグループベースのアクセス システムがあります。 アクセス許可を委任するために、IAM チームは、認可システムの所有者にマッピングし、定義した Permissions Management の責任に対応する Microsoft Entra セキュリティ グループを作成します。 製品の所有権と責任を共有するユーザーが同じセキュリティ グループ内にあることを確認します。

グループの PIM を使用することをお勧めします。 これにより、ユーザーには Permissions Management への JIT アクセスが提供され、ゼロ トラスト JIT と Just-enough-access の原則に準拠します。

Microsoft Entra セキュリティ グループの作成については、「グループとグループ メンバーシップの管理」を参照してください。

Microsoft Entra Permissions Management でアクセス許可を割り当てる

Microsoft Entra セキュリティ グループが作成されると、Permissions Management の管理者がセキュリティ グループに必要なアクセス許可を付与します。

少なくとも、セキュリティ グループに、担当する認可システムに対するビューアー アクセス許可が付与されていることを確認してください。 修復アクションを実行するメンバーが所属するセキュリティ グループには、コントローラー アクセス許可を使用します。 Microsoft Entra Permissions Management ロールとアクセス許可レベルの詳細情報

Permissions Management でのユーザーとグループの管理の詳細については、次を参照してください。

認可システムのライフサイクル管理を決定する

推奨される所有者: 情報セキュリティ アーキテクチャとクラウド インフラストラクチャ

新しい認可システムが作成され、現在の認可システムが進化するにつれて、Microsoft Entra Permissions Management の変更に対して明確に定義されたプロセスを作成して管理します。 次の表は、タスクと推奨される所有者の概要を示しています。

タスク 推奨される所有者
環境で作成された新しい認可システムの検出プロセスを定義する 情報セキュリティアーキテクチャ
新しい認可システムのトリアージとオンボーディング プロセスを Permissions Management に定義する 情報セキュリティアーキテクチャ
新しい認可システムの管理プロセスを定義する: アクセス許可の委任とフォルダー構造の更新 情報セキュリティアーキテクチャ
クロスチャージ構造を開発します。 コスト管理プロセスを決定します。 所有者は組織によって異なります

アクセス許可クリープ インデックス戦略を定義する

推奨される所有者: 情報セキュリティ アーキテクチャ

アクセス許可クリープ インデックス (PCI) によって情報セキュリティ アーキテクチャのアクティビティとレポートがどのように駆動されるかについて、目標とユース ケースを定義することをお勧めします。 このチームは、組織のターゲット PCI しきい値を定義し、他の人々がその達成するのを支援することができます。

ターゲット PCI しきい値を確立する

PCI しきい値は、運用動作をガイドし、環境内でアクションが必要なタイミングを決定するためのポリシーとして機能します。 次の PCI しきい値を確立します。

  • 認可システム
  • 人間の ID ユーザー
    • エンタープライズ ディレクトリ (ED)
    • SAML
    • ローカル
    • ゲスト
  • 非人間の ID

Note

非人間の ID のアクティビティは人間の ID よりも変化が少ないため、非人間の ID にはより厳密な適正サイズ設定を適用します: より低い PCI しきい値を設定します。

PCI のしきい値は、組織の目標とユース ケースによって異なります。 組み込みの Permissions Management リスクのしきい値に合わせることをお勧めします。 リスク別に、次の PCI 範囲を参照してください。

  • : 0 から 33
  • : 34 から 67
  • : 68 から 100

前述の一覧を使用して、次の PCI しきい値ポリシーの例を確認します。

カテゴリ PCI しきい値 ポリシー
認可システム 67: 認可システムを高リスクとして分類する 認可システムの PCI スコアが 67 を超える場合は、認可システムの PCI スコアの高い ID を確認して適切なサイズにします
人間の ID: ED、SAML、ローカル 67: 人間の ID を高リスクとして分類する 人間の ID の PCI スコアが 67 を超える場合は、ID のアクセス許可を適切なサイズに設定します
人間の ID: ゲスト ユーザー 33: ゲスト ユーザーを高リスクまたは中リスクとして分類する ゲスト ユーザーの PCI スコアが 33 を超える場合は、ID のアクセス許可を適切なサイズに設定します
非人間の ID 33: 非人間の ID を高リスクまたは中リスクとして分類する 非人間の ID の PCI スコアが 33 を超える場合は、ID のアクセス許可を適切なサイズに設定します

次のステップ