lander.log

AWS Security Group Source Reference

6 min read

AWS Security Group Source Reference

정의 (Definition)

Security Group Source Reference(소스 참조) 는 보안 그룹 규칙에서 IP 대역(CIDR) 대신 특정 보안 그룹 ID(source_security_group_id)를 허용 조건으로 지정하는 방식입니다. 이는 IP 주소가 동적으로 변하는 클라우드 환경에서 “논리적 그룹(Role)” 간의 통신을 허용하는 최소 권한 원칙(Least Privilege) 의 핵심 구현체입니다.

문제가 되는 배경 (Problem Context)

데이터베이스(RDS, ElastiCache) 보안 그룹을 설정할 때, 편의상 VPC CIDR 전체를 허용하는 경우가 많습니다.

  • 위험: “내부 네트워크는 신뢰한다”는 전제에 기반하지만, VPC 내부의 침해된 인스턴스, 오배포된 워크로드, 테스트 서버 등이 DB에 접근할 수 있는 경로(Lateral Movement)가 열립니다.
  • 한계: 오토스케일링으로 IP가 계속 바뀌는 환경에서, 특정 IP만 화이트리스팅하는 것은 운영 불가능합니다.

핵심 메커니즘 (How it Works)

AWS 네트워크 계층은 패킷의 소스 IP가 “허용된 보안 그룹(Source SG)에 속한 ENI”에서 출발했는지를 검사합니다.

설정 패턴 비교

패턴설정 예시의미보안성비고
VPC CIDR10.0.0.0/16VPC 내 모든 리소스 허용⚠️ Low내부 위협에 취약함
Source SGsg-xxxx해당 배지를 단 리소스만 허용✅ High논리적 경계 구현

Terraform 구현 예시 (Modules)

많이 사용되는 커뮤니티 모듈(terraform-aws-modules)마다 SG 규칙을 넣는 문법이 조금씩 다릅니다.

1. RDS Aurora 모듈

security_group_ingress_rules 블록을 사용하며, referenced_security_group_id 키를 사용합니다.

module "rds" {
  source  = "terraform-aws-modules/rds-aurora/aws"
  version = "~> 10.0"
  
  # ...
 
  security_group_ingress_rules = {
    eks_nodes = {
      description                  = "Allow traffic from EKS nodes"
      ip_protocol                  = "tcp"
      from_port                    = 3306
      to_port                      = 3306
      referenced_security_group_id = module.eks.node_security_group_id # 여기!
    }
    bastion = {
      description                  = "Allow traffic from Bastion"
      ip_protocol                  = "tcp"
      from_port                    = 3306
      to_port                      = 3306
      referenced_security_group_id = aws_security_group.bastion.id
    }
  }
}

2. ElastiCache (Valkey/Redis) 모듈

security_group_rules 블록을 사용하며, 모듈 버전에 따라 referenced_security_group_id 또는 source_security_group_id를 사용합니다.

module "elasticache" {
  source  = "terraform-aws-modules/elasticache/aws"
  version = "~> 1.10"
 
  # ...
 
  security_group_rules = {
    ingress_from_eks = {
      description                  = "From EKS nodes"
      referenced_security_group_id = module.eks.node_security_group_id # 또는 source_security_group_id
    }
    ingress_from_bastion = {
      description                  = "From Bastion"
      referenced_security_group_id = aws_security_group.bastion.id
    }
  }
}

Note: ElastiCache 모듈은 포트(from_port/to_port)가 생략되면 엔진 기본 포트(예: Valkey 6379)를 자동으로 잡는 경우가 많습니다.

불변 조건과 보장 범위 (Invariants & Guarantees)

  • 보장: Source SG로 지정된 그룹에 속한 리소스(ENI)만 트래픽을 보낼 수 있습니다. IP가 바뀌어도 규칙은 유지됩니다.
  • 비보장: “EKS Node SG를 허용했으니 EKS 파드가 붙을 수 있다”는 항상 보장되지 않습니다. (EKS 네트워킹 모드에 따라 다름)

비유 (Analogy)

  • VPC CIDR: “회사 사원증을 가진 사람은 누구나 서버실에 들어올 수 있다.” (청소부, 인턴, 타 부서 포함)
  • Source SG: “보안팀(Source SG) 배지를 패용한 사람만 서버실에 들어올 수 있다.” (역할 기반)

실무적 함의 (Operational Implications)

EKS 환경에서의 주의점 (The “Gotcha”)

“EKS 노드 SG만 허용하면 된다”는 일반화는 위험합니다. 클러스터 네트워크 구성에 따라 DB가 바라보는 소스가 달라집니다.

  1. Standard (AWS VPC CNI 기본): 파드가 노드 ENI를 공유하거나 노드 IP로 SNAT됨 → Node SG 허용 필요.
  2. Security Groups for Pods: 파드가 별도 ENI/SG를 가짐 → Pod SG 허용 필요 (Node SG로는 불충분).
  3. Fargate: 노드가 없거나 관리형임 → Fargate Profile에 할당된 SG 허용 필요.

Bastion 관리

Bastion 호스트에서의 직접 접근도 cidr_blocks(Bastion EIP)보다 source_security_group_id(Bastion SG)로 제어하는 것이 동적 IP 환경에서 훨씬 안정적입니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  • Circular Dependency: SG A가 B를 참조하고, B가 A를 참조하는 규칙을 aws_security_group 리소스 내부(ingress 블록)에 정의하면 Terraform 순환 참조 오류가 발생합니다. 이를 피하기 위해 aws_security_group_rule 리소스로 분리해야 합니다.
  • 모듈별 문법 차이: Terraform 모듈마다 ingress_with_source_security_group_id, security_group_ingress_rules 등 인터페이스가 다르므로 README를 꼭 확인해야 합니다.

References

Recent Posts