과거 대부분의 기업용 애플리케이션은 하나의 거대한 서비스 형태(모놀리식 아키텍처, Monolithic Architecture)로 개발됐습니다. 모놀리식 아키텍처는 개발·관리가 용이하다는 장점이 있지만,시스템 규모가 커질수록 복잡도가 증가하는데요. 이에 따라 코드의 이해와 분석이 어려워지고 작은 수정사항에도 시스템 전체를 다시 개발(build)하고, 배포해야하는 비효율이 발생해 시스템의 개선과 확장이 어렵다는 단점이 존재합니다.
이러한 단점을 극복하기 위해 등장한 개념이 마이크로서비스 아키텍처(MSA, Microservices Architecture)입니다. 경량화되고 독립적인 여러 개의 서비스를 조합해 애플리케이션을 구현하는 방식인데요. 서비스마다 자체 데이터베이스를 가지고 동작하기 때문에 개발부터 빌드·배포까지 효율적으로 수행할 수 있습니다.기업 입장에서는 개발과 유지관리에 드는 시간과 비용을 줄일 수 있어 MSA로의 전환이 대세가 되고 있습니다.
국내업계는 MSA 도입과 전환에 대해 2013년부터 검토를 시작했습니다. 쿠팡, 배달의민족, 11번가 등 스타트업이 선도적으로 MSA를 채택했습니다. 트래픽 증가에 따라 데이터베이스, 서버를 증설해야하는 기존 모놀리식 구조의 한계를 극복하고 MSA로의 전환을 완료했는데요. 이들 기업은 MSA 이후 개발단계의 속도뿐만 아니라 주문 결제 서비스 대고객 응답 속도 개선이 이뤄졌다고 스스로 평가하고 있습니다.
오늘의 주제는 컨테이너의 보안위협과 대응방안인데 왜 마이크로서비스로 이야기를 시작했을까요?
마이크로서비스를 가장 잘 구현할 수 있는 형태의 플랫폼이 컨테이너 방식이기 때문입니다. 국내외 기업이 점차 더 많은 서비스를 MSA 방식으로 개발하는 흐름 속에서 이를 뒷받침하는 기반 기술로서 컨테이너 플랫폼 선택 또한 자연스럽게 증가하고 있습니다.
지금부터 도커(Docker), 쿠버네티스(Kubernetes)로 구체화된 컨테이너 플랫폼의 개념을 간략하게 소개하고, 컨테이너의 보안 위협과 대응 방안에 관해 살펴보겠습니다.
컨테이너, 도커, 쿠버네티스
서버가상화 기술은 하이퍼바이저(Hypervisro)를 활용한 가상머신에서 게스트운영체제(OS)없이 바이러니(Bin)/라이브러리(Lib)와 애플리케이션으로 구성된 컨테이너로 발전하고 있습니다.
기존의 가상머신(VM, Virtue Machine) 서버는 물리적인 서버 위에 하이퍼바이저,그 위에 각각의 게스트 OS가 설치된 VM을 구동하는 형태입니다. 가상머신은 하이퍼바이저에 의해 서버 내 CPU, 메모리, 디스크, 네트워크 등의 자원을 분할공유해 사용합니다.
컨테이너형 서버는 물리적인 서버 위에 서버운영체제(OS), 그 위에 도커 엔진 또는 컨테이너 런타임이 설치되며,그 위에 여러 개의 컨테이너가 동작하는 형태입니다. CPU, 메모리, 디스크, 네트워크와 같은 운영체제의 자원을 필요한 만큼 격리해 컨테이너에 할당하는 형태인데요. 여기서 컨테이너란 일종의 격리된 공간으로서, 별도의 게스트OS 없이 런타임과 바이너리, 데이터만으로 애플리케이션이 구동되는 환경을 가리킵니다.
서두에 언급한 마이크로서비스 아키텍처는, 이와 같은 컨테이너 방식의 플랫폼을 활용해 거대한 애플리케이션을 기능별로 쪼개고, 개별 컨테이너에 경량화된 단위 서비스를 배포합니다. 또한, 컨테이너별 변경 사항이 다른 서비스에 영향 미치지 않아서, 전체 서비스를 하면서도 독립적으로 구성할 수 있습니다.
도커는 리눅스 진영의 오픈소스 프로젝트로, 컨테이너 개념을 구체화한 도구입니다. 쿠버네티스는 엔터프라이즈 버전의 컨테이너 및 도커를 관리하는 도구입니다. 부연 설명하면, 실행 이미지를 컨테이너에 띄우고 실행하는 기술이 ‘도커’이고, 이러한 도커를 기반으로 복잡한 컨테이너들을 관리하는 서비스가 ‘쿠버네티스’입니다.
쿠버네티스는 △컨테이너의 생성과 소멸 △시작 및 중단 시점 제어 △스케줄링 △로드 밸런싱, △클러스터링 등 컨테이너로 애플리케이션을 구성하는 모든 과정을 관리하는 컨테이너의 오케스트레이션 도구입니다.
- 마스터(MASTER): 쿠버네티스 노드를 제어하는 머신. 모든 태스크 할당을 시작함
- 노드(NODE): 할당된 태스크를 요청대로 수행하는 시스템
- 포드(POD): 단일 노드에 배포된 하나 이상의 컨테이너 그룹. 포드에 있는 모든 컨테이너는 IP 주소, IPC, 호스트 이름, 기타 리소스를 공유하며 포드는 기본 컨테이너에서 네트워크와 스토리지를 추상화
- 서비스: 포드에서 작업 정의를 분리함. 쿠버네티스 서비스 프록시는 클러스터에서 다른 위치로 이동한 경우든 교체된 경우든 서비스 요청을 적절한 포드로 자동 수신함
- 큐블렛(Kubelet): 이 서비스는 노드에서 실행되며 컨테이너 매니페스트를 읽고, 정의된 컨테이너가 시작되어 실행 중인지 확인
- 큐벡틀(kubectl): 쿠버네티스의 명령줄 설정 툴
(출처: 쿠버네티스(Kubernetes)란? 개념, 성능, 사용 방법 및 차이점, 레드헷)
지금부터는 컨테이너 플랫폼에 대한 보안 위협이 어떤 것들이 있는지 살펴보겠습니다.
컨테이너 보안위협과 선제적 대응방안 5가지
최근 컨테이너 이미지를 비롯해 컨테이너 구성 요소별 취약점이 증가하고 있다는 경고가 잇달아 공개되고 있습니다. 컨테이너 플랫폼의 주요 구성요소인 △이미지 △레지스트리 △ 오케스트레이터 △컨테이너 △호스트 운영체제(OS) 등에 대한 보안 위협과 대응 방안을 하나씩 살펴보겠습니다.
1)첫째, 컨테이너 이미지에 대한 보안 위협은 이미지 자체의 취약점, 구성의 결함, 악성코드 삽입 등으로 발생할 수 있습니다. 컨테이너 이미지는 애플리케이션을 실행하는데 필요한 모든 구성요소가 포함된 정적 파일(파일의 내용이 변경되지 않는 속성을 갖는 파일)로, 보안 업데이트가 누락됐거나 지원되지 않은 구성요소가 있을 때 취약점이 발생할 수 있습니다. 만일 취약점이 존재하는 상태로 배포될 경우 위험은 커질 수밖에 없습니다.
이미지 취약점이 없더라도 구성이 올바로 이뤄지지 않으면 공격에 노출될 수 있습니다. 불필요한 계정을 갖고 있거나 불필요하게 네트워크에 노출되는 서비스가 있을 때도 구성상의 결함이 발생할 수 있습니다. 패키징된 파일 가운데 악성코드가 포함될 경우도 매우 위험합니다. 배포 환경 내 다른 컨테이너나 호스트를 공격할 수 있기 때문에, 이를 예방하기 위해서는 안전성을 검증이 반드시 선행돼야 합니다.
2)둘째, 레지스트리에 대한 보안 위협입니다.컨테이너의 이미지를 저장하고 배포하는 역할을 레지스트리가 수행합니다. 이미지 취약점이 해결됐다고 하더라도 레지스트리에 연결하는 시스템에 대한 접근통제가 취약하면 전체적인 보안이 위험해질 수 있습니다. 따라서, 반드시 레지스트리에 연결하는 채널을 접근통제 정책에 따라 운영하고 통신 암호화를 적용해야 합니다.
레지스트리에는 중요 데이터에 접근하거나 특정 권한이 필요한 이미지가 포함돼 있습니다. 그렇기 때문에 사용자 인증·권한 부여 요구사항이나 절차가 미흡할 경우 위협으로 작용할 수도 있습니다. 만일 불충분한 인증·권한 관리로 인해 악의적으로 레지스트리 내 보관된 이미지가 변경될 경우, 시스템에 영향을 미칠 수 있습니다.
3)셋째, 오케스트레이터는 컨테이너 환경의 전(全) 과정을 제어·관리하는 역할을 수행합니다.그렇기 때문에 사용자 계정 및 권한관리가 매우 중요한데요. 무단 접근이 허용되는 경우, 자칫 동일한 오케스트레이터가 관리하는 다른 컨테이너의 작동에 영향을 주거나 다른 사용자가 배포한 컨테이너 정책을 바꾸는 등의 악의적인 행위에 노출될 수 있습니다. 따라서, 무단 접근을 막을 수 있도록 원칙적으로 조직 내부 디렉터리 서비스와 연계하는 방식 등을 채택해 계정 운영관리를 강화하는 방안을 고려해야 합니다.
잘못된 컨테이너 네트워크 분리, 그리고 서로 다른 수준의 민감도를 가진 워크로드의 혼합으로 인한 보안 위협도 존재합니다. 즉, 워크로드 민감도 수준이 혼합돼 있을 경우 퍼블릭 서비스가 내부의 중요도 높은 컨테이너로 위험이 전가돼 중요 정보가 탈취당하는 문제가 생길 수 있습니다. 컨테이너 환경은 암호화된 오버레이 네트워크로 인해 기존 네트워크 관리 도구로 모니터링조차 할 수 없습니다.
넷째, 런타임 소프트웨어의 취약점, 제한 없는 네트워크 접근, 안전하지 않은 컨테이너 런타임 구성, 애플리케이션 취약점, 불량 컨테이너 등의 컨테이너 자체 보안 위협입니다.
런타임 소프트웨어 취약점이 발생하면 그 위에서 동작하는 컨테이너 안전성을 보장하기 어렵습니다. 악의적인 소프트웨어가 다른 컨테이너, 호스트운영체제(OS) 리소스를 공격할 수 있는데요.공격자가 권한을 탈취하거나 런타임 자체를 손상시켜 다른 컨테이너에 접근하거나, 컨테이너 간 통신을 모니터링할 수 있습니다.
컨테이너가 제한 없이 네트워크에 접속할 수 있는 경우, 다른 취약점을 찾기 위해 연결된 모든 네트워크를 검색할 수 있게 됩니다. 그렇기 때문에 컨테이너의 네트워크 접근 정책과 전용 도구를 이용해 모니터링이 필요합니다.
개발자가 코드 테스트를 하는 동안 계획 또는 승인되지 않은, 즉 인가되지 않은 불량 컨테이너 가 생길 수 있습니다. 불량 컨테이너 오픈을 예방하기 위해서는 데브옵스(DevOps)팀과 보안관리자들이 엄격한 절차적 보안관리를 수행해야 합니다. 데브옵스(DevOps)는 개발(Development)과 운영(Operation)을 합친 개념입니다.
5) 다섯번째, 호스트OS에 대한 보안 위협입니다.컨테이너는 프로세스가 격리되는 구조이지만, 호스트OS의 공유 커널을 사용하게 되면 하이퍼바이저보다 공격 범위가 커질 수 있으므로, 호스트OS상의 취약점은 실행되는 모든 컨테이너에 영향을 줄 수 있습니다. 불필요한 서비스와 계정의 제거 등 호스트OS 취약점을 제거해야 합니다.
맺음말
컨테이너 환경을 보안 위협으로부터 안전하게 유지하기 위해서는 컨테이너 도입 계획 수립부터 설계, 구축, 운영 및 유지관리, 폐기까지 전체 컨테이너 기술의 수명주기 전반에서 보안을 고려해야 합니다. 또한, 데브섹옵스(DevSecOps)의 연속된 형태로 보안을 구현할 수 있도록 하는 개발(Build), 구축(Deploy), 구동(Run) 단계별로 개발·운영·보안을 담당하는 조직의 역할과 수행 활동(Activity)을 사전에 세부적으로 구체화해야 합니다. 데브섹옵스(DevSecOps)는 데브옵스(DevOps)와 보안(Security)이 결합된 개념입니다. DevOps의 IT 개발부터 배포, 운영, 관리에 이르기까지 전 영역이 보안과 연계된 것을 의미합니다.
컨테이너 환경의 모든 참여자는 이미지를 생성하거나 사용할 때 반드시 이미지 취약점 검사를 수행하고, 사용자별 역할에 따른 권한 기반으로 작업을 허용하며, 익명 요청과 안전하지 않은 토큰 사용을 방지해야 합니다. 또한, https 통신 적용 등 쿠버네티스 및 도커에 대한 보안 설정이 적정한지 검사하고, 이미 보안이 강화된 런타임을 채택하거나 보안옵션을 통해 런타임 보안을 강화해야 하죠. 로그 기록을 정기적으로 확인 감독해 오류 및 부정행위가 발생하거나 예상되는 경우, 즉각적인 확인, 조치가 가능하게 함으로써 보다 안전하게 컨테이너 플랫폼을 사용할 수 있도록 해야 합니다.
| [참고] 애플리케이션 컨테이너 보안 가이드(Application Container Security Guide), NIST Special Publication 800-190, 2019 조현익, ‘컨테이너 보안, 5가지 리스크를 주의하라’ 베스핀글로벌 클라우드 네이티브 보안 웨비나, 2020 |
글 ㅣ LG CNS 사이버시큐리티팀 전경화 책임
