진행중인 PII 보호를 중점으로 하는 프로젝트에서 사용자의 개인정보는 온프레미스 환경에 저장하고, 클라우드에는 식별자(ID)만 전달합니다.
이 아키텍처에서는 온프레미스 환경 기반의 보안 저장소를 구축하여, DB 비밀번호 등 시스템 내 주요 credentials을 안전하게 관리할 필요가 있는데 . . . 이를 위해 HashiCorp Vault를 알게되어 도입하였으며, 애플리케이션 측에서 필요한 credential 를 안전하게 가져올 수 있도록 AppRole 인증 방식을 적용했습니다.
참고로 HashiCorp Vault는 기본적으로 웹 기반 UI도 지원하지만 저는 처음 Vault를 접해보기도 했고, 그냥 터미널에서 진행했습니다. . .
1. 컨테이너 환경 vs OS상 직접 설치
요즘 많이들 애플리케이션을 컨테이너로 띄우는게 일반적이지만, Vault 공식 문서에서 최대한 안정적이고 보안을 중시하는 프로덕션 환경에서는 직접 OS/VM에 Vault를 설치해서 운영하는 방식을 추천한다고 해서 직접 설치해서 실행하였습니다.
https://developer.hashicorp.com/vault/tutorials/day-one-raft/raft-deployment-guide
2. Vault & AppRole
2.1 Vault?
우선적으로 PII DB에 접근하기 위한 DB 관련 credentials를 어디에 보관해야 할지 하다가 선택한 솔루션입니다.
- ❌ 환경변수: 서버가 털리면 파일 시스템에서 바로 조회 가능.
- ✅ Vault: 애플리케이션이 "필요한 순간에만" 비밀번호를 요청해서 메모리에 잠시 들고 있다가 사라짐. 접근 로그(Audit)까지 남음.
2.2 AppRole?
사람은 ID/PW를 입력해서 로그인하지만, 앱 서버가 어떻게 Vault에 로그인 할지 정해야합니다.
Vault 기반 환경에서 가장 표준적으로 사용되는 M2M(Machine-to-Machine) 인증 방식이 바로 AppRole입니다.
AppRole은 인증 정보를 아래 두 개로 분리합니다:
- Role ID: 아이디와 유사 (덜 민감함, 배포 스크립트에 포함 가능)
- Secret ID: 비밀번호와 유사 (매우 민감, CI/CD 파이프라인을 통해 주입)
이 두 가지가 합쳐져야만 Vault 토큰을 발급받을 수 있습니다!
3. 구축
3.1: KV 엔진 활성화 및 시크릿 저장
먼저 비밀번호를 저장할 공간(KV Engine)을 만들고, 실제 DB 계정 정보를 저장했습니다.
3.2: 정책(Policy) 생성
아무나 비밀번호를 보면 안 되므로, secret/pii-db 경로를 "읽기(Read)"만 가능한 정책을 만들었습니다.
3.3: AppRole 설정 및 ID 발급
AppRole 인증을 활성화하고, 앞서 만든 정책을 연결했습니다.
설정이 완료된 후, 애플리케이션이 사용할 Role ID와 Secret ID를 발급받았습니다.
3.3: AppRole 로그인
설정이 정상적으로 동작하는지 검증하기 위해, 발급받은 ID를 사용하여 Vault 로그인을 시도했습니다. 이 과정이 성공해야만 앱이 DB 비밀번호를 가져올 수 있습니다.
이제 애플리케이션 서버에서 이 AppRole을 사용하여 Vault에서 비밀번호를 동적으로 받아와 MySQL에 접속하는 과정을 구현하고 테스트를 통해 검증해보면 될거같습니다!!
4. 테스트 및 검증
Vault 설정이 완료되었으므로, 실제로 "애플리케이션 시작 -> Vault 인증 및 DB 암호 획득 -> DB 연결 -> PII 데이터 저장"의 전체 흐름이 정상적으로 동작하는지 최종 검증을 진행했습니다.
4.1 API 호출 테스트 (Tokenization)
먼저 앱 서버에서 앱 컨테이너를 구동시켰습니다. 컨테이너 로그상에서 Vault 로그인 및 MySQL 연결 성공 메시지를 확인한 뒤, 간단하게curl 명령어를 통해 실제 PII 데이터(이름, 여권번호) 저장을 요청해보았습니다.
이 테스트가 성공하려면 애플리케이션이 AppRole을 통해 Vault에서 동적으로 DB 접속 정보를 받아와야만 합니다.
4.2 DB 저장 데이터 확인
마지막으로 DB 서버에 접속해서 데이터가 실제로 테이블에 잘 들어갔는지 확인하였습니다!
