Vercel 보안 사고는 단순한 또 하나의 클라우드 보안 침해 뉴스에 그치지 않습니다. 이는 현대의 공격이 생산 인프라를 직접 악용하기보다는, 신뢰할 수 있는 SaaS 관계, 악용된 신원 경로, 간과된 접근 가정에서 시작되는 경우가 점점 더 많아지고 있음을 보여주는 실제 사례입니다.
보안 및 IT 팀에게 있어 진정한 교훈은 단순히 고객 데이터가 유출되었을지도 모른다는 사실에만 있는 것이 아닙니다. 보도에 따르면, 공격자가 타사 통합 시스템을 통해 내부 환경으로 매우 신속하게 침투할 수 있었기 때문에, 피해 범위를 파악하는 것이 가장 큰 과제가 되었다고 합니다.
이번 사건은 OAuth를 통해 내부 리소스에 대한 접근 권한을 부여받은, 직원이 승인한 제3자 애플리케이션을 통해 내부 시스템에 무단으로 접근한 것으로 보입니다.
일부 고객 데이터와 특정 접근 관련 정보가 유출된 것으로 알려졌으며, 영향을 받은 고객들에게는 Vercel이 지정한 특정 토큰이나 비밀 키를 교체할 것을 권고받았습니다.
아직 초기 단계임에도 불구하고, 이번 사건은 거의 모든 기업에 중요한 세 가지 문제를 부각시키고 있습니다. 즉, 신원 정보가 공급망의 일부로 점점 더 깊이 자리 잡고 있으며, “비기밀” 데이터조차도 공격자에게 운영적 가치가 있을 수 있고, 대응 속도는 엔드포인트, 신원 정보, SaaS 연동 워크플로우 전반에 걸친 가시성에 달려 있다는 점입니다.
베르셀 보안 사고에서 무슨 일이 있었는가
Vercel은 에서 이번 보안 사고가 OAuth를 통해 기업 ID 계정에 연결된 제3자 애플리케이션과 관련된 침해 사건에서 비롯되었다고 밝혔습니다. 보도에 따르면, 공격자는 그곳에서 직원 계정에 접근한 뒤 회사 내부 환경의 일부로 침투 범위를 확대한 것으로 알려졌다.
이 일련의 과정이 중요한 이유는, 이것이 기존의 경계 침투 방식이 아닌, 제3자 SaaS 통합 및 위임된 접근 권한에 의해 형성된 새로운 공격 패턴을 반영하기 때문입니다:
- 신뢰할 수 있는 제3자 앱이 기업 계정에 연결되어 있습니다.
- OAuth 토큰 액세스를 통해 신뢰 관계가 악용됩니다.
- 직원이 승인한 OAuth 권한 부여를 통해 접근 가능한 리소스는 직원의 기기에 악성코드가 침투해 있을 필요 없이 접근할 수 있습니다.
- 내부 시스템이 빠르게 열거됩니다.
- 인증 정보, 환경 변수 또는 관련 데이터가 다음 단계의 활용 수단이 됩니다.
이와 같은 신원 기반 침입은 통제 수단과 원격 측정 데이터가 여러 팀과 도구로 분산되어 있을 경우 조기에 탐지하기 어려울 수 있습니다.
서로 다른 통제 수단은 종종 동일한 사건의 서로 다른 측면을 포착합니다. ID, 엔드포인트, SaaS 및 클라우드 텔레메트리 데이터를 상호 연관시킴으로써 팀은 전체 활동 체인을 재구성하고 침입이 어떻게 진행되었는지 파악할 수 있습니다.
이 사건이 특히 주목할 만한 이유는 누가 피해를 입었는지가 아니라, 보안 침해 사태가 어떻게 전개되었는지에 있다.
이 사건이 한 기업을 넘어 중요한 이유는 무엇인가
Vercel 보안 사고가 중요한 이유는, 이 사건이 공격자들의 수법이 더 광범위하게 변화하고 있음을 보여주기 때문입니다.
보안 팀은 이제 기기, 서버, 코드 저장소뿐만 아니라 SaaS 플랫폼, 개발자, 클라우드 ID, 자동화 도구를 연결하는 권한 구조까지 방어하고 있습니다.
[클로드 코드(Claude Code) 소스 유출 사건이 AI 개발 도구 관련 위험에 대해 무엇을 드러내는지, 그리고 기업들이 다음으로 무엇을 검토해야 하는지 알아보세요]
OAuth는 이제 매우 위험한 공격 경로가 되었습니다.
OAuth 연동은 사용상의 불편함을 줄여주기 때문에 유용합니다. 또한 사용자와 조직으로부터 신뢰를 물려받을 수 있기 때문에 위험합니다. 공격자가 승인된 연동 기능을 악용할 경우, 팀이 계정을 직접 탈취하는 데 의존하는 일부 통제 수단을 우회할 수 있습니다.
이전에 발급된 OAuth 토큰은 만료되거나 취소될 때까지 계속 사용할 수 있으며, 각 하위 API 호출 시마다 다단계 인증(MFA)이 반드시 재평가되는 것은 아닙니다.
가장 큰 과제는 대개 OAuth 자체가 아니라, 관리되지 않은 OAuth의 무분별한 확산, 광범위한 권한 범위, 그리고 앱 권한 부여에 대한 가시성 부족입니다.
"비민감성"이라고 해서 무해하다는 뜻은 아닙니다
Vercel 보안 사고에 대한 공개 토론에서 얻을 수 있는 가장 중요한 교훈 중 하나는, 암호화된 민감한 기밀 정보와 기밀 등급이 낮은 데이터 간의 차이를 명확히 구분하는 것입니다. 실제 운영 환경에서는 공격자들이 당신의 가장 중요한 자산을 당장 필요로 하지는 않습니다. 그들은 계속 나아가기 위해 충분한 맥락이 필요합니다.
여기에는 다음이 포함될 수 있습니다:
- 위험도가 낮은 것으로 간주되는 API 키
- 내부 프로젝트 메타데이터
- 빌드 또는 배포 변수
- 저장소 참조
- 서비스 계정 관계
- 문서화 또는 티켓 처리 상황
보안 팀은 사고 대응 과정에서, 위험도가 낮다고 여겨졌던 증거물들이 공격자들이 권한이 높은 시스템을 찾아내거나, 명명 규칙을 파악하거나, 통합 지점을 식별하거나, 더 민감한 자산으로 접근 경로를 확장하는 데 도움이 되었다는 사실을 종종 발견합니다.
그렇기 때문에 “비기밀” 데이터의 재분류는 모든 사고 후 검토 과정에서 반드시 다뤄져야 할 사항입니다.
왜 폭발 반경 파악이 대응의 핵심 과제가 되는가
신원 도용으로 시작된 사고가 신뢰할 수 있는 연동 기능을 통해 확산될 때, 가장 먼저 제기되는 어려운 질문은 대개 “정보 유출이 있었는가?”가 아닙니다. 보통은 “정확히 어떤 부분이 건드려졌나요?”라고 묻습니다.
바로 그 지점에서 많은 대응 활동이 주춤해집니다. 각 팀은 환경의 서로 다른 부분을 담당합니다:
- IAM은 신원을 관리합니다
- 보안 운영팀이 경보를 관리합니다
- IT 부서가 엔드포인트를 관리합니다
- 클라우드 팀이 워크로드를 관리합니다
- DevOps는 파이프라인과 시크릿을 관리합니다
- 앱 팀은 배포 변수와 통합 기능을 직접 관리합니다.
만약 이들 팀이 공유된 작전 상황을 바탕으로 업무를 수행하지 못한다면, 조직은 부분적인 사실들을 종합하는 데 귀중한 시간을 낭비하게 된다. 이러한 파편화가 종종 단순한 사건을 장기화된 수사로 번지게 만드는 요인입니다.
[Axios npm 패키지 침해 사건이 왜 공급망 사고에 대해 단순히 CVE 중심의 대응이 아닌 ‘현장 중심’ 조사가 필요한지 보여주는 사례를 살펴보세요]
응답자가 신속하게 답변해야 할 질문들
이와 같은 보안 침해 사고의 경우, 대응 담당자들은 일반적으로 다음 사항을 파악해야 합니다:
| 답변 질문 | 그것이 왜 중요한가 |
|---|---|
| 어떤 사용자 계정이 관련되었습니까? | 초기 접근 권한 및 잠재적인 사칭 범위를 파악합니다. |
| 해당 신원들은 어떤 엔드포인트를 사용했나요? | 사용자 활동, 의심스러운 세션 및 로컬 아티팩트를 검증하는 데 도움이 됩니다. |
| 어떤 SaaS 앱에 위임된 액세스 권한이 있었나요? | 지속성 경로 및 상속된 권한을 식별합니다 |
| 어떤 인증 정보나 토큰이 유출되었을 가능성이 있습니까? | 순번 배정 및 봉쇄 우선순위를 주도한다 |
| 어떤 내부 시스템이 열거되거나 접근되었습니까? | 영향 및 규제 대응 필요 사항을 정의한다 |
| 어떤 하류 팀이나 고객이 영향을 받나요? | 알림, 문제 해결 및 커뮤니케이션을 지원합니다. |
바로 이 때문에 완벽한 예방보다 대응 속도가 더 중요한 것입니다. 현대적인 신원 기반 보안 사고의 경우, 공격자들은 거버넌스 절차보다 더 빠르게 움직일 수 있습니다. 방어 측의 입장에서 볼 때, 이는 대응 문제를 탐지에서 증거에 기반한 범위 설정으로 전환시킨다.
타늄이 바라보는 신원 기반 공급망 위험
이번 사건은 클라우드의 직접적인 취약점이나 코드 악용보다는 제3자 애플리케이션의 남용이나 위임된 접근 권한의 오용과 더 일치하는 것으로 보입니다.
Google Workspace를 통해 승인된 타사 앱을 통한 초기 접근 경로가 보고된 사례는, 신뢰할 수 있는 SaaS 관계가 경계 중심 통제의 효과를 어떻게 약화시킬 수 있는지를 보여준다.
위임된 토큰이나 앱 권한이 악용되면, 공격자는 사용자의 비밀번호가 직접 사용되지 않았더라도 해당 권한이 허용하는 추가적인 내부 서비스나 데이터 저장소로 접근 범위를 확대할 수 있습니다.
운영 측면에서 눈에 띄는 점은 노출된 데이터의 양이라기보다는, 공격자들이 탐지되기 전에 내부 환경을 파악해 나가는 속도와 능력에 있다. 이로 인해 수비수들의 역할이 달라집니다. 과제는 예방에서 신속한 범위 파악 및 피해 반경 축소로 전환된다.
이러한 맥락에서, 엔드포인트 텔레메트리는 범위 파악 및 검증 작업 과정에서 유용한 조사 정보를 제공합니다. 관리 대상 시스템에서 발생한 활동을 파악하고, 관련 증거 자료가 어디에 존재할 수 있는지 확인하는 것은 사건의 정확한 전말을 파악하는 데 있어 매우 중요합니다.
영향을 받는 신원 정보, OAuth 승인 및 SaaS 통합에 대한 보다 포괄적인 그림을 그리기 위해서는 일반적으로 엔드포인트 데이터를 신원 제공자(IdP), SaaS, 클라우드 및 SIEM 로그와 상호 연관시켜 분석해야 합니다.
이번 사건은 조사 과정에서 종종 드러나는 더 광범위한 교훈을 다시 한번 일깨워 줍니다. 즉, ‘비기밀’ 데이터나 신뢰할 수 있다고 가정된 통합 시스템과 같은 분류조차도 공격자들에게 여전히 유력한 공격 수단이 될 수 있다는 점입니다.
신원 기반 사고의 경우, 가장 큰 과제는 대개 전체 환경에서 실제로 어떤 일이 발생했는지에 대한 확신을 확보하는 것입니다. 따라서 효과적인 대응을 위해서는 개별적인 경보보다는 조사 맥락이 핵심이 됩니다.
신원 기반 사고에서 조사 맥락이 중요한 이유
실무적으로 볼 때, 이와 같은 사고에 대응하는 팀은 대개 여러 계층의 증거를 동시에 상호 연관시켜 분석해야 합니다:
- 해킹당한 신원과 관련된 엔드포인트 활동
- 브라우저 세션, 토큰 또는 로컬 아티팩트에 대한 비정상적인 접근의 징후
- 관련 자격 증명이 어디에 존재할 수 있는지에 대한 전사적 증거
- 영향을 받는 시스템 전반에 걸친 구성 또는 실행 패턴의 변화
- 적용 대상에 포함되는 장비, 사용자 및 서비스를 확인
엔드포인트 텔레메트리는 대응 담당자가 다양한 신원, SaaS 통합, 클라우드 서비스 및 엔터프라이즈 시스템 전반에 걸쳐 입증 가능한 증거를 수집할 때 의미 있는 맥락을 제공합니다.
팀이 이러한 맥락을 조기에 파악할 수 있다면, 영향을 정확하게 파악하고, 시정 조치의 우선순위를 정하며, 후속 의사소통을 자신 있게 뒷받침할 수 있는 유리한 입장에 서게 됩니다.
신원 기반 사고 대응을 위한 실용적인 절차
Vercel 보안 사고와 같은 신원 기반 사고의 경우, 대응의 효과성은 대개 명확한 조사 절차를 따르는지에 달려 있습니다.
체계적인 5단계 접근 방식은 팀이 불확실성에서 명확성으로 가능한 한 빨리 나아갈 수 있도록 돕습니다:
- 확인: 악용된 신원 경로를 파악하십시오.
- 범위: 해당 ID와 관련된 엔드포인트 및 환경을 매핑합니다.
- 에서 노출된 자격 증명, 토큰 및 통합 항목을 식별합니다.
- 억제: 억제와 회전을 통해 폭발 반경을 줄이세요
- 검증: 조사가 진행됨에 따라 환경을 지속적으로 검증하십시오.
이 순서가 중요한 이유는 조직이 처음부터 완전한 정보를 갖추고 시작하는 경우가 거의 없기 때문이다. 조사는 대개 단편적인 정보, 즉 불완전한 경보, 제한된 로그, 또는 개별적인 징후로부터 시작됩니다.
기업 전반에 걸쳐 이러한 단편적인 정보들을 조기에 연결해 두면, 팀들이 가정이 아닌 증거를 바탕으로 대응 결정을 내릴 수 있게 됩니다.
SaaS에 크게 의존하는 개발자 워크플로우를 사용하는 보안 팀이 지금 취해야 할 조치
Vercel 보안 사고의 직접적인 영향을 받지 않은 조직이라 할지라도, 이를 계기로 개발자를 대상으로 한 신뢰 모델을 재검토해야 합니다.
OAuth 앱 거버넌스 검토
간단한 질문부터 시작해 봅시다. 어떤 타사 애플리케이션이 기업 신원 정보에 접근할 수 있으며, 그 접근 범위는 어떻게 되나요? 많은 조직, 특히 엔지니어링 및 제품 팀에서는 이 질문에 자신 있게 답하지 못합니다.
주요 우선순위는 다음과 같습니다:
- 승인되고 사용자가 권한을 부여한 모든 OAuth 앱 목록
- 높은 권한 범위를 검토하고 상속된 액세스 권한을 확인하십시오
- 오래되었거나 거의 사용하지 않는 연동 기능을 제거하세요
- 필요한 경우 관리자 승인 절차를 강화한다
- 개인용 생산성 도구가 기업용 테넌트에 연결될 수 있는지 재검토하십시오
이러한 질문들에 대한 명확한 답을 얻는 것은 종종 생각보다 어렵습니다. OAuth 권한 부여가 은연중에 무분별하게 늘어나며, 원래의 사용 사례가 변경된 지 오래되었음에도 불구하고 많은 권한이 여전히 남아 있습니다.
기밀 분류 및 보관에 관한 가정을 재검토한다
사용 중인 환경에서 민감한 변수와 비민감한 변수를 구분하고 있다면, 해당 정책을 재검토하십시오. 이는 모든 변수를 동일하게 취급해야 하기 때문이 아니라, 공격자들이 종종 탐색 및 측면 이동을 위해 저항이 적은 데이터를 이용하기 때문입니다.
질문:
- 이 값을 통해 아키텍처, 명명 규칙 또는 신뢰 관계를 파악할 수 있을까요?
- 이 변수가 하위 시스템들을 열거하는 데 도움이 될 수 있을까요?
- 공격자가 이를 통해 운영상의 맥락을 파악할 수 있을까요?
- 여전히 너무 많은 곳에서 접근할 수 있는 건가요?
ID와 엔드포인트 간의 연관성을 강화
신원 정보가 유출된 경우, 대응 담당자는 해당 신원 정보가 어디에서 사용되었는지, 그리고 어떤 시스템에 접근했는지 파악해야 합니다. 신원 텔레메트리와 엔드포인트 텔레메트리가 운영상 연계되어 있지 않으면, 조사 기간이 길어지고 종종 정보의 공백이 발생합니다.
대규모 환경에서 키 및 토큰 순환을 실행해 보세요
많은 팀이 비밀 정보를 신속하게 교체할 수 있다고 말합니다. 분산 환경, CI/CD 파이프라인, 개발자 도구, 타사 서비스 전반에 걸쳐 이러한 주장을 검증해 본 사례는 많지 않습니다.
유용한 연습 방법 중 하나는 배포 변수나 위임된 토큰이 노출되는 상황을 시뮬레이션하고, 다음 작업에 걸리는 시간을 측정해 보는 것입니다:
- 모든 종속 시스템을 파악하십시오.
- 값을 회전시키기
- 영향을 받은 앱을 재배포합니다
- 사용 중인 오래된 토큰이 남아 있지 않은지 확인
이는 전형적인 클라우드 취약점 악용이 아니라 공급망 신원 확인 문제였음을 시사하는 징후들
보안 실무자들은 해당 패턴을 올바르게 명명함으로써 이점을 얻습니다. Vercel 보안 사고는 인프라 취약점 악용보다는 공급망 신원 도용에 더 가깝게 보입니다.
| 특징 | 신원 정보를 노린 공급망 침해 | 전통적인 인프라 취약점 악용 |
|---|---|---|
| 초기 접근 | 신뢰할 수 있는 제3자 앱 또는 위임된 액세스 | 소프트웨어 결함, 노출된 서비스 또는 잘못된 구성 |
| 신뢰 남용 | OAuth 범위, SaaS 관계, 계정 권한 | 네트워크 또는 애플리케이션 취약점 |
| MFA의 영향 | MFA는 초기 승인 시 충족되었을 수 있으며, 발행된 토큰은 만료되거나 취소될 때까지 계속 작동할 수 있습니다. | 종종 여전히 인증 경로의 일부로 남아 있다 |
| 공격자의 초기 행동 | 열거, 토큰 사용, 앱 내부 접근 | 취약점 악용, 셸 액세스, 권한 상승 |
| 수비수 도전 | 다양한 정체성과 서비스를 아우르는 영향 범위 파악 | 영향을 받은 호스트에 대한 패치 적용, 확산 방지 및 포렌식 조사 |
이 비교는 확인된 원인 분석이 아닌 응답 특성을 반영한 것입니다. 이러한 구분은 조직이 대비하는 방식에 영향을 미치기 때문에 중요합니다. 만약 귀사의 위협 모델이 여전히 노출된 포트와 패치가 적용되지 않은 시스템에 주로 초점을 맞추고 있다면, 기업 내에서 가장 빠르게 확대되고 있는 공격 표면 중 하나를 과소평가하고 있을 수 있습니다.
사고 대응 책임자를 위한 교훈
Vercel 보안 사고에서 얻은 가장 큰 교훈은 신뢰할 수 있는 도구조차 위험할 수 있다는 점이 아닙니다. 신뢰는 지속적으로 검증되어야 하며, 특히 회사 경계와 신원 확인 플랫폼을 넘나들 때 더욱 그러합니다.
사고 대응 책임자들에게 이는 몇 가지 구체적인 우선순위로 이어집니다.
가정 대신 검증을 위해 구축하라
저위험 토큰이 영향력이 작다고 단정하지 마십시오. 승인된 앱이라고 해서 무조건 안전하다고 생각해서는 안 됩니다. 초기 경보의 범위가 좁아 보인다고 해서 해당 타협안이 고립된 것이라고 단정하지 마십시오.
범위에 맞춰 속도를 최적화하십시오
사건 확산 방지도 중요하지만, 신원 관련 사고의 경우 그 범위가 의사소통, 법적 검토, 고객 대응, 교대 근무 계획, 경영진의 신뢰 등 다른 모든 요소를 좌우합니다.
개발자 생태계를 공격 표면의 일부로 간주해야 한다
빌드 플랫폼, CI/CD 도구, 배포 변수, 브라우저 기반 관리자 세션, 협업 앱 등은 모두 동일한 운영 환경의 일부입니다. 공격자들은 이미 이런 식으로 생각하고 있습니다.
Vercel 보안 사고에 관한 자주 묻는 질문
신원 기반 사고는 표준 ‘ ’ 사고 대응 매뉴얼()에 항상 명확하게 부합하지 않는 의문점들을 제기합니다. 다음은 보안 및 IT 팀이 이와 같은 보안 침해 사고를 처리할 때 자주 묻는 질문들입니다.
베르셀 사건은 소프트웨어 취약점 때문이었을까?
아닙니다. 현재까지 파악된 정보에 따르면, 이번 사건은 일반적인 소프트웨어 취약점과 무관하며, 신뢰할 수 있는 제3자 연결을 통한 신원 및 통합 기능의 악용에서 비롯된 것으로 보입니다.
이번 정보 유출 사건에서 OAuth가 왜 중요한가요?
OAuth를 통해 애플리케이션은 사용자를 대신하여 리소스에 접근할 수 있습니다. 만약 그러한 신뢰 관계가 훼손된다면, 공격자는 전통적인 의미에서 비밀번호를 훔칠 필요 없이도 중요한 접근 권한을 획득할 수 있습니다.
“민감하지 않은” 변수가 왜 여전히 문제가 되는가?
데이터가 극도로 민감한 정보로 분류되지 않더라도, 공격자가 환경을 파악하고, 내부 시스템을 식별하며, 의존 관계를 찾아내거나, 더 높은 권한의 접근 권한을 획득하는 데 활용될 수 있습니다.
유사한 사건이 발생한 후 조직은 어떻게 해야 할까요?
대부분의 팀은 OAuth로 연결된 앱을 검토하고, 유출되었을 가능성이 있는 인증 정보를 주기적으로 변경하며, 영향을 받은 신원 정보를 엔드포인트 활동과 대조 분석하고, 어떤 시스템과 서비스가 영향을 받았는지 확인해야 합니다.
엔드포인트 보안 및 규정 준수 도구를 활용하면 호스트 측 범위 지정 및 유효성 검증을 가속화할 수 있지만, OAuth로 연결된 앱과 위임된 범위를 검토하려면 엔드포인트 텔레메트리 데이터 외에도 ID 플랫폼 및 SaaS 감사 데이터가 필요합니다.
더 넓은 관점에서 볼 때 얻을 수 있는 교훈
Vercel 보안 사고는 현대의 보안 침해 사고가 단순히 취약점 악용을 통해서만이 아니라, 종종 신뢰를 통해 발생한다는 점을 다시금 일깨워 줍니다. 초기 침해 경로는 사소해 보일 수 있지만, 일단 공격자가 신원 인증을 통해 내부 시스템에 접근하게 되면 운영상의 문제는 ‘속도’로 귀결됩니다. 즉, 어떤 자원에 접근되었는지, 어떤 정보가 노출되었는지, 그리고 지금 당장 무엇을 변경해야 하는지를 얼마나 빨리 파악할 수 있느냐가 관건입니다.
보안 및 IT 팀의 경우, 바로 이 지점에서 성숙한 대응이 사후 대응식 허둥지둥함과는 차별화됩니다. 예방이 여전히 중요하지만, 신뢰할 수 있는 통합 기능이 악용될 경우, 신원 활동, 엔드포인트 증거, 전사적 노출 정보를 신속하게 하나로 연결하여 논리적으로 타당한 전체 그림을 도출해 낼 수 있는 조직이 가장 효과적으로 대응할 수 있습니다.
OAuth 앱 거버넌스, 토큰 수명 주기 관리, SaaS 감사 가시성, 비밀 정보 관리 및 전반적인 보안 관행을 재검토하는 팀은 향후 발생할 수 있는 신원 관련 사고에 더 잘 대비할 수 있을 것입니다.
귀사의 팀이 엔드포인트 및 기업 환경 전반에 걸쳐 신원 기반 사고를 조사하는 방식을 재검토하고 있다면, Tanium은 조사 범위의 매 순간이 중요한 상황에서 불확실성을 줄이고 더 신속한 대응을 지원하는 데 있어 실용적인 관점을 제시합니다.
방법을 확인해 보시려면 에서 무료 데모를 예약하세요.
