API 키는 아직도 .env에 있나요?
크레덴셜 관리, 이렇게 터집니다
최근 잇따른 대형 해킹사고의 공통점은
정교한 제로데이 공격이 아니라
자격증명 관리 실패입니다.
2026년 상반기에만 수천만 건 규모의 개인정보 유출 사고가
여러 건 발생했습니다.
원인을 파보면 놀라울 정도로 단순합니다.
만료 없이 발급된 토큰, .env에 하드코딩된 API 키,
퇴사자에게 회수하지 않은 접근 권한.
공격자는 취약점을 찾을 필요도 없었습니다.
열려 있는 문으로 걸어 들어갔을 뿐입니다.
왜 이렇게 많이 터지는가
자격증명(credential) 관리가 어려워서가 아닙니다.
급해서, 귀찮아서, 나중에 하려다가 터집니다.
하드코딩
“빨리 테스트해야 하니까 일단 코드에 넣자.”
그 코드가 커밋되고, PR이 머지되고, 프로덕션에 배포됩니다.
Git 히스토리에는 영원히 남습니다.
만료 없는 장기 토큰
한 번 발급하면 1년, 2년, 혹은 영구 유효한 토큰.
유출되면 공격자가 원하는 만큼 사용할 수 있습니다.
발급한 사람은 퇴사했고, 토큰이 있는지조차 모릅니다.
과다 권한
“권한 에러 나면 귀찮으니까 전체 권한 주자.”
읽기만 필요한 서비스에 관리자 권한을 부여합니다.
그 토큰이 유출되면 전체 시스템이 장악됩니다.
퇴사자 토큰 미회수
계정은 비활성화했지만 발급한 토큰은 살아 있습니다.
PAT(Personal Access Token), SSH Key, API Key.
퇴사 후에도 리포, 클라우드, 내부 시스템에 접근 가능합니다.
시크릿이 새어나가는 5가지 경로
1. Git 히스토리
.env를 .gitignore에 추가해도
이미 커밋된 히스토리에는 남아 있습니다.
공개 레포라면 봇이 수 초 내에 수집합니다.
GitHub에서만 매년 수백만 건의 시크릿이 탐지됩니다.
2. CI/CD 로그
빌드 로그에 환경변수가 찍힙니다.
echo $DATABASE_URL을 디버깅용으로 넣고
빌드 로그가 팀 전체에 공개되어 있습니다.
3. 에러 메시지와 스택트레이스
DB 연결 실패 시 커넥션 스트링이 에러에 포함됩니다.
사용자에게 노출되는 500 에러 페이지에
비밀번호가 그대로 찍히는 경우도 있습니다.
4. 협업 도구 공유
슬랙 DM으로 API 키를 보내고,
노션 페이지에 서버 비밀번호를 적어두고,
구글 시트에 접속 정보를 정리합니다.
검색 한 번이면 누구나 찾을 수 있습니다.
5. AI 도구
Copilot에 코드를 붙여넣으면서 API 키를 함께 전송합니다.
MCP 서버의 도구 호출 로그에 토큰이 기록됩니다.
AI가 생성한 코드에 예제 API 키가
실제 키처럼 보이는 형태로 포함됩니다.
토큰 관리 원칙
단기 토큰 + 자동 갱신
토큰 유효 기간은 최대한 짧게 설정합니다.
유출되어도 만료 시간이 지나면 쓸 수 없습니다.
갱신은 사람이 하는 게 아니라 시스템이 자동으로 합니다.
최소 권한 원칙
필요한 권한만 부여합니다.
읽기만 필요하면 읽기만, 특정 리포만 필요하면 그 리포만.
“편하니까 전체 권한”은 사고의 시작입니다.
시크릿 매니저 사용
.env 파일이 아닌 전용 시크릿 매니저에 보관합니다.
HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager 등.
코드에서 시크릿을 직접 참조하지 않고,
런타임에 시크릿 매니저에서 가져오는 구조입니다.
정기 로테이션
시크릿은 주기적으로 교체합니다.
90일이 일반적이고, 민감한 시스템은 30일.
자동화하지 않으면 실행되지 않습니다.
Git 접근 권한 관리
Git 저장소는 소스코드뿐 아니라
인프라 설정, 배포 파이프라인, 시크릿 히스토리까지
조직의 핵심 자산이 모여 있는 곳입니다.
| 방식 | 범위 | 만료 | 권장 |
|---|---|---|---|
| Classic PAT | 계정 전체 또는 대범위 | 선택적 (영구 가능) | 사용 자제 |
| Fine-grained PAT | 리포 단위, 권한 세분화 | 필수 (최대 1년) | 권장 |
| SSH Key | Git 작업 전용 | 수동 관리 | 개인 개발용 |
| GitHub App / Deploy Key | 리포 또는 조직 단위 | 토큰 자동 갱신 | CI/CD 권장 |
실무 권장사항
· Classic PAT 대신 Fine-grained PAT 사용 (리포 단위 권한)
· CI/CD에서는 GitHub App 또는 Deploy Key 사용
· PAT 만료를 90일 이하로 설정
· 퇴사 시 PAT, SSH Key, Deploy Key 전수 회수
· GitHub Secret Scanning 활성화
클라우드 자격증명 관리
AWS, GCP, Azure에서
장기 Access Key를 발급받아 .env에 넣는 건
가장 위험한 패턴 중 하나입니다.
장기 Access Key의 위험
유출되면 만료될 때까지(또는 영원히) 사용 가능합니다.
.env, Docker 이미지, CI 로그 어디에서든 노출될 수 있고,
한 번 유출되면 S3 버킷 전체가 공개되거나
EC2 인스턴스에서 암호화폐 채굴이 시작됩니다.
대안: IAM Role + 임시 자격증명
EC2, ECS, Lambda에서는 IAM Role을 할당합니다.
Access Key가 아예 존재하지 않으므로 유출 가능성이 없습니다.
외부에서 접근이 필요하면 AWS STS로
유효 기간이 짧은(15분~12시간) 임시 토큰을 발급합니다.
클라우드 자격증명 원칙
· 장기 Access Key 발급 최소화 (가능하면 0개)
· 서비스에는 IAM Role 할당, 사람에게는 SSO + MFA
· 불가피한 Access Key는 90일 로테이션 자동화
· 미사용 키 자동 탐지 및 비활성화
· CloudTrail/Audit Log로 API 호출 추적
OAuth 2.0 vs 2.1, 뭐가 달라졌나
OAuth 2.1은 새로운 프로토콜이 아니라
2.0의 보안 모범 사례를 필수(MUST)로 격상한 것입니다.
지금까지 “하면 좋다”였던 것이 “해야 한다”가 됐습니다.
| 항목 | OAuth 2.0 | OAuth 2.1 |
|---|---|---|
| PKCE | 권장 (공개 클라이언트만) | 필수 (모든 클라이언트) |
| Implicit Grant | 허용 | 폐지 |
| Resource Owner Password | 허용 | 폐지 |
| Refresh Token Rotation | 권장 | 필수 |
| Redirect URI 정확 매칭 | 권장 | 필수 |
왜 2.1로 가야 하는가
Implicit Grant는 토큰이 URL에 노출됩니다.
브라우저 히스토리, 리퍼러 헤더, 프록시 로그에 남습니다.
PKCE 없는 Authorization Code Grant는
인가 코드 가로채기(interception) 공격에 취약합니다.
2.1은 이런 “알려진 위험”을 구조적으로 차단합니다.
MCP 서버에서 OAuth를 적용한다면
반드시 2.1 기준으로 구현하세요.
MCP 보안 설계 체크리스트에서 다룬 내용과 직접 연결됩니다.
자동화할 수 있는 것들
시크릿 스캐닝
Git 커밋, CI 로그, Docker 이미지에서
API 키, 토큰, 비밀번호 패턴을 자동 탐지합니다.
GitHub Secret Scanning, GitLeaks, TruffleHog 등.
키 로테이션 자동화
AWS Secrets Manager, Vault의 자동 로테이션 기능.
사람이 기억할 필요도, 수동으로 바꿀 필요도 없습니다.
미사용 자격증명 탐지
90일 이상 사용하지 않은 Access Key, PAT, SSH Key를
자동으로 탐지하고 비활성화합니다.
AWS IAM Credential Report, GitHub Audit Log 활용.
크레덴셜 관리 체크리스트
코드에 하드코딩된 시크릿이 없는가?
☐.env 파일이 .gitignore에 포함되어 있는가?
☐Git 히스토리에 과거 커밋된 시크릿이 남아 있지 않은가?
☐모든 토큰에 만료 기간이 설정되어 있는가? (최대 90일)
☐토큰별로 최소 권한만 부여되어 있는가?
☐시크릿이 전용 매니저(Vault, Secrets Manager)에 보관되어 있는가?
☐CI/CD에서 시크릿이 빌드 로그에 노출되지 않는가?
☐퇴사자의 토큰, SSH Key, PAT이 모두 회수되었는가?
☐시크릿 스캐닝 도구가 활성화되어 있는가?
☐키 로테이션이 자동화되어 있는가?
☐대부분의 해킹사고는
공격자가 뛰어나서가 아니라
방어가 기본을 못 지켜서 발생합니다.
크레덴셜 관리는 그 “기본” 중에서도
가장 기본입니다.
위의 10개 항목 중 하나라도 빠져 있다면
지금 바로 점검하세요.
공격자는 기다려주지 않습니다.
본 글은 리원에이스 기술개발본부가 작성한 기술 콘텐츠입니다. 외부 공유 시 출처를 명시해 주세요.
2026년 8월 19일
리원에이스 기술개발본부