제로 트러스트와 클라우드 보안 확보

제로 트러스트라는 용어를 잘못 사용하거나 잘못 이해하고 있는 경우도 많지만, 이는 실제로 사이버 리스크를 줄이고 회복력을 개선하는 데 도움이 되는 접근 방식입니다.

클라우드로 이동하면 제로 트러스트 아키텍처에 새로운 가능성이 열릴 수 있습니다.

진짜 제로 트러스트와 가짜 제로 트러스트

일부 공급업체에서는 제로 트러스트에서 ID와 액세스 관리가 가장 중요하다고 합니다. 즉, 비즈니스가 승인받은 사용자에게 리소스에 액세스하도록 지원하는 방법이 관건입니다. 이것이 제로 트러스트의 기본 요소인 것은 맞지만, 이는 ID, 인프라, 제품, 프로세스와 공급망 전반에 걸쳐 비즈니스를 운영하는 모든 리스크 표면을 고려하는 더 큰 규모의 전략 중 일부분으로 여겨야 하는 한 가지 구성 요소일 뿐입니다.

모든 보안 전문가는 기술 아키텍처와 네트워크에서의 신뢰에 대해 항상 부정적으로 이야기합니다. 데이터센터 네트워크에 연결된 '신뢰할 수 있는 네트워크'가 침해될 수 있고, 엔드포인트도 해킹될 수 있으며 기업이라는 왕국의 문을 여는 열쇠를 지닌 신뢰할 수 있는 사용자가 내부자로 변질될 수 있고, 신뢰할 수 있는 운영 체제 프로세스가 트로이 목마에 당하거나 신뢰할 수 있는 파일이 악성 파일이 될 수도 있습니다.

따라서 제로 트러스트는 여러 기술 엔터티 사이에 존재하는 각종 암묵적인 신뢰를 모두 배제하는 전략적 접근 방식을 제공합니다. 간단히 말해, 제로 트러스트는 클럽 입구에 경비원을 배치하는 데 그치는 것이 아니라 클럽 내부와 차고에도 경비원을 배치하고, 고객을 클럽 밖으로 에스코트하는 경호원을 고용하는 방침을 필수로 적용하는 것입니다. 잠깐, 제로 트러스트가 그렇게 간단한 개념인가요? 그저 보안을 더 강화하는 방침일 뿐인가요?

솔직히 말하면, 기업에 중요한 질문은 항상 제로 트러스트를 수용할지가 아니라, 이번에 효과가 있을 이유가 무엇이고, 거액의 비용 문제와 변화를 기꺼이 반기지 않는 상황까지 고려하면 어디서 시작해야 할지가 문제입니다.

제로 트러스트 피라미드

그러한 여러 가지 시스템 리스크를 물려받은 기존 회사의 경우 대개 두 가지 기본 요소를 기초로 제로 트러스트 프로그램을 시작합니다. 즉, ID 및 액세스 관리 스택을 조율하고 연결 상황을 조율하는 것입니다. 이렇게 하면 펌웨어 모노컬처, 애플리케이션과 같은 다른 시스템 리스크를 해결할 추가 제로 트러스트 기본 요소를 형성할 기본 토대가 마련됩니다.

제로 트러스트에서 플랫폼의 역할

사이버 보안 회복력에 대해 설명하라고 하면 저자는 '회복력이 우수한 기업을 만들려면 보안을 구성 요소 목표가 아니라 시스템으로 여겨야 한다'고 말하고 싶습니다. 예를 들어, 샌드박스 제어 기능의 효과를 테스트하는 데만 초점을 맞춰서는 안 됩니다. 그보다는 샌드박스를 조직 전반의 다른 보안 제어와 어떻게 통합할 것인지 우선순위를 정해야 합니다. 즉, 가장 중요한 애플리케이션을 침투 테스트하거나, 이 애플리케이션이 백만 달러짜리 IoT 디바이스와 같은 네트워크에 연결되어 있는지 또는 서버에서 추가로 노출된 서비스를 실행하고 있는지 확인하는 데 수백만 달러를 지출해서는 안 됩니다.

전 세계가 분산되고 단편화된 오늘날, 워크로드와 ID가 인터넷 어딘가에 상주해 있으므로 보안 운영에 필요한 다음의 몇 가지 코어 기능을 맞추지 않으면 시스템 전반에 걸친 사이버 보안 관점을 유지하기 매우 힘듭니다.

• 공통의 ID와 정책 스택.
• 실행 가능한 위협에 대한 일반적인 이해.
• 시스템 전체에 걸쳐 정책과 위협 정보를 적용하기 위한 공통의 프로토콜/제어.

Phil Venables의 최근 블로그 게시물을 보면 이 내용이 다른 접근 방식으로 설명되어 있습니다. 글을 인용하면 다음과 같습니다. “대다수의 기업에서 엔터프라이즈 보안에 가장 성공적인 기법 중 하나는 어디에나 적용되는 범용 기준선을 만드는 것입니다. 그런 다음 제어(기존이든 신규든)의 단위 비용을 줄여서 그 기준선을 경제적으로 높이는 것입니다.”

이 블로그에서 Venables는 자동차 제조업계를 예로 들며, 본래 레이싱카에 적용되던 안전성 기능을 누구나 이용하는 패밀리카에 상품화하게 된 양상을 사이버 보안에서도 복제할 수 있다는 의견을 제시했습니다. 사실, 네트워크 보안과 연결은 아주 좋은 예입니다.

예전에는 네트워크 보안이 기업 내에 존재하는 모든 것을 신뢰하고, 외부의 모든 것은 신뢰할 수 없다는 원칙으로 돌아갔습니다. 즉, 기업의 경계선에서만 보안을 적용했습니다. 그런데 이 모델은 원격 근무자, 클라우드, 에지와 모바일 액세스 요구 사항이 적용된 오늘날에는 더 이상 효과적이지 못합니다.

지금은 이 모든 환경이 인터넷에 직접 연결되어 있습니다. 다만 세그먼테이션이나 침입 탐지와 같이 극히 기본적인 제어마저도 결여된 상태입니다. 개별적으로 제어와 정책을 테스트하거나 구축하는 데 비용이 많이 들어 기업 측에서 대부분의 사이버 보안 제어를 감당할 수 없기 때문입니다.

이에 따라 사이버 보안 플랫폼이 제로 트러스트 전략을 구축할 최선의 전략으로 떠오르고 있으며, 시간이 흐르면서 대부분의 사이버 보안 프로그램의 경제적 차별화 요인으로 대두되고 있습니다.

제로 트러스트 관점에서 본 클라우드 기회

레거시 연결이나 보안 스택을 교체하는 것은 대규모 작업이고, 클라우드와 원격 인력 프로그램으로 인해 시작되거나, 때로는 혹독한(랜섬웨어 같은) 계기가 있어야 비로소 시작되기도 합니다. 하지만 이런 경우에도 제로 트러스트 프로그램에는 새로운 가능성이 있으며, 이를 간과하거나 허비해서는 안 됩니다!

워크로드, 애플리케이션과 사용자를 클라우드로 옮기고 DevOps를 도입하는 기업이 점점 늘어나는 지금이야말로 보안을 사후가 아닌 처음부터 구성할 적기입니다. 따라서 체계적인 접근 방식을 취하려면 프로덕션 환경 보안뿐만 아니라 CI/CD 파이프라인과 보안 제어 통합을 파이프라인에서 최대한 일찍부터 고려해야 합니다. 여기서 제로 트러스트 언어로 몇 가지 질문을 공식화하도록 하겠습니다. DevOps와 클라우드 환경 보안을 진지하게 고민하는 경우 이런 질문을 프로젝트 기획안에 포함해야 합니다.

• 소프트웨어 엔지니어의 디바이스가 침해되지 않을 것이라고 확신할 수 있습니까?
• 코드 리포지토리가 침해되지 않을 것이라고 확신할 수 있습니까?
• 개발과 구축 프로세스에서 코드 무결성을 신뢰할 수 있습니까?
• 타사 IaC(Infrastructure as Code) 템플릿이나 도커 컨테이너를 신뢰할 수 있습니까? 이중 절반(평균)에는 불량 취약점이 연관되어 있다는 점을 유의해야 합니다.
• 프로젝트에서 사용되는 다른 소프트웨어 애플리케이션 종속성은 어떻습니까?
• ID가 적절한 권한에 할당되어 있다고 확신할 수 있습니까?
• 자격 증명 하드코딩, 권한이 과도하게 부여된 네트워크 설정과 같은 보안이나 구성 오류가 있는지 코드를 검사하고 있다고 확신할 수 있습니까?
• 마이크로서비스 오케스트레이터가 침해되지 않을 것이라고 확신할 수 있습니까?

해결해야 할 의문점은 많지만, 결국 요점은 DevOps 환경에서 시스템 리스크가 수직, 수평 방향에서 모두 늘어난다는 사실입니다. 수직 방향의 경우, 기존 환경에 비교해 고려해야 할 리스크가 훨씬 많습니다. 수평 방향의 경우, 감염된 패키지 하나가 엄청난 영향을 미칠 수 있습니다. SolarWinds 등 수많은 사례를 통해 이 점을 확인한 바 있습니다.

DevOps와 클라우드 여정을 시작하면서 제로 트러스트를 구축할 기회를 허비해서는 안 됩니다.