~~NOCACHE~~
~~DISCUSSION~~

## 3.CloudFront-APIGateway構成でのWAF設置場所
CloudFrontのオリジンにAPIGatewayを設定する際、WAFはCloudFrontに設定するか、APIGatewayに設定するか、はたまた両方なのか。
目的は、<color #ed1c24>直接リクエストできてしまうAPIGatewayのセキュリティを強化</color>する構成を考えたい。

以下の3つ構成で考えてみた。案1で良いんじゃないかな・・・うーんうーーん、いや案3か・・？
{{:Aws:WAF:pasted:20210603-120117.png?direct 0x150}}
{{:Aws:WAF:pasted:20210603-112044.png?direct 0x150}}
{{:Aws:WAF:pasted:20210603-120135.png?direct 0x150}}

## 案1:CloudFront-WAF-APIGateway
### 概要
・CloudFrontでなく、APIGatewayのみにWAFを設定する構成。
・CloudFrontのアドレスに攻撃ができてしまうが、APIGatewayの手前でWAFによるWebリクエストの評価が可能
・APIGatewayのアドレスに対してもWAFによるWebリクエストの評価が可能となる。

### 設定
■CloudFront
・カスタムヘッダと値を設定する。(後続の処理で許可/拒否するために利用)

■WAF(リージョン)
・一般的なWebセキュリティ対策を設定
・CloudFrontで設定されたカスタムヘッダと値を評価し、許可/拒否する。
・CloudFrontのIPレンジをホワイトリストに入れ許可/拒否を設定

■APIGateway
・特になし

## 案2:WAF-CloudFront-APIGateway
### 概要
・CloudFrontのみにWAFを設定する構成で、APIGatewayにはWAFを設定しない。
・APIGatewayのアドレスは公開していなければこの構成でも良いが、API-IDを総当たりでリクエストすれば攻撃を受けることもある。(カスタムドメインの導入で、更に攻撃を受けにくくすることも可能)
・APIGateway側である程度の対策はできるが、Webリクエストはできてしまうことと、APIGatewayごとに設定が必要なため運用面が課題となる。

### 設定
■WAF(グローバル)
・一般的なWebセキュリティ対策を設定

■CloudFront
・カスタムヘッダと値を設定する。(後続の処理で許可/拒否するために利用)

■APIGateway
・メソッドリクエストの必須HTTPリクエストヘッダーでカスタムヘッダを指定する。
・リソースポリシーにて、CloudFrontのIPレンジで許可/拒否を設定

## 案3:WAF-CloudFront-WAF-APIGateway
### 概要
・CloudFrontとAPIGatewayの両方にWAFを設定する構成。
・CloudFrontとAPIGatewayどちらのアドレスに対してもWAFによるWebリクエストの評価が可能
・CloudFront経由の場合、WAFで2重で評価されるためWAFに関してコストが約2倍かかることとなる。
　(コスト面は案1ではCloudFront、案2ではAPIGatewayに対してWAFによるレート制限がない為、一概に評価ができない)

### 設定
■WAF(グローバル)
・後続でセキュリティ対策をするので、レート制限のみ設定

■CloudFront
・カスタムヘッダと値を設定する。(後続の処理で許可/拒否するために利用)

■WAF(リージョン)
・一般的なWebセキュリティ対策を設定
・CloudFrontで設定されたカスタムヘッダと値を評価し、許可/拒否する。
・CloudFrontのIPレンジをホワイトリストに入れ許可/拒否を設定

■APIGateway
・特になし

## サマリ
・セキュリティ面は案1も案3も同等で、案2が低くなる。<color #ed1c24>※CloudFrontのWAFとAPIGatewayのWAFでは内部エラーが発生した際の違いはある。APIGatewayの方がセキュリティが高い</color>
・コスト面は一概に言えないが案3＞案2＞案1となると思われる。
・運用面では案2がAPIGatewayごとに設定が必要で、案3がWAFの2重管理となる。

^ 項目                  ^ 運用  ^ セキュリティ  ^ コスト  ^ 備考                                                                                                                                                                                 ^
| 案1:CF-WAF-APIGW      |  〇   |  〇           |  ー     | CloudFrontはコンテンツ配信しなければコスト面は大した額でないので、運用面の手間が少なく\\ セキュリティも高いこの案で良いんじゃないだろうか。                                          |
| 案2:WAF-CF-APIGW      |  ×    |  △            |  ー     | APIGatewayのアドレス漏洩は考えすぎだろうか、内部の人間ならわかるから考慮すべきですよね。\\ CloudFrontのカスタムヘッダも内部の人間ならわかるから、やはりセキュリティ面が弱いと思う。  |
| 案3:WAF-CF-WAF-APIGW  |  △    |  〇           |  ー     | WAFがグローバルとリージョンで2重管理となる。\\ 運用面で設定変更が手間になるが、セキュリティは高いと思われる。レイテンシ・・・は不明                                                  |

ちなみにCloudFrontのIPアドレスは下記から取得できますが、更新されることがあるのでメンテは必要になります。
https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html

### 引用(CloudFrontのWAFとAPIGatewayのWAFの違い)
ごくまれに、AWS WAF で、リクエストを許可またはブロックするかどうかについて、
API Gateway、CloudFront、または Application Load Balancer への応答を遅らせる内部エラーが発生する場合があります。

そのような場合は通常、CloudFront はリクエストを許可またはコンテンツを提供します。
API Gateway および Application Load Balancer は、通常、リクエストを拒否し、コンテンツを提供しません。
[[https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/classic-how-aws-waf-works.html|AWS WAF Classic 仕組み]]

{{tag>AWS CloudFront WAF APIGateway}}