How To : 컨테이너 보안을 개선하는 방법

CSO
가트너가 컨테이너 보안(container security)을 올해 가장 우려되는 10가지 요소 가운데 하나로 지정했다. 그만큼 주의를 기울이고 견실한 보안 구현 계획을 마련하는 것이 좋다는 의미다. 컨테이너는 약 10년 전에 처음 등장했지만 가벼움과 재사용 가능한 코드, 유연한 기능, 낮은 개발 비용 등의 장점에 힘입어 갈수록 인기를 얻고 있다. 이번 기사에서는 데브옵스/빌드 환경을 보호하는 데 필요한 툴, 컨테이너 자체를 위한 툴, 그리고 모니터링/감사/규정 준수를 위한 툴을 살펴볼 것이다. 물론 어느 한 가지 툴로 모든 작업을 할 수는 없다.


기본적인 단계부터 시작하자

1. 클라우드 업체가 제공하는 툴 확인
첫 번째 단계는 현재 사용 중인 클라우드 업체가 제공하는 기본 보안 툴에 대해 알아보는 것이다. 애저 보안 센터(Azure Security Center), 구글 쿠버네티스 엔진(Google Kubernetes Engine), 구글 클라우드 보안 커맨드 센터(Google Cloud Security Command Center), 아마존 인스펙터(Amazon Inspector) 등이 포함된다. 애저 보안 센터와 같은 일부 보안 툴은 컨테이너 전용이 아닌 범용 보안 툴이다.

2. 네이티브 도커 관련 보안 기능 익히기
여기에는 리소스 오남용 방지를 위한 정책을 사용하고 액세스 제어 그룹을 설정하고 불필요한 루트 액세스 권한을 제거하는 작업이 포함된다.

3. 깃허브 오픈소스 프로젝트 
코드에서 보안 모범 사례를 확인하는 벤치 시큐리티(Bench Security)와 같은 프로젝트, 그리고 seccomp(secure computing mode)와 같은 리눅스 네이티브 툴은 저렴한 비용으로 이용할 수 있다. 다른 오픈소스 툴에 대해서는 후설할 것이다.

알고 익혀야 할 소프트웨어가 많아서 부담이 되겠지만 특히 관심을 기울여야 할 몇 가지 공통적인 기능이 있다. 사용자와 최종적으로 빌드하려는 앱, 두 가지 모두에 대한 ID 및 인증, 그리고 이 액세스 권한을 제어하는 방법도 여기에 포함된다. 또한 로그 파일을 점검, 감사하고 필터링해서 보안을 위한 조치 가능한 정보를 제공할 수 있어야 한다. 마지막으로, API 키 및 SSL 인증서와 같은 비밀을 보호하기 위한 기반 인프라가 있다. 이러한 비밀은 암호화된 형식으로 저장해야 한다.

아직 겁먹기는 이르다. 이제 시작일 분이다. 컨테이너를 보호하기 위해 필요한 세 가지 영역을 살펴보자.

1. 빌드 환경 보호
컨테이너는 개발자에게 매우 유용하다. 따라서 프로젝트가 완전히 코딩된 이후까지 기다리기보다는 데브섹옵스(DevSecOps) 영역에서 컨테이너를 만드는 시점에 보안 기능을 추가하는 것이 좋다. 이것이 항상 앱을 보호하기 위한 최선의 방편이다. 적절한 보안 툴을 선택하기 전에 다음과 같은 세 가지 중요한 질문에 대한 답을 구하라.

- 앱을 안전하게 보호하기 위해 자동화할 수 있는 워크플로우는 무엇인가? 일부 툴은 특히 오케스트레이션과 관련해 이 부분에서 도움이 된다. 그러나 오케스트레이션 툴의 상당수는 컨테이너 관리와 확장 문제에 초점을 두므로 세부적인 보안 기능이 부족할 수 있다. 유용성과 실질적인 보호 기능 사이에서 적절한 균형을 찾기가 어려운 경우도 있다.

- 앱과 사용자를 위한 액세스 제어에서 얼만큼의 세분화가 필요한가? 이런 제어 수단이 어떻게 적용되며 제한은 무엇인지 잘 아는 것이 좋다. 예를 들어 어느 코드 부분과 컨테이너에 루트/커널 액세스 권한이 있는지, 각기 작업을 수행하기 위해 그 정도 수준의 액세스 권한이 필요한지 여부 등을 항상 확인해야 한다.

- RASP(Runtime Application Self-Protection) 기술을 사용해야 하는가? 한 마디로 답하자면 그렇다. 앱에 초점을 두는 일반적인 RASP 지향 툴과 마찬가지로, 정적 스캔 또는 현재 개발 환경을 사용한 지속적 통합을 통해 컨테이너 런타임 애플리케이션 보호에 특화된 툴이 있다. 컨테이너 코드는 계속 바뀌고, 지속적인 코드 감사는 패치나 업데이트가 필요할 때 시간을 절약할 수 있게 해주므로 후자의 형태가 유용하다. 우수한 RASP 컨테이너 툴은 비정상적인 동작을 찾고 잠재적 위협을 수정하고 부가적인 포렌식 분석을 위해 특이한 이벤트를 격리할 수 있어야 한다.

2. 컨테이너가 위치하는 호스트 보호
컨테이너가 위치하는 호스트 보호는 대체로 잠재적 공격 표면을 줄이기 위해 불필요한 부분을 모두 빼고 가능한 최소의 서비스만 실행하는 리눅스 버전을 실행하는 것을 의미한다. 일부 툴은 호스트 자체를 강화한다. 다른 방법은 앞서 언급한 도커 제어 그룹을 사용하면서 보안 정책을 반영하고 컨테이너의 상호 감염을 차단하기 위해 네임스페이스를 격리하는 것이다. 일부 기업은 클라우드 제공업체의 가상 사설망을 사용해 격리한다. 액세스 수준을 비롯한 기타 메커니즘을 사용해 워크로드를 분리하고 호스트당 실행되는 컨테이너의 수를 제한하는 방법도 사용된다. 일부 기업은 이 같은 이유로 호스트당 하나의 컨테이너만 실행한다.

3. 컨테이너의 내용물 보호
소프트웨어 공급망 이미지를 보자. 각각 컨테이너를 구성하는 요소이므로 기본적인 기능 중 하나는 이미지 소스 무결성 보호다. 즉, 직원 중에서(또는 그 컨테이너의 출처인 오픈소스 프로젝트를 통해) 누군가 이미지를 변경하면 무엇이 변경되었는지를 알 수 있어야 한다.

인터넷에서 많은 컨테이너가 공유된다는 점을 감안하면 유용한 기능이다. 이와 관련된 기능은 이미지를 스캔해 감염 여부를 확인하는 기능이다. 이 작업을 얼마나 자주 하며, 스캔을 자동화할 수 있는가? 신뢰할 수 있는 소스에서 이미지를 얻는 것도 유용하지만 누구나 실수를 하고 의도치 않게 보안 문제를 유발할 수 있다.

일부 기업에서는 컨테이너에 어떤 취약점이 있는지 신경쓰지 않는 경우도 있다. 놀랍게 들릴 수 있지만 그럴 만한 근거는 있다. 단, 한 가지 주의 사항이 있다. 컨테이너 경계를 충분히 보호하는 경우, 또는 실제 앱 코드가 컨테이너 코드의 이러한 부분을 건드리지 않는 경우에만 가능하다는 것이다. 얼마나 많은 취약점을 용인할 수 있느냐를 결정하는 궁극적인 요소는 보안 툴에 대해 얼마큼 확신을 갖고 있느냐다.


일반적인 컨테이너 보안 제품

보안 요구 사항을 정리했다면 이제 일반적으로 사용되는 제품을 살펴 볼 차례다. 여기서 기본적으로 결정해야 할 점은 오픈소스를 사용할 수 있는 범위다. 즉 상용 제품을 구입하기 위한 예산이 얼만큼인지가 중요하다.

툴을 찾기 위한 프로세스를 처음 시작한다면 Sysdig가 좋다. 런타임 코드에서 특이한 행동 감사, 포렌식 분석 및 취약점 점검과 같은 일반적인 보안 사용 사례를 단계별로 다루는 자습서가 충실하게 제공된다(교육 과정 소프트웨어를 모듈로 사용). Sysdig는 오픈소스 RASP 툴 팔코(Falco)와 상용 툴인 모니터(Monitor) 및 시큐어(Secure)도 제공한다. 후자는 이미지 스캔과 취약점 모니터링에 사용된다. 주요 오픈소스 툴에는 다음과 같은 것이 포함된다.

- 앵커(Anchore): 취약점 분석과 이미지 스캔
- 앱아머(Apparmor): RASP 기능용
- 실리엄(Cilium): 네트워크 및 HTTP 계층 보안
- 코어오에스 클레어(CoreOs Clair): 정적 코드 분석
- 다그다(Dagda): 취약점 정적 분석과 모니터링
- 소스랩스(Saucelabs): 무료 라이브 및 자동 코드 테스트 기능 제공

주요 상용 업체는 다음과 같다.
- 얼럿로직(Alertlogic): 컨테이너 ID 및 로그 분석 관리
- 아쿠아섹(AquaSec): RASP, 감사, 이미지 스캔 및 컨테이너 IDS
- 플로체크(Flawcheck): 테너블(Tenable)에서 인수해서 네서스(Nessus) 보안 전문 기술을 활용하는 컨테이너 이미지 스캐너에 통합함
- 트위스트록(Twistlock): RASP 및 부가적인 머신 러닝 보호
- 스렛스택(Threatstack): 클라우드 시큐리티 플랫폼(Cloud Security Platform)에 속하는 취약성 모니터링 툴 제공

마지막으로, 비용에 대해 알아 둘 점이 있다. 대부분의 업체는 제한된 평가판(짧게는 1주일부터 길게는 몇 개월까지)을 제공하므로 구매 전에 테스트해볼 수 있다. 평가용 툴의 경우 대부분 잠재 고객을 관리하기 위한 등록 페이지가 있다. 툴 비용은 API 호출 또는 기타 사용 지표에 따라 청구되므로 대부분 복잡한 가격 모델을 두고 있고, 웹사이트에는 가격이 나와 있지 않다.

예를 들어 Sysdig의 가격 페이지에는 별다른 정보가 없다. 필자가 알아본 바로는 가격은 연 단위 요금제를 기준으로 호스트당 월 30달러부터 시작하며, 대량 구매에 따른 할인이 적용된다. 컨테이너 보호의 가격을 산정하는 데 어려운 부분 중 하나는 컨테이너 인프라의 전체적인 범위를 본인도 모를 수 있다는 점이다. 또한 빠른 변화 속도로 인해 전체적인 비용을 추정하는 것 자체가 불가능할 수도 있다. 따라서 상용 제품에 발을 들여놓기 전에 오픈소스로 시작하는 것이 좋다. editor@itworld.co.kr