컨테이너 보안이란?

컨테이너 보안은 컨테이너화된 애플리케이션을 맬웨어와 기타 취약점으로부터 보호하는 프로세스입니다. 컨테이너 보안에는 지원하는 애플리케이션에서 기반이 되는 인프라에 이르기까지 Linux 컨테이너를 보호하는 빌드, 배포, 런타임 사례를 정의하고 준수하는 작업이 포함됩니다. 

조직이 마이크로서비스 설계 패턴 및 컨테이너 기술(예: Docker, 쿠버네티스)을 도입하면서 보안 팀은 이러한 인프라 전환을 지원하는 컨테이너 보안 솔루션 개발 과제를 안게 되었습니다. 컨테이너 보안은 통합되고 지속적이어야 하며 기업의 전반적인 보안 태세를 지원할 수 있어야 합니다. 

컨테이너 오케스트레이터, 즉 쿠버네티스는 컨테이너 보안에서 중요한 역할을 하며, 풍부한 상황별 데이터에 대한 액세스 권한을 제공하여 가시성, 컴플라이언스, 상황별 리스크 프로파일링, 네트워킹, 런타임 감지를 강화합니다. 효과적인 컨테이너 보안은 배포, 포드, 네트워크 정책 등과 같은 쿠버네티스 구문을 기반으로 합니다. 예를 들어, 쿠버네티스 네트워크 정책은 포드 간 통신을 제어하고 공격자의 영향 범위를 최소화하는 데 사용되어야 하는 기본 보안 기능입니다.

일반적으로 엔터프라이즈를 위한 지속적 컨테이너 보안의 특징은 다음과 같습니다.

• 컨테이너 파이프라인과 애플리케이션 보안
• 컨테이너 배포 환경과 인프라 보안
• 런타임 시 컨테이너화된 워크로드 보안 유지

기업에서 컨테이너 보안 이니셔티브를 구현하는 방법을 알아보세요.

기존 소프트웨어 개발 방식에서는 개발을 종료하기 전에 보안 검토가 최종 테스트 단계가 될 수 있었습니다. 그러나 현대적인 클라우드 네이티브 개발 워크플로우의 경우 공격 표면이 훨씬 크기 때문에 보안 문제가 더 복잡해졌습니다. 컨테이너가 표준 애플리케이션 제공 형식인 클라우드 네이티브 환경에서 코드는 자주 업데이트되고 여러 리포지토리에서 수집됩니다. 구성 오류와 같은 인적 오류는 개발 및 배포 주기의 여러 지점에서 무단 액세스를 야기할 수 있습니다. 보안 취약점은 사실상 어디서든 발생할 수 있습니다. 이러한 이유에서 보안은 지속적인 프로세스가 되어야 합니다.

자동화를 통해 컨테이너 배포를 해결하듯이(쿠버네티스와 같은 컨테이너 오케스트레이션 툴 사용) 보안에도 자동화가 필요합니다. DevSecOps 원칙(DevOps의 보안을 강화하기 위해 생성된 개념)을 사용하여 개발 주기 전체에 걸쳐 코드를 지속적으로 검사하고 확인할 수 있습니다. 취약점을 간과하면 시간이 많이 소요되는 예기치 못한 문제가 발생할 수 있으므로, 조기에 신속하게 발견해 해결하는 것이 좋습니다. 컨테이너는 변경 불가능하기 때문에 컨테이너 보안의 경우 실행 중이 아닌 구축 단계에서 코드에 패치를 적용하면 컨테이너가 삭제되고 재구축될 때 취약점이 다시 발생하지 않습니다.

컨테이너 이미지를 스캔하여 맬웨어와 기타 보안 취약점을 찾는 것은 중요한 단계로, 보안의 여러 계층 중 하나여야 합니다. 조직은 전체 소프트웨어 공급망, 즉 종속성과 런타임 환경을 포함한 컨테이너화된 소프트웨어의 개발과 배포의 모든 단계의 보안을 고려해야 합니다. 

공급망 보안을 고려하는 컨테이너화된 개발의 구체적인 전략 몇 가지는 다음과 같습니다.

• 신뢰할 수 있는 콘텐츠와 엔터프라이즈급 콘텐츠 리포지토리에서 고급 보안 및 액세스 제어 기능을 통해 사전 강화된 이미지를 제공합니다.
• 제로 트러스트 접근 방식에서는 중요한 리소스에 액세스 수준을 최대한 낮게 할당합니다.
• 코드형 정책은 보안 제어를 CI/CD 파이프라인에 임베딩합니다.
• 서명과 검증으로 증명을 시행하고 컨테이너 이미지가 조작되지 않았다는 것을 입증하여 신뢰를 구축합니다.
• GitOps 사례는 애플리케이션과 컨테이너의 보안 구성을 관리하는 데 도움이 됩니다.

이미지 수집

컨테이너는 컨테이너 이미지라는 파일의 계층에서 생성됩니다. 

Buildah와 같은 툴을 사용하면 기존 컨테이너 이미지 시작점의 존재 여부에 관계없이 처음부터 OCI 및 Docker 호환 이미지를 빌드할 수 있습니다.

컨테이너 이미지는 클라우드 네이티브 환경의 표준 애플리케이션 제공 형식이지만 클라우드 네이티브 기업도 클라우드 공급업체 간 워크로드를 혼합합니다. 이상적인 컨테이너 보안 솔루션은 프라이빗 하드웨어, 공유 데이터 센터, Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform과 같은 퍼블릭 클라우드 등 인프라 실행 위치와 관계없이 모든 아키텍처를 지원해야 합니다.

베이스 이미지 또는 골든 이미지(golden image)는 보안에 가장 중요한 요소입니다. 파생 이미지를 생성하는 시작 지점으로 사용되기 때문입니다. 컨테이너 보안은 베이스 이미지를 위한 신뢰할 수 있는 소스를 찾는 데서 시작됩니다. 이미지가 알려진 기업 또는 오픈소스 그룹에서 제공되는지, 평판이 좋은 레지스트리에서 호스팅되는지, 이미지의 모든 구성 요소에 대한 소스 코드를 사용할 수 있는지 확인하세요.

하지만 신뢰할 수 있는 이미지를 사용하는 경우에도 애플리케이션을 추가하고 구성을 변경하면 새로운 변수가 나타날 수 있습니다. 외부 콘텐츠를 도입해 애플리케이션을 빌드하는 경우 사전 예방적인 취약점 관리를 수행해야 합니다.

• 레지스트리에 내장되어 있거나 별도로 구축되어 있는 이미지 스캐너를 사용하여 모든 이미지를 정기적으로 스캔합니다. 특정 언어, 패키지, 이미지 계층을 기반으로 스캔하는 스캐너를 찾으세요.
• 정책 또는 문서화된 모범 사례를 위반한 개조된 컨테이너 이미지(컨테이너 구성 오류라고 함)를 식별해 잠재적인 침해 가능성과 그로 인한 영향을 줄입니다.

취약점 예측과 완화

컨테이너가 널리 사용되는 것은 전체 라이프사이클과 다양한 워크플로우 및 배포 대상 전반에 걸쳐 애플리케이션이나 서비스, 그 모든 종속성 요소를 구축, 패키징, 활성화하기가 쉽기 때문입니다. 그러나 컨테이너 보안에는 몇 가지 과제가 남아 있습니다. 컨테이너는 더욱 세분화된 워크로드 수준의 보안을 구현하는 데 도움이 될 수 있지만 새로운 인프라 구성 요소와 새로운 공격 범위가 생기기도 합니다. 적합한 컨테이너 보안 솔루션은 클러스터 인프라와 오케스트레이터, 실행 중인 컨테이너화된 애플리케이션을 보호하는 데 도움이 되어야 합니다.

정적인 보안 정책과 체크리스트가 엔터프라이즈 컨테이너로 확장되지는 않습니다.

• 공급망에는 더 많은 보안 정책 서비스가 필요하며,
• 보안 팀에서는 컨테이너화된 환경의 네트워킹과 거버넌스 요구 사항이 균형을 유지하도록 해야 합니다.
• 빌드, 유지 관리, 서비스 단계에서 사용되는 툴에는 서로 다른 권한 정책이 지정되어야 합니다.

효과적인 컨테이너 보안 프로그램은 이미지가 배포되기 전에 실시간으로 취약점을 해결하고 공격 표면을 줄이는 방법을 모색하는 동시에 출처 상세 정보를 유지합니다. 컨테이너 파이프라인에 보안을 구축하고 인프라를 보호하여 컨테이너의 안정성과 확장성 및 신뢰성을 보장할 수 있습니다.

컨테이너 이미지를 수집하는 경우 다음 사항을 확인해야 합니다.

• 컨테이너 이미지는 신뢰할 수 있는 소스를 바탕으로 서명되어 있는가?
• 이미지의 출처는 어디이며 이미지를 어떻게 재구축할 수 있는가?
• 해당 이미지의 마지막 스캔 날짜는 언제인가?
• 런타임 및 운영 체제 계층이 최신 상태인가?
• 컨테이너가 얼마나 신속하게, 그리고 얼마나 자주 업데이트되는가?
• 보안 리스크를 식별했는가? 이를 어떻게 추적할 것인가?

이미지를 가져온 다음에는 팀이 사용하는 모든 컨테이너 이미지에 대한 액세스와 활성화를 관리합니다. 이는 다운로드한 이미지와 구축한 이미지를 보호하기 위한 것입니다. 프라이빗 레지스트리를 사용하면 역할 기반 할당을 통해 액세스를 제어하면서 컨테이너에 관련 메타데이터를 할당함으로써 콘텐츠를 관리할 수 있습니다. 이 메타데이터는 알려진 취약점을 식별하고 추적하는 데 도움이 됩니다. 또한 프라이빗 컨테이너 레지스트리를 통해 저장한 이미지에 대한 정책을 자동화하고 할당하여 컨테이너 환경에 취약점을 야기할 수 있는 인적 오류를 최소화할 수 있습니다. 엔터프라이즈급 보안 기능을 갖춘 컨테이너 레지스트리에는 취약점 스캐너도 기본으로 포함됩니다.

액세스 관리 방법을 결정할 때는 다음 사항을 확인해야 합니다.

• 컨테이너 이미지를 관리하기 위해 어떤 역할 기반 액세스 제어를 사용할 수 있는가?
• 이미지 분류를 지원하는 태그 지정 기능이 있는가? 개발 환경, 테스트 환경, 프로덕션 환경용으로만 승인된 것으로 이미지에 태그를 지정할 수 있는가?
• 레지스트리가 알려진 취약점을 추적할 수 있는 가시적인 메타데이터를 제공하는가?
• 레지스트리를 사용하여 정책(예: 서명, 애플리케이션 코드 스캔 등 확인)을 할당하고 자동화할 수 있는가?

파이프라인의 마지막 단계는 배포입니다. 빌드를 완료한 후에는 CIS(Center for Internet Security)와 미국 국립표준기술연구소(NIST)에서 수립한 것과 같은 산업 표준에 따라 빌드를 관리해야 합니다. 여기에서 관건은 특히 새로운 취약점이 발견되는 경우 보안 문제가 있는 빌드에 플래그를 지정하는 정책을 자동화하는 방법을 파악하는 것입니다. 취약점 스캔은 중요하지만 컨테이너 환경을 보호하는 데 사용되는 더 큰 보안 이니셔티브의 일부일 뿐입니다.

컨테이너 패치 적용은 컨테이너 재구축에 비해 좋은 해결책이 되기는 어려우므로 보안 테스트 통합에는 재구축 자동화를 트리거하는 정책이 포함되어야 합니다. 문제를 추적하고 플래그를 지정할 수 있는 구성 요소 분석 툴에서 실행하는 것은 이러한 단계의 첫 번째입니다. 두 번째는 자동화된 정책 기반 배포를 위한 툴링을 설정하는 것입니다.

보안 테스트 및 배포 자동화를 통합하는 경우 다음 사항을 확인해야 합니다.

• 프로덕션 환경에 배포되기 전에 수정해야 하는 알려진 취약점이 컨테이너에 있는가?
• 배포가 올바르게 구성되었는가? 높은 수준의 권한이 필요하지 않은데 과도한 권한이 부여된 컨테이너가 있는가? 읽기 전용 루트 파일 시스템을 사용하고 있는가?
• CIS Benchmark 및 NIST SP 800-190 컴플라이언스를 준수하고 있는가?
• 네트워크 정책, 네임스페이스 등과 같은 내장된 기능을 사용하여 민감한 것으로 간주되는 워크로드를 격리하고 있는가?
• SELinux, AppArmor, seccomp 프로필과 같은 내장형 보안과 하드닝 기능을 사용하고 있는가?

컨테이너 보안은 테스트와 배포 후에도 계속되며, 컨테이너화된 애플리케이션이 실행 시점까지 확장됩니다. 따라서 위협 감지, 네트워크 보안, 인시던트 대응과 같은 측면이 더욱 중요해집니다.

런타임 시 애플리케이션은 빌드 중 놓친 취약점과 구성 오류가 악용될 수 있는 예측 불가능한 실제 위협에 직면할 수 있습니다. 따라서 런타임 보안에는 예상치 못한 방식으로 동작하는 애플리케이션 찾기가 포함되어야 합니다. 런타임 시 이상 감지 기능을 사용하면 권한 에스컬레이션, 암호화폐 채굴, 예기치 못한 네트워크 흐름, 컨테이너 이스케이프, 기타 보안되지 않은 동작들을 식별할 수 있습니다.

네트워크 분할 역시 공격 표면을 최소화하는 데 있어 우려되는 부분입니다. 쿠버네티스에서 기본 네트워크 정책은 포드가 클러스터 내의 다른 포드들과 통신하는 것을 허용합니다. 제로 트러스트 정책을 실행하면 손상된 단일 포드로 인해 클러스터 내의 모든 포드가 손상되는 일은 없습니다.

마지막으로, 인시던트 대응 전략을 통해 팀은 이벤트에 적절히 대응할 수 있습니다. 대응에는 보안 정보 및 이벤트 관리(SIEM) 시스템에 이벤트 전송하기, 애플리케이션 소유자에게 문제 해결이 필요한 배포에 관한 상세 정보와 단계 알리기, 나아가 포드를 자동으로 중단하고 재시작하기 등이 포함될 수 있습니다. 대응은 실행 중인 컨테이너에 패치를 적용하는 것이 아니라, 문제가 되는 컨테이너를 재구축하고 재배포하는 사례를 따라야 합니다.

컨테이너 보안의 또 다른 계층은 컨테이너의 노드/호스트 운영 체제(OS)가 제공하는 격리 기능입니다. 최대 컨테이너 격리를 제공하는 호스트 OS가 필요한데, 이는 컨테이너 배포 환경을 보호하는 데 있어서 매우 중요한 부분입니다. 컨테이너화된 쿠버네티스 환경의 호스트 OS는 컨테이너 간에 공유되며, 쿠버네티스와 상호 작용하여 컨테이너(또는 컨테이너 포드)를 생성하고 관리하는 컨테이너 런타임에 의해 관리됩니다. 

손상된 단일 컨테이너가 호스트 OS와 다른 모든 컨테이너를 손상하지 못하도록 호스트 OS는 컨테이너에서 격리되어야 합니다. 컨테이너 플랫폼이 복원력을 갖추도록 하려면 네트워크 네임스페이스를 사용해 애플리케이션과 환경을 격리하고 보안 마운트를 통해 스토리지를 연결합니다. 호스트 네트워크 네임스페이스, IPC 네임스페이스 또는 UPC 네임스페이스를 공유하도록 컨테이너 런타임을 구성하면 안 됩니다. 컨테이너에 최적화된 사전 강화된 호스트 운영 체제를 선택하고 호스트 취약점 스캔을 사용하세요.

API 관리 솔루션에는 인증과 권한 부여, LDAP 통합, 엔드포인트 액세스 제어, 속도 제한 등의 기능이 포함되어야 합니다.

컨테이너 인프라 보호 방법을 결정하는 경우 다음 사항을 확인해야 합니다.

• 어느 컨테이너가 서로 액세스해야 하는가? 컨테이너가 서로를 어떻게 인식할 수 있는가?
• 네트워크, 스토리지 등의 공유 리소스에 대한 액세스와 관리를 어떻게 제어할 것인가?
• 컨테이너 상태를 어떻게 모니터링할 것인가?
• 수요를 충족하기 위해 애플리케이션 용량을 어떻게 자동 확장할 것인가?
• 호스트 업데이트를 어떻게 관리할 것인가? 모든 컨테이너를 동시에 업데이트할 것인가?

Red Hat® OpenShift®는 Red Hat Enterprise Linux®를 포함하며, 컨테이너 애플리케이션 라이프사이클을 자동화하고 보안을 컨테이너 파이프라인에 통합하며 DevOps에서 DevSecOps 전략으로 이전할 수 있도록 설계되었습니다. Red Hat의 컨테이너 카탈로그는 다수의 인증된 이미지와 실행 환경, 데이터베이스, 그리고 Red Hat Enterprise Linux가 실행되는 모든 환경에서 실행할 수 있는 미들웨어에 대한 액세스를 제공합니다. Red Hat의 이미지는 항상 출처와 무결성을 보장하기 위해 서명되고 검증됩니다.

Red Hat은 새롭게 발견된 취약점에 대한 컨테이너 이미지를 모니터링하고(지속적으로 업데이트되고 공개되는 상태 지수 포함), Red Hat의 퍼블릭 레지스트리로 푸시되는 컨테이너 재구축과 보안 업데이트를 릴리스합니다. Red Hat Advanced Cluster Security for Kubernetes는 DevOps 및 보안 툴을 통합해 위협을 최소화하고, 보안 정책을 실행할 수 있도록 지원합니다. 이를 통해 애플리케이션에 대한 운영 위험을 최소화할 수 있습니다.

Red Hat Service Interconnect를 통해 컨테이너는 서로 액세스하고 통신하면서, 조직의 보안 또는 사용자의 데이터에 더해지는 리스크를 최소화할 수 있습니다.

Red Hat의 보안 파트너는 인증된 통합을 활용해 Red Hat의 컨테이너 보안 기능을 확장하고 강화할 수 있습니다. Red Hat OpenShift에는 보안이 기본 포함되어 있어 보안 파트너 솔루션을 보완해 DevOps 라이프사이클 전반에서 애플리케이션과 컨테이너를 보호합니다.

또한 다음과 같은 유용한 작업도 가능합니다.

• 웹 스케일 컨테이너 오케스트레이션 및 관리
• 여러 사용자가 협업할 수 있는 기능을 갖춘 다양한 웹 콘솔
• CLI & IDE 인터페이스
• CI와 통합
• 빌드 자동화 & S2I(Source-to-Image)
• 배포 자동화
• 원격 스토리지 볼륨 지원
• 간소화된 설치 & 관리
• 지원되는 프로그래밍 언어, 프레임워크 & 서비스의 방대한 컬렉션