NIST SP 800-190

NIST SP 800-190(Application Container Security Guide, 애플리케이션 컨테이너 보안 가이드)는 미국 국립표준기술연구소(NIST, National Institute of Standards and Technology)가 애플리케이션 컨테이너의 이미지·레지스트리·오케스트레이터·런타임·호스트 운영체제에서 발생하는 보안 위험과 대응 방안을 정리한 보안 지침이다.

개요

NIST SP 800-190은 애플리케이션 컨테이너(Application Container)의 설계, 구축, 운영 및 유지보수 과정에서 발생할 수 있는 보안 위협을 분석하고 대응 방안을 제시하는 지침이다.

컨테이너는 운영체제 수준의 가상화와 애플리케이션 패키징을 결합한 기술이다. 애플리케이션과 실행에 필요한 라이브러리·설정 등을 이미지로 구성하고, 호스트 운영체제의 커널을 공유하면서 격리된 환경에서 실행한다.

컨테이너는 기존 가상 머신보다 빠르게 생성·배포할 수 있고 애플리케이션의 이식성과 확장성을 높일 수 있지만, 호스트 커널 공유, 이미지 공급망, 오케스트레이션 권한, 컨테이너 간 통신 등에서 고유한 보안 위험이 발생한다.

NIST SP 800-190은 이러한 위험을 이미지(Image), 레지스트리(Registry), 오케스트레이터(Orchestrator), 컨테이너(Container), 호스트 운영체제(Host OS)의 다섯 영역으로 구분하고, 하드웨어 기반 보호조치를 포함한 대응 방안을 제시한다.

주요 특징은 다음과 같다.

• 컨테이너 기술의 아키텍처와 보안 특성 설명.
• 이미지, 레지스트리, 오케스트레이터, 컨테이너 및 호스트 운영체제의 보안 위험 분석.
• 각 구성요소의 위험에 대응하는 구체적인 보호조치 제시.
• 이미지 취약점 검사와 신뢰할 수 있는 이미지 사용 강조.
• 컨테이너 런타임의 최소 권한 및 격리 설정 권고.
• 서로 다른 민감도의 워크로드에 대한 네트워크 및 호스트 분리 권고.
• 컨테이너의 짧은 수명과 불변성에 적합한 보안 운영 방식 제시.
• 컨테이너 인식형 런타임 보안 도구 사용 권고.
• 하드웨어 신뢰 기반을 활용한 플랫폼 무결성 보호.
• 컨테이너 도입부터 폐기까지 수명주기별 보안 고려사항 제시.
• NIST SP 800-53 보안 통제 및 NIST 사이버보안 프레임워크와의 연계 제공.

항목	내용
문서 번호	NIST SP 800-190
정식 명칭	Application Container Security Guide
한국어 명칭	애플리케이션 컨테이너 보안 가이드
발행기관	NIST
발행일	2017년 9월 25일
현행판	2017년 최종본
주요 분야	컨테이너 보안, 가상화 보안, 클라우드 보안
주요 대상	애플리케이션 컨테이너를 구축·운영·관리하는 조직
핵심 구성요소	이미지, 레지스트리, 오케스트레이터, 컨테이너, 호스트 OS
관련 지침	NIST SP 800-53, NIST SP 800-125
공식 페이지	NIST CSRC
원문	PDF

발행 및 현행 상태

NIST는 2017년 4월과 7월에 SP 800-190의 공개 초안을 발표하고 의견을 수렴한 뒤, 2017년 9월 25일 최종본을 발행하였다.

날짜	상태	내용
2017년 4월 10일	최초 공개 초안	컨테이너 보안 위험과 대응 방안에 대한 의견 수렴
2017년 7월 13일	두 번째 공개 초안	공개 의견을 반영한 개정 초안 발표
2017년 9월 25일	최종본	NIST SP 800-190 확정 발행
2020년 9월 4일	부가 안내	일본 정보처리추진기구(IPA)의 비공식 일본어 번역본 안내

2026년 10월 23일 기준 NIST CSRC의 공식 발행 목록에는 2017년 9월 최종본이 현행 문서로 게시되어 있으며, 별도의 Revision 1 또는 후속 개정판은 확인되지 않는다.

2020년 9월의 안내는 번역본 제공에 관한 것으로, 보안 요구사항이나 본문을 개정한 것은 아니다.

이 문서는 2017년의 컨테이너 기술 환경을 바탕으로 작성되었다. 따라서 당시 사용된 제품명과 구현 사례를 현재의 기술 상태로 해석해서는 안 된다.

특히 최신 컨테이너 런타임, 오케스트레이션 플랫폼 및 소프트웨어 공급망 보호 기술의 세부 구현은 해당 기술의 최신 공식 문서와 함께 확인할 필요가 있다.

적용 대상 및 범위

SP 800-190은 애플리케이션 컨테이너 기술을 도입하거나 운영하는 조직을 대상으로 한다.

주요 독자는 다음과 같다.

• 시스템 관리자.
• 보안 관리자.
• 정보보호 프로그램 책임자.
• 정보시스템 보안 책임자.
• 애플리케이션 개발자.
• 컨테이너 플랫폼 운영자.
• DevOps 및 인프라 운영 담당자.

이 문서는 특정 제품이나 클라우드 사업자에 종속되지 않으며, 다양한 애플리케이션 컨테이너 기술에 공통으로 적용할 수 있는 보안 원칙을 다룬다.

다만 다음 기술은 직접적인 적용 범위에서 제외된다.

• 애플리케이션 컨테이너가 아닌 일반적인 가상 머신.
• 모바일 기기에서 업무 데이터와 개인 데이터를 분리하는 데이터 컨테이너.
• 데스크톱 운영체제의 애플리케이션 격리 기술 가운데 이 문서에서 정의하는 애플리케이션 컨테이너에 해당하지 않는 기술.

하드웨어, 하이퍼바이저, 관리자 단말기, 개발 및 시험 시스템 등은 컨테이너 환경의 보안에 영향을 주지만, 이 문서는 해당 구성요소의 일반적인 보안 대책을 상세하게 다루지는 않는다.

이러한 영역에 대해서는 별도의 NIST 지침을 참조하도록 한다.

컨테이너 기술의 보안 특성

운영체제 커널 공유

일반적인 가상 머신은 하이퍼바이저를 이용해 가상 하드웨어를 제공하며, 각 가상 머신은 독립적인 게스트 운영체제를 실행한다.

반면 애플리케이션 컨테이너는 호스트 운영체제의 커널을 공유한다.

구분	가상 머신	애플리케이션 컨테이너
가상화 방식	하드웨어 가상화	운영체제 수준 가상화
운영체제	가상 머신별 게스트 OS	호스트 OS 커널 공유
주요 격리 경계	하이퍼바이저	운영체제의 프로세스 및 자원 격리 기능
배포 단위	가상 머신 이미지	컨테이너 이미지
주요 보안 위험	하이퍼바이저 취약점, VM 탈출	커널 취약점, 컨테이너 탈출, 과도한 권한
운영 방식	장기간 유지되는 인스턴스가 일반적	이미지 기반 재생성과 교체가 일반적

컨테이너는 일반적으로 네임스페이스(Namespace)를 이용해 프로세스·네트워크·파일시스템 등의 가시성을 분리하고, 제어 그룹(Control Groups, cgroups)을 이용해 CPU와 메모리 등의 자원 사용량을 제한한다.

그러나 커널 자체를 공유하므로 커널 취약점이나 격리 메커니즘의 결함이 악용되면 다른 컨테이너 또는 호스트 운영체제까지 영향을 받을 수 있다.

NIST는 이러한 이유로 컨테이너의 격리 수준이 일반적인 하이퍼바이저 기반 가상화보다 낮을 수 있다고 설명한다.

불변성

컨테이너 환경은 불변성(Immutability)을 중요한 운영 특성으로 활용한다.

실행 중인 컨테이너에 직접 패치를 적용하는 대신, 수정된 애플리케이션과 라이브러리를 포함한 새 이미지를 생성하고 기존 컨테이너를 교체하는 방식이다.

이러한 운영 방식은 다음과 같은 보안상 이점을 제공한다.

• 개발·시험·운영 환경에서 동일한 이미지 사용.
• 검증된 이미지의 반복 배포.
• 변경 이력 추적 및 재현성 향상.
• 침해된 컨테이너를 검증된 이미지로 교체.
• 취약한 이미지의 일괄 교체 및 배포 자동화.

반면 기존 서버를 대상으로 하는 보안 도구는 장기간 유지되는 시스템을 전제로 설계된 경우가 있어 컨테이너의 짧은 수명과 빈번한 변경을 충분히 반영하지 못할 수 있다.

따라서 이미지 기반 취약점 관리와 컨테이너 실행 상태를 인식하는 보안 도구가 필요하다.

컨테이너 보안 아키텍처

SP 800-190은 컨테이너 기술의 핵심 구성요소를 다음과 같이 구분한다.

구성요소	영문	역할	주요 보안 고려사항
이미지	Image	애플리케이션 실행에 필요한 파일과 설정을 패키징	취약점, 악성코드, 비밀정보, 이미지 신뢰성
레지스트리	Registry	이미지 저장·배포·버전 관리	인증, 접근통제, 전송 암호화, 이미지 무결성
오케스트레이터	Orchestrator	컨테이너 배치·확장·관리	관리자 권한, 네트워크 분리, 워크로드 배치, 노드 신뢰
컨테이너	Container	격리된 애플리케이션 실행 환경	런타임 취약점, 권한, 네트워크 접근, 악성 행위
호스트 운영체제	Host OS	커널 및 컨테이너 실행 기반 제공	커널 공유, 공격 표면, 패치, 파일시스템 보호

이미지 생성과 검증

개발자는 애플리케이션 실행에 필요한 바이너리, 라이브러리, 설정 파일 등을 이용해 컨테이너 이미지를 생성한다.

이미지는 여러 계층(Layer)으로 구성될 수 있으며, 기반이 되는 계층을 베이스 이미지(Base Image)라고 한다.

이미지 생성 과정에는 빌드 자동화와 지속적 통합(CI) 도구가 활용될 수 있다.

보안상 중요한 점은 개발 단계에서 생성한 이미지와 시험·승인을 거친 이미지, 실제 운영에 배포되는 이미지의 동일성을 유지하는 것이다.

이미지 저장과 배포

검증된 이미지는 컨테이너 저장소에 저장된다.

레지스트리는 이미지의 저장, 검색, 버전 관리 및 다운로드 기능을 제공한다.

이미지가 레지스트리에 저장된 이후에는 승인되지 않은 변경, 악성 이미지 교체, 오래된 이미지 재사용 등을 방지해야 한다.

컨테이너 배포와 운영

오케스트레이터는 이미지를 이용해 컨테이너를 생성하고 실행할 호스트를 결정한다.

또한 컨테이너의 실행 상태, 네트워크 연결, 확장 및 장애 복구 등을 관리한다.

쿠버네티스는 이러한 오케스트레이션 기술의 대표적인 사례이다.

오케스트레이터는 다수의 컨테이너와 호스트를 통합 관리하므로 관리 권한이 탈취되면 광범위한 피해가 발생할 수 있다.

주요 보안 위험

SP 800-190의 제3장은 컨테이너 기술의 핵심 구성요소에서 발생하는 주요 위험을 다섯 영역으로 구분한다.

이미지 위험

위험	영문	설명
이미지 취약점	Image Vulnerabilities	이미지에 포함된 운영체제 구성요소나 라이브러리에 알려진 취약점이 존재
이미지 설정 결함	Image Configuration Defects	불필요한 서비스 실행, 과도한 권한 등 안전하지 않은 설정
악성코드 포함	Embedded Malware	이미지에 악성코드가 포함되어 배포
평문 비밀정보 포함	Embedded Clear Text Secrets	비밀번호, 인증키 등의 비밀정보가 이미지에 평문으로 포함
신뢰할 수 없는 이미지	Use of Untrusted Images	출처와 무결성이 검증되지 않은 이미지 사용

이미지는 생성 시점에 취약점이 없더라도 이후 새로운 취약점이 발견되면 안전하지 않은 상태가 될 수 있다.

따라서 최초 빌드 시점의 검사뿐 아니라 저장·배포·운영 과정에서 지속적인 취약점 관리가 필요하다.

레지스트리 위험

레지스트리에서는 다음과 같은 위험이 발생할 수 있다.

• 안전하지 않은 레지스트리 연결(Insecure Connections to Registries): 암호화되지 않은 통신으로 이미지나 인증정보가 노출될 가능성.
• 오래된 이미지(Stale Images): 보안 업데이트가 적용되지 않은 이미지가 계속 저장되거나 배포되는 문제.
• 불충분한 인증 및 인가(Insufficient Authentication and Authorization Restrictions): 권한이 없는 사용자가 이미지를 조회·등록·수정·삭제할 가능성.

특히 이미지 등록 권한이 탈취되면 공격자가 정상적인 배포 절차를 이용해 악성 이미지를 운영 환경에 공급할 수 있다.

오케스트레이터 위험

위험	영문	설명
무제한 관리자 접근	Unbounded Administrative Access	관리자에게 필요 이상의 광범위한 권한 부여
비인가 접근	Unauthorized Access	인증·인가 결함으로 클러스터 관리 기능에 무단 접근
컨테이너 간 네트워크 분리 미흡	Poorly Separated Inter-Container Network Traffic	서로 다른 애플리케이션 사이의 네트워크 통신이 충분히 제한되지 않음
서로 다른 민감도의 워크로드 혼합	Mixing of Workload Sensitivity Levels	보안 중요도가 다른 컨테이너가 동일한 호스트에서 실행
오케스트레이터 노드 신뢰 문제	Orchestrator Node Trust	클러스터 구성요소 간 인증 및 신뢰 관계가 충분히 보호되지 않음

오케스트레이터는 자원 활용률을 높이기 위해 서로 다른 애플리케이션을 동일한 호스트에 배치할 수 있다.

그러나 인터넷에 공개된 웹 애플리케이션과 민감한 금융정보를 처리하는 애플리케이션이 동일한 커널을 공유하면, 한쪽의 침해가 다른 쪽에 영향을 줄 위험이 증가한다.

NIST는 워크로드의 목적, 민감도 및 위협 수준에 따라 호스트와 네트워크를 분리하도록 권고한다.

컨테이너 위험

컨테이너 실행 환경에서는 다음과 같은 위험이 발생할 수 있다.

• 런타임 소프트웨어 취약점(Vulnerabilities within the Runtime Software): 런타임의 결함을 이용한 컨테이너 탈출이나 다른 컨테이너 침해.
• 제한되지 않은 네트워크 접근(Unbounded Network Access from Containers): 침해된 컨테이너가 다른 내부 시스템에 접근하거나 공격을 수행.
• 안전하지 않은 런타임 설정(Insecure Container Runtime Configurations): 특권 모드, 과도한 시스템 호출 허용, 민감한 호스트 디렉터리 마운트.
• 애플리케이션 취약점(App Vulnerabilities): SQL 인젝션, 크로스 사이트 스크립팅 등 컨테이너 내부 애플리케이션의 취약점.
• 비인가 컨테이너(Rogue Containers): 조직의 승인이나 관리 없이 생성·운영되는 컨테이너.

특권 모드(Privileged Mode)로 실행되는 컨테이너는 호스트 장치에 광범위하게 접근할 수 있으므로 다른 컨테이너와 호스트 운영체제에 심각한 영향을 줄 수 있다.

또한 호스트의 중요 디렉터리를 쓰기 가능한 상태로 마운트하면 컨테이너 내부의 침해가 호스트 설정 변조로 이어질 수 있다.

호스트 운영체제 위험

위험	영문	설명
넓은 공격 표면	Large Attack Surface	불필요한 서비스와 구성요소로 공격 가능 지점 증가
커널 공유	Shared Kernel	하나의 커널 취약점이 여러 컨테이너에 영향을 줄 가능성
호스트 구성요소 취약점	Host OS Component Vulnerabilities	커널과 시스템 라이브러리 등의 취약점
부적절한 사용자 권한	Improper User Access Rights	호스트 관리자 및 사용자에게 과도한 권한 부여
호스트 파일시스템 변조	Host OS File System Tampering	컨테이너를 통한 호스트 파일 및 설정 변경

컨테이너의 격리는 호스트 운영체제의 보안 기능에 의존한다.

따라서 이미지와 컨테이너를 안전하게 관리하더라도 호스트 운영체제가 침해되면 해당 호스트에서 실행되는 컨테이너 전체가 영향을 받을 수 있다.

주요 대응 방안

SP 800-190의 제4장은 제3장에서 식별한 위험에 대응하는 보호조치를 제시한다.

이미지 보안

이미지 보안의 주요 권고사항은 다음과 같다.

• 이미지에 포함된 운영체제 패키지와 애플리케이션 라이브러리의 취약점 검사.
• 이미지 설정에 대한 보안 기준 준수 여부 확인.
• 불필요한 서비스와 소프트웨어 제거.
• 이미지에 포함된 악성코드 탐지.
• 이미지에 비밀번호·API 키 등 비밀정보를 평문으로 포함하지 않도록 관리.
• 신뢰할 수 있는 이미지와 레지스트리의 허용 목록 유지.
• 암호학적 서명을 이용한 이미지 출처 및 무결성 검증.
• 승인되지 않은 이미지의 실행 차단.
• 취약한 이미지의 재빌드 및 재배포.
• 이미지별 취약점과 보안 설정 상태의 중앙 관리.

NIST는 컨테이너 이미지의 특성을 이해하는 전용 취약점 관리 도구를 사용할 것을 권고한다.

기존 서버 기반 취약점 스캐너는 실행 중인 컨테이너의 파일시스템이나 이미지 계층에 포함된 취약점을 충분히 식별하지 못할 수 있다.

레지스트리 보안

레지스트리의 주요 대응 방안은 다음과 같다.

• 레지스트리와 개발·배포 도구 사이의 통신 암호화.
• 민감한 이미지에 대한 읽기 권한 통제.
• 이미지 등록·변경·삭제 권한에 대한 인증 적용.
• 사용자와 서비스 계정에 최소 권한 원칙 적용.
• 이미지 등록 및 변경 이력에 대한 감사기록 유지.
• 오래되거나 취약한 이미지의 정리.
• 승인된 이미지의 버전과 식별자 관리.
• 이미지 서명 및 무결성 검증.

NIST는 이미지의 버전을 명확하게 지정하여 검증된 이미지를 배포하도록 권고한다.

특히 latest와 같은 태그는 단순한 식별자이며, 실제로 최신 보안 업데이트가 적용되었다는 보증이 아니라는 점에 유의해야 한다.

오케스트레이터 보안

오케스트레이터의 주요 대응 방안은 다음과 같다.

• 관리자에게 필요한 최소한의 권한만 부여.
• 클러스터 전체에 영향을 미치는 관리자 계정의 사용 제한.
• 관리 인터페이스에 강력한 인증 적용.
• 관리자 계정에 다중요소 인증 적용.
• 관리 활동에 대한 중앙 감사 및 모니터링.
• 애플리케이션의 민감도에 따른 네트워크 분리.
• 보안 중요도가 다른 워크로드의 호스트 분리.
• 클러스터 노드 간 인증 및 암호화된 통신.
• 승인되지 않은 노드의 클러스터 참여 차단.
• 관리 노드와 실행 노드의 신뢰 관계 보호.

네트워크 분리 시에는 애플리케이션별 또는 민감도별 가상 네트워크를 구성할 수 있다.

또한 오케스트레이터의 배치 정책을 이용해 보안 수준이 다른 컨테이너가 동일한 호스트 커널을 공유하지 않도록 할 수 있다.

컨테이너 런타임 보안

컨테이너 런타임의 주요 대응 방안은 다음과 같다.

• 런타임 소프트웨어의 보안 업데이트 적용.
• 컨테이너별 네트워크 접근 범위 제한.
• 불필요한 특권 모드 사용 금지.
• 필요한 시스템 호출만 허용.
• 호스트의 민감한 디렉터리 마운트 제한.
• 애플리케이션 실행에 필요한 최소한의 권한 부여.
• 컨테이너 인식형 런타임 보안 도구 사용.
• 비인가 컨테이너의 탐지 및 차단.
• 실행 중인 컨테이너의 비정상 행위 모니터링.
• 침해된 컨테이너의 격리 및 교체.

일반적인 네트워크 보안 장비는 컨테이너 내부의 프로세스와 가상 네트워크 흐름을 충분히 식별하지 못할 수 있다.

따라서 컨테이너의 실행 상태, 프로세스, 네트워크 통신 및 보안 설정을 인식하는 런타임 보안 도구가 필요하다.

호스트 운영체제 보안

NIST는 가능한 경우 컨테이너 실행에 특화된 최소 기능 운영체제(Container-Specific Host OS)를 사용할 것을 권고한다.

컨테이너 전용 운영체제는 일반적인 서버 운영체제보다 불필요한 구성요소와 서비스가 적어 공격 표면을 줄일 수 있다.

주요 보호조치는 다음과 같다.

• 불필요한 서비스 및 소프트웨어 제거.
• 호스트 운영체제와 커널의 보안 업데이트.
• 호스트에 대한 대화형 사용자 접근 제한.
• 컨테이너와 호스트 사이의 파일시스템 접근 제한.
• 민감한 호스트 디렉터리의 마운트 방지.
• 호스트 설정과 시스템 파일의 무결성 보호.
• 워크로드 민감도에 따른 호스트 분리.
• 호스트의 보안 상태에 대한 지속적인 모니터링.

컨테이너 전용 운영체제를 사용하더라도 커널과 필수 시스템 구성요소의 취약점은 계속 관리해야 한다.

하드웨어 기반 보호

SP 800-190은 소프트웨어 기반 보호조치를 보완하기 위해 하드웨어 신뢰 기반(Hardware Root of Trust)을 활용할 수 있다고 설명한다.

대표적인 기술은 신뢰 플랫폼 모듈(Trusted Platform Module, TPM)이다.

하드웨어 기반 보호는 다음 절차로 설명할 수 있다.

1. 시스템 펌웨어, 소프트웨어 및 설정의 측정값 생성.
2. 측정값을 TPM과 같은 하드웨어 신뢰 기반에 저장.
3. 현재 측정값을 기대되는 측정값과 비교.
4. 플랫폼의 무결성과 신뢰 상태 확인.
5. 검증된 실행 환경을 컨테이너 런타임과 이미지로 확장.

이러한 접근법은 부팅 과정과 운영체제의 무결성을 확인하고, 신뢰할 수 있는 환경에서 컨테이너가 실행되는지 검증하는 데 활용할 수 있다.

컨테이너 위협 시나리오

SP 800-190의 제5장은 세 가지 컨테이너 공격 시나리오를 제시한다.

이미지 취약점 악용

Exploit of a Vulnerability within an Image

공격자가 이미지에 포함된 애플리케이션이나 라이브러리의 취약점을 악용하는 시나리오이다.

1. 취약한 구성요소가 포함된 이미지가 생성됨.
2. 해당 이미지로 컨테이너가 배포됨.
3. 공격자가 컨테이너 내부 애플리케이션의 취약점을 악용함.
4. 컨테이너 내부에서 비인가 작업을 수행하거나 민감한 정보에 접근함.
5. 컨테이너의 권한과 네트워크 연결 상태에 따라 다른 시스템으로 공격이 확산될 수 있음.

주요 대응 방안은 이미지 취약점 검사, 신속한 이미지 재빌드, 최소 권한 적용 및 런타임 모니터링이다.

컨테이너 런타임 취약점 악용

Exploit of the Container Runtime

공격자가 컨테이너 런타임의 취약점을 이용해 격리 경계를 우회하는 시나리오이다.

1. 공격자가 컨테이너 내부에서 코드 실행 권한을 확보함.
2. 컨테이너 런타임 또는 격리 메커니즘의 취약점을 악용함.
3. 컨테이너의 격리 경계를 벗어나 호스트 운영체제에 접근함.
4. 호스트의 권한과 자원을 악용하여 다른 컨테이너에 영향을 줄 수 있음.

이러한 공격은 컨테이너 탈출(Container Escape)이라고 한다.

주요 대응 방안은 런타임 패치, 특권 제한, 호스트 운영체제 보호 및 보안 중요도에 따른 워크로드 분리이다.

악성 이미지 실행

Running a Poisoned Image

공격자가 악성코드가 포함되거나 변조된 이미지를 조직의 실행 환경에 배포하도록 유도하는 시나리오이다.

1. 공격자가 이미지 또는 이미지 공급 경로를 변조함.
2. 변조된 이미지가 레지스트리에 저장되거나 정상 이미지로 오인됨.
3. 조직의 배포 절차를 통해 해당 이미지가 실행됨.
4. 이미지에 포함된 악성코드가 컨테이너 내부에서 실행됨.
5. 공격자가 정보 탈취 또는 추가 공격을 수행할 수 있음.

주요 대응 방안은 이미지 출처 검증, 암호학적 서명, 신뢰할 수 있는 레지스트리 사용 및 이미지 실행 정책의 강제 적용이다.

수명주기별 보안 고려사항

SP 800-190의 제6장은 컨테이너 기술의 수명주기를 다섯 단계로 구분하고 각 단계에서 고려해야 할 보안 활동을 설명한다.

단계	영문	주요 보안 활동
착수	Initiation	컨테이너 도입에 따른 정책·절차·조직 운영 방식 검토
계획 및 설계	Planning and Design	보안 아키텍처, 격리 정책, 사고 대응 및 포렌식 계획 수립
구현	Implementation	보안 설정, 이미지 검증, 접근통제 및 모니터링 체계 구축
운영 및 유지보수	Operations and Maintenance	취약점 관리, 이미지 교체, 런타임 감시 및 사고 대응
폐기	Disposition	컨테이너·이미지·관련 자원의 안전한 제거 및 정보 보호

착수 단계

컨테이너 도입에 따라 기존 보안 정책과 운영 절차를 검토한다.

특히 다음 영역의 변경 필요성을 확인한다.

• 취약점 관리.
• 침해사고 대응.
• 디지털 포렌식.
• 시스템 패치 및 업데이트.
• 애플리케이션 개발·배포 절차.
• 보안 담당자와 개발자의 역할.
• 컨테이너 기술에 대한 교육 및 훈련.

컨테이너는 기존 서버와 다른 배포·운영 방식을 사용하므로 기술적 도입뿐 아니라 조직의 운영 절차도 함께 변경해야 한다.

계획 및 설계 단계

컨테이너 환경의 보안 아키텍처와 운영 정책을 수립한다.

특히 컨테이너의 짧은 수명과 불변성을 고려한 포렌식 및 사고 대응 체계를 설계해야 한다.

컨테이너가 종료되거나 교체되면 내부에 저장된 일부 실행 상태와 증거가 사라질 수 있다.

따라서 사고 분석에 필요한 로그와 데이터를 컨테이너의 수명과 독립적으로 보존할 수 있도록 설계하는 것이 중요하다.

또한 워크로드 민감도에 따른 네트워크 및 호스트 분리 방안을 결정한다.

구현 단계

계획된 보안 정책을 실제 컨테이너 플랫폼에 구현한다.

주요 활동은 다음과 같다.

• 신뢰할 수 있는 이미지 저장소 구성.
• 이미지 취약점 검사 체계 구축.
• 이미지 서명 및 무결성 검증.
• 컨테이너 실행 권한 제한.
• 오케스트레이터 관리자 접근통제.
• 네트워크 및 호스트 격리 정책 적용.
• 컨테이너 런타임 모니터링 도구 배치.
• 감사기록 및 보안 이벤트 수집 체계 구축.

보안 정책이 실제 배포 과정에서 강제되는지 확인해야 한다.

운영 및 유지보수 단계

컨테이너 환경의 지속적인 보안 상태를 유지한다.

주요 활동은 다음과 같다.

• 신규 취약점에 대한 이미지 재검사.
• 취약한 이미지의 재빌드 및 재배포.
• 컨테이너 런타임과 호스트 운영체제 업데이트.
• 실행 중인 컨테이너의 이상행위 탐지.
• 비인가 컨테이너의 식별.
• 접근 권한 및 네트워크 정책 점검.
• 보안 사고 발생 시 컨테이너 격리.
• 침해사고 조사에 필요한 증거 보존.

이미지에 보안 업데이트가 필요할 경우 실행 중인 컨테이너를 직접 수정하기보다 새로운 이미지로 교체하는 방식이 권장된다.

폐기 단계

컨테이너와 관련 자원을 폐기할 때는 남아 있는 정보와 접근 권한을 고려해야 한다.

주요 활동은 다음과 같다.

• 사용하지 않는 컨테이너 및 이미지 제거.
• 관련 저장소와 볼륨의 잔존 데이터 확인.
• 비밀정보와 인증정보의 안전한 처리.
• 더 이상 필요하지 않은 접근 권한 회수.
• 보존이 필요한 로그와 기록의 별도 관리.
• 관련 자원의 안전한 폐기.

컨테이너를 삭제하더라도 외부 볼륨이나 공유 저장소에 데이터가 남아 있을 수 있으므로 저장 자원의 수명주기를 별도로 고려해야 한다.

주요 보안 권고사항 요약

SP 800-190의 핵심 권고사항을 운영 영역별로 정리하면 다음과 같다.

영역	핵심 권고사항	주요 목적
이미지 관리	이미지 취약점 및 설정 검사	취약한 구성요소의 배포 방지
이미지 신뢰	승인된 이미지와 레지스트리만 사용	악성 이미지 및 공급망 공격 방지
이미지 무결성	암호학적 서명 및 검증	이미지 변조 탐지
비밀정보 관리	이미지에 평문 비밀정보 포함 금지	인증정보 유출 방지
레지스트리	인증·인가·암호화·감사 적용	이미지 저장 및 배포 경로 보호
오케스트레이터	최소 권한 및 강력한 관리자 인증	클러스터 관리 권한 보호
네트워크	민감도별 가상 네트워크 분리	컨테이너 간 공격 확산 제한
호스트 배치	민감도가 다른 워크로드 분리	공유 커널에 따른 위험 제한
런타임	특권 제한 및 컨테이너 인식형 보안 도구 사용	실행 중 공격 탐지 및 차단
호스트 OS	최소 기능 운영체제와 보안 업데이트	호스트 공격 표면 축소
하드웨어	TPM 등 하드웨어 신뢰 기반 활용	플랫폼 무결성 확인
운영 절차	이미지 교체 중심의 취약점 관리	컨테이너 운영 특성에 맞는 보안 유지

문서 구조

SP 800-190은 본문 7개 장과 부록 A부터 E까지로 구성된다.

구분	영문 제목	주요 내용
제1장	Introduction	문서의 목적, 적용 범위 및 구성
제2장	Introduction to Application Containers	컨테이너 기술의 개념, 아키텍처 및 활용
제3장	Major Risks for Core Components of Container Technologies	핵심 구성요소별 주요 보안 위험
제4장	Countermeasures for Major Risks	위험별 보안 대응 방안
제5장	Container Threat Scenario Examples	컨테이너 공격 시나리오
제6장	Container Technology Life Cycle Security Considerations	수명주기별 보안 고려사항
제7장	Conclusion	결론
부록 A	NIST Resources for Securing Non-Core Components	비핵심 구성요소 보호를 위한 NIST 자료
부록 B	NIST SP 800-53 and NIST Cybersecurity Framework Security Controls Related to Container Technologies	관련 보안 통제와 사이버보안 프레임워크 항목
부록 C	Acronyms and Abbreviations	약어
부록 D	Glossary	용어 정의
부록 E	References	참고문헌

제3장과 제4장의 대응관계

제3장은 보안 위험을 식별하고, 제4장은 해당 위험에 대한 대응 방안을 제시한다.

두 장은 다음과 같이 대응한다.

위험 분석	대응 방안
3.1 이미지 위험	4.1 이미지 보호조치
3.2 레지스트리 위험	4.2 레지스트리 보호조치
3.3 오케스트레이터 위험	4.3 오케스트레이터 보호조치
3.4 컨테이너 위험	4.4 컨테이너 보호조치
3.5 호스트 OS 위험	4.5 호스트 OS 보호조치
하드웨어 신뢰 기반	4.6 하드웨어 보호조치

부록 B의 보안 통제 매핑

부록 B는 컨테이너 기술과 관련된 NIST SP 800-53 보안 통제 및 NIST 사이버보안 프레임워크 항목을 정리한다.

대표적인 보안 통제는 다음과 같다.

통제 번호	영문	컨테이너 보안과의 관계
AC-3	Access Enforcement	컨테이너와 관리 기능에 대한 접근통제
AC-4	Information Flow Enforcement	컨테이너 간 정보 흐름 통제
AC-6	Least Privilege	사용자와 컨테이너 프로세스의 최소 권한 적용
CM-2	Baseline Configuration	컨테이너 및 호스트의 보안 설정 기준 관리
CM-6	Configuration Settings	이미지와 런타임의 보안 설정 관리
RA-5	Vulnerability Scanning	이미지와 구성요소의 취약점 검사
SC-6	Resource Availability	컨테이너별 자원 사용량 제한
SC-7	Boundary Protection	컨테이너와 네트워크 사이의 경계 보호
SC-39	Process Isolation	컨테이너 프로세스 격리
SI-7	Software, Firmware, and Information Integrity	이미지와 소프트웨어의 무결성 검증
SI-14	Non-Persistence	불변 이미지와 교체 방식의 운영

부록 B의 매핑은 2017년 당시의 NIST SP 800-53 및 사이버보안 프레임워크를 기준으로 작성되었다.

따라서 최신 개정판의 통제 번호와 내용, 프레임워크 분류 체계를 확인할 때는 해당 문서의 현행판을 참조해야 한다.

관련 NIST 문서와의 관계

문서	주요 내용	SP 800-190과의 관계
NIST SP 800-125	Guide to Security for Full Virtualization Technologies	일반적인 가상화 보안 지침
NIST SP 800-125A	Security Recommendations for Hypervisor Deployment	하이퍼바이저 보안 지침
NIST SP 800-53	Security and Privacy Controls for Information Systems and Organizations	컨테이너 보안에 적용 가능한 보안 통제 제공
NIST SP 800-154	Guide to Data-Centric System Threat Modeling	컨테이너 위험 분석에 활용된 데이터 중심 위협 모델링 방법
NIST IR 8176	Security Assurance Requirements for Linux Application Container Deployments	리눅스 애플리케이션 컨테이너 배포의 보안 보증 요구사항

NIST SP 800-125와의 차이

NIST SP 800-125는 하이퍼바이저 기반의 완전 가상화(Full Virtualization) 기술에 관한 보안 지침이다.

가상 머신과 하이퍼바이저의 격리, 가상 네트워크, 관리 기능 및 보안 설정 등을 다룬다.

반면 SP 800-190은 호스트 운영체제의 커널을 공유하는 애플리케이션 컨테이너에 초점을 맞춘다.

두 문서는 모두 가상화 환경의 보안을 다루지만 보호 대상과 주요 위험이 다르다.

NIST SP 800-53과의 관계

NIST SP 800-53은 정보시스템과 조직을 위한 보안 및 개인정보 보호 통제 카탈로그이다.

SP 800-190은 이 통제 카탈로그 가운데 컨테이너 기술과 관련된 항목을 식별하고 적용 방향을 설명한다.

다만 SP 800-190 자체가 SP 800-53의 모든 보안 통제를 대체하거나 별도의 보안 통제 기준선을 정의하는 것은 아니다.

NIST IR 8176과의 관계

NIST IR 8176은 리눅스 애플리케이션 컨테이너 배포의 보안 보증 요구사항을 다룬다.

SP 800-190이 다양한 컨테이너 기술에 적용할 수 있는 보안 위험과 운영 지침을 제시한다면, IR 8176은 리눅스 컨테이너 환경의 보안 보증 요구사항을 보다 구체적으로 다룬다.

두 문서는 컨테이너 보안이라는 공통 주제를 다루지만 목적과 기술적 범위가 다르다.

적용 시 유의사항

SP 800-190은 컨테이너 보안을 위한 기술적·운영적 권고사항을 제시하는 지침이다.

다음 사항을 구분할 필요가 있다.

• 컨테이너의 프로세스 격리와 가상 머신의 하드웨어 가상화 기반 격리.
• 이미지 생성 시점의 보안 검사와 운영 중 지속적인 취약점 관리.
• 이미지 무결성 검증과 이미지 내부 소프트웨어의 안전성 검증.
• 컨테이너 내부 애플리케이션의 취약점과 컨테이너 런타임 자체의 취약점.
• 네트워크 수준의 격리와 공유 커널 수준의 격리.
• 이미지 삭제와 외부 저장소에 남아 있는 데이터의 삭제.
• 호스트 운영체제의 보안과 컨테이너 내부의 보안.

특히 이미지에 대한 취약점 검사만으로 컨테이너 환경 전체의 보안을 확보할 수는 없다.

레지스트리, 오케스트레이터, 런타임, 호스트 운영체제 및 하드웨어를 포함한 전체 아키텍처에서 보안조치를 적용해야 한다.

또한 SP 800-190은 2017년에 발행된 지침으로, 이후 등장하거나 발전한 컨테이너 보안 기술의 모든 세부사항을 포함하지는 않는다.

따라서 현재의 컨테이너 환경에 적용할 때는 NIST의 기본적인 보안 원칙을 유지하면서 해당 플랫폼의 최신 보안 기능과 공식 지침을 함께 검토해야 한다.

같이 보기

• 컨테이너 보안
• 컨테이너 가상화
• 컨테이너 저장소
• 도커
• 도커파일
• 쿠버네티스
• 가상화 보안
• 하이퍼바이저
• 최소 권한 원칙