こんにちは、DX推進室の安齋です。
今回はAWSサーバーレスリソース構築でハマった・工夫した箇所の紹介の第5回目となります。
- 第1回は API GatewayでIAM認証を行う
- 第2回は API GatewayのCloudWatchLogsの設定をIaCで行う
- 第3回は Cognitoユーザープールでグループ毎にリソース制御を行う
- 第4回は CloudFrontでオリジンリクエストポリシーを設定する時の注意点
第5回はVPC LambdaからAurora SeverlessをData API経由で使用する際に必要なセキュリティグループの紹介となります。Data APIはHTTPリクエストとレスポンスでAurora Severlessとデータのやり取りをするAPIで、リクエストを送る側はMySQL等のライブラリが一切不要になります。必要最低限のセキュリティグループのルールを調査した際、あまり情報がなかったため、同じように適用したい人がいた時のためにまとめます。
今回のテーマ
上記構成図の赤枠内のネットワーク環境をピックアップした、通信経路図が以下です。
Aurora Severlessにはセキュアな情報を入れるため、ネットワーク経路を限定したく、VPC上に設置しています。併せてAurora Severlessを使用する管理者用APIのLambdaもVPC上に設置しています。全サブネットは二つのアベイラビリティゾーンで冗長化していますが、図のスペースの都合上、記述を割愛しています。以下、図の凡例となります。
- 黒線（実線）
- VPC内部のHTTPS通信
- 黒線（破線）
- AWS内部のHTTPS通信
- 青線（実線）
- インターネット経由のHTTPS通信
通信要件はこちら
以下、Aurora ServerlessとLambdaの通信要件です。通信経路を極力限定するべく、AWSサービスのVPCエンドポイントを使用しています。唯一、CognitoだけはVPCエンドポイントがないため、インターネットを経由したアクセスになります。
| No. | From | To | 用途 |
|---|---|---|---|
| 1 | Aurora Severless | Secret Manager | Aurora Severlessの接続情報の取得 |
| 2 | Aurora Severless | KMS | Aurora Severlessの接続情報の復号化、ログの暗号化 |
| 3 | Aurora Severless | CloudWatch Logs | Error、Auditログの出力 |
| 4 | Aurora Severless | CloudWatch Metrics | リソース監視 |
| 5 | Lambda | Secret Manager | Aurora Severlessの接続情報の取得 |
| 6 | Lambda | KMS | Aurora Severlessの接続情報の復号化、ログの暗号化 |
| 7 | Lambda | CloudWatch Logs | 実行ログの出力 |
| 8 | Lambda | CloudWatch Metrics | リソース監視 |
| 9 | Lambda | Aurora Severless | ユーザー情報の取得 |
| 10 | Lambda | ENI | ENIのアタッチ・デタッチ |
| 11 | Lambda | Cognitoユーザープール | ユーザープール内のユーザー情報の取得 |
VPCエンドポイントのおさらい
VPCエンドポイントは指定したサブネットのENIを消費しますが、指定したサブネットの所属するアベイラビリティゾーンに設置されるため、同一アベイラビリティゾーンのサブネットであればVPCエンドポイントを使用することができます。要するに、VPCエンドポイントはサブネット毎に設置するものではない、ということです。
インターフェイスエンドポイントを作成する場合、エンドポイントはアカウントにマッピングされているアベイラビリティーゾーンに作成され、他のアカウントからは独立したものになります。
https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/vpce-interface.html#vpce-interface-availability-zones
セキュリティグループを作る
通信要件に沿って、
- Aurora Serverless用
- Lambda用
- Aurora SeverlesとLambdaが共通で使用するVPCエンドポイント用
- Lambdaのみが使用するVPCエンドポイント用
の四つのセキュリティグループを作りました。通信経路図の赤枠が該当します。
VPCエンドポイントは同一アベイラビリティゾーンに所属する全サブネットが使用できるため、意図しない通信が発生しないように、必要な通信のみを許可するセキュリティグループのルールを作りました。例えば、Lambdaのみが使用するVPCエンドポイント用セキュリティグループには、Lambdaの所属するサブネットのCIDRのインバウンドのみを許可します。
今回のポイントは、Aurora SeverlessにMySQL用の3306ポートのインバウンドルールや、Lambdaに同様のアウトバウンドルールが不要なことです。必要なルールは、HTTPS通信インバウンドとアウトバウンドルールのみです。
以下、セキュリティグループのルールです。
| No. | 通信経路図の表記 | ルール | プロトコル | From/To | 用途 |
|---|---|---|---|---|---|
| 1 | SG A | インバウンド | HTTPS | [From] LambdaのサブネットCIDR |
1.RDS Dataエンドポイント 2.EC2エンドポイント |
| 2 | SG B | インバウンド | HTTPS | [From] 1.Aurora SeverlessのサブネットCIDR 2.LambdaのサブネットCIDR |
1.Secret Managerエンドポイント 2.KMSエンドポイント 3.CloudWatch Metricsエンドポイント 4.CloudWatch Logsエンドポイント |
| 3 | SG C | アウトバウンド | HTTPS | [To] Aurora SeverlessのサブネットCIDR |
1.RDS Dataエンドポイント 2.Secret Managerエンドポイント 3.KMSエンドポイント 4.CloudWatch Metricsエンドポイント 5.CloudWatch Logsエンドポイント |
| 4 | SG C | アウトバウンド | HTTPS | [To] LambdaのサブネットCIDR |
EC2エンドポイント |
| 5 | SG C | アウトバウンド | HTTPS | [To] 0.0.0.0/0 |
Cognitoユーザープール |
| 6 | SG D | アウトバウンド | HTTPS | [To] Aurora SeverlessのサブネットCIDR |
1.Secret Managerエンドポイント 2.KMSエンドポイント 3.CloudWatch Metricsエンドポイント 4.CloudWatch Logsエンドポイント |
セキュリティグループ SG C のアウトバウンドルールは、No.5が全てを包括しているため、厳密言うとNo.3と4は不要です。
まとめ
Data APIにより、これまでのデータベース周辺の通信要件が大きく変化しました。また、VCPエンドポイントの積極的な使用により、セキュアなネットワーク通信経路を確立することができます。