가상화ㆍ컨테이너 / 개발자 / 보안 / 클라우드

컨테이너와 마이크로서비스 보안이 어려운 이유

Maria Korolov  | CSO 2018.05.10
컨테이너(Containers)는 다양한 컴퓨팅 환경에 소프트웨어를 배포하고 실행하기 위한 방법으로, 작고 빠르며 설정하기도 쉽다. 라이브러리, 바이너리, 구성 파일을 포함한 애플리케이션의 전체 런타임 환경을 보존하므로 플랫폼과 인프라가 추상화되고 따라서 거의 모든 곳에서 애플리케이션을 실행할 수 있다. 컨테이너는 모든 주요 클라우드 제공업체를 통해, 또는 온프레미스 데이터센터와 하이브리드 클라우드에서도 사용할 수 있다. 또한 컨테이너를 통해 기업은 많은 비용을 절감할 수 있다.

개발자는 컨테이너를 사용해 "마이크로서비스(microservices)"를 만든다. 기본적으로 마이크로서비스는 작고 재사용 가능한 애플리케이션 구성 요소다. 재사용이 가능하므로 개발자 시간이 절약되며 다양한 플랫폼에 배포할 수 있다.

이렇게 보면 컨테이너 도입률이 높은 것은 당연하다. 그러나 보안 측면에서 컨테이너의 작동 방식과 최선의 보호 방법은 여전히 연구 단계다. 최근 1,500명의 글로벌 IT 전문가를 대상으로 한 맥아피 설문에 따르면, 직원 수 500명 이상 조직의 약 80%가 컨테이너를 사용 중이다. 이 가운데에서 컨테이너 보안 전략을 둔 비율은 66%에 불과하다. 사실 지난 3월 1,200명의 IT 의사 결정자를 대상으로 실시된 사이버에지(CyberEdge)의 설문에 따르면, 컨테이너는 현재 모바일 기기와 함께 조직의 가장 큰 보안 과제로 꼽힌다.

컨테이너 환경에서 보안이 어려운 이유는 여러 가지다. 그 가운데 하나는 컨테이너가 배포되는 속도다. 또 다른 이유는 일반적으로 애플리케이션을 더 작은 서비스로 분할해야 하므로 데이터 트래픽이 증가하고 액세스 제어 규칙이 복잡해진다는 점이다. 마지막으로, 컨테이너는 아마존과 같이 새로운 종류의 보안 통제가 적용되는 클라우드 기반 환경에서 실행되는 경우가 많다.

클라우드 보안 업체 스택록스(StackRox)의 공동 창업자이자 CTO인 알리 골샨은 컨테이너 보안 툴 생태계가 아직 성숙하지 않은 상태라며 "가상 머신과 클라우드의 초창기와 같다. 조직에서 자체 소유 툴과 인프라를 구축해야 하고, 구현을 위해 많은 리소스가 필요하다. 즉시 사용 가능한 솔루션이 아직 많지 않고 모든 사용 사례를 포괄하는 솔루션도 부족하다"고 말했다.

컨테이너, 부실하게 관리되고 수명도 짧아
컨테이너 시대가 도래하면서 전통적인 소프트웨어 개발 프로세스(빌드, 테스트, 배포)는 빠른 속도로 쇠퇴하고 있다. 실제로 개발자들은 공용 리포지토리에서 즉시 사용 가능한 이미지를 가져다가 클라우드에 던져 넣는 경우가 많다.

이스트윈드 네트웍스(Eastwind Networks)의 최고 보안 및 전략 책임자인 로버트 후버는 "보장 여부가 확실치 않은, 일종의 암시적인 신뢰를 바탕으로 한다"고 말했다. 컨테이너 이미지는 즉시 사용 가능한 편리한 코드 패키지다. 그러나 해당 이미지의 공급자는 보안 문제를 모니터링하거나 릴리스 노트를 게시할 만한 시간이 없거나 아예 그 분야에 관심이 없을 수도 있다.

후버는 "이상적으로는 버전 확인 프로세스를 두는 방법이 있지만 실제로 두는 조직을 본 적이 없다"면서, "기업은 컨테이너의 최신 버전을 사용하고 있는지, 모든 코드가 패치되고 최신 상태인지 여부를 지속적으로 확인해야 한다 그러나 지금은 그 역할을 개발자가 하고 있으며 과정도 수동이다. 향후 더 자동화된 프로세스로 옮겨가겠지만 지금은 간극이 있다. 컨테이너를 가져와서 실행하면 그 이후는 신경쓰지 않는다"고 말했다.

개발자가 스스로 컨테이너를 구축하더라도 별반 나은 점은 없다. 개발 속도 문제로 인해 품질 보증 또는 보안 테스트를 할 시간이 없기 때문이다. 컨테이너가 있다는 것을 인식할 시점이면 개발자는 이미 일을 마치고 떠난 뒤다.

쿠델스키 시큐리티(Kudelski Security)의 솔루션 아키텍처 책임자인 보 레인은 "보안 팀이 개입하기도 전에 라이프사이클이 끝날 수 있다. 그게 어려운 점이며 보안 측면에서 기존과 다른 사고방식이 필요한 부분이다"고 말했다.

레인은 개발 프로세스의 초기에 보안 인식을 심어야 하며 최대한 자동화해야 한다고 말했다. 예를 들어 개발자가 외부 소스에서 이미지를 다운로드하는 경우 컨테이너를 라이브로 가동하기 전에 이 이미지에서 취약점, 패치되지 않은 코드 및 기타 잠재적 문제를 검사해야 한다. 레인은 "컨테이너가 라이브가 된 후, 아마도 아주 짧은 수명 동안 사용되면서 다른 구성 요소와 상호 작용할 그 컨테이너의 보안 상태를 어떻게 유지하고 모니터링할 것인가?"라고 물었다.

예를 들어 클라우드 보안 업체인 스카이하이 네트웍스(Skyhigh Networks)의 경우를 보자. 이 회사의 공동 창업자이자, 올해 초 스카이하이를 인수한 맥아피 클라우드의 엔지니어링 부사장인 세카르 사루카이는 스카이하이 네트웍스는 자체 클라우드 서비스가 있으므로 이런 모든 과제에 대처해야 한다고 말했다.

사루카이는 "최신 아키텍처 스택을 배포하고 마이크로서비스도 있다. 사실 하루에도 여러 번 프로덕션으로 배포할 수 있다. 전통적으로는 보안 테스트나 침투 테스트를 해야 하지만 데브옵스 환경에서는 그렇게 할 수 없다"고 말했다.

사루카이는 기업에서 이런 기능의 상당수를 자동화할 방법을 찾아야 한다고 말했다. 즉, 배포되는 모든 컨테이너를 파악하고 컨테이너의 모든 요소가 안전한지 확인하고 컨테이너가 애플리케이션 컨트롤 또는 애플리케이션 화이트리스트를 사용하는 안전한 환경에 배포되는지 확인한 다음 지속적으로 모니터링해야 한다.

맥아피가 지난 4월 RSA 컨퍼런스에서 발표한 맥아피 클라우드 워크로드 시큐리티(McAfee Cloud Workload Security) 플랫폼이 바로 이런 기능을 수행한다. 사루카이는 "이 제품은 퍼블릭 및 프라이빗 클라우드 환경의 도커 컨테이너와 컨테이너의 워크로드를 보호한다"고 말했다. 환경에는 AWS, 애저, VM웨어가 포함된다. 사루카이는 "감염된 워크로드와 컨테이너를 격리할 수 있는 최초의 클라우드 워크로드 솔루션"이라고 말했다.

이 제품은 예를 들어 불필요한 관리자 권한 또는 암호화 요구 사항 미충족, 공개 읽기 가능으로 설정된 AWS 버킷 등을 검사하는 기능을 통해 구성 관련 위험도 낮춘다. 사루카이는 "문제 교정 속도도 높여준다. 고객과 함께 수행한 연구 결과 최대 90%까지 개선되는 것으로 나타났다"고 말했다.

사루카이가 지금까지 본 컨테이너 보안 문제의 거의 대부분은 잘못된 구성이 원인이 되어 발생했다. 사루카이는 "가장 큰 위험이 도사리고 있는 부분"이라고 말했다.

방대한 서비스 웹
구성 관리와 패치 관리는 어렵고, 공격자가 이를 악용하기는 쉽다. 그러나 이것은 해결 가능한 문제다. 더 큰 난제는 애플리케이션을 상호 연결된 많은 수의 작은 서비스로 분할함으로써 발생하는 복잡성이다.

전통적인 모놀리식 애플리케이션에서는 서비스 하나와 포트 두 개가 전부다. 에그플랜트(Eggplant) CTO 안토니 에드워즈는 "공격자가 어디로 들어올지 정확히 알 수 있다"고 말했다.

따라서 보호하기도 쉽다. 에드워즈는 "그러나 마이크로서비스의 경우 서비스의 수가 많고 포트도 많으므로 보호해야 할 문이 훨씬 더 많다. 게다가 각각의 문이 제공하는 정보도 많지 않으므로 누군가 악의적으로 행동할 경우 이를 파악하기가 더 어렵다"고 말했다.

에드워즈는 따라서 최소 권한, 엄격한 액세스 제어, 격리 및 감사와 같은 원칙을 적용해 개별 서비스의 보안을 최대한 견고하게 해야 한다면서 "이러한 모든 요소는 1970년대부터 이미 있던 것들이다. 지금은 그걸 실천해야 할 뿐이다"고 말했다.

실천은 말보다 어렵다. 시프트레프트(ShiftLeft)의 공동 창업자이자 CEO인 매니시 굽타는 "조직은 모놀리식을 더 작은 조각으로 분할하고 있는데, 이 경우 애플리케이션 내의 데이터 흐름이 훨씬 더 복잡해져 각 마이크로서비스가 하는 작업이 무엇인지 알기가 어려워진다"고 말했다.

여기에 하드 코딩된 액세스 자격 증명 또는 유출된 인증 토큰이 흘러들 경우 전체 시스템이 취약해진다. 굽타는 "아주 큰 문제이지만 사람들이 그 심각성을 아직 인식하지 못하고 있다"고 말했다.

굽타는 더 많은 핵심 시스템이 소프트웨어 서비스 제공 모델로 옮겨갈수록 문제는 더 커진다면서 "많은 앱 데이터가 한 곳에 집중된다는 것을 의미한다. 에퀴팩스(Equfax), 우버(Uber)가 좋은 사례다. 민감하고 중요한 데이터가 마이크로서비스 사이를 오가는데, 이에 대한 명확한 시야를 확보한 경우는 극소수다"고 말했다.

구멍 난 컨테이너로 인한 취약점
컨테이너에는 또 다른 잠재적 보안 문제도 있다. 컨테이너는 공유 환경에서 실행되는데 특히 고객이 이웃을 모르는 퍼블릭 클라우드에서 이에 대한 우려가 크다. 실제로 지난 2년 동안 도커와 쿠버네티스 컨테이너 관리 시스템의 취약점이 드러났다.

퍼블릭 클라우드에서 컨테이너를 실행하는 기업들은 이 문제를 인지하기 시작했다. 레드햇의 컨테이너 플랫폼 오픈시프트(OpenShift)의 수석 제품 관리자인 커스텐 뉴커머는 "대부분의 고객은 컨테이너 이스케이프에서 호스트를 격리하고 컨테이너를 상호 격리하는 데 사용할 수 있는 툴이 무엇인지를 묻는다"고 전했다.

포트웍스(Portworx)의 2017년 컨테이너 도입 설문에 따르면, 응답자의 70% 이상은 리눅스에서 컨테이너를 실행한다. 뉴커머는 "컨테이너를 확실히 격리하려면 리눅스 네임스페이스와 보안 강화 리눅스(Security Enhanced Linux)를 사용해 부가적인 강제 액세스 제어 계층을 두는 방법이 있다"면서, "또한 리눅스 시스템 내에서 프로세스가 액세스할 수 있는 권한의 종류를 제한하는 리눅스 기능도 있다"고 말했다.

리눅스 보안 전문가에게는 익숙한 개념일 수 있지만 컨테이너 배포 팀 또는 최근 윈도우에서 이주해 온 조직에는 생소할 수 있다. 퍼블릭이든 프라이빗 클라우드에서든 적어도 자체 컨테이너 환경을 운영하는 기업은 이런 보안 설정에 대한 전체 통제 권한을 갖고 있다. 기성 컨테이너를 사용할 경우 클라우드 공급자가 기반 보안 인프라를 제대로 갖추기를 기대할 수밖에 없다.

컨테이너 취약점으로 인해 심각한 침해가 발생한 경우는 아직까지는 없다. 소수의 플랫폼(대표적인 이름은 도커, 쿠버네티스)이 이 영역을 지배한다는 사실은 공격자가 하나의 취약점을 신속하게 악용할 경우 그 영향이 광범위하게 미칠 수 있음을 의미한다. 따라서 미리 대비하는 것이 좋다. editor@itworld.co.kr  

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.