마이크로소프트 SAS 토큰 노출: 권한 범위와 대응

공개 GitHub 저장소에 올라온 URL은 AI 모델 파일을 내려받게 하려는 것이었습니다. 그런데 URL에 포함된 Azure Storage 공유 액세스 서명(SAS)은 그보다 넓은 접근을 허용했습니다. 이 사고에서 봐야 할 것은 링크가 발견됐다는 사실만이 아니라, 그 링크가 스토리지 계정에서 무엇을 할 수 있었는지입니다.

Microsoft와 Wiz가 확인한 사실

Wiz는 해당 링크로 모델 파일 외에 약 38TB의 데이터에 접근할 수 있었다고 보고했습니다. 여기에는 퇴사자 두 명의 업무용 컴퓨터 백업과 내부 Teams 메시지 3만 건 이상이 포함됐습니다. Wiz는 읽기뿐 아니라 쓰기와 삭제 권한도 확인했습니다. 이는 접근 가능했던 자료와 권한을 조사한 결과입니다. 제삼자가 그 데이터를 모두 내려받거나 모델을 변조했다는 증거는 아닙니다.

Microsoft도 과도한 권한의 SAS URL을 통해 Wiz가 내부 정보에 접근했다고 확인했습니다. 고객 데이터는 노출되지 않았고 다른 내부 서비스도 위험하지 않았다는 것이 Microsoft의 조사 결론입니다. Wiz는 2023년 6월 22일 신고했고, Microsoft는 6월 24일까지 토큰을 폐기하고 외부 접근을 차단했다고 밝혔습니다. 공개 자료만으로 더 넓은 악용 여부를 단정할 수는 없습니다.

탐지에도 실패 지점이 있었습니다. Microsoft는 과거 저장소 검사에서 그 URL을 찾았지만 결과가 오탐으로 잘못 분류됐다고 밝혔습니다. 이후 원인을 고치고 권한이나 만료 기간이 과도한 SAS를 더 잘 찾도록 탐지 범위를 넓혔습니다. 발견 결과를 닫기 전에 실제 권한 범위를 확인할 절차가 필요한 이유입니다.

소스코드에서 SAS URL을 발견했다면

1. 저장소 위치, 커밋, 발견 시각을 기록하세요. 서명 전체를 티켓이나 채팅에 옮기지 말고 완전한 URL에 대한 접근을 제한하세요. 유효한 SAS URL을 가진 사람은 그 URL에 부여된 권한을 사용할 수 있습니다.

2. 스토리지 담당자와 URL 및 SAS 매개변수를 확인하세요. 리소스 경로와 SAS 종류를 구분하고, 서명된 서비스·리소스 유형 또는 리소스, 권한, 만료 시점, 프로토콜, IP 제한을 살펴야 합니다. 계정 SAS와 서비스 SAS의 범위는 다릅니다. URL 경로만 보고 권한 범위를 판단하지 마세요.

3. SAS 종류와 서명 키에 맞게 폐기하세요. 저장된 액세스 정책에 연결된 서비스 SAS는 정책을 바꿔 폐기할 수 있습니다. 계정 키로 서명한 임시 SAS는 키 교체가 필요할 수 있으며 다른 서비스도 영향을 받으므로 교체 순서를 계획해야 합니다. 사용자 위임 SAS에는 별도의 위임 키 폐기 절차가 있습니다. 이전 URL이 더는 작동하지 않는지 확인하되, 요청 한 건의 실패를 전체 조사의 결론으로 삼지 마세요.

4. Azure Storage 요청 로그를 미리 설정해 보관했다면 SAS 인증 요청, 수행한 작업, 요청 IP, 시간대, 객체 변경을 확인하세요. SAS 인증만으로 사람의 신원을 알 수는 없습니다. 알려진 클라이언트와 대조하고, 로그가 없거나 보존 기간 밖인 부분은 한계로 기록하세요. 다른 저장소나 문서에 복사된 같은 URL도 찾으세요.

탐지가 답할 수 없는 것

Cremit은 설정한 지원 소스에서 자격증명 패턴을 검사하고 발견 건을 담당자의 검토로 연결합니다. SAS 형태의 URL 발견은 조사 시작점이지 스토리지 계정 전체 권한 지도나 악용 증거가 아닙니다. 서명 범위 확인, 폐기, 발급처 로그 조사는 Azure 스토리지 담당자의 작업입니다. 이 사고는 발견 결과를 권한 검토와 실제 조치에 연결해야 한다는 점을 보여 줍니다.