클라우드 공급망 보안 확보
여러 인시던트가 연달아 발생하면서 기업 전체에 심각한 리스크를 초래하는 공급망 취약점이 드러나면서 공급망 보안은 수많은 리더 기업의 최우선 사안이 되었습니다. Log4j 및 SolarStorm과 같은 보안 문제로 인해 크고 작은 기업은 존재조차 몰랐던 리스크에 큰 타격을 입었습니다. 공급망 공격이 발생하는 경우, 소프트웨어 스택을 이루는 하나의 구성 요소 취약점으로 인해 기업 전체가 잠재적 악용 리스크에 노출될 수 있습니다.
Palo Alto Networks 산하 Unit 42®에서 실시한 연구 결과, 클라우드 공급망 내에서 심각한 우려를 일으킬 원인으로 간주해야 하는 중대한 리스크가 확인되었습니다. 연구진이 확인한 바에 따르면, 클라우드 인프라를 구축하는 데 쓰이는 타사 코드 중 63%는 안전하지 않다고 합니다. 이에 따른 보안 리스크에는 기업을 위험에 노출하는 잘못된 구성, 부적절한 권한 할당, 취약한 코드 라이브러리 등이 포함됩니다.
클라우드 공급망이란 무엇인가요?
보통 사람들이 공급망에 대해 이야기할 때 물리적인 위젯이나 상품 등이 한 장소에서 다른 장소로 이동하는 것이라고 생각합니다. 대다수의 기업에서는 아직 이러한 실제 상품의 이동을 클라우드에서 실행되는 애플리케이션이 지원하는 경우가 많다는 사실을 제대로 이해하지 못하고 있습니다. 한 단계 더 나아가자면, 자체적으로 클라우드 네이티브 애플리케이션을 구축하는 기업의 경우 공급망 내부에 공급망이 있습니다.
최신 클라우드 네이티브 애플리케이션은 크게 세 가지 단계에 따라 구축 및 구성됩니다. 첫 단계에서는 클라우드 인프라를 프로비저닝합니다. 두 번째 단계로 애플리케이션을 구축하는 플랫폼인 Kubernetes® 컨테이너 오케스트레이션 서비스를 보유합니다. 세 번째 단계에서는 애플리케이션 컨테이너 이미지 자체를 구축합니다. 이 세 가지 레이어 중 하나라도 잘못 구성되거나 취약한 코드 요소를 포함할 수 있습니다.
SBOM(Software Bill of Materials) 드롭
현재 클라우드 공급망 보안은 복잡하지만, 이는 이러한 복잡성을 단순화할 기회를 제공한 셈이기도 합니다. 클라우드 네이티브 애플리케이션의 경우, 거의 항상 컨테이너를 사용합니다. 따라서 기업에서는 이를 통해 애플리케이션 내부 실제 상황을 간편하게 추적할 수 있습니다.
컨테이너는 서술적이기 때문에 SBOM(Software Bill of Materials) 개념을 간소화해줍니다. 사용자는 컨테이너 매니페스트 내부를 라인별로 확인하여 컨테이너 내부 내용을 파악할 수 있습니다.
일부 행정 명령 14028 에서 미국 정부와 거래하는 공급업체는 SBOM을 사용해야 한다고 규정하면서 SBOM이 소프트웨어 공급망에 포함되는 경우가 늘어나고 있습니다.
클라우드 공급망 보안 확보를 위한 권장 사항
클라우드 공급망에는 다양한 계층, 구성 요소와 소스가 포함되어 있어 복잡할 수 있습니다. 그렇지만, 클라우드 공급망 보안은 크게 네 가지 전략적 접근 방식으로 관리할 수 있습니다.
1단계: 전략 정의
원점 회귀 접근 방식으로 시작하여 클라우드 공급망에 적용한 전체적인 전략을 개략적으로 정하는 것이 매우 중요한 첫 단계입니다. 원점 회귀라는 개념은 프로세스 초반에 보안을 고려하는 것이며, 이를 DevSecOps라고도 합니다. 전략 개요를 대량의 문서로 작성할 필요도 없습니다. 처음에 필요한 것은 비전, 역할과 책임을 개략적으로 정하는 것뿐입니다. 여기서 시작해 시간을 두고 반복 작업을 거칩니다.
2단계: 소프트웨어의 출처와 제작 방식 파악
이 단계에서는 약간의 심층 조사를 통해 소프트웨어가 기업 내 어디에서, 어떻게 제작되는지 파악해야 합니다. 실제로 개발자의 노트북 컴퓨터에서 소프트웨어가 탄생하여 프로덕션 클라우드 환경에 도달하기까지의 과정을 본격적으로 알아보고 문서로 기록합니다.
3단계: 보안 품질 가드레일 파악 및 구현
기존의 제조 공정에서는 오래전부터 품질 관리가 운영 업무의 일부였습니다. 하지만 클라우드 애플리케이션의 경우 항상 그렇지는 않습니다. 이 경우 소프트웨어 제작 단계를 따라 기업에서 선제적인 검사가 필요한 지점이 어디인지 파악해야 합니다. 우수한 보안 컨트롤에는 자동화를 최대한 많이 포함하여 수작업 코드 검토에 드는 노력을 보완해야 하는데, 이러한 업무는 자동으로 확장되지 않습니다.
4단계: 인증 고려
처음 세 단계는 기업에서 개발 중인 애플리케이션에 보안을 내장하는 작업 위주이지만, 애플리케이션 자체와 앱이 사용하는 클라우드 인프라의 보안도 검증해야 합니다. 바로 이 부분에서 인증이 제 역할을 합니다. 대규모 클라우드 제공자는 보통 수많은 타사 증명서와 인증을 포함합니다. 가장 보편적인 예로 SOC2 Typ II 및 ISO 27001 이 있는데, 이를 통해 제공자가 자사 보안 컨트롤을 구현하고 그 유효성을 독립적으로 확인한 방법을 알아볼 수 있습니다.
이러한 인증을 통해 제공자가 체계적으로 리스크를 검토하고 평가하는 방법을 파악할 수 있어야 하는 것이 중요합니다. 이는 클라우드 사용 범위를 확장하면 클라우드 제공자가 곧 귀사가 직접적으로 확장된 것과 같기 때문에 중요합니다.
여기에 간략하게 설명한 모든 단계를 활용하면 보안 리더로서 보안을 원점 회귀로 전환하는 것은 물론, 보안과 개발을 동일시하는 확고한 경로를 마련할 수 있습니다. 기업의 클라우드와 클라우드 네이티브 애플리케이션에 대한 의존도가 점점 높아지고 있으므로, 지금이 클라우드 공급망 보안 전략을 구현할 때입니다.