핵심: 정보의 이름만 보고 위험을 정하기보다, 노출되면 무엇을 할 수 있는지와 실제 접근 조건을 확인한다.
한눈에 보는 흐름
왜 배웠는가?
인프라 저장소를 포트폴리오로 공개하는 방향이 제안되면서, ARN·계정 ID·설정 파일·실행 로그를 어디까지 공개할 수 있는지 조사했다.
핵심 개념
- ARN: AWS 리소스를 구분하는 이름·주소.
- 자격증명·시크릿: API 키, 비밀번호, 개인키처럼 접근에 직접 쓰일 수 있는 값.
- Secret Scanning: 코드·커밋에 비밀값이 섞였는지 찾는 검사.
- Push Protection: 비밀값이 저장소에 올라가는 시점에 막는 기능.
- 커밋 이력: 현재 파일을 수정해도 과거 내용이 남을 수 있는 기록.
조사에서 달라진 판단
처음 질문은 “ARN을 전부 지워야 하나?”였다. 여러 조원의 글은 식별정보 노출과 권한을 사용할 수 있게 하는 조건을 나눠 검토했다.
운영 계정·리소스 이름은 불필요한 노출을 줄이고 코드 재사용성을 위해 일반화할 수 있다. 동시에 키·토큰, IAM 신뢰 조건, 저장소와 실행 로그를 함께 점검해야 한다는 방향으로 정리가 구체화됐다.
실제 기록 · 현재 코드에서 과거 기록까지
장혜리의 9월 22일 Gitleaks 글에는 116개 커밋을 검사했고 기본 규칙에서 탐지된 시크릿이 0건이었다고 기록돼 있다.
이 결과의 범위는 그 시점의 커밋과 검사 규칙이다. ARN·실행 로그·과다 권한까지 모두 안전하다는 판정은 아니다.
함께 점검한 사각지대
- Actions 로그: 파일을 검색하는 것만으로 실행 중 출력된 값을 확인할 수는 없다.
- Variables / Secrets: 변수를 사용한다고 출력이 자동으로 가려지는 것은 아니다.
- Terraform state·운영 설정: 코드 외에도 실제 리소스 값과 비밀정보가 담길 수 있는 자료를 확인한다.
- CI 권한·외부 PR: 공개 저장소의 변경 제안을 어떤 권한으로 실행할지 검토한다.
자동 검사로 연결한 방향
조사 글들은 로컬 검사, CI 검사, 업로드 단계의 차단을 비교했다. Gitleaks 적용 방안도 작성됐다. 이 자료는 자동 검사 도입 방안을 다루며, 최종 활성화 결과까지 포함하지는 않는다.
배운 점
“검색해서 안 나왔다”는 결과에 검사 대상·규칙·시점·빠진 범위를 붙이면 판단이 더 정확해진다.
원문과 작성자
- 팀 IaC 레포 보호를 위한 자동화 솔루션 조사 — 작성자 미기재
- Gitleaks 적용 방안 — 오병은
