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