😎

[Azure] ネットワーク セキュリティサービスについて

2023/01/09に公開

学習資材

https://learn.microsoft.com/ja-jp/training/modules/design-implement-network-security-monitoring/

Azure DDos Protection

Basicはデフォルトで有効になっているが、Standardにすることで、仮想ネットワーク内に作成されるリソースのパブリックIPに対して追加保護が可能になる。
レイヤー7のアプリケーション層への保護としては、Azure WAFが存在する。
Azure WAFだけだど、レイヤー3・4へのDDoSがカバーしきれないため、セキュリティ向上としてはStandardもあったほうがより良くなる。
DDoSは
レイヤーに跨って行われる攻撃のようですね。

Web アプリケーション ファイアウォールを構成しても、帯域幅消費型攻撃や状態枯渇攻撃を受ける可能性があります。 したがって、WAF 仮想ネットワーク上で DDoS Protection Standard を有効にして、帯域幅消費型攻撃やプロトコル攻撃に対する保護を強化することを強くお勧めします。

帯域幅消費型攻撃や状態枯渇攻撃がレイヤー3・4への攻撃となるわけですね。

例えば、帯域幅消費型攻撃は以下のような攻撃である。

これらの攻撃は、膨大な量の一見正当なトラフィックでネットワーク層をあふれさせます。

Azure DDos Protection Basicについて

ずっと気になっていた、BasicがデフォルトでON・OFFなのか問題。意外にも記載があった。
結論から言うと、既定でAzureプラットフォームに組み込まれているとのこと。実際にユーザがアクセスできるのは、Standardを使う時の設定らしいね。

Basic DDoS 保護は、追加コストなしに、既定で Azure プラットフォームに統合されています。

https://learn.microsoft.com/ja-jp/training/modules/introduction-to-azure-virtual-networks/

Azure DDos Protection Standardについて

Vnet内リソースのIPアドレスに対して保護ポリシーを追加することができる。現状は、App Serviceには非対応であることに注意

Azure Firewall

  • ルールの優先度の付け方について
    優先順位を最初から連番で付けてしまうのではなく、100刻みに付けておくのがベストプラクティスらしい。仮にルールを追加する場合に、柔軟に対応することを目的としている。
    なお優先順位は、100~65000の間でに任意で付けることが可能である。

  • ルールの種類について
    DNATとネットワーク、アプリケーションの3種類が存在する。
    DNATでは、インターネットからの通信を内部アドレスに変換するためのルールを定義する。

    例えば、インターネットからFirewallのパブリックIPでSSHすると、DNATルールによって指定のVMにログインができる・・・といった使い方になる。

また、ネットワークとアプリケーションの違いとしては、以下の通りである。

ネットワーク アプリケーション
TCP/UDP HTTP(S)
宛先はIPアドレスで指定する。 宛先はFQDNで指定する。

レイヤー層の違いで認識しておけばOKである。
DNAT > ネットワーク > アプリケーションの優先順位で処理が行われる。
そのため、優先度番号を付ける際にも、上記を守れるように番号付けを行うこと。

Firewallリソースは、Vnetと同じリージョン,同じRGに存在する必要がある。

Azure Firewall Manager

  • 概要
    複数のAzure Firewallのルールの一元管理に役立つ機能である。
  • 使いどころ
    ① それぞれのリージョンで、ハブ&スポーク構成で、通信制御を行いたい。
    ② ①が複数のリージョンに跨って存在する。
    ③ なるべく共通するルールは一元管理するなど、効率化を図りたい。

(すごくわかりやすいサイトなので必須で見ておきたい)
https://cloudsteady.jp/post/10089/
(上記だと、セキュリティで保護されたハブの説明しかないため、ハブ仮想ネットワークについては以下を参照)
https://codezine.jp/article/detail/11993

Azure Front Door × WAF

Front DoorにもWAFポリシーを適用することができる。
ゼロからカスタムポリシーを作成する必要はなく、クロスサイトスクリプティングやSQLインジェクションといったレイヤー7攻撃に対するマネージドルールは存在する。
ただし、WAFポリシーを作成すると、既定では検知モード(WAFログには残るが、実際のブロックはしない)のため注意が必要。
カスタム規則を作成するときには、一致規則とレート制限規則が存在する。前者は単純なルールの一致を判断するだけだが、後者はそれに加えてリクエスト数を見る。

レート制御規則により、任意のクライアント IP アドレスからの異常なトラフィックが制限されます。 1 分間に許可されるクライアント IP アドレスからの Web 要求の数に、しきい値を構成することができます。 この規則は、クライアントの IP アドレスからのすべての要求を許可またはブロックする点が、IP リストに基づく許可または禁止のカスタム規則と異なります。 詳細なレート制御については、レート制限を、HTTP(S) パラメーター一致などの他の一致条件と組み合わせることができます。

明示的にIPアドレスリストを作成しなくても、異常なクライアントからのIPを制御できそうだ。

NSGとAzure Firewallの棲み分け

どちらもアクセス制御に関するサービスである。動作する箇所として、NSGはNICで、Firewallはネットワークの境界で動作する。Firewallの方が高機能で、料金もかかる(NAT機能やFQDNでのフィルター機能)。そのため、基本はNSGで実現して、NSGでできないことをFirewallを利用するといった棲み分けが良い。
https://jpaztech.github.io/blog/network/difference-nsg-fw/

Discussion