リカバリ性のベスト プラクティス
テナントには、意図しない削除や構成の誤りが生じます。 こうした意図しないイベントの影響を最小限に抑えるためには、その発生に備える必要があります。
リカバリ性とは、意図しない変更が生じたサービスを元の正常な状態に戻すことのできる準備のプロセスと機能のことです。 意図しない変更には、Microsoft Entra テナント内のアプリケーション、グループ、ユーザー、ポリシー、その他のオブジェクトの論理削除、物理削除、または構成の誤りなどがあります。
リカバリ性には、組織の回復性を高める効果があります。 回復性は関連しているものの、異なるものです。 回復性とは、システム コンポーネントの中断に耐え、ビジネス、ユーザー、顧客、および運用への影響を最小限にして復旧する能力です。 システムの回復性を高める方法の詳細については、「Microsoft Entra ID を使って ID およびアクセス管理の回復性を強化する」を参照してください。
この記事では、削除と構成の誤りに備えて、企業のビジネスに対する意図しない結果を最小限に抑えるためのベスト プラクティスについて説明します。
削除と構成の誤り
削除と構成の誤りは、テナントにさまざまな影響を及ぼします。
削除
削除の影響は、オブジェクトの種類によって異なります。
ユーザー、Microsoft 365 グループ、アプリケーションは論理的な削除ができます。 論理的に削除された項目は、Microsoft Entra ID のごみ箱に送信されます。 ごみ箱に入っている間、アイテムは使用できません。 ただし、そのプロパティはすべて保持されているため、Microsoft Graph API の呼び出しによって、または Azure portal で復元できます。 論理的な削除状態のアイテムのうち、30 日以内に復元されなかったアイテムは、完全に、つまり物理的に削除されます。
重要
その他の種類のオブジェクトはすべて、削除が選択されるとすぐ物理的に削除されます。 物理的に削除されたオブジェクトを復旧させることはできません。 作成し直して再構成する必要があります。
削除とその復元方法の詳細については、「削除からの回復」を参照してください。
構成の不備
構成の誤りとは、組織のポリシーや計画から逸脱し、意図しない結果や望ましくない結果を引き起こすリソースまたはポリシーの構成のことです。 テナント全体の設定や条件付きアクセス ポリシーの構成の誤りによって、セキュリティと、組織のパブリック イメージに重大な影響を与える可能性があります。 構成の誤りにより、次の可能性があります。
- 管理者、テナント ユーザー、外部ユーザーによるテナント内のリソースの操作方法が変更される。
- ユーザーが他のテナントと対話する、および外部ユーザーがテナントと対話する機能が変更される。
- サービス拒否を引き起こす。
- データ、システム、アプリケーション間の依存関係が解除される。
構成の誤りとそこから回復させる方法について詳しくは、構成の誤りからの回復に関する記事を参照してください。
Shared responsibility
回復性は、クラウド サービス プロバイダーとしての Microsoft とお客様の組織とが共同で担う責任です。
削除や構成の誤りには、Microsoft から提供されるツールとサービスを使用して備えることができます。
ビジネス継続性と障害計画
物理的に削除されたアイテムや構成に誤りのあるアイテムを復元するのは、多くのリソースを必要とするプロセスです。 事前に計画することで、必要なリソースを最小限に抑えることができます。 特別に復元を担当する管理者のチームを設置することを検討してください。
復元プロセスをテストする
オブジェクトの種類ごとの復元プロセスと、それに伴う情報伝達をリハーサルしてください。 リハーサルは、必ずテスト オブジェクトで行ってください。テスト テナント内で行うのが理想です。
計画をテストすると、次のことを判断するのに役立ちます。
- オブジェクトの状態を記述したドキュメントの有効性と完全性。
- 解決までの標準的な所要時間。
- 適切な情報伝達とその対象ユーザー。
- しかるべき成功と考えられる課題。
情報伝達プロセスを作成する
問題と復元のタイムラインを他の人々が把握できるよう、事前に定義された情報伝達のプロセスを作成します。 復元の情報伝達計画には、次の点を含めるようにします。
伝えられる情報伝達の種類。定義済みテンプレートの作成を検討してください。
情報伝達の受け手となる関係者。 適宜、次のグループを含めます。
- 影響を受ける経営者。
- 復旧作業を行う運用管理者。
- ビジネス承認者と技術承認者。
- 影響を受けるユーザー。
情報伝達のトリガーとなるイベントの定義。その例を次に示します。
- 最初の削除。
- 影響のアセスメント。
- 解決までの時間。
- 復元。
既知の良好な状態を文書化する
テナントとそのオブジェクトの状態を定期的に文書化します。 そうすれば、物理的な削除や構成の誤りが発生した場合でも、復旧のロードマップを持つことができます。 現在の状態を文書化するうえで、次のツールが役立ちます。
- Microsoft Graph API を使うと、Microsoft Entra のさまざまな構成から現在の状態をエクスポートできます。
- Microsoft Entra Exporter は、構成設定をエクスポートするために使用できるツールです。
- Microsoft 365 Desired State Configuration は、PowerShell Desired State Configuration フレームワークのモジュールの 1 つです。 これを使って構成をエクスポートすることで、以前のさまざまな設定の状態を参照したり適用したりすることができます。
- 条件付きアクセス API を使用すると、条件付きアクセス ポリシーをコードとして管理できます。
よく使用される Microsoft Graph API
Microsoft Graph API を使うと、Microsoft Entra のさまざまな構成から現在の状態をエクスポートできます。 この API は、以前の状態について参照する資料や、エクスポートしたコピーからその状態を適用する機能が、事業を継続するうえで不可欠となるほとんどのシナリオに対応します。
Microsoft Graph API は、組織のニーズに応じて細かくカスタマイズできます。 バックアップや参考資料のためのソリューションを実装するためには、データの照会、保存、表示のためのコードを開発者が設計しなければなりません。 その機能の一部として、オンライン コード リポジトリが多くの実装で使用されています。
回復に役立つ API
| リソースの種類 | リファレンスのリンク |
|---|---|
| ユーザー、グループなどのディレクトリ オブジェクト | directoryObject API user API group API application API servicePrincipal API |
| ディレクトリ ロール | directoryRole API roleManagement API |
| 条件付きアクセス ポリシー | 条件付きアクセス ポリシー API |
| デバイス | デバイス API |
| ドメイン | ドメイン API |
| 管理単位 | 管理単位 API |
| 削除済みアイテム* | deletedItems API |
*これらの構成エクスポートは、少数の管理者にのみアクセス権を与えて安全に保存してください。
必要となるドキュメントのほとんどは、Microsoft Entra Exporter から入手できます。
- 望ましい構成が導入済みであることを確認します。
- エクスポーターを使用して現在の構成を収集します。
- エクスポートを確認し、自分のテナントのエクスポートされていない設定を把握して手動で文書化します。
- アクセスが制限された安全な場所に出力を保存します。
Note
レガシ多要素認証ポータル内の、アプリケーション プロキシとフェデレーション設定に関する設定は、Microsoft Entra Exporter や Microsoft Graph API ではエクスポートされない場合があります。 Microsoft 365 Desired State Configuration モジュールは、Microsoft Graph と PowerShell を使って、Microsoft Entra ID からさまざまな構成の状態を取得します。 この情報は参考情報として使用できるほか、PowerShell Desired State Configuration スクリプトを使って既知の良好な状態を再適用する目的に使用できます。
条件付きアクセスの Graph API を使用すると、ポリシーをコードのように管理できます。 運用前環境からポリシーを昇格させるための承認や、バックアップと復元、変更の監視、緊急事態に備えた計画を自動化しましょう。
オブジェクト間の依存関係をマッピングする
一部のオブジェクトを削除すると、依存関係が原因で他に影響が波及することがあります。 たとえば、アプリケーションの割り当てに使用されるセキュリティ グループを削除すると、そこに属していたユーザーは、そのグループが割り当てられているアプリケーションにアクセスできなくなります。
共通の依存関係
| オブジェクトの種類 | 潜在的な依存関係 |
|---|---|
| アプリケーション オブジェクト | サービス プリンシパル (エンタープライズ アプリケーション)。 アプリケーションに割り当てられているグループ。 アプリケーションに影響を与える条件付きアクセス ポリシー。 |
| サービス プリンシパル | アプリケーション オブジェクト。 |
| 条件付きアクセス ポリシー | ポリシーに割り当てられたユーザー。 ポリシーに割り当てられたグループ。 ポリシーの対象となるサービス プリンシパル (エンタープライズ アプリケーション)。 |
| Microsoft 365 グループ以外のグループ | グループに割り当てられたユーザー。 グループが割り当てられている条件付きアクセス ポリシー。 グループにアクセス権が割り当てられているアプリケーション。 |
監視とデータ保持
Microsoft Entra 監査ログには、テナント内で実行されたすべての削除操作と構成操作に関する情報が含まれています。 これらのログは、Microsoft Sentinel などのセキュリティ情報イベント管理ツールにエクスポートすることをお勧めします。 また、Microsoft Graph を使って変更を監査すれば、一定期間にわたって差分を監視するカスタム ソリューションを構築することもできます。 Microsoft Graph を使って削除済みアイテムを検索する方法について詳しくは、Microsoft Graph v1.0 での削除済みアイテムの一覧表示に関する記事を参照してください。
監査ログ
テナントからアクティブ状態のオブジェクトが削除されると、監査ログには必ず "<オブジェクト> の削除" (アクティブから論理削除またはアクティブから物理削除のどちらかの) イベントが記録されます。
アプリケーション、サービス プリンシパル、ユーザー、Microsoft 365 グループの削除イベントは論理的な削除です。 その他すべての種類のオブジェクトでは、物理的な削除になります。
| オブジェクトの種類 | ログ内のアクティビティ | 結果 |
|---|---|---|
| Application | アプリケーションとサービス プリンシパルの削除 | 論理的な削除 |
| Application | アプリケーションの物理的な削除 | 物理的な削除 |
| サービス プリンシパル | サービス プリンシパルを削除する | 論理的な削除 |
| サービス プリンシパル | サービス プリンシパルの物理的な削除 | 物理的な削除 |
| User | ユーザーの削除 | 論理的な削除 |
| User | ユーザーの物理的な削除 | 物理的な削除 |
| Microsoft 365 グループ | グループの削除 | 論理的な削除 |
| Microsoft 365 グループ | グループの物理的な削除 | 物理的な削除 |
| 他のすべてのオブジェクト | <オブジェクトの種類> の削除 | 物理的な削除 |
注意
監査ログでは、削除されたグループの種類は区別されません。 論理的に削除されるのは、Microsoft 365 グループだけです。 グループの削除に関するエントリが表示されている場合、Microsoft 365 グループの論理的な削除であるか、他の種類のグループの物理的な削除である可能性があります。 既知の良好な状態のドキュメントには、組織内にあるグループごとにグループの種類を含める必要があります。
構成の変更の監視については、構成の誤りからの回復に関する記事を参照してください。
ブックを使用して構成の変更を追跡する
Azure Monitor ブックは、構成の変更を監視するのに役立ちます。
機密性の高い操作のレポート ブックは、侵害を示す可能性のある、アプリケーションやサービス プリンシパルの次のような疑わしいアクティビティを識別するのに役立ちます。
- 変更されたアプリケーション、サービス プリンシパルの資格情報、または認証方法。
- サービス プリンシパルに付与された新しいアクセス許可。
- サービス プリンシパルのディレクトリ ロールとグループ メンバーシップの更新。
- 変更されたフェデレーション設定。
「テナント間アクセス アクティビティ ブック」は、外部テナント内のどのアプリケーションにユーザーがアクセスしているか、また外部ユーザーが自分のテナント内のどのアプリケーションにアクセスしているかを監視するのに役立ちます。 このブックを使用して、テナント間の受信または送信アプリケーション アクセスの異常な変更を検索します。
運用上のセキュリティ
オブジェクトの再作成や再構成が必要になることより、不要な変更を防止することの方がはるかに簡単です。 アクシデントを最小限に抑えるために、変更管理プロセスには次のタスクを含めるようにしてください。
- 最小特権モデルを使用する。 チームの各メンバーが、通常のタスクを完了するために必要な最小限の特権を持っていることを確認します。 通常とは異なるタスクのために、特権をエスカレートするプロセスが必要です。
- 構成と削除は、オブジェクトの管理制御で有効にする。 作成、更新、削除 (CRUD) の操作を必要としないタスクには、セキュリティ閲覧者のような、より特権の少ないロールを使用します。 CRUD 操作が必要な場合は、可能な限り、オブジェクト固有のロールを使用します。 たとえば、ユーザー管理者はユーザーのみを削除でき、アプリケーション管理者はアプリケーションのみを削除できます。 可能な限り、こうしたより制限されたロールを使用してください。
- Privileged Identity Management (PIM) を使用する。 PIM を使用すると、権限の Just-In-Time エスカレーションによって物理的な削除などのタスクを許可できます。 PIM を構成することで、特権エスカレーションの通知を受け取ったり承認を行ったりすることができます。