次の方法で共有

Azure でのミッション クリティカルなワークロードに関するセキュリティの考慮事項

  • [アーティクル]

セキュリティは基本的な設計原則の 1 つであり、ミッション クリティカルなアーキテクチャ プロセス内で最大級の関心事として扱う必要がある重要な設計領域でもあります。

ミッション クリティカルな設計の主な焦点が、アプリケーションのパフォーマンスと可用性を維持するために信頼性を最大化するということを考慮して、この設計領域内で適用されるセキュリティの考慮事項と推奨事項は、可用性に影響を与え、全体的な信頼性を妨げる可能性のある脅威を軽減することに重点を置いています。 たとえば、サービス拒否 (DDoS) 攻撃が成功すると、可用性とパフォーマンスに壊滅的な影響を与えることが知られています。 アプリケーションが SlowLoris などの攻撃ベクトルをどのように軽減するかは、全体的な信頼性に影響します。 そのため、本質的にミッション クリティカルなアプリケーションを実現するには、アプリケーションの信頼性を直接的または間接的に侵害することを目的とした脅威からアプリケーションを完全に保護する必要があります。

また、セキュリティ態勢の強化には、特にパフォーマンス、運用の機敏性、場合によっては信頼性に関して、多くの場合、重大なトレードオフがあることに注意することも重要です。 たとえば、ディープ パケット インスペクションなどの次世代ファイアウォール (NGFW) 機能のためにインライン ネットワーク仮想アプライアンス (NVA) を組み込むと、スケーラビリティと回復の運用がアプリケーションと密接に連携していない場合にはパフォーマンスが大幅に低下し、運用が複雑になり、信頼性のリスクが生じます。 そのため、主要な脅威ベクトルを軽減することを目的とした追加のセキュリティ コンポーネントとプラクティス方法も、アプリケーションの信頼性目標をサポートするように設計されていることが重要であり、これにより、このセクションで説明する推奨事項と考慮事項の重要な側面が形成されます。

重要

この記事は、Azure Well-Architected のミッション クリティカルなワークロード シリーズの一部です。 このシリーズに慣れていない場合は、「ミッション クリティカルなワークロードとは何ですか?」から始めることをお勧めします。

GitHub logo ミッション クリティカルなオープンソース プロジェクト

参照実装は、GitHub で入手できるオープンソース プロジェクトの一部です。 コード資産ではゼロ トラスト モデルを採用して、セキュリティ設計と実装アプローチを構築し、ガイドします。

ゼロ トラスト モデルとの連携

Microsoft ゼロ トラスト モデルは、アプリケーションのすべてのレイヤーにセキュリティを適用するためのプロアクティブで統合されたアプローチを提供します。 ゼロ トラストの基本原則は、すべてのトランザクションを明示的かつ継続的に確認し、最小限の特権を主張し、インテリジェンスを利用し、高度な検出を使用して準リアルタイムで脅威に対応することを目指しています。 最終的には、アプリケーション境界の内外で信頼を排除し、システムに接続しようとするあらゆるものに対して検証を強制することが中心となります。

設計上の考慮事項

アプリケーションのセキュリティ態勢を評価するときは、各考慮事項の基礎としてこれらの質問から始めます。

  • 主要なセキュリティの脆弱性の軽減策を検証するための継続的なセキュリティ テスト。

    • セキュリティ テストは自動化された CI/CD プロセスの一部として実行されていますか?
    • そうでない場合、特定のセキュリティ テストはどのくらいの頻度で実行されますか?
    • テスト結果は、目的のセキュリティ態勢と脅威モデルに照らして測定されていますか?

  • すべての下位環境にわたるセキュリティ レベル。

    • 開発ライフサイクル内のすべての環境は、運用環境と同じセキュリティ態勢を備えていますか?

  • 障害発生時の認証と認可の継続性。

    • 認証または認可サービスが一時的に使用できなくなった場合、アプリケーションは引き続き動作できますか?

  • 自動化されたセキュリティ コンプライアンスと修復。

    • 主要なセキュリティの設定への変更は検出できますか?
    • 非準拠の変更を修正するための対応は自動化されていますか?

  • コードがコミットされる前にシークレットを検出し、ソース コード リポジトリを介したシークレットの漏えいを防ぐシークレット スキャン。

    • コードの一部として資格情報を持たなくても、サービスへの認証は可能ですか?

  • ソフトウェア サプライ チェーンのセキュリティ保護も確実に行ってください。

    • 使用されているパッケージの依存関係内の共通脆弱性および露出 (CVE) を追跡することはできますか?
    • パッケージの依存関係を更新する自動化プロセスはありますか?

  • データ保護キーのライフサイクル。

    • サービス マネージド キーはデータ整合性の保護に使用できますか?
    • カスタマー マネージド キーが必要な場合、安全で信頼性の高いキーのライフサイクルはどのようになりますか?

  • CI/CD ツールには、考慮されるすべての環境サブスクリプションへの Azure リソース デプロイのコントロール プレーン アクセスを容易にするために、十分なサブスクリプション レベルのアクセス権を持つ Microsoft Entra サービス プリンシパルが必要です。

    • アプリケーション リソースがプライベート ネットワーク内でロック ダウンされている場合、CI/CD ツールがアプリケーション レベルのデプロイとメンテナンスを実行できるようにするプライベート データ プレーン接続パスはありますか。
      • これによりさらに複雑さが増し、必要なプライベート ビルド エージェントを介したデプロイ プロセス内のシーケンスが必要になります。

設計の推奨事項

  • Azure Policy を使用して、すべてのサービスにセキュリティと信頼性の構成を適用し、構成時にコントロール プレーンによって逸脱が修復または禁止されるようにして、"悪意のある管理者" シナリオに関連する脅威を軽減できます。

  • 運用サブスクリプション内で Microsoft Entra Privileged Identity Management (PIM) を使って、運用環境への継続的なコントロール プレーン アクセスを取り消します。 これにより、追加の "抑制と均衡" を通じて、"悪意のある管理者" のシナリオによってもたらされるリスクが大幅に軽減されます。

  • この機能をサポートするすべてのサービスには Azure マネージド ID を使用します。これは、アプリケーション コードからの資格情報の削除が容易になり、サービス間通信の ID 管理の運用上の負担が軽減されるためです。

  • 機能をサポートするすべてのサービスで、データ プレーンの認可に Microsoft Entra ロールベースのアクセス制御 (RBAC) を使います。

  • アプリケーション コード内でファーストパーティの Microsoft ID プラットフォーム認証ライブラリを使用して、Microsoft Entra ID と統合します。

  • 選択した ID プラットフォームが使用できない場合、またはアプリケーションの認可に部分的にしか使用できない場合に、機能は低下するが使用できるエクスペリエンスの実現のために、安全なトークン キャッシュを検討してください。

    • プロバイダーが新しいアクセス トークンを発行できなくても、既存のアクセス トークンを検証できる場合、アプリケーションと依存サービスはトークンの有効期限が切れるまで問題なく動作できます。
    • トークン キャッシュは、通常、(MSAL などの) 認証ライブラリによって自動的に処理されます。

  • コードとしてのインフラストラクチャ (IaC) と自動化された CI/CD パイプラインを使用して、障害状況下を含むすべてのアプリケーション コンポーネントの更新を推進します。

    • CI/CD ツール サービス接続が重要な機密情報として保護されるようにし、どのサービス チームも直接使用できないようにします。
    • 運用 CD パイプラインに詳細な RBAC を適用して、"悪意のある管理者" のリスクを軽減します。
    • "悪意のある管理者" のリスクをさらに軽減し、すべての運用環境の変更に対してさらなる技術的保証を提供するために、運用環境デプロイ パイプライン内で手動承認ゲートの使用を検討してください。
      • 追加のセキュリティ ゲートは機敏性の点でトレードオフになる可能性があるため、手動ゲートでも機敏性を維持できる方法を考慮して、慎重に評価する必要があります。

  • すべての下位環境に適切なセキュリティ態勢を定義して、主要な脆弱性が軽減されるようにします。

    • 特にデータの流出に関しては、規制要件でその必要性が規定されている場合を除き、運用と同じセキュリティ態勢を適用しないでください。これにより、開発者の機敏性が大幅に損なわれてしまうためです。

  • ミッション クリティカルなワークロードのリソースが含まれるすべてのサブスクリプションに対して、Microsoft Defender for Cloud (旧称 Azure Security Center) を有効にします。

    • Azure Policy を使用してコンプライアンスを適用します。
    • 機能をサポートするすべてのサービスに対して Azure Defender を有効にします。

  • DevSecOps を採用し、CI/CD パイプライン内にセキュリティ テストを実装します。

    • テスト結果は、自動的か手動かを問わず、リリースの承認を通知するために、準拠したセキュリティ態勢に対して測定する必要があります。
    • セキュリティ テストを、各リリースの CD 運用プロセスの一部として適用します。
      • 各リリースのセキュリティ テストによって運用の機敏性が損なわれる場合は、適切なセキュリティ テストの頻度が適用されていることを確認します。

  • ソース コード リポジトリ内でシークレット スキャンと依存関係のスキャンを有効にします。

脅威モデリング

脅威モデリングは、特定された潜在的な脅威を使用して適切なセキュリティ緩和策を開発することで、セキュリティ設計に対するリスク ベースのアプローチを提供します。 さまざまな確率で発生する潜在的な脅威が数多く存在し、多くの場合、脅威は予期しない、予測不可能な、さらには混沌とした形で連鎖する可能性があります。 この複雑さと不確実性は、従来のテクノロジ要件に基づくセキュリティ アプローチがミッション クリティカルなクラウド アプリケーションにほとんど適さない理由です。 ミッション クリティカルなアプリケーションの脅威モデリングのプロセスは、複雑で揺るぎないものになることが予想されます。

これらの課題に対処するには、以下の防御レイヤーを考慮しながら、モデル化された脅威を補う軽減策を定義して実装するために、レイヤー化された多層防御アプローチを適用する必要があります。

  1. 基本的なセキュリティ機能と制御を備えた Azure プラットフォーム。
  2. アプリケーションのアーキテクチャとセキュリティの設計。
  3. Azure リソースをセキュリティで保護するために適用される、組み込みの有効でデプロイ可能なセキュリティ機能。
  4. アプリケーション コードとセキュリティ ロジック。
  5. 運用プロセスと DevSecOps。

Note

Azure ランディング ゾーン内にデプロイする場合は、一元化されたセキュリティ機能のプロビジョニングによる追加の脅威軽減レイヤーがランディング ゾーン実装によって提供されることに注意してください。

設計上の考慮事項

STRIDE は、主要な脅威ベクトル全体にわたるセキュリティ脅威を評価するための軽量のリスク フレームワークを提供します。

  • なりすまし ID: 権限を持つ個人の偽装。 たとえば、攻撃者が以下を使用して別のユーザーに偽装する
    • ID
    • 認証
  • 入力の改ざん: アプリケーションに送信される入力の変更、またはアプリケーション コードを変更するための信頼境界の侵害。 たとえば、攻撃者が SQL インジェクションを使用してデータベース テーブル内のデータを削除する。
    • データ整合性
    • 検証
    • ブロックリスト/許可リスト
  • アクションの否認: 既に実行されたアクションに異議を唱える機能、およびアプリケーションが証拠を収集して説明責任を果たす機能。 たとえば、悪意のある管理者を追跡することができないまま重要なデータを削除する場合。
    • 監査/ログ
    • 署名
  • 情報漏えい: 制限された情報へのアクセスの取得。 たとえば、攻撃者が制限されたファイルにアクセスする。
    • 暗号化
    • データ窃盗
    • 中間者攻撃
  • サービス拒否: ユーザー エクスペリエンスを低下させる、悪意のあるアプリケーションの中断。 たとえば、Slowloris などの DDoS ボットネット攻撃。
    • DDoS
    • ボットネット
    • CDN と WAF の機能
  • 特権の昇格: 認可の悪用による特権アプリケーション アクセスの取得。 たとえば、攻撃者が URL 文字列を操作して機密情報にアクセスするなど。
    • リモート コード実行
    • 承認
    • 分離:

設計の推奨事項

  • 各スプリント内にエンジニアリング予算を割り当てて、潜在的な新しい脅威を評価し、軽減策を実装します。

  • すべてのアプリケーション サービス チーム全体で整合性を高めるには、セキュリティの軽減策が一般的なエンジニアリング基準内に確実に収まるように、意識的な取り組みを適用する必要があります。

  • サービス レベルの脅威モデリングでサービスを開始し、アプリケーション レベルのスレッド モデルを集約することで、モデルを統合します。

ネットワーク侵入保護

可用性を維持し、データの整合性を保護するには、ミッション クリティカルなアプリケーションと包含データへの不正アクセスを防止することが不可欠です。

設計上の考慮事項

  • ゼロ トラストでは、侵害された状態が想定され、各要求が制御されていないネットワークから送信されたかのように検証されます。

    • 高度なゼロトラスト ネットワーク実装では、マイクロセグメンテーションと分散イングレス/エグレスマイクロ境界が採用されています。

  • Azure PaaS サービスは通常、パブリック エンドポイントを介してアクセスされます。 Azure には、パブリック エンドポイントをセキュリティで保護する機能に加え、それらを完全にプライベート化する機能も用意されています。

    • Azure Private Link や Azure プライベート エンドポイントには、プライベート IP アドレスとプライベート ネットワーク接続を使用した、Azure PaaS リソースへの専用アクセスが用意されています。
    • Virtual Network サービス エンドポイントでは、選択したサブネットから選択した PaaS サービスへのサービス レベルのアクセスが提供されます。
    • Virtual Network インジェクションでは、App Service Environment を介した App Service など、サポートされているサービスに専用のプライベート デプロイが提供されます。
      • 管理プレーンのトラフィックは、依然としてパブリック IP アドレスを通して流れます。

  • サポートされているサービスについては、Azure プライベート エンドポイントを使用した Azure Private Link が、悪意のある管理者による外部リソースへのデータの書き込みなど、サービス エンドポイントに関連付けられたデータ流出のリスクに対処します。

  • プライベート エンドポイントまたはサービス エンドポイントを使用して Azure PaaS サービスへのネットワーク アクセスを制限する場合、アプリケーションをデプロイおよび管理するために、デプロイ パイプラインが Azure リソースの Azure コントロール プレーンとデータ プレーンの両方にアクセスするためのセキュリティで保護されたネットワーク チャネルが必要になります。

    • Azure リソースとしてプライベート ネットワーク上にデプロイされたプライベート セルフホステッド ビルド エージェントは、プライベート接続経由で CI/CD 機能を実行するためのプロキシとして使用できます。 ビルド エージェントには、別の仮想ネットワークを使用する必要があります。
      • CI/CD ツールからプライベート ビルド エージェントへの接続が必要です。
    • 別の方法として、パイプライン内でリソースのファイアウォール規則をその場で変更して、Azure DevOps エージェントのパブリック IP アドレスからの接続を許可し、タスクが完了した後にファイアウォールが削除されるようにします。
      • ただし、この方法は Azure サービスのサブセットにのみ適用できます。 たとえば、これはプライベート AKS クラスターでは実現できません。
    • アプリケーション サービスで開発者および管理タスクを実行するには、ジャンプ ボックスを使用できます。

  • Azure リソースのデータ プレーンへの接続が必要なさらなるシナリオとして、管理タスクとメンテナンス タスクの完了があります。

  • 対応する Microsoft Entra サービス プリンシパルとのサービス接続を Azure DevOps 内で使用して、Microsoft Entra ID を通じて RBAC を適用できます。

  • サービス タグをネットワーク セキュリティ グループに適用して、Azure PaaS サービスとの接続を容易にすることができます。

  • アプリケーション セキュリティ グループは、複数の仮想ネットワークにまたがることはありません。

  • Azure Network Watcher でのパケット キャプチャは、最大 5 時間に制限されています。

設計の推奨事項

  • 外部からの攻撃面を減らすため、アプリケーションがビジネス上の目的を達成するために必要な最小限に公衆ネットワークのアクセスを制限します。

  • プライベート ビルド エージェントを処理する場合、インターネットに直接 RDP または SSH ポートを開かないでください。

    • Azure Bastion を使用して、Azure Virtual Machines へのセキュリティで保護されたアクセスを提供し、インターネット経由で Azure PaaS の管理タスクを実行します。

  • DDoS 標準保護プランを使用して、アプリケーション内のすべてのパブリック IP アドレスをセキュリティで保護します。

  • Azure Front Door を Web アプリケーション ファイアウォール ポリシーと使用して、複数の Azure リージョンにまたがるグローバル HTTP/S アプリケーションを配信し、保護できるようにします。

    • ヘッダー ID 検証を使用してパブリック アプリケーション エンドポイントをロック ダウンし、Azure Front Door インスタンスからのトラフィックのみを受け入れるようにします。

  • ディープ パケット インスペクションや TLS インスペクションなどの追加のインライン ネットワーク セキュリティ要件により、Azure Firewall Premium またはネットワーク仮想アプライアンス (NVA) の使用が必須となる場合は、最大限の高可用性と冗長性が得られるように構成されていることを確認します。

  • パケット キャプチャの要件が存在する場合は、キャプチャ ウィンドウが限られているにもかかわらず、Network Watcher パケットを使用して取り込みます。

  • ネットワーク セキュリティ グループとアプリケーション セキュリティ グループを使用して、アプリケーション トラフィックをマイクロセグメント化します。

    • セキュリティ アプライアンスを使用してアプリケーション内トラフィック フローをフィルター処理しないようにします。
    • Azure Policy を使用して、特定の NSG 規則が常にアプリケーション サブネットに関連付けられるように強制することを検討してください。

  • NSG フロー ログを有効にし、それらを Traffic Analytics にフィードして、内部および外部のトラフィック フローに関する分析情報を取得します。

  • Azure Private Link/プライベート エンドポイント (使用可能な場合) を使用して、アプリケーション設計内の Azure PaaS サービスへのアクセスをセキュリティで保護します。 Private Link をサポートする Azure サービスの詳細については、「Azure Private Link の可用性」を参照してください。

  • プライベート エンドポイントが使用できず、データ流出のリスクが許容できる場合は、Virtual Network サービス エンドポイントを使用して、仮想ネットワーク内から Azure PaaS サービスへのアクセスをセキュリティで保護します。

    • すべてのサブネットで仮想ネットワーク サービス エンドポイントを既定で有効にしないでください。重要なデータ流出チャネルが導入されてしまいます。

  • ハイブリッド アプリケーションのシナリオでは、プライベート ピアリングを使用して ExpressRoute 経由でオンプレミスから Azure PaaS サービスにアクセスします。

Note

Azure ランディング ゾーン内にデプロイする場合は、オンプレミス データ センターへのネットワーク接続がランディング ゾーンの実装によって提供されることに注意してください。 1 つの方法は、プライベート ピアリングで構成された ExpressRoute を使用することです。

データの整合性の保護

暗号化は、データの整合性を確保するための重要なステップであり、最終的には、さまざまな脅威を軽減するために適用できる最も重要なセキュリティ機能の 1 つです。 そのため、このセクションでは、アプリケーションの信頼性を損なうことなくデータを保護するための、暗号化とキー管理に関連する重要な考慮事項と推奨事項について説明します。

設計上の考慮事項

  • Azure Key Vault にはキーとシークレットのトランザクション制限があり、コンテナーごとに一定期間内の帯域幅調整が適用されます。

  • キー、シークレット、証明書のアクセス許可はコンテナー レベルで適用されているため、Azure Key Vault によりセキュリティ境界が提供されます。

    • Key Vault アクセス ポリシーの割り当てにより、キー、シークレット、または証明書へのアクセス許可が個別に付与されます。

  • ロールの割り当てが変更された後、ロールが適用されるまでに最大 10 分 (600 秒) の待機時間が発生します。

    • Azure ロールの割り当てには、サブスクリプションあたり 2,000 件の制限があります。

  • Azure Key Vault の基になるハードウェア セキュリティ モジュール (HSM) は、FIPS 140 検証を受けています。

  • Azure Key Vault は高可用性と冗長を提供し、可用性を維持し、データ損失を防ぎます。

  • リージョンのフェールオーバー中、Key Vault サービスのフェールオーバーには数分かかる場合があります。

    • フェールオーバー中、Key Vault は読み取り専用モードになるため、ファイアウォールの構成や設定などのキー コンテナーのプロパティを変更することはできません。

  • プライベート リンクを使用して Azure Key Vault に接続する場合、リージョン フェールオーバー中に接続が再確立されるまでに最大 20 分かかることがあります。

  • バックアップでは、シークレット、キー、または証明書のポイントインタイム スナップショットが、Azure の外部では復号化できない暗号化された BLOB として作成されます。 BLOB から使用に適したデータを取得するには、同じ Azure サブスクリプションと Azure 地域内の Key Vault に復元する必要があります。

    • バックアップ中にシークレットが更新され、不一致が生じることがあります。

  • サービス マネージド キーを使用すると、Azure はローテーションなどのキー管理機能を実行するため、アプリケーション操作のスコープが縮小されます。

  • 規制管理により、サービス暗号化機能に対するカスタマー マネージド キーの使用が規定されている場合があります。

  • Azure データ センター間でトラフィックが移動する場合、基になるネットワーク ハードウェアで MACsec データ リンク層暗号化が使用され、Microsoft または Microsoft の代理によって制御されていない物理的境界の外部で転送中のデータがセキュリティで保護されます。

設計の推奨事項

  • 可能な場合はサービスマネージド キーを使用してデータを保護することで、暗号化キーを管理し、キーのローテーションなどの運用タスクを処理する必要がなくなります。

    • 明確な規制要件がある場合にのみ、カスタマー マネージド キーを使ってください。

  • 追加の暗号化メカニズムやカスタマー マネージド キーを考慮する必要がある場合は、すべてのシークレット、証明書、キーのセキュリティで保護されたリポジトリとして Azure Key Vault を使用します。

    • 削除されたオブジェクトのリテンション期間の保護を可能にするために、論理的な削除と消去のポリシーを有効にして Azure Key Vault をプロビジョニングします。
    • アプリケーション運用環境には、HSM でサポートされる Azure Key Vault SKU を使用します。

  • 各リージョンのデプロイ スタンプ内に個別の Azure Key Vault インスタンスをデプロイして、ローカライズによる障害の分離とパフォーマンスの向上を実現すると共に、単一の Key Vault インスタンスによって課せられるスケール制限を回避します。

    • アプリケーションのグローバル リソースには専用の Azure Key Vault インスタンスを使用します。

  • シークレット、キー、証明書を完全に削除する認可を特別なカスタム Microsoft Entra ロールに制限することで、最小限の特権モデルに従います。

  • 暗号化キーと Key Vault 内に保存されている証明書が確実にバックアップされ、万一 Key Vault が使用できなくなった場合にオフライン コピーを提供します。

  • Key Vault 証明書を使用して証明書の調達と署名を管理します。

  • キーと証明書のローテーションの自動化プロセスを確立します。

    • 管理を容易にするために、公開証明機関を使用して証明書の管理と更新プロセスを自動化します。
      • 証明書の自動更新を補うために、アラートと通知を設定します。

  • キー、証明書、シークレットの使用状況を監視します。

    • Azure Monitor 内での予期しない使用に対するアラートを定義します。

ポリシー主導のガバナンス

セキュリティ規則は、最終的には、すべてのアプリケーション サービスとチームに一貫して包括的に適用される場合にのみ有効です。 Azure Policy には、セキュリティと信頼性のベースラインを適用するフレームワークが用意されており、ミッション クリティカルなアプリケーションの一般的なエンジニアリング基準への継続的なコンプライアンスが確保されます。 具体的には、Azure Policy は Azure Resource Manager (ARM) コントロール プレーンの重要な部分を形成し、許可されているユーザーが実行できるアクションを制限することで RBAC を補完し、利用されるプラットフォーム サービス全体で重要なセキュリティと信頼性の規則を適用するために使用できます。

そのため、このセクションでは、ミッション クリティカルなアプリケーションに対する Azure Policy 主導のガバナンスの使用に関する重要な考慮事項と推奨事項について確認し、セキュリティと信頼性の規則が継続的に適用されるようにします。

設計上の考慮事項

  • Azure Policy には、プライベート エンドポイントの使用や Availability Zones の使用など、セキュリティと信頼性の規則を適用することでコンプライアンスを推進するメカニズムが用意されています。

Note

Azure ランディング ゾーン内にデプロイする場合は、一元化されたベースライン ポリシー割り当ての実施がランディング ゾーン管理グループとサブスクリプションの実装に適用される可能性があることに注意してください。

  • Azure Policy を使用して、プロビジョニングや構成などの自動化された管理アクティビティを推進できます。

    • リソース プロバイダーの登録。
    • 個々の Azure リソース構成の検証と承認。

  • Azure Policy の割り当てスコープによって対象範囲が決まり、Azure Policy 定義の場所によってカスタム ポリシーの再利用性が示されます。

  • Azure Policy には、特定のスコープでの定義の数など、いくつかの制限があります。

  • "Deploy If Not Exist" (存在しない場合はデプロイする) (DINE) ポリシーの実行には数分かかる場合があります。

  • Azure Policy によって、コンプライアンス レポートとセキュリティ監査に重要な入力が提供されます。

設計の推奨事項

  • 規制およびコンプライアンスの要件を Azure Policy 定義にマッピングします。

    • たとえば、データ所在地の要件がある場合は、使用可能なデプロイ リージョンを制限するポリシーを適用する必要があります。

  • 利用されているすべての Azure サービスについて、安全で信頼性の高い構成定義を取り込むための一般的なエンジニアリング条件を定義し、この条件が Azure Policy 割り当てにマップされてコンプライアンスが適用されるようにします。

    • たとえば、Azure Policy を適用して、関連するすべてのサービスに対して Availability Zones の使用を強制し、信頼性の高いリージョン内デプロイ構成を確保します。

ミッション クリティカルの参照実装には、サンプルの一般的なエンジニアリング基準を定義して適用するための、セキュリティと信頼性を中心とした幅広いポリシーが含まれています。

  • Azure Policy を使用して、一般的なエンジニアリング基準に対するサービス構成のドリフトを監視します。

専用の管理グループの下に複数の運用サブスクリプションがあるミッション クリティカルなシナリオの場合は、管理グループのスコープで割り当てに優先順位を付けます。

  • 組み込みのポリシーを可能な限り使用して、カスタム ポリシー定義を維持する運用上のオーバーヘッドを最小限に抑えます。

  • カスタム ポリシー定義が必要な場合は、包含される環境サブスクリプション全体で再利用できるように、適切な管理グループ スコープで定義がデプロイされていることを確認します。これにより、運用と下位環境全体でポリシーを再利用できるようになります。

    • アプリケーション ロードマップを Azure ロードマップに合わせる場合は、使用可能な Microsoft リソースを使用して、重要なカスタム定義を組み込み定義として組み込めるかどうかについて確認します。

Note

Azure ランディング ゾーン内にデプロイする場合は、より広範な Azure 資産内のすべてのアプリケーションで再利用できるように、中間にある会社のルート管理グループのスコープ内にカスタム Azure Policy 定義をデプロイすることを検討してください。 ランディング ゾーン環境では、特定の一元化されたセキュリティ ポリシーが上位管理グループのスコープ内で既定で適用され、Azure 資産全体にわたってセキュリティ コンプライアンスが適用されます。 たとえば、VM 拡張機能を通じてソフトウェア構成を自動的にデプロイし、準拠するベースライン VM 構成を適用するには、Azure ポリシーを適用する必要があります。

  • Azure Policy を使用して、アプリケーション全体で一貫したタグ付けスキーマを適用します。
    • 必要な Azure タグを特定し、追加ポリシー モードを使用して使用法を適用します。

アプリケーションが Microsoft ミッション クリティカル サポートに登録されている場合は、適用されたタグ付けスキーマが意味のあるコンテキストを提供し、アプリケーションを深く理解してサポート エクスペリエンスを充実させるようにします。

  • Microsoft Entra アクティビティ ログを、アプリケーションで使われるグローバルな Log Analytics ワークスペースにエクスポートします。
    • Azure アクティビティ ログがオペレーショナル データと共に長期保有用としてグローバル ストレージ アカウント内にアーカイブされるようにします。

Azure ランディング ゾーンでは、Microsoft Entra アクティビティ ログも一元化されたプラットフォームの Log Analytics ワークスペースに取り込まれます。 この場合、Microsoft Entra ID がグローバル Log Analytics ワークスペースで引き続き必要かどうかを評価する必要があります。

  • セキュリティ情報とイベント管理を Microsoft Defender for Cloud (旧称 Azure Security Center) と統合します。

Virtual Machines を使用する場合の IaaS 固有の考慮事項

IaaS Virtual Machines の使用が必要なシナリオでは、いくつかの詳細について考慮する必要があります。

設計上の考慮事項

  • イメージはデプロイされた後、自動的に更新されません。
  • 実行中の VM に、更新プログラムが自動的にインストールされることはありません。
  • イメージと個々の VM は、通常、すぐに使用できる状態では書き込まれていません。

設計の推奨事項

  • SSH、RDP、またはその他のプロトコルへのアクセスを提供することにより、パブリック インターネット経由で Virtual Machines への直接アクセスを許可しないでください。 常に、少数のユーザー グループへのアクセスが制限された Azure Bastion とジャンプボックスを使用してください。
  • ネットワーク セキュリティ グループ、(Azure) ファイアウォール、またはアプリケーション ゲートウェイ (レベル 7) を使用して、エグレス トラフィックをフィルター処理して制限し、直接のインターネット アクセスを制限します。
  • 多層アプリケーションの場合は、異なるサブネットを使用することを検討し、ネットワーク セキュリティ グループを使用してその間のアクセスを制限します。
  • 可能な場合は、公開キー認証の使用を優先します。 Azure Key Vault などの安全な場所にシークレットを格納します。
  • 認証とアクセス制御を使用して VM を保護します。
  • ミッション クリティカルなアプリケーションのシナリオで説明したのと同じセキュリティ手法を適用します。

上記のミッション クリティカルなアプリケーション シナリオのセキュリティ プラクティス (該当する場合) と、「Azure における IaaS ワークロードのセキュリティに関するベスト プラクティス」に従って適用します。

次のステップ

ミッション クリティカルなアプリケーション シナリオの運用手順のベスト プラクティスを確認します。

操作手順