운영 중인 WordPress 블로그의 Amazon RDS for MySQL이 저장 시 암호화되지 않은 상태였습니다. RDS는 기존 인스턴스의 암호화를 제자리에서 켤 수 없기 때문에 스냅샷 복사와 새 인스턴스 복원, 애플리케이션 엔드포인트 전환이 필요했습니다. 이번 작업에서는 저장 시 암호화뿐 아니라 WordPress와 RDS 사이의 전송 구간도 TLS로 강제했습니다.
전환 전 확인한 항목
- WordPress 코어와 주요 공개 URL의 정상 응답
- 게시물과 옵션 테이블의 레코드 수
- 기존 DB 엔드포인트와 파라미터 그룹
- 애플리케이션이 TLS 옵션으로 접속할 수 있는지
- 문제 발생 시 기존 엔드포인트로 되돌릴 수 있는 설정 백업
RDS 저장 시 암호화 전환 흐름
- 기존 비암호화 RDS의 수동 스냅샷 생성
- AWS 관리형 RDS KMS 키를 사용해 스냅샷을 암호화 복사
- 암호화된 스냅샷에서 새 RDS 인스턴스 복원
- 보안 그룹과 파라미터 그룹 연결 상태 확인
- 새 엔드포인트로 TLS 접속 및 데이터 건수 비교
- WordPress의 DB 엔드포인트 전환
- 글 조회와 옵션 쓰기·읽기·삭제 테스트
- 충분한 검증 후 기존 RDS와 임시 스냅샷 삭제
MySQL TLS를 선택이 아닌 필수로
새 파라미터 그룹에는 require_secure_transport=ON을 적용했습니다. 이 설정에서는 암호화되지 않은 MySQL 연결이 서버에서 거절됩니다. WordPress의 mysqli 연결에는 SSL 클라이언트 플래그를 사용했고, 실제 세션의 TLS cipher가 설정되는지 확인했습니다.
define( 'MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL );초기에는 인증서 검증까지 한 번에 강제하려 했지만 현재 PHP/MySQL 클라이언트 구성과 맞지 않아 WordPress 연결이 실패했습니다. 즉시 해당 플래그를 되돌리고 서비스 복구 후, 지원되는 SSL 연결 방식과 RDS 서버 측 강제를 조합했습니다. 보안 설정도 실제 런타임 호환성을 확인하며 단계적으로 적용해야 한다는 점을 다시 확인했습니다.
전환 후 검증
- 새 RDS가
StorageEncrypted=true인지 확인 - 파라미터 그룹이
in-sync인지 확인 - 평문 MySQL 연결이 거절되는지 확인
- WordPress 부트스트랩과 관리자 로그인 페이지 확인
- REST API, robots.txt, 카테고리와 개별 글 HTTP 200 확인
- 테스트 옵션의 생성·조회·삭제 확인
삭제는 검증 이후에
새 인스턴스가 정상이라고 표시되는 것만으로 기존 DB를 바로 삭제하지 않았습니다. WordPress에서 실제 조회와 쓰기 테스트를 수행하고 브라우저 화면까지 확인한 뒤 기존 RDS를 삭제했습니다. 마이그레이션 중에 만든 임시 스냅샷도 비용 정책에 맞춰 마지막에 정리했습니다.
백업 정책에 대한 별도 판단
이 개인 블로그는 비용을 고려해 RDS 자동 백업과 PITR을 의도적으로 사용하지 않고 있습니다. 이는 암호화와 별개의 가용성·복구 정책입니다. 일반적인 업무 시스템이라면 자동 백업과 복구 시점 목표를 먼저 정하는 편이 안전하며, 이 글의 선택을 그대로 적용하기보다 데이터 중요도와 비용을 함께 판단해야 합니다.
마무리
이번 전환으로 RDS 저장 데이터는 KMS로 암호화되고, WordPress와 MySQL 사이에는 TLS가 강제됩니다. 가장 중요했던 부분은 새 자원을 만드는 명령보다 전환 전후의 검증 순서와 되돌릴 기준을 명확히 정한 것이었습니다.