클라우드 보안의 공동 책임 모델, 그 뉘앙스부터 제대로 알자

2017-09-22 10:59
  • 카카오톡
  • 네이버 블로그
  • url
클라우드 제공자는 고객이 쉽고 정확하게 구성하도록 만들고
클라우드 고객은 보안 책임이 자신에게도 있다는 걸 인지해야


[보안뉴스 오다인 기자] 올 여름 아마존 웹 서비스(AWS)에서 연이어 터진 정보 유출 사고는 좋은 뉴스거리였던 건 분명하지만 보안 전문가들은 어떤 교훈을 얻었을까? 보안 업체 업가드(UpGuard)가 방치된 AWS S3 버킷을 발견한 건 물론 잘한 일이지만 공격자들이 실제로 민감한 정보를 확보했는지 여부는 말하기 어렵다. 그러나 수많은 헤드라인이 쏟아진 뒤, 어둠의 해커들이 검색 엔진을 통해 숨겨진 보물들을 찾아냈으리라고 추정하는 건 억지가 아니다. 이로써 향후 더 많은 유출과 위험이 잉태됐으리라 짐작된다.


[이미지=iclickart]

이를 명심하면서 한 걸음 물러나 AWS의 공동 책임 모델을 떠올려보자. AWS는 클라우드 인프라 보안에 근본적인 책임이 있지만 당신도 인프라 정보와 시스템에 대해 책임이 있다. 명확하게 느껴질 지라도 실제론 그렇지 않다. 공동 책임 모델의 뉘앙스를 이해하는 게 중요하다.

클라우드 보안 사고의 대부분은 기업이 허용 범위를 잘못 구성한 데서 초래된다. 소프트웨어, 하드웨어, 서비스 제공자 등이 고유한 보안 정책을 갖고 있지 않거나 너무 복잡하게 만들어서 발생하는 경우도 있다. 최근 드러난 AWS 정보 유출의 경우, 클라우드 제공자인 AWS와 고객 모두에게 잘못이 있다. AWS와 고객은 각자가 유출에 어떻게 원인이 됐는지 반성해야 하고, 앞으로 어떻게 하면 더 잘할 수 있을지 고민해야 한다.

기업(고객)의 측면
기업은 클라우드의 위험을 더 잘 이해할 필요가 있다. 이용 가능성과 가동 시간은 중요한 이점이지만 해당 정보를 ‘나만 쓸 수 있다’는 걸 의미하진 않는다. 기업이 구성을 제대로 하지 않은 정보는 공격자도 쓸 수 있는 것이다. 많은 클라우드 제공자가 기업 정보를 관리하고 있지 않다. 클라우드 제공자는 단지 인프라를 제공할 뿐이다. 그러므로 정보의 관리와 보호는 기업 스스로의 책임이다. 또한, 기업은 접근 제어 목록을 적절하게 관리하고 있는지 확인해야 한다. 이럴 때 고품질의 구성 및 정책을 실현할 수 있고 누가 무엇에 접근할 수 있는지 감시할 수 있다.

클라우드 제공자 측면
본 사안은 아마존만의 문제가 아니지만 아마존이 시장을 지배하고 있는 만큼 대부분의 침해가 아마존에서 발생할 것으로 보인다. 기업에 스토리지 시스템을 제공하고 보안 정책을 도입하는 마이크로소프트와 구글 등 클라우드 제공자들도 사용자가 보안을 잘못 구성할 때마다 아마존과 유사한 상황에 처하게 될 것이다. 클라우드 정보 유출이 클라우드 제공자의 잘못이 아니더라도 공동 책임 모델의 한 당사자로서 클라우드 제공자는 기업이 더 쉽고 올바르게 허용 범위를 구성할 수 있도록 만들어야 한다. 일부 클라우드 제공자는 머신 러닝 같은 기술을 도입해 보안 정책상 비정상적인 부분을 식별할 예정이다. 이를 통해 기업이 취약한 구성에 익숙해지는 걸 막는 것이다.

AWS의 경우, 아마존은 시스템을 더 영리하게 만들 필요성을 인지해야 한다. 아마존 메이시(Amazon Macie)의 발표를 보면, 아마존이 이를 인지하고 있다는 걸 알 수 있다. 예를 들어, 비정상적인 상황에 대해 온전성 검사가 이뤄져야 한다. 거대한 정보가 노출됐다거나 누구나 정보를 볼 수 있도록 허용 범위가 조정됐다거나 할 때 말이다. 또한, 더 단순한 워크플로우가 필요하다. 장점을 따지는 데 있어 최고정보책임자(CIO)의 의견이 최고정보보호책임자(CISO)의 의견보다 언제나 우선적으로 고려되는 경향이 있다. 그러므로 보안은 유연성과 이용 가능성에 밀리는 2등 시민인 셈이다. 정책이나 규칙을 만드는 데 유연성이 한 요소라면 복잡성도 또 다른 요소다. 복잡성이 존재한다면 위험과 취약점이 있다는 뜻이다.

결국에 아마존이 일을 더 많이 해야 한다는 소리지만, 이 문제는 기업이 직면한 숙제들로 다시 돌아가게 된다. 보안 제어가 지나치게 많아 서비스와 애플리케이션을 설치, 구성, 배치, 감시하는 게 더 어려워진다는 숙제 말이다. 그러나 보안 제어가 너무 많아서 위험과 취약점이 발생하는 경우는 거의 없다. 아마존은 어떤 보안이 구축됐는지 반드시 치밀하게 살펴야 하지만, 시스템과 정보가 적절하게 보호됐는지 확인하는 건 최우선적으로 AWS 고객의 책임이다. 해커가 훔쳐간 건 AWS의 정보가 아니라 기업의 정보일 테고, 진짜 위험에 처한 건 AWS가 아니라 기업이기 때문이다.

올해 드러난 사고들은 클라우드 정보 유출의 마지막이 아닐 것이다. 저마다 자신의 교훈을 나눌 것이나 무엇보다 공동 책임 모델 안에서 움직이고 그 뉘앙스를 이해하는 것은 기업이 자신감을 갖고 위험을 관리하도록 도울 것이다. 컴퓨팅 파워와 스토리지를 아웃소싱 한다는 건 보안까지 아웃소싱 한다는 뜻은 아니다. 그러므로 클라우드에 올리는 정보를 보호할 책임은 여전히 당신에게도 있다.

글 : 벤 존슨(Ben Johnson)
[국제부 오다인 기자(boan2@boannews.com)]

Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>

헤드라인 뉴스

TOP 뉴스

이전 스크랩하기


과월호 eBook List 정기구독 신청하기

    • 지인테크

    • 인콘

    • 엔텍디바이스코리아

    • 핀텔

    • KCL

    • 아이디스

    • 씨프로

    • 웹게이트

    • 엔토스정보통신

    • 하이크비전

    • 한화비전

    • ZKTeco

    • 비엔에스테크

    • 지오멕스소프트

    • 원우이엔지

    • HS효성인포메이션시스템

    • TVT코리아

    • 이화트론

    • 다누시스

    • 테크스피어

    • 홍석

    • 슈프리마

    • 인텔리빅스

    • 시큐인포

    • 미래정보기술(주)

    • 유니뷰

    • 비전정보통신

    • 아이원코리아

    • 인터엠

    • 위트콘

    • 성현시스템

    • 한국씨텍

    • 투윈스컴

    • 스피어AX

    • 다후아테크놀로지코리아

    • 한결피아이에프

    • 경인씨엔에스

    • 디비시스

    • 트루엔

    • 세연테크

    • 프로브디지털

    • 동양유니텍

    • 포엠아이텍

    • 넥스트림

    • 핀텔

    • 위즈코리아

    • 삼오씨엔에스

    • 벨로크

    • 피앤피시큐어

    • 신우테크
      팬틸드 / 하우징

    • 에프에스네트워크

    • 네이즈

    • 케이제이테크

    • 셀링스시스템

    • (주)일산정밀

    • 아이엔아이

    • 새눈

    • 미래시그널

    • 인빅

    • 유투에스알

    • 에이티앤넷

    • 케비스전자

    • 한국아이티에스

    • 엣지디엑스

    • 네티마시스템

    • 에이앤티글로벌

    • 이엘피케이뉴

    • 와이즈콘

    • 현대틸스
      팬틸트 / 카메라

    • 제네텍

    • 구네보코리아주식회사

    • 창성에이스산업

    • 에이앤티코리아

    • 지에스티엔지니어링
      게이트 / 스피드게이트

    • 티에스아이솔루션

    • 엔에스티정보통신

    • 엔시드

    • 포커스에이아이

    • 넥스텝

    • 엘림광통신

    • 메트로게이트
      시큐리티 게이트

    • 레이어스

    • 주식회사 에스카

    • 엠스톤

    • 글로넥스

    • 유진시스템코리아

    • 카티스

    • 세환엠에스(주)

Copyright thebn Co., Ltd. All Rights Reserved.

MENU

회원가입

Passwordless 설정

PC버전

닫기