클라우드, 온프레미스 환경보다 보안에 더 취약하지 않아
[보안뉴스= 박연주 KT IMO보안팀장] 클라우드 도입 초기이던 2008년, IDC가 시행한 클라우드 컴퓨팅 사용의 문제점에 대한 조사에서 ‘보안’은 1위를 차지했다. 그리고 2016년 클라우드가 보편화된 상황에서 클라우드 도입의 장벽이 무엇인지 조사한 결과에서 보안을 꼽은 응답자는 53%로 여전히 1위였다.
클라우드가 인터넷을 통해 컴퓨터 하드웨어와 소프트웨어의 기능을 이용할 수 있도록 하는 서비스이기에 사이버 침해에 대한 막연한 두려움이 있을 수 있다. 자체 전산실에 시스템을 구축하고 직접 시스템을 이용하는 것(이하 온프레미스)과 클라우드 서비스를 이용하는 것 사이에 사이버 침해 위협 관점에서 어떤 차이가 있는지 살펴보고자 한다.
첫째, 네트워크 대역폭이나 시스템 자원을 고갈시켜 서비스 중단을 가져올 수 있는 디도스(DDoS) 공격을 살펴보면 자사 시스템을 목적지로 공격이 발생할 경우 클라우드나 온프레미스 환경 모두 서비스 중단이나 지연의 위험이 있다. 물론 클라우드 서비스 제공자의 논리적 환경 내에서 근접한 타 이용자가 받은 공격으로 서비스에 일시적 지연이나 제한이 발생할 수 있는 가능성이 잠재되어 있다는 점이 공유 인프라 환경의 약점이 될 수 있다. 하지만 많은 클라우드 서비스 제공자가 디도스 탐지·대응을 위한 시스템을 구축해 위험을 최소화하기 위한 노력을 하고 있다는 점은 고려해야 한다.
둘째, 시스템 OS나 미들웨어의 취약점을 노리는 공격의 관점에서 보면 이용하는 클라우드 서비스 모델에 따라 보안책임 공유의 모델이 서비스 제공자와 서비스 이용자 간에 공유되고 적용돼야 한다. 서버나 스토리지 같은 하드웨어 인프라(Iaas)를 사용하고 있다면 이용자가 스스로 취약점에 대한 정보를 수집하고 대응해야 한다. 아울러 공격 시도를 모니터링·분석해 공격시도를 차단할 책임이 있다. 플랫폼까지 서비스를 하는 PaaS 제공자나 소프트웨어 서비스를 제공하는 SaaS 제공자는 제공자가 시스템 OS나 미들웨어 취약점을 조치하고 공격시도를 탐지·차단하는 노력을 해야 한다.
그러나 많은 IaaS 이용자는 자사에 보안 관리의 책임이 있다는 것을 간과하는 경우가 많다. 클라우드에 있는 하드웨어, 소프트웨어 자원에 대해서 접근경로를 제한해 접근을 허용할 출발지와 서비스 포트만 열어야 한다. 그러나 확인된 현황은 그렇지 못한 경우가 많다. 2017년 RedRodk의 CSI팀은 인터넷에서 SSH의 접근 경로가 허용되는 것과 같은 위험도가 높은 보안 기준을 지키지 않는 경우가 46%라고 밝히고 있으며, 연구 대상의 37%는 인터넷에서는 숨겨져 있어 야 할 데이터베이스가 인터넷으로부터의 질의에 응답하고 있는 것을 확인했다. 클라우드 보안 위험은 이용자의 취약한 관행에서 기인되고 있는 것을 나타내고 있다.
셋째, 웹이나 모바일 앱 같은 서비스를 대상으로 발생하는 대부분의 해킹은 어플리케이션의 취약점을 이용해 시도된다. 이러한 해킹을 예방하는 방법은 안전한 소프트웨어 설계와 시큐어코딩 등이다. 앱 취약점을 이용하는 해킹은 소프트웨어의 소유권과 관리 책임을 가진 쪽에서 해킹에 대한 예방과 대응 책임을 가져야 한다. 즉, 온프레미스 환경으로 운영관리를 하는 기업이 자체 보안 시스템을 구축, 보안관제를 하고 취약점 진단을 통해 보안 설정 변경이나 취약한 앱을 수정하는 역할을 했던 것처럼 클라우드를 이용하더라도 동일한 보안활동을 해야 한다. 클라우드 사업자는 이러한 보안활동을 지원하기 위해 다앙한 보안 서비스 상품을 제공하고 있다. 대부분의 상품은 ‘기본’이 아닌 ‘옵션’으로 선택하는 것이므로 서비스 이용자가 보안 책임에 대해 잘 인식하고 자체적인 활동이나 옵션을 선택해 잘 해결할 수 있었으면 한다.
세 가지 관점에서 살펴본 내용의 결론을 내리면 클라우드가 온프레미스 환경보다 보안에 더 취약하다고 볼 수 없다는 것이다. 보안이 우려돼 클라우드를 사용하지 않았다면 이용자의 보안 책임이 달라지지 않는다는 점을 명심하고 운용비용이나 서비스의 성능과 같은 다른 요소를 고려해 결정해야 한다. 또한, 클라우드 서비스 제공자가 공유 인프라를 총괄하는 관점에서 필요한 보안 책임을 어떻게 이행하고 있는지 살펴봐야 한다. 클라우드에 적용되는 서비스제공자와 서비스이용자간 공동 책임 개념을 이해하고 각자가 자신을 몫을 다함으로 보안 우려를 벗고 클라우드의 다양한 혜택을 누릴 수 있기를 기대한다.
[글_ 박연주 KT IMO보안팀장(younju.park@kt.com)]
[보안뉴스= 박연주 KT IMO보안팀장] 클라우드 도입 초기이던 2008년, IDC가 시행한 클라우드 컴퓨팅 사용의 문제점에 대한 조사에서 ‘보안’은 1위를 차지했다. 그리고 2016년 클라우드가 보편화된 상황에서 클라우드 도입의 장벽이 무엇인지 조사한 결과에서 보안을 꼽은 응답자는 53%로 여전히 1위였다.
클라우드가 인터넷을 통해 컴퓨터 하드웨어와 소프트웨어의 기능을 이용할 수 있도록 하는 서비스이기에 사이버 침해에 대한 막연한 두려움이 있을 수 있다. 자체 전산실에 시스템을 구축하고 직접 시스템을 이용하는 것(이하 온프레미스)과 클라우드 서비스를 이용하는 것 사이에 사이버 침해 위협 관점에서 어떤 차이가 있는지 살펴보고자 한다.
[이미지=iclickart]
첫째, 네트워크 대역폭이나 시스템 자원을 고갈시켜 서비스 중단을 가져올 수 있는 디도스(DDoS) 공격을 살펴보면 자사 시스템을 목적지로 공격이 발생할 경우 클라우드나 온프레미스 환경 모두 서비스 중단이나 지연의 위험이 있다. 물론 클라우드 서비스 제공자의 논리적 환경 내에서 근접한 타 이용자가 받은 공격으로 서비스에 일시적 지연이나 제한이 발생할 수 있는 가능성이 잠재되어 있다는 점이 공유 인프라 환경의 약점이 될 수 있다. 하지만 많은 클라우드 서비스 제공자가 디도스 탐지·대응을 위한 시스템을 구축해 위험을 최소화하기 위한 노력을 하고 있다는 점은 고려해야 한다.
둘째, 시스템 OS나 미들웨어의 취약점을 노리는 공격의 관점에서 보면 이용하는 클라우드 서비스 모델에 따라 보안책임 공유의 모델이 서비스 제공자와 서비스 이용자 간에 공유되고 적용돼야 한다. 서버나 스토리지 같은 하드웨어 인프라(Iaas)를 사용하고 있다면 이용자가 스스로 취약점에 대한 정보를 수집하고 대응해야 한다. 아울러 공격 시도를 모니터링·분석해 공격시도를 차단할 책임이 있다. 플랫폼까지 서비스를 하는 PaaS 제공자나 소프트웨어 서비스를 제공하는 SaaS 제공자는 제공자가 시스템 OS나 미들웨어 취약점을 조치하고 공격시도를 탐지·차단하는 노력을 해야 한다.
그러나 많은 IaaS 이용자는 자사에 보안 관리의 책임이 있다는 것을 간과하는 경우가 많다. 클라우드에 있는 하드웨어, 소프트웨어 자원에 대해서 접근경로를 제한해 접근을 허용할 출발지와 서비스 포트만 열어야 한다. 그러나 확인된 현황은 그렇지 못한 경우가 많다. 2017년 RedRodk의 CSI팀은 인터넷에서 SSH의 접근 경로가 허용되는 것과 같은 위험도가 높은 보안 기준을 지키지 않는 경우가 46%라고 밝히고 있으며, 연구 대상의 37%는 인터넷에서는 숨겨져 있어 야 할 데이터베이스가 인터넷으로부터의 질의에 응답하고 있는 것을 확인했다. 클라우드 보안 위험은 이용자의 취약한 관행에서 기인되고 있는 것을 나타내고 있다.
▲박연주 KT IMO보안팀장[사진=KT]
세 가지 관점에서 살펴본 내용의 결론을 내리면 클라우드가 온프레미스 환경보다 보안에 더 취약하다고 볼 수 없다는 것이다. 보안이 우려돼 클라우드를 사용하지 않았다면 이용자의 보안 책임이 달라지지 않는다는 점을 명심하고 운용비용이나 서비스의 성능과 같은 다른 요소를 고려해 결정해야 한다. 또한, 클라우드 서비스 제공자가 공유 인프라를 총괄하는 관점에서 필요한 보안 책임을 어떻게 이행하고 있는지 살펴봐야 한다. 클라우드에 적용되는 서비스제공자와 서비스이용자간 공동 책임 개념을 이해하고 각자가 자신을 몫을 다함으로 보안 우려를 벗고 클라우드의 다양한 혜택을 누릴 수 있기를 기대한다.
[글_ 박연주 KT IMO보안팀장(younju.park@kt.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
엄호식기자 기사보기
.gif)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
