스토리지 계층에 제로 트러스트 원칙을 진지하게 적용해야겠다고 생각한 것은 어떤 백서나 업체의 발표를 보고 내린 결정이 아니었다. 그 계기가 된 것은, 지금도 잊을 수 없는 한 랜섬웨어 사고 현장에서의 경험이었다. 공격자는 운영 시스템만 노린 것이 아니라 백업까지 파괴하려 했다. 그 순간 필자는 진정한 복원력이 무엇인지 생각했고, 지금까지 스스로를 속이고 있었다는 사실을 깨달았다.

그 충격적인 경험은 중요한 사실을 일깨워줬다. 스토리지 계층을 제로 트러스트 체계로 준비하지 않는다면, 그 위에 구축한 모든 보안은 모래 위에 세운 성과 같다. 이는 더 이상 이론 속 이야기가 아니다. 2024년 2월, 체인지 헬스케어(Change Healthcare) 사건을 보자. 공격자는 단순히 데이터를 암호화하는 데 그치지 않고, 제대로 격리되지 않은 백업을 겨냥해 기업의 복구 능력 자체를 체계적으로 파괴했다. 그 결과 몇 달간 혼란이 이어졌고, 수십억 달러 규모의 피해가 발생했다. 원인은 단 하나, 스토리지를 신뢰할 수 있는 부차적 요소로만 취급한 데 있었다.

수치를 보면 충격적이다. 랜섬웨어 공격은 갈수록 더 빈번해지고 피해 규모는 훨씬 커지고 있다. 문제는 단순히 공격이 늘어난 것이 아니라, 공격이 점점 더 지능적으로 진화하고 있다는 점이다. 이제 최신 랜섬웨어는 단순히 파일을 암호화하는 데 그치지 않는다. 퀼린(Qilin) 같은 변종은 백업을 추적해 파괴하도록 설계됐고, 다이어 울프(Dire Wolf)는 복구 자체를 기술적으로 불가능하게 만든다. 사이버 범죄 집단은 메두사(Medusa) 같은 서비스형 랜섬웨어(Ransomware-as-a-Service) 플랫폼을 통해 공격을 산업화했으며, 우리가 마지막 보루로 의지해 온 ‘복구 능력’ 자체를 정조준하고 있다.

왜 스토리지는 여전히 우리의 아킬레스건인가?

수년 동안 기업이 네트워크, ID, 애플리케이션 영역에 제로 트러스트를 도입하도록 지원해왔지만, 필자는 늘 같은 패턴을 목격했다. 스토리지는 언제나 간과된다. 예외는 없다.

이런 일이 반복되는 이유는 크게 3가지로 정리할 수 있다.

• - 스토리지는 눈에 잘 띄지 않는다. 많은 팀이 이를 단순한 백엔드 인프라로, 그저 뒤에서 조용히 존재하는 수동적 시스템 정도로 여긴다. 그러나 현실은 다르다. 마이터 어택(MITRE ATT&CK) 기법 가운데 T1485(데이터 파괴), T1490(시스템 복구 방해) 같은 항목은 스토리지를 정조준한다. 공격자는 어디를 노려야 할지 정확히 알고 있는데, 업계는 여전히 스토리지를 전장(battlefield)이 아닌 배경(background) 정도로 취급한다.
• - 스토리지는 본질적으로 복잡하다. 여러 클라우드 업체, 지역, 온프레미스 시스템 전반에 걸쳐 일관된 정책을 적용하는 일은 쉽지 않다. 실제로 일부 팀은 보안을 논의하기 이전에 스토리지 현황을 파악하는 데만 몇 달을 소비하기도 한다.
• - 잘못된 가정이 뿌리 깊게 자리 잡고 있다. 업계는 오랫동안 애플리케이션이 안전하다면 그 애플리케이션이 접근하는 데이터도 ‘신뢰할 수 있다’고 여겨왔다. 하지만 공격자가 애플리케이션을 우회해 곧바로 스토리지 API를 겨냥한다면 어떻게 될까? 답은 명확하다. 게임 오버다.

실제로 효과적인 3가지 원칙

필자는 여러 기업에서 스토리지 계층 제로 트러스트를 도입하면서 한 가지를 깨달았다. 이 과제를 단순한 기술 문제가 아니라 리더십 차원의 3가지 원칙으로 정리해야 경영진이 전략적 성과를 제대로 이해할 수 있다는 점이다.

데이터에 접근할 수 있는 경로를 통제하라

스토리지 보안을 위한 경계 보안은 단일 방화벽에 의존하는 대신, 스토리지 API를 사용할 수 있는 신뢰된 네트워크와 환경을 명확히 구분하는 정책적 경계 설정에서 출발해야 한다.

필자가 주도했던 한 프로젝트에서는 멀티 테넌트 클라우드 환경에서 네트워크 경계를 활용해 프로젝트 간 데이터 확산을 차단했다. 그 효과는 즉각적으로 나타났다. 설령 공격자가 유효한 자격 증명을 확보하더라도, 경계 밖에서는 민감한 데이터 세트에 접근할 수 있는 경로 자체가 존재하지 않았다.

여기서 얻은 핵심 교훈은 명확하다. 거부를 기본 표준으로 삼고, 모든 예외 요청은 잠재적 위험 결정으로 취급해야 한다는 것이다.

누가 언제 데이터를 다룰 수 있는지 통제하라

스토리지 환경에서의 IAM(Identity and Access Management)은 단순한 정적 역할(role) 부여를 넘어야 한다. 핵심은 다음과 같다.

• - 최소 권한 원칙(Least privilege) : 필요한 권한만, 필요한 시간 동안만 부여한다.
• - 업무 분리(Separation of duties) : 접근 권한과 보존 정책은 서로 다른 담당자가 관리한다.
• - 적시 접근(Just-in-time access, JIT) : 특정 작업을 위해 일시적으로 권한을 부여하고, 작업이 끝나면 자동으로 회수한다.

이 변화는 결코 쉽지 않았다. 개발자는 속도가 떨어질 것을 우려했고, 운영팀은 승인 절차가 늘어나는 것을 꺼렸다. 그러나 JIT를 명확한 권한 설정과 감사 부담 감소와 연계하자 점차 도입이 확대됐다.

일부 데이터는 손댈 수 없게 만들어라

WORM(Write-Once-Read-Many) 불변성은 단순한 규제 준수 체크박스가 아니다. 전략적 안전장치다. 한 번 적용된 보존 잠금(retention lock)은 만료 시점까지 유지되며, 심지어 특권을 가진 내부자조차 해당 데이터를 수정하거나 삭제할 수 없다.

필자는 이 차이를 직접 확인했다. 한 시뮬레이션에서 관리 권한을 가진 공격자가 전체 데이터 세트를 삭제할 수 있었지만 불변 백업만은 지워지지 않았다. 이는 ‘전면적 위기’와 ‘빠른 복구’의 갈림길을 만든다. 이 경험이 주는 메시지는 명확하다. 불변성은 시간을 벌어주고 확실성을 보장한다. 이는 사고가 터졌을 때 가장 절실히 필요로 하는 2가지 요소다.

스토리지가 준비되지 않으면 벌어지는 일

모든 대형 침해 사고는 교훈을 남긴다. 이들 공격의 공통점은 명확하다. 공격자가 운영 시스템만큼이나 복구 지점(recovery point)도 집요하게 노렸다는 사실이다.

2017년 머스크(Maersk) 사례는 최악의 상황에서 운 좋게 살아남은 경우였다. 낫페트야(NotPetya)가 글로벌 인프라 전체를 파괴하면서 도메인 컨트롤러 백업까지 지워졌는데, 우연히 가나의 한 서버가 정전으로 오프라인 상태였기에 살아남을 수 있었다. 단 한 번의 정전이, 글로벌 해운 대기업과 디지털 전멸 사이를 갈라놓은 것이다.

2021년 JBS 푸드(JBS Foods)는 상황이 달랐다. 레빌(REvil) 공격에서 일부 백업은 살아남았지만, 결국 1,100만 달러의 몸값을 지불했다. 이유는 단순했다. 복구가 진행되고 있었지만 기업이 버틸 수 있는 시간보다 더 오래 걸렸기 때문이다. 백업만으로는 충분하지 않다. 복구 속도가 비즈니스를 지탱할 수 있어야 한다.

2025년 밀리외데이터(Miljödata) 사례는 공급망 공격의 진화를 잘 보여준다. 한 스웨덴의 IT 서비스 기업이 공격을 받자, 무려 200곳의 지방자치단체가 급여를 처리하지 못하는 사태가 벌어졌다. 핵심 업체가 스토리지에 대한 제로 트러스트 원칙을 따르지 않는다면, 그들의 취약점은 곧 모두의 취약점이 된다.

같은 해 다비타(DaVita)는 최악의 이중 갈취 공격을 당했다. 공격자는 1.5TB 규모의 환자 데이터를 탈취하고 시스템을 암호화한 뒤, 2가지 위협 모두에 몸값을 요구했다. 그러나 포괄적인 제로 트러스트 아키텍처는 이를 정면으로 방어할 수 있다. 경계 보안은 데이터 유출을 탐지되지 않고 수행하기 어렵게 만들고, 불변 백업은 암호화 기반 협박에서 공격자의 협상력을 무력화한다.

거버넌스 관점에서 본 제로 트러스트

경영진에게 이 원칙을 설명할 때 필자는 3가지 분명한 성과에 집중한다. 위험 감소, 복원력 확보, 규제 준수다. 경영진은 데이터 계층에서의 공격 표면이 줄어들고 있는지, 상위 방어선이 뚫리더라도 복구 지점이 살아남을 수 있는지, 그리고 SEC 17a-4(f) 나 HIPAA 같은 주요 규제에 맞춰 보존·접근 정책이 설계돼 있는지를 반드시 확인해야 한다.

이 부분에서는 정책 코드화(Policy as Code)가 결정적인 변화를 가져왔다. 단순히 ‘데브옵스(DevOps)스러워서’가 아니라, 모든 핵심 통제에 대해 감사 가능한 변경 이력과 검토 가능한 기록을 남기기 때문이다. 이사회 차원에서는 “백업이 잠겨 있다는 걸 어떻게 증명할 수 있는가?”라는 질문에, 정책 커밋 로그를 직접 제시하며 투명성과 책임성을 입증할 수 있다는 의미가 된다.

현장에서 얻은 교훈

스토리지에 제로 트러스트를 확장하는 일은 주말 프로젝트처럼 간단히 끝낼 수 있는 작업이 아니다. 시작하기 전에 누군가 알려줬으면 했던 점은 다음과 같다.

첫째, 속도와 복잡성에 대한 반발은 피할 수 없다. 그러나 자동화, 간단한 예외 처리 워크플로우, 그리고 측정 가능한 지표를 제시하면 위험 감소가 생산성을 저해하지 않는다는 점을 입증할 수 있다.

둘째, 시뮬레이션은 생각보다 훨씬 중요하다. 스토리지 복구 테스트 없이 랜섬웨어 대응 모의훈련을 하는 것은 비상구 점검도 안 한 채 화재 대피 훈련을 하는 것과 다르지 않다. 압박 상황에서 실제 전략이 통하는지 여부는 직접 시험해보기 전에는 알 수 없다.

셋째, CFO는 가장 든든한 동맹이 될 수 있다. 필자는 설계 단계에서 CFO를 일찍 참여시키는 법을 배웠다. 데이터 보존 정책이 곧 복구 보장과 수천만 달러 규모의 몸값 요구 방어로 이어진다는 사실을 이해한 순간, CFO는 적극적으로 예산 확보를 지원하는 후원자가 됐다.

어려운 질문

만약 기업의 사이버 복원력을 책임지고 있다면, 스스로에게 이렇게 물어야 한다. “만약 공격자가 지금 유효한 자격 증명과 네트워크 접근 권한을 갖고 있다면, 우리의 복구 지점을 무력화할 수 있는가?”

답이 “그렇다” 혹은 “잘 모르겠다”라면, 제로 트러스트 전략이 아직 완성되지 않은 것이다.

공격자가 내부로 침투한 뒤에야 스토리지의 허점을 발견해서는 안 된다. 스토리지를 위한 제로 트러스트는 생존을 위한 비즈니스 필수 조건이지 단순한 기술 업그레이드가 아니다.

이제는 스토리지를 ‘보이지 않는 인프라’로 취급하는 태도를 버려야 한다. 스토리지는 실제로 공격 표면이며, 적극적으로 방어해야 할 전장이다. 다른 모든 방어가 무너졌을 때 기업을 재앙에서 지켜줄 유일한 것은 복구 속도와 확실성이다.

*Vivek Radhakrishnan은 구글, 아마존, 에지버브 시스템즈(EdgeVerve Systems)에서 16년 이상 경력을 쌓은 숙련된 엔지니어링 리더다.

dl-itworldkorea@foundyrco.com