컨테이너 환경의 5가지 주요 보안 리스크

컨테이너 기반 애플리케이션 개발·서비스 환경을 도입해야 할 때 고려해야 할 보안 문제는 무엇이 있을까.

컨테이너 이미지를 비롯해 아키텍처상 구성요소 취약점이 증가하고 있다는 경고가 최근 잇달아 나오고 있는 가운데 이미지, 레지스트리, 오케스트레이터, 컨테이너, 호스트 운영체제(OS)까지 컨테이너 구성요소별 보안 리스크를 살펴봤다.

조현익 베스핀글로벌 섹옵스(SecOps) 프로덕트 매니저가 지난 29일 베스핀글로벌이 개최한 ‘클라우드 네이티브 보안 웨비나’에서 발표한 내용을 정리했다. 조 매니저는 ‘컨테이너 보안, 5가지 리스크를 주의하라’는 주제 발표에서 컨테이너 이미지 생성부터 이를 테스트하고 저장, 배포, 관리하는 전체 시스템과 아키텍처에 걸쳐 발생 가능한 보안 위험을 식별, 분석해 관리해야 한다고 강조했다.

이미지 리스크

컨테이너 이미지 리스크 관리는 매우 중요하다. 이미지 리스크는 취약점, 구성 결함, 악성코드 삽입 등으로 발생할 수 있다.

이미지는 애플리케이션을 실행하는데 필요한 모든 구성요소가 포함된 정적 파일로, 매우 중요하다. 만일 보안 업데이트가 누락됐거나 지원되지 않은 구성요소가 있을 경우 취약점이 발생할 수 있다. 만일 취약점이 존재하는 상태로 배포될 경우 보안위험은 커진다.

이미지 취약점이 없더라도 구성이 올바로 이뤄지지 않으면 공격에 노출될 수 있다. 불필요한 계정을 갖고 있거나 불필요하게 네트워크에 노출되는 서비스가 있을 경우에도 구성 결함이 발생할 수 있다.

패키지된 파일 가운데 악성코드가 포함될 경우도 매우 위험하다. 배포 환경 내 다른 컨테이너나 호스트를 공격할 수 있기 때문이다 이를 예방하기 위해서는 안전성을 검증하지 않은 구성요소는 사용하지 않아야 한다.

조 매니저는 “이미지는 내부에서 직접 만들거나 외부 이미지를 재사용하기도 한다. 이 과정에서 위험이 발생할 수 있기 때문에 이미지는 반드시 신뢰할 수 있는 절차를 통해 제공받고 사용해야 한다. 철저한 검증을 통해 안전성을 보장받는 절차가 필요하다”고 말했다.

레지스트리 리스크

이미지는 레지스트리에 저장되고 배포된다. 이미지 취약점이 해결됐다고 하더라도 레지스트리에 어떠한 시스템이든 필요할 때 연결해 사용할 수 있다면 보안이 취약해질 수 있다. 따라서 반드시 연결되는 채널을 명확한 정책에 따라 운영하고 통신 암호화가 적용돼야 한다.

레지스트리에 중요 데이터에 접근하거나 특정 권한이 필요한 이미지가 포함돼 있기 때문에 사용자 인증·권한 부여 요구사항이나 절차가 미흡할 경우 위협으로 작용할 수도 있다. 만일 불충분한 인증·권한 관리로 인해 악의적으로 이미지가 변경될 경우 시스템에 큰 영향을 미칠 수 있다.

오케스트레이터 리스크

오케스트레이터는 컨테이너 환경 전체를 제어 관리하는 중요한 역할을 수행한다. 때문에 사용자 계정 및 권한관리가 매우 중요하다. 무단 접근이 허용되는 경우 자칫 동일한 오케스트레이터가 관리하는 다른 컨테이너의 작동에 영향을 주거나 다른 사용자가 배포한 컨테이너 정책을 바꾸는 등의 악의적인 행위에 노출되는 위협이 나타날 수 있다.

조 매니저는 무단 접근을 막을 수 있도록 원칙적으로 조직이 사용하는 인증 디렉토리 서비스와 연계해 써야 한다고 권고했다. 디렉토리 서비스가 분리된 경우 퇴사자의 계정이 삭제되지 않고 남아있게 되는 등 운영 계정관리가 취약해질 수 있기 때문이다.

잘못된 컨테이너 네트워크 분리, 그리고 서로 다른 수준의 민감도를 가진 워크로드의 혼합으로 인한 리스크도 존재한다. 컨테이너 환경은 암호화된 오버레이 네트워크로 인해 기존 네트워크 관리도구로 모니터링할 수 없다. 가상 네트워크를 통해 중요도와 민감도가 서로 다른 앱이 공유되는 경우에는 위협이 커질 수 있다. 그리고 중요성에 대한 수준이 다른 애플리케이션을 동일 호스트에 함께 배치할 경우에도 위험성이 존재한다. 이 문제를 해소하기 위해서는 설계 단계에서부터 신경을 써야 한다는 게 조 매니저의 설명이다.

그는 “네트워크가 분리돼 있지 않을 경우 컨테이너가 취약점 등으로 인해 위험한 상황이 생기면 그 위험이 다른 네트워크로 전이될 가능성이 있다”며 “워크로드 민감도 수준이 혼합돼 있을 경우 퍼블릭 서비스가 내부의 중요한 민감도 높은 컨테이너로 위험이 전가돼 중요 정보가 탈취당하는 문제가 생길 수 있다”고 지적했다.

이밖에도 오케스트레이터가 관리하는 클러스터 노드는 모두 신뢰성을 확보해야 한다.

컨테이너 리스크

컨테이너 리스크로는 런타임 소프트웨어(SW) 취약점, 제한없는 네트워크 접근, 안전하지 않은 컨테이너 런타임 구성, 애플리케이션 취약점, 불량 컨테이너 등을 들 수 있다.

런타임 SW 취약점 발생하면 그 위에서 동작하는 컨테이너 안전성을 보장하기 어렵다. 악의적인 SW가 다른 컨테이너, 호스트OS 리소스를 공격할 수 있다. 공격자가 권한을 탈취하거나 런타임 자체를 손상시켜 다른 컨테이너에 접근하거나 컨테이너 간 통신을 모니터링할 수 있는 위험성이 존재한다.

컨테이너가 제한없이 네트워크에 접속할 수 있는 경우 컨테이너 손상돼 악의적으로 작동하게 되면 다른 취약점을 찾기 위해 연결된 모든 네트워크를 검색할 수 있게 된다. 따라서 컨테이너 네트워크 접속 정책과 전용 도구를 이용해 감시가 필요하다.

불량(Rouge) 컨테이너는 계획 또는 승인되지 않은 컨테이너를 말한다. 개발자가 코드 테스트를 하는 동안 인가되지 않은 컨테이너가 생길 수 있다. 만약 이런 컨테이너가 유출될 경우보안 문제로 작용할 수 있기 때문에 데브옵스(DevOps)팀과 보안관리자들이 엄격히 관리해야 한다.

호스트OS 리스크

운영 중인 모든 호스트OS는 공격 대상이 되기 십상이기 때문에 악용될만한 취약점을 최소화해 공격 범위를 줄여야 한다. 만일 구성요소에 취약점이 존재할 경우 호스트OS상에서 실행되는 모든 컨테이너에 영향을 줄 수 있다. 또한 불필요한 서비스와 계정을 제거하지 않은 채 방치한다면 이 역시 공격에 이용될 수 있다.

컨테이너는 프로세스가 격리되는 구조이지만, 공유 커널을 사용하게 되면 컨테이너 특화 OS의 경우에도 하이퍼바이저보다 공격 범위가 커질 수 있어 주의해야 한다.

조 매니저는 “호스트OS 리스크 관리 방법은 서버 보안과 유사하다”며 “일반적으로 서버는 계정을 통해 사용자가 접근해 작업하지만 컨테이너에서 사용되는 워크노드는 아주 특별한 경우가 아니면 서버에 계정을 만들어서 접근해 작업하면 안된다. 이런 상황이 생기면 오케스트레이터가 배포한 컨테이너가 변하고 이로 인해 탈취가 가능해진다”고 지적했다.

이밖에도 적절할 사용자 접근권한 관리가 미흡하거나 컨테이너·런타임 취약점 관리 등을 통해 OS의 파일시스템이 변조될 경우 실행 중인 모든 컨테이너의 안정성과 보안에 영향을 미칠 수 있다.

컨테이너 환경을 보안위협으로부터 안전하게 유지하기 위해서는 계획을 수립부터 설계, 구축, 운영 및 유지관리, 폐기까지 전체 컨테이너 기술 수명주기 전반에서 보안을 고려해야 한다. 예를 들어 컨테이너 도입시 우선적으로 기존에 조직이 운영하고 있는 보안 정책을 변화되는 환경에 맞춰 조정해야 한다.

조 매니저는 “컨테이너를 도입하는 많은 기업들은 대개 보안을 운영, 유지관리 단계에서 솔루션을 도입하려는 경우가 많다”라면서 “이 경우 컨테이너 취약점을 해결하기 위해 많은 비용이 들고, 조직 간 협업도 안돼 취약점이 존재한 상태로 운영하는 것을 볼 수 있다. 컨테이너 도입을 고려하는 기업들은 각 단계에서 원칙적으로 보안을 처리하는 모델을 도입할 필요가 있다”고 강조했다.

베스핀글로벌 컨테이너 환경의 5가지 주요 리스크를 해소하기 위해 데브스섹옵스(DevSecOps)의 연속된 파이프라인 상에서 보안을 구현할 수 있도록 하는 동시에 현재 기업이 운영 중인 보안 거버넌스상에서 개발(Build), 구축(Deploy), 구동(Run) 단계별로 개발·운영·보안 조직들이 각각 어떠한 역할과 방어 행위를 해야하는지를 정의해놓은 도구와 보안 솔루션을 제시하고 있다.

글. 바이라인네트워크
<이유지 기자>yjlee@byline.network