오늘의 핵심
엔비디아의 AI 개발 클라우드 Brev에서 무단 활동이 확인돼 고객 가상머신용 SSH 키가 노출됐을 가능성이 제기됐다. 키는 교체됐지만, 이용 기업은 기존 키의 사용 흔적과 연계 자격증명을 별도로 점검해야 한다.
확인된 사실
왜 중요한가
SSH 키는 개발·운영 서버에 직접 접근할 수 있는 자격증명이므로 플랫폼 측 교체만으로 과거 접근과 후속 행위에 대한 검증이 끝나지 않는다.
외부 개발 플랫폼이 자동 생성한 키가 다른 서버, 저장소 또는 자동화 작업에도 등록됐다면 사고 영향 범위가 원래 서비스 밖으로 확장될 수 있다.
AI·클라우드 개발 환경에는 소스코드와 API 토큰, 모델 자산이 함께 모이므로 단일 접근키 노출이 여러 자산의 위험으로 이어질 수 있다.
inxight의 관점
이번 사고의 핵심은 특정 공급업체보다 ‘누가 키를 만들고 어디까지 배포했는가’를 기업이 즉시 파악할 수 있어야 한다는 점이다.
서비스 제공자의 키 교체 통보를 대응 완료로 간주하지 말고, 키의 신뢰 대상과 접속 기록, 인스턴스 내부 자격증명을 하나의 범위로 묶어 조사해야 한다.
개발 편의를 위해 플랫폼이 자동 관리하는 자격증명도 기업의 자산 목록과 퇴출 절차에 포함해야 한다.
실무 체크리스트
- Brev 이용 여부와 통지 수신 여부를 확인하고, 모든 대상 인스턴스에 새 SSH 키만 등록돼 있는지 검증한다.
- 10월 4일 이후의 SSH 인증·명령 실행·파일 변경 기록에서 낯선 IP, 계정, 공개키 지문과 지속성 설정을 점검한다.
- 기존 키가 등록됐던 저장소, 배포 서버, CI/CD 작업과 점프 호스트를 찾아 신뢰를 제거하거나 키를 교체한다.
- 대상 인스턴스에 저장된 API 토큰과 클라우드 자격증명의 권한·사용 이력을 확인하고 필요하면 폐기 후 재발급한다.
- 외부 개발 플랫폼이 생성하는 키와 토큰의 소유자, 유효기간, 사용처를 중앙 자산 목록에 등록한다.