RDS 보안 그룹 화이트리스트 설정이 필수인 3가지 이유
1. IP가 아닌 '신원(Identity)' 기반 제어
RDS의 가장 큰 특징 중 하나는 엔드포인트(DNS) 주소를 쓰지만, 내부적인 사설 IP는 유동적이라는 점입니다. (페일오버나 유지보수 시 변경될 수 있음)
IP 기반의 한계: 웹 서버가 100대라면 보안 그룹에 IP 100개를 일일이 등록해야 할까요? 서버가 늘어날 때마다 DB 설정을 바꿔야 할까요? 이건 운영의 재앙입니다.
보안 그룹 참조(SG-to-SG): RDS 보안 그룹의 소스(Source)에 '웹 서버 보안 그룹 ID(예: sg-12345)'를 넣어보세요. 그러면 해당 보안 그룹을 가진 모든 서버는 IP가 무엇이든, 몇 대가 늘어나든 자동으로 DB 접속 권한을 갖게 됩니다. "IP가 아니라 명찰(SG)을 보고 문을 열어주는 것"이죠.
2. 횡적 이동(Lateral Movement) 차단
만약 보안 그룹을 0.0.0.0/0(전체 오픈)으로 설정하거나 너무 넓게 잡으면, 인프라 내의 취약한 다른 서버가 해킹당했을 때 해커가 아주 손쉽게 DB까지 침투할 수 있습니다.
최소 권한 원칙: 오직 애플리케이션 서버, 배치 서버, 그리고 관리용 Bastion 호스트의 보안 그룹만 허용하세요. 이렇게 하면 설령 다른 서버가 뚫리더라도 DB라는 최종 보루는 지켜낼 수 있습니다.
3. '실수'로 인한 데이터 유출 방지
많은 보안 사고가 해커의 천재성보다는 관리자의 사소한 실수(Misconfiguration)에서 시작됩니다.
퍼블릭 액세스 차단: RDS 인스턴스를 실수로 'Publicly Accessible'로 생성했더라도, 보안 그룹이 특정 사설 대역이나 특정 보안 그룹만 허용하고 있다면 외부 인터넷에서는 절대 접근할 수 없습니다. 이중 잠금 장치 역할을 하는 셈입니다.
보안 그룹 설정 방식 비교
항목 | 애니웨어 오픈 (0.0.0.0/0) | 화이트리스트 (SG 참조) |
보안 수준 | 매우 위험 (전 세계가 공격 가능) | 최상 (허가된 대상만 가능) |
운영 편의성 | 초기엔 편하나 사고 시 대책 없음 | 자동화에 최적화됨 (Auto Scaling 대응) |
감사(Audit) | 추적이 불가능함 | 명확한 인가 경로 파악 가능 |
실수 방어 | 방어막 없음 | 인적 오류에 강함 |
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.