次の方法で共有

Azure で運用可能なセキュリティに関するベスト プラクティス

  • [アーティクル]

この記事では、Azure 内のデータ、アプリケーション、その他の資産を保護するための運用可能な一連のベスト プラクティスについて説明します。

これらのベスト プラクティスは、集約された意見に基づくものであり、Azure プラットフォームの最新の機能に対応しています。 人の考えやテクノロジは時間の経過と共に変化するため、この記事は、それらの変化が反映されるように定期的に更新されます。

強力で運用可能なセキュリティに関するプラクティスの定義とデプロイ

Azure で運用可能なセキュリティとは、ユーザーが Azure 内のデータ、アプリケーション、その他の資産を保護するために使用できる、サービス、コントロール、機能を指します。 Azure で運用可能なセキュリティは、セキュリティ開発ライフサイクル (SDL)、Microsoft セキュリティ レスポンス センター プログラム、サイバー セキュリティの脅威状況に対する深い認識など、Microsoft に固有の機能から得られた知識が組み込まれたフレームワークを基盤としています。

ユーザーに多要素認証を適用する

すべてのユーザーに対して 2 段階認証を要求することをお勧めします。 これには、組織内の管理者およびアカウントが侵害された場合に重大な影響を及ぼす可能性のあるその他のユーザー (財務担当者など) が含まれます。

2 段階認証を要求するオプションは複数あります。 最適なオプションは、目的、実行している Microsoft Entra エディション、ライセンス プログラムによって異なります。 最適なオプションを判断するには、「ユーザーに 2 段階認証を要求する方法」を参照してください。 ライセンスと価格の詳細については、Microsoft Entra ID および Microsoft Entra 多要素認証の価格に関するページを参照してください。

2 段階認証を有効にするオプションと利点を次に示します。

オプション 1: Microsoft Entra セキュリティの既定値群を使用して、すべてのユーザーとログイン方法に対して MFA を有効にします 利点: このオプションを使用すると、環境内のすべてのユーザーに対して、次のような厳しいポリシーで MFA を簡単かつ迅速に適用できます。

  • 管理者アカウントと管理ログオン メカニズムにチャレンジします
  • すべてのユーザーに Microsoft Authenticator 経由の MFA チャレンジを要求します
  • レガシ認証プロトコルを制限します。

この方法はすべてのライセンス レベルで使用できますが、既存の条件付きアクセス ポリシーと併用することはできません。 詳細については、Microsoft Entra のセキュリティの既定値群に関するページを参照してください。

オプション 2: ユーザーの状態を変更することで多要素認証を有効にします。
利点:2 段階認証を要求するための従来の方法です。 これは、クラウド内の Microsoft Entra 多要素認証と Azure Multi-Factor Authentication Server の両方で機能します。 この方法を使用すると、ユーザーはサインインするたびに 2 段階認証を実行するよう求められ、条件付きアクセス ポリシーがオーバーライドされます。

多要素認証をどこで有効にする必要があるかを判定するには、組織に適している Microsoft Entra 多要素認証のバージョンに関するページを参照してください。

オプション 3: 条件付きアクセス ポリシーを使用して多要素認証を有効にします。 利点:このオプションでは、条件付きアクセスを使用して特定の条件下で 2 段階認証を要求できます。 特定の条件としては、異なる場所、信頼されていないデバイス、または危険と見なされるアプリケーションからのユーザーのサインインを指定できます。 2 段階認証を要求する特定の条件を定義すると、要求のメッセージがユーザーに繰り返し表示されないようにすることができます。このようなメッセージは、不快なユーザー エクスペリエンスとなり得ます。

これは、ユーザーの 2 段階認証を有効にするうえで最も柔軟性の高い手段です。 条件付きアクセス ポリシーを有効にする方法は、クラウド内の Microsoft Entra 多要素認証に対してのみ機能します。これは、Microsoft Entra ID のプレミアム機能です。 この方法の詳細については、クラウド ベースの Microsoft Entra 多要素認証のデプロイに関するページを参照してください。

オプション 4: リスクベースの条件付きアクセス ポリシーを評価することにより、条件付きアクセス ポリシーを使用した多要素認証を有効にします。
利点:このオプションの利点は次のとおりです。

  • 組織の ID に影響する潜在的な脆弱性を検出します。
  • 組織の ID に関連する検出された疑わしいアクションに対する自動応答を構成します。
  • 疑わしいインシデントを調査し、適切なアクションを実行して解決します。

この方法では、Microsoft Entra ID Protection のリスク評価を使用して、すべてのクラウド アプリケーションのユーザーおよびサインインのリスクに基づいて 2 段階認証が要求されるかどうかを判断します。 この方法を使用するには、Microsoft Entra ID P2 ライセンスが必要です。 この方法の詳細については、Microsoft Entra ID Protection に関するページを参照してください。

Note

オプション 2 (ユーザーの状態を変更することで多要素認証を有効にする) では、条件付きアクセス ポリシーをオーバーライドします。 オプション 3 および 4 では条件付きアクセス ポリシーを使用するため、オプション 2 をそれらと共に使用することはできません。

2 段階認証などの新しい ID 保護レイヤーを追加しない組織は、資格情報盗用攻撃を受けやすくなります。 資格情報盗用攻撃はデータの侵害につながる可能性があります。

ユーザー パスワードの管理と監視

次の表に、ユーザー パスワードの管理に関連するベスト プラクティスをいくつか示します。

ベスト プラクティス: クラウドで適切なレベルのパスワード保護があることを確認します。
詳細: Microsoft ID プラットフォーム (Microsoft Entra ID、Active Directory、Microsoft アカウント) のユーザーを対象とした Microsoft のパスワードのガイダンスにあるガイダンスに従います。

ベスト プラクティス: ユーザー アカウントに関連する疑わしい動作を監視します。
詳細: 危険な状態のユーザーと危険なサインインを、Microsoft Entra セキュリティ レポートを使用して監視します。

ベスト プラクティス: 危険度の高いパスワードを自動的に検出して修復します。
詳細: Microsoft Entra ID Protection は、Microsoft Entra ID P2 エディションの機能であり、次のことを行えます。

  • 組織の ID に影響する潜在的な脆弱性を検出する
  • 組織の ID に関連する検出された疑わしいアクションに対する自動応答を構成する
  • 疑わしいインシデントを調査し、適切なアクションを実行して解決する

Microsoft からインシデント通知を受け取る

セキュリティ運用チームが Microsoft からの Azure インシデント通知を必ず受け取るようにしてください。 セキュリティ チームはインシデント通知により侵害された Azure リソースの存在を知ることができるため、潜在的なセキュリティ リスクに素早く対応して修復することができます。

Azure の登録ポータルで、管理者の連絡先情報にセキュリティ操作を通知する詳細を確実に含めることができます。 連絡先情報は、電子メール アドレスと電話番号です。

Azure サブスクリプションを管理グループに整理する

組織に多数のサブスクリプションがある場合は、これらのサブスクリプションのアクセス、ポリシー、およびコンプライアンスを効率的に管理する方法が必要になることがあります。 Azure 管理グループでは、サブスクリプションを上回る範囲のレベルが提供されます。 管理グループと呼ばれるコンテナーにサブスクリプションを整理して、管理グループに管理条件を適用できます。 管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。

管理グループとサブスクリプションの柔軟な構造をディレクトリに構築することができます。 各ディレクトリには、ルート管理グループと呼ばれる 1 つの最上位管理グループがあります。 このルート管理グループは階層に組み込まれており、すべての管理グループとサブスクリプションはルート管理グループにまとめられます。 ルート管理グループを使用すると、グローバル ポリシーと Azure ロールの割り当てをディレクトリ レベルで適用できます。

管理グループの使用に関するベスト プラクティスを次にいくつか示します。

ベスト プラクティス: ポリシーやアクセス許可などのガバナンス要素が追加されたときに、新しいサブスクリプションが確実に適用されるようにします。
詳細: ルート管理グループを使用して、すべての Azure 資産に適用される企業全体のセキュリティ要素を割り当てます。 要素の例としては、ポリシーやアクセス許可があります。

ベスト プラクティス: 各セグメント内における制御とポリシーの一貫性に関するポイントを提供するため、最上位レベルの管理グループをセグメント化戦略と合わせます。
詳細: ルート管理グループの下のセグメントごとに 1 つの管理グループを作成します。 ルートの下に他の管理グループは作成しないでください。

ベスト プラクティス: 運用とセキュリティの両方を妨げる混乱を回避するため、管理グループの深さを制限します。
詳細: 階層は、ルートを含めて 3 レベルまでに制限します。

ベスト プラクティス: ルート管理グループを使用して企業全体に適用する項目を慎重に選択します。
詳細: ルート管理グループ要素がすべてのリソースにわたって適用される明確な必要性があること、そして影響度が低いことを確実にします。

適切な候補は次のとおりです。

  • 明確な事業影響のある規制要件 (たとえば、データ主権に関連する制限)
  • 慎重にレビューされた audit 効果のあるポリシーや Azure RBAC アクセス許可割り当てなど、運用に関する潜在的なマイナスの影響がほぼない要件

ベスト プラクティス: ルート管理グループに対する企業全体の変更すべてを、適用する前に慎重に計画してテストします (ポリシー、Azure RBAC モデルなど)。
詳細: ルート管理グループ内の変更は、Azure 上のすべてのリソースに影響する可能性があります。 企業全体にわたる一貫性を確保する強力な方法が提供される一方で、エラーや不適切な使用によって実稼働運用にマイナスの影響が発生する可能性があります。 テスト ラボまたは運用パイロットで、ルート管理グループに対するすべての変更をテストします。

ブループリントの使用による環境の作成の簡素化

Azure Blueprints サービスによってクラウド アーキテクトや中央の情報技術グループは、組織の標準、パターン、要件を実装および順守した反復可能な一連の Azure リソースを定義できます。 Azure Blueprint を使用すると、開発チームは一連の組み込みコンポーネントを使用し、組織のコンプライアンスに従ってこれらの環境を作成しているという自信を持って、新しい環境を迅速に構築して立ち上げることができます。

予期しない動作変化の記憶域サービスを監視します。

クラウド環境でホストされる分散型アプリケーションの問題の診断およびトラブルシューティングは、従来の環境よりも複雑になる可能性があります。 アプリケーションは、PaaS や IaaS インフラストラクチャ、オンプレミス、モバイル デバイス、これらの環境を組み合わせたものにデプロイできます。 アプリケーションのネットワーク トラフィックがパブリックとプライベート ネットワークを走査可能性があり、アプリケーションが複数の記憶域テクノロジを使用して可能性があります。

アプリケーションが動作 (低速の応答時間) などの予期しない変更を使用するストレージ サービスを継続的に監視する必要があります。 詳細なデータを収集して、問題を徹底的に分析するログを使用します。 監視とログの両方から得られた診断情報を基に、アプリケーションで発生した問題の根本原因を特定できます。 そして、問題をトラブルシューティングし、問題を修復する適切な手順を決定できます。

Azure Storage Analytics では、ログが記録され、Azure ストレージ アカウントのメトリック データを得ることができます。 このデータを使用して、要求のトレース、使用傾向の分析、ストレージ アカウントの問題の診断をすることをお勧めします。

脅威の防止、検出、および対応

Microsoft Defender for Cloud を使用すると、Azure リソースのセキュリティの可視性を高める (および制御する) ことで、脅威の防止、検出、対応を行うことができます。 これにより、Azure サブスクリプション全体に統合セキュリティの監視とポリシーの管理を提供し、気付かない可能性がある脅威を検出し、さまざまなセキュリティ ソリューションと連動します。

Free レベルの Defender for Cloud では、Azure 内のリソースと、Azure 外部の Arc 対応リソースに対して限定的なセキュリティが提供されます。 拡張セキュリティ機能では、これらの機能を拡張して、脅威と脆弱性の管理と規制コンプライアンス レポートが追加されます。 Defender for Cloud のプランを使用すると、セキュリティの脆弱性を検出して修正し、悪意のあるアクティビティをブロックするためにアクセスとアプリケーション制御を適用し、分析とインテリジェンスを使用して脅威を検出し、攻撃を受けたときにすばやく対応できます。 Defender for Cloud Standard は、最初の 30 日間無料で試用できます。 Defender for Cloud で Azure サブスクリプションの拡張セキュリティ機能を有効にすることをお勧めします。

Defender for Cloud を使用して、独自のデータ センター、Azure、およびその他のクラウド内でお使いのすべてのリソースのセキュリティ状態の一元的なビューを実現できます。 セキュリティの制御が適切かつ正しく構成されているかを一目で確認し、注意が必要なリソースを素早く特定できます。

Defender for Cloud は、包括的なエンドポイント検出と対応 (EDR) 機能を提供する Microsoft Defender for Endpoint とも統合されます。 Microsoft Defender for Endpoint を統合することで、異常を発見し、脆弱性を検出できます。 また、Defender for Cloud によって監視されているサーバー エンドポイントに対する高度な攻撃を検出して対応することもできます。

ほぼすべてのエンタープライズ組織には、多様なシグナル収集デバイスからログ情報を統合することで新たな脅威を識別することに役立つ、セキュリティ情報およびイベント管理 (SIEM) システムがあります。 ログはその後データ分析システムにより分析され、すべてのログ収集および分析ソリューションで避けることのできないノイズから、"興味を引く" ものが何であるかを識別するのに役立ちます。

Microsoft Sentinel は、スケーラブルでクラウドネイティブのセキュリティ情報イベント管理 (SIEM) およびセキュリティ オーケストレーション自動応答 (SOAR) ソリューションです。 Microsoft Sentinel では、アラートの検出、脅威の可視性、予防的な捜索、および脅威への自動対応により、インテリジェントなセキュリティ分析と脅威インテリジェンスが提供されます。

脅威に対する保護、検出、および対応に関するベスト プラクティスを次にいくつか示します。

ベスト プラクティス: クラウドベースの SIEM を使用して SIEM ソリューションの速度とスケーラビリティを向上させます。
詳細: Microsoft Sentinel の特徴と機能を調査して、現在オンプレミスで使用しているものの機能と比較します。 Microsoft Sentinel が組織の SIEM 要件を満たしている場合は、採用を検討してください。

ベスト プラクティス: 調査に優先順位を付けることができるよう、最も重大なセキュリティの脆弱性を見つけます。
詳細: Azure のセキュリティ スコアを調べ、Microsoft Defender for Cloud に組み込まれた Azure ポリシーとイニシアティブの結果として生じる推奨事項を確認します。 これらの推奨事項は、セキュリティ更新プログラム、エンドポイント保護、暗号化、セキュリティ構成、WAF の欠落、インターネットに接続された VM など、最大の危険への対応に役立ちます。

Center for Internet Security (CIS) コントロールを基にしたセキュリティ スコアにより、組織の Azure セキュリティを外部ソースに対してベンチマークすることができます。 外部検証は、チームのセキュリティ戦略を検証し強化することに役立ちます。

ベスト プラクティス: マシン、ネットワーク、ストレージおよびデータ サービス、アプリケーションのセキュリティ体制を監視して、潜在的なセキュリティの問題を検出し優先順位を付けます。
詳細: 最も優先順位が高い項目から、Defender for Cloud のセキュリティに関する推奨事項に従います。

ベスト プラクティス: Defender for Cloud のアラートをセキュリティ情報とイベント管理 (SIEM) ソリューションに統合します。
詳細: SIEM を使用している組織のほどんとは、アナリストの応答を必要とするセキュリティ アラートに関する中央情報センターとして SIEM を使用しています。 Defender for Cloud によって生成された処理済みイベントは、Azure Monitor で利用可能なログの 1 つである Azure アクティビティ ログに発行されます。 Azure Monitor では、任意の監視データを SIEM ツールにルーティングするための統合パイプラインが提供されています。 手順については、「SIEM、SOAR、または IT Service Management ソリューションへのアラートのストリーミング」を参照してください。 Microsoft Sentinel を使用している場合は、Microsoft Defender for Cloud の接続に関する記事を参照してください。

ベスト プラクティス: Azure ログを SIEM に統合します。
詳細: データの収集とエクスポートに Azure Monitor を使用します。 この方法はセキュリティ インシデントの調査を可能にするために重要であり、オンライン ログのリテンションは制限されます。 Microsoft Sentinel を使用している場合は、データ ソースの接続に関する記事を参照してください。

ベスト プラクティス: Endpoint Detection and Response (EDR) 機能を攻撃の調査に統合することで、調査と検出プロセスを高速化し、誤検出を減らします。
詳細: Defender for Cloud のセキュリティ ポリシーを使用して Microsoft Defender for Endpoint の統合を有効にします。 脅威の検出とインシデント対応に Microsoft Sentinel を使用することを検討してください。

エンド ツー エンドのシナリオ ベースのネットワーク監視

お客様は、仮想ネットワーク、ExpressRoute、Application Gateway、ロード バランサーなどのネットワーク リソースを組み合わせて Azure にエンド ツー エンド ネットワークを構築します。 各ネットワーク リソースは監視することができます。

Azure Network Watcher は地域サービスです。 この診断ツールおよび視覚化ツールを使用して、ネットワーク シナリオ レベルで Azure 内と Azure 間の状態を監視して診断します。

ネットワークの監視と使用可能なツールのベスト プラクティスを次に示します。

ベスト プラクティス: パケット キャプチャを使ってリモート ネットワーク監視を自動化する。
詳細: Network Watcher を使用して、VM にログインすることなくネットワークの問題を監視して診断します。 アラートの設定によりパケット キャプチャをトリガーし、パフォーマンスに関する情報をパケット レベルでリアルタイムに確認可能です。 問題が起きた場合には、詳細に調査してより適切に診断できます。

ベスト プラクティス: フロー ログを使用して、ネットワーク トラフィックに関する分析情報を得る。
詳細: ネットワーク セキュリティ グループのフロー ログを使うと、ネットワーク トラフィックのパターンをより深く把握できます。 フロー ログの情報をもとに、コンプライアンスに関するデータを収集し、ネットワークのセキュリティ プロファイルを監査、監視できます。

ベスト プラクティス: VPN 接続の問題を診断する。
詳細: Network Watcher を使用して、VPN Gateway と接続に関する最も一般的な問題を診断します。 問題を識別するだけでなく、詳細なログを使用して、詳しい調査を行うこともできます。

実証済みの DevOps ツールによるセキュリティ保護されたデプロイ

次の DevOps のベスト プラクティスを使用して、エンタープライズとチームが、生産性と効率性があることを確認します。

ベスト プラクティス: サービスのビルドとデプロイを自動化する。
詳細: コードとしてのインフラストラクチャは、モジュール式インフラストラクチャの構築と管理に関連する IT 担当者の日常作業の負担を軽減する、一連の技法とプラクティスです。 これにより、ソフトウェア開発者がアプリケーション コードを構築し保守するように、IT 担当者は最新のサーバー環境を構築、維持できます。

Azure Resource Manager を使用して、宣言型のテンプレートを使ってアプリケーションをプロビジョニングすることができます。 1 つのテンプレートで、複数のサービスをその依存関係と共にデプロイできます。 アプリケーション ライフサイクルの各ステージで、同じテンプレートを使用してアプリケーションを繰り返しデプロイします。

ベスト プラクティス: Azure Web アプリまたはクラウド サービスに自動的にビルドし、デプロイする。
詳細: Azure DevOps Projects を Azure Web アプリまたはクラウド サービスに自動的にビルドしてデプロイするように構成できます。 コードをチェックインするたびに、Azure DevOps により、Azure へビルドが実行され、バイナリが自動的にデプロイされます。 パッケージのビルド プロセスは、Visual Studio の Package コマンドに相当し、発行手順は Visual Studio の Publish コマンドに相当します。

ベスト プラクティス: リリース管理を自動化します。
詳細: Azure Pipelines は、複数の段階に分かれたデプロイを自動化し、リリース プロセスを管理するためのソリューションです。 継続的で管理されたデプロイメント パイプラインを作成し、すばやく、簡単に、頻繁にリリースできます。 Azure Pipelines を使用すると、リリース プロセスを自動化し、承認ワークフローを事前定義できます。 オンプレミスまたはクラウドに展開し、必要に応じて拡張、カスタマイズできます。

ベスト プラクティス: アプリを起動する前または更新プログラムを運用環境にデプロイする前に、パフォーマンスを確認する。
詳細: 次の目的で、クラウドベースのロード テストを実行します。

  • アプリのパフォーマンスの問題を見つけます。
  • デプロイの品質を向上します。
  • アプリが常に使用可能であることを確認します。
  • アプリが、次の立ち上げ、またはマーケティング キャンペーン時のトラフィックに対応できることを確認します。

Apache JMeter はコミュニティの強力な支持を受けている、無料で人気のオープン ソース ツールです。

ベスト プラクティス: アプリケーションのパフォーマンスを監視する。
詳細: Azure Application Insights は、複数のプラットフォームで使用できる Web 開発者向けの拡張可能なアプリケーション パフォーマンス管理 (APM) サービスです。 Application Insights を使用して、実行中の Web アプリケーションを監視します。 パフォーマンスに異常があると、自動的に検出されます。 組み込まれている分析ツールを使えば、問題を診断し、ユーザーがアプリを使用して実行している操作を把握できます。 Application Insights は、パフォーマンスやユーザビリティを継続的に向上させるうえで役立つように設計されています。

DDoS に対する被害軽減と保護

分散型サービス拒否 (DDoS) は、アプリケーションのリソースを枯渇させようとする攻撃の種類です。 目的は、正当な要求を処理するアプリケーションの可用性と能力に影響を与えることです。 これらの攻撃は、いっそう高度なものになり、規模と影響も大きくなっています。 この攻撃は、インターネット経由で一般に到達可能なすべてのエンドポイントで実行できます。

DDoS に対する回復性を設計しビルドするときは、さまざまな障害モードに対応した計画と設計が必要です。 Azure の DDoS 回復性のサービスをビルドするためのベスト プラクティスを次に示します。

ベスト プラクティス: 設計と実装から、デプロイと運用まで、アプリケーションのライフ サイクル全体を通して、セキュリティを優先する必要があります。 アプリケーションには、比較的少量の要求によって大量のリソースを使用し、結果としてサービスを停止させるような、バグが含まれる可能性があります。
詳細: Microsoft Azure で実行されるサービスを保護するには、お客様は、自分のアプリケーションのアーキテクチャをよく理解し、ソフトウェア品質の 5 つの重要な要素に注目する必要があります。 お客様は、標準的なトラフィックの量、アプリケーションと他のアプリケーションの間の接続モデル、パブリック インターネットに公開されるサービス エンドポイントについて知っておく必要があります。

アプリケーション自体を対象とするサービス拒否攻撃に対処するのに十分な回復力をアプリケーションに持たせることが、最も重要です。 Azure プラットフォームには、セキュリティ開発ライフサイクル (Security Development Lifecycle: SDL) からセキュリティとプライバシーが組み込まれるようになっています。 SDL は、すべての開発段階でセキュリティに対処し、Azure がいっそう安全になるように継続的に更新されることを保証します。

ベスト プラクティス: 水平方向にスケーリングするようにアプリケーションを設計し、増加した負荷の需要を満たす (特に、DDoS 攻撃の場合)。 アプリケーションがサービスの 1 つのインスタンスに依存する場合は、単一障害点が発生します。 複数のインスタンスをプロビジョニングすると、システムの回復力と拡張性が高まります。
詳細: Azure App Service の場合は、複数のインスタンスを提供する App Service プランを選択してください。

Azure Cloud Services の場合は、複数インスタンスを使用するように各ロールを構成してください。

Azure Virtual Machines の場合は、VM アーキテクチャに 1 つ以上の VM が含まれていることと、可用性セットに各 VM が含まれていることを確認してください。 自動スケーリング機能には Virtual Machine Scale Sets を使うことをお勧めします。

ベスト プラクティス: アプリケーションのセキュリティ防御を多層化すると、攻撃が成功する可能性が減少します。 Azure プラットフォームの組み込み機能を使って、アプリケーションのセキュリティ保護設計を実装します。
詳細: 攻撃のリスクは、アプリケーションの規模 (攻撃対象領域) と共に大きくなります。 公開されている IP アドレス空間を承認リストを使用して閉鎖し、ロード バランサー (Azure Load Balancer と Azure Application Gateway) を用いて不要にリスニングしているポートを閉じることで、攻撃対象領域を減らすことができます。

ネットワーク セキュリティ グループも、攻撃対象領域を軽減する 1 つの手段です。 サービス タグおよびアプリケーション セキュリティ グループを使用して、セキュリティ規則作成の複雑さを軽減し、アプリケーションの構造の自然な延長としてネットワーク セキュリティを構成することができます。

お客様は、可能な限り、仮想ネットワークに Azure サービスをデプロイする必要があります。 このプラクティスを使用すると、サービス リソースはプライベート IP アドレスを通して通信できます。 仮想ネットワークからの Azure サービス トラフィックは、パブリック IP アドレスを発信元 IP アドレスとして既定で使用します。

サービス エンドポイントを使用すると、サービス トラフィックは、仮想ネットワークから Azure サービスにアクセスするときに、仮想ネットワークのプライベート アドレスを発信元 IP アドレスとして使用するように切り替わります。

Azure 内のリソースと供に、お客様のオンプレミスのリソースが攻撃されることがよくあります。 オンプレミスの環境を Azure に接続している場合は、オンプレミスのリソースのパブリック インターネットへの露出を最小限にします。

Azure には、ネットワーク攻撃からの保護を提供する 2 つの DDoS サービス オファリングがあります。

  • 基本保護は、追加コストなしに、既定で Azure に統合されます。 グローバルにデプロイされる Azure ネットワークのスケールと容量が、常時有効なトラフィック監視とリアルタイムのリスク軽減によって、一般的なネットワーク層攻撃からの保護を提供します。 基本保護では、ユーザーによる構成やアプリケーションの変更は必要なく、Azure DNS などの PaaS サービスを含むすべての Azure サービスを保護できます。
  • 標準保護は、ネットワーク攻撃に対する高度な DDoS 軽減機能を提供します。 この機能は、お客様固有の Azure リソースを保護するために自動的に調整されます。 保護は、仮想ネットワークの作成時に簡単に有効にできます。 作成の後で行うこともでき、アプリケーションまたはリソースを変更する必要はありません。

Azure Policy の有効化

Azure Policy は、ポリシーの作成、割り当て、管理に使用する Azure のサービスです。 これらのポリシーにより、リソースにルールと効果が適用されて、それらのリソースが会社の標準とサービス レベル アグリーメントに準拠した状態に保たれます。 Azure Policy では、割り当て済みのポリシーでリソースの非準拠を評価することによって、このニーズが満たされます。

Azure Policy を有効にして、組織の明文化されたポリシーを監視し実施します。 これにより、ハイブリッド クラウド ワークロードのセキュリティ ポリシーを一元的に管理することで、会社や規制のセキュリティ要件に確実に準拠できます。 コンプライアンスを強制するポリシーの作成と管理方法について確認してください。 ポリシーの要素の概要については、「Azure Policy の定義の構造」を参照してください。

Azure Policy の採用後に従うセキュリティのベストプラクティスを次にいくつか示します。

ベスト プラクティス: ポリシーにより、いくつかの種類の効果をサポートします。 これらについては、「Azure Policy の定義の構造」で確認できます。 deny 効果と remediate 効果によってビジネス業務にマイナスの影響がある可能性があるため、audit 効果から開始して、ポリシーからのマイナスの影響のリスクを抑えます。
詳細: audit モードでポリシーのデプロイを開始し、その後 deny または remediate に進みます。 deny または remediate に移る前に、audit 効果の結果をテストしレビューします。

詳細については、「コンプライアンスを強制するポリシーの作成と管理」を参照してください。

ベスト プラクティス: ポリシー違反の監視を担当するロールを特定し、適切な修復アクションが確実に迅速に行われるようにします。
詳細: 割り当てられたロールに、Azure portal またはコマンド ラインを使用してコンプライアンスを監視させます。

ベスト プラクティス: Azure Policy は、組織の明文化されたポリシーを技術的に表したものです。 混乱を減らし、一貫性を高めるため、すべての Azure Policy 定義を組織のポリシーにマッピングします。
詳細: ポリシーの定義内または イニシアティブ定義の説明内に組織のポリシーへの参照を追加することにより、組織のドキュメント内または Azure Policy の定義自体にマッピングをドキュメント化します。

Microsoft Entra リスク レポートを監視する

ほとんどのセキュリティ侵害は、攻撃者がユーザーの ID を盗むことにより環境にアクセスできるようになると発生します。 侵害された ID を検出するのは簡単な作業ではありません。 Microsoft Entra ID では、アダプティブ機械学習アルゴリズムとヒューリスティックを使用して、ユーザー アカウントに関連する疑わしいアクションを検出します。 検出された疑わしいアクションはそれぞれ、リスク検出と呼ばれるレコードに格納されます。 リスク検出は、Microsoft Entra のセキュリティ レポートに記録されます。 詳細については、危険な状態のユーザー セキュリティ レポートに関する記事、およびリスクの高いサインイン セキュリティ レポートに関する記事をご覧ください。

次のステップ

Azure を使用してクラウド ソリューションを設計、デプロイ、管理するときに使用するセキュリティのベスト プラクティスの詳細については、「Azure セキュリティのベスト プラクティスとパターン」を参照してください。

Azure のセキュリティとそれに関連する Microsoft サービスの一般情報については、以下のリソースを参照してください。