2020.05.27

클라우드 리소스 구성 자동화, 새로운 보안 위협으로 부상

Lucian Constantin | CSO
외부 공격뿐 아니라 클라우드 구성 변경도 치명적인 보안 위협을 일으키기도 한다. 

많은 조직이 클라우드 인프라 구축을 코딩으로 자동화한다. 이는 데브옵스 라이프사이클 초기에 안전한 보안 구성 기준선을 마련하게 해준다. 그러나 대부분 클라우드 리소스의 보안은 공중에 붕 떠버린 상태가 된다. 이는 문서로 남기지 않은 클라우드 구성 변경 때문이다. 
 
ⓒDreamstime

클라우드 보안회사인 어큐릭스(Accurics)의 최신 연구에 따르면 무려 90%의 사례에서 클라우드 리소스 구성이 구축 후 특별 권한을 가진 이용자에 의해 변경된 것으로 나타났다. 

대부분 구성 변경에는 정상적인 이유가 있겠지만, 나머지는 침입에 이은 악의적 ‘횡적 이동 공격’의 결과일 수 있다. 불안정한 구성은 클라우드 리소스 및 클라우드 호스트 데이터 등 데이터 유출의 가장 큰 원인이 된다. 클라우드 리소스 구성이 방치될 경우 이는 공격자에게 손쉬운 진입점이 될 수 있다. 

코드형 인프라와 그릇된 보안 인식 
어큐릭스에 따르면 현재 클라우드 환경의 구성 변경은 4분의 1 가량이 코딩을 통해 이뤄진다. 이는 지난 몇 년 동안 증가하기 시작한 코드형 인프라(Infrastructure as Code, IaC) 또는 지속 구성 자동화(Continuous Configuration Automation, CCA)라고 알려진 데브옵스 과정의 일부다. 

대다수 클라우드 서비스 업체는 고객이 기계 가독형 정의 파일, 또는 템플릿을 통해 새로운 리소스나 클라우드 인스턴스를 프로비저닝할 수 있도록 허용한다. 그리고 여러 클라우드에서 작동하는 써드파티 툴도 이용할 수 있다. 

어큐릭스 보고서는 고객 설문조사, CISO 및 설계 파트너, 그리고 실제 구축된 수십만 개의 클라우드 리소스를 분석한 자체 텔레메트리에서 나온 결과다.

IaC 템플릿을 제대로 구현하면, 보안을 강화할 수 있다. 수작업 구축에서 흔한 인간 오류 확률을 줄여 주기 때문이다. 복잡한 설정이 관여한 경우라면 특히 그렇다. 이는 시트프 레프트 및 데브옵스 파이프라인의 조기 통합 과정의 일부일 수 있다. 

그러나 이러한 혜택을 얻고자 한다면 베스트 프랙티스를 따르는 IaC 템플릿을 만들고 각종 표준에 부합하는 클라우드 리소스 구성을 생성해야 한다. 

문제는 그렇지 못한 경우다. 보안업체인 팔로알토 네트웍스가 깃허브 리포지터리 등에서 수집한 IaC 템플릿을 분석한 결과, 20만 개에 가까운 파일이 위험한 구성 옵션을 가지고 있는 것으로 확인됐다. 여기에서 다음과 같은 공통 문제가 발견됐다. 

• 데이터 스토리지의 암호화 및 로깅 부재 
• 인터넷에 직접 노출된 SSH, RDP 등의 서비스 
• 업계 최소 요건을 충족하지 못한 인증 정보 
• CPU나 메모리 리소스 제한이 없는 컨테이너 
• 보안 스토리지를 지원하지 않는 상태의 클라우드 스토리지 

어큐릭스는 실무에서 검출된 구성 오류 중 67%가 높은 위험 수준이었고 여기에는 오픈 보안 그룹, 과도한 허용 수준의 ID 및 액세스 관리(IAM) 개체, 노출된 클라우드 스토리지 서비스가 포함된다고 밝혔다. 

또한 40% 이상의 리소스가 인터넷보안센터 핵심 보안 제어 절차(CIS critical security controls)을 충족하지 못했고, 18%는 PCI-DSS 요건을 충족하지 못했고, 19%는 SOC 2 표준을 위반했으며, 10%는 HIPAA 요건을 충족하지 못했다. 

어큐릭스의 공동설립자이자 CEO인 새친 애거월은 <CSO>에 “24%의 구성 정보가 코딩을 통해 이루어진 것은 나쁘지 않다. 문제는 대부분 코드가 초기 보안 위험 평가 없이 실무 환경에 투입되는 것이다”라고 지적했다. 

이어서 그는 “그렇다면 데브옵스 파이프라인을 구축하며 IaC를 조기 투입할 때 문제가 된다. 기본적으로 클라우드 설계 의도는 좋다. 하지만, 초기 설계 과정에서 보안을 전혀 평가하지 않는다. 클라우드에 보안을 내장할 좋은 기회인데도 그렇다”라고 지적했다. 

클라우드 구성 이탈 문제
IaC 템플릿이 보안 구성 옵션을 포함하는지 확인하는 것은 클라우드의 보안 태세를 향한 첫 단계다. 구축 이후에 클라우드 리소스와 인스턴스를 지속적으로 모니터링하며 보안에 영향을 줄 수 있는 구성 변경을 파악하는 것 역시 매우 중요하다. 

어큐릭스의 조사 결과에 따르면 코드를 통해 이루어진 클라우드 구축의 90% 이상에서 보안 상태 이탈은 흔한 현상으로 나타났다. 

어큐릭스는 보고서에서 “특별 권한을 가진 이용자가 실무에 투입된 클라우드 인프라를 직접 변경한 후 보안 프로비저닝을 위해 정의된 코드를 수정하지는 않는다”라고 말했다. 

그러면서 “변경이 권한 있는 사용자가 인프라를 프로비저닝하도록 정의된 코드를 업데이트하지 않은 채 프로덕션의 클라우드 인프라를 바로 적용해 변경이 위험을 초래한 사례도 있다. 어느 쪽이든 클라우드 상태는 단일 진실 공급원(Single source of truth)인 코드를 통해 정의된 보안 기준선에서 이탈하게 된다”라고 덧붙였다. 

예를 들어, 처음 프로비저닝된 것보다 더 많은 IAM 개체를 수작업으로 추가하는 것은 거의 모든 환경에서 보편적으로 행해진다고 애가월은 말했다. 특별 권한을 가진 이용자가 실무 환경에서 리소스를 제거하거나 새 코드를 추가하는 것도 흔하다. 

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

몇몇 이탈의 원인은 관행적으로 이뤄진 관리자, 인프라 엔지니어의 작업 습관 결과다. 데브옵스 자체가 문화 변화를 동반하는 것과 같이, 기록 없이 구성 정보를 수작업으로 변경하는 관행 역시 시간이 지나며 새 정책들이 도입되면 빈도가 줄 것이다.  

그러나, 수작업 변경에는 다른 이유들 역시 있다. 예를 들어 공격자가 권한을 상승시키려 한다든지 하는 것이다. 따라서 실행 중인 클라우드 인스턴스와 리소스를 모니터링하며 구성 정보가 변경되었는지 파악하는 것이 여전히 중요하다. 

실무 환경에서 직접 이루어진 보안되지 않고 기록되지 않은 구성 정보 변경 검출이 늦어질수록 이를 수정하거나 되돌리기가 더 어려워진다. 다른 변경이 딸려 있을 수 있고, 변경한 사람의 원래 의도가 소실되었을 수 있기 때문이다. 어큐릭스의 보고서에 따르면 실무에서 보고된 문제 중 해결된 경우는 4%에 불과했다.   

어큐릭스는 “이는 새삼스러울 게 없다. 인프라를 잘못 구성한 개발자까지 문제를 역추적하는 것은 어려울 뿐 아니라 자칫하면 클라우드까지 재구축해야 할 수도 있다. 게다가 비용도 많이 든다”라고 말했다. 

현대 소프트웨어 개발을 가속했던 코드 재사용 관행 역시 마찬가지이다. 이에 의해 기업 및 독립 개발자는 써드파티 라이브러리, 컴포넌트, 프레임워크를 이용해 애플리케이션을 보다 쉽게 개발할 수 있다. 

그러나 개발자에게 써드파티 컴포넌트를 자유롭게 이용할 수 있게 함으로써 취약점을 추적하고 패치하는 일이 극도로 어려워졌다. 대개 소프트웨어 구성 요소 목록이 없고, 애당초 특정 라이브러리의 특정 버전이 특정 애플리케이션에서 왜 사용되었는지를 망각했기 때문이다. 

각종 컨테이너 및 서버리스 기술과 여러 프로비저닝 템플릿의 이용이 증가하면 비슷한 상황이 펼쳐질 수 있다. 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCE)의 지난해 설문조사에서는 41%의 조직이 서버리스 기술을 이용 중이었고, 84%의 조직이 컨테이너를 활용 중이었다. 이는 코로나19 팬데믹 이전의 설문이고, 대다수 전문가는 팬데믹으로 인해 클라우드 컴퓨팅 서비스의 도입이 가속되었다고 확신했다. 

또한 어큐릭스는 80% 이상의 조직이 한 종류 이상의 IaC 기술을 이용하고 있음을 발견했다. 예를 들어 테라폼(Terraform), 쿠버네티스 YAML, 도커파일(Dockerfile), 오픈파스 YAML(OpenFaaS YAML) 같은 것들이다. ciokr@idg.co.kr
 



2020.05.27

클라우드 리소스 구성 자동화, 새로운 보안 위협으로 부상

Lucian Constantin | CSO
외부 공격뿐 아니라 클라우드 구성 변경도 치명적인 보안 위협을 일으키기도 한다. 

많은 조직이 클라우드 인프라 구축을 코딩으로 자동화한다. 이는 데브옵스 라이프사이클 초기에 안전한 보안 구성 기준선을 마련하게 해준다. 그러나 대부분 클라우드 리소스의 보안은 공중에 붕 떠버린 상태가 된다. 이는 문서로 남기지 않은 클라우드 구성 변경 때문이다. 
 
ⓒDreamstime

클라우드 보안회사인 어큐릭스(Accurics)의 최신 연구에 따르면 무려 90%의 사례에서 클라우드 리소스 구성이 구축 후 특별 권한을 가진 이용자에 의해 변경된 것으로 나타났다. 

대부분 구성 변경에는 정상적인 이유가 있겠지만, 나머지는 침입에 이은 악의적 ‘횡적 이동 공격’의 결과일 수 있다. 불안정한 구성은 클라우드 리소스 및 클라우드 호스트 데이터 등 데이터 유출의 가장 큰 원인이 된다. 클라우드 리소스 구성이 방치될 경우 이는 공격자에게 손쉬운 진입점이 될 수 있다. 

코드형 인프라와 그릇된 보안 인식 
어큐릭스에 따르면 현재 클라우드 환경의 구성 변경은 4분의 1 가량이 코딩을 통해 이뤄진다. 이는 지난 몇 년 동안 증가하기 시작한 코드형 인프라(Infrastructure as Code, IaC) 또는 지속 구성 자동화(Continuous Configuration Automation, CCA)라고 알려진 데브옵스 과정의 일부다. 

대다수 클라우드 서비스 업체는 고객이 기계 가독형 정의 파일, 또는 템플릿을 통해 새로운 리소스나 클라우드 인스턴스를 프로비저닝할 수 있도록 허용한다. 그리고 여러 클라우드에서 작동하는 써드파티 툴도 이용할 수 있다. 

어큐릭스 보고서는 고객 설문조사, CISO 및 설계 파트너, 그리고 실제 구축된 수십만 개의 클라우드 리소스를 분석한 자체 텔레메트리에서 나온 결과다.

IaC 템플릿을 제대로 구현하면, 보안을 강화할 수 있다. 수작업 구축에서 흔한 인간 오류 확률을 줄여 주기 때문이다. 복잡한 설정이 관여한 경우라면 특히 그렇다. 이는 시트프 레프트 및 데브옵스 파이프라인의 조기 통합 과정의 일부일 수 있다. 

그러나 이러한 혜택을 얻고자 한다면 베스트 프랙티스를 따르는 IaC 템플릿을 만들고 각종 표준에 부합하는 클라우드 리소스 구성을 생성해야 한다. 

문제는 그렇지 못한 경우다. 보안업체인 팔로알토 네트웍스가 깃허브 리포지터리 등에서 수집한 IaC 템플릿을 분석한 결과, 20만 개에 가까운 파일이 위험한 구성 옵션을 가지고 있는 것으로 확인됐다. 여기에서 다음과 같은 공통 문제가 발견됐다. 

• 데이터 스토리지의 암호화 및 로깅 부재 
• 인터넷에 직접 노출된 SSH, RDP 등의 서비스 
• 업계 최소 요건을 충족하지 못한 인증 정보 
• CPU나 메모리 리소스 제한이 없는 컨테이너 
• 보안 스토리지를 지원하지 않는 상태의 클라우드 스토리지 

어큐릭스는 실무에서 검출된 구성 오류 중 67%가 높은 위험 수준이었고 여기에는 오픈 보안 그룹, 과도한 허용 수준의 ID 및 액세스 관리(IAM) 개체, 노출된 클라우드 스토리지 서비스가 포함된다고 밝혔다. 

또한 40% 이상의 리소스가 인터넷보안센터 핵심 보안 제어 절차(CIS critical security controls)을 충족하지 못했고, 18%는 PCI-DSS 요건을 충족하지 못했고, 19%는 SOC 2 표준을 위반했으며, 10%는 HIPAA 요건을 충족하지 못했다. 

어큐릭스의 공동설립자이자 CEO인 새친 애거월은 <CSO>에 “24%의 구성 정보가 코딩을 통해 이루어진 것은 나쁘지 않다. 문제는 대부분 코드가 초기 보안 위험 평가 없이 실무 환경에 투입되는 것이다”라고 지적했다. 

이어서 그는 “그렇다면 데브옵스 파이프라인을 구축하며 IaC를 조기 투입할 때 문제가 된다. 기본적으로 클라우드 설계 의도는 좋다. 하지만, 초기 설계 과정에서 보안을 전혀 평가하지 않는다. 클라우드에 보안을 내장할 좋은 기회인데도 그렇다”라고 지적했다. 

클라우드 구성 이탈 문제
IaC 템플릿이 보안 구성 옵션을 포함하는지 확인하는 것은 클라우드의 보안 태세를 향한 첫 단계다. 구축 이후에 클라우드 리소스와 인스턴스를 지속적으로 모니터링하며 보안에 영향을 줄 수 있는 구성 변경을 파악하는 것 역시 매우 중요하다. 

어큐릭스의 조사 결과에 따르면 코드를 통해 이루어진 클라우드 구축의 90% 이상에서 보안 상태 이탈은 흔한 현상으로 나타났다. 

어큐릭스는 보고서에서 “특별 권한을 가진 이용자가 실무에 투입된 클라우드 인프라를 직접 변경한 후 보안 프로비저닝을 위해 정의된 코드를 수정하지는 않는다”라고 말했다. 

그러면서 “변경이 권한 있는 사용자가 인프라를 프로비저닝하도록 정의된 코드를 업데이트하지 않은 채 프로덕션의 클라우드 인프라를 바로 적용해 변경이 위험을 초래한 사례도 있다. 어느 쪽이든 클라우드 상태는 단일 진실 공급원(Single source of truth)인 코드를 통해 정의된 보안 기준선에서 이탈하게 된다”라고 덧붙였다. 

예를 들어, 처음 프로비저닝된 것보다 더 많은 IAM 개체를 수작업으로 추가하는 것은 거의 모든 환경에서 보편적으로 행해진다고 애가월은 말했다. 특별 권한을 가진 이용자가 실무 환경에서 리소스를 제거하거나 새 코드를 추가하는 것도 흔하다. 

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

몇몇 이탈의 원인은 관행적으로 이뤄진 관리자, 인프라 엔지니어의 작업 습관 결과다. 데브옵스 자체가 문화 변화를 동반하는 것과 같이, 기록 없이 구성 정보를 수작업으로 변경하는 관행 역시 시간이 지나며 새 정책들이 도입되면 빈도가 줄 것이다.  

그러나, 수작업 변경에는 다른 이유들 역시 있다. 예를 들어 공격자가 권한을 상승시키려 한다든지 하는 것이다. 따라서 실행 중인 클라우드 인스턴스와 리소스를 모니터링하며 구성 정보가 변경되었는지 파악하는 것이 여전히 중요하다. 

실무 환경에서 직접 이루어진 보안되지 않고 기록되지 않은 구성 정보 변경 검출이 늦어질수록 이를 수정하거나 되돌리기가 더 어려워진다. 다른 변경이 딸려 있을 수 있고, 변경한 사람의 원래 의도가 소실되었을 수 있기 때문이다. 어큐릭스의 보고서에 따르면 실무에서 보고된 문제 중 해결된 경우는 4%에 불과했다.   

어큐릭스는 “이는 새삼스러울 게 없다. 인프라를 잘못 구성한 개발자까지 문제를 역추적하는 것은 어려울 뿐 아니라 자칫하면 클라우드까지 재구축해야 할 수도 있다. 게다가 비용도 많이 든다”라고 말했다. 

현대 소프트웨어 개발을 가속했던 코드 재사용 관행 역시 마찬가지이다. 이에 의해 기업 및 독립 개발자는 써드파티 라이브러리, 컴포넌트, 프레임워크를 이용해 애플리케이션을 보다 쉽게 개발할 수 있다. 

그러나 개발자에게 써드파티 컴포넌트를 자유롭게 이용할 수 있게 함으로써 취약점을 추적하고 패치하는 일이 극도로 어려워졌다. 대개 소프트웨어 구성 요소 목록이 없고, 애당초 특정 라이브러리의 특정 버전이 특정 애플리케이션에서 왜 사용되었는지를 망각했기 때문이다. 

각종 컨테이너 및 서버리스 기술과 여러 프로비저닝 템플릿의 이용이 증가하면 비슷한 상황이 펼쳐질 수 있다. 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCE)의 지난해 설문조사에서는 41%의 조직이 서버리스 기술을 이용 중이었고, 84%의 조직이 컨테이너를 활용 중이었다. 이는 코로나19 팬데믹 이전의 설문이고, 대다수 전문가는 팬데믹으로 인해 클라우드 컴퓨팅 서비스의 도입이 가속되었다고 확신했다. 

또한 어큐릭스는 80% 이상의 조직이 한 종류 이상의 IaC 기술을 이용하고 있음을 발견했다. 예를 들어 테라폼(Terraform), 쿠버네티스 YAML, 도커파일(Dockerfile), 오픈파스 YAML(OpenFaaS YAML) 같은 것들이다. ciokr@idg.co.kr
 

X