설명
인터넷에 노출되는 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
}
설명:
- 변경 전: 두 인스턴스가 하나의 프로파일과 역할을 공유합니다.
- 변경 후: 프로파일을 분리합니다. 각 프로파일이 실제로 다른 최소 권한 역할을 사용하는지 확인해야 합니다.