Microsoft 365 および Google Workspace のバックアップにおける主要なセキュリティ問題

Microsoft 365 と Google Workspace のバックアップ:データのセキュリティと暗号化

本格的なバックアップソリューションであれば、データは転送中と保存中の両方で暗号化されます。製品間の違いは、暗号化を適用するタイミングと、暗号化キーを誰が管理するかという点にあります。

保存中の AES-256

AES-256 は、データがストレージに保存された時点で保護し、想定されるあらゆるコンプライアンス要件を満たします。違いは、そのタイミングにあります。一部の製品は送信元で暗号化を行うため、バケットに到達した時点でオブジェクトはすでに解読不能な状態になっています。他の製品は、この処理をストレージプロバイダーに委ね、到着時にサーバーサイド暗号化によって処理させます。送信元での暗号化は、バックアップソリューションが送信前にデータを暗号化し、バケットの設定方法にかかわらず、ストレージバケット内でも暗号化された状態を維持するため、より強力な保護を提供します。

転送中のHTTPS

クラウド間バックアップでは、データは2回移動します。まずAPIを介してMicrosoftやGoogleのサーバーから送信され、次にユーザのストレージバケットに保存されます。どちらの経路もTLS経由で通信されます。

確認すべき点は、この2回目の転送を認証する認証情報です。これを単一のバケットに限定しておけば、情報漏洩の被害は限定されます。しかし、多くの設定ガイドが黙って行っているように、広範なアカウント権限を付与してしまうと、バックアップを書き込むための鍵が、そのクラウドアカウント内の他のすべてのリソースにアクセスできてしまうことになります。

顧客が管理する暗号化キー

契約によっては、バックアップベンダーが技術的にデータを読み取ることができないことが求められる場合があります。BYOKでは、鍵をお客様自身のAWS KMSまたはAzure Key Vaultに保管することで、この要件に対応しています。留意すべき点が2つあります。鍵を紛失するとバックアップデータも永久に失われてしまうこと、およびインシデント発生時にKMSにアクセスできなくなった場合でも復元が正常に行えることを確認しておく必要があることです。顧客契約や規制当局が顧客による鍵の管理を要求している場合には、検討する価値があります。そうでない場合は、管理しなければならない新たな障害要因が追加されることになります。

バックアップの耐障害性と隔離

暗号化は、第三者がバックアップを読み取ることを防ぎますが、削除を防ぐことはできません。このセクションでは、グローバル管理者アカウントが侵害された場合、それが単なるインシデントに留まるのか、それとも致命的な事態となるのかを決定します。

オブジェクトロックと不変性

不変性とは、保存期間が満了するまでバックアップコピーを変更または削除できないことを意味し、これはバックアップソフトウェアではなく、ストレージプラットフォームによって強制されます。S3互換ストレージでは、これはオブジェクトロックと呼ばれ、Amazon S3、Wasabi、Backblaze B2で同じように機能します。

オブジェクトロックには2つのモードがあります。ガバナンスモードにはオーバーライド機能が組み込まれているため、ルートアカウントまたはバイパス権限を持つユーザはロックされたデータを早期に削除できます。これはまさに、管理者アクセス権を持つ攻撃者が狙う権限そのものです。コンプライアンスモードでは、このオーバーライド機能が排除されます。有効期限が切れるまでは、あなたやプロバイダー自身のサポートチームを含め、誰もそのデータを削除することはできません。

Climb CloudのBackup for Microsoft 365およびBackup Google Workspaceは、Amazon S3、Wasabi、での不変性をサポートしており、これを適用するには2つの方法があります。デフォルトの「オブジェクトロック」はストレージ側で設定され、バケットに書き込まれたすべてのデータをロックします。一方、「GFSバックアップ用オブジェクトロック」は、ユーザごとおよびサービスごとに割り当てられる保存期間ポリシーを通じて機能するため、クライアントのメールボックスとドライブのデータで異なるロック期間を設定することが可能です。

エアギャップと分離

オブジェクトロックは、攻撃者が依然としてアクセス可能なコピーを保護するものです。一方、分離は、その距離そのものを確保するものであり、バックアップの保存場所を選択することでその距離を決定します。ベンダー独自のクラウドに保存した場合、本番データと復旧データは、同じサプライヤーのインフラストラクチャに依存することになります。

BYOC(Bring Your Own Cloud)は別のアプローチです。バックアップは、Microsoft や Google の管理者アカウントとは一切接続されていないプラットフォーム上で、ユーザが発行・ローテーションする認証情報の下、ユーザが所有するストレージアカウントに書き込まれます。

エアギャップはさらに厳格な概念であり、頭の中で明確に区別しておく価値があります。本来、これは物理的なものを指していました。例えば、金庫内のテープ、棚に置かれたドライブ、外部とのネットワーク接続が一切ないマシンなどです。APIを介してスケジュール通りに実行されるものは、これには該当しません。隔離とオブジェクトロックの組み合わせが実用的な代替手段となり、これによりコピーにはアクセス可能のままですが、ロックが有効な間は破壊されることはありません。

冗長性とレプリケーション

冗長性は、ストレージクラスが標準で提供する機能です。S3 Standardでは、すべてのオブジェクトがリージョン内の少なくとも3つのアベイラビリティゾーンに書き込まれますが、これを利用するために特別な設定は必要ありません。一方、レプリケーションはユーザが定義し、料金を支払うルールであり、この2つのうちアカウント境界を越えることができるのはレプリケーションのみです。ここで、冗長性は「耐久性」から「分離性」へと性質が変わります。

重要なデフォルトの挙動が1つあります。レプリケーションが有効なバケットからオブジェクトを削除すると、S3はソース側に削除マーカーを追加しますが、宛先にはコピーしません。AWSがこのように設計したのは、上流で何らかの問題が発生した場合でも、宛先の状態を保持するためです。

データの保存地域

コンプライアンス上の扱いを決定するのは、バケットが作成された際に設定されたバケットのリージョンです。これは、バックアップコンソールが稼働しているリージョンとは異なり、この2つのリージョンが予想以上に異なる法域に属していることがよくあります。

メタデータは、それが記述するデータと必ずしも同じ場所にあるとは限らないため、ユーザを惑わせやすい部分です。両者がどこに保存されているか、またサポート担当者がどちらにアクセスする際にどこにいるのか、ベンダーに確認してください。

3つのレイヤー、3つの異なる役割

不変性により、攻撃者がデータを破壊することは防げますが、データは単一のアカウントにのみ保存されるため、そのアカウントが消滅する可能性があります。冗長性は、コピーを複数の場所に保管することでこの問題を解決しますが、有効な鍵は攻撃者にとってもあなたにとっても同じように機能するため、認証情報に関しては何の対策にもなりません。分離はこの問題を解決しますが、保護対象のコピーが上書きされない場合にのみ有効です。各レイヤーは次のレイヤーが機能する部分で機能しなくなるため、エアギャップと不変性は、本来は同じ役割を競い合っているわけではないにもかかわらず、代替案として議論されることがあります。

Climb Cloud Backup(CCB)は、これら3つの要件をすべて満たすSaaSバックアップソリューションを提供しており、設定は弊社ではなくお客様自身が行います。バックアップデータはお客様が所有するストレージに保存されるため、分離は構造的に確保され、冗長性はお客様が選択したプロバイダーとストレージクラスによって実現されます。不変性はAmazon S3、Wasabi上で動作し、保存期間ポリシーを通じて適用されます。

IDおよびアクセスセキュリティ

バックアップの障害は、復元が必要になるまで気づかれないことがよくあります。アラートにより運用上の問題を早期に発見でき、監査ログはそれらの調査に必要な痕跡を提供します。

二要素認証

個々の管理者に有効化を任せるのではなく、すべてのアカウントでこれを強制的に適用してください。その後、裏口も確認してください。APIトークン、CLIアクセス、および有効期間が長いセッションクッキーは、多くの場合、第二要素なしで認証が行われ、閉じたばかりの扉を再び開けてしまうからです。

ロールベースのアクセス制御

バックアップを管理するすべてのユーザが、その内容を閲覧する必要はありません。Climb Cloud Backup for M365/Google では、サインインごとにこの権限を区分しています。プロバイダーロールは、コンテンツを閲覧することなくバックアップと保存期間の設定を行うのに対し、グローバル管理者またはスーパー管理者はデータの閲覧と復元を行うことができます。日常業務はプロバイダーロールに任せてください。

OAuth と最小権限に基づく API アクセス

クラウド間バックアップでは、保存されたユーザパスワードの代わりに、OAuth ベースのアプリケーション認証を使用すべきです。要求された各 API 権限を、バックアップまたは復元操作に割り当ててください。復元には書き込みアクセスが必要になる場合がありますが、その場合は、その旨を文書化し、必要なワークロードに限定し、取り消し可能にする必要があります。

アクセス制御のさらなる強化

以下の3つの追加制御により、さまざまなアクセス経路に対応します。

シングルサインオン

コンソールへのアクセスを中央集約型のID管理下に置き、離職時の手続きを簡素化します。ユーザを無効化するとコンソールへのアクセスも停止されるはずですが、アクティブなセッション、フォールバックアカウント、およびサービスIDについて、製品がどのように処理するかを確認してください。

IP許可リスト

コンソールへのアクセスを承認済みネットワークに限定し、安定した送信元IPアドレスと組み合わせることで最大の効果を発揮します。緊急時のアクセスを遮断する可能性があるため、管理された例外経路を定義し、テストを行ってください。

職務の分離

本番環境とバックアップ環境の管理を、異なるIDで行います。1つのアカウントで両方の環境を管理している場合、そのアカウントが侵害されると、ソースデータやリカバリコピーが漏洩する恐れがあります。サポートされている場合は、データの削除や保持期間の変更を別の役割に割り当ててください。

監視、アラート、および監査機能

データが必要になるまで、バックアップの失敗に気づかない場合があります。アラートは失敗したジョブや実行されなかったジョブを通知し、監査ログは誰がいつバックアップ環境を変更したかを記録します。

メールアラート

ジョブの失敗や一部完了、スケジュールの未実行、完了シグナルの欠如についてアラートを送信します。毎日の成功レポートは「ハートビート」としての役割を果たしますが、それが停止したことに誰かが気づいて初めて意味があります。

アラートは、責任の所在とエスカレーション手順が明確に定義された監視用アドレスやチケット管理システムに転送してください。アラートが目立つようにするため、大量の自動送信メールとは区別して管理してください。

監査ログ

どのイベントが記録されるか、ログの保存期間はどのくらいか、ファイルまたはAPI経由でエクスポート可能かどうかを確認してください。保存期間は、調査およびコンプライアンスの要件を満たす必要があります。そうでない場合は、ログをSIEMに転送するか、アーカイブしてください。

ログイン、設定および権限の変更、復元、削除を、実行したユーザ、対象、タイムスタンプ、結果とともに記録してください。

異常検知とランサムウェア検知

一部のプラットフォームでは、各バックアップ実行結果をユーザの通常の変更率と比較し、異常値を検知します。OneDriveを標的とするランサムウェアは、対象となるすべてのファイルを上書きするため、変更されたデータの量がベースラインを大幅に上回る急増を示し、その急増が検知されるのです。ただし、このチェックは次のバックアップ実行時にのみ行われるため、タイミングに制限があります。これは、Microsoft 365やGoogle Workspaceのセキュリティアラート、エンドポイント検知に代わるものではなく、それらと併せて活用すべき追加のシグナルとして捉えてください。

安全な復元とバックアップの整合性

バックアップは、完全かつ安全に復元できる場合にのみ価値を発揮します。マルウェアのスクリーニング、整合性チェック、および復元テストは、そのプロセスの各段階を検証するものです。

復元前のマルウェアスキャンが重要なのは、ランサムウェアの攻撃者が、攻撃を実行するまで数週間にわたり環境内に潜伏し、その結果、ペイロードが直近の復元ポイント内に残ってしまうためです。この機能が利用できない場合は、隔離された場所に復元し、本番環境のテナントに一切影響が及ばないよう、そこでスキャンを行ってください。

バックアップの整合性検証では、通常はチェックサムや類似の検証手法を用いて、保存されたデータが書き込まれた内容と依然として一致しているかどうかを確認します。これは、バックアップがすべてを捕捉したことを証明するものではありません。ライセンス、認証、または権限の変更により、ユーザやアイテムでエラーが発生しているにもかかわらず、ジョブは警告を表示したまま完了することがあります。全体的なステータスだけでなく、ユーザごとおよびスキップされたアイテムごとの結果も確認してください。

復旧テストは、3-2-1-1-0における「0」に相当し、ダッシュボードが正常表示されているという仮定ではなく、実際に復元を行うことでその有効性が証明されます。プラットフォームで自動化されていない場合は、四半期ごとのテストをカレンダーに組み込み、所要時間を計測し、発生した事象を記録してください。保険会社や監査機関の双方から、この記録の提出が求められるようになってきています。

M365 および Google Workspace バックアップのセキュリティ機能一覧

この一覧に基づいて製品を評価してください。プロセスやストレージ構成で対応できるのであれば、意図的な機能の欠落は問題ありませんが、復元時にその欠落に気づいた場合は危険です。

もし3つの事項のみを徹底するのであれば、適用される保存期間ポリシーによる不変性、自社が管理するストレージへのバックアップデータの保存、およびテナント管理とは分離されたバックアップ管理の3つにしてください。これらを徹底することで、単なる「悪い1週間」が「事業の閉鎖」につながるような事態を防ぐことができます。

Climb CloudBackupのMicrosoft 365およびGoogle Workspace向けバックアップは、BYOCモデルで動作し、保存時のAES-256暗号化、転送時のHTTPS、ロールベースのアクセス制御、多要素認証、監査ログ、およびAmazon S3、Wasabi上の不変バックアップを備えています。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください