削除からの回復

この記事では、Microsoft Entra テナントで論理的および物理的削除から回復する方法について説明します。 まだ行っていない場合は、基礎知識を得るために「回復可能性のベスト プラクティス」をお読みください。

削除を監視する

Microsoft Entra 監査ログには、テナント内で実行されたすべての削除操作に関する情報が含まれています。 これらのログを Microsoft Sentinel などのセキュリティ情報イベント管理ツールにエクスポートします。

また、Microsoft Graph を使って変更を監査すれば、一定期間にわたって差分を監視するカスタム ソリューションを構築することもできます。 Microsoft Graph を使用して削除済みアイテムを検索する方法について詳しくは、Microsoft Graph v1.0 での削除済みアイテムの一覧表示に関するページを参照してください。

監査ログ

テナント内のオブジェクトが論理的または物理的な削除によってアクティブな状態から削除されると、監査ログには常に "<オブジェクト> の削除" イベントが記録されます。

アプリケーション、ユーザー、Microsoft 365 グループの削除イベントは論理的な削除です。 その他すべての種類のオブジェクトでは、物理的な削除になります。 "<オブジェクト> の削除" イベントと削除されたオブジェクトの種類を比較して、物理的な削除イベントの発生を追跡します。 論理的な削除がサポートされていないイベントをメモします。 また、"<オブジェクト> の物理的な削除" イベントをメモします。

オブジェクトの種類	ログ内のアクティビティ	結果
Application	Delete application	論理的な削除
Application	アプリケーションの物理的な削除	物理的な削除
User	ユーザーの削除	論理的な削除
User	ユーザーの物理的な削除	物理的な削除
Microsoft 365 グループ	グループの削除	論理的な削除
Microsoft 365 グループ	グループの物理的な削除	物理的な削除
他のすべてのオブジェクト	"objectType" を削除する	物理的な削除

注意

監査ログでは、削除されたグループの種類は区別されません。 論理的に削除されるのは、Microsoft 365 グループだけです。 グループの削除に関するエントリが表示されている場合、Microsoft 365 グループの論理的な削除であるか、他の種類のグループの物理的な削除である可能性があります。

既知の良好な状態を記したドキュメントには、組織内にあるグループごとにその種類が記載されていることが大切です。 既知の良好な状態の文書化については、「回復可能性のベスト プラクティス」を参照してください。

サポート チケットを監視する

特定のオブジェクトへのアクセスに関するサポート チケットが急激に増加している場合、削除が発生した可能性があります。 一部のオブジェクトには依存関係があるため、アプリケーションへのアクセスに使用されるグループ、アプリケーション自体、またはアプリケーションを対象とする条件付きアクセス ポリシーを削除すると、広い範囲に急激な影響が発生する可能性があります。 このような傾向が見られた場合は、アクセスに必要なオブジェクトが削除されていないことを確認してください。

論理的な削除

ユーザー、Microsoft 365 グループ、アプリケーションの登録などのオブジェクトが論理的に削除されると、他のサービスで使用できない中断の状態になります。 この状態のアイテムではプロパティが保持されます。また、30 日の間復元できます。 30 日が経過すると、論理的に削除された状態のオブジェクトは完全に、つまり、物理的に削除されます。

注意

物理的に削除された状態からオブジェクトを復元することはできません。 再作成して再構成する必要があります。

論理的な削除が発生する場合

ご利用の環境でオブジェクトの削除が発生する理由を理解し、準備できるようにすることが重要です。 このセクションでは、オブジェクト クラスによる論理的な削除の一般的なシナリオについて説明します。 組織に固有のシナリオが確認される場合があるため、検出プロセスが準備の鍵となります。

ユーザー

ユーザーは、Azure portal、Microsoft Graph、または PowerShell を使用してユーザー オブジェクトが削除されるたびに、論理的な削除状態になります。

ユーザーが削除される最も一般的なシナリオは次のとおりです。

• 管理者が要求に応じて、または日常的なユーザー メンテナンスの一環として、Azure portal でユーザーを意図的に削除する。
• Microsoft Graph または PowerShell のオートメーション スクリプトによって削除がトリガーされる。 たとえば、一定期間にサインインしていないユーザーを削除するスクリプトがある場合です。
• ユーザーが Microsoft Entra Connect との同期のスコープ外になる。
• ユーザーが HR システムから削除され、自動化されたワークフローによりプロビジョニング解除される。

Microsoft 365 グループ

Microsoft 365 グループが削除される最も一般的なシナリオは次のとおりです。

• 管理者が、サポート リクエストなどに応じてグループを意図的に削除する。
• Microsoft Graph または PowerShell のオートメーション スクリプトによって削除がトリガーされる。 たとえば、一定期間にグループ所有者がアクセスまたは構成証明していないグループを削除するスクリプトがある場合です。
• 管理者以外が所有するグループを意図せず削除する。

アプリケーション オブジェクトとサービス プリンシパル

アプリケーションが削除される最も一般的なシナリオは次のとおりです。

• 管理者が、サポート リクエストなどに応じてアプリケーションを意図的に削除する。
• Microsoft Graph または PowerShell のオートメーション スクリプトによって削除がトリガーされる。 たとえば、使用または管理されなくなった不要なアプリケーションを削除するプロセスが必要な場合です。 通常は、意図しない削除を回避するために、スクリプトを作成するのではなく、アプリケーションのオフボード プロセスを作成します。

アプリケーションを削除すると、アプリケーションの登録は既定で論理的な削除状態になります。 アプリケーション登録とサービス プリンシパルの関係を理解するには、Microsoft Entra ID - Microsoft ID プラットフォームのアプリとサービス プリンシパルに関するページを参照してください。

管理単位

最もよくある削除のシナリオは、まだ必要であるにもかかわらず、誤って管理単位 (AU) を削除してしまった場合です。

論理的な削除からの回復

論理的に削除されたアイテムは、管理ポータルまたは Microsoft Graph を使用して復元できます。 すべてのオブジェクト クラスの論理的な削除機能をポータルで管理できるわけではありません。一部は、deletedItems Microsoft Graph API を使用してのみ一覧表示、表示、物理的な削除、または復元されます。

論理的な削除で維持されるプロパティ

オブジェクトの種類	維持される重要なプロパティ
ユーザー (外部ユーザーを含む)	ObjectID、グループ メンバーシップ、ロール、ライセンス、アプリケーションの割り当てを含むすべてのプロパティが維持される
Microsoft 365 グループ	ObjectID、グループ メンバーシップ、ライセンス、アプリケーションの割り当てを含むすべてのプロパティが維持される
アプリケーションの登録	すべてのプロパティが維持される。 この表の後の詳細を参照してください。
サービス プリンシパル	すべてのプロパティが維持される
管理単位 (AU)	すべてのプロパティが維持される

ユーザー

論理的に削除されたユーザーは、Azure portal の [ユーザー] - [削除済みのユーザー] ページで確認できます。

ユーザーを復元する方法の詳細については、次のドキュメントを参照してください。

• Azure portal から復元する場合は、最近削除したユーザーの復元または完全な削除に関するページを参照してください。
• Microsoft Graph を使用した復元については、Microsoft Graph v1.0 での削除済みアイテムの復元に関するページを参照してください。

グループ

論理的に削除された Microsoft 365 グループは、Azure portal の [グループ] - [削除済みのグループ] ページで確認できます。

論理的に削除された Microsoft 365 グループを復元する方法の詳細については、次のドキュメントを参照してください。

• Azure portal から復元する場合は、削除された Microsoft 365 グループの復元に関するページを参照してください。
• Microsoft Graph を使用した復元については、Microsoft Graph v1.0 での削除済みアイテムの復元に関するページを参照してください。

アプリケーションとサービス プリンシパル

アプリケーションには、アプリケーションの登録とサービス プリンシパルという 2 つのオブジェクトがあります。 登録とサービス プリンシパルの違いについて詳しくは、Microsoft Entra ID のアプリとサービス プリンシパルに関するページを参照してください。

Azure portal からアプリケーションを復元するには、[アプリの登録]>[削除されたアプリケーション] を選択します。 復元するアプリケーションの登録を選び、[アプリの登録を復元] を選択します。

現時点では、サービス プリンシパルは deletedItems Microsoft Graph API を使用して一覧表示、表示、物理的な削除、または復元できます。 Microsoft Graph を使用したアプリケーションの復元については、削除済みアイテムを復元する - Microsoft Graph v1.0 に関するページを参照してください。

管理単位

AU は deletedItems Microsoft Graph API を使用して一覧表示、表示、または復元できます。 Microsoft Graph を使用した AU の復元については、削除済みアイテムを復元する - Microsoft Graph v1.0 に関するページを参照してください。 AU が削除されると、論理的に削除された状態のままになり、30 日間復元できますが、その間は物理的な削除はできません。 論理的に削除された SU は、30 日後に自動的に物理的に削除されます。

物理的な削除

物理的な削除とは、Microsoft Entra テナントからオブジェクトを完全に削除することです。 論理的な削除がサポートされていないオブジェクトは、この方法で削除されます。 同様に、論理的に削除されたオブジェクトは、削除から 30 日が経過すると物理的に削除されます。 論理的な削除がサポートされているオブジェクトの種類は次のとおりです。

• ユーザー
• Microsoft 365 グループ
• アプリケーションの登録
• サービス プリンシパル
• 管理単位

重要

その他のすべてのアイテムの種類は、物理的に削除されます。 物理的に削除されたアイテムを復元することはできません。 再作成する必要があります。 管理者も Microsoft も、物理的に削除されたアイテムを復元することはできません。 物理的な削除による中断の可能性を最小限に抑えるために、プロセスとドキュメントを用意して、このような状況に備えてください。

準備と現在の状態の文書化の方法については、「回復可能性のベスト プラクティス」を参照してください。

物理的な削除が発生する場合

物理的な削除は、次の状況で発生します。

論理的な削除から物理的なそれに移行した場合:

• 論理的に削除されたオブジェクトが 30 日以内に復元されなかった場合。
• 管理者が論理的な削除状態のオブジェクトを意図的に削除する。

直接、物理的に削除された場合:

• 削除されたオブジェクトの種類で論理的な削除がサポートされていない。
• 管理者が (通常は要求に応じて) ポータルを使用して、アイテムを完全に削除することを選択する。
• オートメーション スクリプトによって、Microsoft Graph または PowerShell を使用したオブジェクトの削除がトリガーされた場合。 オートメーション スクリプトを使用して古いオブジェクトをクリーンアップすることは珍しくありません。 テナント内のオブジェクトに対する堅牢なオフボーディング プロセスは、重要なオブジェクトが大量に削除される可能性がある誤りを避けるのに役立ちます。

物理的な削除からの回復

物理的に削除されたアイテムは再作成して再構成する必要があります。 不要な物理的削除は回避するのが最善です。

論理的に削除されたオブジェクトを確認する

論理的な削除状態のアイテムを頻繁に確認し、必要に応じて復元するプロセスがあることを確めます。 これを行うには、次のようにします。

• 削除済みアイテムを頻繁に一覧表示します。
• 何を復元するかについて特定の条件があることを確認します。
• 必要に応じて、アイテムの評価と復元のために特定のロールまたはユーザーが割り当てられていることを確めます。
• 継続性管理計画を作成してテストします。 詳細については、企業のビジネス継続性管理計画における考慮事項に関するページを参照してください。

不要な削除を回避する方法の詳細については、「リカバリ性のベスト プラクティス」の次の記事を参照してください。

• ビジネス継続性と障害計画
• 既知の良好な状態を文書化する
• 監視とデータ保持