Limitations of Korea's Cloud Security Assurance Program (CSAP) Kubernetes Security Criteria and Proposed Policy Improvement Directions

국내 클라우드 보안 인증(CSAP)의 Kubernetes 보안 기준의 한계와 정책적 개선 방향 제안

Abstract

Kubernetes has become a core platform for cloud infrastructure, and corresponding security requirements are growing increasingly sophisticated. In South Korea, the Cloud Security Assurance Program (CSAP), operated by the Korea Internet & Security Agency (KISA), provides security checklists for Kubernetes environments based on the Common Configuration Enumeration (CCE). However, these CCE items are largely focused on static configuration checks and do not sufficiently address modern security needs such as runtime protection, policy enforcement, and supply chain security. This study analyzes the Kubernetes-related CCE items in comparison with global security frameworks, including the CIS Benchmark, MITRE ATT&CK, NIST SP 800-190, and the NSA-CISA Kubernetes Hardening Guide. The analysis reveals that the current checklist is limited in both scope and technical depth, making it insufficient to address real-world security threats in cluster operations. To overcome these limitations, this study proposes a multi-layered security assessment model consisting of configuration checks, runtime security, and policy-based controls, and designs it to enable effective evaluation through integration with open-source automation tools. The proposed model is expected to contribute to the improvement of CCE items and the practical enhancement of CSAP certification criteria.

Kubernetes는 클라우드 인프라의 핵심 플랫폼으로 자리잡으며, 이에 따른 보안 요구도 점차 고도화되고 있다. 한국인터넷진흥원에서 운영하는 CSAP(Cloud Security Assurance Program)은 Kubernetes 환경에 대해 CCE(Common Configuration Enumeration) 기반 점검 항목을 제공하고 있으나, 구성 설정 위주의 정적 점검에 치중되어 런타임 보안, 정책 통제 등 최신 보안 요구는 충분히 반영되지 못하고 있다. 이 연구는 CCE 내 Kubernetes 항목을 중심으로 관련 학술연구와 CIS Benchmark, MITRE ATT&CK, NIST SP 800-190, NSA-CISA 가이드라인 등 글로벌 보안 프레임워크와의 비교 분석을 수행하였다. 그 결과, 현행 항목은 점검 범위와 기술적 깊이에서 한계가 있으며, 실제 클러스터 운영 보안 위협에 대응하기 어렵다는 구조적 취약성을 확인하였다. 이에 이 연구는 정적 구성, 실행환경 보안, 정책 기반 통제의 세 계층으로 구성된 다층 보안 점검 체계를 제안하고, 오픈소스 자동화 도구와의 연계를 통해 실효성 있는 점검이 가능하도록 설계하였다. 제안된 체계는 CCE 항목의 개선과 CSAP 인증 기준의 현실적 보완에 기여할 수 있을 것으로 기대된다.

1. 서론

클라우드 네이티브 환경의 확산으로 Kubernetes는 국내외 핵심 인프라로 자리잡고 있으며, 이에따른 보안 요구도 함께 고도화되고 있다. 특히 국내에서는 공공기관, 금융권, 민간 클라우드 사업자를 중심으로 Kubernetes 기반 환경 도입이 활발히 진행되고 있다. Kubernetes는 분산된 컴포넌트 구조와 API 기반 운영 체계를 바탕으로, 기존 VM 기반 보안 모델과는 구별되는 다층 보안 접근이 요구된다. 단순한 구성 설정 점검을 넘어, 실행 환경의 위협 탐지, 정책 기반 통제, 이미지 무결성 검증 등이 필수적이다.

이에 한국인터넷진흥원(KISA)은 클라우드 보안 인증 제도인 CSAP(Cloud Security Assurance Program)[1]를 운영하며, 39종의 시스템별 보안기준을 마련하고 있다. Kubernetes 환경에 대해서는 Master 및 Worker 노드의 주요 컴포넌트(API Server, Scheduler, Kubelet 등)를 대상으로 CCE(Common Configuration Enumeration)[2] 기반의 구성 설정 항목을 제시하고 있다. 그러나 이는 초기 설치 환경에 국한된 정적 점검 중심으로, 런타임 보안, 정책 통제 등 현대적 보안 수요를 충분히 반영하지 못한다는 지적이 있다.

본 연구는 CSAP 내 Kubernetes 관련 CCE 항목의 구조적 한계를 분석하고, 국내 환경에 실질 적용 가능한 보완 방향을 제시하고자 한다. 특히 실행환경 보안과 정책 통제를 포함한 다층 점검 체계를 통해, CSAP 인증의 현실성과 운영 효율성을 높이는 정책적 시사점을 도출하는 것을 목표로 한다

2. 관련 연구

Kubernetes 보안은 클라우드 네이티브 환경의 핵심 영역으로 주목받고 있으며, 관련 연구는 학술적 분석과 실무 지침으로 병행 발전해왔다. 본 절에서는 선행 논문과 국내외 보안 프레임워크 및 가이드라인으로 각각 분리하여 살펴본다.

2.1 Kubernetes 보안 관련 학술연구

Kubernetes 보안에 대한 학술적 연구는 클러스터 내 보안 취약점을 효과적으로 대응하기 위한 다층적 접근을 중심으로 발전해왔다. 대표적으로, 첫째는 API Server, Kubelet, Scheduler 등 핵심 컴포넌트의 설정 상태를 기준으로 한 정적 구성 설정 점검(Configuration) 영역으로, Kubernetes 보안 구성을 표준화하고 점검 자동화를 위한 기초로 활용되어 왔다. 둘째는 클러스터 실행 중 발생 할 수 있는 위협을 실시간으로 탐지하고 분석하는 실행 환경 기반 보안(Runtime Security) 영역으로, 이는 이상 행위 탐지 기술과 공격 시나리오 기반 대응 전략 수립을 중심으로 연구가 확장되고 있다. 셋째는 RBAC, PodSecurityPolicy, 네트워크 정책 등의 보안 정책을 자동화 도구와 연계해 적용하는 정책 기반 통제(Policy Enforcement) 영역으로, 클러스터 보안의 일관성과 운영 효율성을 동시에 확보하기 위한 방향으로 진화하고 있다.

이러한 세 축은 최근의 주요 학술 연구와 글로벌 보안 프레임워크에서 공통적으로 강조되고 있으며, 본 연구가 제안하는 정책적 개선방향의 이론적 기반을 형성한다. 본 절에서는 이 세 영역에 대한 대표적 학술연구를 정리하고, 이 논문의 정책적 개선방향과의 연결 지점을 고찰한다.

Shamim et al.(2020)[3]은 Kubernetes 보안 원칙을 'XI Commandments of Kubernetes Security'라는 형태로 제시하면서, 클러스터의 구성과 실행정책을 계층화된 구조로 정리하였다. RBAC 기반 최소 권한 설정, Pod 간 네트워크 분리, Audit Logging 활성화, PodSecurityPolicy 적용, TLS 통신 보장, 신뢰된 이미지 사용 등은 이 논문에서 제안하는 정적구성(Configuration) 및 정책 기반 통제(Policy) 계층의 구조 설계와 밀접하게 연관된다.

Rahman et al.(2023)[4]은 92개의 오픈소스 프로젝트로부터 수집한 2,039개의 Kubernetes 매니페스트 파일을 분석하여 구성 보안 오류의 유형과 분포를 실증적으로 조사하였다. 이들은 정적 분석 도구인 SLI-KUBE를 활용해 securityContext 미설정, 리소스 제한 미기입, 호스트 네트워크 사용 등 11가지 주요 구성 오류를 식별하였고, 총 1,051건의 취약한 설정사례를 보고하였다. 해당 연구는 Kubernetes 구성파일에서 보안 설정 오류가 광범위하게 존재하며, 자동화된 정적 점검 도구의 도입이 필수적임을 강조하였다. 이 논문에서는 이러한 구성 기반 보안 점검의 필요성을 기반으로, 정적 점검뿐 아니라 실행 시점 보안과 정책 연계 점검으로 확장하는 다층적 보안 평가 모델의 필요성을 제기한다.

Aly et al.(2025)[5]은 Kubernetes 환경에서 실시간으로 다양한 유형의 위협을 탐지하고 동시에 공격자를 유인하는 사이버 기만(Deception) 기법을 적용한 프레임워크를 제안하였다. 본 연구에서는 KServe 기반 머신러닝 모델을 활용하여 DDoS, 권한 상승 등 다양한 공격을 실시간으로 분류하고, KubeDeceive를 통해 공격자를 디코이 리소스로 유도함으로써 실질적 피해를 방지하였다. 실험 결과 탐지 정확도는 91%, 기만 성공률은 93%에 달했으며, 이러한 연구는 Kubernetes 런타임 보안 영역에서 실시간 대응과 능동적 방어의 결합 가능성을 실증적으로 보여주었다. 이 논문에서는 이를 기반으로 런타임 계층의 정량 점검 요소 도출 및 정책 연계 방안을 함께 고려한다.

Budigiri et al.(2021)[6]은 Kubernetes의 네트워크 정책(NetworkPolicy)이 멀티테넌트 환경에서 얼마나 효과적으로 보안을 제공하는지를 실증적으로 분석하였다. Cilium과 Calico와 같은 eBPF 기반 CNI 플러그인을 활용하여 정책 적용 시의 네트워크 지연 및 처리량 저하를 계측하고, 네트워크 분리 효과 및 정책 회피 가능성도 함께 평가하였다. 실험 결과, 네트워크 정책은 최소한의 성능 손실로 강력한 트래픽 제어를 제공하며, Kubernetes 환경에서 저비용 고효율의 보안 통제 수단임을 입증하였다. 이 논문은 이와 같은 선행연구를 기반으로, 정책 기반 통제가 클러스터 보안의 운영 효율성과 일관성을 확보하는 데 중요한 역할을 한다는 점을 확장하여 다룬다.

Darwesh et al.(2022)[7]는 Kubernetes 실무자 중심의 관찰을 통해 10가지 보안 실천 항목을 정리하였으며, 이미지 취약점 분석, 익명 접근 차단, 네트워크 정책 설정 등 구성 외 요소를 포함한 보안 전 생애주기 관점의 접근이 특징이다. 신뢰된 이미지 사용과 실행 권한 최소화 등을 강조함으로써, 이 논문의 후속 연구에서 공급망 보안 계층 구조 설계의 간접적 이론적 기반으로 활용될 수 있다.

Nirmata(2025)[8]은 Kubernetes 환경에서의 보안 자동화 정책(OA: OPA, Kyverno 등)의 적용 효과를 비교 분석하였으며, RBAC 및 네트워크 정책의 통제 정확성과 충돌 가능성을 정량 평가하였다. 이는 본 연구의 정책 계층 설계와 도구 평가에서 유사한 기준을 제공한다.

이와 같은 선행 연구들은 Kubernetes 보안을 구성 점검, 실행 보안, 정책 통제라는 계층적 모델로 해석하고 있으며, 각각의 영역에서 실무 적용가능성이 높은 요소들을 도출하고 있다. 그러나 이러한 연구들은 대부분 글로벌 프레임워크 및 오픈소스 도구 중심의 접근에 집중되어 있으며, 국내 인증 제도(CSAP)의 실무 환경과 기준 항목에 기반한 구조적 분석은 부족한 상황이다. 본 연구는 이러한 학술적 공백을 보완하고자, 국내 CSAP의 Kubernetes 관련 항목을 중심으로 구조적 한계를 도출하고, 정책적 현실성과 적용 가능성을 갖춘 보완 체계를 제안함으로써, 기존 연구를 보완하고 국내 인증 기준 개선에 기여하고자 한다.

2.2 Kubernetes 보안을 위한 국내외 프레임워크 및 인증 기준

Kubernetes 환경의 보안 강화를 위해 다양한 글로벌 보안 프레임워크와 가이드라인이 제시되고 있으며, 이는 국내 인증 기준의 구조적 한계를 진단하고 보완 방향을 도출하는 데 중요한 비교 기준이 된다. 본 절에서는 대표적인 글로벌 보안 기준 네 가지와 국내 ISMS-P 인증 체계를 간략히 소개하고, 이들이 CSAP의 CCE 기반 점검 항목과 갖는 시사점을 중심으로 정리한다.

첫째, Center for Internet Security(CIS)[9]에서 제정한 이 벤치마크는 Kubernetes 클러스터 내 주요 컴포넌트(API Server, Controller Manager, Scheduler, Kubelet 등)에 대한 최소 보안 설정 기준을 제공한다. 각 항목은 '설정 권장사항', '적용 방법', '위험성 설명', 'Remediation 방법' 등으로 구성되며, 실무에서 바로 사용할 수 있도록 구성되어 있다. CIS Benchmark는 보안 수준에 따라 Level 1(기본 보안)과 Level 2(고강도 보안)로 구분되어 있으며, kubebench[14] 등의 오픈소스 도구를 통해 자동 점검이 가능하다. 이는 국내 CCE 항목과 유사성이 높고, 사실상 구성 기반 점검의 국제적 표준으로 활용되고 있다.

둘째, MITRE[10]는 실제 침해 사례에 기반하여 공격자의 전술(Tactics), 기법(Techniques), 절차(Procedures)를 체계화한 위협 모델링 프레임워크를 운영하고 있으며, Kubernetes 환경에 특화된 전용 Matrix도 별도로 제공하고 있다. 해당 Matrix는 Initial Access(초기 접근), Execution(명령 실행), Privilege Escalation(권한 상승), Lateral Movement(횡적 이동), Defense Evasion(탐지 회피) 등의 전술을 포함하고 있으며, 예시로는 kubelet API 노출, 악성 이미지 배포, container escape, hostPath 악용 등이 있다. 이 프레임워크는 Falco[15], Tetragon[16] 등의 런타임 탐지 도구와 연계되어 실시간 위협 탐지 및 이상 행위 분석을 가능하게 하며, 단순 구성 설정을 넘어 공격자 관점의 대응 전략 수립을 가능하게 한다.

셋째, 미국 국립표준기술연구소(NIST)[11]에서 발표한 이 문서는 컨테이너화된 애플리케이션 환경의 보안 가이드라인으로, Kubernetes 환경을 포함한 오케스트레이터 수준의 정책 기반 통제 방안을 포함하고 있다. 주요 내용으로는 이미지 무결성 검증, TLS 적용, RBAC 정책 구성, Pod 보안 정책 적용, 감사 로그 설정, 네트워크 정책 구성 등이 있으며, 특히 위험 기반 접근(Risk-Based Approach)을 통해 민감도에 따라 보안 통제 우선순위를 정하는 방식이 강조된다. 이는 조직 차원에서 정책적 접근을 구조화하는데 적합하며, 국내 인증 체계의 정책 기반 계층 설계에 정합성이 높다.

넷째, 미국 국가안보국(NSA)[12]과 사이버보안 기반시설청(CISA)이 공동으로 발표한 이 가이드는 실질적인 운영 환경에서 Kubernetes 클러스터 보안을 강화하기 위한 실무 중심의 지침을 제공한다. 주요 권장사항으로는 non-root 사용자 실행, read-only filesystem 적용, privileged 컨테이너 금지, etcd 접근 통제, RBAC 세분화, TLS 암호화 적용, 감사 로그(Audit Log) 설정, NetworkPolicy 구현 등이 있다. 또한 클라우드 매니지드 서비스(EKS, GKE 등) 에서도 적용 가능한 구체적 설정 지침을 제공함으로써, 실제 환경에서의 적용성이 매우 높다. 국내 CSAP 기준의 실효성 강화와 매니지드 환경 적용성을 높이는 데 참고 기준으로 유의미하다.

한편, 국내의 ISMS-P[13]는 민간 중심의 정보보호 및 개인정보 보호 통합 인증체계로, 시스템 보호, 접근통제, 로그 관리 등의 일반 보안 항목은 포함하고 있으나, Kubernetes 환경에 특화된 실행환경 보안, 정책 통제는 미비하다. 이에 따라 현대적 보안 요구를 충족하기 위해 보완이 필요하다.

3. 국내 CSAP의 Kubernetes 보안 항목(CCE)의 구조적 분석 및 시사점

한국인터넷진흥원(KISA)에서 운영 중인 클라우드 보안 인증 제도(CSAP)는 공공기관의 클라우드 서비스 이용 시 보안성을 평가하기 위한 기준으로, Kubernetes 환경에 대해서도 CCE(Common Configuration Enumeration) 기반 점검 항목을 제공하고 있다. 본 장에서는 이러한 CCE 항목의 구성과 점검 방식, 구조적 특성을 분석하고, 그 한계를 도출함으로써 이후 장에서 제안할 보완모델의 기반을 마련하고자 한다.

3.1 Kubernetes CCE 점검 항목 개요

Kubernetes CCE 점검 항목은 클러스터를 구성하는 마스터 노드와 워커 노드의 주요 컴포넌트에 대한 보안 설정 여부를 확인하는 항목으로 구성되어 있다. 마스터 노드는 API Server, Controller Manager, Scheduler, etcd 등의 요소를 포함하고, 워커 노드는 kubelet 및 kube-proxy 등을 중심으로 구성된다. 현재 총 24개 항목(마스터 17개, 워커 7개)은 대부분 kubeadm 기반의 초기 설치 환경을 기준으로 설계되어 있으며, 구체적인 구성 설정 여부에 따른 정적 점검 방식이 주를 이룬다.

3.2 항목 구성 방식 및 시사점

CCE 항목은 대부분 ‘특정 보안 설정이 존재하는가’, ‘보안 관련 플래그가 활성화되어 있는가’와 같은 이진 응답(yes/no) 형식의 단순 정적 점검 항목으로 구성되어 있다. 예를 들어, API Server에서 익명 접근을 제한하는 설정(--anonymousauth=false)이나, Kubelet 통신 시 인증서 기반 신뢰를 확보하는 설정(--kubelet-certificate-authority) 등이 이에 해당된다. 이러한 항목은 Kubernetes 초기 설치 이후 변경 가능성이 낮은 설정값을 중심으로 구성되어 있으며, 설정의 존재 여부 자체가 보안 상태를 대표한다고 간주하는 구조이다.

이러한 점검 항목의 형식은 CIS Kubernetes Benchmark의 Level 1 항목과 유사한 구조를 보이며, 기본적인 보안 요구사항 준수 여부를 확인하는 데에는 일정 수준의 유용성을 제공한다. 그러나 CCE는 CIS 기준과 달리 보안 수준(Level 1/2) 구분이 존재하지 않으며, 각 항목의 위험도, 적용 우선순위, 운영 환경별 적용 권장도 등의 부가정보가 부재하다. 이로 인해 보안 담당자는 모든 항목을 동일한 중요도로 취급하게 되며, 실제 환경의 자원과 위협 수준에 맞는 선별적 대응이 어렵다.

또한, CCE 항목은 대부분 kubeadm 기반의 온프레미스 환경을 전제로 하고 있어, 매니지드 Kubernetes 환경(AWS EKS, Google GKE 등)에서는 적용할 수 없는 항목이 다수 포함되어 있다. 예를 들어, API Server 실행 시 Kubelet 요청 인증을 위한 인증서 경로 지정(--kubelet-client-certificate), Controller Manager의 인증서 경로 설정(--root-ca-file), etcd 간 통신 암호화를 위한 인증서 파일 설정(--peer-cert-file) 등의 항목은 사용자가 해당 컴포넌트에 직접 접근하거나 설정을 수정할 수 없는 클라우드 환경에서는 실질적인 점검이 불가능하다. 이러한 구성 방식은 다양한 운영 환경에서의 보안 점검 요구를 충분히 반영하지 못하며, 현실적인 적용 가능성을 제한하는 요인으로 작용한다.

결과적으로, CCE 항목 구성 방식은 점검의 반복성과 단순화 측면에서는 이점이 있으나, 보안 위험도 기반의 대응 전략 수립에는 한계가 명확하며, 실질적 보안 운영에 기여하기 위해서는 위험기반 분류 체계, 정책 기반 점검 항목, 클라우드 특화 항목 등 보다 다층적인 구조로의 개선이 필요하다.

4. 글로벌 보안 프레임워크 비교 분석 및 시사점

본 장에서는 국내 CCE 기준과 글로벌 보안 프레임워크(CIS Benchmark, MITRE ATT&CK,NIST SP 800-190, NSA-CISA) 간의 항목 구성 및 적용 범위를 비교하여, 국내 기준이 포괄하지 못하는 영역과 그 원인을 도출한다.

4.1 쿠버네티스 보안 항목 비교 기준 설정

본 연구에서는 국내 CCE 기준과 글로벌 Kubernetes 보안 프레임워크 간의 비교를 위해, 구성요소의 기술적 범위와 실무 적용 가능성을 반영한 다섯 가지 평가 기준을 설정하였다. 첫째, 프레임워크가 제시하는 보안 점검 항목의 양적 범위(점검 항목 수)는 해당 기준의 커버리지를 정량적으로 판단하는 지표로 활용하였다. 둘째, 정적 설정 보안은 Kubernetes 클러스터 초기 설정 및 구성파일 기반의 보안 항목 포함 여부를 평가 기준으로 삼았다. 셋째, 런타임 보안은 클러스터 실행 중 발생 가능한 보안 위협 탐지 및 행위 기반의 대응 가능성 여부를 평가하였다. 넷째, 정책 기반 통제는 RBAC(Role-Based Access Control), PSP(PodSecurityPolicy), 네트워크 정책(NetworkPolicy) 등과 같은 Kubernetes 정책 메커니즘에 대한 점검 항목이 프레임워크에 포함되어 있는지를 기준으로 삼았다.

이러한 비교 기준은 NIST SP 800-190, CIS Benchmark, MITRE ATT&CK, NSA-CISA Kubernetes Hardening Guide 등에서 제시하는 보안계층별 접근법과 Shamim et al.(2020)[3], Darwesh et al.(2022)[7]의 실무 중심 보안 연구를 바탕으로 정립한 것이다.

4.2 쿠버네티스 보안 항목 비교 및 시사점

본 절에서는 앞서 설정한 비교 기준에 따라, 국내 CCE 기준과 글로벌 보안 프레임워크 간 보안항목의 포함 여부와 범위를 정리하였다. <표 1>은 각 프레임워크가 다루는 보안 항목의 범위를 중심으로 정리한 것이다.

<표 1> 글로벌 보안 프레임워크 보안항목 비교

CSAP의 CCE 기준은 현재 Kubernetes 클러스터의 정적 구성 점검에 초점을 두고 있으며, 다양한 보안 계층을 충분히 반영하지 못하고 있다. 본 절에서는 앞서 제시한 글로벌 보안 프레임워크(CIS Benchmark, MITRE ATT&CK, NIST SP 800-190, NSA-CISA Kubernetes Hardening Guide)와의 비교를 통해, Kubernetes 보안에서 요구되는 핵심 계층을 중심으로 CCE 항목의 구조적 한계를 네 가지 측면에서 분석하였다. 해당 측면은 ① 정적 구성 점검의 실효성, ② 런타임 보안, ③ 정책 기반 통제로, 최근 Kubernetes 환경에서 요구되는 다층 방어 구조를 기준으로 설정하였다.

첫째, 정적 구성 점검의 실효성이다. Kubernetes 보안 아키텍처의 첫 번째 계층인 정적 구성 점검(Configuration Layer)은 클러스터 초기 단계에서 주요 컴포넌트 설정 값을 검토하여 보안 기준의 준수 여부를 사전에 확보하는 과정이다. 그러나 기존의 구성 점검 방식은 실무 환경에서의 적용 가능성과 운영 효율성 측면에서 한계를 드러낸다. 주요 점검 기준인 CCE는 대부분 단순 체크리스트 형식으로 구성되어 있으며, 각 항목의 위험도나 우선순위, 적용 난이도에 대한 정량적 정보가 부족하다. 특히 클라우드 매니지드 환경에서는 컨트롤 플레인 설정 접근이 제한되어 점검 항목의 상당수가 실질적으로 적용 불가능하며, 결과적으로 구성 점검이 단순 준수 확인에 그치는 경향이 있다. 이에 따라 실질적인 보안 강화로 연결되기 위해서는, 구성 점검 항목에 대한 위험 기반 해석과 정책 연계 방안이 함께 고려될 필요가 있다.

둘째, 런타임 보안 항목의 부재이다. 현재 CCE 기준은 클러스터 구성 시점의 초기 설정 항목에 국한되어 있으며, 실행 중 발생하는 이상 행위 탐지, eBPF 기반 이벤트 분석, 로그 기반 위협 탐지 등 런타임 보안 요소는 포함되어 있지 않다. 이러한 구성은 실질적인 공격 발생 시점에 대한 대응역량을 담보하지 못하는 구조적 한계로 작용한다.

셋째, 정책 기반 통제 항목의 미흡이다. Kubernetes 보안 아키텍처에서 RBAC(Role-Based Access Control), Open Policy Agent(OPA), NetworkPolicy 등은 핵심적인 보안 통제 메커니즘으로 간주되며, 최소 권한 설정, 리소스 격리, 정책 기반 접근 제어를 가능하게 한다. 그럼에도 불구하고, 국내 클라우드 보안 인증 제도인 CSAP의 Kubernetes 취약점 진단 기준에서도 정책 통제 항목은 일부 제한적으로 포함되어 있으나, 전반적으로는 여전히 CCE/CIS 기반의 구성 설정 중심 점검에 머물러 있다. 정책 수준의 보안 요구사항을 반영하거나 자동화된 통제를 평가하는 데 한계가 있다.

이상의 분석을 통해, 현행 CCE 기준은 급변하는 클라우드 네이티브 환경과 Kubernetes 보안의 특수성을 충분히 반영하지 못하고 있는 것으로 판단된다. 이에 따라 구성 설정을 넘어서 런타임 보안, 정책 기반 통제 등을 포함한 다층 보안 구조의 반영이 필요하며, 향후에는 글로벌 보안 프레임워크와의 연계성과 실무 적용성을 고려한 점검 체계의 구조적 개선이 요구된다.

이러한 차이점은 국내 제도에서 CCE 항목을 기반으로 점검 체계를 설계할 경우, 실제 클러스터 운영 환경에서 요구되는 보안 수준과의 괴리를 야기할 수 있음을 시사한다. 따라서 CCE 항목의 적용 가능성을 평가함에 있어, CIS 등 글로벌 프레임워크와의 기술적·구조적 비교 분석을 병행하고, 보완적 관점에서의 정책 연계 또는 계층적 보안 모델 도입이 병행될 필요가 있다. 분석 결과, 국내 CCE 기준은 정적 설정 보안에 치우쳐 있으며, 글로벌 프레임워크들이 강조하는 실행환경 보안, 정책 통제 등 핵심 계층을 포함하지 못하고 있음이 확인된다.

5. 클라우드 보안 인증(CSAP)의 Kubernetes 보안 기준의 정책적 개선 방향

본 장에서는 국내 CSAP 인증 기준 내 Kubernetes 보안 항목의 구조적 한계를 보완하기 위한 정책적 개선 방향을 제안한다. 특히, 현재 구성 설정 기반의 정적 점검 항목만으로는 클라우드 네이티브 환경의 보안 요구를 충분히 충족시키기 어려우며, 글로벌 보안 프레임워크에서 강조되는 운영환경 중심의 동적 대응력, 정책 기반 통제의 일관성 등에 대한 반영이 요구된다.

따라서 본 장에서는 기존 CCE 기반 점검 구조를 유지하되, 실효성과 현장 적용성을 강화하기 위한 정책적 보완 항목군을 계층화된 구조로 제시하며, 이를 통해 점검 항목의 적용 유연성과 제도 연계 가능성을 함께 확보하고자 한다.

5.1 CSAP Kubernetes 보안 기준의 구조적 보완을 위한 점검 계층 설계

제안하는 점검 기준 보완 구조는 기존의 정적구성 설정(Configuration) 항목을 중심으로 개선‧유지하되, 그 위에 클러스터 운영 시 발생 가능한 보안 이벤트에 대한 점검(Runtime)과, 리소스 및 행위 제어 정책의 일관성과 집행 가능성을 확보하기 위한 정책 기반 통제(Policy) 항목을 보완적으로 포함하는 형태로 설계된다. 이러한 계층화는 Kubernetes 환경의 보안 요구사항을 보다 실질적으로 반영하고, 다양한 배포 방식과 클러스터 운영형태(kubeadm, 매니지드 환경 등)에 따라 점검항목의 적용 가능성을 탄력적으로 조정할 수 있도록 한다.

<표 2>는 이와 같은 구조를 요약하여 구성한 것으로, 각 보안 계층별 점검 목적과 대상 항목의 예시를 정리하고 있다.

<표 2> CSAP의 Kubernetes 보안 기준에 대한 다층 보안 점검 체계

5.1.1 정적 구성 점검 (Configuration Layer) 개선

Kubernetes 보안 아키텍처의 첫 번째 계층인 정적구성 점검(Configuration Layer)은 클러스터 초기 단계에서 주요 컴포넌트의 보안 설정을 정량적으로 검토하여 보안 기준 준수 여부를 사전에 확보하는 절차이다. 이 계층에서는 Common Configuration Enumeration(CCE) 및 Center for Internet Security(CIS) Kubernetes Benchmark에서 제시하는 항목을 기준으로, API Server, Controller Manager, etcd, Kubelet 등 주요 컴포넌트의 설정 상태를 점검한다.

예를 들어, API Server는 클러스터 요청의 진입 지점으로서 보안 설정의 중요도가 높으며, 익명 접근 차단(--anonymous-auth=false), 노드 및 역할 기반 권한 부여 설정(--authorization-mode=Node,RBAC), 감사 로그 기록 설정(--audit-log-path) 등이 필수적으로 요구된다. 이러한 항목이 부재하거나 부적절하게 설정될 경우, 인증되지 않은 접근자에 의해 시스템이 침해될 위험이 존재한다.

Controller Manager는 종료된 Pod를 자동으로 정리하기 위한 임계값 설정(--terminated-pod-gc-threshold)과 성능 프로파일링 비활성화 설정(--profiling=false)을 통해 불필요한 자원 노출을 방지하며, etcd는 클러스터 상태 정보를 저장하는 핵심 저장소로서 클라이언트 인증 강제(--client-cert-auth=true), 인증서 파일 지정(--peer-cert-file), 자동 TLS 생성을 방지하는 설정(--auto-tls=false) 등을 통해 기밀성과 무결성을 유지한다.

Kubelet은 워커 노드에서 Pod를 관리하는 컴포넌트로, 익명 접근 차단(--anonymous-auth=false), 읽기 전용 포트 비활성화(--read-only-port=0), 외부 인증 서버를 통한 권한 검증(--authorization-mode=Webhook) 등을 통해 불필요한 API 접근을 차단하고 공격 표면을 최소화한다.

하지만 이러한 구성 점검 방식은 실무 환경, 특히 클라우드 매니지드 환경에서 다음과 같은 한계를 갖는다. 첫째, 대부분의 CCE 항목은 예/아니오 형식의 단순 체크리스트로 구성되어 있으며, 각 항목에 대한 위험도, 적용 우선순위, 운영 난이도 등의 메타 정보가 부재하다. 이로 인해 실무자는 자원 및 위협 수준에 따른 선별적 대응이 어렵고, 점검 결과를 기반으로 한 보안 전략 수립이 제한된다.

둘째, 클라우드 매니지드 환경(AWS EKS, GKE 등)에서는 API Server, Controller Manager, etcd 등 컨트롤 플레인 컴포넌트에 대한 사용자 접근이 제한되어 있어, 기존 점검 항목 중 상당수가 실질적으로 적용이 불가능하다. 이는 CCE가 온프레미스 환경을 전제로 설계된 결과로, 다양한 운영 환경을 반영하지 못하는 구조적 제약이 존재한다.

셋째, 현재의 구성 점검은 단순 설정 유무 확인에 그치며, 점검 결과를 정책 수립, 시정 조치, 운영 프로세스 개선 등 실질적인 보안 활동으로 연계하기 어렵다. 이는 위험 기반 대응을 위한 정보 해석력과 정책적 연계성을 갖추지 못한 구조적 한계로 작용한다.

이러한 문제를 해결하기 위해 다음과 같은 정책적 개선이 필요하다. 첫째, 점검 항목에 대해 위험도 기반 분류 체계를 도입하고, 보안 영향도, 적용 난이도, 우선순위 등의 메타정보를 명시하여 실무자의 적용 효율성을 높여야 한다. 둘째, 온프레미스와 매니지드 환경을 명확히 구분하고, 사용자 통제 가능 영역(PodSecurity, RBAC, NetworkPolicy 등)을 중심으로 한 클라우드 특화 기준이 마련되어야 한다. 셋째, 점검 결과를 기반으로 한 정책 수립, 시정 조치 가이드라인, 보안 운영 프로세스와의 연계 방안이 제도화되어야 한다. 마지막으로, CIS Benchmark, NIST SP 800-190, NSA-CISA Hardening Guide 등 국제 기준과의 정합성을 확보하고 이를 통합 참조 체계로 반영함으로써 국내 기준의 신뢰성과 적용성을 동시에 향상시킬 필요가 있다.

아울러, 점검의 반복성과 정확성을 확보하기 위해 kube-bench, SLI-KUBE 등의 오픈소스 도구를 활용한 자동화 기반 정적 점검 체계 구축도 병행되어야 하며, 이는 DevSecOps 파이프라인과 연계될 경우 보안의 사전 예방 효과를 더욱 극대화할 수 있다.

5.1.2 실행환경 보안 점검 (Runtime Layer)

실행 환경 보안(Runtime Security Layer)은 Kubernetes 클러스터의 운영 중 발생할 수 있는 비정형 공격 및 이상 행위(anomalous behavior)를 실시간으로 탐지하기 위한 보안 계층이다. 이는 클러스터 실행시점에서 발생하는 이벤트를 기반으로, 사전 구성된 보안 정책이나 정적 점검만으로는 탐지하기 어려운 동적 위협을 식별하는 데 핵심적인 역할을 수행한다.

실행 환경에서 탐지할 수 있는 대표적인 이상 행위 유형은 다음과 같다. 첫째, 컨테이너 탈출(container escape) 시도로, 이는 컨테이너 경계를 벗어나 호스트 OS에 접근하려는 공격 유형이며, /proc/kcore, /etc/shadow, /var/run/docker.sock 접근 등이 해당된다. 둘째, 비인가 셸 접근 및 명령어 실행으로, bash, sh, curl | sh, wget 등 의심스러운 명령이 컨테이너 내부에서 실행되는 경우다. 셋째, 비정상 네트워크 호출로, 이는 외부 C2(Command and Control) 서버 연결, 내부 lateral movement, DNS tunneling 등의 행위로 나타난다. 넷째, Linux Capabilities 요청 및 setuid 설정 변경 등 권한 상승 행위 역시 주요 탐지 대상이다. 이러한 런타임 행위는 MITRE ATT&CK for Containers 프레임워크의 전술(Tactics) 및 기법(Techniques)에 매핑될 수 있으며, 특히 T1609(Container Administration Command), T1611(Escape to Host), T1059(Command and Scripting Interpreter) 등이 Kubernetes 환경에서 빈번하게 나타나는 공격 기술로 보고되고 있다.

실행 환경 보안 계층에서의 위협 탐지 체계는 크게 다섯 단계로 구성된다. 첫째, eBPF(Event Collector)를 활용하여 클러스터 내부의 시스템 호출, 파일 접근, 네트워크 연결, 프로세스 실행 등 런타임 수준에서 발생하는 이벤트를 실시간으로 수집한다. 이 수집기는 커널 수준에서의 가시성을 확보할 수 있도록 설계되며, 컨테이너 내에서 발생하는 비정상 행위를 누락 없이 포착하는 데 목적이 있다.

둘째, 수집된 이벤트는 행위 분석기(Behavioral Analyzer)로 전달되며, 이 분석기는 룰 기반(static rule-based engine) 또는 머신러닝 기반 모델로 구성될 수 있다. 룰 기반 방식은 사전에 정의된 시그니처 또는 조건과의 일치 여부를 판단하며, 머신러닝 기반 방식은 정상/비정상 행위를 학습하고 이상값으로 판단되는 이벤트를 탐지한다.

셋째, 분석된 행위 정보는 MITRE ATT&CK 프레임워크의 TTP(Tactics, Techniques, and Procedures) 항목에 매핑된다. 이 매핑 과정은 단일 이벤트에 그치지 않고, 공격자의 행위 흐름을 식별하고 해당 행위가 침투, 실행, 권한 상승, lateral movement, 영향(Impact) 중 어느 단계에 해당하는지를 분류한다.

넷째, 식별된 위협은 자동으로 탐지 보고서(detection report) 형태로 생성되며, 해당 보고서는 보안 운영자 또는 자동화 시스템이 대응 결정을 내릴 수 있도록 상세한 로그, 이벤트 시점, 관련 리소스, 적용된TTP ID 등을 포함한다.

마지막으로, 보고된 위협은 사전에 정의된 시나리오 기반 대응 매트릭스(response matrix)에 따라 자동 경고(Alert), 프로세스 종료(Kill), 네트워크 차단(Block), 관리자 통보 등의 조치로 연계된다. 이 대응은 Falco[14]의 webhook 알림, Tetragon의 능동 제어(Active Enforcement) 기능 등으로 자동화될 수 있으며, 이를 통해 클러스터 보안의 실시간성과 민첩성이 동시에 확보된다.

이러한 자동 대응은 특히 Falco와 Tetragon 같은 오픈소스 도구를 통해 구현 가능하다. Falco는 CNCF(Cloud Native Computing Foundation)의 공식 인증 프로젝트로, Kubernetes 런타임 위협 탐지를 위한 사실상 표준 도구로 자리잡고 있다. Falco는 eBPF 또는 syscall 기반으로 이벤트를 감시하며, Webhook을 통해 경고를 전송하거나, Syslog/SIEM 시스템과 연동하여 보안 관제 체계와의 자동화 연계가 가능하다. 이를 통해 실시간 경고를 SOC(Security Operations Center)로 전달하고, 보안 운영 자동화를 강화할 수 있다.

Tetragon은 이벤트 수집 외에도 능동적 제어(active enforcement) 기능을 지원하여, 탐지된 위협에 대해 정책 기반의 즉각적 차단 또는 프로세스 종료 조치를 자동 수행할 수 있다.

실시간 런타임 탐지 기술의 효과성은 Aly et al.(2025)[5]의 연구에서도 실증되었다. 이들은 KServe 기반 머신러닝 모델을 통해 DDoS, 권한 상승, reverse shell 등 다양한 공격 유형을 실시간 분류하고, KubeDeceive를 통해 공격자를 디코이(decoy) 리소스로 유도하는 프레임워크를 제안하였다. 실험 결과, 탐지 정확도는 91%, 디코이 유인 성공률은 93%에 달하였으며, 이는 런타임 보안 기술이 탐지와 방어의 통합된 접근 방식으로 진화하고 있음을 보여준다.

이와 같이, 실행 환경 보안 계층은 Kubernetes 클러스터의 실시간 동작 상태를 기반으로 정적 구성 점검과 정책 기반 통제로는 대응이 어려운 비정형 위협에 대해 탐지 및 대응 능력을 확보할 수 있으며, 클러스터 전체 보안성의 실효성을 높이는 데 기여한다.

5.1.3 정책 기반 통제 점검 (Policy Layer)

정책 기반 통제(Policy Enforcement)는 Kubernetes 보안 체계의 마지막 계층으로, 클러스터 내부 리소스에 대한 접근 권한 및 실행 조건을 세부적으로 정의하고 이를 일관되게 적용함으로써, 클러스터 보안의 실효성과 규정 준수(Compliance)를 확보하는 데 핵심적인 역할을 한다. 본 계층은 단순한 구성 상태의 존재 유무 확인을 넘어, 정책이 실제 운영 환경에 적용되고 있으며, 위반 리소스에 대한 자동 차단 또는 수정 조치가 수행되는지를 포함하여 종합적으로 평가하는 것을 목표로 한다.

Kubernetes는 본질적으로 선언형(Declarative)리소스 모델을 기반으로 하기 때문에, 클러스터 내 리소스가 어떻게 생성되고, 어떤 조건 하에 운영되어야 하는가에 대한 정책을 명확히 정의하고, 이를 강제하는 메커니즘의 도입이 필수적이다. 정책 통제는 일반적으로 다음의 세 가지 축으로 구성된다.

첫째, 접근 통제(Access Control)이다. API 서버를 통해 특정 리소스에 접근하거나 조작할 수 있는 권한은 역할 기반 접근 제어(Role-Based Access Control, RBAC)를 통해 관리되며, 이는 최소 권한 원칙(Principle of Least Privilege)을 실현하고, 사용자 및 서비스 계정의 권한을 세분화하는 기반이 된다.

둘째, Pod 수준의 실행 조건 제어이다. 컨테이너는 기본적으로 높은 권한을 가질 수 있으므로, 보안 취약점을 방지하기 위해 비루트 사용자 실행, 호스트 네트워크 및 네임스페이스 접근 제한, 리소스 제한 설정 등 실행 조건을 정책으로 명확히 정의해야 한다.

셋째, Admission 단계의 정책 검증 및 거부 처리이다. 사용자가 리소스를 API 서버에 제출할 때, 사전에 정의된 정책을 기반으로 리소스를 실시간 평가하고, 위배될 경우 이를 자동 거부하거나 수정하는 구조가 필요하다. 이러한 Admission Control 기반의 정책 적용 구조는 단순한 정책 선언을 넘어, 실제 운영환경에서의 자동 적용(enforcement) 가능성을 평가하는 핵심 기준이 된다.

이 논문에서는 이러한 정책 기반 통제를 다층 점검체계의 마지막 계층으로 정의하며, 클러스터 보안 정책이 선언된 수준에 머무르지 않고, 실질적으로 운영환경에 자동 적용되고 통제력이 유지되고 있는지를 구조적으로 점검하는 방향을 제시한다. 특히, 정책의 존재 여부뿐 아니라, 행위 제한 효과, 위반 리소스 처리 방식, 정책 충돌 방지 및 일관성 유지 메커니즘까지 포함한 종합적 정책 평가 체계로 접근할 필요가 있다.

이를 위해 이 논문은 정책 기반 통제 계층의 구현방안으로 Kyverno[17]와 OPA(Open Policy Agent)[18]를 제시한다. Kyverno는 Kubernetes 네이티브 정책 엔진으로 YAML 기반 직관적 정책 정의가 가능하며, 정책 위반 시 자동 수정(mutate), 거부(deny), 감사(audit)의 세 가지 실행 모드를 제공한다. 반면, OPA는 보다 정교한 정책 표현이 가능한 Rego 언어 기반의 정책 엔진으로, 복잡한 조건 로직 구현 및 외부평가 로직 연동이 가능하다는 장점이 있다.

이러한 도구들은 단순히 정책이 존재하는지를 확인하는 데 그치지 않고, 실제로 클러스터에 적용되어 정책 위반 리소스를 자동으로 차단하거나 수정하는 기능을 수행함으로써, 선언적 정책의 자동 적용 여부를 검증하는 핵심 도구로 기능한다. 이 논문은 Kyverno 및 OPA 기반 정책 적용 흐름과 실행 예시를 구조화하여, 자동화 기반 점검 체계로서의 정책 계층 구현 가능성과 실효성을 함께 제시한다.

결론적으로, 정책 기반 통제 계층은 클러스터 보안의 마지막 방어선이자, 보안 거버넌스 실현을 위한 핵심 기제로 작용하며, 점검 체계의 정합성과 확장 가능성을 확보하는 데 중요한 역할을 수행한다.

5.2 적용 방안

본 연구에서 제안한 Kubernetes 다층 보안 점검 체계는 기존의 CSAP 내 점검 프레임워크를 전면적으로 대체하려는 접근이 아니다. 오히려, 정적 구성 중심의 CCE(Common Configuration Enumeration) 기반 항목을 보완하고, 동적 위협 대응 및 정책 집행 수준까지 포함하는 확장형 점검 체계로서의 역할을 지향한다.

이에 따라 본 체계의 적용은 선택형 항목 또는 가점 항목(Optional or Incentive-Based Category)으로 우선 도입하는 방식이 적절하다. 이러한 점진적 적용 전략은 다음과 같은 측면에서 정책적 현실성과 실무적 유연성을 동시에 만족시킨다.

첫째, 기존 CSAP 인증 심사 체계는 법적 근거 및 인증 실무의 형식적 절차가 이미 고정화되어 있어, 새로운 점검 항목의 전면 도입은 심사 운영 부담과 수검 기관의 준비 부담을 초래할 수 있다. 그러나 선택형 또는 가점 항목으로의 도입은 제도 내 저항 없이 추가적인 보안 역량 확보를 유도할 수 있으며, 실제로 점검 항목의 실효성(탐지 정확도, 위반 발생률 감소 등)을 시범 적용을 통해 검증할 수 있는 장점이 있다.

둘째, 선택형 항목으로 도입된 항목이 일정 기간 동안 유의미한 효과를 입증하고, 다양한 운영 환경(EKS, GKE, kubeadm, 온프레미스 등)에서 적용 가능성이 확인될 경우, 향후 필수 점검 항목으로의 단계적 전환도 가능하다. 이와 같은 ‘시험적 도입 → 효과 입증 → 제도화’ 구조는 과거 ISMS-P 항목 개편 과정에서 이미 유사한 선례가 존재하며, 행정적 수용성을 확보한 정책 모델이다.

셋째, 운영 측면에서는 수작업 기반 점검의 비효율성과 오류 가능성을 해소하기 위해, 정책 정의–점검 실행–결과 보고서 생성을 자동화할 수 있는 경량화된 구조를 제시하는 것이 바람직하다. 특히, 리소스 구성 점검, 실행 중 행위 감시, 보안정책 위반 차단 등을 체계화한 스크립트 및 정책 템플릿은 점검 일관성 확보와 심사자–심사대상자간의 해석 차이를 줄이는 데 기여한다. 이 과정에서 사용되는 도구는 특정 오픈소스를 고정적으로 채택하기보다는, 다양한 기술 생태계를 수용할 수 있는 유연한 구조로 제시되어야 하며, 도구 사용 여부는 각 기관의 클러스터 구성, 예산, 기술 역량에 따라 자율적으로 선택할 수 있도록 하는 것이 제도적 수용성 측면에서 바람직하다.

또한, 자동화 기반 점검은 인증 기관의 입장에서도 다음과 같은 운영상 이점을 제공한다. 첫째, 반복 점검 항목에 대한 자동화 수행은 심사자의 수작업 부담을 줄이고, 항목 간 누락 또는 중복점검을 방지하여 점검의 신뢰성을 높일 수 있다. 둘째, 표준화된 점검 보고서 양식과 로깅 구조의 활용은 심사 이후 피드백 및 후속 평가에 필요한 근거를 자동 확보함으로써 인증 심사의 투명성을 향상시킨다. 셋째, 심사 대상자의 사전 점검 능력을 강화하여, 인증 준비 기간을 단축시키는 효과도 기대할 수 있다.

결론적으로, 본 점검 체계는 기존 CSAP 인증 구조의 근간을 건드리지 않으면서도, 국내 클라우드 보안 인증이 직면한 구성 편향성, 런타임 사각지대, 정책 일관성 부족 문제를 실무적으로 해결할 수 있는 현실적 대안으로 작용할 수 있다. 특히 점진적 도입 모델과 자동화 기반 점검 구조의 병행 적용은, 단기적으로는 제도적 저항 없이 기능 향상을 달성하고, 장기적으로는 인증 신뢰성과 글로벌 정합성 확보라는 두 마리 토끼를 동시에 추구할 수 있는 전략적 방향이 될 것이다.

5.3 기대 효과

제안된 다층 보안 점검 체계는 Kubernetes 기반 클라우드 환경의 전 주기 보안을 실현하기 위한 구조로, 구성 설정–실행환경 보안–정책 기반 통제에 이르는 다층 보안 커버리지를 제공한다. 이는 기존 CCE 기준이 정적 구성 점검에 국한되어 있었던 한계를 보완하고, Kubernetes 클러스터의 운영 전반을 포괄하는 실질적인 보안 점검체계로 기능할 수 있다.

아울러 본 점검 체계는 CIS Kubernetes Benchmark, NIST SP 800-190, MITRE ATT&CK for Containers 등 주요 국제 보안 프레임워크와의 구조적 정합성을 고려하여 설계되었으며, 이를 통해 국내 인증 기준이 국제 기준과의 기술적 호환성과 상호 인정 가능성을 확보할 수 있는 기반을 제공한다.

특히, 본 체계는 ISMS-P(정보보호 및 개인정보보호 관리체계 인증)의 기술적 보호조치 항목과도 연계 가능성이 높다. 현재 ISMS-P는 Kubernetes와 같은 클라우드 네이티브 환경에 특화된 점검 항목이 미비하다는 지적이 있으며, 본 연구의 다층 보안 점검 체계는 ISMS-P의 점검 기준 확장 또는 보완 항목으로도 적용 가능성을 갖는다. 이는 CSAP과 ISMS-P 간의 기준 정합성 확보 및 상호 보완적 구조 구성에도 기여할 수 있을 것으로 기대된다.

6. 결론

본 연구는 국내 클라우드 보안 인증 제도(CSAP)에서 활용 중인 CCE 항목의 Kubernetes 보안 기준이 정적 구성 설정에 편중되어 있으며, 실행 환경 보안, 정책 통제 등 클라우드 네이티브 환경의 핵심 보안 요소를 반영하지 못하고 있다는 한계를 진단하였다.

CCE 항목은 kubeadm 기반 초기 설치 환경을 전제로 하며, 클라우드 매니지드 환경(EKS 등) 적용의 어려움, 자동화 연계 미비, 실효성 부족 등의 한계를 가진다. 이에 따라 본 연구는 CIS Benchmark, MITRE ATT&CK, NIST SP 800-190, NSA-CISA 등 국제 보안 프레임워크를 비교·분석하고, 정적 구성, 실행 보안, 정책 통제를 포함한 다층 보안 점검 체계를 제안하였다. 제안된 모델은 kube-bench, Falco, Kyverno 등의 오픈소스 도구와 연계를 통해 정량적 점검 자동화가 가능하며, 국내 인증제도의 현실과 적용성을 고려한 점진적 보완안으로 기능할 수 있다. 또한 본 체계는 국제 기준과의 정합성 확보, 수작업 점검의 한계 극복, 클라우드 환경 적용성, 대응력 강화 등 다양한 정책적 실효성을 갖는다. ISMS-P와의 연계 가능성 또한 높아, 국내 인증제도 간 상호 보완 구조 확립에도 기여할 수 있다.

본 연구에서 제시한 Kubernetes 보안 다층 점검 체계는 정적 구성, 실행 환경, 정책 통제 보안을 중심으로 구성되며, 이는 단순한 설정 확인을 넘어 운영 전반에 보안을 내재화한 구조로 확장 가능하다. 특히 이러한 구조는 DevSecOps 실현을 위한 기술적 기반으로 기능할 수 있으며, 향후 Kubernetes 기반 보안 인증은 단순 준수 점검을 넘어 DevSecOps 프레임워크로의 진화를 요구받게 될 것이다. 후속 과제로는 정량적 점검 도구의 적용, 단계적 도입 전략 수립, 클라우드 환경별 적용 가능성 검토, 시범 적용을 통한 제도 반영 검증 등이 제시된다. 결론적으로 본 연구는 Kubernetes 환경에 적합한 보안 인증 기준의 기술적·정책적 방향을 제시함으로써, 향후 CSAP 고도화 및 국내 인증 제도의 국제 정합성 확보에 기여할 수 있을 것으로 기대된다.