본문으로 바로가기
60278302 0762020052260278302 08 0801001 6.1.7-RELEASE 76 ITWorld 0 false true true false 1590128328000 1590520067000 기업 클라우드 구성 2005241301

기업의 새 보안 취약점 '클라우드 구성 이탈'

글자크기
많은 기업이 코드를 이용해 클라우드 인프라 구축을 자동화한다. 이렇게 하면 데브옵스 라이프사이클의 초기에 안전한 구성의 기준을 마련할 수 있다. 그러나 이후 문서화되지 않은 변경이 탐지되지 않는 상태로 유지되면서 대부분의 클라우드 리소스의 보안 상태가 취약해질 수 있다.
ITWorld

<이미지를 클릭하시면 크게 보실 수 있습니다>


ⓒ Jonny Lindner (CC0)

클라우드 보안 업체 어큐릭스(Accurics)의 최근 연구를 보면, 클라우드 구축 이후 권한이 높은 사용자에 의해 클라우드 리소스 구성이 수정되는 경우가 90%에 이른다. 이러한 변경 중 상당수는 정상적인 비즈니스 측면의 이유 때문이지만, 침해 후 악의적인 횡적 이동 활동의 결과인 경우도 있었다. 안전하지 않은 구성은 클라우드 리소스 및 클라우드 호스팅 데이터와 관련한 데이터 침해의 가장 큰 원인이다. 이와 같은 구성이 방치될 경우 공격자에게는 손쉬운 진입점이 될 수 있다.

코드형 인프라와 보안에 대한 착각

어큐릭스에 따르면 클라우드 환경의 모든 구성 변경 중에서 거의 4분의 1이 현재 코드를 통해 이뤄진다. 이는 지난 몇 년 동안 도입이 확대된 코드형 인프라(IaC) 또는 지속적 구성 자동화(CCA)로 알려진 데브옵스 프로세스 때문이다. 대부분의 클라우드 서비스 업체는 고객이 기계가 읽을 수 있는 정의 파일 또는 템플릿을 통해 새로운 리소스나 클라우드 인스턴스를 프로비저닝하도록 허용하며, 여러 클라우드에서 작동하는 써드파티 툴도 나와 있다.

어큐릭스 보고서에 언급된 데이터의 출처는 고객 설문, CISO, 설계 파트너, 오픈소스 연구 자료, 그리고 실제 환경에 구축된 수십만 개의 클라우드 리소스를 분석한 어큐릭스 자체 데이터다.

IaC 템플릿을 올바르게 구현하면 수동 구축에서, 특히 다수의 설정이 관계될 때 자주 발생하는 사람의 실수 가능성을 낮춰주므로 보안을 강화할 수 있다. 보안을 데브옵스 파이프라인에서 더 왼쪽, 즉 더 조기에 통합하는 프로세스에 IaC 템플릿을 활용할 수 있다. 그러나 이러한 혜택을 얻으려면 기업은 IaC 템플릿이 모범 사례에 따르고 다양한 표준을 준수하도록 클라우드 리소스를 구성해야 한다.

문제는 그렇지 못한 경우다. 보안 업체 팔로알토 네트웍스(Palo Alto Networks)가 깃허브 리포지토리 및 기타 출처에서 수집한 IaC 템플릿을 분석한 결과 약 20만 개의 템플릿 파일에 안전하지 않은 구성 옵션이 포함된 것으로 나타났다. 공통으로 발견된 문제는 다음과 같다.
  • 데이터 스토리지의 암호화 및 로깅 부재
  • SSH, RDP와 같은 서비스가 인터넷에 직접 노출됨
  • 산업 최소 기준을 충족하지 못하는 인증 정보
  • CPU 또는 메모리 제한이 없는 컨테이너
  • 보안 스토리지가 활성화되지 않은 클라우드 스토리지

어큐릭스는 기업 인프라에서 발견된 구성 실수의 67%가 심각한 등급의 위험이었으며 열린 보안 그룹, 과도한 권한이 부여된 ID 및 액세스 관리(IAM) 역할, 노출된 클라우드 스토리지 서비스 등이 포함됐다고 지적했다. 리소스의 40% 이상이 인터넷 보안 센터(Center for Internet Security: CIS) 핵심 보안 컨트롤을 완전히 충족하지 못했으며 18%는 PCI-DSS 요구사항을 충족하지 못했다. 19%는 SOC 2 표준을 위반했고 10%는 HIPAA 요구사항을 충족하지 못했다.

어큐릭스의 CEO인 사친 아가왈은 “코드를 통한 구성의 24% 정도는 문제가 없다. 그러나 이 코드의 대부분이 보안 위험 평가 없이 바로 실제 운영 환경에 프로비저닝된다는 것이 심각하다. 데브옵스 파이프라인을 만들고 코드형 인프라를 조기에 도입하기 시작했다면 이 부분이 문제가 될 수 있다. 클라우드를 설계하는 의도 자체는 기본적으로 좋다. 그러나 이 프로세스의 초기에 보안을 구현해 코드에 내장할 기회가 되는 보안 평가를 수행하지 않는 것이 문제의 본질이다”라고 말했다.

클라우드 구성 이탈 문제

IaC 템플릿에 안전한 구성 옵션이 포함되도록 하는 것은 견고한 클라우드 보안 상태를 향한 첫 단계일 뿐이다. 구축한 클라우드 리소스와 인스턴스에서 보안에 영향을 미칠 수 있는 배포 후 구성 변경을 지속해서 모니터링하는 것이 매우 중요하다. 어큐릭스의 연구 결과를 보면, ‘상태 이탈(posture drift)’은 코드를 통해 프로비저닝되는 클라우드 환경의 90% 이상에서 흔히 발견된다.

보고서는 “실제로 권한이 높은 사용자가 인프라를 프로비저닝하도록 정의된 코드를 업데이트하지 않은 채로 프로덕션의 클라우드 인프라를 바로 적용되는 경우가 있다. 그중에는 승인된 정상적인 변경도 있지만 변경으로 인해 위험이 발생하는 때도 있다. 어느 쪽이든, 클라우드 상태는 단일 진실 공급원(single source of truth)인 코드를 통해 정의된 보안 기준선에서 이탈하게 된다”라고 말했다.

아가왈은 "예를 들어 원래 프로비저닝된 것보다 많은 IAM 역할을 수동으로 추가하는 것은 거의 모든 환경에서 흔하게 찾을 수 있는 관행이다. 또한, 특권 사용자가 실행 중인 환경에서 새 리소스를 추가하거나 리소스를 삭제하는 때도 비일비재하다"라고 말했다.

어큐릭스에 따르면, 보안 기준에서 이탈된 클라우드 리소스의 77%에는 인스턴스(37%), 애플리케이션 로드 밸런서(19%), 보안 그룹(15%), 클라우드 스토리지 서비스(5.5%)가 포함된다.

이탈의 이유 중에는 문화적인 부분도 있고, 관리자와 인프라 엔지니어의 작업 습관도 있다. 데브옵스 자체에 문화적 변화가 포함되는 것과 마찬가지로, 문서화하지 않고 수동으로 구성을 변경하는 관행은 새로운 정책에 따라 시간이 지나면서 줄어들 수 있다. 그러나 공격자가 권한 승격을 시도하는 등 다른 수동 변경 원인도 있으므로, 실행 중인 클라우드 인스턴스와 리소스에서 구성 변경을 모니터링하는 것은 여전히 중요하다.

실행 중인 환경을 대상으로 하는 한 안전하지 않고 문서화되지 않은 수동 구성 변경을 탐지하는 데 걸리는 시간이 길수록 나중에 이를 고치거나 되돌리기 더 어려워진다. 그 변경에 의존하는 다른 변경이 발생하거나 변경한 사람의 원래 의도를 알 수 없기 때문이다. 어큐릭스의 보고서를 보면 프로덕션에서 보고되는 문제 중 해결되는 비중은 4%에 불과하다. 어큐릭스 측은 “인프라를 잘못 구성한 개발자까지 문제를 역추적하기는 어렵고 큰 비용이 드는 클라우드 재배포가 필요하므로 해결 비중이 작을 수밖에 없다”라고 설명했다.

해결 비중이 낮은 다른 이유는 현대 소프트웨어 개발 속도를 높인 '코드 재사용' 관행이다. 기업과 독립 개발자가 서드파티 라이브러리, 구성요소 및 프레임워크를 사용해 더 쉽게 애플리케이션을 만들 수 있게 해줬다. 그러나 개발자가 사용할 서드파티 구성요소를 자유롭게 선택할 수 있도록 허용하면 기업은 취약점 추적과 패치에서 어려움에 직면하게 된다. 많은 경우 소프트웨어 명세서가 없고 특정 라이브러리의 특정 버전이 특정 애플리케이션에 사용된 이유조차 알기 어렵다.

다양한 컨테이너와 서버리스 기술, 여러 프로비저닝 템플릿의 사용이 증가하는 것도 비슷한 상황을 유발할 수 있다. 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)이 지난해 실시한 설문에서, 기업의 41%가 서버리스 기술을 사용하고 84%가 컨테이너를 사용 중인 것으로 나타났다. 이는 코로나바이러스 팬데믹이 닥치기 전의 수치이며 대부분의 전문가는 코로나바이러스 팬데믹이 클라우드 컴퓨팅 서비스 도입을 가속화할 것으로 본다.

어큐릭스 조사 결과에서 기업의 80% 이상이 테라폼(Terraform), 쿠버네티스(Kubernetes) YAML, 도커파일(Dockerfile), 오픈FaaS(OpenFaaS) YAML 등의 코드형 인프라 기술을 2가지 이상 사용 중인 것으로 나타났다. editor@itworld.co.kr

Lucian Constantin editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지
기사가 속한 카테고리는 언론사가 분류합니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.