마이크로소프트 애저 클라우드 취약점이 알려주는 클라우드 보안의 4가지 교훈

클라우드가 온프레미스 솔루션보다 더 안전하다는 이야기를 자주 듣는다. 그러나 정말 그럴까? 둘 모두 유사한 취약점과 위험에 노출된다. 때론 배포와 패치에 익숙하지 않은 문제 때문에 클라우드가 온프레미스가 더 복잡할 수 있다.

최근 클라우드의 위험을 조명하는 사건들이 발생했다. 이런 사건을 통해 관리자가 이해해야 할 클라우드 위험과 배울 수 있는 교훈을 간략히 정리했다. 
 

애저 코스모스(Azure Cosmos)의 문을 열어 둔 마이크로소프트

보안업체인 위즈(Wiz)의 연구진은 최근 코스모스 데이베이스에서 수천 마이크로소프트 애저 고객들의 계정과 데이터베이스에 대한 무제한 접근 권한을 획득할 수 있었다고 발표했다. 

이 연구진은 로컬 주피터(Jupyter) 노트북을 조작해 코스모스 DB 기본키(primary key) 등 몇몇 고객 비밀 정보가 들어있는 다른 고객 노트북으로 권한을 상승시킬 수 있었다. 연구진은 “취약점은 주피터 노트북이 활성화되어 있고, 외부 IP 접근을 허용한 주피터 노트북을 가진 코스모스 DB에만 영향을 준다”라고 설명했다. 

또한 이들은 이런 주피터 노트북을 파악해 보호하는 몇몇 방법을 제시했다. CISA는 이런 서비스를 사용하는 사용자는 애저 인증서 키를 다시 생성하는 것이 좋다고 권장했다.

수동 패치가 필요한 애저 리눅스 가상머신 취약점

이 연구진은 이후 OMIGOD로 부르는 중요한 문제를 발견했다. 마이크로소프트 WMI(WIndows Management Infrastructure)에서 리눅스 같은 역할을 하는 OMI(Open Management Infrastructure)에서 이 취약점을 발견했다. 

이 서비스는 모든 리눅스 가상머신에 자동으로 설치되는데, 쉽게 패치되지 않는 취약점이다. 현재 새로 설치된 리눅스 가상머신은 원격 코드 실행의 대상이 될 수도 있다.

위즈의 연구진에 따르면, 위험에 노출될 수 있는 고객의 비율이 65%에 달한다. 보안 전문가가 더 우려하는 문제는 이 취약점이 패치가 어려울 뿐만 아니라, 마이크로소프트가 머신을 패치해 보호하는 프로세스와 권고 사항들을 완벽히 이해하지 못하는 것으로 보인다는 것이다.

마이크로소프트가 블로그에서 언급했듯, 이 앱은 자동 업데이트 메커니즘을 갖고 있지 않기 때문에 수동 패치를 해야 한다. 마이크로소프트는 패치된 버전에 따라 고정된 OMI 버전을 업데이트하는 프로세스를 갖고 있다. 

OMI와 애저 코스모스 취약점은 규모가 아주 큰 최고의 클라우드 공급업체 또한 취약점을 갖고 있을 수 있다는 점을 보여준다. 이런 취약점이 알려졌을 때 클라우드 공급업체가 얼마나 잘 대응하는지 주목하는 것이 좋다.

저장소에 노출된 상태로 남겨진 자격증명

비밀번호가 적힌 포스트잇을 책상 위에 붙여놓은 것처렁 클라우드 서비스를 잘못 구성하거나, 안전하지 못한 상태로 유지하는 경우도 많다. 개발자들은 깃허브(GitHub) 저장소에 비밀번호를 남겨두는 경우가 많다. 코드 ‘빌드(builds)’와 ‘버전(versions)’에 대해서는 자주 들었을 것이다. 개발자가 다양한 버전을 추적하고, 버그를 수정하는 등 후속 조치를 하는 방법이다. 또 개발자가 여백에 메모를 남길 수도 있다. 여기에 공격자들이 나중에 발견할 수 있는 하드코딩 된 자격증명(Credentials)이 포함되어 있는 경우도 있다.

지난 6월, 깃허브는 자격증명을 검사할 수 있는 도구를 추가했다. 깃허브는 2015년부터 노출해서는 안 되는 비밀번호나 비밀이 코드에 있는지 검사해왔다. 이후 깃허브는 이런 비밀번호들이 공격자에게 노출되지 않도록 패키지 레지스트리 자격증명을 검사하는 도구를 추가했다.

클라우드 서비스 보안에 대한 교훈

개발자와 관리자는 항상 다음과 같은 사항을 실천해야 한다.
  

• 외부 IP 접근이 가능한 클라우드 서비스가 무엇인지 검사한다.
• 외부 접근과 관련된 위험을 평가하고, 이런 접근을 보호할 다른 방법이 있는지 판단한다.
• 보안 문제를 파악할 수 있도록 클라우드 공급업체로부터 알림을 받는 조치를 취한다.
• 이용하는 개발 플랫폼에 관한 보안 관련 뉴스와 정보를 계속 주시한다. 

마이크로소프트 애저의 경우, MSRC(Microsoft Security Response Center)를 활용할 수 있다. 클라우드 공급업체는 자사가 먼저 문제를 해결하고, 패치 설치가 필요한지 알리는 경우가 많다.

중소기업도 방법이 있다. 데이터를 보관할 장소를 결정하고, 선택한 공급업체가 적절한 솔루션을 선택했는지 판단한다. 공급업체가 얼마나 잘 대응하고 책임감 있는지 파악하기 위해 사이트의 비밀번호 정책을 이용해 보는 것도 좋다. 복잡한 비밀번호 구문 사용에 제한이 있거나 글자 수에 제한이 있다면, 이는 공급업체가 구식 인증 솔루션을 사용하고 있음을 알려준다. 특정 사이트가 스마트폰 문자만을 이중 인증으로 사용하고, 인증 애플리케이션을 제공하지 않는다면, 이는 인증 프로세스가 개선될 필요가 있음을 말해준다.

많은 금융업체가 이중 인증 수단으로 스마트폰 인증만 지원한다. 금융업체는 새로운 기술 배치가 느린 편이다. 테스트와 요구사항 때문에 배치에 오랜 시간이 소요되기 때문이다. 최소한 금융 관련 정보는 이중 인증 프로세스로 보호되는지 여부를 확인해야 한다.

클라우드 공급업체의 연구진이 고객에게 직접 문제를 알리는 버그 바운티 프로그램을 운영하고 있는지 확인한다. 예를 들어, 마이크로소프트는 애저에 대한 온라인 버그 바운티 프로그램을 운영하고 있다.

공급업체의 책임과 자사의 책임에 대해 검토, 판단한다. 마이크로소프트는 공급업체와 개발자 간 공동 책임 개념을 다룬 여러 백서를 갖고 있다. 이 문서들을 살펴보면, 해당 공급업체가 하게 되는 일과 책임을 파악할 수 있다. 마이크로소프트의 경우, 다음과 같이 운영과 보안에 대한 책임을 규정했다. 
 

• 온프레미스 솔루션은 고객이 운영과 보안의 모든 측면을 책임진다. 
• IaaS 솔루션의 경우, 건물과 서버, 네트워킹 하드웨어, 하이퍼바이저 같은 요소들은 플랫폼 공급업체가 관리한다. 고객은 운영체제, 네트워크 구성, 애플리케이션, ID, 클라이언트, 데이터에 대한 보안과 관리에 책임을 지거나, 공동 책임을 진다. 
• PaaS 솔루션은 IaaS에 토대를 둔다. 공급업체는 네트워크 제어 관리 및 보안에 추가 책임을 진다. 고객은 애플리케이션과 ID, 클라이언트, 데이터 보안과 관리에 책임, 또는 공동 책임이 있다. 
• SaaS 솔루션의 경우, 공급업체가 애플리케이션을 제공하고 기반 구성요소에서 고객을 추상화한다. 고객에게도 책임을 져야 할 부분이 있다. 데이터를 정확히 분류해야 하고, 사용자와 엔드포인트 관리에 공동 책임을 져야 한다.

마지막으로 고객이 클라우드 보안 문제를 인지하도록 도와주는 공급업체의 프로세스를 검토, 평가한다.
   

• 자신의 소프트웨어를 이용할 때 ‘경고’을 등록하도록 권장하는가? 
• 클라우드 서비스에 온프레미스 부분을 설치할 때, 애플리케이션을 사용할 때마다 필요한 업데이트가 있는지 확인하는가? 
• 현재 사용자가 소프트웨어와 해당 공급업체의 고객 대응에 대해 어떤 이야기를 하는가? 
• 공급업체가 적시에 클라우드 서비스를 업데이트하고 있는가? 
• 이런 배포에 대해 충분한 정보를 잘 제공하고 있는가?

기업은 데이터가 어디에 있든, 공급업체가 문제를 어떻게 대응하는지 평가해야 한다. 공격자와 보안 연구진은 클라우드 컴퓨팅의 취약점을 찾고 있다. 클라우드 서비스에 대한 보안 인식을 높여 공급업체에 보안과 고객에 대한 커뮤니케이션 방법을 물어야 한다. 안전 및 보안과 관련된 공급업체의 주장을 그대로 믿지 말고, 공급업체가 특정 문제에 얼마나 빨리 대응하는지 모니터링한다. editor@itworld.co.kr