次の方法で共有

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

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

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

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

Von Bedeutung

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

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

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

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

設計に関する考慮事項

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

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

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

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

    • 開発ライフサイクル内のすべての環境のセキュリティ体制は運用環境と同じですか?

  • 障害が発生した場合の認証と承認の継続性。

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

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

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

  • コードがコミットされる前にシークレットを検出するためのシークレット スキャン。ソース コード リポジトリを介したシークレット リークを防ぎます。

    • コードの一部として資格情報を持たないサービスに対する認証は可能ですか?

  • ソフトウェア サプライ チェーンをセキュリティで保護します。

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

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

    • サービスマネージドキーをデータ整合性保護に使用できますか?
    • カスタマー マネージド キーが必要な場合、セキュリティで保護された信頼性の高いキーライフサイクルはどのようになっていますか?

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

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

設計に関する推奨事項

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

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

  • アプリケーション コードからの資格情報の削除が容易になり、サービス間通信の ID 管理の運用上の負担が軽減されるため、機能をサポートするすべてのサービスに 対して Azure マネージド 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: 権限を持つ個人の偽装。 たとえば、攻撃者が別のユーザーを偽装している場合、そのユーザーの認証情報を使用することで実現される可能性があります。
    • アイデンティティ
    • 認証
  • 改ざん入力: アプリケーションに送信された入力の変更、またはアプリケーション コードを変更するための信頼境界の違反。 たとえば、SQL インジェクションを使用してデータベース テーブル内のデータを削除する攻撃者などです。
    • データ整合性
    • 検証
    • ブロックリスト/許可リスト
  • アクションの否認: 既に実行されているアクションを否定する機能と、証拠を収集して説明責任を推進するアプリケーションの能力。 たとえば、悪意のある管理者にトレースする機能のない重要なデータの削除などです。
    • 監査/ログ記録
    • 署名
  • 情報漏えい: 制限された情報へのアクセス権を取得します。 たとえば、攻撃者が制限されたファイルにアクセスする可能性があります。
    • 暗号化
    • データ窃盗
    • 中間者による通信傍受攻撃
  • サービス拒否: 悪意のあるアプリケーションの中断によってユーザー エクスペリエンスが低下します。 たとえば、Slowloris などの DDoS ボットネット攻撃です。
    • DDoS攻撃
    • ボットネット
    • CDN と WAF の機能
  • 特権の昇格: 承認の悪用による特権アプリケーション アクセスの取得。 たとえば、攻撃者が URL 文字列を操作して機密情報にアクセスしたとします。
    • リモート コード実行
    • 認証
    • 隔離

設計に関する推奨事項

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

  • すべてのアプリケーション サービス チームの一貫性を促進するために、セキュリティ軽減策を共通のエンジニアリング基準内に確実に取り込むには、意識的な取り組みを適用する必要があります。

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

ネットワーク侵入保護

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

設計に関する考慮事項

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

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

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

    • Azure Private Link/プライベート エンドポイントは、プライベート IP アドレスとプライベート ネットワーク接続を使用して、Azure PaaS リソースへの専用アクセスを提供します。
    • Virtual Network サービス エンドポイントは、選択したサブネットから選択した PaaS サービスへのサービス レベルのアクセスを提供します。
    • Virtual Network Injection は、App Service 環境を介した 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 パケットを使用してキャプチャします。

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

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

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

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

  • プライベート エンドポイントが利用できず、データ流出リスクが許容される場合は、仮想ネットワーク サービス エンドポイントを使用して、仮想ネットワーク内から 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 地域内の Key Vault に復元する必要があります。

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

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

  • 規制コントロールでは、サービス暗号化機能のためのカスタマー マネージド キーの使用が規定されている場合があります。

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

設計に関する推奨事項

  • 可能な場合は、データ保護にサービスマネージド キーを使用します。暗号化キーを管理し、キーのローテーションなどの操作タスクを処理する必要はありません。

    • 明確な規制要件がある場合にのみ、カスタマー マネージド キーを使用します。

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

    • Azure Key Vault をソフト削除と消去ポリシーを有効にしてプロビジョニングし、削除されたオブジェクトの保持保護を実現します。
    • HSM でサポートされる Azure Key Vault SKU は、アプリケーションの運用環境に使用します。

  • リージョンデプロイ スタンプごとに個別の Azure Key Vault インスタンスをデプロイし、ローカライズによる障害の分離とパフォーマンスの利点を提供し、1 つの 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 Policy 定義をデプロイして、より広範な Azure 資産内のすべてのアプリケーションで再利用できるようにすることを検討してください。 ランディング ゾーン環境では、Azure 資産全体にセキュリティ コンプライアンスを適用するために、より高い管理グループ スコープ内で特定の一元化されたセキュリティ ポリシーが既定で適用されます。 たとえば、VM 拡張機能を使用してソフトウェア構成を自動的にデプロイし、準拠しているベースライン VM 構成を適用するには、Azure ポリシーを適用する必要があります。

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

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

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

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

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

仮想マシンを使用する場合の IaaS 固有の考慮事項

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

設計に関する考慮事項

  • デプロイ後、イメージは自動的に更新されません。
  • 更新プログラムは、実行中の VM に自動的にインストールされません。
  • イメージと個々の仮想マシンは、通常、初期状態ではセキュリティが強化されていません。

設計に関する推奨事項

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

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

次のステップ

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

運用手順