Azure Key Vault

애플리케이션을 배포하려면 데이터베이스 비밀번호, 외부 API 키, 암호화 키 같은 민감한 값이 어딘가에 있어야 합니다. 가장 흔한 방법은 소스 코드나 환경 변수 파일에 넣는 것인데, 이 방식은 팀이 커질수록 위험이 커집니다. 실수로 Git에 커밋되거나, 서버에 SSH 접속한 사람이 파일을 열면 그대로 노출됩니다. 키를 교체해야 할 때는 값이 박혀 있는 모든 서버와 파이프라인을 하나씩 찾아다니며 바꿔야 하고, 누가 언제 그 값에 접근했는지 추적할 방법이 없습니다. 서비스 수가 늘어날수록 비밀 값의 산포도 함께 늘어나는 구조입니다.

초기 개발 환경에서는 환경 변수 파일이나 배포 스크립트 안에 비밀 값을 두는 것이 실용적인 선택이었습니다. 서비스가 한두 개일 때는 관리자가 어디에 무엇이 있는지 파악할 수 있었습니다. 그런데 마이크로서비스 아키텍처가 확산되면서 서비스마다 독립적인 배포 파이프라인이 생겼고, 비밀 값은 여러 저장소와 파이프라인에 분산됐습니다. 업계에서 공개 Git 저장소에 API 키가 노출되는 사고가 반복됐고, SOC 2나 PCI DSS 같은 컴플라이언스 기준은 '비밀 값의 위치와 접근 기록을 증명하라'는 요구를 명시하기 시작했습니다. 이 압력 속에서 비밀 값을 코드와 분리하고, ID 기반 인증으로 접근을 통제하며, 모든 조회를 감사할 수 있는 전용 저장소가 필요해졌습니다.

Key Vault는 저장 대상에 따라 세 가지 유형을 구분합니다. Secrets에는 API 키나 연결 문자열 같은 임의의 문자열을 넣고, Keys에는 암호화나 서명에 쓰이는 키 자체를 HSM으로 보호하며, Certificates에는 TLS 인증서를 저장하고 만료 전 자동 갱신을 처리합니다. 애플리케이션이 값을 꺼내려면 Entra ID로 자신의 신원을 먼저 증명해야 합니다. 권장 방식은 Managed Identity로, 코드에 자격 증명을 심지 않고도 Azure 플랫폼이 자동으로 토큰을 발급합니다. 토큰이 유효하면 Key Vault는 RBAC 규칙을 확인하고 요청된 값을 반환합니다. 값에는 버전이 붙어 있어서 교체 후에도 이전 버전으로 롤백할 수 있고, 자동 순환을 설정하면 주기적으로 새 버전이 생성됩니다. 모든 접근은 감사 로그에 기록되므로 '누가, 언제, 어떤 값을 읽었는가'를 나중에 추적할 수 있습니다.

App Configuration과 Key Vault는 둘 다 코드 밖에서 값을 관리하는 역할을 하지만, 다루는 데이터의 성격이 다릅니다. Key Vault는 유출되면 보안 사고로 이어지는 값을 HSM 보호와 세밀한 접근 제어로 다루는 데 맞춰져 있습니다. App Configuration은 기능 플래그나 환경별 설정값처럼 민감도가 낮은 구성 데이터를 빠르게 읽고 관리하는 데 더 적합합니다. 실무에서는 두 서비스를 같이 쓰는 경우가 많습니다. App Configuration에서 Key Vault 참조를 통해 비밀 값을 가져오는 구성이면, 설정과 비밀 값의 책임을 분리하면서도 애플리케이션은 단일 엔드포인트만 바라보게 됩니다. '이 값이 노출되면 보안 사고인가, 아니면 설정 오류인가'로 어느 쪽을 쓸지 구분할 수 있습니다. Key Vault가 적합하지 않은 경우는 대량의 데이터를 직접 암호화할 때입니다. 암호화 키를 보호하는 역할이지, 데이터를 직접 암호화하는 저장소가 아닙니다.

보안 요건이 생기기 시작한 팀에서 Key Vault가 처음 논의되는 시점은 대체로 비슷합니다. 배포 파이프라인에 DB 연결 문자열이 환경 변수로 박혀 있거나, 신입 개발자 온보딩 시 시크릿 파일을 메신저로 주고받는 상황이 보이면 도입을 검토할 때입니다. 이후에는 App Service의 앱 설정에 Key Vault 참조를 달아 런타임에 최신 값을 가져오거나, 컨테이너 환경에서 CSI 드라이버로 볼륨에 마운트하는 방식이 흔히 쓰입니다. 초당 수백 건 이상의 비밀 조회가 발생하는 서비스라면 SDK 레벨 캐싱을 함께 설계해야 합니다. Key Vault는 요청마다 네트워크를 타는 구조이기 때문에, 캐싱 없이 매 요청마다 조회하면 지연이 누적됩니다.