이 시리즈를 처음 접했다면 처음부터 시작하는 것이 좋습니다.
컨테이너 보안 기본 사항: 소개
애플리케이션 자본 시대에 CI/CD 파이프라인은 이를 통해 빌드하고 제공하는 애플리케이션의 속도와 보안을 좌우하는 중요한 구성 요소입니다.
이는 API를 통해 통합되고 스크립트나 플러그인을 통해 호출되는 복잡한 도구 시스템으로, 컨테이너화된 애플리케이션을 빌드하고 최종적으로 제공하는 프로세스 를 디지털 방식으로 표현합니다. 즉, 나쁜 행위자가 시스템을 손상시킬 수 있는 지점이 여러 개 있다는 뜻입니다. 믿기 어려울지 몰라도 오늘날 상당수의 기업이 클라우드를 활용하고 있으며 이는 필연적으로 원격 액세스를 의미한다는 점을 기억하세요.
즉, 파이프라인 보안에는 두 가지 측면이 있습니다. 첫째는 파이프라인 자체의 보안입니다. 두 번째는 파이프라인의 보안입니다.
1. 인증은 선택 사항이 아닙니다
클라우드에서 파이프라인의 일부로 도구와 서비스를 사용하거나 호스팅 서비스로 사용하는 경우 공격에 노출될 수 있습니다. 원격 개발자나 운영진이 내부적으로 호스팅된 도구와 서비스에 액세스하도록 허용하면 공격에 노출될 수 있습니다. 그런 우려를 일축하기 전에, 지난 몇 년 동안 외부 접근에 시스템을 공개함으로써 발생한 침해의 수를 잊지 마세요. 파이프라인 보안과 관련해 가장 좋은 생각은 악의적인 행위자들이 접근할 수 있다는 것입니다.
즉, 가장 먼저 할 일은 액세스를 보호하는 것입니다. 강력한 인증은 선택 사항이 아닙니다. 중요 시스템에 대한 접근성을 세부적으로 조정하기 위해서는 접근 제어를 사용하는 것이 좋습니다. 시스템은 내부적으로만 접근 가능하다고 생각하더라도요. 악의적인 행위자가 침입할 수 있는 다른 시스템이 네트워크에 존재합니다.
인증 문제를 해결했다면 다음은 권한 부여입니다. 권한 부여는 인증된 사용자가 시스템 내에서 무엇을 할 수 있는지 지정합니다. 중요한 구성 요소에 액세스할 수 있는 자격 증명이 적을수록 더 유리하므로 역할에 따라 권한을 구분하는 것이 중요합니다.
파이프라인의 모든 구성 요소에는 인증 및 승인이 필요합니다. 즉, 저장소부터 애플리케이션과 컨테이너를 구축하는 데 사용되는 도구까지 모든 것을 의미합니다.
2. 파이프라인 구성 요소 보안
공격자가 공개 저장소를 스캔하여 엄청난 양의 보물(자격 증명 및 기타 비밀)을 발견했다는 보고를 듣는 것은 안타깝게도 드문 일이 아닙니다. 저장소에서 인증을 요구하라는 알림은 1번을 참조하세요.
오늘날 파이프라인의 현실은 각각 인증이 필요한 통합된 도구 체인이라는 것입니다. 이로 인해 자격 증명과 비밀(키)이 파이프라인을 구성하는 도구와 서비스를 호출하는 스크립트에 저장되는 경우가 많습니다. 이건 매우 심각한 문제입니다. 특히 해당 스크립트가 저장되어 있는 저장소의 인증 관행이 취약한 경우 더욱 그렇습니다.
신임장은 보호되어야 하는 중요한 자산입니다. 정보가 어디에 저장되어 있는지, 어떻게 보호되고 있는지 파악하세요. "비밀 확산"을 관리하는 데 유용한 도구는 HashiCorp Vault 입니다. Vault는 비밀을 중앙 위치에 안전하게 저장합니다.
3. 자재 목록 유지 관리
시스템이나 시스템 구성 요소를 보호하려면 먼저 해당 시스템이나 구성 요소가 존재한다는 사실을 알아야 합니다. 환경에 무엇이 있는지 파악하려면 포괄적인 자재 목록을 유지하는 것이 중요합니다. 중요한 점은, 여러분의 환경에 무엇이 있어야 하는지 , 반대로 무엇이 있어서는 안 되는지 알아야 한다는 것입니다.
잘 유지관리된 재고는 오염되거나 손상된 부품을 파이프라인에 삽입하려는 시도로부터 보호하는 데 도움이 될 수 있습니다. 단일 기본 컨테이너나 적어도 관리 가능한 소수의 컨테이너로 표준화하면 잠재적인 문제를 감지하는 능력이 크게 향상될 수 있습니다. 그러므로 편차가 발생하면 조사가 가능한 경고가 울려야 합니다. 예를 들어, 해시를 비교하고, 가능한 경우 컨테이너 이미지의 디지털 서명을 검증하는 것은 중요한 단계입니다. 원격 저장소에서 가져오는 경우, 저장소가 손상되었을 가능성이 있습니다.
DockerHub에서 보안 침해가 발생하여 19만 명의 사용자의 자격 증명과 토큰이 노출된 경우가 바로 그렇습니다. 공격자는 해당 정보를 사용해 이미지를 손상시키고 나중에 다른 시스템에 접근할 수 있었습니다.
컨테이너 이미지에서 멈추지 마세요. 외부에서 공급된 애플리케이션 구성 요소는 손상될 수 있다는 점을 기억하세요. 구체적인 예로 는 NodeJS NPM 패키지 이벤트 스트림에 암호화폐 채굴 소프트웨어를 삽입하는 것이 있습니다.
유지 관리되는 이미지 및 구성 요소 인벤토리를 표준화하면 취약성이 발생할 경우를 대비해 취약성을 수정하는 작업도 간소화됩니다. 단일 기본 OS 계층을 업데이트하는 것은 여러 컨테이너 세트를 업데이트하는 것보다 관리하기가 훨씬 쉽습니다.
4. 스캔 및 수정
컨테이너 환경이 손상되거나 공격에 취약해지는 방법은 수없이 많습니다. 우리는 종종 소프트웨어의 취약점을 컨테이너 이미지로 생각합니다. 스캔 및 업데이트/패치와 같은 문제에 주의를 기울여야 하지만, 덜 자주 발견되고 해결되는 구성 기반 문제도 있습니다. 이 중 대부분은 올바른 구성을 사용하면 예방할 수 있습니다. 파이프라인에는 보안 침해를 감지하거나 안전하지 않은 구성에 대한 경고를 보낼 수 있는 도구가 포함되어야 합니다.
Aqua Security는 컨테이너와 구성을 스캐닝하고 평가하는 데 도움이 되는 도구를 제공합니다. Kube-bench와 kube-hunter는 Kubernetes 환경에서 흔하지만 중요한 구성 실수를 식별하는 데 유용한 리소스입니다.
세상의 모든 검사를 실시하더라도, 조치를 취하지 않으면 침해나 침해를 방지하는 데 도움이 되지 않습니다. Tripwire의 2019년 컨테이너 보안 현황 에 따르면 5개 조직 중 1개(17%)가 컨테이너 이미지의 취약점을 알고 있지만 이를 배포한 것으로 나타났습니다. 그런 점을 감안하면, 설문 조사에서 조직의 절반 이상(60%)이 지난 12개월 동안 컨테이너 관련 보안 사고를 경험한 것으로 나타난 것은 놀랄 일이 아닐 것입니다.
이 점은 자주, 그리고 충분히 강조할 수 없습니다. 파이프라인에 보안 검사를 통합한 경우(통합해야 함) 결과에 대한 후속 조치를 취하는 것이 중요합니다. 해결하지 않고 검사를 실행하면 보안을 개선하는 데 아무런 도움이 되지 않습니다.
다시 한번 말씀드립니다. 조치를 취하지 않으면 검사를 실행해도 보안이 향상되지 않습니다.
파이프라인 보안은 다면적인 문제이며 까다로울 수 있습니다. 파이프라인은 다른 애플리케이션 세트와 마찬가지로 취급되어야 합니다. 궁극적으로는 운영상의 문제이기는 하지만요. 파이프라인 에 보안을 통합하는 동안 파이프라인 의 보안을 무시하지 마세요.
이 시리즈의 다음 블로그를 읽어보세요.
컨테이너 보안 기본 사항: 관현악법