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

  • [アーティクル]

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

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

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

重要

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

GitHub ロゴMission-Critical オープンソース プロジェクト

参照実装は、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。

注意

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 サービス プリンシパルを持つサービス Connectionsは、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 検査などの追加のインライン ネットワーク セキュリティ要件で、premium またはネットワーク仮想アプライアンス (NVA) Azure Firewall使用が義務付けられている場合は、高可用性と冗長性を最大限に確保するように構成されていることを確認します。

  • パケット キャプチャの要件が存在する場合は、Network Watcherパケットを使用してキャプチャ期間が制限されているにもかかわらずキャプチャします。

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

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

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

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

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

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

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

注意

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

データ整合性の保護

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

設計上の考慮事項

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

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

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

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

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

  • Azure Key Vault基になるハードウェア セキュリティ モジュール (HSM) には、FIPS 140 検証があります。

  • Azure Key Vault では、高可用性と冗長性が提供され、可用性を維持し、データ損失を防ぐことができます。

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

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

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

  • バックアップでは、Azure の外部で復号化できない暗号化された BLOB として、シークレット、キー、または証明書の特定の時点のスナップショットが作成されます。 BLOB から使用可能なデータを取得するには、同じ Azure サブスクリプションと Azure geography 内の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の使用など、セキュリティと信頼性の規則を適用することでコンプライアンスを推進するメカニズムを提供します。

注意

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の使用を強制し、信頼性の高いリージョン内デプロイ構成を確保します。

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

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

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

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

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

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

注意

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

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

アプリケーションが Microsoft Mission-Critical サポートにサブスクライブされている場合は、適用されたタグ付けスキーマが、アプリケーションの深い理解を持つサポート エクスペリエンスを強化するための意味のあるコンテキストを提供していることを確認します。

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

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

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

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

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

設計上の考慮事項

  • イメージは、デプロイ後に自動的に更新されません。
  • 更新は、実行中の VM に自動的にインストールされません。
  • 通常、イメージと個々の VM はすぐには強化されません。

設計の推奨事項

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

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

次のステップ

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

操作手順