次の方法で共有

クラウド資産を保護する

  • [アーティクル]

この記事では、Azure クラウド資産の信頼性とセキュリティを維持するためのベスト プラクティスについて説明します。 信頼性により、ダウンタイムを最小限に抑えながらクラウド サービスの運用を維持できます。 セキュリティにより、リソースの機密性、整合性、可用性が保護されます。 クラウド運用を成功させるには、信頼性とセキュリティの両方が重要です。

CAF の管理プロセス (準備、管理、監視、保護 (RAMP) を示す図)。

信頼性の管理

信頼性管理には、ダウンタイムを最小限に抑え、ビジネスを保護するために、冗長性、レプリケーション、および定義された復旧戦略を使用する必要があります。 表 1 では、3 つのワークロードの優先順位、信頼性の要件 (アップタイム SLO、最大ダウンタイム、冗長性、負荷分散、レプリケーション)、およびサービス レベル目標 (SLO) に合ったシナリオの例を示します

表 1. ワークロードの優先順位と信頼性の要件の例。

優先順位 ビジネスへの影響 最小アップタイム SLO 1 か月あたりの最大ダウンタイム アーキテクチャの冗長性 負荷分散 データのレプリケーションとバックアップ シナリオ例
高 (ミッション クリティカル) 企業の評判や収益に対する直接的および重大な影響。 99.99% 4.32 分 複数リージョン & 各リージョンの複数の可用性ゾーン アクティブ/アクティブ 同期のリージョン間データ レプリケーションおよび回復用のバックアップ ミッション クリティカルなベースライン
ミディアム 会社の評判または収益に対する測定可能な影響。 99.9% 43.20 分 複数のリージョンおよび各リージョンの複数の可用性ゾーン アクティブ/パッシブ 非同期のリージョン間データ レプリケーションおよび回復用のバックアップ 信頼性の高い Web アプリ パターン
低 会社の評判、プロセス、または利益には影響しません。 99% 7.20 時間 単一リージョン & 複数の可用性ゾーン 可用性ゾーンの冗長性 可用性ゾーン間での同期データレプリケーションと復旧のためのバックアップ & App Service ベースライン
仮想マシンのベースライン

信頼性の責任を特定する

信頼性の責任はデプロイ モデルによって異なります。 次の表を使用して、インフラストラクチャ (IaaS)、プラットフォーム (PaaS)、ソフトウェア (SaaS)、およびオンプレミスのデプロイに対する管理責任を特定します。

責任 オンプレミス IaaS (Azure) PaaS (Azure) SaaS
データ ✔️ ✔️ ✔️ ✔️
コードとランタイム ✔️ ✔️ ✔️
クラウド リソース ✔️ ✔️ ✔️
物理ハードウェア ✔️

詳細については、「信頼性に対する共同責任」を参照してください。

信頼性の要件を定義する

明確に定義された信頼性要件は、アップタイム ターゲット、復旧、データ損失許容度にとって重要です。 信頼性の要件を定義するには、次の手順に従います。

  1. ワークロードに優先順位を付けます。 ビジネスの重要度と財務投資レベルに基づいて、ワークロードに高、中 (既定)、または低優先度を割り当てます。 ビジネス目標との整合性を維持するために、優先順位を定期的に確認します。

  2. すべてのワークロードにアップタイム サービス レベル目標 (SLO) を割り当てます。 ワークロードの優先順位に従ってアップタイム ターゲットを確立します。 優先順位の高いワークロードでは、より厳密なアップタイム目標が必要です。 SLO は、アーキテクチャ、データ管理戦略、復旧プロセス、コストに影響します。

  3. サービス レベル インジケーター (SLI) を識別します。 SLI を使用して、SLO に対するアップタイム パフォーマンスを測定します。 たとえば、サービス正常性の監視 および エラー率などがあります。

  4. すべてのワークロードに目標復旧時間 (RTO) を割り当てます。 RTO は、ワークロードに許容される最大ダウンタイムを定義します。 RTO は、年間のダウンタイム許容時間よりも短くする必要があります。 たとえば、アップタイム SLO 99.99% では、年間ダウンタイムが 52 分 (1 か月あたり 4.32 分) 未満で済みます。 次の手順に従います。

    1. エラーの数を見積もります。 各ワークロードが 1 年に失敗する可能性があると考える頻度を見積もります。 運用履歴を含むワークロードの場合は、SLI を使用します。 新しいワークロードの場合は、障害モード分析 を実行して正確な見積もりを取得します。

    2. RTO を見積もる。 年間の許容されるダウンタイムを、推定故障数で割ります。 1 年に 4 つの障害を見積もる場合、RTO は 13 分以下 (52 分/ 4 エラー = 13 分 RTO) である必要があります。

    3. 回復時間をテストします。 フェールオーバー テストとライブ 障害中の復旧にかかる平均時間を追跡します。 障害からの復旧にかかる時間は、RTO よりも短くする必要があります。 ビジネス継続性ソリューションで数時間かかる場合

  5. すべてのワークロードの目標復旧ポイント (RPO) を定義します。 ビジネスが許容できるデータ損失の量を決定します。 この目的は、データのレプリケートとバックアップの頻度に影響します。

  6. ワークロードの信頼性ターゲットを定義します。 ワークロードの信頼性ターゲットについては、信頼性ターゲットを定義するための Well-Architected Framework の 推奨事項を参照してください。

データの信頼性を管理する

データの信頼性には、可用性と一貫性を維持するために、データ レプリケーション (レプリカ) とバックアップ (ポイントインタイム コピー) が含まれます。 表2 を参照して、データの信頼性ターゲットに合わせたワークロードの優先順位の例を確認してください。

表 2. データ信頼性の構成例を使用したワークロードの優先順位。

ワークロードの優先度 アップタイム SLO データのレプリケーション データのバックアップ シナリオ例
高 99.99% リージョン間の同期データ レプリケーション

可用性ゾーン間の同期データ レプリケーション		 高頻度のリージョン間バックアップ。 頻度は RTO と RPO をサポートする必要があります。 ミッションに不可欠なデータプラットフォーム
ミディアム 99.9% リージョン間の同期データ レプリケーション

可用性ゾーン間の同期データ レプリケーション		 リージョン間バックアップ。 頻度は RTO と RPO をサポートする必要があります。 Reliable Web App パターン におけるデータベースおよびストレージ ソリューション
低 99% 可用性ゾーン間の同期データ レプリケーション リージョン間バックアップ。 頻度は RTO と RPO をサポートする必要があります。 ゾーン冗長を使用したベースライン Web アプリでのデータの回復性

このアプローチでは、データの信頼性の構成をワークロードの RTO 要件と RPO 要件に合わせる必要があります。 次の手順に従います。

  1. データ レプリケーションを管理します。 ワークロードの RTO と RPO の要件に従って、同期的または非同期的にデータをレプリケートします。

    データの配布 データのレプリケーション 負荷分散の構成
    可用性ゾーン間 同期 (ほぼリアルタイム) ほとんどの PaaS サービスは、クロスゾーン負荷分散をネイティブに処理します
    リージョン間 (アクティブ/アクティブ) 同期 アクティブ/アクティブの負荷分散
    リージョン間 (アクティブ/パッシブ) 非同期 (定期的) アクティブ/パッシブ構成

    詳細については、「レプリケーション: データの冗長性」を参照してください。

  2. データ バックアップを管理します。 バックアップは、ディザスター リカバリー (サービスエラー)、データ復旧 (削除または破損)、インシデント対応 (セキュリティ) 用です。 バックアップでは、ワークロードごとに RTO と RPO の要件をサポートする必要があります。 RTO と RPO の目標に合ったバックアップ ソリューションを選択します。 Azure Cosmos DB や Azure SQL Database のネイティブ バックアップなど、Azure の組み込みソリューションを優先します。 オンプレミス データを含むその他の場合は、Azure Backup 使用します。 詳細については、「バックアップ」を参照してください。

  3. ワークロード データの信頼性を設計します。 ワークロード データの信頼性の設計については、「Well-Architected Framework データのパーティション分割ガイド」 を参照し、Azure サービス ガイド してください (信頼性に関するセクションから始めます)。

コードとランタイムの信頼性を管理する

コードとランタイムはワークロードの役割です。 Well-Architected フレームワークの 自己治癒と自己保存ガイドのに従ってください。

クラウド リソースの信頼性を管理する

クラウド リソースの信頼性を管理するには、多くの場合、アーキテクチャの冗長性 (重複するサービス インスタンス) と効果的な負荷分散戦略が必要です。 ワークロードの優先順位に合わせたアーキテクチャの冗長性の例については、表 3 を参照してください。

表 3. ワークロードの優先順位とアーキテクチャの冗長性の例。

ワークロードの優先度 アーキテクチャの冗長性 負荷分散アプローチ Azure 負荷分散ソリューション シナリオ例
高 2 つのリージョンと可用性ゾーン アクティブ/アクティブ Azure Front Door (HTTP)

Azure Traffic Manager (HTTP 以外)		 ミッション クリティカルなベースライン アプリケーション プラットフォーム
ミディアム 2 つのリージョンと可用性ゾーン アクティブ/パッシブ Azure Front Door (HTTP)

Azure Traffic Manager (HTTP 以外)		 信頼性の高いウェブアプリケーションパターンの設計指針
低 単一リージョンと可用性ゾーン 可用性ゾーン間 Azure Application Gateway

仮想マシン用の Azure Load Balancer を追加する		 App Service ベースライン
仮想マシンのベースライン

ワークロードの信頼性要件を満たすために、アーキテクチャの冗長性を実装する必要があります。 次の手順に従います。

  1. アーキテクチャのアップタイムを見積もります。 ワークロードごとに、複合 SLA を計算します。 ワークロードが失敗する可能性があるサービス (クリティカル パス) のみを含めます。 次の手順に従います。

    1. ワークロードのクリティカル パス上のすべてのサービスに対して Microsoft アップタイム SLA を収集します。

    2. 独立したクリティカル パスがない場合は、関連する各サービスのアップタイムの割合を乗算して、単一リージョン複合 SLA を計算します。 独立したクリティカル パスがある場合は、計算する前に手順 3 に進みます。

    3. 2 つの Azure サービスが独立したクリティカル パスを提供する場合は、独立したクリティカル パスの数式をそれらのサービスに適用します。

    4. マルチリージョン アプリケーションの場合は、単一リージョン複合 SLA (N) を複数リージョンのアップタイム式に入力します。

    5. 計算されたアップタイムとアップタイム SLO を比較します。 必要に応じて、サービス レベルまたはアーキテクチャの冗長性を調整します。

    利用事例 数式 変数 例 説明
    単一リージョンのアップタイムの見積もり N = S1 × S2 × S3 × ... × Un N: 単一リージョンのクリティカル パスでの Azure サービスの複合 SLA。
    S: 各 Azure サービスの SLA アップタイムの割合。
    n: クリティカル パス上の Azure サービスの合計数。    		 N = 99.99% (アプリ) × 99.95% (データベース) × 99.9% (キャッシュ) 単一のクリティカル パスにアプリ (99.99%)、データベース (99.95%)、キャッシュ (99.9%) を使用する単純なワークロード。
    独立したクリティカル パスの見積もり S1 x 1 - [(1 - S2) × (1 - S3)] S: 独立したクリティカル パスを提供する Azure サービスの SLA アップタイムの割合。 99.99% (アプリ) × (1 - [(1 - 99.95% データベース) × (1 - 99.9% キャッシュ)]) 2 つの独立したクリティカル パス。 データベース (99.95%) またはキャッシュ (99.9%) は、ダウンタイムなしで失敗する可能性があります。
    複数リージョンのアップタイムの見積もり M = 1 - (1 - N)^R M: 複数リージョンのアップタイムの見積もり。
    N: 単一リージョン複合 SLA。
    R: 使用されているリージョンの数。    		 N = 99.95% および R = 2 の場合、M = 1 - (1 - 99.95%)^2 2 つのリージョンにデプロイされたワークロード。

  2. サービス レベルを調整します。 アーキテクチャを変更する前に、さまざまな Azure サービス レベル (SKU) が信頼性の要件を満たすことができるかどうかを評価します。 一部の Azure サービス レベルでは、Azure Managed Disks など、異なるアップタイム SLA を使用できます。

  3. アーキテクチャの冗長性を追加します。 現在のアップタイムの見積もりが SLO に足りない場合は、冗長性を高めます。

    1. 複数の可用性ゾーンを使用します。 複数の可用性ゾーンを使用するようにワークロードを構成します。 可用性ゾーンでアップタイムがどのように向上するかは、見積もりが難しい場合があります。 可用性ゾーンを考慮するアップタイム SLA を持つのは、一部のサービスのみです。 SLA が可用性ゾーンを考慮する場合は、アップタイムの見積もりでそれらを使用します。 例については、次のテーブルを参照してください。

      Azure サービスの種類 可用性ゾーン SLA を使用した Azure サービス
      コンピューティング プラットフォーム App Service、
      Azure Kubernetes Service、
      Virtual Machines
      データストア Azure Service Bus、
      Azure ストレージ アカウント、
      Azure Cache for Redis、
      Azure Files Premium レベル
      データベース Azure Cosmos DB、
      Azure SQL Database、
      Azure Database for MySQL、
      Azure Database for PostgreSQL、
      Azure Managed Instance for Apache Cassandra（Apache Cassandra 用の Azure 管理インスタンス）
      ロードバランサー (負荷分散装置) Application Gateway
      安全 Azure Firewall

    2. 複数のリージョンを使用します。 多くの場合、アップタイム SLO を満たすために複数のリージョンが必要です。 トラフィックの分散には、グローバル ロード バランサー (Azure Front Door または Traffic Manager) を使用します。 マルチリージョン アーキテクチャでは、慎重なデータ整合性管理が必要です。

  4. アーキテクチャの冗長性を管理します。 冗長性の使用方法を決定する: 毎日の操作 (アクティブ) の一部としてアーキテクチャの冗長性を使用できます。 または、ディザスター リカバリー シナリオ (パッシブ) でアーキテクチャの冗長性を使用できます。 例については、表 3 参照してください。

    1. 可用性ゾーン間の負荷分散。 すべての可用性をアクティブに使用します。 多くの Azure PaaS サービスでは、可用性ゾーン間の負荷分散が自動的に管理されます。 IaaS ワークロードでは、内部ロード バランサー を使用して、可用性ゾーン間で負荷分散を行う必要があります。

    2. リージョン間で負荷分散を行います。 信頼性のニーズに基づいて、複数リージョンのワークロードをアクティブ/アクティブ/パッシブのどちらで実行するかを決定します。

  5. サービス構成を管理します。 Azure リソースの冗長インスタンス間で構成を一貫して適用するため、リソースは同じように動作します。 一貫性を維持するために、コードとしてのインフラストラクチャを使用します。 詳細については、「重複するリソース構成 を参照してください。

  6. ワークロードの信頼性を設計します。 ワークロードの信頼性設計については、Well-Architected フレームワークを参照してください。

    ワークロードの信頼性 指導
    信頼性の柱 高可用性マルチリージョン設計
    冗長性を考慮した設計
    可用性ゾーンとリージョンの使用
    サービス ガイド Azure サービス ガイドの (信頼性セクションから始めます)

詳細については、「冗長性」を参照してください。

ビジネス継続性を管理する

障害からの復旧には、サービスを迅速に復元し、中断を最小限に抑えてユーザーの満足度を維持するための明確な戦略が必要です。 次の手順に従います。

  1. 障害に備える。 高、中、低の優先順位に基づいて、ワークロード用に個別の復旧手順を作成します。 データの信頼性、コードとランタイムの信頼性、および クラウド リソースの信頼性 は、障害に備える基礎となります。 ビジネス継続性の準備に役立つその他の回復ツールを選択します。 たとえば、オンプレミスおよび仮想マシン ベースのサーバー ワークロード Azure Site Recovery を使用します。

  2. テストとドキュメント復旧計画。 フェールオーバーとフェールバックのプロセスを定期的にテストして、ワークロードが目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たしていることを確認します。 インシデント発生時に簡単に参照できるように、復旧計画の各ステップを明確に文書化します。 Azure Site Recovery などの復旧ツールが、指定した RTO を一貫して満たしていることを確認します。

  3. エラーを検出します。 この方法で誤検知が増加した場合でも、迅速に停止を特定するためのプロアクティブなアプローチを採用します。 ダウンタイムを最小限に抑え、ユーザーの信頼を維持することで、カスタマー エクスペリエンスに優先順位を付けます。

    1. エラーを監視します。 ワークロードを監視して、1 分以内に停止を検出します。 Azure Service Health と Azure Resources Health を使用し、Azure Monitor アラート を使用して、関連するチームに通知します。 これらのアラートを Azure DevOps または IT Service Management (ITSM) ツールと統合します。

    2. サービス レベル インジケーター (SLI) を収集します。 SLA として機能するメトリックを定義して収集することで、パフォーマンスを追跡します。 チームでこれらのメトリックを使用して、サービス レベル目標 (SLO) に対するワークロードのパフォーマンスを測定します。

  4. エラーに対応します。 ワークロードの優先順位に合わせて復旧応答を調整します。 冗長インフラストラクチャとデータ レプリカに要求をすぐに再ルーティングするフェールオーバー手順を実装します。 システムが安定したら、根本原因を解決し、データを同期し、フェールバック 手順を実行します。 詳細については、フェールオーバーとフェールバックに関するセクションを参照してください。

  5. エラーを分析します。 問題の根本原因を特定し、問題に対処します。 レッスンを文書化し、必要な変更を加えます。

  6. ワークロードの障害を管理します。 ワークロードのディザスター リカバリーについては、Well-Architected Framework の ディザスター リカバリー ガイドの と Azure サービス ガイド を参照してください (信頼性に関するセクションから始めます)。

Azure 信頼性ツール

利用事例 解決策
データ レプリケーション、バックアップ、およびビジネス継続性 Azure サービス ガイドの (信頼性セクションから始めます)

クイック リファレンス:
Azure Cosmos DB
Azure SQL Database
Azure Blob Storage
Azure Files
[データ バックアップ] Azure Backup
ビジネス継続性 (IaaS) Azure Site Recovery
複数リージョンのロード バランサー Azure Front Door (HTTP)
Azure Traffic Manager (HTTP 以外)
マルチ可用性ゾーンのロード バランサー Azure Application Gateway (HTTP)
Azure Load Balancer (HTTP 以外)

セキュリティの管理

反復的なセキュリティ プロセスを使用して、クラウド環境の脅威を特定して軽減します。 次の手順に従います。

セキュリティ操作の管理

セキュリティコントロールを管理して、クラウド資産に対する脅威を検出します。 次の手順に従います。

  1. セキュリティ ツールを標準化します。 標準化されたツールを使用して、脅威の検出、脆弱性の修正、問題の調査、データのセキュリティ保護、リソースの強化、大規模なコンプライアンスの適用を行います。 Azure セキュリティ ツールの を参照してください。

  2. 環境のベースラインを設定します。 クラウド資産の通常の状態を文書化します。 セキュリティ を監視し、ネットワーク トラフィック パターンとユーザーの動作を文書化します。 Azure のセキュリティ ベースライン を使用し、Azure サービス ガイド して、サービスのベースライン構成を開発します。 このベースラインにより、異常や潜在的なセキュリティの弱点を簡単に検出できます。

  3. セキュリティコントロールを適用します。 アクセス制御、暗号化、多要素認証などのセキュリティ対策を実装すると、環境が強化され、侵害の可能性が軽減されます。 詳細については、「セキュリティの管理」を参照してください。

  4. セキュリティ責任を割り当てます。 クラウド環境全体のセキュリティ監視の責任を指定します。 定期的な監視とベースラインとの比較により、不正アクセスや通常とは異なるデータ転送などのインシデントをすばやく識別できます。 定期的な更新と監査により、進化する脅威に対してセキュリティ ベースラインが効果的に維持されます。

詳細については、「CAF セキュア」を参照してください。

セキュリティ インシデントを管理する

ランサムウェア、サービス拒否、脅威アクターの侵入など、セキュリティ インシデントから復旧するためのプロセスとツールを採用します。 次の手順に従います。

  1. インシデントの準備を行います。 調査、軽減、通信の役割を明確に定義するインシデント対応計画を策定します。 計画の有効性を定期的にテストします。 脆弱性管理ツール、脅威検出システム、インフラストラクチャ監視ソリューションを評価して実装します。 インフラストラクチャのセキュリティ強化を通じて攻撃対象領域を減らし、ワークロード固有の復旧戦略を作成します。 インシデント対応の概要 およびインシデント対応プレイブック を参照してください。

  2. インシデントを検出します。 Microsoft Sentinel などのセキュリティ情報およびイベント管理 (SIEM) ツールを使用して、セキュリティ データを一元化します。 Microsoft Sentinel の セキュリティ オーケストレーション、自動化、応答機能 (SOAR) を使用して、日常的なセキュリティ タスクを自動化します。 脅威インテリジェンス フィードを SIEM に 統合して、クラウド環境に関連する敵対者の戦術に関する分析情報を得ることができます。 Microsoft Defender for Cloud 使用して、Azure で脆弱性を定期的にスキャンします。 Microsoft Defender は、 を Microsoft Sentinel と統合して、セキュリティ イベントの統一されたビューを提供します。

  3. インシデントに対応します。 インシデントの検出時にインシデント対応計画を直ちにアクティブ化します。 調査と軽減の手順をすばやく開始します。 ディザスター リカバリー計画をアクティブ化して、影響を受けるシステムを復元し、インシデントの詳細をチームに明確に伝えます。

  4. セキュリティ インシデントを分析します。 各インシデントの後、脅威インテリジェンスを確認し、学習した教訓とパブリック リソースからの分析情報 (MITRE ATT&CK ナレッジ ベースなど) に基づいてインシデント対応計画を更新します。 脆弱性管理および検出ツールの有効性を評価し、インシデント後の分析に基づいて戦略を調整します。

詳細については、「インシデント対応の管理 (CAF セキュア)」を参照してください。

Azure セキュリティ ツール

セキュリティ機能 Microsoft のソリューション
ID およびアクセス管理 Microsoft Entra ID
ロールベースのアクセス制御 Azure ロールベースのアクセス制御
脅威の検出 Microsoft Defender for Cloud
セキュリティ情報管理 Microsoft Sentinel
データのセキュリティとガバナンス Microsoft Purview
クラウド リソースのセキュリティ Azure セキュリティ ベースライン
クラウド ガバナンス Azure Policy
エンドポイントのセキュリティ Microsoft Defender for Endpoint
ネットワークのセキュリティ Azure Network Watcher
産業用セキュリティ Microsoft Defender for IoT

次のステップ

CAF 管理チェックリスト