번들이 실은 비밀 키, 프런트에서 남는 흔적들

환경변수에 키를 숨겨두면 안전하다는 믿음은 프런트엔드에서 특히 위험하다. 사실을 뒤집어 보자. 서버 환경변수는 런타임까지 도달하면 그나마 보호되지만, 브라우저에서 실행되는 번들은 빌드 시점에 값이 굳어버린다. .env라는 이름이 주는 안도감 뒤에는 번들 파일, 로그 한 줄, 커밋 히스토리라는 세 개의 뚫린 문이 대기하고 있다.

번들은 포장된 게 아니라 낱개로 풀려 있다

dotenv로 키를 읽어 프런트에 넘기는 흔한 패턴을 떠올려 보라. 빌드 도구는 그 값을 모듈 안의 문자열 리터럴로 치환한다. 어느 시점에 주입되든 결과물은 같은 접근 권한을 갖는다. grep -rl "sk-" dist/ 한 줄이면 끝이 난다.

여기서 많이 오해한다. 난독화를 하면 된다고 믿는 순간이 오는데, 난독화는 이름을 바꿀 뿐 값은 그대로다. 롤백, 청크 분리, 캐시 부스팅으로 감추는 것도 분리된 모듈을 합치면 전부 노출된다. 원칙은 하나다. 브라우저로 내려가는 값은 반드시 공개라고 간주하고 관리해야 한다. 인기 포털급 규모의 사이트들에서 번들에 API 엔드포인트와 함께 스트리밍 키가 통째로 박혀 나간 사례를 실제로 찾아볼 수 있다.

그렇다면 프런트에서 필요한 키는 어디 두나. 별도 인증 서버를 두거나, 키를 절대 프런트로 보내지 않고 브라우저에서 받은 요청만 백엔드가 대신 수행하는 BFF 구조로 가야 한다. 키가 도저히 클라이언트에 필요한 경우엔 키를 직접 두지 말고, 권한이 최소화된 별도 계정이나 만료가 짧은 단기 토큰을 발급받는 방향으로 설계한다.

일부 값은 아무리 해도 피할 수 없다. 퍼블릭 SDK 키처럼 원래 공개되는 것은 상관없다. 문제는 이를 관리 키와 같은 .env 파일에 나란히 두는 습관이다. 키가 문서상으로든 주석으로든 "민감하지 않음"과 "절대 금지"를 한 파일에서 관리하면, 열람 권한을 나눌 수 없다. 민감도별로 파일을 나누고 빌드에서 주입되는 경로 자체를 분리하는 게 장기적으로 낫다.

로그 한 줄이 곧 유출

서버 쪽은 다른 문이 열린다. 시크릿이 코드 어디에도 없는 데도 터지는 경우가 대부분 여기서 시작된다. 나머지 공통 원인은 디버그 로깅이다. 요청 본문이나 쿼리 인자를 통째로 찍는 개발용 로그를 운영에 그대로 두면, 키가 인자로 흘러 들어가는 순간 함께 로그로 남는다.

구체적인 경로를 짚어 보자. 통상 세 지점이 흔하다. 첫째, URL 쿼리스트링에 ?key=... 꼴로 키를 태우는 경우. 이 값은 접속 로그, 리퍼러 헤더, 브라우저 기록, 프록시 캐시에 동시에 남는다. 둘째, 예외 스택 트레이스에 시크릿이 문자열로 포함되는 경우. 셋째, CI 로그에 빌드 인자를 그대로 출력하는 경우. 셋째가 덜 알려진 흥미로운 지점이다. CI 환경변수로 넣은 값은 쉘 확장 과정에서 명령어 인자로 노출될 수 있고, set -x나 export 같은 디버그 플래그가 켜져 있으면 그대로 찍힌다.

로그 정책은 프런트보다 감시가 쉬운 편이다. 시크릿이 남는 형식을 정규표현식으로 걸러내는 필터를 로그 수집 파이프라인 맨 앞에 두라. 문자열 자체를 마스킹하는 것만으로는 부족하다. 매칭된 로그는 사후 검토를 위해 별도로 수집하고, 접근을 제한해야 한다. 키처럼 보이는 값을 로깅하는 패턴을 발견하면 바로 CI 단계에서 실패로 만들어 버리는 게 빠르다.

git log -p가 마지막 문이다. 이건 파일 룰로도 완전히 막기 어렵다. .gitignore에 .env를 넣었다가 git add -f로 강제로 밀어 넣는 순간, 히스토리에 영원히 남는다. 뒤늦게 지우고 다시 커밋해도 이미 공개되어 있으면 도로다. 커밋 이력 전체를 다시 써야 하는 filter-repo 작업은 비용 대비 효과가 좋지 않다.

그보다는 들어가지 못하게 막는 게 앞선다. 커밋 훅에서 시크릿 패턴을 탐지하고, 누락분은 CI preseason 스캔으로 잡는다. 도구 선택도 중요하다. 정규식 기반 도구는 키가 다른 형식(sk-, AKIA, ghp_)이면 놓치기 쉽다. 시크릿 탐지 도구는 패턴이 고정된 것보다 연속적인 키 탐지나 대량 시크릿 탐지를 지원하는 쪽이 훨씬 실용적이고, 결과를 후킹해서 merge를 막는 식의 연동이 필요하다. 이건 상황에 따라 다르다. 팀이 등록한 시크릿 형식이 몇 개 안 되면 정규식으로 충분하고, 형식이 제각각이면 고도화된 스캐너가 필요하다. 기준은 팀이 예전에 실제로 잃어버린 형식의 수다.

유출 뒤에는 토큰을 믿지 말 것

어디서 샜든 공통 동작이 하나 있다. 사고 당시 유일하게 유효한 조치는 즉시 폐기(detach)다. 시크릿이 공개됐다면 이미 공격자가 썼을 가능성을 가정해야 한다. 절대 "이번 건 우연히 안 보였을 것"이라는 판단에 기대면 안 된다. 토큰이 그 사이 실제로 사용됐는지를 감사 로그로 확인하는 것은 늦은 검증이다.

절차 순서를 정해 두자. 먼저 해당 키의 권한을 즉시 회수하고, 둘째로 나머지 키 전부를 회전(rotation)한다. 하나만 새 키로 바꿔치고 다른 것을 놔두면, 같은 사고를 두 번 겪는다. 회전이 끝난 뒤에야 영향 범위를 판단한다. 어떤 인증 키가 새어났는지, 어느 시점부터인지, 누가 접근했을 수 있는지 함께 정리한다.

여기서 사람들이 자주 놓치는 부분은 무결성 검사를 회로에 붙여 두는 것이다. 사고를 막는 것보다 사고를 자동으로 감지하는 게 실제로는 더 빈번하게 작동한다. 한 예로, 특정 사용자명과 함께 쓰였는지, 자주 틀리는지 같은 로그 패턴을 모니터링하다가 의심스러운 접근이 감지되면 알림을 보내고 토큰을 자동으로 폐기시키는 워크플로를 CI에 붙일 수 있다. 로테이션 주기도 강제해야 한다. 만료 없는 장수 토큰은 아무리 길어도 위험 수준이 높다. 몇 주나 몇 달 단위로 자동 회전하는 잡을 두고, 사람이 기억하지 않아도 돌아가게 만들어 두면 사고 이후의 절차가 절반은 사라진다.

새 키를 배포할 때도 무결성 확인은 계속 필요하다. 교체된 키가 실제로 저장소에 들어갔는지(되지 않아야 하는 지점에), 비밀 관리 서비스에만 존재하는지 빌드 때 마다·배포 때마다 명시적으로 검증한다. 시크릿 관리 툴에 저장했다고 해서 자동으로 확보되는 게 아니다. 조회권한, 배포 권한, 로그 접근 권한이 각각 분리되어 있는지도 별도의 점검 항목으로 본다.

운영 환경에서 시크릿을 다룰 때는 형편과 규모를 고려한 선택이 필요하다. 폴리시 시크릿 관리 서비스를 도입하는 건 작은 팀이나 단일 서비스에는 과할 수 있다. 그 대신 환경변수를 불러오는 계층을 하나 두고, 로컬에서는 파일, 서버에서는 시크릿 서비스에서 몯역로 불러오게 분리하는 정도로 시작해도 충분하다. 처음부터 서비스를 강제하기보다, 실제로 키를 볼 수 있는 지점(개발 PC, CI, 서버)이 각각 얼마나 넓은지를 먼저 그려 보고 결정하는 게 맞다.

가장 그럴듯한 실패를 하나만 꼽자면, "다 회전했으니 됐다"고 믿는 순간이다. 회전은 사고의 시작점이지 끝이 아니다. 회전이 끝나면 반드시 각 지점—번들, 로그, 히스토리, 그리고 저장소 밖의 캐시—에 값이 흩어졌는지 한 번 더 뒤져야 한다. 번들은 소스 대신 단계별 아티팩트에서, 로그는 라이브가 아닌 보관된 백업에서, 커밋은 HEAD가 아닌 전체 이력에서 검색해야 한다. 이 세 곳 어디에서도 안 나올 때, 그때 사고를 마감한다. 찾는다는 기대보다 못 찾는다는 기대를 하고 뒤져라. 그래야 놓치는 일이 줄어든다.

댓글

댓글을 읽어오는 중입니다.