보안 / 클라우드

"결국 데이터 유출 문제는 기업의 책임", 반드시 활용해야 할 클라우드 보안 통제 수단

Fahmida Y. Rashid  | CSO 2017.07.21
클라우드 기반 시스템을 잘못 구성해 초래된 데이터 침해 사고가 끊이지 않고 있다. 가장 최근에는 미국 버라이즌(Verion) 고객 600만 명의 정보가 유출됐다. 이는 클라우드 공급업체와 기업이 클라우드 보안을 공동으로 책임져야 한다는 점을 일깨우는 또 다른 사례다.

클라우드 서비스 공급업체가 클라우드 환경을 책임진다고 '오해'를 한다. 이들은 '절반'만 책임지기 때문이다. 아마존과 마이크로소프트, 구글 같은 클라우드 공급업체는 가상 머신이 실행되는 서버 하드웨어와 보유한 데이터센터의 보안을 책임진다.

그러나 가상 머신과 애플리케이션 보안은 고객 각자의 책임이다. 클라우드 공급업체는 고객 워크로드를 보호하기 위해 다양한 보안 서비스와 도구들을 제공하지만, 관리자가 필요한 방어 수단을 실제 구현해야 효과가 있다. 고객이 자신의 네트워크, 사용자, 애플리케이션을 보호하지 않으면, 클라우드 공급업체가 제공하는 보안 도구는 무용지물이다.

버라이즌의 경우, 서드파티 서비스 공급업체가 백오피스(지원 업무)와 콜센터(고객 지원) 운영을 처리하고, 모든 고객 지원 전화 데이터를 저장했다. 구체적으로 지난 6개월 동안 AWS의 S3(Simple Storage Service) 데이터 저장소에 고객 센터에 전화를 건 모든 버라이즌 고객의 이름과 주소, 전화번호, 계정 PIN 코드 등을 저장했다. 고객 서비스 경험을 높이기 위해 데이터를 수집해왔다. 그러나 S3 버킷을 잘못 구성, 외부 액세스가 가능해졌다. 참을성 있게 웹 주소를 파악하면 누구나 정보를 다운로드 받을 수 있는 상태가 되고 말았다. 데이터를 획득한 '범죄자'는 콜센터에 전화를 건 버라이즌 고객을 가장해 고객 계정에 액세스할 수 있게 되었다.

이런 종류의 실수는 아주 흔하다. 최근 클라우드 보안 업체인 레드록(RedLock)의 클라우드 인프라 보안 팀이 발표한 조사 결과에 따르면, 잘못된 구성으로 퍼블릭 클라우드 서비스가 노출된 기업과 기관의 비율이 40%에 달한다.

잘못된 구성은 심각한 문제를 초래한다
버라이즌은 실수로 퍼블릭 클라우드에서 데이터가 유출된 수많은 기업 가운데 하나에 불과하다. 몇주 전, 300만 레슬링 팬의 개인 데이터가 온라인에 유출됐다. WWE(World Wrestling Entertainment)가 비밀번호 보호나 액세스 통제 없이, AWS S3 인스턴스의 데이터베이스를 암호화하지 않은 결과였다.

지난 6월, 미국 공화당 전국 위원회(RNC)는 데이터 분석업체인 딥 루트 애널리틱스(Deep Root Analytics)가 소유한 아마존 S3 스토리지 서버에 미국 전체 유권자의 약 60%에 달하는 1억 9,000만 명의 개인 식별 정보를 개방된 '플레인텍스트' 형식으로 저장한 사실을 인정했다.

방산업체인 부즈 알렌 해밀톤(Booz Allen Hamilton)에서는 퍼블릭 S3 인스턴스에 저장한 펜타곤 소유의 파일 6만 건이 노출되는 사고가 발생했다. 여기에는 미국 군사 작전 같은 기밀 파일, 암호화 처리를 하지 않은 다섯 종의 보안 크리덴셜이 포함되어 있었다.

클라우드 보안 분야의 신생 업체인 레드록을 공동 창업한 CEO 바룬 바드워르는 "클라우드가 안전하지 못한 것이 문제가 아니다. 고객들이 네트워크와 애플리케이션, 데이터를 안전하게 구성하는 책임을 이행하지 않는 것이 문제다. 기업과 기관이 올바르게 구성만 하면, AWS 같은 퍼블릭 클라우드 인프라는 아주 안전하다"고 강조했다.

클라우드 보안업체인 쓰레트스택이 AWS를 이용하는 200개 기업을 분석한 결과에 따르면, 아주 중요한 보안 요소를 하나 이상 잘못 구성한 기업의 비율이 73%이다. 인가를 받지 않은 사람이나 조직이 AWS 콘솔에 로그인, 데이터에 직접 액세스하고, 더 큰 공격에 잘못 구성된 부분을 악용하고, 전체 환경을 통제하도록 방치한 것을 예로 들 수 있다. 범죄자의 '노력'이 아닌 기초적인 보안을 경시하고, IT 정책을 수립하지 않은 실수가 이런 침해 사고의 원인들이다.

IT 관리자, 개발자, 엔지니어, 보안 부서 등 프로비저닝을 책임진 당사자가 누구이든, 클라우드 환경을 구성하는 방법을 제대로 이해하지 못하는 사람들이 너무 많다. 더 이상은 퍼블릭 클라우드를 정보 저장 장소로만 취급할 수 없다. 다음 보안 대책과 수단으로 클라우드 환경, 애플리케이션, 데이터에 대한 승인되지 않은 액세스를 차단해야 한다.

1. 자신의 책임 부분을 인식한다
클라우드 서비스 별로 차이가 있다. 다시 말해, 책임의 정도와 수준이 다르다. SaaS 공급업체는 애플리케이션을 보호한다. 또 데이터 전송, 저장을 안전하게 만든다. 그러나 클라우드 인프라 보안은 보호 대상에서 제외된다. 따라서 기업과 기관은 AWS EC2(Elastic Compute Cloud), 아마존 EBS, 아마존 VPC(Virtual Private Cloud) 인스턴스에 대한 책임이 있다. 여기에는 애플리케이션을 관리하는 운영 체제 구성, 데이터 보호가 포함된다.

대조적으로 아마존은 S3의 운영체제와 애플리케이션을 유지 관리하고, 기업과 기관은 데이터 관리, 액세스 통제(관리), ID 정책 관리를 책임진다. 아마존은 S3의 데이터를 암호화 하는 도구들을 제공하고 있다. 그러나 서버로 유입 또는 유출되는 데이터를 보호하는 것은 기업과 기관의 책임이다. 각각의 클라우드 보안 관리를 누가 책임지는지 공급업체에 확인해야 한다.

2. 액세스를 관리한다
레드록의 CSI에 따르면, 인터넷에 개방된 상태인 퍼블릭 클라우드 데이터베이스의 비율이 31%이다. 퍼블릭 클라우드 환경의 리소스 93%가 아웃바운드 트래픽을 전혀 제약하지 않고 있다.

로드 밸런서나 배스천 호스트(bastion hosts)가 아닌 클라우드 워크로드 중 9%가 모든 포트에서 모든 IP 주소의 트래픽을 승인하도록 설정되어 있다. 이는 좋지 않은 생각이다. 로드 밸런서와 배스천 호스트만 인터넷에 노출되도록 설정해야 한다.

버라이즌에서 데이터 침해 사고가 발생한 이유는 S3 버킷에서 외부 액세스를 허용했기 때문이다. 불행히도 가장 많이 저지르는 실수 가운데 하나다. 쓰레트스택에 따르면, S3 버킷에서 모든 이들에게 액세스를 승인한 조사 대상 기업의 비율이 37%이다. 많은 관리자가 퍼블릭(공개) 서브넷에 0.0.0.0/0을 사용, 서버가 누구나 승인을 하도록 설정해 놓고 있다. 이런 식으로 연결을 개방하면, 어떤 머신이든 접속할 수 있다. AWS의 경우, S3 버킷에 퍼블릭 액세스 정책을 적용하면 안 된다.

많이 저지르는 또 다른 실수는 SSH를 열어 놓는 것이다. 쓰레트스택 조사에 따르면, 73%의 기업과 기관들이 이렇게 하고 있다. 13%는 SSH를 인터넷에 직접 연결시켜 놓았다. 서버 위치를 파악하면, 방화벽을 뚫고 데이터에 직접 액세스할 수 있다는 의미다.

유수 클라우드 공급업체들은 모두 ID 및 액세스 관리 도구를 제공하고 있다. 이런 도구를 활용해야 한다. 액세스를 한 사람, 액세스 한 데이터, 시기를 알 수 있어야 한다. ID(신원)와 액세스 관리 정책을 수립할 때, 특수 권한은 최소한 승인하고 필요한 경우에 추가 승인을 하는 방식을 채택해야 한다. 보안 그룹의 초점을 가능한 좁혀야 하며, 가능하다면 참조 보안 그룹 ID를 사용한다.

아마존 VPC의 경우, 관리자가 AWS 내부에 논리적으로 분리된 네트워크를 생성, 가상 네트워크에서 서버를 시작할 수 있다. 이는 생산 환경을 개발 환경, 중간 단계 환경으로부터 보호하고, 데이터를 분리해 유지할 수 있는 방법이다.

3. 데이터를 보호한다
클라우드의 데이터를 암호화하지 않는 실수도 많다. 레드록의 CSI에 따르면, 암호화가 되어있지 않은 퍼블릭 클라우드 데이터 베이스가 82%에 달한다. 데이터를 암호화하지 않고, 승인받지 않은 당사자가 서버에 액세스할 수 있도록 구성하는 바람에 유권자 정보와 펜타곤의 기밀 파일이 노출되는 사고가 발생했다. 요주의 정보를 클라우드에 저장하면서, 서버에 대한 액세스를 차단하고 데이터를 보호하는 적절한 보안책을 적용하지 않은 것은 무책임하고 위험한 행위이다.

가능할 때마다 암호화 키를 계속 유지 관리해야 한다. 클라우드 서비스 공급업체에 키에 대한 액세스를 제공할 수 있지만, 기본적으로 데이터는 기업과 기관의 책임이다.
윈매직(WinMagic) COO 마크 히크먼은 "집을 수리하면서, 수리업자에게 집 열쇠를 맡기는 것과 같다. 모든 것이 잘될 것이라고 기대한다. 그러나 수리업자가 문을 잠글 것이라고 100% 믿을 수 없다. 또한 이들의 하도급업자를 믿을 수도 없다. 애초 키를 줘서 위험을 초래할 이유가 없는 것이다"고 강조했다.

클라우드 공급업체가 암호화 도구와 관리 서비스를 제공하는 경우에도, 이를 적용하지 않는 기업들이 너무 많다. 암호화는 '안전 장치'이다. 보안 구성에 문제가 있어 데이터가 다른 누군가의 손에 떨어지는 경우에도, 데이터를 사용할 수 없도록 만들어 준다.

4. 크리덴셜을 보호한다
원로그인(OneLogin) 침해 사고에서 알 수 있듯, AWS 액세스 키가 노출되는 사례가 많다. 공개 웹사이트, 소스코드 저장소, 보호를 하지 않은 쿠베르네티스(Kubernetes) 대시보드, 기타 포럼 등에서 노출될 수 있다. AWS 액세스 키를 보물처럼 취급해야 한다. 그리고 이 키를 공개 포럼에서 유출하는 일이 없도록 개발자를 교육한다.

각각의 외부 서비스에 저마다 다른 고유의 키를 생성해 사용하고, 특수 권한을 최소화 한 상태에서 액세스를 제한한다. 키에 지나치게 많은 권한을 줘서는 안 된다. 나쁜 사람 손에 들어갈 경우, 민감한 리소스와 데이터에 액세스 하는 데 악용될 수 있기 때문이다. IAM 역할을 생성, API 호출 등 특정 특수 권한을 지정한다.

또 정기적으로 키를 순환해 사용한다. 레드록 조사에 따르면, 90일 동안 순환되지 않은 액세스 키의 비율이 63%이다. 이는 공격자들에게 침해된 키를 가로채기, 특수 권한 사용자로 클라우드 환경에 침입할 시간을 벌어준다.

루트 사용자 계정을 사용하지 않는다. 이는 관리자 작업에도 해당되는 부분이다. 루트 사용자를 사용, 새로운 사용자를 생성해 특정 특수 권한을 지정한다. 그리고 루트 계정을 잠근다(가능하면 이중 인증 추가). 이후 아주 특별한 계정 및 서비스 관리 작업에만 이를 사용한다. 나머지 경우에는 적절한 권한만 사용자에게 제공한다. 사용되지 않는 사용자 계정을 확인, 이를 비활성화 시킨다. 누구도 사용하지 않는 계정을 유지, 공격자에게 잠재적인 침입 경로를 제공할 이유가 없다.

5. 여전히 '보안 위생'이 중요하다
'심층 방어(Defense-in-depth)'는 클라우드 환경 보안에 특히 중요하다. 하나의 보안 통제책이 실패해도, 다른 보안 통제책으로 애플리케이션과 네트워크, 데이터를 안전하게 유지할 수 있기 때문이다.

다중 인증(Multi-factor authentication, MFA)은 사용자 이름과 비밀번호에 추가된 보안 계층을 제공, 공격자의 침입이 더 어렵도록 만든다. 관리 콘솔과 대시보드, 특수 권한 계정에는 반드시 MFA를 적용한다. 레드록 조사에 따르면, 다중 인증이 구현되지 않은 루트 계정이 58%나 된다. 쓰레트스택 조사에서 62%는 MFA를 사용하지 않는 AWS 사용자가 1명 이상이라고 대답했다.

6. 가시성을 높인다
유수 클라우드 공급업체는 모두 로깅 도구를 제공한다. 이 보안 로깅 도구를 켜서, 미승인 액세스 시도 등의 문제가 있는지 감시해야 한다. 아마존은 AWS 환경을 감사할 수 있는 클라우드트레일(CloudTrail)을 제공하고 있지만, 이 서비스를 사용하지 않는 기업 및 기관이 많다.

활성화 시킬 경우, 클라우드트레일은 API 호출자의 신원, 호출 시간, 호출자의 소스 IP주소, 요청 파라미터, AWS 서비스의 응답 등 AWS API 호출 기록 모두를 유지한다. 변경 추적, 리소스 관리, 보안 분석, 컴플라이언스(준수) 감사 등에도 사용할 수 있다.
실수로 침해 사고가 초래되는 일이 있어서는 안 된다.

데이터 침해 사고는 외부 공격자의 공격으로만 초래되지 않는다. 사람의 실수로 요주의 데이터가 유출될 수도 있다. 무언가를 활성화시키는 것을 까먹거나, 무언가를 적용하고 확인하지 않는 등의 실수는 공격자에게 공격할 수 있는 경로를 제공한다.

기업과 기관은 정기적으로 클라우드 환경의 보안을 평가해야 한다. 개발업체와 공급업체, 파트너의 보안 역시 마찬가지다. 버라이즌의 침해 사고는 서드파티 개발업체의 실수가 고객 조직의 골칫거리가 될 수 있음을 보여준다.

공동 책임 보안 모델(shared security model)이 존재하는 이유가 있다. 클라우드 워크로드 보안을 책임지는 당사자가 누구이든, 결국 데이터에 발생한 문제를 책임지는 것은 고객 기업이나 기관이다. editor@itworld.co.kr
 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.