IP ベースのアクセス制御リスト (ACL) とは

Azure でのネットワーク セキュリティの管理を簡単にするため、2018 年に Azure サービス タグが導入されました。 サービス タグは、特定の Azure サービスに関連付けられている IP アドレス プレフィックスのグループを表し、ネットワーク セキュリティ グループ (NSG)、Azure Firewall、ユーザー定義ルート (UDR) で使用できます。 サービス タグの目的は、IP ベースの ACL を簡単に有効にできるようにすることですが、それだけをセキュリティ対策として実装するべきではありません。

Azure でのサービス タグについて詳しくは、サービス タグに関する記事をご覧ください。

背景

標準的な手順としてお勧めするものの 1 つは、アクセス制御リスト (ACL) を使って、有害なトラフィックから環境を保護することです。 アクセス リストは、条件とアクションのステートメントです。 条件では、IP アドレスなど、照合するパターンを定義します。 アクションは、許可や拒否など、実行する必要がある想定される操作を示します。 これらの条件とアクションを、ポートと IP に基づいてネットワーク トラフィックに対して確立できます。 ポートと IP に基づく TCP (伝送制御プロトコル) の会話は、5 タプルで識別されます。

このタプルには 5 つの要素があります。

• プロトコル (TCP)

• ソース IP アドレス (パケットを送信した IP)

• ソース ポート (パケットの送信に使われたポート)

• ターゲット IP アドレス (パケットの送信先)

• ターゲット ポート

IP ACL を設定するときは、ネットワークの通過を許可する IP アドレスの一覧を設定して、他のすべてをブロックします。 さらに、IP アドレスだけでなく、ポートにもこれらのポリシーを適用します。

IP ベースの ACL は、ネットワーク デバイスからファイアウォールまで、ネットワークのさまざまなレベルで設定できます。 IP ACL は、サービス拒否攻撃のブロックや、トラフィックを受信できるアプリケーションとポートの定義など、ネットワーク セキュリティ リスクを軽減するのに役立ちます。 たとえば、Web サービスをセキュリティ保護するには、Web トラフィックのみを許可して他のすべてのトラフィックをブロックする ACL を作成できます。

Azure とサービス タグ

Azure 内の IP アドレスでは、セキュリティ脅威に対する追加の保護レイヤーを構築するため、既定で保護が有効になります。 これらの保護には、統合された DDoS 保護と、リソース公開キー基盤 (RPKI) の有効化などのエッジでの保護が含まれます。 RPKI は、暗号化の信頼を有効にすることで、インターネット ルーティング インフラストラクチャのセキュリティを強化するように設計されたフレームワークです。 RPKI は Microsoft ネットワークを保護し、他のユーザーがインターネット上で Microsoft の IP 空間の公開を試みないようにします。

多くのお客様は、防御戦略の一環としてサービス タグを有効にしています。 サービス タグは、IP 範囲によって Azure サービスを識別するラベルです。 サービス タグの値は、自動的に管理されるプレフィックスの一覧です。 自動管理により、個々の IP アドレスを手動で管理して追跡する必要性が減ります。 サービス タグの自動メンテナンスにより、サービスのオファリングが強化されて冗長性とセキュリティ機能の向上が提供されると、すぐにそのメリットが得られます。 サービス タグにより、必要な手動部分の数が減り、サービスのトラフィックが常に正確になります。 NSG または UDR の一部としてサービス タグを有効にし、送信を許可するトラフィックのサービス タグを指定すると、IP ベースの ACL が有効になります。

制限事項

IP ベースの ACL のみに頼った場合の課題の 1 つは、RPKI が実装されていない場合に IP アドレスを偽装できることです。 Azure では、IP スプーフィングを軽減するために、RPKI と DDoS 保護が自動的に適用されます。 IP スプーフィングは悪意のあるアクティビティのカテゴリであり、信頼できると考えていた IP が信頼すべき IP ではなくなることです。 IP アドレスを使って信頼できるソースのふりをすると、そのトラフィックはコンピューター、デバイス、またはネットワークにアクセスできるようになります。

既知の IP アドレスであっても、必ずしも安全または信頼できるとは限りません。 IP スプーフィングは、ネットワーク レイヤーだけでなく、アプリケーション内でも発生する可能性があります。 HTTP ヘッダーの脆弱性を利用して、ハッカーはセキュリティ イベントをもたらすペイロードを挿入できます。 検証のレイヤーは、ネットワークだけでなく、アプリケーション内からも発生する必要があります。 信頼の指針を構築したとしても、サイバー攻撃の高度化に対して検証は必要です。

今後の予定

すべてのサービスで、サービス タグにおける IP プレフィックスの役割と意味を文書化します。 サービスとそれが送信するトラフィックの性質を考慮しないで、サービス タグをただ使うのでは、トラフィックをセキュリティで保護するのに十分ではありません。

サービスの IP プレフィックスとサービス タグには、サービス自体より多くのトラフィックとユーザーが含まれる場合があります。 Azure サービスでお客様が制御可能な宛先が許可されている場合、お客様は同じ Azure サービスの他のユーザーによって制御されるトラフィックを誤って許可しています。 使用する各サービス タグの意味を理解することは、リスクを理解し、追加する必要のある保護レイヤーを特定するのに役立ちます。

IP アドレスだけに頼るのではなく、トラフィックの認証と認可を実装することが常にベスト プラクティスです。 クライアントが提供するヘッダーなどのデータを検証すると、スプーフィングに対する保護が一段階強化されます。 Azure Front Door (AFD) は、ヘッダーの評価による拡張保護を備えており、それがユーザーのアプリケーションと識別子に適合していることを確認します。 Azure Front Door の拡張保護について詳しくは、「Azure Front Door の配信元へのトラフィックをセキュリティで保護する」をご覧ください。

まとめ

サービス タグなどの IP ベースの ACL は、ネットワーク トラフィックを制限する優れたセキュリティ防御ですが、そのレイヤーだけで悪意のあるトラフィックを防いではなりません。 サービス タグに加えて、Private Link や仮想ネットワーク インジェクションなど、Azure で利用できるテクノロジを実装すると、セキュリティ態勢が向上します。 Private Link と仮想ネットワーク インジェクションについて詳しくは、Azure Private Link に関する記事と、「仮想ネットワークに専用の Azure サービスをデプロイする」をご覧ください。