컨테이너 및 쿠버네티스의 컴플라이언스 고려 사항

컨테이너를 구동하고 있다면, 잠재적인 보안 리스크에 대해서도 생각해 보셨을 겁니다. 워크플로우에 DevOps 접근 방식을 채택했거나 체계적으로 구축된 CI/CD 파이프라인이 마련되어 있지만 민감한 데이터를 보호하고자 할 수 있습니다.

역할 기반 액세스 제어(RBAC)는 쿠버네티스 API 엔드포인트에 대한 권한 부여를 관리하는 일반적인 방식을 제공합니다. 쿠버네티스 클러스터의 RBAC 구성은 어떤 주체가 어떤 네임스페이스의 어떤 리소스 유형을 어떻게 할 것인지 제어하지만, 역할을 어떻게 구성해야 하는지는 규정하지 않습니다. 여기에서 컴플라이언스 프레임워크가 필요합니다.

미국 국립표준기술연구소 특별 간행물 800-190(NIST 800-190)에서는 컨테이너화된 애플리케이션의 보안과 관련된 몇 가지 특정 과제와 조직에서 애플리케이션의 보안 프로파일을 개선하기 위해 수행해야 하는 작업을 이해하기 위한 프레임워크를 제공합니다.

NIST 지침은 미국 정부 기관과 정부 계약자를 대상으로 하지만, 어떤 회사든 NIST 800-190 지침을 따를 수 있습니다. 이러한 지침을 따르면 전반적인 보안을 강화하는 것은 물론 PCI 및 HIPAA와 같은 다른 컴플라이언스 프레임워크를 더욱 쉽게 충족할 수 있기 때문입니다.

리스크

NIST 800-190은 컨테이너화된 애플리케이션에서 보안 취약점의 일반적인 소스를 강조합니다. 이러한 소스에는 다음이 포함됩니다.

• 손상된 이미지
• 컨테이너 이미지의 구성 오류
• 신뢰할 수 없는 컨테이너 이미지
• 잘못 관리된 비밀 정보
• 잘못 구성된 액세스 제어
• OS 취약점
• 불필요하게 광범위한 공격 범위

NIST 800-190은 조직에서 컨테이너화된 애플리케이션 보안에 대해 기존 애플리케이션에 대한 접근 방식과는 다른 방식을 취해야 할 필요성을 강조합니다. 컨테이너화된 애플리케이션에는 가상 머신과는 다른 리스크 요인이 있기 때문에 다른 보안 사례가 필요합니다.

NIST 800-190에서는 조직에 다음을 요구합니다.

• 특정 목적을 위한 툴을 사용해 빌드에서 배포, 런타임까지 라이프사이클 전반에서 이미지 취약점을 관리합니다.
• 이미지가 구성 모범 사례를 준수하는지 확인합니다.
• 이미지 외부에 비밀 정보를 저장하고, 쿠버네티스를 사용해 비밀 정보를 관리하고, 비밀 정보가 필요한 컨테이너에 대한 액세스를 제한하고, 유휴 상태 및 전송 중에 비밀 정보를 암호화하여 보호합니다.
• 레지스트리에 푸시하거나 레지스트리에서 풀링할 때 보안 연결을 사용합니다.
• 컨테이너가 항상 최신 이미지 버전을 사용하는지 확인합니다.
• 최소한 민감한 네트워크와 민감하지 않은 네트워크를 분리해 네트워크 트래픽을 분할합니다.
• 쿠버네티스를 사용해 안전하게 노드를 도입하고 노드의 인벤토리와 연결 상태를 유지합니다.
• 컨테이너의 아웃바운드 트래픽을 제어합니다.
• CIS 벤치마크와 같은 컨테이너 런타임 구성 표준으로 지속적인 컴플라이언스를 보장합니다.
• 보안 제어를 사용해 컨테이너와 인프라 수준에서 위협과 잠재적인 침입을 탐지합니다.
• 가능한 한 공격 범위가 작은 강화된 컨테이너별 운영 체제를 사용합니다.
• 컨테이너가 정상적으로 작동하는 데 필요한 최소한의 권한을 보유하도록 보장하여 호스트 파일 시스템의 변조를 방지합니다.

NIST 800-190 요건을 준수할 필요가 없는 조직에서도 조직의 보안 상태를 개선하는 데 유용한 프레임워크로 이러한 요건을 고려해야 합니다. 이는 조직이 빌드, 배포, 런타임 단계 전반에서 보안을 생각하며 각 단계의 고유한 보안 요건을 처리하는 데 도움이 됩니다.

결제 카드 산업 데이터 보안 표준(PCI-DSS)은 2004년 Visa, MasterCard, American Express, Discover, JCP가 산업 전반의 보안 및 데이터 보호 표준을 마련하기 위해 만들었으며, 처음으로 발표된 후 기술 변화에 맞춰 여러 번 업데이트되었습니다. 이 표준은 카드 소유자의 데이터를 저장, 처리, 전송하는 인력, 프로세스, 기술 등 카드 소유자에 대한 데이터 환경의 모든 부분에 적용됩니다. 기술 측면에서는 하드웨어와 소프트웨어 모두를 포함합니다.

PCI 요건을 준수하는 것은 쉽지 않으며, 매년 기업에서는 평균 550만 달러의 비용이 듭니다. 하지만 준수하지 않는 경우에는 평균 벌금이 1480만 달러로, 훨씬 많은 비용이 듭니다. 올바른 프로세스와 툴이 있으면 PCI 컴플라이언스는 그리 큰 문제가 아닙니다.

PCI DSS는 보다 일반적인 6가지 목표에 연결되는 12가지 요건을 지니고 있습니다.

안전한 네트워크 시스템 구축 및 유지관리

1. 카드 소유자의 데이터를 보호하기 위한 방화벽 구성을 설치하고 유지관리합니다.
2. 벤더에서 제공한 기본값을 시스템 암호와 기타 보안 매개변수에 사용하지 않습니다.

카드 소유자 데이터 보호

1. 저장된 카드 소유자 데이터를 보호합니다.
2. 개방형 퍼블릭 네트워크 전반에서 카드 소유자 데이터의 전송을 암호화합니다.

관리 프로그램의 취약점 유지관리 보장

1. 맬웨어 및 익스플로잇으로부터 모든 시스템을 보호하고 백신 소프트웨어를 정기적으로 업데이트합니다.
2. 보안 시스템과 애플리케이션을 개발하고 유지관리합니다.
3. 강력한 액세스 제어 조치를 구현합니다.

알 필요가 있을 때 알려주는 방식으로 비즈니스별 카드 소유자 데이터에 대한 액세스 제한

1. 시스템 구성 요소에 대한 액세스를 식별하고 인증합니다.
2. 카드 소유자 데이터에 대한 물리적 액세스를 제한합니다.

정기적인 네트워크 모니터링 및 테스트

1. 네트워크 리소스 및 카드 소유자 데이터에 대한 모든 액세스를 추적하고 모니터링합니다.
2. 보안 시스템과 프로세스를 정기적으로 테스트합니다.

정보 보안 정책의 유지관리 보장

1. 모든 직원에 대한 정보 보안 관련 정책을 유지관리합니다.

컨테이너화된 애플리케이션에 대한 PCI 컴플라이언스

컨테이너 및 쿠버네티스 환경과 직접적으로 관련된 PCI에 요약되어 있는 위의 6가지 목표와 관련된 여러 가지 요건이 있습니다. 다음 요건을 해결할 수 있도록 컨테이너와 쿠버네티스 보안 툴링을 평가합니다.

1.12 모든 무선 네트워크를 비롯해 카드 소유자 환경(CDE)과 기타 네트워크 간 모든 연결을 식별하는 현재 네트워크 다이어그램

1.1.4 각 인터넷 연결 및 완충 영역(DMZ)과 내부 네트워크 영역 간의 방화벽 요건

1.2. 신뢰할 수 없는 네트워크와 카드 소유자 데이터 환경의 모든 시스템 구성 요소 간의 연결을 제한하는 방화벽 및 라우터 구성을 구축합니다.

1.2.1 인바운드와 아웃바운드 트래픽을 카드 소유자 데이터 환경에 필요한 트래픽으로 제한하고 다른 모든 트래픽은 거부합니다.

1.3.2 인바운드 인터넷 트래픽을 DMZ 내 IP 주소로 제한합니다.

1.3.4 카드 소유자 데이터 환경에서 인터넷으로 무단 아웃바운드 트래픽을 허용하지 않습니다.

1.3.5 네트워크에 설정된 기존 연결만 허용합니다.

2.1 벤더에서 제공한 기본값은 항상 변경하고 네트워크에 시스템을 설치하기 전 불필요한 기본 계정을 제거 또는 비활성화합니다.

2.2 모든 시스템 구성 요소에 대한 구성 표준을 개발합니다. 이러한 표준이 알려진 모든 보안 취약점을 해결하고 업계가 인정한 시스템 강화 표준과 일치하는지 확인합니다.

2.2.1 각기 다른 보안 수준이 필요한 기능이 동일한 서버에 공존하는 것을 방지하기 위해 서버당 주요 기능을 하나만 구현합니다. (예를 들어, 웹 서버, 데이터베이스 서버, DNS는 각각 별도의 서버에 구현되어야 합니다.)

2.2.2 시스템 기능에 필요한 서비스, 프로토콜, 데몬 등만 활성화합니다.

2.2.3 안전하지 않은 것으로 간주되는 모든 필수 서비스, 프로토콜, 데몬에 대해 추가 보안 기능을 구현합니다.

2.2.5 스크립트, 드라이버, 기능, 하위 시스템, 파일 시스템, 불필요한 웹 서버와 같은 불필요한 기능을 모두 제거합니다.

2.3 강력한 암호화를 사용해 콘솔이 아닌 모든 관리자 액세스를 암호화합니다.

2.4 PCI DSS 범위에 있는 시스템 구성 요소의 인벤토리를 유지관리합니다.

3.6.2 암호화 키 분배의 보안을 유지합니다.

6.1 보안 취약점 정보에 대한 신뢰할 수 있는 외부 소스를 사용해 보안 취약점을 식별하기 위한 프로세스를 구축하고 새로 발견한 보안 취약점에 리스크 랭킹을 할당(예: "높음", "중간", "낮음")합니다.

6.2 벤더에서 제공한 적절한 보안 패치를 설치해 모든 시스템 구성 요소와 소프트웨어를 알려진 취약점에서 보호합니다. 중요 보안 패치는 릴리스 후 1달 이내에 설치합니다.

6.4.1 개발/테스트 환경을 프로덕션 환경과 분리하고 액세스 툴로 이러한 분리를 시행합니다.

6.4.2 개발/테스트 및 프로덕션 환경 간 작업을 분리합니다.

6.5.1 주입 결함, 특히 SQL 주입을 고려합니다. 기타 주입 결함과 마찬가지로 OS 커맨드 주입, LDAP 및 XPath 주입 결함 또한 고려합니다.

6.5.3 안전하지 않은 암호화 스토리지

6.5.4 안전하지 않은 커뮤니케이션

6.5.6 취약점 식별 프로세스에서 식별된 모든 "리스크 높음" 취약점(PCI DSS 요건 6.1의 정의에 따름)

10.2.5 모든 시스템 구성 요소에 대한 자동 감사 추적을 구현하여 식별 및 인증 메커니즘(새로운 계정 생성 및 권한 에스컬레이션을 포함하되 이에 국한되지 않음)에 대한 사용과 변경 사항, 루트 또는 관리 권한이 있는 계정에 대한 모든 변경 사항, 추가, 삭제를 재구성합니다.

11.2.1 분기별로 내부 취약점 스캔을 수행합니다. 취약점을 해결하고 다시 스캔하여 모든 "리스크 높음" 취약점이 엔터티의 취약점 랭킹(요건 6.1에 따름)에 따라 해결되었는지 확인합니다. 스캔 작업은 반드시 자격이 있는 직원이 수행해야 합니다.

11.5 변경 탐지 메커니즘(예: 파일 무결성 모니터링 툴)을 배포해 중요 시스템 파일, 구성 파일, 콘텐츠 파일에 대한 무단 수정(변경, 추가, 삭제 포함)이 발생하는 경우 직원에게 알리고, 적어도 일주일에 한 번 중요 파일 비교를 수행할 소프트웨어를 구성합니다.

11.5.1 변경 탐지 솔루션에서 생성된 모든 알림에 응답하는 프로세스를 구현합니다.

1996년 의료정보보호법(Health Information Portability and Accountability Act)은 모든 건강 기록과 관련된 환자의 개인 정보를 관리하기 위해 HIPAA 컴플라이언스 프레임워크를 만들었습니다. 여기에 디지털 건강 기록을 관리하기 위해 2003년 보안 규칙이 추가되었습니다. 개인을 식별할 수 있는 전자보호건강정보(ePHI)를 다루는 모든 조직에서는 HIPAA 요건을 준수해야 합니다. 여기에는 진료, 커뮤니케이션, 청구를 위해 의료 기관에서 직접 사용하는 애플리케이션이 포함됩니다.

HIPAA 컴플라이언스와 관련한 주요 과제는 보안 프레임워크가 조직이 컨테이너와 쿠버네티스에서 지침을 어떻게 준수해야 하는지에 대한 구체적인 정보보다는 대략적인 지침만 제공한다는 점입니다. 또한 보호되는 건강 정보 및 보호되지 않는 건강 정보 간의 차이는 PCI 컴플라이언스에 따라 보호해야 하는 신용카드 정보와 그렇지 않은 정보 간의 차이보다 명확하지 않은 경우가 많습니다.

의료 기관 이외에도 의료 기관에 대한 스토리지 또는 청구 서비스를 제공하는 모든 조직은 전자보호건강정보(ePHI) 처리와 관련된 서비스를 제공하는 경우 HIPAA 요건을 만드시 준수해야 합니다.

HIPAA 보안 규칙 표준은 관리, 물리, 기술 관련 안전 조치로 세분화됩니다. IT 인프라와 관련된 기술적 안전 조치는 다음과 같은 표준을 포함합니다.

• 액세스 제어
• 감사 제어
• 무결성
• 인증
• 전송 보안

HIPAA 보안 규칙은 조직이 ePHI 보안을 유지하기 위해 취해야 하는 조치에 대한 세부 정보를 제공하지 않으며, 컨테이너화된 애플리케이션에 한정되지 않습니다. 일반적으로 HIPAA 컴플라이언스 준수 작업을 시작하는 가장 좋은 방법은 컨테이너 보안에 대한 지침과 모범 사례를 제공하는 NIST SP 800-190 프레임워크를 적용하는 것입니다. HIPAA와 달리 NIST SP 800-190은 컨테이너에 한정된 프레임워크를 제공하므로 컴플라이언스를 더 쉽게 증명할 수 있습니다. 하지만 HIPAA 요건을 충족하려면 ePHI를 보호하고 다른 데이터 유형으로부터 분리하여 유지하기 위해 추가적인 분리 제어를 구현해야 합니다.

또한 HIPAA는 조직이 애플리케이션을 완전 복원하여 지속적인 컴플라이언스를 입증할 수 있도록 데이터뿐만 아니라 구성 파일에 대한 백업을 유지하도록 요구합니다.