시크릿 관리

값을 코드 안에 적어 두는 것이 오랫동안 기본이었습니다. 짧고 확실하게 동작하기 때문입니다. 그 방식의 문제는 저장소를 열 수 있는 사람 전부가 그 값을 갖게 된다는 데 있습니다.

페이지덱에서 그 사실이 드러난 날이 있었습니다. 새로 들어온 개발자가 첫날 저장소를 내려받았는데 설정 파일 안에 운영 데이터베이스 비밀번호가 그대로 적혀 있었습니다. 3년 전에 급하게 넣고 잊은 줄이었습니다. 그 줄을 지우고 다시 올렸지만 끝나지 않았습니다. 지운 뒤에도 값은 커밋 이력에 남아, 과거 시점을 꺼내 보는 누구에게나 보였습니다.

되돌리기 어렵다는 점이 이 문제의 성격입니다. 이력에서 한 값을 완전히 지우는 일은 이력 전체를 다시 쓰는 작업이고, 이미 저장소를 내려받은 사람의 컴퓨터에는 손을 댈 수 없습니다. 그래서 유일한 답은 그 값을 무효화하고 새로 발급하는 것입니다. 처음부터 코드에 두지 않게 된 이유입니다.

코드 변경을 자동으로 검증하고 배포까지 잇는 CI/CD 아래에서 이 일은 구성 갈래에 놓입니다. 환경마다 다르게 꽂아 주는 설정 값인 환경 변수 가운데 새면 안 되는 것만 따로 떼어 다루는 자리입니다.

다섯 단계로 굴립니다.

1. 무엇이 시크릿인지 가릅니다. 알려져도 문제없는 값과 새면 안 되는 값을 나누는 일입니다. 결제 대행사의 주소는 알려져도 되는 설정이고 그 대행사에 요청을 보낼 때 쓰는 키는 시크릿입니다. 이 구분이 없으면 모든 값을 금고에 넣게 되고, 값 하나 바꿀 때마다 절차를 밟아야 해서 팀이 금고를 우회하기 시작합니다.
2. 전용 저장소에 넣습니다. 내용을 읽을 수 없게 바꿔 보관하고 누가 언제 어떤 값을 꺼냈는지 기록을 남기는 것이 이 저장소가 하는 일입니다. 기록이 남는다는 점이 파일에 적어 두는 것과의 차이입니다. 사고가 났을 때 무엇이 샜는지 범위를 좁힐 수 있습니다.
3. 실행 시점에 주입합니다. 프로그램이 뜰 때 환경 변수로 꽂아 주고 코드는 그 변수를 읽습니다. 값을 파일에 적어 빌드에 포함하면 빌드 결과물인 아티팩트 안에 그 값이 섞여 들어가고, 아티팩트는 여러 곳에 복사되므로 회수할 방법이 없습니다.
4. 권한을 사람이 아니라 역할로 줍니다. 스테이징 키는 개발자 전원이 꺼낼 수 있게 두고 운영 키는 배포 파이프라인만 꺼낼 수 있게 둡니다. 사람이 운영 키를 쥐어야 하는 상황 자체를 줄이는 것이 목적입니다.
5. 주기적으로 갈아 끼웁니다. 90일에 한 번처럼 기한을 정해 두고 새 값으로 바꿉니다. 바꾸는 일보다 바꿀 수 있는 상태를 유지하는 것이 목적입니다. 한 번도 갈아 본 적 없는 키는 정작 샜을 때도 바꾸지 못합니다. 누가 어디서 쓰는지 아무도 모르기 때문입니다.

샜을 때의 절차도 미리 적어 둡니다. 누가 어떤 순서로 무엇을 무효화하는지가 없으면 사고 당일에 그 순서를 정하느라 한 시간을 씁니다.

들여놓을 시점은 셋 중 하나가 처음 생길 때입니다. 환경이 둘 이상으로 갈릴 때, 코드를 만지는 사람이 셋을 넘을 때, 외부 결제나 데이터 저장소를 붙일 때입니다. 그전에는 값이 하나뿐이고 아는 사람도 하나라서 급하지 않습니다.

한계도 분명합니다.

1. 금고에도 열쇠가 필요합니다. 금고에 접근하는 자격 증명 하나는 어딘가에 있어야 하고, 그 하나는 같은 방식으로 보호할 수 없습니다. 실무에서는 이 한 겹을 기계에 부여된 신원으로 대체합니다. 클라우드가 서버마다 발급하는 신원을 쓰면 적어 둘 값 자체가 없어집니다.
2. 실행 중에는 평문입니다. 프로그램 메모리 안에서는 읽을 수 있는 상태라, 오류가 났을 때 그 값이 로그에 그대로 찍히면 금고가 한 일이 사라집니다. 로그에서 특정 이름의 값을 가리는 처리를 함께 걸어 둡니다.
3. 편의와 부딪힙니다. 로컬에서 개발할 때마다 금고를 거치면 느리고 인터넷이 끊기면 아무것도 못 합니다. 개발용으로는 권한이 좁은 별도 값을 쓰고 운영 값은 로컬에 내려오지 않게 막습니다.

내용을 읽을 수 없게 바꾸는 암호화와 겹쳐 보이지만 다루는 질문이 다릅니다. 암호화는 무엇으로 어떻게 바꿀지를 정하고, 시크릿 관리는 그 열쇠를 어디에 두고 누가 언제 꺼내는지를 정합니다. 암호화를 아무리 잘해 두어도 그 열쇠가 코드에 적혀 있으면 자물쇠와 열쇠를 한 봉투에 넣은 셈입니다.

"이 키 저장소에 들어 있어요. 지우는 걸로는 안 되고 무효화하고 새로 발급해야 합니다."

지운다고 없어지지 않는다는 지적입니다.

"운영 키는 파이프라인만 꺼낼 수 있게 해 두죠. 사람이 들고 있을 이유가 없어요."

권한을 역할로 주자는 제안입니다.

"오류 로그에 토큰이 찍히고 있어요. 마스킹 걸어야 합니다."

금고 밖으로 값이 새는 경로를 짚는 말입니다.

페이지덱에서는 태오가 저장소를 만들고 규원이 무효화 절차를 승인합니다. 키가 샜을 때 운영을 멈출지는 기술 판단이 아니라 사업 판단이라 규원이 정하고, 그 기준을 사고 전에 적어 두었습니다. 결제 키가 새면 즉시 무효화하고, 읽기 전용 조회 키가 새면 다음 배포에 맞춰 갈아 끼웁니다.

설정 파일을 저장소 제외 목록에 넣었으니 안전하다고 보는 경우가 가장 많습니다. 파일이 더 이상 올라가지 않으면 일이 끝난 것처럼 보입니다. 하지만 제외 목록은 앞으로 올라갈 것만 막습니다. 한 번이라도 올라간 값은 이력에 남아 있고, 그 이력은 저장소를 내려받은 모든 사람의 컴퓨터에 복사되어 있습니다. 이미 올라간 값에 대한 답은 제외가 아니라 무효화뿐입니다. 순서를 거꾸로 하면 목록만 정리한 채 살아 있는 키를 몇 달 더 방치합니다.

작은 팀에는 필요 없다고 여기는 것도 흔합니다. 셋이 만드는 제품에 금고까지 두는 것이 과해 보이기 때문입니다. 그런데 이 일의 필요는 사람 수가 아니라 값의 위험으로 정해집니다. 세 명이 만드는 제품도 고객 결제를 받는 순간부터 그 키 하나로 남의 돈을 움직일 수 있습니다. 나중에 들여놓는 비용이 처음부터 두는 비용보다 훨씬 큽니다. 이미 코드 스무 곳에 흩어진 값을 걷어내고 전부 무효화하고 다시 발급하는 작업은 며칠이 걸리고, 그 며칠 동안 배포가 멈춥니다.