자격증명 노출이 의심된다면? 유출 대응법

자격증명 노출이 내부 침해로 이어지는 과정

클라우드 서비스와 DevOps 기반 개발 환경에서는 다양한 자격증명이 사용된다. 클라우드 환경에 접근하는 Access Key, 외부 서비스와 연동하는 API Key, GitHub 저장소에 접근하기 위한 Personal Access Token(PAT) 등이 대표적이다.

이런 자격증명은 소스코드에 직접 입력하거나 환경설정 파일을 저장소에 올리는 과정에서 또는 메신저나 이메일, Jira, Wiki 등 협업 도구로 자격증명을 공유한 기록이 외부에 노출되는 경우도 있다. 개발자 단말이 악성코드에 감염되거나 신뢰하기 어려운 IDE 확장 프로그램 설치로 인해 자격증명이 탈취될 가능성도 배제할 수 없다.

공격자는 확보한 자격증명으로 GitHub 저장소나 클라우드 환경에 접근할 수 있다. 이후 소스코드와 설정 정보를 확인하고 추가 자격증명을 수집하거나 권한을 확대해 내부 시스템으로 횡적 이동할 수 있다. 나아가 CI/CD 환경까지 장악할 경우 악성코드를 배포하는 공급망 공격으로 이어질 가능성도 있다.

파일 삭제만으로는 충분하지 않은 이유

GitHub 저장소에 자격증명이 포함된 파일을 실수로 올린 뒤 해당 파일을 삭제하거나 새로운 커밋으로 덮어쓰더라도 안심해서는 안 된다. Git은 변경 이력을 관리하기 때문에 과거 커밋에 자격증명이 그대로 남아 있을 수 있다.

Git Filter-Repo나 BFG Repo-Cleaner 등을 이용해 저장소 이력을 정리할 수 있지만, 이미 외부에서 저장소를 복제했다면 노출된 정보를 회수하기 어렵다. 따라서 자격증명 노출이 확인됐거나 의심되는 경우에는 저장소에서 관련 내용을 삭제하는 데 그쳐서는 안 된다.

가장 먼저 해야 할 조치는 기존 자격증명을 즉시 폐기하고 새로운 값으로 재발급하는 것이다. GitHub PAT뿐 아니라 소스코드에 포함돼 있던 데이터베이스 계정과 비밀번호, AWS Access Key, Azure Service Principal, Google Cloud Service Account Key, API Key, SSH Key, 인증서 및 기타 서비스 계정 등도 모두 새로운 값으로 교체해야 한다.

감사 로그에서 비정상적인 활동 점검

자격증명 노출이 의심된다면 GitHub와 클라우드 환경의 감사 로그를 확인해 침해 가능성을 점검해야 한다. GitHub 계정과 조직의 Audit Log 및 Security Log를 검토하고, 최근 1~3개월 동안 평소와 다른 접근이나 관리 행위가 있었는지 확인해야 한다.

다음과 같은 기록이 확인되면 비정상 활동 여부를 주의 깊게 살펴봐야 한다.

• 평소 접속하지 않던 국가 또는 IP 주소에서 로그인한 기록
• 단시간 내 다수 저장소를 조회하거나 Clone한 기록
• 업무 시간 외(심야·주말)에 대량의 Push 또는 다운로드가 수행된 기록
• Personal Access Token(PAT) 생성 또는 재생성 기록
• OAuth App 승인 또는 GitHub App 설치 기록
• Deploy Key 또는 Repository Secret 변경 기록

클라우드 환경에서는 AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs 등의 감사 로그를 분석해 다음과 같은 이상 행위가 있었는지 확인해야 한다.

• IAM 사용자 또는 Access Key 생성
• 역할(Role) 생성 또는 권한 정책 변경
• STS AssumeRole 호출 증가
• Secrets Manager 또는 Key Vault 접근 증가
• 대량의 클라우드 리소스 생성
• 보안 정책(Security Group, Firewall 등) 변경

재발 방지를 위한 보안 권고 사항

1. 자격증명 관리 체계 강화
   소스코드에 자격증명을 직접 입력하는 하드코딩을 금지하고, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault 등의 비밀정보 관리 솔루션을 활용하면 필요한 자격증명을 실행 시점에 안전하게 불러와 사용해야 한다.
   또한, 환경설정 파일(.env)과 인증서, 개인키 등이 저장소에 업로드되지 않도록 .gitignore를 설정하고 지속적으로 점검해야 한다. GitHub Secret Scanning과 Push Protection 기능을 활성화하고, Private 및 Internal Repository에도 해당 기능이 적용돼 있는지 반드시 확인해야 한다. 메신저, 이메일, Jira, Wiki 등 협업 도구를 통한 자격증명 공유는 금지하고, 과거 공유 이력도 함께 점검해야 한다.
2. 임시 자격증명 및 최소 권한 원칙 적용
   장기간 사용되는 Access Key는 사용을 최소화하고 IAM Role, OIDC Federation, Workload Identity처럼 일정 시간이 지나면 자동으로 만료되는 임시 자격증명을 활용하는 것이 바람직하다. GitHub와 클라우드 콘솔, 데이터베이스, CI/CD 시스템 등 주요 정보 자원에는 다중인증(MFA)을 적용해 계정 탈취 위험을 줄여야 한다. PAT(Personal Access Token)는 필요한 저장소와 권한 범위에 한해서만 발급하고, 업무상 필요하지 않은 전체 저장소 접근 권한은 부여하지 않아야 한다.
3. 접근통제 및 개발 환경 보안 강화
   GitHub 조직과 클라우드 관리 콘솔에는 가능한 경우 IP Allow List나 VPN 기반 접근통제를 적용해 허용된 네트워크에서만 접근할 수 있도록 구성해야 한다.
   개발자 단말은 최신 보안 패치를 유지하고, VS Code 등 IDE 확장 프로그램과 오픈소스 패키지는 신뢰할 수 있는 배포처에서 설치해야 한다. 악성코드 감염이나 정보 탈취를 막기 위해서는 안랩 V3, EDR, MDS, XDR 등 엔드포인트 보안 솔루션을 운영하고 이상 행위를 지속적으로 모니터링하는 것도 필요하다.
4. 개발 및 운영 프로세스 개선
   코드 리뷰 과정에서는 자격증명이 포함돼 있는지 확인하는 절차를 운영하고, Secret Scanning 도구를 활용해 저장소를 주기적으로 점검해야 한다. 장기간 사용 중인 Access Key와 API Key, PAT 등에 대해서는 정기적인 교체 정책을 수립하고, 더 이상 사용하지 않는 자격증명은 즉시 폐기해야 한다.
   또한 오픈소스 의존성과 CI/CD 파이프라인 보안도 정기적으로 점검해 공급망 공격 가능성을 줄이고, 개발자를 대상으로 자격증명 관리 및 안전한 개발보안에 대한 교육을 지속적으로 실시해야 한다.

클라우드 환경에서는 자격증명 하나가 노출되는 것만으로도 소스코드 저장소와 클라우드 인프라, 데이터베이스, 배포 시스템을 잇는 공격 경로가 될 수 있다. 노출이 의심될 때는 파일 삭제보다 자격증명 폐기와 재발급을 먼저 수행하고, 감사 로그를 통해 추가 침해 여부를 확인해야 한다. 최소 권한과 임시 자격증명 사용, 정기적인 교체와 모니터링을 통해 자격증명 중심의 보안 관리 체계를 강화해야 한다.