멘토 피드백에서 팀 인프라 레포(kintoun-infra)를 포트폴리오용으로 public 전환하는 게 권장됐다. 컴플라이언스 파트에서 사전 검토를 먼저 진행했고, 파일·코드 수준에서는 민감정보가 없다는 결론이 나왔다. 다만 검토 과정에서 한 가지 질문이 남았다.

Terraform 코드와 CI 로그에 남는 ARN은 지워야 하는 값인가?

"당연히 지워야지"라고 답하기는 쉽다. 하지만 그렇게 결론 내리면 왜 지워야 하는지, 지우고 나면 안전해지는지에 대해 아무것도 설명하지 못한다. AWS 공식 문서와 실제 공격 기법을 근거로 다시 따져봤다.

TL;DR

• AWS 공식 문서는 ARN과 계정 ID를 비밀·민감·기밀 정보로 분류하지 않는다.
• 그렇다고 "노출돼도 무해"한 건 아니다. 정확한 표현은 "노출을 전제로 방어가 성립해야 한다"이다.
• ARN을 알아야만 성립하는 공격 경로는 실제로 존재한다. 하지만 그 경로들의 취약점은 ARN 노출이 아니라 리소스 정책·신뢰 정책의 조건 부재다.
• 따라서 조치는 "ARN을 지운다"가 아니라 "ARN이 공개돼도 무해한 상태인지 검증한다"가 되어야 한다.

1. AWS는 뭐라고 하나

IAM 사용자 가이드의 ARN 설명 문단에 이런 문장이 있다.

ARN은 다른 식별 정보와 마찬가지로 신중하게 사용하고 공유해야 하지만, 비밀·민감·기밀 정보로 간주되지 않습니다.

계정 ID를 설명하는 Account Management 문서에도 토씨까지 같은 문장이 들어 있다. 우연이 아니다. 이 문구는 2022년 논쟁 이후 AWS가 문서를 명확히 하겠다고 밝히면서 정리된 결과다.

re:Post의 관련 아티클은 계정 ID 노출을 낮은 위험으로 분류하면서, 액세스 키 전면 회전이나 계정 이관 같은 대응은 과잉이라고 명시한다. 계정 ID를 전화번호에 비유한 표현이 적절하다. 나를 식별하지만, 안다고 해서 우리 집에 들어올 수 있는 건 아니다.

실제로 공개 생태계를 보면 이건 예외가 아니라 관행에 가깝다.

• Datadog 같은 SaaS 벤더는 크로스 계정 신뢰 관계 설정을 위해 자사 계정 ID를 공식 문서에 대놓고 공개한다. Scott Piper는 이런 벤더 계정 ID 목록을 별도로 관리해 왔다.
• Corey Quinn은 논쟁을 끝내겠다며 본인 계정 ID를 블로그 본문에 그대로 게시했다.
• Trivy 프로젝트는 "계정 ID를 시크릿으로 탐지하는 건 오탐"이라는 이슈를 통해 영향도를 낮음으로 정리했다.

AWS 공식 문서와 예제가 111122223333 같은 placeholder를 쓰는 것은 사실이다. 다만 이것이 민감정보라서인지, 독자가 실제 값으로 오인해 그대로 복사하는 것을 막기 위해서인지는 AWS가 명시한 적이 없다. 문서 본문의 명시적 문장이 더 강한 근거라고 봤다.