컨테이너 보안은 컨테이너 이미지 및 이미지 리포지토리, 실행 중인 컨테이너의 콘텐츠, 기본 컨테이너 인프라를 포함하여 컨테이너화된 워크로드의 모든 구성 요소를 보호하는 관행입니다.
오늘날 컨테이너를 배포하기 위한 다양한 도구와 플랫폼이 있기 때문에 컨테이너 보안에 영향을 미치는 특정 프로세스는 환경마다 다릅니다. 그러나 컨테이너 보안의 기본 구성 요소는 관련된 특정 기술에 관계없이 동일합니다.
컨테이너는 애플리케이션을 실행할 수 있는 유연하고 이식 가능한 방법을 제공하기 때문에 소프트웨어 배포를 위한 인기 있는 솔루션이 되었습니다. 그러나 컨테이너는 소프트웨어 제공 파이프라인과 호스팅 스택에 다음과 같은 새로운 계층을 도입하기도 합니다.
이러한 구성 요소는 소프트웨어 환경에 복잡성을 더하고 공격 표면을 증가시킵니다. 컨테이너 보안은 조직이 위험과 위협으로부터 이러한 구성 요소를 보호하는 동시에 컨테이너화된 호스팅 환경과 컨테이너화되지 않은 호스팅 환경 모두에 존재하는 다른 리소스(예: 컨테이너를 호스팅하는 서버에서 실행되는 운영 체제)를 방어할 수 있는 방어 수단을 갖추도록 하는 데 중요합니다.
컨테이너 보안에는 더 큰 공격 표면을 관리해야 한다는 사실 외에도 컨테이너는 개발자, IT 엔지니어 및 보안 분석가가 워크로드에 대해 갖는 직접적인 가시성을 제한하기 때문에 컨테이너 보안이 어렵습니다. 결과적으로 위협을 탐지하고 대응하는 것이 더 어려울 수 있습니다.
예를 들어 분석가가 컨테이너를 호스팅하는 운영 체제에서 사용할 수 있는 메트릭 및 로그만을 기반으로 보안 모니터링을 수행하는 경우 컨테이너 자체에서 생성된 메트릭 및 로그는 일반적으로 운영 체제에서 관리되지 않으므로 컨테이너 내에서 비정상적인 활동을 감지하지 못할 수 있습니다. 각 컨테이너 내부에서 어떤 일이 일어나고 있는지 파악하기 위해 엔지니어는 컨테이너와 호스트 서버를 분리하는 추상화 계층을 뚫을 수 있는 보안 도구가 필요합니다.
모든 컨테이너화된 환경에 동일한 유형의 도구가 포함되어 있는 것은 아닙니다. 예를 들어 오케스트레이터를 사용하지 않고 컨테이너를 실행할 수 있습니다. 즉, 컨테이너 보안의 구성 요소는 팀이 컨테이너를 관리하는 데 사용하는 특정 도구와 플랫폼에 따라 달라질 수 있습니다.
즉, 대부분의 경우 컨테이너 보안에는 다음과 같은 주요 구성 요소가 포함됩니다.
공격자가 컨테이너 이미지를 호스팅하는 레지스트리를 침해하면 악성 코드를 삽입할 수 있으며, 이로 인해 오염된 이미지를 기반으로 컨테이너를 실행하는 모든 환경으로 멀웨어가 확산됩니다.
이러한 위험으로부터 보호하기 위해 엔지니어는 컨테이너 레지스트리의 내용에 대한 무단 액세스를 방지하는 엄격한 액세스 제어를 구현해야 합니다. 또한 악의적인 활동의 징후가 될 수 있는 비정상적인 액세스 패턴에 대해 레지스트리를 모니터링해야 합니다.
공격자는 컨테이너 런타임의 취약성을 악용하여 컨테이너를 제어하고 컨테이너를 호스팅하는 서버까지 제어할 수 있습니다. 조직은 컨테이너 런타임 소프트웨어를 패치하고 최신 상태로 유지하여 Docker 컨테이너 보안(또는 사용하는 런타임의 보안)을 관리함으로써 이러한 위험을 관리할 수 있습니다.
관리자가 컨테이너를 실행할 때 적용하는 환경 구성은 보안에 영향을 미칠 수 있습니다. 예를 들어, 컨테이너를 루트로 실행하는 것은 위반으로 인한 잠재적 피해를 증가시키는 상승된 권한을 부여하기 때문에 일반적으로 모범 사례가 아닙니다. 컨테이너를 호스팅하는 환경에 적용되는 설정을 보호하는 것은 컨테이너 보안의 필수 구성 요소입니다.
Kubernetes와 같은 오케스트레이터를 사용하는 컨테이너화된 워크로드의 경우 오케스트레이션 플랫폼을 알려진 취약성으로부터 보호하는 것이 중요합니다. 또한 관리자는 위협으로부터 방어하기 위해 오케스트레이터를 구성하고 관리할 때 모범 사례를 따라야 합니다. 예를 들어 Kubernetes 컨테이너 보안에서 관리자는 기본 제공 RBAC(역할 기반 액세스 제어) 프레임워크를 사용하여 리소스에 대한 액세스를 제한해야 합니다.
Stateful 컨테이너화된 애플리케이션은 스토리지 리소스에 따라 달라집니다. 해당 스토리지에서 호스팅되는 데이터를 보호하는 것은 컨테이너 보안의 또 다른 중요한 구성 요소입니다.
컨테이너는 네트워크를 사용하여 서로 통신하고 외부 요청을 수락 및 수신합니다. 따라서 엔지니어는 내부 및 외부 네트워크가 올바르게 구성되었는지 확인하고 비정상적인 활동을 모니터링하여 내부 및 외부 네트워크를 모두 보호해야 합니다.
컨테이너가 호스팅되는 위치에 따라 특정 추가 컨테이너 보안 솔루션 또는 사례를 사용할 수 있습니다.
예를 들어, Docker를 사용하는 팀은 플랫폼에 내장된 보안 스캐너를 통해 Docker 컨테이너 보안의 일부 측면을 관리하여 컨테이너 이미지 내의 악의적인 종속성을 감지할 수 있습니다. Kubernetes네이티브 RBAC 프레임워크는 컨테이너화된 워크로드를 보호하는 데 도움이 될 수 있습니다.
마찬가지로 AKS(Azure Kubernetes Service), GKE(Google Kubernetes Engine) 또는 EKS(Elastic Kubernetes Service)와 같은 관리형 서비스를 통해 컨테이너를 실행하는 경우 조직은 각 서비스의 클라우드 제공업체 플랫폼에 내장된 보안 도구를 활용하여 워크로드를 모니터링하고 보호할 수 있습니다.
팀이 컨테이너를 보호하는 데 사용하는 컨테이너 보안 솔루션은 다음과 같은 핵심 기능을 제공해야 합니다.
대부분의 컨테이너화된 워크로드의 경우 다음 모범 사례는 공격 위험을 최소화하고 팀의 탐지 능력을 최대화하는 데 도움이 될 수 있습니다.
관리자는 컨테이너화된 호스팅 스택 내에서 구성 요소를 설정할 때 최소 권한 원칙을 따라야 합니다. 최소 권한은 사용 권한을 필요한 가장 낮은 수준으로 제한하는 것을 의미합니다.
멀웨어를 포함할 가능성이 높은 신뢰할 수 없는 레지스트리에서 컨테이너 이미지를 다운로드하지 마세요. 가능한 경우 잘 정립되고 신뢰할 수 있는 조직에서 유지 관리하는 레지스트리를 선택합니다.
컨테이너 보안과 관련하여 환경의 일부 계층만 검사하고 모니터링하는 것만으로는 충분하지 않습니다. 조직은 컨테이너 레지스트리 및 이미지에서 런타임 환경, 기본 인프라 및 그 사이의 모든 것에 이르기까지 모든 구성 요소를 지속적으로 모니터링해야 합니다. 포괄적인 모니터링은 위험을 감지하는 관리자의 능력을 극대화합니다.
컨테이너에 대한 공격 표면은 본질적으로 컨테이너화되지 않은 앱보다 크지만, 팀은 불필요한 구성 요소 또는 계층을 실행하지 않도록 하여 공격 표면을 줄일 수 있습니다. 예를 들어 개발자가 테스트 목적으로 시작하는 컨테이너는 테스트가 완료되는 즉시 종료해야 합니다.
컨테이너 이미지 내에 존재하는 콘텐츠가 적을수록 취약성 위험이 낮아집니다. 이러한 이유로 미니멀리스트 이미지, 즉 애플리케이션을 실행하는 데 필요한 라이브러리, 소프트웨어 패키지 및 기타 구성 요소만 포함하는 이미지를 선호합니다.
효과적인 컨테이너 보안의 핵심은 컨테이너가 의존하는 모든 프로세스와 리소스에 보안을 통합하는 것입니다. CloudGuard for Workload Protection 은 다음을 제공하는 포괄적인 컨테이너 보안 솔루션을 제공하여 이를 용이하게 합니다.
컨테이너 보안 가이드를 읽거나 무료 데모를 요청하여 자세히 알아보세요.
피드백