LoginSignup
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@smr1

AzureのNetworkセキュリティ（NSG、Firewall、WAF）

Last updated at Posted at 2024-10-27

Network Security Group

  • OSI Layer4のフィルター

    • IPアドレス
    • ポートナンバー
    • プロトコル

  • 向きは入出力が可能

  • NICとSubnetに適用可能、基本はSubnetレベルが推奨

  • Statefulなので片方ががあればもう片方も自動で許可される、例えばInbound許可ルールがあればOutboundルールは不要

  • ルールは100から4096まで、数字が小さいほうが優先させれる

Default Rule

削除はできないが、上書きできる。
image.png

共通：

  • VNet内の通信は全て通信可能とする（VNet間はダメ）

Inbound：

  1. Azure Load Balancerからの通信を受け入れる
  2. すべてのInboundを拒否

Outbound：

  1. Internetへの接続を許可
  2. すべてのOutboundを拒否

NSGとAzure Firewall

両方とも通信制限を行うリソースだが用途が異なる。

image.png

Azure Firewall

基本機能

ネットワークの境界にインターネットフェーシングでデプロイされる。

  • レイヤ3からレイヤ7まで対応するマネージドステートフルファイアウォール
  • マイクロソフト脅威インテリジェンスとの統合
  • 集中型ポリシー管理
  • 可用性ゾーンの認識
  • SNATとDNAT

SNAT、DNATの違い

ソ ー ス NAT (SNAT)：送信元 IP アドレスを変換する
デスティネ ー ション NAT (DNAT)：宛先 IP アドレスを変換する NAT用

  • Azure Monitorとの統合をサポート

Azure FirewallのPolicy

  • SKUを決める
    image.png

  • DNSを決める
    image.png

  • TLSインスペクション

SSLインスペクションは、クライアント（ユーザー側）とサーバー（Webサイト側）との間をセキュリティ製品が仲介し、双方に対してHTTPS通信を確立します。
セキュリティ製品が両者の通信に対する中間者となり、通信を捕捉することで検査を行います。SSLインスペクションは、マルウェアによる悪性通信や、機密情報の流出などを監視します。

要するに暗号化通信を複合して、悪意のある通信がないか検査するということらしい。複合化した後はもう一度暗号化して後ろに流す。なので証明書が必要になる。

  • Azure Firwall ManagerからRuleを決める

NAT rule

DNAT ルールは、1 つ以上のファイアウォールのパブリック IP アドレスを介した受信トラフィックを許可または拒否します。 パブリック IP アドレスをプライベート IP アドレスに変換する場合は、DNAT 規則を使用できます。

DNATのルールを定義可能。
DNAT、DedstinationなのでAzure Firewallにきた受け入れの通信のIP、Portを変換する。

image.png

Network rule

ネットワーク ルールでは、ネットワーク レイヤー (L3) とトランスポート レイヤー (L4) に基づいて、受信、送信、および East-West のトラフィックを許可または拒否します。IP アドレス、任意のポート、および任意のプロトコルに基づいてトラフィックをフィルター処理

オリジナルの行き先IPアドレスをベースに、Forward先のIPが設定可能。AllowとDenyが設定可能。
image.png

Application rule

アプリケーション ルールでは、アプリケーション レイヤー (L7) に基づいて、送信および East-West のトラフィックを許可または拒否します。 完全修飾ドメイン名 (FQDN)、URL、および HTTP/HTTPS プロトコルに基づいてトラフィックをフィルター処理

通信元のIP、行き先のFQDNをもとに通信のAllowとDenyが設定可能。
image.png

アプリケーションルールとネットワークルールの違い

上述の通り、ネットワークルールは L4 で動作し、アプリケーションルールは L7 で動作します。
どちらのルールを使用すべきかについては以下がベストプラクティスとなりますので、ご確認いただけますと幸いです。

HTTP, HTTPS の通信において FQDN ベースで通信を制御できるものはアプリケーションルールを利用する
HTTP, HTTPS の通信において FQDN ベースで通信を制御できないものはネットワークルールを利用する
HTTP, HTTPS, MSSQL 以外の通信はネットワークルールを利用する

Firewall Ruleの処理順番

  • Azure Firewallは処理の順番は親から始まり子が処理される
  • ネットワークルール > アプリケーションルールの順番で処理される

Premium機能

  • 通信暗号化
  • 侵入検知
  • パスベースフィルタリング
  • Web閲覧データをカテゴリ（ギャンブルとか）

image.png

侵入検知とThreat Intelligence

image.png

image.png

Deploy

  • 専用の/26のSubnetがAzureFirewallSubnetとして必要（名前がこれである必要がある）
  • 管理用のPublic IPが必要

image.png

image.png

VNetのここでデプロイすることもできる。AzureFirewallSubnetという専用のSubnetが必要。
image.png

Azure Web Application Firewall

  • Layer7、アプリセキュリティ用
  • Application Gateway、Front Door、CDNと統合可能
  • DetectionもしくはPreventionモードが可能

なので、今まで話していたAzure FirewallはLayer4でバックエンドがVMやLoad BalancerなどIaaSの場合に推奨。WAFはバックエンドがWeb Appsなどアプリの場合になる。

VMの上にIISなどでWebアプリを動かしている場合はAzure Firewall＋WAFにしてもいい。

WAF Policy Deploy

WAF Policyを個別に作るときはAppGW用かFront Door用かを質問されてしまうため、WAF PolicyはApp GWとFDで共用はできない。別々に作る必要がある。

image.png

ただし、App GWもFront Doorもリソースレベルではなく、パスベース、ListenerやEndpointレベルでAssociateすることができる。

image.png

image.png

Managed Ruleset

OWASPのTop Tenルール、Microsoft推奨ルールなど。CSRF、SQL Injectionなどの一般的な対応。カスタマイズ可能。ちなみにAppGW用のルールはOWASPを選択できるが、
image.png

Front DoorはOWASPが選択できない。とはいっても、Microsoft Default RulesetはOWASPに基づいており、MicrosoftのThreat Intelligenceと統合などをしているらしいので、そこまで大きくは変わらないかも。
image.png

ただし、StandardのFront DoorだとOWASPなどのマネージド規則による保護が利用できない。これは企業利用だと正直この時点で自動的にPremium確定といってもいい気がする。

Azure Front Door には2 つのレベルがあります。
Azure Web アプリケーション ファイアウォールは、すべての機能を備えたAzure Front Door Premium とネイティブに統合されています。 Azure Front Door Standard の場合は、カスタム ルールのみがサポートされています。

DDos Protection

また、WAFはDDos Protectionも提供する。
ただし、DDos攻撃はLayer3/4とLayer7の2つのレイヤーがあり得る。それに対してWAFはLayer7を防御するのみである。

追加でLayer3/4を防御したい場合は、以下のどちらかになる。

1. Application GatewayでAzure DDos Protectionを利用する

2. Front Doorを利用すればデフォルトでL3/4のDDos攻撃も防御してくれる

WAF を超えて、Azure Front Door では、L3/4 DDoS 攻撃から保護するための既定の Azure インフラストラクチャ DDoS 保護も提供されます。

Custom Rule

それでもDDos対策をすり抜ける場合、カスタムルールでRate Limit等を設定することができる。

image.png

Rate Limitは地域とクライアントアドレス（IPベース）の2種類で設定可能。
image.png

1分間、または5分間ごとに定義可能。
image.png

詳しくは別サイトで。

WAFの誤検知への対応

ルール除外などの対応が必要になる。
導入時には検出モードから始めることになる。以下の記事を読んでふむふむなるほどーという感じでした。

  • Managed Ruleの特定のルールを特定の条件下のときに除外する。
    image.png

  • カスタムルールのほうがManaged Ruleより優先されるため、特定条件の通信を許可する

DDos Protection

DDos対策にはその他専用のDDos Protectionというリソースも存在する。

Azureには最低限のDDos保護は存在する。ただしそれがサービスで想定しているレートと合っているかは微妙なところ。DDos ProtectionリソースはIPベースまたはVNetベースの保護が可能。ただしコストがそこそこ高いので利用すべきか悩むかもしれない。

このサービスを使用しないと Azure のサービスが安全ではくなりますか?
Azure で実行されているサービスは、既定のインフラストラクチャ レベルの DDoS 保護によって本質的に保護されています。 ただし、インフラストラクチャに対する保護の場合、ほとんどのアプリケーションで処理できる容量よりはるかに高いしきい値を持ち、テレメトリやアラートが提供されないため、トラフィック量がプラットフォームによって無害であると認識されても、それを受信するアプリケーションにとっては壊滅的になる可能性があります。
Azure DDoS Protection サービスにオンボードすることで、アプリケーションには、攻撃とアプリケーション固有のしきい値を検出するための専用の監視が提供されます。 サービスは、予想されるトラフィック量に合わせて調整されたプロファイルを使用して保護され、DDoS 攻撃に対する防御は、はるかに厳しくなります。

ただ、Public IPを幾つも露出させているシステムはアタックサーフェスが多いということであり、NWの閉域化が原則のこの時代そもそものアーキテクチャが悪いという可能性が高い。

そういう意味だと、WAF付きのApplication GatewayかFront Doorにエンドポイントは限定したうえで、各種リソースはPrivate Endpointでインターネットを遮断するほうが遥かにセキュアになる。その場合DDos Protection自体がそもそも不要になる。

Private Endpointはこちら参照。

Network Monitoring

最後に少しだけログの話を。
Diagnostics Settings > Log Analyticsに保管する。

  • Metrics
  • Logs

これはAzure Monitor全般の話になってしまうが、Azure FirewallなどはDiagnostics SettingsでログをLog Analyticsにためるようにする。

image.png

image.png

Logは以下のリソース毎に以下のようなテーブルに吐き出される。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?