プロジェクトで使うSecurity Groupを一括管理し、リソース間の通信許可をSecurity Group IDの参照で設計するパターンを解説する。 IPアドレスに依存せず、外部へ開く入口を必要最小限に絞るネットワークアクセス制御の実践を紹介する。
「Security Groupの入れ物を一括で作り、個別の許可はリソース側で追加する」という設計パターン自体は、IAMと共通する考え方として親記事IAMとSecurity Group ─ 2つのアクセス制御レイヤーの設計で解説している。 本稿ではSecurity Group固有の判断に絞る。
1. 一括管理で作るもの、リソース側で追加するもの
一括管理では、Security Groupの入れ物と、どのリソースにも共通する規則だけを定義する。
「誰からの通信を受けるか」は、受ける側のリソースのTerraformで決める。
# 概念例: RDSを構築するコードの中で、ECSタスクからの接続を許可する
|
resource "aws_security_group_rule" "rds_from_ecs" {
|
type = "ingress"
|
security_group_id = aws_security_group.rds.id # 受ける側: RDS
|
source_security_group_id = aws_security_group.ecs.id # 接続元: ECSタスク
|
from_port = 3306
|
to_port = 3306
|
protocol = "tcp"
|
description = "Allow MySQL from ECS tasks"
|
} |
この形にすると、RDSのコードを読めば「どこから接続できるか」がわかる。 リソースを削除すれば、そのリソースへの許可も一緒に削除対象になる。
2. IPアドレスではなくSecurity Group IDで許可する理由
CIDRで許可する場合の問題
# 概念例: CIDRで許可する（通常は避ける）
|
cidr_blocks = ["10.0.1.0/24"] # ECSタスクを置くサブネット |
- ECSタスクのIPアドレスは固定されない
- サブネット全体を許可すると、同じサブネットにある無関係なリソースからも接続できる
- サブネットの構成を変えると、許可ルールも直す必要がある
Security Group IDで許可する利点
- IPアドレスに依存しない: タスクのIPアドレスが変わっても許可は維持される
- 最小権限: 同じサブネットの中でも、指定したSecurity Groupを持つリソースだけを許可する
- 意図が読める: 「ECSタスクからの接続を許可する」ことがコードから読み取れる
- 構成変更に強い: サブネットを組み替えても許可ルールを直さなくてよい
Security Group IDで表せない接続元
管理者の端末から踏み台へのSSHは、この例外に含めない。 3章のとおり、受信ポートを開けずに接続できるためである。
3. 受信ポートを開けない管理接続
踏み台やサーバーへの管理接続のために、オフィスのIPアドレスからSSH（22番ポート）を許可する構成は多い。 本構成では、管理接続のための受信ポートを開けない。
AWS Systems ManagerのSession Managerを使うと、インスタンスへの接続はAWSのサービスを経由した安全な経路で行われ、SSHの認証情報を管理する必要もなくなる。 インスタンス側に必要なのは、Session Managerのエンドポイントへの送信経路である。
この結果、踏み台用Security Groupの受信ルールは空になる。 踏み台からデータベースなどへ接続する場合は、踏み台用Security GroupのIDを接続元として、接続先のSecurity Groupに許可を追加する。 他のリソースと同じ「受ける側で許可する」パターンに収まる。
踏み台の配置、秘密鍵の保管、OS更新とKey Pair更新の運用は、踏み台サーバのOS更新とKey Pair更新で解説している。
4. リソース別の通信許可パターン
受ける側のリソースが、許可する接続元のSecurity Group IDを受け取り、自身のSecurity Groupに受信ルールを追加する。
実線の矢印は、受ける側のTerraformに書く受信ルールに対応する。 「このリソースに誰が接続できるか」は、受ける側のコードを読めば完結する。
ALBの受信
- CloudFrontからの接続: AWSが管理するマネージドプレフィックスリストを接続元に指定する。IPv4用の
com.amazonaws.global.cloudfront.origin-facingと、IPv6用のcom.amazonaws.global.ipv6.cloudfront.origin-facingがある。CloudFrontが最新の状態に保つため、IPアドレスの範囲を自分で管理しなくてよい - 内部ALB: 特定のSecurity Groupからの接続だけを許可する
CloudFrontのマネージドプレフィックスリストは、VPCのクォータへの数え方が他のプレフィックスリストと異なる。 Security Groupのルール数に余裕があるかを設計時に確認する。
5. まとめ
Security Groupの設計で目指すのは、許可の一覧を眺めたときに外から入れる場所が公開の入口だけになっている状態である。 管理のための入口も、受信ポートとしては持たない。