破壊的なサイバー攻撃から Azure リソースを保護する
この記事では、ゼロ トラストの原則を適用し、次のような方法で破壊的なサイバー攻撃から Microsoft Azure リソースを保護する手順について説明します。
| ゼロ トラストの標準 | Definition |
|---|---|
| 明示的に検証する | 常に利用可能なすべてのデータポイントに基づいて認証および承認してください。 |
| 最小限の特権アクセスを使用する | ジャスト・イン・タイムおよびジャスト・エナフ・アクセス（JIT/JEA）、リスクベースのアダプティブ・ポリシー、データ保護により、ユーザー・アクセスを制限します。 |
| 侵害を前提とする | 影響範囲を最小限に抑えるために、アクセスをセグメント化します。 エンドツーエンドで暗号化されていることを確認し、分析を使用して可視化し、脅威検出を推進し、防御を強化します。 リソースのロック、仮想マシンのバックアップとディザスター リカバリー、データ保護とデータ可用性のサービス、および回復インフラストラクチャ、構成ベースのサービス、プラットフォームの自動化と DevOps ツールの保護を使用して、防御を強化します。 脅威の検出には、Microsoft Sentinel と高度なマルチステージ検出を使い、Azure リソースのインシデント対応計画を準備します。 |
この記事には、次の方法に関するガイダンスが含まれます。
- 破壊的なサイバー攻撃から Microsoft Azure リソースを保護します。
- サイバー攻撃の発生を検出します。
- それらに応答する方法。
この記事は、セキュリティ侵害防止と回復インフラストラクチャを実装するゼロ トラスト ビジネス シナリオをサポートする技術実装担当者のためのものです。
リファレンス アーキテクチャ
次の図は、保護のカテゴリごとにグループ化された、このゼロ トラスト ガイダンスの参照アーキテクチャを示したものです。
この Azure 環境には、次のものが含まれます。
| コンポーネント | 説明 |
|---|---|
| A | 仮想マシンとそのファイル |
| B | データ サービスとそのデータ |
| C | ファイルとテンプレートおよび自動化スクリプトを含む回復インフラストラクチャ |
| D | 構成ベースのサービス |
| E | プラットフォームの自動化と DevOps のツール (示されていません) |
各種類の資産を保護するためのタスクについては、この記事のステップ 1 で詳しく説明します。
この記事の内容は？
この記事では、ゼロ トラストの原則を参照アーキテクチャ全体に適用するステップについて説明します。
| ステップ | タスク |
|---|---|
| 1 | サイバー攻撃に対する保護を構成します。 |
| 2 | サイバー攻撃の検出を構成します。 |
| 3 | インシデント対応計画を準備します。 |
ステップ 1: サイバー攻撃に対する保護を構成する
多くの組織は、移行作業の一環として、Azure 仮想マシンのためのバックアップとディザスター リカバリーのソリューションを実装します。 たとえば、Azure ネイティブ ソリューションを使ったり、独自のクラウド エコシステム向けのサードパーティ ソリューションの使用を選んだります。
仮想マシンとそのアプリやデータの保護は重要ですが、仮想マシンを超えて保護の範囲を拡大することも重要です。 このセクションでは、破壊的なサイバー攻撃から Azure のさまざまな種類のリソースを保護する方法に関する考慮事項と推奨事項について詳しく説明します。
サービス固有の考慮事項に加え、リソース ロックを使って、管理プレーンを保護してサービスが削除されないようにすることを検討する必要があります。 リソース ロックを使って、リソースを読み取り専用の状態にすることもできます。 リソース ロックは、制御されたアクセスによって動作し、Azure リソースが変更または破棄されないようにして、サイバー攻撃でそれらが破壊される可能性を減らします。
リソース ロックが予期しない結果にならないようにするには、ロックを適用する前の考慮事項を検討して、適切なリソースに、それらの動作を妨げないような方法で、ロックを適用していることを確認する必要があります。 たとえば、リソース グループ全体ではなく仮想ネットワーク (VNet) をロックすれば、ロックによってリソース グループ内の他のリソースが過剰に制限されるのを防ぐことができます。 これらの考慮事項により、変更または削除されると最も破壊的になるリソースのロックを優先する必要があります。
ロックには、フェールオーバー対象のワークロードの目標復旧時間に関する考慮事項も含まれる場合があります。 ディザスター リカバリー計画ではロックを考慮する必要があり、制御された方法でロックを削除する手順をテストする必要があります。 日常業務と緊急時のシナリオの両方の一部としてロックを管理する方法について、管理者と SecOps スタッフをトレーニングする必要があります。
ロックを削除するアクセス権を持つ管理者は制限する必要があり、Microsoft Entra Privileged Identity Management で提供されるもののような JIT アクセスが含まれる必要があります。 リソースのロックを変更するためのアクセスは、Microsoft.Authorization/locks/* スコープで制御し、永続的なアクセスの一部として許可しないようにする必要があります。
A. 仮想マシンの保護
スケール セットや Kubernetes クラスターなど、仮想マシンベースのワークロードの場合は、管理プレーンでのリソース ロックの使用に加えて、2 つの保護レイヤーを計画する必要があります。
第一に、攻撃が発生した場合に失われたデータを復元できるように、仮想マシンからのデータのバックアップを計画する必要があり、これには Azure Kubernetes Service (AKS) が含まれます。 また、論理的な削除の制御を使って、バックアップされたデータ自体を攻撃から保護する必要もあります。 バックアップの構成については、以下を参照してください。
- Recovery Services コンテナーを作成して構成する
- Azure で仮想マシンをバックアップする
- Azure Kubernetes Service クラスターのバックアップを構成する
- AKS のバックアップと回復
- ランサムウェアから保護するためのバックアップと復元の計画
- Azure Backup の論理的な削除
次に、リージョンの基になるインフラストラクチャが攻撃されたときに、サーバーを新しい場所に復元できるように計画する必要があります。 仮想マシンでのレプリケーションの構成については、「Azure VM のディザスター リカバリーを設定する」をご覧ください。 これには、フェールオーバーの間に使われるリソースに対するアプリケーションと設定の構成が含まれます。
重要
仮想マシン スケール セットの一部である仮想マシンに Azure Site Recovery を使うと、仮想マシンの状態をレプリケートできます。 ただし、レプリケートされたデバイスではスケーリングはサポートされません。
Kubernetes クラスターなど、一部の仮想マシン ベースのワークロードでは、Azure Site Recovery を使ってサーバーの実際の状態をレプリケートすることはできません。 アクティブ/パッシブ構成などの他のソリューションが必要な場合があります。
B. データ サービスの保護
データ サービスは操作に不可欠なデータを含むサービスの非公式なコレクションですが、リソース自体はそれほど重要ではありません。 たとえば、同じ方法で構成されて同じデータをホストする 2 つのストレージ アカウントの間に違いはほとんどありません。
データ サービスは仮想マシンとは異なり、オペレーティング システムの構成が、実行中のアプリケーションや管理プレーンの構成とは異なる場合があります。 その結果、これらのサービスは次のようになります。
- 多くの場合、GRS 層の一部として別のリージョンにレプリケートするストレージ アカウントの機能など、独自のフェールオーバー ツールが含まれています。
- 攻撃からデータを保護し、攻撃が発生した場合にデータを再び使用できるようにする方法について、独自の考慮事項があります。
次の表はよく使われるサービスのデータ保護と可用性の参照を示したものですが、各サービスの製品ドキュメントを調べて、利用できるオプションを理解する必要があります。
警告
ストレージ アカウントの一部の回復シナリオはサポートされていません。 詳しくは、「サポートされていないストレージの回復」をご覧ください。
C: 回復インフラストラクチャの保護
ワークロード上のリソースを保護するだけでなく、回復手順のドキュメント、構成スクリプト、テンプレートなど、中断後に機能の復元に使うリソースも保護する必要があります。 攻撃者が回復インフラストラクチャをターゲットにして中断させることができる場合、環境全体が侵害されて、攻撃からの回復が大幅に遅れ、組織がランサムウェアのシナリオに対して脆弱になる可能性があります。
Azure Backup によって保護されているデータの場合、Azure Backup の論理的な削除を使うと、削除された場合でもバックアップ データを回復できます。 さらに、強化された論理的な削除では、論理的な削除の割り当てが適用され、保持期間を定義できます。
セキュリティをさらに強化するには、重要な操作に対してマルチユーザー認可 (MUA) を実装します。これは、重要な操作では実行前に 2 人以上のユーザーによる承認を必要とする機能です。 これにより、1 人のユーザー、したがって 1 つのユーザー アカウントしか持たない攻撃者では、バックアップの整合性を損なうことができなくなり、セキュリティが強化されます。 MUA を有効にして構成し、認可されていない変更や削除からバックアップ ポリシーを保護します。
認可されていないアクセスを防ぐリソース ロックと JEA/JIT アクセス、および危険にさらされているリソースの検出によって、Azure Site Recovery を保護することができます。
Azure Disk Encryption (ADE) またはカスタマー マネージド キー (CMK) で暗号化された仮想マシンを Azure Site Recovery でレプリケートすると、確実に暗号化キーがターゲット リージョンの Azure Key Vault に格納されます。 ターゲット リージョンにキーを格納すると、フェールオーバー後のキーへのシームレスなアクセスが容易になり、データ セキュリティの継続性が維持されます。 破壊的なサイバー攻撃から Azure Key Vault を保護するには、論理的な削除や消去保護などの高度な脅威に対する保護機能有効にします。
暗号化された仮想マシンの詳細なレプリケーション手順のガイダンスについては、次を参照してください。
D. 構成ベースのサービスの保護
構成ベースのサービスとは、管理プレーンの構成以外にデータを持たない Azure サービスです。 これらのリソースは一般にインフラストラクチャ ベースであり、ワークロードをサポートする基本的サービスです。 たとえば、VNet、ロード バランサー、ネットワーク ゲートウェイ、アプリケーション ゲートウェイなどです。
これらのサービスはステートレスであるため、保護すべき操作データはありません。 これらのサービスを保護するのに最適なオプションは、破壊的な攻撃の後でこれらのサービスの状態を復元できる、Bicep などのコードとしてのインフラストラクチャ (IaC) デプロイ テンプレートを使うことです。 スクリプトをデプロイに使うこともできますが、少数のサービスだけが影響を受ける既存の環境で機能を復元するには、IaC デプロイの方が適しています。
同じ方法で構成されたリソースをデプロイできる場合に限り、サービスは動作し続けることができます。 これらのリソースのコピーをバックアップして保持するのではなく、プログラムによるデプロイを使って攻撃から回復できます。
IaC の使用について詳しくは、「コードとしてのインフラストラクチャの使用に関する推奨事項」をご覧ください。
E. プラットフォームの自動化と DevOps ツールの保護
プログラムによるデプロイやその他の種類の自動化を使っている場合は、プラットフォームの自動化と DevOps ツール リソースもセキュリティで保護する必要があります。 デプロイ インフラストラクチャの保護の例については、「DevOps CI/CD パイプラインのセキュリティ保護」と「開発ライフサイクルをセキュリティで保護するための推奨事項」をご覧ください。
ただし、コード自体の保護も計画する必要があり、これは使っているソース管理ツールによって異なります。 たとえば、GitHub には、ソース コード リポジトリに関するリポジトリのバックアップ手順があります。
また、特定のサービスを確認して、攻撃や破壊からソース コードとパイプラインを最適に保護する方法を決める必要もあります。
仮想マシンでホストされているビルド エージェントなどのコンポーネントの場合は、仮想マシン ベースの適切な保護計画を使って、必要なときにエージェントを確実に利用できるようにすることができます。
ステップ 2: サイバー攻撃の検出を構成する
Azure インフラストラクチャに対する攻撃を検出するには、Microsoft Defender for Cloud から始めます。これは、クラウドネイティブ アプリケーション保護プラットフォーム (CNAPP) であり、さまざまなサイバー脅威や脆弱性からクラウドベースのアプリケーションを保護するように設計されたセキュリティ対策とプラクティスから構成されています。
Defender for Cloud は、Azure コンポーネントに関する追加計画との組み合わせで、Azure コンポーネントからシグナルを収集し、サーバー、コンテナー、ストレージ、データベース、その他のワークロードに固有の保護を提供します。
次の図は、Defender for Cloud と Microsoft Sentinel を経由する Azure サービスからのセキュリティ イベント情報のフローを示したものです。
図の説明:
- Azure サービスは、Microsoft Defender for Cloud にシグナルを送信します。
- Microsoft Defender for Cloud と Defender for Servers などの追加プランは、強化された脅威検出のシグナルを分析して、セキュリティ情報イベント管理 (SIEM) データを Microsoft Sentinel に送信します。
- Microsoft Sentinel は、SIEM データを使って、サイバー攻撃の検出、調査、対応、プロアクティブなハンティングを行います。
この記事のステップ 1 の推奨事項に従って Azure リソースをより適切に保護した後は、Microsoft Sentinel を使って破壊的サイバー攻撃を検出する計画を用意する必要があります。 作業を始める場所としては、「Microsoft Sentinel での高度なマルチステージ攻撃の検出」をお使いください。 これにより、データの破壊、サービスの拒否、悪意のある管理アクティビティといった特定のシナリオに対する検出を構築できます。
対応のためのワークロードの準備の一部として、次のことを行う必要があります。
- リソースが攻撃を受けているかどうかを判断する方法を明らかにします。
- 結果としてインシデントをキャプチャして発生させる方法を決めます。
ステップ 3: インシデント対応計画を準備する
インシデントが発生する前に、破壊的サイバー攻撃に対する明確に定義されていてすぐに実装できるインシデント対応計画を用意する必要があります。 インシデントの間に、進行中の攻撃を阻止したり、破損したデータやサービスを復元したりする方法を決定する時間はありません。
すべての Azure アプリケーションと共有サービスに、仮想マシン、データ サービス、構成サービス、自動化と DevOps サービスを復元するためのプレイブックを含む、対応と回復の計画が必要です。 アプリケーションまたはサービスの領域ごとに、その定義と、明確に定義された依存関係が必要です。
プレイブックでは次のことが必要です。
次のシナリオのためのプロセスを含めます。
- Azure VM をセカンダリ リージョンにフェールオーバーする
- Azure portal で Azure VM のデータを復元する方法
- Azure の仮想マシンにファイルを復元する
- Azure Backup で強化された論理的な削除を使用して、論理的に削除されたデータと復旧ポイントを復旧する
- 災害の後で Kubernetes クラスターの状態を復元する
- 削除されたストレージ アカウントを復旧します
- 論理的に削除されたキー コンテナーを回復する
- 論理的に削除されたシークレット、キー、証明書をキー コンテナーから回復する
- Azure SQL Database のディザスター リカバリー ガイダンス
このサービスを構成する他のリソースの復元プロセスを含めます。
SecOps メンテナンス プロセスの一部として定期的にテストします。
推奨されるトレーニング
- Privileged Identity Management を実装する
- バックアップとディザスター リカバリーのソリューションを設計する
- Microsoft Defender for Cloud を使用してクラウド セキュリティ態勢を改善する
- Microsoft Sentinel を使用して検出を作成し、調査を実行する
次のステップ
セキュリティ侵害防止と回復インフラストラクチャの実装を続けます。
関連情報
この記事でメンションされているさまざまなサービスとテクノロジについては、次のリンクを参照してください。