비밀번호를 채팅에 흘렸다 — 그 후 30분 룰

실수는 일어난다. 터미널 명령어를 복사해서 채팅에 붙여넣다가 비밀번호가 포함된 연결 문자열이 그대로 들어간다. 로그에 쿼리 파라미터가 찍히다가 세션 토큰이 흘러나온다. 우리도 그런 일을 겪었고, 그때 당황해서 무엇을 먼저 해야 할지 몰랐던 경험이 지금의 절차를 만들었다.

왜 30분인가

노출된 자격증명의 위험은 시간이 지날수록 커진다. 채팅 기록이 다른 사람에게 공유될 수 있고, 로그가 외부에 접근 가능한 곳에 저장될 수 있다. 30분은 “발견하자마자 처리한다”를 팀이 공유하기 쉬운 시간 단위로 표현한 것이다. 규칙이 없으면 “나중에”가 며칠이 되기도 한다.

처리 순서

1단계 — 즉시 무효화: 노출된 자격증명을 교체하거나 비활성화한다. 비밀번호라면 지금 바로 변경한다. API 키라면 즉시 폐기하고 새 키를 발급한다. 채팅 메시지를 삭제하거나 로그를 지우는 것은 두 번째다. 무효화가 먼저다.

2단계 — 노출 범위 파악: 해당 자격증명이 어디에 쓰였는지 확인한다. 채팅 플랫폼이라면 공유된 채널의 범위, 로그라면 누가 접근할 수 있는 저장소인지를 본다. 외부에 노출됐을 가능성이 있으면 접근 로그도 확인한다.

3단계 — 의존하는 곳 업데이트: 변경한 자격증명을 쓰는 애플리케이션, 스크립트, CI 파이프라인의 환경 변수를 새 값으로 교체한다. 이 단계를 빠뜨리면 서비스가 중단된다.

4단계 — 팀 공유: 무슨 일이 있었고 어떻게 처리했는지를 팀에 알린다. 처벌이 아니라 기록과 학습이 목적이다. 같은 채널에서 반복되지 않도록 유출 경로를 확인하고 개선점을 남긴다.

예방 쪽에서 바꾼 것들

사후 처리보다 예방이 낫다. 우리가 바꾼 것들이다.

• 연결 문자열이나 자격증명을 직접 붙여넣는 대신 환경 변수 이름을 공유한다
• 터미널 히스토리에 비밀번호가 남는 명령어 패턴을 팀이 공유하고 피한다
• 로그 레벨 설정에서 쿼리 파라미터 로깅을 운영 환경에선 끈다

실수가 없는 팀보다 실수에 빠르게 대응하는 팀이 현실적인 목표다.

— by slecs