RDS·Aurora 서버리스 환경에서 달라지는 보안취약점 진단 기준 (AWS 공동책임모델)

작성자: 보안왕 김보안

 

취약점 진단 체크리스트는 기본적으로 온프레미스 MySQL 환경을 기준으로 정의되어 있다.
그래서 실무 현장에서 RDS나 Aurora 환경을 점검하다 보면,
“이건 취약으로 봐야하나 아니면 예외로 처리해야하나?”, “설정 파일이 없는데 뭘 확인해야하지?”
이런 상황이 정말 자주 발생한다.

즉, 온프렘 기준을 그대로 적용하면 오탐이 우수수 떨어지는 구조다.
문제는 이게 컨설턴트 잘못이 아니라, 애초에 기준이 만들어진 전제가 다르기 때문이다.

그래서 이 글에서는 실제 현장에서 느끼는 관점대로,
“같은 MySQL이라도 온프렘과 RDS/Aurora는 어떤 기준으로 봐야 하는가”를 정리해보려고 한다.

---

1) 계정·권한 점검 — “권한 없음”이 취약이 아니라 오히려 정상

온프렘 MySQL은 root 계정이 절대적인 존재다.
SUPER, FILE, SHUTDOWN 같은 민감한 권한을 모두 가지고 있고,
그래서 KISA, 금융보안원 기준에서도 과도한 권한을 가지고 있지 않은지 매우 중요하게 본다.

그런데 RDS나 Aurora에서는 이런 권한 구조가 통째로 다르다.

• root가 없다.
• admin(또는 cluster admin) 계정만 있지만
• 그 계정조차 SUPER/FILE 권한이 없다.

즉, 권한이 제한되어 있는 것이 취약이 아니라 정상적인 구조다.

그럼에도 온프렘 기준을 그대로 가져오면
"관리자 권한 과도 부여" 항목에서 무조건 ‘취약’이 찍힌다.
실제로는 취약이 아닌데도 말이다.

그래서 RDS/Aurora 평가에서는 점검 방향 자체가 달라져야 한다.

• 온프렘: 불필요한 관리자 권한 제거
• 클라우드: “해당 권한이 부여되지 않는 구조임. 접근 통제는 IAM · SG 레벨에서 이루어짐”

이렇게 통제 레이어를 DB 내부에서 AWS 계층으로 올려서 해석해줘야 한다.

---

2) 비밀번호 정책 — MySQL이 아니라 플랫폼이 관리하는 영역

취약점 진단 기준을 보면
비밀번호 복잡도, 주기적 변경, 재사용 금지 같은 내용이 반드시 등장한다.
문제는 MySQL 자체가 이런 기능을 거의 지원하지 않는다는 점이다.
그래서 온프렘 DB에서는 별도 Password Validation Plugin을 붙여서 해결하곤 한다.

그런데 RDS/Aurora는 그 plugin조차 마음대로 사용할 수 없다.
엔진 버전마다 지원 여부도 다르고, 아예 적용 자체가 막혀 있는 경우도 많다.

만약 이를 모른 채 온프렘 기준대로 점검하면
“비밀번호 재사용 방지 없음 → 취약”
이런 식의 오탐이 필연적으로 발생한다.

현실적인 접근은 이렇다:

• 온프렘: DB 엔진 내부 정책 위주로 점검
• RDS/Aurora: 애플리케이션 계정 관리 정책, IAM 정책, 접근 경로 등 상위 인증 체계에서 보완이 이루어지는지를 기준으로 점검

즉, DB가 아닌 플랫폼 전체의 인증 구조를 평가해야 한다.

---

3) 접근 통제 — DB가 아니라 ‘Security Group’이 실질 통제자

온프렘 MySQL에서는 host 기반 접근 제어나 방화벽이 1차 통제다.
그래서 “불필요한 원격 접속 허용 여부”는 매우 중요한 항목이다.

하지만 RDS/Aurora는 접근 제어 방식 자체가 완전히 다르다.

• Security Group(SG)이 사실상 방화벽이다.
• VPC/Subnet/NACL 구조 속에서 접근 가능 여부가 결정된다.
• DB 내부 host 컬럼은 부수적 역할일 뿐이다.

가장 많이 오해하는 부분이 바로 여기다.
특히 'Public access = No' 라고 해서 무조건 안전한 것도 아니다.
SG가 0.0.0.0/0으로 열려 있으면 의미 없다.

그래서 온프렘 기준을 그대로 적용하면 오탐이 발생하고,
RDS/Aurora에서는 다음 기준으로 재해석해야 한다.

• DB 접근 통제 여부는 host 기반이 아니라 SG 기반으로 평가
• Public access 여부보다 SG Inbound 최소화 여부가 핵심
• IAM 인증, Proxy 구조 사용 여부도 보조 통제로 인정

즉, 접근 통제의 중심이 DB가 아니라 네트워크 계층으로 이동했음을 이해해야 한다.

---

4) 설정 파일(my.cnf) — 아예 존재하지 않는 항목을 점검할 수 없다

온프렘 MySQL 점검에서 가장 기본적인 것은 my.cnf 설정값이다.
local_infile, secure_file_priv, log 설정, symbolic-links 설정 등
DB 보안의 핵심이 모두 여기에 담겨 있기 때문이다.

그런데 RDS/Aurora에는 my.cnf 파일 자체가 없다.

설정은 모두 Parameter Group으로 관리되고,
게다가 일부 값은 AWS 정책상 수정조차 불가능하다.

그래서 다음과 같은 금융보안원 항목(DBM-022 등)은
RDS/Aurora에서는 무조건 예외 처리해야 한다.

• 설정 파일 접근 권한
• 설정 파일 소유자
• 설정 파일 권한
• 설정 파일 무결성

이런 항목은 AWS가 완전히 관리하는 영역이며
고객이나 컨설턴트가 점검할 수 있는 영역이 아니다.

따라서 보고서에는 반드시 다음과 같은 문구가 필요하다.

“본 DB는 AWS RDS/Aurora 기반으로 설정 파일(my.cnf)에 대한 접근이 불가하므로, AWS 관리형 통제로 예외 처리함.”

이 한 줄이 평가 품질을 결정짓는다고 해도 과언이 아니다.

---

5) 로그·감사 — 파일 기반 점검에서 CloudWatch 기반 점검으로 전환

온프렘에서 log 점검은 매우 직관적이다.
/var/log/mysql/slow.log 같은 파일을 직접 열어보면 된다.

근데 RDS/Aurora에서는 로그 파일이 없다.
정확히 말하면, 보이질 않는다.
모든 로그는 CloudWatch로 Export해야만 확인할 수 있다.

그래서 DBM-011(감사 로그 수집 및 백업) 같은 항목은
판단 기준 자체를 이렇게 바꿔야 한다.

• 로그 파일 존재 여부 → X
• CloudWatch Logs Export 활성화 여부 → O
• Performance Insights·Enhanced Monitoring 설정 여부 → O
• Event Subscription 구성 여부 → O

즉, “파일 기반”이라는 관점을 버리고
AWS의 모니터링 체계를 중심으로 항목을 재해석해야 한다.

---

6) 백업·복구 — mysqldump보다 Snapshot이 우선하는 세계

온프렘에서는 mysqldump 또는 binlog 기반 백업 체계를 점검한다.
필요하면 백업 파일 권한, 백업 보관 기간 등까지 확인한다.

하지만 RDS/Aurora는 자동화된 Snapshot 시스템이 기본이다.
Backup retention 기간, 스냅샷 암호화(KMS), Multi-AZ 여부,
Aurora cluster replication 구조 등이 실제 보안성을 결정한다.

따라서 “백업 정책 미흡” 같은 항목을 점검할 때도
온프렘 방식이 아니라 AWS Snapshot 구조를 기준으로 평가해야 한다.

---

7) 결론 — 이름만 MySQL이지, 평가 기준은 완전히 달라야 한다

KISA나 금보원 DB 진단 기준은 온프렘 DB 모델을 기반으로 만들어졌기 때문에
RDS/Aurora 같은 Managed DB에 동일하게 적용하면
의도치 않은 오탐이 대량으로 나온다.

그래서 컨설턴트는 다음 원칙을 가져야 한다.

1. 점검 목적은 유지
   • 최소 권한
   • 접근 통제
   • 로그 확보
   • 백업/복구 보장
2. 점검 방법은 AWS 환경에 맞게 재해석
   • 설정 파일 → Parameter Group
   • 로그 파일 → CloudWatch
   • 권한 점검 → AWS 관리 모델 기반
   • 네트워크 → SG/VPC 중심
   • 패치 → AWS 자동 업데이트 정책 확인
3. AWS 기능을 ‘대체 통제(Compensating Control)’로 명확히 문서화
   • 상위기관도 이 부분은 예외 인정

결론적으로, 같은 MySQL이라도
온프렘, RDS, Aurora는 완전히 다른 평가 기준을 적용하는 것이 맞다.

 

이미지 참고

---

📘 부록: 글에서 언급된 AWS 주요 서비스 설명

1) Amazon RDS

AWS가 운영을 대부분 대신해주는 Managed DB 서비스.
패치, 백업, 모니터링 등 인프라 부담을 줄여준다.
MySQL, PostgreSQL, Oracle 등 여러 엔진을 지원한다.

2) Amazon Aurora

AWS가 직접 설계한 고성능 MySQL/PostgreSQL 호환 DB.
스토리지 계층이 클러스터 기반이라 장애복구가 빠르고 고가용성이 뛰어나다.
권한·설정이 더 강하게 제한되는 대신 안정성이 높다.

3) Security Group (SG)

AWS의 가상 방화벽.
DB 접근 통제는 MySQL host 기반이 아니라 SG 설정이 핵심이다.

4) VPC

AWS 내부의 독립 네트워크.
DB가 Public/Private 어디에 위치하는지에 따라 보안성이 크게 달라진다.

5) CloudWatch Logs

RDS/Aurora의 slow log, error log 등을 저장하고 조회하는 서비스.
온프렘처럼 파일을 직접 확인할 수 없기 때문에 CloudWatch가 사실상 로그의 ‘원본’ 역할을 한다.

6) Parameter Group

RDS/Aurora의 설정값을 관리하는 기능.
my.cnf 파일을 대체하며, 변경 가능한 항목과 불가능한 항목이 명확히 나뉜다.

7) KMS

AWS의 암호화 키 관리 서비스.
DB 스냅샷, 저장 데이터, 백업 암호화를 담당하며 금융권 암호화 기준을 충족하는 핵심 요소다.