컨테이너 보안 기초: 파이프라인 보안

이 시리즈를 처음 접하신다면 첫 글부터 읽어 보세요:
컨테이너 보안 기초: 소개

애플리케이션 자본의 시대에 CI/CD 파이프라인은 애플리케이션을 빌드하고 제공하는 속도와 보안을 좌우하는 핵심 구성 요소입니다.

이는 API를 통해 통합되고 스크립트나 플러그인으로 호출되는 복잡한 도구 시스템으로, 컨테이너화된 애플리케이션을 구축하고 최종적으로 제공하기 위해 따르는 프로세스를 디지털 방식으로 구현합니다. 즉, 악의적인 공격자가 시스템을 침해할 수 있는 지점이 여러 곳에 존재한다는 뜻입니다. 다소 현실성 없는 이야기처럼 들릴 수 있지만, 오늘날 상당수의 조직이 클라우드를 활용하고 있으며, 이는 필연적으로 원격 액세스를 수반한다는 점을 기억해야 합니다.

즉, 파이프라인 보안에는 두 가지 측면이 있습니다. 첫째는 파이프라인 자체의 보안이고, 둘째는 파이프라인 내의 보안입니다.

파이프라인 자체의 보안

1. 인증은 선택 사항이 아닙니다
클라우드 또는 호스팅 서비스에서 파이프라인의 일부로 도구와 서비스를 사용한다면 공격에 노출될 수 있습니다. 원격 개발자나 운영 담당자가 내부에서 호스팅되는 도구와 서비스에 접근할 수 있도록 허용하는 경우에도 공격에 노출될 수 있습니다. 이러한 우려를 대수롭지 않게 여기기 전에, 시스템을 외부에 개방한 결과 지난 몇 년간 수많은 보안 침해가 발생했다는 사실을 잊지 말아야 합니다. 파이프라인 보안과 관련해서는 악의적인 공격자가 실제로 접근할 수 있다고 전제하는 것이 가장 안전합니다.

따라서 가장 먼저 해야 할 일은 접근을 보호하는 것입니다. 강력한 인증은 선택 사항이 아닙니다. 중요 시스템에 대한 접근 권한을 세밀하게 조정하려면 접근 제어를 사용하는 것이 좋습니다. 시스템이 내부에서만 접근 가능하다고 생각하더라도 마찬가지입니다. 악의적인 공격자는 네트워크의 다른 시스템을 통해 접근할 수 있습니다.

인증을 적용했다면 다음 단계는 권한 부여입니다. 권한 부여는 인증된 사용자가 시스템 내에서 수행할 수 있는 작업을 규정합니다. 중요 구성 요소에 접근할 수 있는 자격 증명은 적을수록 안전하므로 역할에 따라 권한을 구분하는 것이 중요합니다.

파이프라인의 모든 구성 요소에는 인증과 권한 부여가 필요합니다. 여기에는 리포지토리부터 애플리케이션과 컨테이너를 빌드하는 데 사용되는 도구까지 모두 포함됩니다.

2. 파이프라인 구성 요소 보호
안타깝게도 공격자가 공개 리포지토리를 스캔하여 방대한 양의 보물(자격 증명 및 기타 비밀 정보)을 발견했다는 소식은 드물지 않습니다. 리포지토리에 인증을 적용해야 한다는 점은 1번 항목을 참조하세요.

오늘날의 파이프라인은 여러 도구가 통합된 하나의 연쇄 구조이며, 각 도구에는 인증이 필요합니다. 이 때문에 자격 증명과 비밀 정보(키)가 파이프라인을 구성하는 도구와 서비스를 호출하는 스크립트에 저장되는 경우가 많습니다. 이는 매우 심각한 문제™이며, 특히 해당 스크립트가 저장될 수 있는 리포지토리의 인증 관행까지 허술하다면 더욱 그렇습니다.

자격 증명은 반드시 보호해야 하는 중요한 자산입니다. 자격 증명이 어디에 존재하고 어디에 저장되며 어떻게 보호되는지 파악해야 합니다. 무분별하게 분산된 비밀 정보를 관리하는 데 유용한 도구로는 HashiCorp Vault가 있습니다. Vault는 비밀 정보를 중앙 위치에 안전하게 저장합니다.

파이프라인 보안

3. 자재 명세서 유지
시스템 또는 시스템 구성 요소의 보안을 확보하려면 먼저 해당 요소가 존재한다는 사실을 알아야 합니다. 현재 환경에 무엇이 있는지 파악할 수 있도록 포괄적인 자재 명세서를 유지하는 것이 중요합니다. 더 나아가 환경에 무엇이 있어야 하는지 그리고 반대로 무엇이 있어서는 안 되는지 파악해야 합니다.

잘 관리된 인벤토리는 오염되거나 손상된 구성 요소를 파이프라인에 삽입하려는 시도를 방지하는 데 도움이 될 수 있습니다. 단일 기본 컨테이너 또는 최소한 관리 가능한 소수의 컨테이너로 표준화하면 잠재적인 문제를 탐지하는 능력을 크게 향상할 수 있습니다. 따라서 표준에서 벗어난 사항이 발견되면 조사할 수 있도록 경고가 발생해야 합니다. 예를 들어 해시를 비교하고, 가능한 경우 컨테이너 이미지의 디지털 서명을 검증하는 것은 중요한 단계입니다. 원격 리포지토리에서 이미지를 가져오는 경우 해당 리포지토리가 침해되었을 가능성이 있습니다.

실제로 DockerHub에서 침해 사고가 발생해 자격 증명과 토큰이 노출되었을 때 사용자 19만 명이 이러한 피해를 입었습니다. 공격자는 이 정보를 이용해 이미지를 변조하고, 나중에 이를 통해 다른 시스템에 접근했을 수 있습니다.

컨테이너 이미지에만 국한하지 마세요. 외부에서 가져온 애플리케이션 구성 요소도 침해될 수 있다는 점을 기억해야 합니다. 구체적인 사례로는 NodeJS NPM 패키지에 암호화폐 채굴 소프트웨어가 삽입된 사건인 event-stream이 있습니다.

유지 관리되는 이미지 및 구성 요소 인벤토리를 표준으로 채택하면 언젠가는 반드시 발생하는 취약점을 더욱 신속하게 해결할 수 있습니다. 서로 제각각인 컨테이너를 일일이 업데이트하는 것보다 단일 기본 OS 계층을 업데이트하는 편이 훨씬 관리하기 쉽습니다.

4. 스캔 및 문제 해결
컨테이너 환경이 침해되거나 공격에 취약해지는 경로는 매우 다양합니다. 흔히 컨테이너 이미지에 포함된 소프트웨어의 취약점을 먼저 떠올립니다. 이러한 취약점에 주의를 기울여 스캔하고 업데이트하거나 패치를 적용해야 하지만, 상대적으로 잘 탐지되거나 해결되지 않는 구성 관련 문제도 있습니다. 이 중 상당수는 올바르게 구성하면 예방할 수 있습니다. 파이프라인에는 침해를 탐지하거나 안전하지 않은 구성을 경고할 수 있는 도구가 포함되어야 합니다.

Aqua Security는 컨테이너와 구성을 모두 스캔하고 평가하는 데 도움이 되는 도구를 제공합니다. Kube-bench와 kube-hunter는 Kubernetes 환경에서 흔하지만 치명적인 구성 오류를 식별하는 데 유용한 리소스입니다.

o FOSS
https://github.com/aquasecurity/kube-bench
https://github.com/aquasecurity/kube-hunter

o 상용
https://www.aquasec.com/

아무리 많은 검사를 수행해도 그 결과에 따라 조치하지 않으면 시스템 침해나 보안 사고를 예방하는 데 도움이 되지 않습니다. Tripwire의 2019년 컨테이너 보안 현황 보고서에 따르면 조직 5곳 중 약 1곳(17%)은 컨테이너 이미지의 취약점을 알고도 그대로 배포한 것으로 나타났습니다. 이를 고려하면 조사 대상 조직의 절반 이상(60%)이 지난 12개월 동안 컨테이너 관련 보안 사고를 경험했다는 결과도 그리 놀랍지 않습니다.

이 점은 아무리 자주, 아무리 강조해도 지나치지 않습니다. 보안 검사를 파이프라인에 통합한다면(반드시 그래야 합니다) 검사 결과에 따른 후속 조치를 취하는 것이 중요합니다. 문제를 해결하지 않는다면 검사를 실행해도 보안 개선에는 아무런 도움이 되지 않습니다.

다시 한번 강조합니다. 검사를 실행하더라도 발견된 문제를 해결하지 않으면 보안 개선에는 아무런 도움이 되지 않습니다.

파이프라인 보안은 여러 측면이 얽힌 까다로운 문제일 수 있습니다. 파이프라인은 운영용이라는 차이가 있을 뿐, 결국 일련의 애플리케이션이므로 다른 애플리케이션과 동일하게 다뤄야 합니다. 보안을 파이프라인에 통합하는 동안 파이프라인 자체의 보안을 간과하지 마세요.

이 시리즈의 다음 블로그 글을 읽어보세요:
컨테이너 보안 기초: 오케스트레이션