ACSC Essential 8 ユーザー バックアップ ガイドラインを追求する理由

オーストラリアサイバーセキュリティセンター(ACSC)は、サイバーセキュリティの向上に向けたオーストラリア政府の取り組みをリードしています。 ACSC は、オーストラリアのすべての組織に対し、ACSC のサイバー セキュリティ インシデントを軽減するための戦略の基本 8 つの軽減戦略をベースラインとして実装することを推奨しています。 Essential Eight と呼ばれるベースラインは、敵対者がシステムを侵害するのをはるかに困難にする基本的なサイバー セキュリティ対策です。

必須の 8 つの成熟度レベルを使用すると、組織は、今日の相互接続された ICT 環境における一般的な脅威に対するサイバー セキュリティ対策の妥当性を評価できます。

バックアップは、ハードウェアの故障、盗難、偶発的な損傷、自然災害などの物理的な手段の結果として発生する場合でも、誤った削除、破損、ウイルスやマルウェアの感染などの論理的な手段の結果として発生する場合でも、重要なデータを損失から保護するための重要な戦略です。 Essential Eight の軽減策として、バックアップは、実装の規範的なガイダンスを提供するのが難しい場合もあります。これは、organization固有のニーズによって大きく異なります。 通常のバックアップの重要性は、 ACSC のサイバー セキュリティ インシデントを軽減するための戦略における重要な 8 つの戦略の 1 つである包含 os によって確認できます。

バックアップの従来の方法は、データの完全コピー、差分コピー、または増分コピーを定期的に実行し、バックアップ メディアをオフライン (理想的には別の機能に保存) して、データのクリーンコピーをタイムリーに復元できるようにすることです。 このようなアプローチをオンラインの世界でミラーしたくなるかもしれませんが、クラウド サービスの規模によって、このような対策が実用的でコストがかかり得ない場合があります。

つまり、Microsoft 365 などのサービスでデータをバックアップする必要はありませんか? いいえ！ 情報が確実に保護されていることを確認する必要があります。 ただし、Microsoft 365 などのサービスを使用する方法は、当然、オンプレミスのファイル共有を現在保護する方法とは異なります。 組織は、ビジネス要件を満たすために必要に応じてサービス内でデータが保護されるように、組み込みの保持設定を構成することに重点を置く必要があります。 組織はまた、データ分類スキームに投資して、他のコントロールで保護する真に重要な情報を特定する必要があります。 Microsoft 365 は、ユーザーと管理者が誤って削除または破損した場合にファイルと電子メールを復元できるようにするサービスを提供します。 オンプレミスのワークロードまたは Azure サービスに格納されているデータの場合、Azure Backupは、データをバックアップして Microsoft Azure クラウドから復旧するためのシンプルで安全でコスト効率の高いソリューションを提供します。

最後に、ディザスター リカバリー シナリオでは、環境を運用状態に復元するために必要な構成が、データ自体と同じくらい重要になる場合があります。 サーバーとドメインの情報は、Microsoft Azure Recovery Services (MARS) エージェントを使用してシステム状態のバックアップを通じてキャプチャされ、Azure Backup サービスに格納されます。 Microsoft 365 や Azure などのクラウド サービスを構成する場合、コードとしてのインフラストラクチャ ソリューションは、スクリプトまたはデプロイ テンプレートを使用して、必要な設定に環境をリセットしたり、同じ構成で 2 つ目のテナントをプロビジョニングしたりできる、管理ポータル内で直接手動で変更する代替手段を提供します。

Essential Eight では予防策の最小セットが概説されているため、組織は環境によって保証される追加の対策を実装する必要があります。 さらに、Essential Eight はほとんどのサイバー脅威を軽減するのに役立ちますが、すべてのサイバー脅威を軽減するわけではありません。 そのため、 サイバー セキュリティ インシデントを軽減するための戦略 | Cyber.gov.au 、 情報セキュリティ マニュアル (ISM) | Cyber.gov.au の戦略など、その他の軽減戦略とセキュリティ制御を検討する必要があります。

Essential8 Controls の標準バックアップ コンポーネントの成熟度レベル 1、2、3 と ISM へのマッピングの概要を次の表に示します。

ISM コントロール 2024 年 9 月	成熟度レベル	軽減策
1511	1, 2, 3	データ、アプリケーション、設定のバックアップは、ビジネスの重要性とビジネス継続性の要件に従って実行され、保持されます。
1515	1, 2, 3	ディザスター リカバリー演習の一環として、バックアップから一般的な時点へのデータ、アプリケーション、設定の復元がテストされます。
1810	1, 2, 3	データ、アプリケーション、設定のバックアップが同期され、一般的な時点への復元が可能になります。
1811	1, 2, 3	データ、アプリケーション、設定のバックアップは、セキュリティで保護された回復性のある方法で保持されます。
1812	1, 2, 3	特権のないユーザー アカウントは、他のアカウントに属するバックアップにアクセスできません。
1814	1, 2, 3	特権のないユーザー アカウントは、バックアップを変更および削除できません。
1705	2、3	特権ユーザー アカウント (バックアップ管理者アカウントを除く) は、他のアカウントに属するバックアップにアクセスできません
1707	2、3	特権ユーザー アカウント (バックアップ管理者アカウントを除く) は、バックアップを変更および削除できません。
1813	2、3	特権のないユーザー アカウントは、他のアカウントや自分のアカウントに属するバックアップにアクセスできません。
1706	3	特権ユーザー アカウント (バックアップ管理者アカウントを除く) は、独自のバックアップにアクセスできません。
1708	3	バックアップ管理者アカウントは、保有期間中にバックアップを変更および削除できません。

方法

Microsoft 365 での In-Place リテンション期間

共有責任モデルでは、お客様は常に情報とデータに対する責任を負います。 従来のバックアップ実装では、通常、ストレージ コンテナーとその中のすべての保護に重点を置いてきた。 このキャッチオール戦略は、オンプレミスで直面するさまざまな脅威から保護するために必要であった可能性がありますが、物理環境に対するクラウド サービスの責任の導入により、クラウド プロバイダーに移行し、代替コントロールを使用して、機器の損失や故障による脅威の軽減、結果として発生する可能性のあるデータの物理的または論理的な破損を軽減できます。 このような場合、回復性の開発によって、バックアップからインフラストラクチャを回復する必要性が否定される可能性があります。

Microsoft Cloud サービスの回復性と継続性の完全な内訳は、このドキュメントの範囲外です。 組織は、 Microsoft Cloud のリスク評価ガイド に記載されている概念を理解し、 Service Trust Portal で利用可能な適切な外部監査レポートを確認する必要があります。

情報保護の標準的な原則の 1 つは、データとバックアップを個別に保持する必要があるため、サービス内でリテンション期間を使用するという考え方は、最初はお客様に対して直感的に見えることがよくあります。 クラウド サービス内で情報を保持することには多くの利点があります。 Microsoft 365 E3 ライセンスを使用して、平均organizationで使用可能なストレージを検討します。

• ユーザーがホーム ディレクトリに似た独自のファイルをファイル共有に格納するOneDrive for Businessは、既定で 5 TB にストレージを拡張するオプションをユーザーごとに 1 TB に提供し、Microsoft サポート要求に応じてより多くのストレージを使用できます。
• Exchange Onlineでは、100 GB のプライマリ メールボックスと個人用アーカイブ内の無制限のストレージを使用できます。
• SharePoint Online は、コラボレーション サイトとMicrosoft Teamsのバックエンド ストレージを提供し、顧客ごとにプールされたストレージの初期 1 TB と、ライセンスを持つユーザーごとにさらに 10 GB を提供します。

その結果、一般的な 1,000 ユーザーのorganizationでは、Microsoft 365 は 5,111 TB 以上または 5.11 PB を超えるストレージを提供してから、メールボックス アーカイブと、出発したユーザーのメールボックスと個人用ファイルの無制限のストレージを検討します。

この情報をすべて外部サービスに複製すると、バックアップと復元の操作のために転送にかなりの時間がかかり、時間の経過と伴ってビジネスに対するかなりの財務コストが発生する可能性があります。 さらに、データをサービスの外部に移動する際に考慮すべきその他のリスクがあります。たとえば、地理的リージョンの外部にデータを転送することによる規制コンプライアンスへの影響、意図的に、またはそうではない場合、サード パーティのサービスを通じてデータが侵害される可能性があるリスクなどです。 しかし、最終的には、ユーザーの利便性に関する最大の考慮事項の 1 つは、削除されたファイルや、ユーザーのディレクトリ全体を一掃するランサムウェア感染が発生した場合 OneDrive for Businessでも、ユーザーが適切なバージョンのファイルを復元したり、ライブラリ全体を特定の時点に簡単に復元したりするために、管理者の支援なしに簡単に行うことができます。

アイテム保持ポリシーと保持ラベル

保持ポリシーとラベル は、Microsoft 365 でのデータの保持方法を制御する手段を提供します。 アイテム保持ポリシーは、Exchange Onlineメールボックスやパブリック フォルダー、SharePoint Online サイト、OneDrive for Business アカウント、Microsoft 365 グループ、Teams メッセージ、Viva Engage (Yammer) コンテンツなどの場所に適用できます。 1 つのポリシーを複数の場所または個々のサイトまたはユーザーに適用でき、アイテムはコンテナーに割り当てられた保持設定を継承します。 保持設定が適用されると、ユーザーは通常の方法でファイルやメールを操作しますが、ファイルやメッセージが変更または削除されるたびに、システムはデータのコピーをユーザーから隠されたセキュリティで保護された場所に透過的に格納します。

さまざまなワークロードの保持設定のしくみの詳細については、次の記事を参照してください。

• SharePoint と OneDrive の保持の詳細
• Microsoft Teams の保持の詳細
• Viva Engageのリテンション期間について説明します (Yammer)
• Exchange の保持の詳細

アイテム保持ポリシーを使用して、サイトまたはメールボックス レベルのコンテンツに同じ保持設定を割り当てる必要がありますが、より詳細なアプリケーション保持ラベルを使用して、アイテム レベル (フォルダー、ドキュメント、または電子メール) で設定を割り当てることができます。 保持ポリシーとは異なり、保持ラベルは、Microsoft 365 テナント内の別の場所に移動された場合、コンテンツと共に移動します。 保持ラベルには、保持期間の終了時に廃棄レビューをトリガーしたり、コンテンツをレコードとしてマークしたりするなど、アイテム保持ポリシーにはない機能も用意されています。

保持ラベルは、キーワード、パターン、機密情報の種類、トレーニング可能な分類子に基づいて、手動または自動で適用できます。 機密情報の種類 は、個人データ、財務アカウント番号、医療データなど、ファイルや電子メールの機密情報を表すパターンを認識するために使用できます。 トレーニング可能な分類子は、機械学習を使用して項目を理解して分類し、履歴書とソース コードをすぐに認識するか、トレーニング期間後にコントラクトや作業指示書などのorganization固有の情報を認識することで、このアプローチを拡張します。

保持ポリシーとラベルは、データ ライフサイクル管理計画の重要なコンポーネントであり、バックアップ のスタンドインと、より広範なデータ ガバナンスへの影響の両方で評価する必要があります。

保持の In-Place の例外

一部の種類の真に重要な情報については、オンライン サービスの外部でコピーを維持することが実用的な場合があります。 たとえば、電源障害や通信の失敗によってインターネットにアクセスできなかった場合、ディザスター リカバリー 計画と SharePoint サイトに格納されている従業員連絡先登録はほとんど価値がありません。 組織は、確率と影響に基づいて重要なイベントを適切に計画するために、標準的なリスク管理プラクティスを採用する必要があります。 データの識別と分類は、不要なデータを複製することなく、最も重要な情報を別の場所に格納するのに役立ちます。

バックアップまたは回復ソリューションとして意図されていませんが、Microsoft Office Apps for Enterprise の一部としてOneDrive for Businessと Outlook は、どちらも、クラウド サービスと同期されたデータのコピーをユーザーのローカル コンピューターに格納します。このコピーは、元のデータ ソースへのアクセスが利用できない場合にアクセスすることも、コピーすることもできます。 OneDrive クライアント アプリケーションを使用して、キー ドキュメントをオフサイト コンピューターに同期することもできます。

サード パーティの移行ツールを使用すると、Microsoft SharePoint Server のオンライン サービスとスタンバイ インスタンスの間でコンテンツをミラーしたり、プライベート クラウド ソリューションでMicrosoft Exchange Serverしたりできます。 このような精巧でコストのかかるソリューションは、ほとんどの組織やユーザーには保証されませんが、定量的リスク分析を通じて必要と判断された場合は、ビジネスクリティカルなデータとアカウントに実装できます。

Azure Backupを使用してオンプレミスとクラウドベースのサービスをバックアップする

Azure Backup サービスは、Microsoft Azure 内からオンプレミスとクラウドベースのデータをバックアップおよび回復するための、シンプルで安全でコスト効率の高いソリューションを提供します。 Azure のネイティブ コントロールにより、Windows/Linux VM、Azure Managed Disks、Azure Files共有、SQL データベース、SAP HANA データベース、Azure BLOB のバックアップが有効になります。 Microsoft Azure Recovery Services (MARS) エージェントは、ファイル、フォルダー、システム状態をオンプレミスまたは仮想マシンからバックアップし、オンプレミスのAzure Backup Server (MABS) または System Center Data Protection Manager (DPM) サーバーと統合して、Hyper-V VM、Microsoft SQL Server、SharePoint Server、Microsoft Exchange、または VMware VM などのワークロードをバックアップする機能を提供します。

Azure Backupには、転送中および保存中のデータを保護するための広範なセキュリティ機能が含まれています。これには、きめ細かいロールベースのアクセス制御、データの暗号化、意図しない削除からの保護、疑わしいアクティビティの監視とアラートが含まれます。

ID とユーザー アクセスの管理と制御

Recovery Services コンテナーで使用されるストレージ アカウントは分離されており、悪意のある目的でユーザーがアクセスすることはできません。 アクセスは、復元などのAzure Backup管理操作でのみ許可されます。 Azure Backupを使用すると、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、きめ細かいアクセスを通じてマネージド操作を制御できます。 Azure RBAC を使用すると、チーム内で職務を分離し、ジョブを実行するために必要なアクセス権のみをユーザーに付与できます。

Azure Backupには、バックアップ管理操作を制御するための 3 つの組み込みロールが用意されています。

• バックアップ共同作成者: Recovery Services コンテナーを削除し、他のユーザーにアクセスを許可する以外に、バックアップを作成および管理する
• バックアップ オペレーター: バックアップの削除とバックアップ ポリシーの管理を除き、共同作成者が行うすべての操作
• バックアップ リーダー: すべてのバックアップ管理操作を表示するためのアクセス許可

これらの 3 つの組み込みロールに割り当てられている特定の機能の詳細については、次のページ「 Azure ロールベースのアクセス制御を使用したバックアップの管理」を参照してください。 また、Azure リソースの所有者 (Azure リソース グループの所有者など) も、Azure Backupアクセス許可を含む資産に対するアクセス許可を継承するため、特別な考慮事項に焦点を当てる必要があります。

Recovery Services コンテナーに対する重要な操作に対する保護の追加レイヤーを提供するために、Azure Backupでは Resource Guard によるマルチユーザー承認がサポートされます。 Microsoft Entra Privileged Identity Managementを使用して、バックアップ管理者が管理者特権のアクセス許可にアクセスするための承認を取得する必要があることを確認できますが、ユーザーは、保持期間を短縮するためのバックアップ ポリシーの変更や、削除されたバックアップを確実に使用できるようにする論理的な削除機能の無効化など、ロールが提供するすべての機能にアクセスできます 14日。 Resource Guard は、別のサブスクリプションまたはテナント内の Recovery Services コンテナーと Resource Guard インスタンスの両方に対するアクセス許可をバックアップ管理者に要求することで、承認に対処します。

バックアップ管理者がポリシーの変更や論理的な削除の無効化などの重要な操作を実行するには、まず、サブスクリプション ホスティング Azure Backupでバックアップ共同作成者ロールを取得してから、Resource Guard の共同作成者ロールを取得する必要があります。そうしないと、アクションは失敗します。 PIM では、これが必要な理由に関する正当な理由をキャプチャし、短期間割り当て、自動的に取り消すなど、両方の昇格がログに記録され、異なる管理者からの承認が必要になる可能性があります。

クライアント デバイスの設定とプログラムを管理する

設定とアプリケーションを保持するためにクライアント デバイスをバックアップするのではなく、最新の管理アプローチにより、クライアント デバイスをユーザーへの影響を最小限に抑えて簡単に置き換えることができます。 データ ストレージの場所は、クラウド サービスに自動的にリダイレクトされ、同期されます。つまり、オフライン アクセスのみを容易にするために、デバイス上のすべてのコピーが存在します。 アプリケーションは、Microsoft Intuneなどの管理ソリューション内のユーザーポリシーまたはデバイス ポリシーと、クラウドベースのユーザー プロファイルに格納されているアプリケーション設定に基づいて自動的にプロビジョニングできます。

Windows Autopilot を使用すると、ユーザーは、organizationによって事前構成されているか、小売業者から新規に購入されたかに関係なく、ユーザーが自分のコンピューターを簡単に設定でき、デバイスのリセット、再利用、または回復にも使用できます。

ランサムウェアの回復と悪意のあるアクションに関する考慮事項

前のセクションでは、バックアップと復元のシナリオの従来のプロセスの代替として Microsoft サービス内でデータを保持する方法を強調してきましたが、Essential 8 コントロールの意図を考慮すると、ランサムウェア インシデントの影響や不正な管理者または侵害された特権アカウントの意図的なアクションに特に注意する必要があります。

最新の管理とゼロトラストのアプローチでは、ランサムウェアによって侵害されたクライアント マシンが、データを失うことなく Windows Autopilot などのテクノロジによってリモートでワイプおよび再プロビジョニングされる可能性があるため、エンドポイント自体にわずかな影響が生じます。 Azure Backupの仮想マシンまたはシステム状態のバックアップからサーバーを復元または再作成できます。これには、ネットワーク共有にあるユーザー ファイルの復元が含まれます。 SharePoint Online または OneDrive for Businessに格納されているユーザーのファイルを回復するには、「SharePoint と OneDrive を既知の状態に復元する」セクションで後述するように、過去 30 日以内にサイト全体を以前の時点に復元できます。 まれに、ランサムウェアによって削除された電子メール メッセージは、削除済みアイテムから回復される可能性があります。

Microsoft では、ランサムウェア攻撃からの回復に関する具体的なガイダンスを公開し、メールを回復するためのそのガイダンスの手順 6 のオプションを呼び出します。具体的には、管理者がExchange Onlineを利用してユーザーのメールボックス内の削除されたメッセージを回復する方法、エンド ユーザーが非表示の [回復可能なアイテム] フォルダーにアクセスするなど、Outlook for Windows で削除されたアイテムを回復する方法について説明します。

サービスがデータを保持またはバックアップするように構成できるのと同様に、不満を持つ従業員か、侵害された特権アカウントへのアクセス権を持つ外部アクターであるかに関係なく、悪意を持つユーザーによってデータを消去するように構成することもできます。 実際の 2 つの例では、管理者はエグゼクティブのアカウントの保持ポリシーを無効にするよう強制され、エグゼクティブはファイルと電子メールを消去して証拠を破棄することができ、管理者のアカウントにアクセスできる外部脅威アクターは、organizationに対するワイパー攻撃を開始する前にバックアップを削除することができました。 これらのシナリオでは、管理特権を管理するための補正コントロールを含む、多層防御アプローチの必要性が強調されています。

Microsoft 365 には 保持ロック 機能が含まれており、管理者が保持ポリシーとラベルを無効または削除したり、制限を減らしたりするのを防ぐことができます。 これは、データのセキュリティを確保し、規制コンプライアンスを実証するための重要な機能ですが、グローバル管理者やMicrosoft サポートを含む誰も無効にできないため、注意して使用する必要があります。

ポリシーを保護するためのその他のオプションには、Just-In-Time 昇格と承認によるロールベースのアクセスに対する厳格な制御が含まれており、ユーザーが自分で必要な特権を取得できないようにします。 これらの機能については、「 管理特権の制限」のガイドで詳しく説明されています。

Azure Backupでは、Resource Guard は、ポリシーの削除や変更、論理的な削除の無効化などの保護された操作を実行するために、別のサブスクリプションからのアクセス許可を要求することで、Privileged Identity Managementを超えるセキュリティレイヤーを提供します。 これを適切に行うと、別のチームによる承認と監督が保証されます。つまり、保護された機能に変更を加えるには、少なくとも 2 人または 3 人の個人が関与する必要があります。

はじめに

既定のアイテム保持ポリシーを設定する

Microsoft 365 でデータを保護するには、アイテム保持ポリシーを作成し、適切な場所に適用する必要があります。 保持ラベルとは異なり、複数のアイテム保持ポリシーを同じコンテンツに適用できます。つまり、標準のorganization全体の既定値を作成し、必要に応じてコンテナー レベル (アイテム保持ポリシー) またはアイテム レベル (保持ラベル) で長い保持を適用できます。

たとえば、Microsoft Purview ポータルのデータ ライフサイクル管理ソリューションで、すべての Exchange メール受信者、すべての SharePoint サイト、すべての OneDrive アカウント、すべての Microsoft 365 グループに適用されるアイテム保持ポリシーを作成し、最後にアクションなしでアイテムを保持するポリシーを 1 年間設定します。 ポリシーはすべての既存の場所に適用され、後で作成された新しい場所はこれらの設定を継承します。 アイテムが削除された場合、クリーンアップ プロセスの実行が許可される前に、適切な場所 (Exchange 用の回復可能なアイテム フォルダー、SharePoint および OneDrive 用の保持保持ライブラリ) に 1 年間保持されます。 削除されなかったアイテムは、1 年間の保留期間が切れるとその場所に残り、無期限に保持できますが、その後削除された場合は、直ちにクリーンアップ フェーズに移動して適切なサービスで完全に削除されます。

特定のユーザーまたはサイトに適用される保持ポリシーを増やしたり、機密情報を含むアイテムに保持ラベルを付けたりすることで、必要に応じてより長い保持設定を適用できます。 保持ポリシーには アダプティブ スコープまたは静的スコープを指定できます。ポリシーで使用できるオプションは、この選択内容によって異なる場合があります。 Teams および Viva Engage (Yammer) 設定を他のサービスを含む静的ポリシーでは定義できないため、テナント内のすべての場所をカバーするために、複数のポリシーを作成する必要がある場合があります。

出発したユーザーのコンテンツを保持する

会社を離れたユーザーが所有するコンテンツを保持する従来の方法は、メールボックスを PST にエクスポートし、個人用ファイルをファイル サーバーまたはオフライン ストレージ メディアに保存することですが、組織では、マネージャーや後継者による手動レビューだけでなく、電子情報開示ソリューションを通じてそのデータの可視性を提供するために、このデータにオンラインでアクセスできるようにすることが多くあります。 Microsoft 365 は、ライセンスが削除された後、またはアカウントが削除された後、ユーザーのデータを既定で 30 日間保持します。その間、ユーザーがorganizationに戻った場合にアクセスまたは再アクティブ化できます。 この期間が経過した後もデータを保持するために、Microsoft 365 のアイテム保持ポリシーと保持ラベルは、保護するコンテンツが残っている限り、削除クリーンアップ プロセスの開始を妨げる可能性があります。 つまり、前のセクションで定義した 1 年間の保留でコンテンツが保護されている場合、organizationを離れるユーザーは、アカウントが削除され、ライセンスが再割り当てされた後でも、少なくとも翌年に Microsoft 365 によって保持されるメールとファイルを保持します。

Exchange Onlineは引き続き従来の訴訟ホールド機能をサポートしていますが、保留が削除されるまでメールボックスとアーカイブ全体を保護できますが、代わりに Microsoft 365 リテンション期間を使用して、コンテンツに基づいて異なる設定を適用し、保持期間が切れたときにデータに何が起こるかを管理することをお勧めします。

Microsoft 365 での元従業員の管理の詳細については、「 元従業員の管理」を参照してください。

ISM コントロール 2024 年 9 月	成熟	Control	Measure
1511	1, 2, 3	データ、アプリケーション、設定のバックアップは、ビジネスの重要性とビジネス継続性の要件に従って実行され、保持されます。	Microsoft 365 のリテンション期間により、サービス内に格納されているデータがキャプチャされ、回復性の高い環境に保持されます。 保持ラベルやポリシーは、前に説明したように構成する必要がありますが、通常の書き込みまたは削除操作によってファイルが保持されるため、特定のコピー プロセスをスケジュールまたは実行する必要はありません。
1515	1, 2, 3	ディザスター リカバリー演習の一環として、バックアップから一般的な時点へのデータ、アプリケーション、設定の復元がテストされます。	保持ラベルやポリシーは、データ保持が期待どおりに実行されるように検証する必要があります。
1705	2、3	特権ユーザー アカウント (バックアップ管理者アカウントを除く) は、他のアカウントに属するバックアップにアクセスできません。	保持ラベルやポリシーの対象となるデータへのアクセスは、アクセスが十分に理解されるように検証する必要があります。  認証に加えて、特権アカウントが他のアカウントのバックアップや独自のアカウントのバックアップにアクセスできないように、特別な注意を払う必要があります。
1707	2、3	特権ユーザー アカウント (バックアップ管理者アカウントを除く) は、バックアップを変更および削除できません。	保持ラベルやポリシーの対象となるデータへのアクセスは、アクセスが十分に理解されるように検証する必要があります。  認証に加えて、特権アカウントが他のアカウントのバックアップや独自のアカウントのバックアップにアクセスできないように、特別な注意を払う必要があります。
1810	1, 2, 3	データ、アプリケーション、設定のバックアップが同期され、一般的な時点への復元が可能になります。	保持ポリシーは Microsoft 365 サービスの一部として保存され、これらのポリシーの管理とガバナンスは適切に管理する必要があります。
1811	1, 2, 3	データ、アプリケーション、設定のバックアップは、セキュリティで保護された回復性のある方法で保持されます。	保持ポリシーは Microsoft 365 サービスの一部として保存され、これらのポリシーの管理とガバナンスは適切に管理する必要があります。

削除されたメールボックスアイテムをユーザーとして復元する

ユーザーがメールボックス内のアイテムを削除すると、そのアイテムは 削除済みアイテム フォルダーに移動され、フォルダーを開いて目的の場所にドラッグして復元できます。 ユーザーが削除済みアイテムからアイテムを削除した場合、削除済みアイテム フォルダーを空にした場合、または Shift + Delete を選択して別のフォルダーからアイテムを完全に削除した場合、アイテムは 回復可能なアイテム フォルダーに格納されます。

[回復可能なアイテム] フォルダーからアイテムを復元するには、Outlook デスクトップ アプリケーションのツール バーから [削除済みアイテムを回復する] オプションを選択するか、Outlook on the webの [削除済みアイテム] フォルダーを右クリックします。 その後、適切な項目を選択して復元できます。これにより、アイテムが [削除済みアイテム] フォルダーに返され、その後、より永続的な場所に移動できます。 ユーザーは、[削除済みアイテムの回復] インターフェイスからアイテムを消去することもできます。この時点では、管理者のみが復元できます。

削除済みアイテムの回復の詳細については、「Outlook for Windows で削除済みアイテムを回復する」および「Outlook Web Appで削除されたアイテムまたは電子メールを回復する」を参照してください。

削除されたメールボックスアイテムを管理者として復元する

管理者は、ユーザーに代わって削除されたアイテムを複数の方法で回復できます。

1 人のユーザーの削除済みアイテムを回復するには、管理者は、新しい Exchange 管理 センターの受信者の [メールボックス] 設定で [削除済みアイテムの回復] オプションを選択できます。

管理者は、Exchange Online PowerShell を使用して、Get-RecoverableItems コマンドと Restore-RecoverableItems コマンドを使用して削除されたアイテムを回復することもできます。 Exchange 管理 Center メソッドと PowerShell メソッドの両方で、アイテムは元の場所に復元されます。

管理者は、複数のユーザー間でメッセージを検索するために、Microsoft Purview コンプライアンス ポータルのコンテンツ検索機能を使用できます。

検索が完了すると、結果の詳細なレポートが利用可能になり、管理者はクエリをさらに絞り込んだり、結果を PST ファイルにエクスポートしたりできます。

コンテンツ検索アプローチは、SharePoint Online に格納されているファイルを回復するためにも使用でき、標準電子情報開示ケースで使用されるのと同じメカニズムでコンテンツを検索およびエクスポートできます。

ISM コントロール 2024 年 9 月	成熟	Control	Measure
1515	1, 2, 3	ディザスター リカバリー演習の一環として、バックアップから一般的な時点へのデータ、アプリケーション、設定の復元がテストされます。	ユーザーと管理者の両方によるメールボックスアイテムの復元は、プロセスが定義され、理解されていることを確認するために文書化、テスト、検証する必要があります。

SharePoint と OneDrive での以前のバージョンのファイルの復元

バージョン管理は、SharePoint Online および OneDrive for Business のすべてのリストとライブラリで既定で有効になっており、ドキュメントの最新の 500 バージョンは自動的に保持されます。 SharePoint では、ストレージ要件を最適化するためにファイル間の変更のみが格納されますが、バージョン管理はサイト クォータに影響を与え、必要に応じて個々のリストとライブラリで調整できます。

ブラウザーから SharePoint または OneDrive で以前のバージョンのファイルを復元するには、ドキュメント ライブラリを開き、復元するファイルを選択し、省略記号を選択して [バージョン履歴] を選択します。 スペースを節約するために、個々のバージョンを表示および復元したり、必要に応じて削除したりできます。

バージョン履歴には、ファイルを右選択するか、[ファイル情報] を使用して>Microsoft 365 Apps for enterpriseエクスプローラーでアクセスすることもできます。

ISM コントロール 2024 年 9 月	成熟	Control	Measure
1515	1, 2, 3	ディザスター リカバリー演習の一環として、バックアップから一般的な時点へのデータ、アプリケーション、設定の復元がテストされます。	Microsoft 365 サービスに保持されているデータは、バックアップの完了を確実にするために復元テストを必要としない場合がありますが、プラットフォーム内のファイル、サイト、または電子メール メッセージを回復するためのさまざまなオプションを理解し、特定のシナリオに適していることを確認する必要があります。 Microsoft 365 では、復元機能をセルフサービス形式でエンド ユーザーが直接使用できるようにしています。そのため、適切なドキュメントとヘルプデスク サービスは、質問のあるすべてのユーザーが利用できる必要があります。

SharePoint と OneDrive を既知の正常な状態に復元する

OneDrive または SharePoint ドキュメント ライブラリ内のファイルの多くがマルウェアによって削除、上書き、破損、または感染した場合は、過去 30 日以内にライブラリ全体を以前のポイントに復元できます。 右上の [設定] アイコンで、[ OneDrive の復元 ] または [ このライブラリの復元] を選択します。

ドロップダウン ボックスから [ 昨日]、[ 1 週間前]、[ 3 週間前] 、または [ カスタム日時 ] を選択すると、適切なファイルが選択された状態でスライダーが調整されます。 [ 復元 ] を選択すると、強調表示された変更が元に戻されます。

不足しているアイテム、削除済みアイテム、または破損したアイテムの回復の詳細については、「 SharePoint と OneDrive で不足している、削除された、または破損したアイテムを回復する方法」を参照してください。

ISM コントロール 2024 年 9 月	成熟	Control	Measure
1511	1, 2, 3	データ、アプリケーション、設定のバックアップは、ビジネスの重要性とビジネス継続性の要件に従って実行され、保持されます。	ファイルは、SharePoint Online/OneDrive for Businessまたはファイル共有に保存し、Microsoft 365 リテンション期間またはAzure Backupを介してバックアップできます。
1515	1, 2, 3	ディザスター リカバリー演習の一環として、バックアップから一般的な時点へのデータ、アプリケーション、設定の復元がテストされます。	Microsoft 365 サービスに保持されているデータは、バックアップの完了を確実にするために復元テストを必要としない場合がありますが、プラットフォーム内のファイル、サイト、または電子メール メッセージを回復するためのさまざまなオプションを理解し、特定のシナリオに適していることを確認する必要があります。 ファイル、サイト、電子メールを回復するためのオプションに関するこの理解を定期的に強化し、管理者や IT 担当者が最新のプロセスを最新の状態に保つ必要があります。

Azure Backupの構成

Azure Backupを構成するプロセスは、保護するサービスによって異なりますが、最初の手順は常にバックアップを格納するコンテナーの作成です。 Azure には 、Recovery Services コンテナー と Backup コンテナーの 2 種類のコンテナーが用意されており、作成する必要がある種類は、使用するデータ ソースによって決まります。

Recovery Services コンテナーは通常、Azure Virtual Machines、Azure Files、Azure SQL データベースなどのサービスのデータまたは構成情報のコピーを格納し、System Center Data Protection Manager、Windows Server、Azure Backup Server との統合をサポートします。 Recovery Services コンテナーでは、論理的な削除機能がサポートされています。これは、削除されたバックアップのコピーを 14 日間保持し、他のコストに影響を与えることはありません。

バックアップ コンテナーには、Azure Database for PostgreSQL、Azure Blob、Azure Disks、Kubernetes Service、AVS Virtual Machinesなどの新しい Azure ワークロードのバックアップ データが格納されます。

コンテナーとバックアップは、Azure Backup センターを通じて作成でき、バックアップを大規模に管理、監視、運用、分析するための単一の統合管理エクスペリエンスを提供します。

さまざまなバックアップ操作を構成するための詳細なガイダンスは、Microsoft Docsから入手できます。たとえば、Azure VM、Azure VM 上の SQL、Azure Disk、Azure BLOB、Azure Files。

Microsoft Azure Recovery Services (MARS) エージェントは、ファイル、フォルダー、ボリュームまたはシステムの状態をオンプレミスのコンピューターからバックアップしたり、Azure 仮想マシンから個々のファイルやフォルダーをバックアップしたりするために使用できます。 MARS エージェントは、個々のサーバーにダウンロードしてインストールして、Azure への直接バックアップを行うか、Microsoft Azure Backup Server (MABS) または System Center Data Protection Manager (DPM) サーバーにインストールできます。このシナリオでは、MABS/DPM へのマシンとワークロードのバックアップと MARS エージェントを使用して Azure コンテナーにバックアップします。

Hyper-V 仮想マシン、Microsoft SQL Server、SharePoint Server、Microsoft Exchange などのオンプレミスのワークロードを保護するには、ドメインに参加しているサーバーに Microsoft Azure Backup Server をインストールします。 MABS を使用して VMware VM を保護することもできます。

ISM コントロール 2024 年 9 月	成熟	Control	Measure
1511	1, 2, 3	データ、アプリケーション、設定のバックアップは、ビジネスの重要性とビジネス継続性の要件に従って実行され、保持されます。	Azure Backupは、ローカルおよび地理的に冗長なストレージのオプションを使用して、クラウドにリソースをバックアップするための簡単なソリューションを提供します。 バックアップは、オンデマンドまたはスケジュールに従って実行でき、Windows Server システム状態を介してソフトウェアとサーバーの構成情報を含めることができます。
1515	1, 2, 3	ディザスター リカバリー演習の一環として、バックアップから一般的な時点へのデータ、アプリケーション、設定の復元がテストされます。	Azure Backupでは、オンプレミスとクラウドのワークロードにわたって、さまざまな従来のバックアップ サービスが提供されます。 復元オプションはワークロードによって異なりますが、一般的に復元する時点と、元の場所または別の場所に復旧するかどうかを選択できます。 テスト 計画には、すべてのオプションが組み込まれている必要があります。

Microsoft 365 バックアップ

Microsoft 365 バックアップ サービスは、オンプレミスと Azure にあるデータをバックアップするための Microsoft のクラウド内生まれのバックアップ ソリューションです。 これは、既存のオンプレミスまたはオフサイトのバックアップ ソリューションを、信頼性の高いセキュリティで保護されたコスト競争力のあるクラウド バックアップ ソリューションに置き換えます。 また、クラウドで実行されている資産を保護する柔軟性も提供します。

主要なアーキテクチャの概要:

• データが Microsoft 365 データ信頼の境界や現在のデータ所在地の地理的な場所を離れることはありません。
• バックアップは、製品のオフボードを介してバックアップ ツール管理者によって明示的に削除されない限り変更できません。
• OneDrive、SharePoint、Exchange には、物理的な災害から保護するために、データの物理的に冗長なコピーが複数存在します。

Microsoft 365 Desired State Configuration (DSC) ツールを使用したテナント構成の管理

Microsoft 365 DSC は、Microsoft エンジニアが率いる Open-Source イニシアチブであり、コミュニティによって管理されています。これにより、Microsoft 365 テナントの構成方法の定義を記述し、その構成の展開を自動化し、定義された構成の監視を確実に行い、検出された構成ドリフトに対する通知と対処を行うことができます。 また、Exchange Online、Teams、SharePoint、OneDrive、セキュリティとコンプライアンス、Power Platforms、Intune、Plannerなどの主要なワークロードなど、既存の Microsoft 365 テナントから完全に忠実な構成を抽出することもできます。

Microsoft 365 DSC ユーザー ガイドが用意されており、作業の開始に役立ちます。 ツールは、organizationの設定に応じてさまざまな方法で使用できます。最も簡単な形式では、このツールを使用して、Microsoft 365 テナントから構成を抽出し、今後回復または復元が必要な場合に一連のファイルとして保存できます。 もう 1 つのオプションは、ステージング テナントを維持し、ツールを使用して運用環境にすべての変更をデプロイすることです。

ISM コントロール 2024 年 9 月	成熟	Control	Measure
1511	1, 2, 3	データ、アプリケーション、設定のバックアップは、ビジネスの重要性とビジネス継続性の要件に従って実行され、保持されます。	Microsoft 365 環境の構成設定は、Microsoft 365DSC ツールを使用して、ユーザー フレンドリな Excel または HTML レポートとして、またはテナント構成をリセットするために使用できるエクスポート パッケージとしてキャプチャできます。
1515	1, 2, 3	ディザスター リカバリー演習の一環として、バックアップから一般的な時点へのデータ、アプリケーション、設定の復元がテストされます。	Microsoft 365DSC ツールを使用して、以前にキャプチャした構成データを復元目的でインポートできます。

レベル 1 の要件

データ、アプリケーション、設定のバックアップは、ビジネスの重要性とビジネス継続性の要件に従って実行および保持されます

Microsoft 365 のリテンション期間により、サービス内に格納されているデータがキャプチャされ、回復性の高い環境に保持されます。 保持ラベルやポリシーは、前に説明したように構成する必要がありますが、通常の書き込みまたは削除操作によってファイルが保持されるため、特定のコピー プロセスをスケジュールまたは実行する必要はありません。

Azure Backupは、ローカルおよび地理的に冗長なストレージのオプションを使用して、クラウドにリソースをバックアップするための簡単なソリューションを提供します。 バックアップは、オンデマンドまたはスケジュールに従って実行でき、Windows Server システム状態を介してソフトウェアとサーバーの構成情報を含めることができます。

Microsoft 365 環境の構成設定は、Microsoft 365DSC ツールを使用して、ユーザー フレンドリな Excel または HTML レポートとして、またはテナント構成をリセットするために使用できるエクスポート パッケージとしてキャプチャできます。 ファイルは、SharePoint Online/OneDrive for Businessまたはファイル共有に保存し、Microsoft 365 リテンション期間またはAzure Backupを介してバックアップできます。

ディザスター リカバリー演習の一環として、バックアップから一般的な時点へのデータ、アプリケーション、設定の復元がテストされます

Microsoft 365 サービスに保持されているデータは、バックアップの完了を確実にするために復元テストを必要としない場合がありますが、プラットフォーム内のファイル、サイト、または電子メール メッセージを回復するためのさまざまなオプションを理解し、特定のシナリオに適していることを確認する必要があります。 Microsoft 365 では、復元機能をセルフサービス形式でエンド ユーザーが直接使用できるようにしています。そのため、適切なドキュメントとヘルプデスク サービスは、質問のあるすべてのユーザーが利用できる必要があります。 ファイル、サイト、電子メール メッセージを回復するためのオプションの理解は、ディザスター リカバリー演習を通じて定期的に強化する必要があります。

Azure Backupでは、オンプレミスとクラウドのワークロードにわたって、さまざまな従来のバックアップ サービスが提供されます。 復元オプションはワークロードによって異なりますが、一般的に復元する時点と、元の場所または別の場所に復旧するかどうかを選択できます。 テスト 計画には、すべてのオプションが組み込まれている必要があります。

特権のないユーザー アカウントは、他のアカウントに属するバックアップにアクセスできません

Microsoft 365 のインプレースリテンション期間では、データの個別のコピーはなく、情報の場所に基づいてアクセスできます。 たとえば、読み取りアクセス許可を持つすべてのユーザーは SharePoint Online でファイルのバージョン履歴を表示できますが、投稿アクセス許可を持つユーザーのみが実際に以前のバージョンを復元できます。 コントロールに関しては、特権のないアカウントは、既にアクセスできる以上の情報にアクセスできないことを意味します。

Azure Backup にアクセスするには、バックアップ共同作成者、バックアップ オペレーター、またはバックアップ 閲覧者ロールを付与する必要があります。そのため、定義上、特権のないアカウントはデータにアクセスできません。

特権のないユーザー アカウントは、バックアップの変更または削除を防止します

Microsoft 365 で保持されているデータのコピーを変更または削除することはできません。

特権のないアカウントには、バックアップを変更または削除するためのアクセス許可はもちろん、Azure Backupへのアクセス権はまったくありません。

レベル 2 の要件

特権のないユーザー アカウントは、他のアカウントに属するバックアップにアクセスできません

Microsoft 365 には、特権のないアカウントがアクセスするための個別のバックアップはなく、既にアクセスできるファイルのバージョンのみを表示できます。 一般に、コントロールの目的が、ユーザーがバックアップ リポジトリを介して情報にアクセスできないようにする場合、Microsoft 365 は、インプレースリテンション期間の一部としてコンテンツの重複がないため、要件に準拠します。特権のないアカウントは、承認されたデータにのみアクセスできます。 特権アカウントにも、特定のアクセス権を付与する必要があります。

特権のないユーザー アカウントと特権ユーザー アカウント (バックアップ管理者を除く) は、バックアップを変更または削除できません

Microsoft 365 で保持されているデータのコピーを変更または削除することはできません。 ただし、特権ユーザーは、情報が保持されなくなっているようなアイテム保持ポリシーを変更または削除できます。 保持ロック を使用して、グローバル管理者を含む誰もポリシーをオフにしたり、ポリシーを削除したり、制限を減らしたりできないようにすることができます。 これは不正な管理者から保護するのに役立ちますが、このコントロールを利用するかどうかを決定する前に、organizationへの影響を理解しておくことが重要です。

Azure Backupの RBAC モデルでは、バックアップを変更または削除するアクセス許可を持つのは、バックアップ共同作成者のみです。 Azure Backupには、既定で有効になっている論理的な削除機能も提供され、偶発的または悪意のある削除の場合は、削除されたバックアップを 14 日間保持します。

レベル 3 の要件

特権のないユーザー アカウントと特権ユーザー アカウント (バックアップ管理者を除く)、バックアップにアクセスできない

Microsoft 365 には、特権アカウントまたは特権のないアカウントがアクセスするための個別のバックアップはありません。 ユーザーは保持されているファイルとバージョンにアクセスできますが、プライマリ コピーとしてこのデータにアクセスすることとバックアップにアクセスすることには違いはありません。

権限のないアカウントまたは特権アカウントに適切なアクセス許可が付与されていないと、Azure Backupにアクセスできないため、バックアップにアクセスできません。

特権のないユーザー アカウントと特権ユーザー アカウント (Backup Break Glass アカウントを除く) は、バックアップを変更または削除できません

成熟度レベル 2 の要件と同様に、ユーザー、特権、またはその他の方法では、Microsoft 365 のデータの保持コピーを変更または削除することはできません。

Azure Backupでバックアップを変更または削除する権限を持つのは、バックアップ共同作成者だけです。 バックアップ中断アカウントのみがこれらのアクセス許可を持っていることを確認するには、このようなアカウントにのみこのロールを付与します。

Microsoft プラットフォームを使用した成熟度レベルの管理

次の情報では、通常のバックアップで必要な成熟度レベルを達成するための実装アクションに関するガイダンスを提供します。 Microsoft のセキュリティとコンプライアンス プラットフォームを使用して、実装を実現し、コンプライアンスを追跡できます。 Microsoft Purview Compliance Manager には、Essential8 コントロールの実装を評価、管理、追跡するためのテンプレートが用意されています。

組織は Essential8 テンプレートを選択し、対象とする成熟度レベルに基づいて評価を作成できます。 評価テンプレートは、目的の成熟度レベルを達成するための改善アクションを実装するための実用的なガイダンスを提供します。 詳細については、 ACSC の Essential8 成熟度モデル を参照してください。

リファレンス - アーティクル

• 回復性および継続性の概要
• Azure Backup サービスとは
• 概要 - Microsoft365DSC - クラウド構成
• アイテム保持ポリシーと保持ラベルの詳細
• 非アクティブなメールボックスを作成および管理する
• Microsoft 365 でのマルウェアとランサムウェアの保護
• Microsoft 365 テナントにランサムウェア保護を展開する
• 必須の 8 成熟度モデルと ISM マッピング

リファレンス - 成熟度レベル

ISM コントロール 2024 年 9 月	レベル 1	レベル 2	レベル 3
1511 データ、アプリケーション、設定のバックアップは、ビジネスの重要性とビジネス継続性の要件に従って実行され、保持されます。	Y	Y	Y
1810 データ、アプリケーション、設定のバックアップが同期され、一般的な時点への復元が可能になります。	Y	Y	Y
1811 データ、アプリケーション、設定のバックアップは、セキュリティで保護された回復性のある方法で保持されます。	Y	Y	Y
1515 バックアップから一般的な時点へのデータ、アプリケーション、設定の復元は、ディザスター リカバリー演習の一環としてテストされます。	Y	Y	Y
1812 特権のないユーザー アカウントは、他のアカウントに属するバックアップにアクセスできません。	Y	Y	Y
1814 特権のないユーザー アカウントは、バックアップを変更および削除できません。	Y	Y	Y
1813 特権のないユーザー アカウントは、他のアカウントや自分のアカウントに属するバックアップにアクセスできません。	N	Y	Y
1705 特権ユーザー アカウント (バックアップ管理者アカウントを除く) は、他のアカウントに属するバックアップにアクセスできません	N	Y	Y
1707 特権ユーザー アカウント (バックアップ管理者アカウントを除く) は、バックアップを変更および削除できません。	N	Y	Y
1706 特権ユーザー アカウント (バックアップ管理者アカウントを除く) は、独自のバックアップにアクセスできません。	N	N	Y
1708 バックアップ管理者アカウントは、保有期間中にバックアップを変更および削除できません。	N	N	Y