아톤 “쿠버네티스 보안, 애플리케이션 단위로 통합 관리해야”

클라우드 네이티브 전환과 함께 쿠버네티스 운영이 늘면서, 설정 오류와 오픈소스 취약점 같은 문제가 보안 과제로 떠오르고 있다. 보안 기업 아톤은 22일 바이라인네트워크와 진행한 웨비나에서 쿠버네티스 보안 대응 방안을 공유하며 애플리케이션 단위 통합 보안 관리 전략을 제시했다.

이날 웨비나에서 정현석 아톤 시큐리티센터장은 “인공지능(AI)과 클라우드 확산으로 쿠버네티스가 핵심 인프라로 자리 잡았지만, 보안 표준과 현장 모범사례는 여전히 부족하다”며 “컨테이너 환경에서는 개별 보안 솔루션을 따로 도입하는 방식만으로 구조적 문제를 해결하기 어렵다”고 말했다.

쿠버네티스는 컨테이너 기반 애플리케이션을 자동으로 배포·확장·관리하는 오픈소스 플랫폼이다. 컨테이너는 생성과 삭제가 빠르고 구성 요소가 많다. 이 특성 때문에 자산을 계속 추적하기 어렵고, 설정 하나가 노출로 이어지기 쉽다.

아톤은 이같은 보안 환경 변화와 맞물려 소프트웨어 공급망 공격도 커졌다고 진단했다. 공급망 공격은 오픈소스 패키지나 라이브러리 취약점을 악용해 여러 소프트웨어로 피해가 번지는 방식이다. 하나의 취약점이 연쇄적으로 확산해 많은 조직에 영향을 줄 수 있다. 쿠버네티스 환경에서는 컨테이너 이미지가 배포 단위가 된다. 이미지 안에 오픈소스 패키지와 라이브러리가 함께 들어가다 보니, 공급망 취약점이 곧바로 운영 환경으로 이어질 수 있다.

정 센터장은 컨테이너 환경의 상당수가 취약한 상태로 운영되고, 클라우드 보안 사고의 대부분이 설정 오류 같은 사용자 실수에서 비롯된다는 점도 문제로 들었다. 그는 “컨테이너 이미지 취약점, 쿠버네티스 설정 오류, 실행 중 발생하는 런타임 위협을 각각 따로 관리하면 전체 보안 상태를 파악하기 어렵기에 해법이 필요하다”고 설명했다.

쿠버네티스 환경의 8가지 보안 위협

정 센터장은 위협이 늘었다는 수준을 넘어 운영 구조 자체가 보안에 불리하게 바뀌고 있다고 강조했다. 우선 취약점이 폭증했다. 그는 “2025년에만 4만8000개의 공통 취약점 및 노출(CVE)이 발견됐다”며 “취약점이 늘어날수록 보안팀이 ‘높음 이상’에 해당하는 위협만 추려도 처리량이 감당되지 않는다”고 설명했다.

오픈소스를 많이 사용하는 환경도 위협을 키우고 있다. 오픈소스는 개발 속도를 높이지만, 어떤 구성 요소를 썼는지 정리가 안 돼 있으면 취약점이 나왔을 때 영향 범위를 계산하기 어렵다. 그 사이 알려진 취약점이 노출된 시간이 길어지고 공격자들은 이 틈을 노린다.

컨테이너 도입이 빠르게 늘어난 점도 변수다. 컨테이너는 보안 관점에서 ‘이미지(패키지)’, ‘설정(클러스터 구성)’, ‘실행 중 행위(런타임 이벤트)’가 동시에 움직인다. 그런데 현장에서는 이미지 취약점, 쿠버네티스 구성 취약점, 런타임 위협을 한 시야에서 엮어 보기 어렵다. 한 영역만 점검하면 다른 것에 빈틈이 생길 수 있다.

클라우드 사고가 설정 오류에서 시작되는 점도 지적됐다. 권한을 과하게 주거나 외부 노출을 허용하는 설정이 남아 있으면 공격자는 이곳을 파고든다. 정 센터장은 이를 “전문성 부족과 보안 정책 부재가 만든 구조적 문제”라고 설명했다.

책임이 분산되는 구조도 문제다. 소프트웨어·컨테이너·클라우드 중 어디에서 문제가 시작됐는지에 따라 담당자가 나뉘면, 누가 무엇을 언제까지 고칠지가 명확해지지 않는다. 개발자는 보안을 자신의 업무로 받아들이지 않기 쉽고, 보안 담당자는 개발·운영 맥락을 모르면 우선순위를 잡기 어렵다는 설명이다.

여기에 마이크로서비스 아키텍처(MSA)와 데브옵스(DevOps)이 확산이 복잡성을 더한다는 점도 있다.. 애플리케이션이 잘게 쪼개지고, 컨테이너 생성·소멸 주기가 짧아지면서 기존 보안 체계로는 감지와 추적이 어려워진다. 정 센터장은 “컨테이너가 만들어진 지 5분 만에 사라지는 환경도 있다”고 말했다.

규제 강화도 부담이 되는 지점이다. 공공 납품이나 수출 과정에서 개발환경·오픈소스·컨테이너까지 보안에 문제가 없다는 것을 증명해야 하지만, 이를 뒷받침할 프레임워크와 기술은 부족하다. 이에 점검 결과를 토대로 추적할 수 있는 체계가 필요해진다는 취지다.

마지막으로는 도구가 분산되어 있다는 점이 문제로 꼽혔다. 소프트웨어 보안 도구가 여러 개로 쪼개져 각자 따로 운영되면 위협에 대한 알림이 흩어지고, 같은 문제를 서로 다른 화면에서 반복해서 확인하게 된다. 이러면 피로도가 커지고 조치하는 속도는 떨어진다는 설명이다.

애플리케이션을 보안의 기준 단위로 묶어야

이러한 문제 속에서 아톤이 제시한 해법은 ‘애플리케이션 중심의 보안 단위’다. 쿠버네티스에서 애플리케이션을 구성하는 워크로드, 네트워크, 권한, 스토리지 같은 리소스를 한 덩어리로 묶어 보안을 평가·관리하는 방식이다. 애플리케이션을 기준으로 봐야 무엇이 위험한지 한눈에 들어오고, 담당자에게 바로 전달할 수 있다는 것이 아톤측 설명이다.

정 센터장은 쿠버네티스 보안을 ▲구성 오류 ▲오픈소스 취약점 ▲런타임 위협 세 가지로 나눠 함께 점검해야 한다고 강조했다. 먼저 ‘구성 오류’는 외부 노출 설정, 과도한 권한, 네트워크 통제 미흡처럼 잘못 설정해서 생기는 위험이다.

‘오픈소스 취약점’은 컨테이너 이미지에 포함된 패키지·라이브러리에서 발견되는 CVE를 뜻한다. ‘런타임 위협’은 실행 중인 컨테이너 내부에서 비정상 행위가 발생하는지를 보는 영역이다. 예를 들어 컨테이너에 쉘로 접속하거나 민감 파일에 접근하는 행위, 의심스러운 외부 통신 시도 같은 이벤트가 여기에 포함된다.

아톤은 이 개념을 구현한 플랫폼으로 ‘오르빗 시큐리티(Orbit Security)’를 제시했다. 오르빗 시큐리티는 애플리케이션을 더 작은 단위인 ‘컴포넌트’로 나누고, 컴포넌트별 보안 점수를 산정해 개발자와 보안 담당자가 같은 기준으로 취약점을 확인하도록 설계했다.

정 센터장은 “개발자, 보안 담당자, 최고정보보호책임자(CISO)가 각자 다른 도구와 관점으로 보안을 바라보면 책임이 분산된다”며 “애플리케이션 단위를 기준으로 보안을 수치화하고 담당자를 명확히 지정해야 대응 속도를 높일 수 있다”고 말했다.

또 “조직이 따라야 할 컴플라이언스를 기준으로 보안 정책을 만들고, 점수로 상시 점검해야 한다”고 덧붙였다. ISO 27001이나 정보보호 관리체계(ISMS) 같은 인증 기준을 점검 항목으로 바꾸고, 현장 설정과 실행 상태를 실시간으로 대조해야 한다는 것이다.

데모로 ‘점수화·원인 추적·조치 흐름’ 공개

아톤은 오르빗 시큐리티의 데모도 공개했다. 화면은 역할에 따라 달랐다. 개발자 화면에서는 자신이 맡은 애플리케이션과 컴포넌트의 종합 점수를 보여주고 위험 요인을 구성 오류·이미지 취약점·런타임 이벤트로 나눠 원인을 짚었다. 특정 컴포넌트를 선택하면 어떤 패키지에서 취약점이 나왔는지, 심각도는 어느 정도인지, 어떤 버전으로 올리면 해결되는지까지 가이드를 제시했다.

쿠버네티스 설정 전담 화면에서는 워크로드·네트워크·스토리지 같은 리소스의 설정 오류를 탐지해 보여줬다. 예를 들어 과도한 권한을 허용하는 설정이 있으면 해당 설정 위치를 함께 제시해 수정 포인트를 좁혔다.

런타임 영역에서는 컨테이너 내부에서 발생한 이벤트를 시간 흐름에 따라 확인하고, 정책 위반 이벤트를 ‘인시던트’로 묶어 담당자에게 전달하는 모습을 시연했다. 인시던트는 경고나 정책 위반 이벤트를 조치해야 할 사건으로 묶어 티켓화하고, 담당자와 처리 기한을 지정해 진행 상태를 추적하는 단위를 뜻한다.