일부 전문가들 “클라우드, 클러스터, 컨테이너, 코드” 보안 강조
‘안전한 워크로드 실행, 컨테이너 취약점 스캔, 애플리케이션 코드 보안’ 등

클라우드 기반의 빌드 도구로서 본문 기사와는 직접 관련이 없음. (사진=IAR)
클라우드 기반의 빌드 도구로서 본문 기사와는 직접 관련이 없음. (사진=IAR)

[애플경제 전윤미 기자] 클라우드에만 존재하도록 특별히 설계된 애플리케이션 또는 전체 인프라 환경인 ‘클라우드 네이티브’ 보안이 특히 강조되고 있다. 특히 이에 대해 일부 전문가들은 클라우드(Cloud), 클러스터(Cluster), 컨테이너(Container)와 코드(Code) 등 ‘4C’를 그 핵심으로 제시하고 있다.

사이버보안업체 이글루코퍼레이션은 최근 “클라우드 계층이 취약하거나 취약한 방식으로 구성된 경우, 이 기반 위에서 구축된 구성 요소가 안전하다는 보장은 없다. 각 클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기 위한 보안 권장 사항을 제시하고 있다”면서 보안 권장사항을 구체적으로 소개하고 있어 눈길을 끈다.

이 회사 IT사업본부 원격관제팀의 연준모 연구원은 “여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한 신뢰 컴퓨팅 기반(trusted computing base)”이라며 이같이 밝혔다.

앱 공격 영역에 따른 클러스터 보안

그에 따르면 클라우드 보안을 위한 클러스터의 경우, 워크로드를 안전하게 실행하기 위한 보안이 중요하다.

즉, “애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 중점을 둘 수 있다.”면서 “예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와, 리소스를 소진하는 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, 서비스 B의 리소스를 제한하지 않으면 서비스 A가 손상될 위험이 높다.”고 경고했다.

이에 쿠버네티스에서 실행되는 워크로드를 보호하기 위한 보안이 중요하다는 조언이다.

워크로드 보안을 위해 고려할 영역 중엔 우선 ▲RBAC 인증, 즉 쿠버네티스 API에 대한 접근과 ▲인증, ▲애플리케이션 시크릿 관리와 유휴상태에서의 etcd 암호화 등이 있다. 또 ▲파드 시큐리티 설정을 확인하고 ▲서비스 품질과 클러스터 리소스 관리, ▲네트워크 정책 ▲쿠버네티스 인그레서를 위한 TLS 등이 있다.

컨테이너 보안 위한 4가지 부문

다음으론 ‘컨테이너’ 부문의 보안이다. 이를 위해 컨테이너에서 고려할 영역은 ▲컨테이너 취약점 스캔 및 OS에 종속적인 보안, ▲이미지 서명 및 시행, ▲권한있는 사용자의 비(非)허용 등이다.

그 중 ▲컨테이너 취약점 스캔 및 OS에 종속적인 보안을 위해 이미지 빌드 단계의 하나로 컨테이너에 알려진 취약점이 있는지를 반드시 검사해야 한다. 또 ▲이미지 서명 및 시행의 경우는 컨테이너 이미지에 서명, 컨테이너의 내용에 대한 신뢰 시스템을 유지하는게 중요하다. 또 ▲권한있는 사용자의 비(非)허용은 컨테이너를 구성할 때 그 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너에 만들되, 그 방법에 대해선 설명서를 참조하도록 하는 것이다.

클라우드 기반의 IaaS 시설로서 본문 기사와는 직접 관련이 없음. (사진=더존비즈온)
클라우드 기반의 IaaS 시설로서 본문 기사와는 직접 관련이 없음. (사진=더존비즈온)

앱 보안 위한 5가지 방안

다음으로 안전한 ‘코드’가 중요하다. 특히 애플리케이션 코드는 가장 많은 제어를 할 수 있는 주요 공격 영역 중 하나이다. 연 연구원은 “애플리케이션 코드 보안은 쿠버네티스 보안 주제를 벗어나지만, 애플리케이션 코드를 보호하기 위한 방안은 대략 5가지로 분류된다”고 제시했다.

우선은 TLS를 통한 접근이 있다. 이는 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 세이크를 수행하는 것이다. 대체로 이는 전송 중인 모든 것을 암호화한다. 나아가서 서비스 간 네트워크 트래픽을 암호화하는 것이 바람직하다는 권고다. 또 인증서를 갖고 있는 두 서비스의 양방향 검증을 실행하는 mTLS를 통해 수행할 수 있다.

코드 보안을 위해선 통신포트 범위를 제한하는 방법도 있다. 이는 당연한 것일 수도 있지만, 가능하면 통신이나 매트릭 수집에 꼭 필요한 서비스의 포트만 노출시키는게 옳다.

타사 종속성으로 인한 보안 문제도 중요하다. 즉, 애플리케이션의 타사 라이브러리를 정기적으로 스캔, 현재 알려진 취약점이 없는지 확인하는 방법을 모색해야 한다. 각 언어에는 이런 검사를 자동으로 수행하는 도구가 있다.

‘정적 코드’를 분석하는 것도 중요하다. 대부분의 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 도구가 있다. 그래서 “가능한 한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용, 검사를 해야 한다”는 것이다.

‘동적 공격’ 탐지 기술도 있다. 널리 알려진 공격 수법 중 일부를 테스트할 수 있는 자동화된 도구, 즉, SQL인젝션, CSRF, XSS 등이 있다.

성공적인 클라우드 전용 아키텍처의 충분조건?

이같은 클라우드 네이티브 보안 외에도 성공적인 클라우드 전용 아키텍처를 위해선 “유지 보수가 용이하고 차세대 클라우드의 지원을 받는 동시에 비용이 효율적이고 자가 복구가 가능한 전제조건이 필요하다.”는 조언이다.

또 클라우드 네이티브 아키텍처는 레거시 시스템(legacy system)에 비하여 물리적 서버에 의존하지 않고도 더 높은 수준의 유연성을 제공하고 있다는 설명이다.

또 마이크로 서비스와 서버리스 함수는 클라우드 네이티브 아키텍처에서 중심 역할을 수행하고 있다.

마이크로 서비스는 클라우드 전용 애플리케이션 아키텍처의 핵심이며, 클라우드로 전환하는 기업의 필수 도구다. 마이크로 서비스는 애플리케이션을 여러 개의 독립된 서비스로 배열하며, 각 서비스는 특정 기능을 제공한다.

연 연구원은 “많은 소프트웨어 회사들이 마이크로 서비스를 사용하고 있는데 이는 마이크로 서비스가 데브옵스(DevOps)를 지원하고, 유연성, 확장성, 비용 절감 등의 효과를 동반하고 있기 때문”이라며 “클라우드 네이티브 마이크로 서비스는 또 API를 통해 서로 통신하며, 이벤트 기반 구조를 사용해 각 애플리케이션의 전반적인 성능을 향상시킨다”고 파악했다.

저작권자 © 애플경제 무단전재 및 재배포 금지