これまでの記事
全体構成
今回はおまとめ記事なので、ピンクの枠はありません
前回の記事でハマったポイント
- Lmabda VPCによる制約
- Lambdaからの無制限アクセスを制限するためのRDS Proxyが使う必要がある
- Lambdaと同一VPC内にRDS Proxyが必要
- RDS Proxy間で接続して解決
という感じでした。
前回ややこしくなってしまい書き切れなかった補足
Security Groupのところをややこしく書いてたので、図面を用意して 表にして見ました。
Security Groupやネットワークの情報整理
サブネットマスク
- 右のVPC全体(192.168.0.0/23)
public-subetを192.168.0.0/24private-subnetを192.168.1.0/24
- 左のVPC全体(192.168.10.0/23)
public-subnetを192.168.10.0/24private-subnetを192.168.11.0/24
Security Group
- LambdaのSecurity Groupを
SG-A - LambdaのVPCがいる方RDS ProxyのSecurity Groupを
SG-B - LambdaがいるVPC peeringのSecurity Groupを
SG-C - RDSがいるVPC PeeringのSecurity Groupを
SG-D - RDSがいる方のRDS ProxyのSecurity Groupを
SG-E - RDSのSecurity Groupを
SG-F
として記載します。
セキュリリティグループの設定
- SG-Aのインバウンド
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| HTTP | TCP | 80 | 192.168.0.0/23 | |
| HTTPS | TCP | 443 | 192.168.0.0/23 |
- SG-Aのアウトバウンド
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| HTTP | TCP | 80 | 0.0.0.0/0 | |
| HTTPS | TCP | 443 | 0.0.0.0/0 | |
| DNS | UDP | 53 | 0.0.0.0/0 | |
| MySQL/Aurora | TCP | 3306 | 192.168.1.0/24 |
- SG-Bのインバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | SG-A |
- SG-Bのアウトバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | SG-A | |
| MySQL/Aurora | TCP | 3306 | 192.168.11.0/24 |
- SG-Cのインバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | 192.168.0.0/23 | |
| MySQL/Aurora | TCP | 3306 | 192.168.10.0/23 |
- SG-Cのアウトバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | 192.168.0.0/23 | |
| MySQL/Aurora | TCP | 3306 | 192.168.10.0/23 |
- SG-Dのインバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | 192.168.0.0/23 | |
| MySQL/Aurora | TCP | 3306 | 192.168.10.0/23 |
- SG-Dのアウトバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | 192.168.0.0/23 | |
| MySQL/Aurora | TCP | 3306 | 192.168.10.0/23 |
- SG-Eのインバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | SG-B |
- SG-Eのアウトバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | SG-B |
- SG-Fのインバウンド設定
| タイプ | プロトコル | ポート範囲 | ソース | 備考 |
|---|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | SG-E | |
| MySQL/Aurora | TCP | 3306 | 192.168.10.0/23 |
対抗のネットワークが複雑化している関係で、Security Groupを入れてたりIPやCIDR等を入れてますが、Security Groupを入れ子にすることをできる限り推奨します。
また、重要なところですが、 汎用性を広げる為、peering間では通信を全て許可していますが個々のサービスで制限をかける必要があります。
作業のおまとめ
Security Groupの表だけで結構大変なことになってしまいましたが順番を書くと
- API Gatewayを作る
- Route 53とCertificate ManagerのDNS認証で用いて証明書を作る、この時、設置するリージョンに気をつけること
- Lambda用のSecurity Groupを作る
- Lambdaを作る
- VPC peering用のSecurity Groupを作る
- VPC peeringを接続する
- RDS Proxy用のSecurity Groupを作る
- RDS Proxyを作る
- RDSのSecurity Groupの編集をする
- 接続確認
- 疎通確認後、API GatewayにWAFを取り付け
- 動作検証
と言った形になります。
作った後の感想
こういう物ほど、Cloud formationが使えたら良いなぁとか思いました。 正直、入れ子になりすぎてどれがどれ？ 見たいな事は多々ありました。
なんで作らなかったって？？ ここまで書いておいて何ですが、 実は、取得していた認証規格の関係でコードと呼ばれる物にすると 全て、「コードテスト」と「セキュリティ基準」に満たす必要があり、そちらの方に工数を取られてしまう と言う観点で、当時は諦めました。
今後はできれば良いなぁとかそういうのを作れたら良いなぁとか最近思ってます。
