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

# Network Security Group
- OSI Layer4のフィルター
    - IPアドレス
    - ポートナンバー
    - プロトコル
- 向きは入出力が可能
- NICとSubnetに適用可能、基本はSubnetレベルが推奨

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

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

## Default Rule
削除はできないが、上書きできる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/ab109784-c5ec-8969-73ec-c72602a1f5d4.png)

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

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

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


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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/e50df78d-1197-f69f-83f4-30ddcec6f712.png)

https://jpaztech.github.io/blog/network/difference-nsg-fw/

https://www.idaten.ne.jp/portal/page/out/secolumn/multicloud/column053.html

# Azure Firewall

https://www.cloudou.net/virtual-network/vnet016/

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

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

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

https://wa3.i-3-i.info/diff970network.html

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

## Azure FirewallのPolicy

https://learn.microsoft.com/ja-jp/azure/firewall/policy-rule-sets#rule-types

- SKUを決める
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/4bc62f9b-3664-3870-8f7c-e1d8006e6d08.png)

- DNSを決める
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/547a525b-3a0a-de7b-8ea3-ba43fc00cf28.png)

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

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

https://www.sompocybersecurity.com/column/glossary/ssl-inspection

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/da4b9078-2d3a-5b41-0a2c-4309b4751cbb.png)

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

オリジナルの行き先IPアドレスをベースに、Forward先のIPが設定可能。AllowとDenyが設定可能。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/e7dd3040-3ee7-7db4-d559-5b34d993bbf9.png)

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

通信元のIP、行き先のFQDNをもとに通信のAllowとDenyが設定可能。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/99f1ca24-820b-45cc-fc15-197418fe1069.png)

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

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

https://jpaztech.github.io/blog/network/firewall-rules/

### Firewall Ruleの処理順番

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/5afe3ec8-7dd0-255a-0b77-84ba84ce56c9.png)

### 侵入検知とThreat Intelligence

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/6c34a820-c545-3126-afa2-fed4392ce06a.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/ebb58a16-be82-97a3-01ba-a74a10d027d3.png)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/9bd4f905-91de-f176-d729-aa94b606d968.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/b26c8606-7c46-32fe-b5e7-06ac553836b0.png)

VNetのここでデプロイすることもできる。AzureFirewallSubnetという専用のSubnetが必要。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/2ae7a41d-50f9-600c-64b9-4a1aab01dbd5.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/7bb707fd-f67a-a712-23c8-5961a59530e1.png)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/f5c2c8eb-407b-0ddb-8ebd-db45eb496c74.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/1b50ee81-469b-0ffb-fff7-d1b8a851b666.png)

## Managed Ruleset
OWASPのTop Tenルール、Microsoft推奨ルールなど。CSRF、SQL Injectionなどの一般的な対応。カスタマイズ可能。ちなみにAppGW用のルールはOWASPを選択できるが、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/45c4effe-7f57-8477-f28e-c6cda2114b16.png)

Front DoorはOWASPが選択できない。とはいっても、Microsoft Default RulesetはOWASPに基づいており、MicrosoftのThreat Intelligenceと統合などをしているらしいので、そこまで大きくは変わらないかも。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/3541cfb9-1a47-c7ce-68fb-ed1fba647db6.png)

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

https://learn.microsoft.com/ja-jp/azure/web-application-firewall/afds/afds-overview#waf-rules

> 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を利用する

https://learn.microsoft.com/ja-jp/azure/application-gateway/tutorial-protect-application-gateway-ddos

#### 2. Front Doorを利用すればデフォルトでL3/4のDDos攻撃も防御してくれる
> WAF を超えて、Azure Front Door では、L3/4 DDoS 攻撃から保護するための既定の Azure インフラストラクチャ DDoS 保護も提供されます。 

https://learn.microsoft.com/ja-jp/azure/web-application-firewall/shared/application-ddos-protection

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/2e402692-8fc9-faf8-2e95-845f89fde7cc.png)

Rate Limitは地域とクライアントアドレス（IPベース）の2種類で設定可能。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/1532f429-566b-7220-93fd-2a68087ca7d9.png)

1分間、または5分間ごとに定義可能。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/927219c6-5143-352c-c7fc-585b6821022a.png)


詳しくは別サイトで。

https://www.tama-negi.com/2020/02/13/waf/

## WAFの誤検知への対応

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

https://qiita.com/kotetsu-ex-sr/items/4fc0e3a0f9a98883dd07

- Managed Ruleの特定のルールを特定の条件下のときに除外する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/08dac511-3dfd-2d45-cf0f-cef08fc714b6.png)

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

https://jpaztech.github.io/blog/network/handle-waf-false-positive/

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

https://www.cloudou.net/virtual-network/vnet023/

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

https://learn.microsoft.com/ja-jp/azure/ddos-protection/ddos-faq#--------------azure------------------

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

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

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

Private Endpointはこちら参照。

https://qiita.com/smr1/items/b5667f9366143686c04c


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

- Metrics
- Logs

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/2d08522e-3915-d3d7-386e-a5c631aef503.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/654538/fa89e60e-4528-d644-2b5f-ee6d71f512d2.png)

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

https://learn.microsoft.com/ja-jp/azure/azure-monitor/reference/tables/microsoft-network_applicationgateways