심야 배포 중 증발한 접근 키, 메신저 기술 감사 로그로 추적선 잠근 IT 스타트업

지난해 3분기 정보보호관리체계(ISMS) 본심사를 앞둔 클라우드 관리 서비스(MSP) 스타트업 A사는 운영 서버 접속용 일회용 비밀번호(OTP) 발급 키가 메신저 개발 채널에 평문으로 게시됐다는 외부 지적을 받았다. 배포 주기와 온콜(긴급 장애 대응) 근무가 겹친 심야 시간대에 발생한 일이었다. 누가 어떤 권한으로 해당 토큰을 내려받아 적용했는지 메신저 내부 기록을 역추적하려 했으나, 작성자가 대화를 삭제한 뒤여서 접근 경로 소명에 사흘이 걸렸다.

이 사건을 계기로 A사는 전사 메신저를 도입하며 대화방 내 텍스트 수정 및 삭제, 파일 내려받기, 외부 인입 웹훅(Webhook) 호출 내역을 별도 스토리지에 격리 보관하는 기술 감사 로그 체계를 가동했다.

삭제된 메시지와 토큰도 기록에 남겨

IT 스타트업의 개발 현장은 지속적 통합·배포(CI/CD) 파이프라인과 인프라 모니터링 봇이 사내 메신저와 긴밀하게 묶여 돌아간다. 서버 장애가 감지되면 모니터링 시스템이 메신저 채널에 오류 로그와 함께 데이터베이스(DB) 접근 임시 크레덴셜을 쏘아 올리고, 담당 엔지니어가 이를 복사해 터미널에 접속하는 식이다.

문제는 이 과정에서 생성되는 민감 정보가 대화방에서 휘발되거나 임의로 수정될 때 발생한다. A사가 구축한 감사 로그는 엔지니어가 메신저 화면에서 특정 메시지를 지우거나 첨부된 구성 파일(Config YAML)을 내려받아도 해당 행위의 타임스탬프와 출발지 IP, 원본 텍스트를 감사 관리자 화면에 즉시 적재한다.

A사 보안인프라팀 팀장은 "온콜 엔지니어가 새벽 장애 복구 중에 메신저로 주고받은 핫픽스 스크립트나 API 키는 사고 후 원인 분석의 핵심 근거가 된다"며 "화면에서 지워졌더라도 감사 데이터베이스에는 원본 페이로드가 남아 있어야 사후 포렌식이 성립한다"고 말했다.

외부 협력사 연동 채널의 권한 분리

기술 중심 조직 특성상 오픈소스 라이브러리 유지보수자나 고객사 엔지니어가 게스트 계정으로 개발 채널에 참여하는 일도 빈번하다. 메신저 감사 체계는 게스트 계정이 채널 내 공유된 환경변수 예시 파일이나 시스템 아키텍처 다이어그램을 내려받을 때 별도의 감사 태그를 부여하도록 했다.

일반 업무 채널과 프로덕션 인프라 제어 채널의 로그 수집 정책도 분리했다. 단순 잡담이 오가는 채널은 검색 주기만 관리하지만, 배포 봇이 물려 있는 채널은 텍스트 변경 이벤트가 발생하는 즉시 보안 감사 전용 S3 버킷으로 해시값과 함께 전송된다.

실시간 탐지와 데이터 보존 비용의 균형

감사 로그 구축 후 사후 소명 절차는 체계화됐으나, 운영 측면에서 조율해야 할 과제는 남아 있다. 개발 봇이 초 단위로 쏟아내는 시스템 메트릭과 에러 스택 트레이스까지 전부 원문 보존할 경우 스토리지 비용이 급증하고 유의미한 감사 신호를 골라내기 어려워진다.

A사는 현재 모니터링 알림의 텍스트 본문은 메타데이터 위주로 축약 저장하고, 사람 간의 대화나 파일 입출력 로그만 장기 보존소로 분기하는 필터링 룰을 다듬고 있다. 암호화 키 관리 규정과의 정합성을 맞추는 작업도 다음 분기 점검 항목으로 잡혀 있다.

※ 본 기사의 사례는 도입 현장에서 반복적으로 확인되는 상황을 바탕으로 재구성한 것이다.