Offcanvas

CIO / CSO / 클라우드

‘CISO 다수가 모르거나 간과하는’ 클라우드 보안 문제 8가지

2024.08.23 Evan Schuman  |  CSO
오늘날 일반적인 기업은 다수의 클라우드 공급업체를 활용하고 있는 가운데, 잘 알려지지 않은 몇 가지 주요 보안 문제를 살펴본다.
 
Image Credit : Getty Images Bank

기업 CISO는 글로벌 위협 환경 전반에서 보안을 유지하려는 과정에서 다양한 클라우드 환경과 애증 관계에 놓이게 된다. 애석하게도 많은 CISO에게는 ‘증오’가 더 큰 비중을 가진다.

클라우드 환경의 운영이 기존 운영의 연장선에 있는 것으로 보일 수 있지만 실제로는 크게 다르다. 기업 전체에 분산되어 있는 다양한 클라우드 팀에 의해 제어되기에 사이버 보안 팀의 지시 및 요구와 상충될 수 있다.

즉 멀티클라우드 환경에서는 탐지하기 어려운 교묘한 사이버 보안 문제가 광범위하게 발생할 수 있다. 다양한 클라우드 보안 전문가들과 함께 의외성을 가진 클라우드 보안 문제에 대해 이야기를 나눠보았다.

임시 리소스는 생각보다 더 큰 위협
클라우드와 관련해 임시 리소스만큼 끈질긴 골칫거리도 드물다. 대부분 수명이 짧아 스캔하기 어렵고 맬웨어를 숨기기에 이상적인 장소이기 때문이다. 그러나 임시 스토리지 인스턴스나 특정 기능을 위해 잠시 존재하는 동적 프로비저닝과 같은 이러한 임시 리소스는 클라우드 환경에서 점점 더 보편화되고 있다.

소프트웨어 공급자 지브텍의 캐시 메릴 설립자는 “임시 리소스의 일시적인 측면으로 인해 보안팀은 위협이 적다고 생각하여 잠재적인 보안 위험을 과소평가할 수 있다"라며, “그러나 일단 이러한 리소스가 손상되면 포렌식 을 위한 흔적을 남기지 않기 쉽다. 악의적인 활동을 위한 진입점 또는 임시 피난처로 악용될 수 있다라고 말했다.

특히 기존의 보안 도구와 관행은 오랜 기간 동안 사용되어 온 인프라에 맞게 구성된 경우가 많기에 수명이 짧은 이러한 구성 요소에 자동으로 확장되지 않을 수 있다는 설명이다.

메릴은 즉 일반적인 보안 검사가 임시 리소스에 대한 공격을 놓칠 확률이 매우 높다며, “최악의 시나리오가 있다. 읽기-쓰기 액세스를 전 세계에 열어두는 것”이라고 말했다. 

클라우드에서는 IT 인벤토리 핑계가 통하지 않음
보안 전문가들은 종종 온프레미스의 IT 자산에 대한 인벤토리 작업을 꺼리곤 한다. 하지만 클라우드에서 인벤토리 작업을 수행하는 것이 훨씬 쉬우며 더 이상 인벤토리 작업을 피할 이유가 없다는 사실을 많은 사람들이 깨닫지 못하고 있다고 위즈(Wiz)의 수석 클라우드 보안 연구원 스콧 파이퍼는 주장했다. 그는 지난날의 인벤토리 작업의 까다로움에 대해 다음과 같이 말했다.

“많은 사람들이 과거 인벤토리 작업으로 인한 상처를 가지고 있다. 물리적으로 전선을 추적하고 디바이스를 눈으로 확인해야 했던 과거의 세상에서는 IT 인벤토리 작업이 매우 어려웠다. 디바이스가 실행하는 소프트웨어와 구성 방식을 이해해야 했고, 이를 위해서는 에이전트를 투입해야 했다."

“이는 잠재적인 성능 및 안정성 위험에 대한 테스트 및 승인을 받은 OS에서 작동하는 에이전트가 필요하고, 에이전트를 설치하기 위해 디바이스에 인증하는 방법, 에이전트가 수행해야 하는 네트워크 통신에 대한 추가 가능한 구성 변경, 에이전트가 호출을 중단하는 경우 문제 해결 등을 파악해야 하기 때문에 어려운 문제였다.”

반대로 클라우드는 모든 것을 API로 간주하므로 인벤토리를 훨씬 더 간단하게 가져올 수 있다. 여전히 재미있는 작업은 아니지만 과거 만큼 핑계를 댈 정도는 아니라는 설명이다. 

파이퍼는 “API 세트로 모든 리소스를 식별할 수 있다. 서버에 설치된 모든 애플리케이션과 라이브러리를 스캔하는 작업은 API로 디스크를 스냅샷한 다음 여유 시간을 들여 해당 데이터를 평가하는 방식으로 수행할 수 있다"라고 말했다.

그는 이어 “인벤토리가 제공하는 가치에도 불구하고 인벤토리 확보의 어려움 때문에 그만한 가치가 없다고 생각하는 시각이 있다”라며, 클라우드에서도 이러한 인벤토리 작업을 회피한다면 심각한 사이버 보안 문제를 초래할 수 있다고 강조했다.

클라우드 청구서가 공격 추적에 유용할 수 있지만 주의가 필요
일부 공격자는 랜섬웨어를 통해 기업 데이터를 훔치거나 DDoS를 통해 운영을 중단시키는 데 관심이 없고 그저 기업에 불이익을 주려 시도한다. 기업이 많은 클라우드 요금을 추가로 부담하도록 설계된 지갑 거부(DoW) 공격이 대표적이다.

하지만 클라우드 지출의 급증만이 공격의 지표인 것은 아니다. 기술 컨설팅 회사인 ISG의 파트너인 더그 세일러스는 “사용량이 크게 감소하는 것도 공격 신호일 수 있다. 누군가 클라우드를 다운시키는 경우다. 지난 90일 동안의 백업을 제거하는 공격도 있다. 이러한 상황에서도 요금표를 통해 모니터링 시스템에 앞서 공격을 포착할 수 있다”라고 말했다.

즉 클라우드 지출을 추적하면 사이버 보안에 대한 통찰을 얻을 수 있다. 그러나 새로운 기능과 서비스가 지속적으로 추가되는 클라우드 과금의 특성으로 인해 실시간 조사가 어렵다. 세일러스는 “하이퍼스케일러들이 수많은 제품을 시장에 출시하고 있다. 사이버 팀과 IT 팀은 뒤늦게 이러한 제품에 대해 알게 되는 경우도 있다”라고 말했다.

IT 교육 회사 플루럴사이트(Pluralsight)의 수석 클라우드 전략가 드류 퍼먼트에 따르면 DoW 공격은 일반적으로 클라우드 컴퓨팅 요금을 올리기 위해 API 엔드포인트를 반복적으로 트리거하는 방식으로 이뤄진다.

그는 “데이터 세트의 규모가 커짐에 따라 취약한 엔드포인트를 악용하고 대규모의 값비싼 데이터 전송을 유발하는 DoW 공격이 점점 더 위험해지고 있다. 조직은 엔드포인트의 남용을 방지하기 위해 API 게이트웨이 속도 제한을 구현하고 단일 IP 주소 또는 범위의 요청 수를 제한하도록 웹 애플리케이션 방화벽 정책을 구성해야 한다”라고 설명했다.

언스트앤영의 사이버 보안 전략 담당 전무이사인 브라이언 레빈은 클라우드 사용에 대한 내부 투명성 부족이 또 다른 문제가 될 수 있다고 덧붙였다.

그는 “여러 팀 간에 공유해야 하는 지식과 이를 적시에 효과적으로 공유할 수 있는 상급자의 부재는 흔한 문제다. 클라우드 서비스 공급업체들이 추가적인 보안 제품과 패키지를 내놓으면서 혼란 가능성도 커진다. 기업에 정작 유용한 신상품이 무엇인지를 분석하기란 어려운 문제다”라고 말했다.

레빈은 중요한 로그를 기록하고 저장하는 데 추가 비용을 청구하는 클라우드 플랫폼의 예를 들었다. 이러한 플랫폼은 공격자가 고의로 로그를 삭제하거나 접근 가능한 로그를 조작할 때 이벤트 후 분석과 포렌식을 수행하는 요긴하지만, 정작 필요한 조직이 이를 파악하기가 쉽지 않을 수 있다고 전했다.
 
기업의 IDP 전략이 부실할 가능성이 높음
IDP(ID 공급자)가 운영 장애를 일으키는 경우는 비교적 드물고 오래 지속되지도 않는다. 또 백업 서비스로 전환하는 작업이 최종 사용자에게 더 큰 혼란을 초래할 수 있다. 그저 기본 시스템의 복구 여부를 확인하는 게 나을 수 있다.

그러나 복원이 언제 이루어질지 알 수 없기 때문에 기업에는 여전히 IDP 백업 전략이 필요하다고 독일 컨설팅 회사 쿠핑거콜 애널리스트의 수석 분석가인 마틴 쿠핑거는 지적했다. 하지만 안타깝게도 위에서 언급한 이유로 많은 기업이 백업 전략을 세우지 않고 있다.

쿠핑거는 “모든 인증이 IDaaS/SaaS 서비스에 의존하는 상황에서 서비스 중단을 얼마나 오래 견딜 수 있을까? 기본 IDP를 사용할 수 없을 때 이러한 서비스를 인증할 수 있는 무언가가 있어야 한다”라며, 기본 IDP가 사용하는 클라우드 환경과 별도로 또는 온프레미스에서 실행되는 두 번째 IDP를 보유하는 것이 좋다고 조언했다.

완벽한 대처가 어려운 SaaS의 보안 문제
SaaS 보안 허점은 교묘하고 교활하기 십상이다. 많은 SOC 담당자가 알아채지 못하는 사이에 조용히 위험을 크게 증가시킬 수 있다.

가트너 찰리 윈클리스 애널리스트는 “SaaS 벤더별로 위험도가 천차만별이다. 또 SaaS 앱에 따라서도 조직에 미칠 수 있는 위험이 달라진다. 거대 업체들은 대개 훌륭하다. 하지만 이후의 몇 개 계층은 사용을 허용할 수 있는 수준이며, 다시 그 뒤로 평가하기 어려운 각종 SaaS 앱들이 있다”라고 말했다.
.
그는 이어 “이 문제는 많은 CISO가 3대 하이퍼스케일러에 집중하고 SaaS를 무시한다는 사실 때문에 더욱 복잡해진다. 코드 리포지토리가 SaaS에 있는 경우가 많다. 예상보다 훨씬 덜 안전할 수 있다”라고 말했다.

댕글링 DNS 포인터(Dangling DNS pointer)가 문제 소지를 가짐
DNS는 클라우드에서 큰 문제가 될 수 있음에도 불구하고 무해해 보이는 문제로는 DNS가 있다며, 가트너의 윈클리스는 다음과 같이 설명했다.

“클라우드의 동적인 특성으로 인해 DNS에 노출되기 쉽다. 팀에서 ‘azurewebsites.net DNS’를 사용하여 사이트를 설정하고 CNAME을 직접 만들어 사이트를 가리킨다고 가정해 본다. CNAME이 아닌 일반적인 사이트만 삭제하면 공격자가 댕글링 DNS로 가장할 수 있다. 이는 클라우드만의 문제는 아니지만 클라우드의 역동성 때문에 실수로 댕글링 DNS 포인터 문제를 남기기 쉽다.”

그에 따르면 누군가가 클라우드에서 리소스를 프로비저닝할 때 그 이름을 일일이 기억할 수는 없을 것이라며, 이로 인해 댕글링 DNS 문제가 발생할 수 있다. “공격자가 해당 기본 도메인을 등록하고 거기에 원하는 것을 넣으면 합법적인 기업 파일처럼 보일 수 있다”라고 윈클리스는 설명했다.

API 접근성이 보안 사고로 쉽게 이어짐
API는 클라우드 구조의 핵심이지만 공격자에게 많은 진입로를 제공하기도 한다. ID 거버넌스 기업 컨덕토원의 폴 쿼나 CTO는 “의외로 흔하지만 간과되는 클라우드 보안 취약점이 바로 앱의 로컬 API 키다. 예를 들어 직원이 해고되어 해당 사용자의 싱글 사인온을 비활성화한다고 가정해 본다. 대부분의 경우 SSO가 비활성화된 후에도 계속 작동하는 로컬 API 키가 있다. 로컬 API 키는 사용자의 SSO 상태와 독립적으로 작동하며 SSO가 꺼져도 자동으로 해지되지 않기 때문이다. 이는 사용자가 여전히 일부 시스템이나 데이터에 액세스할 수 있다는 것을 의미하며, 이는 심각한 보안 위험을 초래한다”라고 말했다.

ISG의 사일러스도 이에 동의하며 API에 액세스하는 사용자 지정 코드를 보안 문제의 잠재적 원인으로 강조했다. 그는 주요 클라우드 플랫폼을 사용하는 기업의 예를 들며 다음과 같이 설명했다.

“누군가가 이러한 공급업체를 사용하고 있고 그 공급업체가 공통의 ID 플랫폼(예: SailPoint)을 사용한다고 가정해본다. 세일포인트가 AWS와 마이크로소프트 등에 데이터 스트림을 전달하고 있다면 하이퍼스케일러 환경 중 하나에서 해당 고객의 모든 정보에 대한 액세스를 허용할 수 있다. 클라우드에서 제한된 데이터 액세스를 허용할 수도 있다. 이제 공격자가 해당 AWS API를 표적으로 삼았다고 가정해본다. 그 클라이언트가 여러 클라우드 플랫폼에서 동일한 자격 증명을 사용했다면 광범위한 액세스를 제공할 수 있다."

IMDSv2: 무지가 클라우드를 망칠 수 있음
2024년 3월, 아마존은 AWS 플랫폼의 중요한 부분인 인스턴스 메타데이터 서비스(IMDS)에 대한 업데이트를 조용히 출시했다. 플로럴 인사이트의 퍼먼트는 “기업 보안팀이 IMDS를 사용하고 있다는 사실조차 인식하지 못할 수 있다. 따라서 메타데이터 노출과 관련된 심각한 보안 위협이 존재할 수 있다는 의미”라고 말했다. 그는 다음과 같이 경고했다.

“AWS는 IMDS를 사용하여 다른 애플리케이션과 서비스에서 사용하는 보안 자격 증명을 저장하고 REST API를 사용하여 해당 정보를 사용할 수 있도록 한다. 공격자는 서버 측 요청 위조[SSRF]를 사용하여 IMDS에서 자격 증명을 훔칠 수 있으며, 이를 통해 측면 이동 또는 데이터 도용을 위한 인스턴스 역할로 인증할 수 있다.”

“AWS는 승인되지 않은 메타데이터의 보안을 개선하기 위해 최신 버전의 IMDS인 버전 2를 도입했지만, 많은 조직이 여전히 원래의 IMDSv1을 기본값으로 사용하고 있다. CISO가 이러한 잠재적인 보안 허점을 차단할 수 있도록 최근 AWS는 새로 출시된 모든 아마존 C2 인스턴스를 기본적으로 더 안전한 IMDSv2로 설정할 수 있는 기능을 발표했다.”

“MDSv2는 2019년 11월에 AWS에서 출시되었지만 기본값을 새 버전으로 설정하는 기능은 2024년 3월에야 도입됐다. 그 결과 많은 조직이 취약한 기존 IMDSv1을 계속 사용했다. 흥미로운 점은 기본값이 새로 시작하는 인스턴스에만 적용되므로 IMDSv1이 설치된 기존 인스턴스는 여전히 재구성해야 한다는 점이다."

그에 따르면 이는 대부분의 조직에게 매우 심각한 위협이다. 새 버전으로 전환해야 할 필요성을 인식하지 못하는 경우가 많기 때문이다. 퍼먼트는 “공격자가 자격 증명을 확보하여 조직 내에서 횡이동할 수 있다는 위험이 있다’라고 말했다. ciokr@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.