説明
インターネットに公開する EC2 と内部用ワークロードが IAM ロールを共有すると、公開インスタンスに不要な内部データ権限まで付与するおそれがあります。侵害時には、そのロールでアクセスできる範囲へ被害が広がり得ます。
パブリックサブネットだけで接続可否が決まるわけではありません。実際のアドレス・経路・セキュリティグループを確認し、ネットワーク名だけでなく業務に必要な権限に基づいてロールを分離してください。
想定される影響
- 公開インスタンスの侵害が、共有ロールでアクセスできるデータに影響するおそれがあります。
- 異なる業務で共有すると、権限変更の影響や利用主体を把握しにくくなります。
対処方法
- 権限要件が異なるワークロードには別のロールとインスタンスプロファイルを使ってください。名前だけを変え、同じロールや権限を使い続ける変更では不十分です。
- AWS 操作とリソースを限定し、プロファイル変更後に必要なアクセスの成功と不要なアクセスの拒否をテストしてください。
例
AMI、VPC モジュール、ロール、内部ワークロード用の別プロファイルを用意する必要がある抜粋です。変更後の aws_iam_instance_profile.test_profile3 は、内部業務用の別ロールに接続してください。
変更前
hcl
resource "aws_iam_instance_profile" "example" {
name = "test_profile"
role = aws_iam_role.test_role.name
}
resource "aws_instance" "public_instance" {
ami = data.aws_ami.ubuntu.id
instance_type = "t2.micro"
subnet_id = module.vpc.public_subnets[0]
iam_instance_profile = aws_iam_instance_profile.example.name
}
resource "aws_instance" "private_instance" {
ami = data.aws_ami.ubuntu.id
instance_type = "t2.micro"
subnet_id = module.vpc.private_subnets[0]
iam_instance_profile = aws_iam_instance_profile.example.name
}
変更後
hcl
resource "aws_iam_instance_profile" "public_profile" {
name = "test_profile"
role = aws_iam_role.test_role2.name
}
resource "aws_instance" "public_instance" {
ami = data.aws_ami.ubuntu.id
instance_type = "t2.micro"
subnet_id = module.vpc.public_subnets[0]
iam_instance_profile = aws_iam_instance_profile.public_profile.name
}
resource "aws_instance" "private_instance" {
ami = data.aws_ami.ubuntu.id
instance_type = "t2.micro"
subnet_id = module.vpc.private_subnets[0]
iam_instance_profile = aws_iam_instance_profile.test_profile3.name
}
補足:
- 変更前: 両インスタンスが同じプロファイルとロールを共有します。
- 変更後: プロファイルを分けます。それぞれが実際に別の最小権限ロールを使うことを確認してください。