시크릿 관리 입문: 하드코딩된 Access Key가 사고가 되기 전에

코드 속에 잠든 열쇠들

배포를 서두르다 보면 흔히 벌어지는 일이 있습니다. DB 비밀번호를 코드에 적어 두고 "나중에 정리하자"고 넘어가는 것이죠. OWASP Secrets Management Cheat Sheet가 지적하는 현실도 같습니다. 시크릿의 범위는 "API 키, 데이터베이스 크리덴셜, IAM 권한, SSH 키, 인증서 등"으로 넓어졌는데, 많은 조직에서 이것들이 소스코드에 평문으로 하드코딩되고, 설정 파일과 구성 관리 도구 곳곳에 흩어져 있습니다.

이 구조의 문제는 노출 반경입니다. 코드를 볼 수 있는 사람은 누구나 열쇠도 볼 수 있고, 저장소가 한 번 유출되면 서비스 하나가 아니라 인프라 전체의 열쇠 꾸러미까지 함께 나갈 수 있습니다. 한 단계 나은 선택으로 환경변수를 쓰기도 하지만, 이 역시 끝은 아닙니다. 환경변수는 대체로 모든 프로세스에서 접근 가능하고 로그나 시스템 덤프에 포함될 수 있어, 새어 나갈 경로가 남는 방식이기 때문입니다. OWASP도 도커 시크릿 관리 맥락에서, 다른 방법이 불가능한 경우가 아니라면 환경변수 사용을 권장하지 않는다고 명시합니다. 결국 질문은 하나로 모입니다. 열쇠를 코드와 서버 여기저기에 두지 않고, 어디에 모아 어떻게 관리할 것인가.

원칙은 네 가지: 중앙화·회전·최소 권한·감사

OWASP의 답은 명확합니다. 조직에는 시크릿의 "저장, 프로비저닝, 감사, 회전, 관리를 중앙화"할 필요가 커지고 있다는 것입니다. 이 중앙화 위에 얹히는 운영 원칙 가운데, 입문 단계에서 먼저 챙길 세 가지를 추리면 다음과 같습니다.

• 정기 회전(rotation): OWASP는 "훔친 크리덴셜이 짧은 시간만 유효하도록 정기적으로 회전하라"고 권고합니다. 주기는 시크릿의 기능에 따라 분 단위부터 연 단위까지 달라집니다. 단, 사람의 로그인 비밀번호는 예외입니다. OWASP는 NIST 권고에 따라 사용자 크리덴셜은 정기 회전 대상이 아니라 침해 의심·증거가 있을 때만 회전하라고 안내합니다.

• 최소 권한(least privilege): "엔지니어가 시크릿 관리 시스템의 모든 시크릿에 접근할 수 있어서는 안 된다"는 것. 시스템은 세분화된 접근 제어를 제공해야 합니다.

• 감사(auditing): 최소한 누가 어떤 시스템·역할을 위해 시크릿을 요청했는지, 요청이 승인됐는지 거부됐는지, 언제 누가(무엇이) 사용했는지를 남깁니다.

원칙 목록 밖의 기본기도 있습니다. OWASP는 시크릿을 로그에 남기지 말 것(평문이 찍히지 않도록 마스킹·암호화 적용)과 평문 전송 금지를 요구하고, 저장 단계의 암호화 역시 기본으로 둡니다.

도구로 내려가면: Vault와 AWS Secrets Manager

원칙을 손으로 지키기는 어렵습니다. 그래서 도구가 있습니다. HashiCorp Vault의 공식 소개는 "온프레미스, 클라우드, 하이브리드 어디에 배포하든 중앙화되고 잘 감사되는 권한·시크릿 관리를 제공한다"는 것입니다. 여러 클라우드와 온프레미스가 섞인 환경, 특정 클라우드에 묶이고 싶지 않은 조직에서 강점이 있습니다. 다만 HashiCorp 스스로도 시크릿 관리 요구가 단순한 조직에는 자체 운영 Vault가 과할 수 있다며 관리형 서비스부터 검토하라고 안내합니다.

AWS 중심 환경이라면 AWS Secrets Manager가 자연스럽습니다. 공식 문서 기준으로 이 서비스는 DB 크리덴셜, 애플리케이션 크리덴셜, OAuth 토큰, API 키 같은 시크릿의 관리·조회·회전을 담당합니다. 핵심 동작이 하드코딩 문제를 정면으로 겨냥합니다. 코드에 박힌 크리덴셜을, 필요할 때 시크릿을 받아 오는 런타임 호출로 대체하는 것입니다. 코드에는 더 이상 열쇠가 없고, 열쇠를 꺼내는 방법만 남습니다.

회전도 도구의 몫이 됩니다. Secrets Manager는 자동 회전 일정을 설정해 장기 시크릿을 단기 시크릿으로 대체할 수 있고(관리형 회전을 제외한 자동 회전은 Lambda로 실행되어 별도 과금), 크리덴셜이 애플리케이션과 함께 저장되지 않으므로 회전할 때 앱을 고쳐서 재배포할 필요가 없습니다. 한 가지 짚을 점은 도구의 분업입니다. AWS는 시크릿 종류별 권고를 구분합니다. AWS 자격 증명은 IAM, 암호화 키는 KMS, SSH 키는 EC2 Instance Connect, 인증서는 ACM. 모든 것을 한 통에 넣는 게 아니라, 종류에 맞는 관리 도구를 쓰는 것이 공식 권고입니다.

어디서 시작할까: 동적 시크릿까지 가는 길

이미 돌아가는 서비스에 시크릿 관리를 도입한다면 순서는 이렇게 잡을 수 있습니다.

• 1단계, 찾기: 코드 저장소·설정 파일·배포 스크립트에서 하드코딩된 시크릿을 찾아냅니다. OWASP는 탐지를 개발자 단계로 앞당겨 IDE나 pre-commit 훅에서 시크릿 탐지 도구(Yelp Detect Secrets 등)를 켜 두라고 권고합니다. 그리고 저장소 이력에 한 번 올라간 키는 커밋을 지워도 이력과 포크에 남을 수 있으므로, 발견 즉시 회전(무효화 후 재발급)이 원칙입니다.

• 2단계, 모으기: 새 키를 중앙 저장소(Vault·Secrets Manager)에 두고, 애플리케이션은 런타임 조회로 전환합니다. AWS는 하드코딩된 시크릿을 Secrets Manager로 옮기는 이전 절차를 별도 튜토리얼로 안내합니다.

• 3단계, 돌리기: 자동 회전을 걸어 장기 시크릿을 단기로 바꾸고, 최소 권한과 감사 로그를 설정합니다. 중앙화의 대가도 설계에 넣어야 합니다. OWASP는 시크릿 관리 서비스가 불능이 될 가능성에 대비하라며, 비상용(break-glass) 크리덴셜을 보조 시스템에 안전하게 백업해 두라고 권고합니다.

• 4단계, 동적으로: OWASP는 "가능한 곳에서는 동적 시크릿을 사용해 크리덴셜 재사용의 표면적을 줄이라"고 권고합니다. 필요할 때 생성되고 수명이 지나면 만료되는 방식이라, 애플리케이션의 DB 크리덴셜이 탈취되더라도 재기동 시점에는 이미 만료되어 쓸 수 없게 되는 식입니다.

시크릿 관리는 한 번의 프로젝트가 아니라 운영 습관에 가깝습니다. 다만 출발점은 분명합니다. 지금 코드 저장소에 열쇠가 몇 개나 잠들어 있는지 세어 보는 것. 그 숫자가 0이 아니라면, 오늘이 가장 이른 시작일입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)