Claude Code와 유출 방지 대책: API 키를 남기지 않는 로그 구현

유출이 계속되는 지금, 개발 로그에 API 키까지 남기고 있지는 않은가?

나는 우선 요청 전체를 저장하는 것을 멈추고 싶다. 인증 정보까지 디버깅 자료로 삼는 것은 너무 부주의하다.

Anthropic의 9월 보고서에서는 Claude Code를 사용한 공격 워크플로우를 관측하고 있다. 이 회사는 적은 인원으로 넓은 범위까지 공격할 수 있게 되었다고 본다. 나는 구멍을 찾는 자동 처리 과정에, 결과를 읽고 다음 작업을 선택하는 역할까지 추가된 점에 주목한다. 국내 사건에서의 AI 이용은 확인이 필요하다.

10월 9일의 보도에서 다룬 IDCF 피해는 495개 기업/지자체에 영향을 미쳤다. 제3보에서는 일부 존(zone)의 데이터는 추출 및 복원이 어려울 전망이다. 공유 기반 시설이 멈추면, 각 이용자의 앱도 휘말린다. 495는 유출 건수가 아니다.

개인정보보호위원회의 자료는 MFA나 EDR을 예시로 들며, 불필요한 개인 데이터의 삭제도 촉구하고 있다. 우선 저장 항목을 좁힌다.

가상 데이터를 Python 3.14.8로 실행했다. log_demo.py에 저장하고, python3 log_demo.py로 구동한다.

def log_fields(d):
s = d["status"]
if type(s) is not int or not 100 <= s <= 599:
...

True
{'status': 200}

키 이름만 제외하고, 중첩된 Authorization이 남아있는 것을 확인했다. 허가한 숫자들만 재조립하면, 알 수 없는 항목도 저장되지 않는다. 타입(type)을 보는 것은 status 필드에 비밀 문자열을 넣는 우회로를 막기 위해서다. HTTP 상태 코드만의 최소 예시이므로, 조사용 항목은 용도별로 추가한다.

기존 로그나 SDK의 별도 로그에는 이 가공이 통하지 않는다. 개발용 키의 권한과 기한도 좁히고, 불필요한 복사본은 보관 의무나 조사 필요성을 확인하여 정리해야 한다. 감사 로그는 보호하며 남겨둔다. 오늘은 저장용 딕셔너리를 재조립한다.