오픈인프라 한국 커뮤니티 / 김관영 부회장


그로메트릭 / 김관영 대표


 



 

1. 컨테이너 이미지 보안의 중요성

컨테이너 이미지는 애플리케이션 코드, 운영체제, 라이브러리 및 YAML/JSON 파일 등 컨테이너를 실행하는 데 필요한 모든 것을 포함하는 컨테이너의 기본 빌딩 블록입니다. 컨테이너 이미지는 그림1과 같이 여러 개의 기반 이미지(base image)로 구성되며, 이들은 읽기 전용(read-only) 레이어로 쌓여 있습니다. 각 기반 이미지 레이어는 애플리케이션을 실행하는 데 필요한 파일 시스템의 일부를 포함하고 있으며, 이러한 레이어들은 함께 결합되어 완전한 파일 시스템을 형성합니다. 이 구조는 이미지의 재사용성과 효율성을 높이는 데 기여하며, 쓰기 가능한 레이어로 컨테이너 기반 이미지에 따른 동작이 이루어집니다.


[그림1. 컨테이너 이미지 계층과 컨테이너 실행 계층(Docker 홈페이지: https://docs.docker.com/storage/storagedriver/) ]


 

보안 관점에서 바라보면, 컨테이너 이미지를 통해 운영체제 수준에서 격리된 환경을 제공합니다. 이는 컨테이너가 호스트 시스템 나머지 부분과 격리되어 있으며, 다른 컨테이너와 자원을 공유하지 않는다는 것을 의미합니다. 따라서 컨테이너 이미지를 통해 보다 빠른 시작 시간과 적은 오버헤드를 가지며, 클라우드 환경에서의 확장성과 효율성을 높여줍니다.

반면, 컨테이너 이미지에 포함된 소프트웨어에 취약점이 있다면 해당 애플리케이션은 위험에 노출될 수가 있습니다. 즉, 컨테이너 이미지가 안전하지 않으면 컨테이너도 안전하지 않습니다. 따라서 컨테이너 이미지에 대한 취약점 관리가 필수이며, 이를 위해 이미지 스캐닝 도구를 사용하여 이미지 내의 알려진 취약점을 식별하고, 이를 해결하기 위한 업데이트와 패치를 적용해야 합니다. 이와 같이 컨테이너 이미지 보안은 컨테이너 보안 전체의 가장 중요한 부분이라 볼 수 있겠습니다.

또한 컨테이너 이미지 보안은 컨테이너 이미지가 end-to-end로 동작하는 DevOps를 넘어선 DevSecOps 관점으로 바라볼 필요가 있습니다. 이해를 돕기 위해 DevSecOps Pipeline 보안의 목표를 설명하는 그림을 인용합니다. 그림2에서 설명하는 개발 파이프라인에 다양한 단계를 제품 고객에게 더욱 안전하고 안정적인 제품을 제공할 수 있습니다. 몇 가지 오픈 소스 및 상용 툴을 예로 설명하며, 또한 툴과 파이프라인상에 구현하려는 위치를 자유롭게 선택할 수 있고 통합할 수 있습니다. 보안 단계를 구현하는 것 외에도 중앙 취약성 관리 솔루션을 보유하고 있다면 애플리케이션 보안에 대한 가시성을 가질 수 있고 단계별 필요한 툴에 대해 나열되어 있어 전체 보안 향상에 도움을 줄 수 있습니다.


[그림2. DevSecOps Pipeline (OWASP DevSecOps guideline - v-0.2)]


 

오픈 소스 웹 애플리케이션 보안 프로젝트에 해당하는 OWASP (Open Web Application Security Project)에서는 DevSecOps에 대한 Shift-Left 보안에 대해 언급하고 있습니다. Shift-left 보안은 개발 최종 단계에 보안을 도입하는 대신 프로세스 초기에 보안을 도입합니다. 프로젝트 기초에서부터 초기 시작부터 위협 모델링을 통해 설계시 보안을 고려하고 대규모 보안 테스트를 소규모 보안 테스트로 세분화하여 개발 파이프라인에 통합하는 것을 목표로 합니다. 이와 같이 컨테이너 기반 인프라를 활용하고 있는 상황에서 컨테이너 이미지에 대한 선제적인 보안 요소를 고려하고 이를 DevSecOps 실천 사례를 기반으로 반영하는 과정을 통해 컨테이너 이미지 보안을 향상할 수 있겠습니다.

 



 

2. 컨테이너 이미지 취약점

컨테이너 이미지가 노출될 수 있는 주요 취약점에 대해 구체적으로 살펴봅시다.

  • 소프트웨어 취약점: 컨테이너 이미지에 포함된 소프트웨어 자체에 알려진 취약점이 있을 수 있습니다.

예)Alpine Linux(Busybox) Docker 이미지 취약점(CVE-2019-5021): Docker 컨테이너에 루트가 아닌 사용자로 서비스를 실행하는 경우 shadow 관련 없는 보안 취약점을 통해 시스템을 손상시킨 공격자 또는 셸 액세스 권한이 있는 사용자가 컨테이너 내에서 자신의 권한을 루트로 승격시켜 리부팅 등을 실행할 수 있음




  • 구성 오류: 컨테이너 이미지 구성이 잘못되어 공격자가 악용할 수 있는 보안 허점이 있을 수 있습니다.
    예)루트 사용자로 애플리케이션을 실행하는 설정을 하거나 또 다른 예로는 민감한 데이터(예: API 키, Secret 등 credential)를 환경 변수나 이미지 자체에 하드코딩하는 실수 등을 말함
  • 악성 코드: 공격자가 악성 코드를 삽입하여 컨테이너 이미지를 감염시킬 수 있습니다.
    오픈 소스 라이브러리에 악성 코드를 숨기고, 해당 라이브러리를 사용하는 컨테이너 이미지를 통해 시스템을 감염시킬 수 있으며, 만약 사전에 걸러지지 않고 프로덕션 환경에 배포되면, 공격자는 네트워크 트래픽을 도청하거나, c2서버에 접속하여 추가적인 악성 소프트웨어를 다운로드하고 실행하여 시스템을 제어할 수 있게 됩니다.
  • 사용자망 공격: 공격자는 Pipeline상의 악성 코드가 포함된 컨테이너 이미지를 이용하여 권한상승을 통한 사용자의 네트워크의 권한 탈취를 지속적으로 시도

공격자는 배포된 악성 코드를 통하여 래터럴 무브먼트(Lateral Movement, 권한상승을 통한 측면이동)를 통해 네트워크에 액세스하거나 데이터를 탈취할 수 있습니다. 이를 방지하기 위해 신뢰할 수 있는 소스에서만 이미지와 라이브러리를 가져오고, 정기적인 보안 감사를 수행하는 것이 중요


 

이러한 컨테이너 이미지 취약점을 살펴보고 분석하는 방법에는 크게 정적인 SAST 방식과 동적인 DAST 방식, 그리고 인터렉티브 IAST를 기반으로 테스팅 및 분석하는 방식으로 나눌 수 있습니다. 각 방식에 대해 구체적으로 살펴보겠습니다.

 



 

  • SAST(Static Application Security Testing)

정적 코드 분석(Static scanning)은 코드를 실행하지 않고 프로그램의 오류를 찾는 중요한 프로세스입니다. 이 과정은 구문 위반, 보안 취약점, 프로그래밍 오류, 코딩 표준 위반, 정의되지 않은 값 등 다양한 코딩 문제를 식별하는 데 도움을 줍니다.

정적 코드 분석을 위한 주요 도구로는 Fortify, SonarQube, Veracode, Security Code Scan, Brakeman, Enlightn, Inquisition, CodeSweep, HCL AppScan on Cloud, Semgrep, Checkmarx SAST, 가 있으며, 이들은 다양한 프로그래밍 언어와 플랫폼을 지원합니다. 또한, IaC(코드형 인프라) 보안 스캔을 통해 Terraform, Ansible, Puppet 등의 코드에 대한 보안 취약점 및 구성 오류를 방지할 수 있습니다. 이를 위한 도구로는 Checkov, Ansible-lint, puppet-lint, tfsec, terrascan, tflint 등이 있습니다. 이러한 정적 분석 도구들은 코드의 품질을 향상시키고 보안을 강화하는 데 중요한 역할을 합니다.

 

  • DAST(Dynamic Application Security Testing)

동적 애플리케이션 보안 테스트(DAST)는 실행 중인 웹 애플리케이션의 보안 취약점을 식별하는 데 사용되는 "블랙박스" 테스트 방식입니다. 이 접근 방식은 애플리케이션에 악성 페이로드를 주입하여 SQL 인젝션, XSS(교차 사이트 스크립팅), 입력/출력 검증 오류, 인증 문제, 서버 구성 실수 등의 보안 취약점과 약점을 찾습니다. DAST 도구는 애플리케이션의 소스 코드나 구축된 프레임워크에 접근할 필요 없이 클라이언트 측과 서버 측 모두에서 스캔을 수행할 수 있으며, 주로 자동화된 방식으로 작동해 야간 검사 등에 활용됩니다.

주요 DAST 도구로 오픈소스인 ZED Attack Proxy(ZAP)가 있으며 상용제품으로는 Acunetix, Netsparker, InsightAppSec(AppSpider), Veracode Dynamic Analysis, Burp Suite, HCL AppScan on Cloud, Nuclei 등이 있으며, 이들은 다양한 웹 애플리케이션의 보안 취약점을 효과적으로 식별하고 분석하는 데 사용됩니다. 이 도구들은 자동 웹 보안 테스트, 취약점 식별 및 보안 테스트 전반을 지원하는 통합 플랫폼을 제공합니다.

 

  • IAST(Interactive Application Security Testing)

IAST(상호작용형 애플리케이션 보안 테스팅)는 애플리케이션이 실행되는 동안, 자동화된 테스트, 사람에 의한 테스팅 또는 애플리케이션 기능과의 상호 작용을 통해 보안 취약점을 찾아내는 테스팅 방법입니다. IAST의 중심에는 애플리케이션 코드에 통합된 센서 모듈이 있으며, 이 모듈은 테스팅 도중 애플리케이션의 동작을 모니터링하여 취약점을 감지하고 실시간으로 알림을 발송합니다.

IAST는 통합 개발 환경(IDE), 연속 통합(CI) 환경, 품질 보증 과정 또는 실제 운영 환경에서의 실시간 피드백을 제공합니다. 센서는 전체 코드, 데이터 흐름과 제어 흐름, 시스템 구성 데이터, 웹 컴포넌트, 백엔드 연결 데이터에 대한 접근 권한을 가지고 있습니다. 예를 들어, API 키를 평문으로 하드코딩하거나 사용자 입력을 적절히 처리하지 않거나 SSL 암호화 없이 연결을 사용하는 것과 같은 취약점을 식별할 수 있습니다.

IAST와 SAST(정적 애플리케이션 보안 테스팅)는 다른 접근 방식을 취합니다. SAST는 소스 코드를 실행하지 않는 환경에서 검사하여 보안 위험을 나타내는 코드 패턴을 찾아내지만, 실행 시점의 다른 보안 대책을 고려하지 않아 거짓 긍정의 결과를 초래할 수 있습니다. 반면, IAST는 실제 실행 환경에서 보안 취약점을 실시간으로 감지할 수 있어, 실제 운영 환경에서도 유연하게 적용할 수 있습니다.

IAST와 DAST(동적 애플리케이션 보안 테스팅)의 차이점은, DAST가 애플리케이션의 외부에서 보안 위험을 평가하는 반면, IAST는 애플리케이션 내부의 동작을 모니터링하며 실시간으로 취약점을 찾아낸다는 것입니다. DAST는 전문 앱섹 팀에 의해 운영되어야 하며, 일반적으로 자동화하기 어렵습니다. 하지만 IAST는 실시간 테스트를 통해 즉각적인 피드백을 제공합니다.

IAST 도구의 예로는 Contrast Community Edition (CE), Checkmarx Interactive Application Security Testing(CxIAST), Seeker Interactive Application Security Testing, HCL AppScan on Cloud 등이 있습니다. 이러한 도구들은 애플리케이션 보안 강화에 필수적인 역할을 하며, 개발 및 운영 환경에서 보안 취약점을 식별하고 대응하는 데 도움을 줍니다.

또한 컨테이너 이미지 보안을 분석하기 위한 방식으로 소프트웨어 구성 요소 분석 (SCA, Software Component/Composition Analysis)이 있습니다. 소프트웨어 구성 요소 분석(SCA)은 코드베이스의 제3자 및 오픈 소스 구성 요소를 관리하기 위해 애플리케이션 보안을 자동화하는 과정입니다. SCA는 코드베이스 내의 잠재적으로 취약한 구성 요소를 찾아내어 공급망 공격과 같은 높은 보안 위험을 방지할 뿐만 아니라 각 구성 요소에 대한 라이선싱 정보도 제공합니다. 이를 통해 조직은 코드베이스 라이브러리의 보안 위험을 줄이고 현대 소프트웨어 개발 생명주기 초기에 이를 적용해야 합니다.

SCA는 취약한 라이브러리가 생산 환경으로 푸시되는 것을 방지하기 위해 SAST, DAST, IAST와 같은 보안 테스트 이전에 적용해야 하며, 공급망 공격 위험을 신속하게 줄이기 위해 라이브러리의 지속적인 모니터링을 구현해야 합니다.

 



 

컨테이너 이미지 보안에 도움을 주는 도구는 다음과 같다. 적절히 활용하여 컨테이너 이미지 보안을 강화해보자.:

오픈 소스:

  • OWASP Dependency-check: Java, .NET, JavaScript, Ruby를 지원하며 프로젝트 의존성 내에 공개된 취약점을 탐지하려고 시도하는 SCA 도구입니다.
  • RetireJS: JavaScript 특화 의존성 검사기입니다.
  • Safety: 알려진 보안 취약점을 위한 Python 의존성 검사기입니다.
  • bundler-audit: Ruby 3rd party 라이브러리 버전에 대한 패치 수준 검증을 제공합니다.

상용:

  • Hakiri: Ruby 및 Rails 기반 GitHub 프로젝트를 위한 의존성 검사를 제공하는 상용 도구입니다.
  • HCL AppScan on Cloud: SAST, SCA 및 IaC를 동시에 수행할 수 있는 서비스로 구축된 SAST 도구입니다.
  • Snyk: SaaS 솔루션으로 제공되는 SCA 도구입니다.
  • WhiteSource: 소프트웨어 개발 생명주기 전반에 걸쳐 취약점으로부터 보호하고 라이선스 정책을 시행합니다.
  • Synopsys BlackDuck: 소프트웨어 개발 생명주기(SDLC) 전반에 걸쳐 오픈 소스 사용, 보안 위험, 라이선스 준수에 대한 정책을 정의하고 자동으로 시행할 수 있습니다.

 

인프라 취약점 스캐닝은 DevOps가 개발 및 배포 과정을 자동화하는 데 큰 역할을 하지만, 사용되는 컨테이너, 라이브러리 등이 자주 업데이트 되므로 코드를 배포하는 인프라가 안전한지 확인하는 것이 필수적입니다. 이를 위해 취약점 스캐닝을 파이프라인에 통합하는 것이 최선의 방법입니다.

취약점 스캐너는 알려진 약점을 평가하기 위해 설계된 컴퓨터 프로그램으로, 컴퓨터, 네트워크 또는 애플리케이션의 취약점을 발견하는 데 사용됩니다. 이러한 스캐너는 잘못된 구성 또는 프로그래밍 오류로 인해 발생하는 취약점을 식별하고 탐지하는 데 도움을 줍니다. 현대의 취약점 스캐너는 인증된 스캔과 인증되지 않은 스캔 모두를 지원하며, 주로 SaaS(서비스로서의 소프트웨어) 형태로 제공됩니다.

인증된 스캔은 스캐너가 SSH나 RDP와 같은 원격 관리 프로토콜을 사용하여 네트워크 기반 자산에 직접 접근하고 제공된 시스템 자격 증명을 사용하여 인증하는 방법입니다. 이를 통해 스캐너는 호스트 운영 체제의 구체적인 서비스와 구성 세부 정보와 같은 저수준 데이터에 접근할 수 있으며, 운영 체제와 설치된 소프트웨어에 대한 자세하고 정확한 정보를 제공할 수 있습니다.

반면, 인증되지 않은 스캔은 false positive(오탐)를 많이 발생시킬 수 있으며, 자산의 운영 체제 및 설치된 소프트웨어에 대한 자세한 정보를 제공할 수 없는 방법입니다. 이 방법은 보통 외부에 접근 가능한 자산의 보안 상태를 판단하려는 위협 행위자나 보안 분석가가 사용합니다.

도구로는 SAINT, Nessus, Arachni, Burp Suite, Nexpose, Nikto 등이 있으며, 이들은 네트워크의 보안 취약점을 스캐닝하고 발견된 취약점을 이용하는 데 사용됩니다. 이러한 도구들은 운영 체제, 네트워크 장치, 데이터베이스, 웹 서버 등 다양한 기술에 대한 스캔을 지원하며, XSS, SQL 인젝션, 코드 인젝션, 파일 포함 변형 등 다양한 취약점을 스캔할 수 있습니다.

 

 


참 고 문 헌




  2. https://owasp.org/www-project-devsecops-guideline/latest/index
  3. https://cloud.google.com/software-supply-chain-security/docs?hl=ko
  4. https://www.alpinelinux.org/posts/

  5. https://cve.mitre.org/
  6. https://aquasecurity.github.io/trivy/v0.50/tutorials/overview/
  7. https://snyk.io/series/devsecops/8-best-practices/



저작권 정책


K-ICT 클라우드혁신센터의 저작물인 『컨테이너 이미지 보안』은 K-ICT 클라우드혁신센터에서 오픈인프라 한국 커뮤니티 김관영 부회장에게 집필 자문을 받아 발행한 전문정보 브리프로, K-ICT 클라우드혁신센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.