이걸 공유하면 안 될 텐데: 2026년에 여전히 노출된 AWS 키를 찾아내는 37가지 Google Dork 패턴
Source: Dev.to
결코 해결되지 않는 로딩 바
브라우저 탭에서 절반 정도 멈춰버린 로딩 바. 깔끔하게 해결되지 않고, 마치 너무 많이 생각하고 있는 듯 그 자리에 그냥 머무르는 종류. 그 뒤 어딘가에, 수년 전 색인된 공개 페이지가 아직도 접근 가능하고, 조용히 존재한다.
노출에 대한 오해
이것이 대부분의 사람들이 노출을 오해하는 지점이다. 그들은 침해를 사건—폭발, 헤드라인—으로 상상한다. 실제로는 지속성이다: 한 번도 정리되지 않은 오래된 아티팩트, 빌드 환경 밖에서 보일 의도가 없었던 인증 문자열이 이제는 절대 잊지 않는 검색 인덱스에 남아 있다.
AWS가 프레임에 들어오다
- 목표물로서가 아니라.
- 인프라 중력으로서.
AWS 자격 증명이 얼마나 자주 공개 표면에 유출되는지 이해하면, “해킹”이라는 관점에서 생각을 멈추고 절대 꺼지지 않은 검색 시스템이라는 관점으로 생각하게 된다. 그리고 한 번 보면 눈을 뗄 수 없다.
Google 색인은 수동적이지 않다. 이는 조각들로부터 공개 웹을 지속적으로 재구성하는 과정이다.
위험한 이유는 정교함이 아니라 단순함이다. 개발자들은 로그, 저장소, 붙여넣기 사이트, 잘못 구성된 버킷, CI 출력물 등에 흔적을 남긴다. 그 흔적들은 색인된다. 원래 의도가 사라진 뒤에도 오래 지속된다.
AWS 자격 증명은 이 생태계에서 특히 취약한데, 이는 구조적으로 인식 가능하기 때문이다. 패턴을 따르고, 로그에 기록되며, 삽입되고, 검색 엔진이 볼 수 있는 곳에 복사된다.
공격자는 여기서 창의성이 필요하지 않다. 대규모 패턴 인식이 필요할 뿐이다. 나머지는 잡음 필터링에 불과하다.
“Google Dork”의 신화
Google dork라는 용어는 오해의 소지가 있습니다. 영리함을 암시하지만 실제로는 예측 가능한 인간 실수에 대한 구조화된 쿼리일 뿐입니다.
근본적인 논리는 언제나 동일합니다: 절대로 인덱싱돼서는 안 되는 콘텐츠를 찾아내는 것.
AWS 자격 증명의 경우, 이는 보통 몇 가지 반복되는 노출 유형으로 압축됩니다:
- 자격 증명 조각이 포함된 공개 로그
- 하드코딩된 키가 들어 있는 소스 코드
- CI/CD 출력 덤프
- 잘못 구성된 S3 목록 또는 XML 오류
- Paste‑style 덤프 및 디버깅 메모
이 각 카테고리는 검색어로 설명될 수 있습니다—마법 문자열이 아니라 구조적 지문입니다.
실제 자격 증명을 찾아내는 정확한 쿼리를 재현하지는 않을 것입니다. 이는 직접적인 촉진에 해당하기 때문입니다. 중요한 점은 더 간단하고 불편합니다:
검색 방법 자체는 전혀 이색적이지 않습니다. 노출 자체가 대부분의 작업을 수행합니다.
37개의 고유한 트릭이 있다고 가장하기보다는 같은 메커니즘의 37가지 변형—다른 필터, 다른 파일 유형, 다른 상황—을 이해하는 것이 더 정확합니다. 동일한 기본 검색 동작이 적용됩니다.
노출 클러스터
다음과 같이 클러스터링되는 경향이 있습니다:
- 자격 증명 언어 패턴은 공개 저장소와 문서 유출에서 나타납니다. 일반적으로 환경 변수 덤프나 공개될 의도가 없었던 구성 파일과 연결됩니다.
- 키 서명 패턴은 로그와 코드 아티팩트에 나타납니다. 시스템은 디버깅이나 배포 중에 식별자를 읽을 수 있는 형태로 출력하는 경우가 많습니다.
- 인프라 명명 패턴은 클라우드 관련 파일에서 드러나며, 특히 개발자가 운영 구성 파일을 실수로 커밋할 때 나타납니다.
- 백업 및 내보내기 패턴은 데이터베이스 덤프, JSON 내보내기, 일시적으로 호스팅되었지만 인덱싱 가능한 위치에서 제거되지 않은 아카이브 파일에 존재합니다.
- 서비스 통합 패턴은 AWS가 타사 시스템에 연결되고 자격 증명이 통합 로그나 웹훅 페이로드를 통해 유출될 때 나타납니다.
각 클러스터는 속임수가 아닙니다. 이는 다른 복장을 입은 실패 모드입니다.
37개의 별도 “덕”이 존재한다는 생각은 대부분 서술상의 편의일 뿐입니다. 실제로 존재하는 것은 적대적인 인덱싱을 가정하도록 설계되지 않은 시스템 전반에 걸친 반복입니다.
왜 이것은 사라지지 않는가
- 클라우드 개발은 기본적으로 빠릅니다.
- 보안 정리는 기본적으로 느립니다.
개발자들은 환경, 파이프라인, 스테이징 시스템, 빠른 테스트를 순환합니다. 키는 폐기되는 것보다 더 빨리 생성됩니다. 로그는 정제되는 것보다 더 빨리 공유됩니다.
하나의 실수만으로 충분합니다: CI 파이프라인에서 디버그 출력이 남는 경우. 일단 인덱싱되면, 제거는 코드 문제가 아니라 2차 시스템 문제가 됩니다. 그리고 2차 시스템 문제는 내용이 오래 남는 곳입니다.
불편한 진실은 검색 엔진이 새로운 유출을 발견하는 것이 아니라; 기존 유출을 다시 발견하고 있다는 것입니다. 이는 “2026년 실시간 AWS 키”에 대한 허위의 새로움 느낌을 만들죠. 키 자체는 새롭지 않으며, 접근 경로도 새롭지 않습니다. 지속되는 것은 인덱싱입니다.
이것이 대부분의 사람들이 놓치는 차이점입니다.
- 노출된 키는 숨겨져 있기 때문에 가치가 없는 것이 아니라.
- 여전히 유효하기 때문에 가치가 있습니다.
그리고 유효성은 주의 지속 시간보다 오래 살아남는 경향이 있습니다.
방어 자세
방어 측에 있다면, 대응은 똑똑한 검색이 아니라 인덱싱을 가능하게 하는 조건을 제거하는 것입니다. 대부분의 사고는 같은 지루한 해결책으로 무너집니다:
- 커밋 전 자격 증명 스캔, CI 수준에서 강제 적용.
- 침해를 전제로 하는 회전 정책, 신뢰가 아니라.
- 기본적으로 출력을 공개된 것으로 간주하는 로깅 위생.
- 잘못된 구성이 일반적이라고 가정하고 구성된 스토리지 버킷, 드물지 않음.
한 줄 요약 기준
- 모든 저장소를 인덱싱될 것처럼 취급한다
- 모든 로그를 외부로 전달될 것처럼 취급한다
- 모든 자격 증명을 이미 한 번 복사된 것처럼 취급한다
- 모든 임시 저장 위치를 영구적인 노출 위험으로 취급한다
이것이 기본 기준입니다. 그 외는 최적화일 뿐입니다.
자동화: 양날의 검
자동화가 이러한 격차를 해소할 것이라는 기대가 있었습니다. 그렇지 않았습니다. 대신 자동화는 속도를 높였습니다:
- 배포가 더 많아짐
- 임시 환경이 더 많아짐
- 시간당 생성되는 자격 증명이 더 많아짐
- 신중하게 제어되지 않는 곳에 구조화된 출력을 내보내는 로깅 시스템이 더 많아짐
검색 인덱싱은 단순히 그 속도를 따라갔습니다.
여기에는 극적인 실패가 없습니다. 단일 취약점 클래스도 없습니다. 단지 규모와 부주의가 상호 작용할 뿐입니다.
마무리 생각
핵심은 예측 가능한 방식으로.
시스템은 현대적이다. 실수는 오래되었다.
사람들이 “AWS 키를 위한 Google dorks”에 대해 이야기할 때, 이는 해킹 기법을 설명하는 것이 아니다.
그들은 공개적으로 조회 가능한 운영 부주의의 지도를 설명하고 있다.
불안한 부분은 접근이 아니라 가시성이다.
노출을 이해하는 데 필요한 모든 것은 이미 인터넷의 표면 레이어에 존재한다—숨겨진 것 없고, 이색적인 것 없으며.
그저 한 번도 정리되지 않은 흔적들일 뿐이다.
이를 마무리하고, 깔끔한 도덕적 경계나 책임·인식에 대한 진술로 끝내고 싶은 유혹이 있다.
그것은 부정확할 것이다.
여기서는 아무것도 깔끔하게 해결되지 않는다. 비밀을 노출하는 동일한 시스템이 사람들이 매일 의존하는 인프라를 구축하고, 위험을 초래하는 동일한 속도가 현대적인 배포를 가능하게 한다.
당신은 그것을 이해했다고 해서 사라지지 않는 긴장감을 남게 된다.
그리고 그 긴장감 어딘가에, 잊혀진 로그 파일에 아직도 존재하는 인증 문자열이 있다. 아직도 색인되고, 기술적으로 유효하며, 특정한 누군가를 기다리고 있다.