Azure でのエンドポイント セキュリティのベスト プラクティス
"エンドポイント" は、外部エンティティが通信できるように、Web アプリケーションによって公開されるアドレスです。 エンドポイントとの悪意のある、または不注意による対話によって、アプリケーションのセキュリティどころかシステム全体さえ危険にさらされる可能性があります。 エンドポイントを保護する方法の 1 つは、それが受信するネットワーク トラフィックを対象に、規則セットの定義などフィルター コントロールを設けることです。 多層防御アプローチを使用すると、リスクをさらに軽減することができます。 主要なトラフィック コントロールが失敗した場合にエンドポイントを保護する補助コントロールを組み込みます。
この記事では、Azure のサービスと機能を使用して Web アプリケーションを保護する方法について説明します。 製品のドキュメントについては、「関連リンク」を参照してください。
重要なポイント
- Azure Front Door、Application Gateway、Azure Firewall、Azure DDoS Protection を使用して、すべてのパブリック エンドポイントを保護します。
- Web ワークロードを保護するには、Web アプリケーション ファイアウォール (WAF) を使用します。
- ワークロードの公開方法を保護し、使用されていない方法を制限します。
- DDoS 攻撃を軽減します。 停止するとビジネスが影響を受ける重要なワークロードには、標準的な保護を使用します。 また、もう 1 つの保護レイヤーとして CDN を検討します。
- 仮想マシンがインターネットに直接アクセスしないように、ポリシーを適用するためのログや監視を備えたプロセスと手順を開発します (プロキシやファイアウォールなど)。
- 自動化された限定的な CI/CD デプロイ プロセスを実装します。
パブリック エンドポイント
パブリック エンドポイントは、インターネット経由でトラフィックを受信します。 エンドポイントがあると、攻撃者はサービスに簡単にアクセスできるようになります。
サービス エンドポイントと Private Link を利用すると、PaaS エンドポイントへのアクセスが、承認された仮想ネットワークからのみに制限されるため、データの侵入リスクとそれに関連するアプリケーションの可用性に関連する影響を効果的に軽減できます。 サービス エンドポイントの場合、PaaS サービスへのサービス レベルのアクセスが提供されます。一方、Private Link の場合、特定の PaaS リソースへの直接アクセスを提供することで、(悪意のある管理者シナリオなどの) データ流出リスクを軽減します。
必要に応じて、サービス エンドポイントとプライベート リンクを構成してください。
このワークロードのすべてのパブリック エンドポイントは保護されていますか?
設計で最初に評価することは、パブリック エンドポイントがそもそも必要かどうかということです。 そうである場合は、これらのメカニズムを使用して保護します。
詳細については、「仮想ネットワーク サービス エンドポイント」および「Azure プライベート エンドポイントとは」を参照してください。
Web アプリケーション ファイアウォール (WAF)
WAF を使用すると、基本レベルのセキュリティが Web アプリケーションに提供されます。 WAF により多層防御の軽減策が追加されるため、WAF は組織がアプリケーション セキュリティに既に取り組んでいる場合に適しています。
WAF を使用すると、アプリケーションでよく見られるセキュリティ脆弱性を攻撃者が悪用するリスクが軽減されます。 WAF を使用すると、基本レベルのセキュリティが Web アプリケーションに提供されます。 攻撃者は (クライアント エンドポイントと同じように) 組織へのイングレス ポイントとして Web アプリケーションをターゲットにするため、この機能は重要な軽減策です。
外部のアプリケーション エンドポイントは、悪意によってアプリケーションがダウンする可能性を防ぐため、Slowloris のようなサービス拒否 (DoS) 攻撃からアプリレベルの悪用まで、一般的な攻撃ベクトルから保護する必要があります。 必要な保護 (Azure DDoS Protection) を実現するために、Azure Firewall、Application Gateway/Azure Front Door、WAF、DDoS ネットワーク保護などの Azure ネイティブ テクノロジを使用できます。
Azure Application Gateway には WAF 機能があり、Web トラフィックが検査されて、HTTP レイヤーで攻撃が検出されます。 それは、Secure Sockets Layer (SSL) の暗号化と解読を行うことができる、ロード バランサーであり、完全な HTTP(S) リバース プロキシです。
たとえば、ワークロードが Application Service Environment (ILB ASE) でホストされているとします。 API は内部的に統合され、外部のユーザーに公開されます。 この外部公開は、Application Gateway を使用して実現できます。 このサービスはロード バランサーです。 それによって要求が内部の API Management サービスに転送された後、ASE にデプロイされている API が使用されます。 セキュリティで保護された信頼できるアウトバウンド呼び出しのため、Application Gateway はポート 443 にも構成されます。
ヒント
前の例の設計に関する考慮事項については、「内部の API を外部ユーザーに公開する」を参照してください。
Azure Front Door と Azure Content Delivery Network (CDN) にも WAF の機能があります。
推奨アクション
Azure Front Door、Application Gateway、Azure Firewall、Azure DDoS Protection、サードパーティ ソリューションなど、適切なソリューションを使用してパブリック エンドポイントをすべて保護します。
詳細情報
Azure Firewall
インターネットや他の外部の場所からの、悪意がある可能性のあるトラフィックから、仮想ネットワーク全体を保護します。 受信トラフィックが検査され、通過することが許可された要求のみが渡されます。
一般的な設計では、アプリケーションの前面に DMZ または境界ネットワークを実装します。 DMZ は、ファイアウォールを備えた独立したサブネットです。
ヒント
設計に関する考慮事項については、「高可用性 NVA をデプロイする」を参照してください。
組み合わせアプローチ
さらに高いセキュリティが必要であり、仮想ネットワークに Web と Web 以外のワークロードが混在している場合は、Azure Firewall と Application Gateway の両方を使用します。 これら 2 つのサービスを連携させるには、いくつかの方法があります。
たとえば、エグレス トラフィックをフィルター処理するとします。 特定の Azure ストレージ アカウントへの接続は許可しますが、それ以外には許可しません。 完全修飾ドメイン名 (FQDN) ベースのフィルターが必要です。 この場合は、Azure Firewall と Application Gateway を並列に実行します。
もう 1 つの一般的な設計は、Azure Firewall ですべてのトラフィックを検査すると共に、WAF で Web トラフィックを保護し、さらに、アプリケーションがクライアントの送信元 IP アドレスを知る必要がある場合です。 この場合は、Application Gateway を Firewall の前に配置します。 逆に、トラフィックが Application Gateway に到達する前に、その検査とフィルター処理を行う場合は、WAF の前に Firewall を配置できます。
詳細については、「仮想ネットワークの Azure Firewall と Application Gateway」を参照してください。
さまざまなクラウド リソースが動的に開始および停止するネットワークでは、簡潔なファイアウォール規則を作成することは困難です。 Microsoft Defender for Cloud を使用して構成の誤りのリスクを検出します。
認証
インターネットに接続するサービスでは、セキュリティで保護されないレガシ プロトコルを無効にします。 レガシ認証方法は、クラウドでホストされるサービスにとって最も脅威となる攻撃ベクトルの 1 つです。 この方法ではパスワード以外の要素がサポートされておらず、パスワード スプレー、辞書、ブルート フォースなどの攻撃の対象となります。
DDoS 攻撃を軽減する
分散型サービス拒否 (DDoS) 攻撃を受けたサーバーは、偽のトラフィックによって過負荷になります。 DDoS 攻撃は一般的であり、有害である場合があります。 攻撃により、アクセスが完全にブロックされたり、サービスが停止させられる可能性があります。 アプリケーションでダウンタイムが発生すると、業務に悪影響を及ぼす可能性があるため、ビジネスに不可欠なすべての Web アプリケーションやサービスについて、既定の防御策以上の DDoS 軽減策を講じてください。
ダウンタイムがビジネスに悪影響を与えるサービスについては、事前保護を採用することをお勧めします。
DDoS 保護をどのように実装しますか?
次にいくつかの考慮事項を示します。
- ワークロードが実行されるインフラストラクチャ レベルでの DDoS 保護。 Azure インフラストラクチャには、DDoS 攻撃に対する防御が組み込みされています。
- ネットワーク (第 3 層) レイヤーでの DDoS 保護。 Azure では、仮想ネットワークにプロビジョニングされたサービスに対して追加の保護が提供されます。
- キャッシュによる DDoS 保護。 コンテンツ配信ネットワーク (CDN) では、別の保護レイヤーを追加できます。 DDoS 攻撃の際は、トラフィックが CDN によってインターセプトされ、バックエンド サーバーに到達するのを阻止されます。 Azure CDN はネイティブに保護されています。 Azure では、独自の DDoS 軽減プラットフォームで保護されている一般的な CDN もサポートされます。
- 高度な DDoS 保護。 セキュリティ ベースラインでは、機械学習を使用して異常なトラフィックを検出し、サービスの低下が発生する前にアプリケーションをプロアクティブに保護する監視手法を備えた機能を検討してください。
Azure DDoS Protection サービスの詳細については、 Azure DDoS Protection のドキュメントを参照してください。
推奨されるアクション
DDoS 攻撃の影響を受けやすい重要なワークロードを特定し、すべてのビジネス クリティカルな Web アプリケーションとサービスに対して分散型サービス拒否 (DDoS) の軽減策を有効にします。
詳細情報
DDoS 保護の使用方法を示す参照アーキテクチャの一覧については、Azure DDoS Protection の参照アーキテクチャに関する記事をご覧ください。
DevOps を導入する
開発者は、アプリ サーバーにコードを直接公開しないようにする必要があります。
このワークロードでコードを公開するための CI/CD プロセスが組織にありますか?
アプリケーション用に継続的インテグレーション/継続的デリバリー (CI/CD) のライフサイクルを実装します。 自動化された限定的な CI/CD デプロイ プロセスを支援するプロセスとツールを用意します。
公開方法はどのようにセキュリティで保護されていますか?
FTP や Web 配置など、複数の方法でアプリのコンテンツを公開できるアプリケーション リソースでは、使用されていないエンドポイントを無効にする必要があります。 Azure Web Apps の場合は、SCM が推奨されるエンドポイントです。 機密性の高いユース ケースについては、ネットワーク制限により個別に保護できます。
次のステップ
関連リンク
メインの記事に戻る: ネットワークのセキュリティ