클라우드에는 운영 게이트가 필요합니다—특히 보안을 위해

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

2017년 1월, 큰 인기를 끌던 MongoDB가 공격자들의 상당히 예측 가능한 수법으로 자리 잡아 가던 데이터 인질 공격을 당했습니다. 이후 침해 사고를 조사한 결과, 공격자들은 대부분의 경우 아무것도 악용하지 않은 것으로 드러났습니다. 문제는 소프트웨어가 아니라 설정에 있었습니다. 주로 AWS에서 실행되던 기본 설정 때문에 인터넷에 연결된 사람이라면 누구나 데이터베이스에 접근할 수 있도록 완전히 노출되어 있었습니다.

여기에는 현재 악명 높은 CloudPets 사태도 포함됩니다. 이 사태로 인해 아이들과 부모 사이의 음성 메시지(비공개로 여겨졌던)가 데이터베이스(보안이 설정되지 않은 MongoDB 인스턴스)를 확보하거나 앱 아키텍처와 Amazon S3 사용 방식을 이해할 만큼 지식이 있는 사람이라면 누구나 공개적으로 접근할 수 있는 상태였습니다. Cloud Pets는 프로필 사진과 음성 녹음을 저장하는 데 S3를 사용하면서 어떠한 보안 조치도 취하지 않은 것으로 보이며, 올바른 참조 정보만 있으면 누구나 해당 자료에 접근할 수 있도록 방치했습니다.

제가 CloudPets만 꼬집는다고 생각하실까 봐 덧붙이자면, RedLock CSI 팀은 최근 “Amazon Relational Database Service 및 Amazon RedShift와 같은 퍼블릭 클라우드 컴퓨팅 환경에 있는 데이터베이스의 82%가 암호화되어 있지 않다”는 사실을 발견했습니다.

[극적인 침묵]

더욱이 “해당 데이터베이스 중 31%는 인터넷에서 들어오는 연결 요청을 허용하고 있었습니다.”

덧붙이자면, 2017년 1월 첫 몇 주 동안 27,000대가 넘는 MongoDB 서버가 침해당했습니다이 사건과 관련해 허술한 보안 관행으로 피해를 본 곳은 CloudPets만이 아니었습니다. 최초의 공격이 알려졌을 당시 MongoDB 블로그에서 언급했듯이 “이러한 공격은 MongoDB에 내장된 광범위한 보안 기능을 통해 예방할 수 있습니다。 이러한 기능을 올바르게 사용해야 합니다, 보안 문서를 참고하면 올바르게 사용하는 데 도움이 될 것입니다. [강조는 필자]”

MongoDB 자체가 안전하지 않았던 것이 아니라, 보안 설정이 전혀 되어 있지 않았던 것입니다. 문제는 제품 자체가 아니라, 클라우드를 통해 IoT 및 모바일 앱을 서둘러 소비자에게 제공하려는 이들의 부실한 관행에 있습니다.

안전하지 않은 관행을 부추기는 클라우드

온프레미스 데이터센터에는 소프트웨어를 외부에 공개하고 데이터 제공에 사용하기 전에 반드시 통과해야 하는 물리적 관문(방화벽 등)과 운영상의 관문(프로세스 및 승인 절차)이 있습니다. 클라우드는 설계상 물리적 관문이 더 적으며, 안타깝게도 흔히 그렇듯 애플리케이션이 세상에 공개되기 전에 거쳐야 할 운영상의 관문도 더 적습니다. 운영상의 관문이 줄어든 것이 바로 ‘로그 IT’ 또는 ‘섀도 IT’라는 개념이 자리 잡게 된 배경입니다. 긴 준비 기간과 수개월이 아닌 수년에 걸친 프로젝트 일정에 불만을 느낀 현업 부서 관계자들은 처음에는 IT 부서를 ‘우회’하기 위해 클라우드를 사용하기 시작했습니다. 하지만 이는 해당 애플리케이션의 보안과 성능을 보장하기 위해 마련된 운영상의 관문까지 우회한다는 의미이기도 했습니다.

이는 클라우드의 문제가 아니라 클라우드를 도입하는 사람들의 문제입니다. 지난 10년 동안 들어온 “물리적 하드웨어를 프로비저닝하는 데 시간이 너무 오래 걸린다”는 이야기만이 문제가 아닙니다. 경쟁사보다 먼저 당장 시장에 진출하고 싶어 하는 비즈니스 이해관계자들을 정말 답답하게 만드는 것은 “IT 승인 절차를 통과하는 데 시간이 너무 오래 걸린다”는 점입니다.

Respondents to a 2017년 Arxan/IBM이 후원한 모바일 및 IoT 보안 설문조사의 응답 결과도 이를 뒷받침합니다. 응답자들은 앱 개발팀이 받는 압박이 IoT 및 모바일 앱의 보안 취약성을 초래한다고 지적했습니다. 69%는 모바일 앱 개발을 서두르는 것이 취약한 코드의 원인이라고 답했으며, IoT 앱에 대해서도 75%가 같은 의견을 보였습니다.

이와 같은 압박은 애초에 제품을 유용하게 만드는 데이터베이스와 클라우드 스토리지를 구축하고 보호하는 작업에도 이어집니다. Cloud Pets의 핵심은 장난감 자체가 아니라 장난감이 데이터를 주고받을 수 있는 기능에 있습니다. 인터넷을 통해서 말입니다. 즉, 크리스마스 출시일을 맞추기 위해 서둘러 개발하고 클라우드에 배포한 IoT 앱 중 하나에 제품의 성공이 달려 있다는 뜻입니다.

개발자만이 자신이 제공해야 하는 애플리케이션의 보안을 책임지는 것은 아닙니다. 데이터베이스든 파일 공유든 일반적인 앱 서비스든, 해당 애플리케이션을 지원하는 클라우드 서비스를 프로비저닝하는 담당자 역시 보안에 대한 책임을 일부 져야 합니다. 비현실적인 마감 기한을 강요하고 최종 배포를 위한 운영 검증 절차를 최소한으로 줄이도록 부추기는 비즈니스 이해관계자도 마찬가지입니다.

물론 IT는 디지털 트랜스포메이션을 수용하고, 소비자에게 제품을 성공적으로, 그리고 안전하게 제공하기 위한 운영 관문을 간소화해야 합니다. 그러나 기업과 개발자는 클라우드에서 이러한 운영 관문을 계속 무시한 채, ‘기본’ 설정에 의존하는 허술한 보안 관행으로 소비자는 물론 기업 이해관계자까지 위험에 빠뜨려서는 안 됩니다. 이는 제품보다는 프로세스에 관한 문제입니다. 즉, 앱과 그 사용자를 예방 가능한 침해 위험에 노출하기 전에 정책이 적용되고 구성이 올바르게 설정되었는지 확인해야 합니다.

당혹스러운 사고를 피하려면, 시장에 출시하기 전에 반드시 통과해야 하는 최소한의 기본 운영 관문을 정의하고 시행함으로써 기본적인 보안 기준부터 확립해야 합니다.

생산성과 수익성을 모두 뒷받침하는 애플리케이션의 퍼블릭 클라우드 마이그레이션이 가속화되고 있기 때문에, 조직에는 이러한 운영 관문이 그 어느 때보다 필요합니다. 또한 마이그레이션 속도가 빨라질수록 공격자가 이를 악용할 기회도 늘어납니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물