데이터 저장 및 분석을 제공하는 미국 클라우드 서비스인 Snowflake의 고객은 최근 다음과 같은 문제를 겪었습니다. 대규모 공개 데이터 유출 사상 최대 규모라고 합니다. 이 유출 사고는 무선 통신사 AT&T의 '거의 모든' 고객과 티켓마스터, 렌딩트리와 같은 다른 회사의 고객을 포함하여 약 170개 조직에 영향을 미쳤습니다.
하지만 이번 유출 사고는 피해를 입은 고객과 기업에게만 치명적인 것이 아닙니다. 클라우드 공유 책임 모델이 무너지면 어떤 일이 일어날 수 있는지를 보여주는 훌륭한 사례이기도 합니다. 그 방법을 살펴보겠습니다.
목차
안전한 클라우드 파일 전송
MASV는 ISO 27001/SOC 2 인증 및 TPN 검증(골드 실드 등급)을 받은 안전한 파일 전송 서비스입니다.
📣공유 책임 모델은 일반적으로 한쪽은 고객, 다른 한쪽은 공급업체 간에 데이터 보호 및 취약성 관리 책임을 명확하게 구분합니다.
공급업체 책임과 고객 책임의 결합. 충분히 간단해 보이시죠?
그러나 문제는 사용자가 클라우드 제공업체가 실제로는 제공업체의 책임이 아닌 데이터 보안 책임을 처리할 것이라고 생각하거나 제공업체가 제공하는 도구를 활용하지 않는 경우입니다. (예: 멀티팩터 인증(MFA) 적용 등).
그렇게 되면 보안 책임 공유 모델이 무너지게 됩니다. 그리고 데이터 유출의 가능성은 훨씬 더 높아집니다.
AT&T 데이터 유출: 어떻게 발생했을까요?
이번 데이터 유출 사고는 이러한 클라우드 공유 책임 모델의 붕괴로 인한 직접적인 결과로 보입니다.
이 모델에 따라, 그리고 많은 클라우드 서비스와 마찬가지로 Snowflake는 전통적으로 사이버 보안 도구와 기능을 제공했지만 사용자가 스스로 보안 상태를 관리할 수 있도록 했습니다. 예를 들어, Snowflake는 MFA와 같은 액세스 관리 도구를 제공했지만 이전에는 사용자가 이를 시행할 것을 요구하지 않았습니다.
![눈송이 데이터 유출_ 어떻게 발생했나_ 플레이스홀더 이미지](https://massive.io/wp-content/uploads/2024/07/The-Snowflake-Data-Breach_-How-Did-It-Happen_.png)
출처: Verdict.co.uk
A 간단한 설명 클라우드 서비스 제공업체가 발표한 성명서에서는 이번 유출이 "단일 인증(SFA)을 사용하는 사용자를 대상으로 한 표적 캠페인"이라고 인정하며, SFA를 사용하는 Snowflake 계정의 비밀번호는 "이전에 구매했거나 정보 탈취 멀웨어를 사용하여 획득한 것"이라고 덧붙였습니다.
번역: 키스트로크 로깅(또는 이와 유사한) 멀웨어가 사용자 비밀번호를 수집한 다음, 안전하지 않은 스노우플레이크 계정에 침입하여 (예상대로) 내부 데이터에 혼란을 야기하는 데 사용되었습니다. 하지만 안타까운 사실은 유출된 Snowflake 계정의 관리자가 비교적 간단한 요건인 사용자에 대한 MFA 액세스 제어를 시행했다면 이번 유출 사고는 거의 발생하지 않았을 것이라는 점입니다.
(테크크런치 는 최근 이번 공격에 사용된 것과 같은 스노우플레이크 고객 인증정보로 추정되는 '수백 개'가 온라인에서 여전히 사용 가능하다고 보고했습니다.)
놀랍지 않게도, 유출이 공개 된 이후 Snowflake는 새로운 인증 정책 관리자가 모든 스노우플레이크 사용자가 MFA를 사용하도록 강제할 수 있습니다.
클라우드에서 기업(및 사용자)을 위한 교훈
우리 모두는 실수로부터 배우는 것이 중요하며 퍼블릭 클라우드 서비스와 사용자도 다르지 않습니다.
관리자가 MFA와 같은 합리적인 사이버 보안 조치를 시행할 수 있도록 하는 공급업체와 함께, 이 사건에서 배울 수 있는 다른 중요한 데이터 보호 교훈도 있습니다:
MFA/2FA 및 기타 합리적인 보안 기본값 적용
데이터 유출 이제는 대부분의 일상적인 비즈니스 사용자들도 MFA 또는 2단계 인증(2FA)을 통한 액세스 제어의 중요성을 인식할 정도로 보편화되었습니다. 관리자는 항상 이를 시행해야 하며 클라우드 제공업체는 항상 이 옵션을 제공해야 합니다.
MFA는 직원들에게 약간의 마찰을 야기하지만(최근 컴퓨터를 교체하면서 설정하는 동안 두 시간 동안 약 100건의 MFA 인증을 처리해야 했습니다), 많은 사이버 공격을 차단할 수 있습니다. 그 이유만으로도 타협할 수 없습니다.
마이그레이션을 신중하게 처리하지 않으면 MFA 단계가 해당 프로세스를 중단시킬 수 있으므로 클라우드 서비스는 자동화된 프로세스에 연결된 레거시 계정에서 MFA를 활성화하는 고객을 위한 교육 및 지원도 제공해야 합니다.
모든 새 리소스(예: 스토리지 버킷, 데이터베이스 또는 가상 머신)를 기본적으로 공개하지 않고 모든 공개 액세스를 차단하도록 자동으로 구성하는 등의 다른 보안 기본값도 클라우드 공급업체에서 구현해야 합니다.
이러한 조치는 최종 사용자에게 약간의 마찰을 야기할 수 있지만, 그 반대의 경우보다는 보안을 강화하는 방향으로 나아갈 수 있게 해줍니다.
개방형 위협 인텔리전스(OSINT) 수집
고객을 대신하여 다크 웹과 일반 인터넷에서 위협을 지속적으로 모니터링하고 잠재적인 침해 징후에 대응하세요. 부주의한 사용자가 실수로 오픈 코드 리포지토리에 API 키를 노출하는 경우가 종종 발생하고 있습니다. 깃허브의 스트라이프 API 키 (죄송합니다).
클라우드 기업은 오픈 소스 코드 저장소에서 키 유출이 있는지 모니터링하고 유출을 발견하면 영향을 받는 고객에게 연락해야 합니다. 공급업체는 이를 위해 CrowdStrike와 같은 자동화된 도구를 사용할 수 있습니다.
잠재적 위협을 파악할 수 있는 도구 제공
또한 클라우드 제공업체는 주요 사이버 보안 플랫폼과의 도구 및 통합을 제공하여 DevSecOps 팀을 평가하고 잠재적인 위협을 파악하며 사용자가 사이버 보안 모범 사례를 따를 수 있도록 더 많은 유연성을 제공해야 합니다. 클라우드 제공업체가 이러한 보안 제어 기능을 제공하지 않는다면 관리자는 이러한 도구를 찾아봐야 합니다.
- 실례입니다: Splunk나 Wiz와 같은 서비스는 클라우드 인프라 내의 모든 작업을 수동적으로 모니터링하여 침해의 단서가 될 수 있지만 탐지되지 않을 수 있는 사용 이상 징후를 자동으로 찾아낼 수 있습니다.
- 또 다른 예입니다: API 키 교체. 예를 들어 사용자가 3개월마다 API 키를 변경하려는 경우 공급업체는 시스템 다운타임을 크게 발생시키지 않으면서 이를 수행할 수 있는 메커니즘을 제공해야 합니다. 즉, 동시에 여러 개의 API 키를 생성할 수 있는 기능을 제공해야 합니다.
당연한 것을 당연하게 여기지 마세요
마지막으로, 특히 고객으로서 공유 책임 모델을 당연하게 여기거나 안주하지 마세요.. "다른 회사의 책임이다"라는 사고방식에 빠지거나 보안 도구가 의무 사항이 아니라면 중요하지 않다고 생각하기 쉽습니다.
클라우드 제공업체는 사용자가 책임감 있는 보안 태세를 갖출 수 있도록 최대한 많은 교육과 문서를 제공하는 동시에 자체 직원에게도 최신 보안 위협과 모범 사례에 대해 교육해야 합니다.
그리고 사용자는 항상 모범 사례를 따르고 설명서를 읽어야 하며, 문서로 확인하기 전에는 클라우드 인프라 제공업체가 알아서 처리해 줄 것이라고 가정해서는 안 됩니다.
MASV: 계층화된 보안 접근 방식
강력한 TLS 1.2 및 AES-256 기반 암호화와 엄격한 액세스 제어를 통해 AWS 보안을 기반으로 구축된 MASV는 저장 및 전송된 모든 데이터를 안전하게 유지합니다. 계층화된 보안 접근 방식 를 포함합니다:
- 직원 보안 인식 교육 강력한 내부 비밀번호 생성기.
- 제품 보안 정기적인 코드 스캔과 관리자 로그인에 대한 자동 알림을 포함합니다.
- 고객 보호 강력한 비밀번호를 의무적으로 적용하고, MFA 및 비밀번호 생성기 사용을 의무적으로 권장하는 등의 정책을 시행하고 있습니다.
- 유효성 검사 타사 사이버 보안 감사 및 규정 준수를 통해 보안을 강화합니다.
MASV에 가입하기 를 클릭하고 오늘 무료로 시작하세요.
프리미엄 클라우드 인프라
MASV는 보안성이 뛰어난 AWS 클라우드 인프라에서 실행되므로 파일은 항상 안전하게 보호됩니다.