Top 11 Threats in Cloud Computing and How to Prevent Them for AWS

Contents

CSA(Cloud Security Alliance)의 최신 보고서에 따르면 클라우드 컴퓨팅과 관련된 가장 큰 위험은 설정(configuration)과 인증(Authentication)에 관련된 문제다. 이전 보고서에서 시스템 취약성(vulnerabilities)과 멀웨어(malware)를 지적했던 것에 비하면 새로운 방향전환이라 할 만하다.

기업은 서버를 포함한 디지털 자산과 애플리케이션 그리고 모든 종류의 데이터들을 클라우드로 지속적으로 옮기고 있다. 클라우드는 운영성, 확장성, 접근및 관리 등에 있어서 많은 이점을 가지고 있다. 대부분의 경우에는 클라우드 시스템을 신뢰하고 호스팅하기에 충분하며 사용자는 이 이점을 누릴 수 있다. 그러나 다른 모든 기술과 마찬가지로 클라우드의 사용에도 위험이 있다. 이 문서는 인증과 설정관련 문제로 시작하는 11개의 중요 위협과 이들 위협에 대한 대응 방안을 담고 있다. 대응은 AWS를 기준으로 한다.

데이터 유출(Data Breaches)는 사이버 공격과 같은 보안사고로 승인되지 않은 당사자가 기밀 또는 민감한 데이터를 보거나 도난, 판매, 사용되는 것을 의미한다.

• 재정적 손실을 초래한다.
• 계약및 법적 문제
• 데이터 유출은 회사의 평판을 손상시키고 사업 파트너와 고객에게 불신을 초래할 수 있다.
• 지적 재산권 손실
• 회사의 브랜드가치 손상

• 중요 데이터에 대한 암호화 기술 구현
• 중요 데이터에 접근 할 수 있는 사람에 대한 엄격한 관리, 이중 보안 검사, 보안 감사의 수행
• 클라우드에 업로드된 데이터의 가치, 유출에 따른 손실과 책임자에게 미치는 영향을 정의 한다.

암호화 기술 구현 : AWS의 EBS, S3, SQS, SNS, Kinesis, Redshift, MQ 등 데이터를 다루는 주요 서비스들은 기본적으로 암호화 기능을 제공한다. 암호화는 default encryption과 SSE(Server side encryption)두 가지 타입이 있다. Default encryption은 암호화 설정을 체크하는 하면 활성화되며, 저장이 되는 시점에 암호화되고 읽는 시점에 복호화된다. SSE는 애플리케이션 혹은 서비스가 데이터를 암호화해서 쓰고 읽는 방식(AWS 서비스에 따라서 사용 할 수 있는 암호화 옵션에 차이가 있을 수 있다.)이다. 예를 들어 S3버킷에 SSE를 적용했다면 S3 객체를 업로드하거나 다운로드 할때 kms:Decrypt권한이 하다. 따라서 특정 애플리케이션(kms:Decrypt IAM 권한을 가진)만이 데이터를 읽고 쓸 수 있다.

중요 데이터에 대한 접근관리 : IAM을 이용해서 리소스별로(데이터베이스, 스토리지) 접근권한을 설정할 수 있다.

• IAM Role을 이용 특정 애플리케이션, Lambda, 인스턴스, 컨테이너에서만 접근 할 수 있도록 한다.
• AWS Access Key를 이용 데이터베이스 인증토큰을 생성해서 접근 하도록 한다. 데이터베이스에 대한 권한을 가진 사용자가 Access key를 관리하고 요청이 있을 때 인증토큰을 발급하면 될 것이다. 인증토큰은 15분간 유효하므로 안전하게 사용 할 수 있다. 아이디/패스워드, 사용자 자격 증명을 저장 할 필요가 없다.

보안 감사 : CloudTrail로 IAM의 생성, 삭제, 사용에 대한 로그를 모니터링 할 수 있다.

정보보호 가버넌스 : 업무계획을 수립할 때, 정보보호 활동도 함께 수행한다. 서비스가 다루는 정보들 중, 중요 정보와 비 중요 정보들을 가려내고 어떤 보호 조치를 취해야 할지를 결정한다. 개인정보, 신용정보, 의료정보, 위치정보 등이 중요 정보들이 될 것이다. 모든 중요 정보를 하나의 동일한 (높은)레벨로 관리를 하는 건 보안조직의 입장이다. 하지만 데이터는 사용 가능해야 하므로, 중요 정보도 몇 단계로 나눠서 적절한 수준으로 관리를 해야 한다. 즉 보안은 가용성, 기밀성, 무결성을 강조할 것이고, 서비스 및 개발 조직은 사용성을 강조 할 것이다. 균형을 맞춰야 한다.

컴퓨팅 설정이 잘못된 경우 악성활동에 취약해진다. 아래는 잘못된 설정의 예다.

1. 중요 데이터가 저장된 S3의 설정을 실수 해서, 외부에 노출됐다.
2. 컨테이너, 애플리케이션에 과도한 권한을 줬다.
3. 시스템 로깅, 모니터링 설정을 빼먹었다.
4. Security Group을 잘못 설정해서 모든 포트가 모든 소스에 대해서 열려있다.

설정 오류의 설정, 데이터가 암호화 돼있는지, 모니터링/감지 속도에 따라 사업에 미치는 영향이 결정된다. 가장 일반적인 문제는 스토리지에 저장된 데이터가 외부에 노출되는 것이다.

클라우드 설정은 매우 복잡할 수 있으며, 동적으로 변경될 수 있다. 보통 사람의 손으로 수동으로 설정을 변경하는 과정에서 문제가 발생한다. 따라서 회사는 클라우드의 설정을 자동으로 적용 할 수 있는 시스템, 그리고 잘못된 구성을 지속적으로 스캔하고 실시간으로 문제를 해결 할 수 있는 방법/툴을 찾아서 도입해야 한다.

데이터 암호화 : 잘못된 설정으로 데이터가 누출되더라도 피해를 최소화 할 수 있다. 모든 중요데이터를 암호화 하자.

IaC : VPC, Routing Table, Internet Gateway, Security Group을 모두 코드화 한다. 코드화를 하면 사람의 실수를 줄일 수 있으며, 자동화 할 수 있다. 코드이므로 CICD 과정과 통합 할 수 있다. CloudFormation, Terraform 등을 사용 할 수 있다.

Incident Management System: 자원변경을 모니터링하고 변경내용을 관리 할 수 있는 시스템이 필요하다. Opsgenie를 이용한 인프라 이벤트 관리 시스템을 참고하자.

기업이 IT 인프라를 클라우드로 이전함에 따라서, 클라우드에서의 적절한 보안 아키텍처와 정책을 수립하는 일이 중요해지고 있다. 기존의 내부 IT 스택과 보안 정책을 클라우드에 그대로 옮길 수 있다고(lift and shift) 가정하지 말자.

클라우드로 안전하게 마이그레이션하고 배포 및 운영을 위해서는 적절한 보안 아키텍처 및 전략이 필요하다. 취약한 보안으로 사이버 공격이 성공하면, 재정적 손실, 평판 손상, 법적문제 등이 발생 할 수 있다.

• 보안 아키텍처가 비지니스 목표와 일치하는지 검토한다.
• 보안 아키텍처 프레임워크를 개발한다.
• 위협 모델이 최신상태인지 확인한다.
• 보안 상태를 지속적으로 모니터링 한다.

DevSecOps 활동을 한다. 보안을 민첩한 DevOps 사이클에 통합한다. 프로젝트 설계/분석 단계에서 보안이 참여하도록 한다. 개발/배포 단계에서는 CICD 프로세스에 보안정책이 시행되도록 한다. CICD에서는 빌드외에 유닛테스트, 통합테스트, 문서화를 자동화 할 건데, 소프트웨어 취약점 분석, 설정변경 리뷰 등을 통합한다. CICD 사이클과 함께 점진적으로 보안수준이 높아지도록 할 수 있다.

DevOps에 "모니터링/관제/사고관리/운영" 시스템이 포함될 거다. 이 시스템에 보안도 넣는다. 보안담당자와 운영자는 보안 활동을 위해서 필요한 절차/툴을 개발해야 한다. 보안 설정의 코드화 클라우드 인프라, 클라우드 자원 등에서 발생하는 보안 로그들의 수집/분석/이벤트 관리 할 수 있도록 한다.

Cloud Native에 맞는 보안 정책을 수립해야 한다. 온-프레미스 환경에서의 보안 정책을 클라우드 환경에 lift and shift 했다가는 DevOps 가 무너질 것이다. 공동 책임 모델을 개발하자. 공동책임모델은 (약간씩 이름이 다르긴 하지만) AWS, Azure, GCP 등에서 베스트 프랙티스를 찾을 수 있으니 참고해서 개발 할 수 있다.

자격 증명의 부적절한 보호, 암호화 관리의 실패, 확장가능한 자격 증명 관리 시스템의 부재, 다단계 인증 미 사용으로 인한 보안 사고가 발생 할 수 있다.

데이터에 대한 무단 액세스가 가능하다. 결과적으로 합법적인 사용자로 가장한 악의적인 사용자에 의한 정보보호 이슈가 발생 할 수 있다.

• MFA를 적용하고, Root Account를 제한한다.
• 클라우드 사용자에 대한 엄격한 액세스 제어와 연습.
• 최소권한 원칙에 따른 계정 정책의 수행
• 비지니스 목적별로 VPC와 자격증명 그룹을 분리해서 관리한다.
• Key의 라이프사이클을 관리하고 사용하지 않는 자격증명을 제거한다.
• 중앙에서 프로그래밍 방식으로 Key를 관리한다.

• AWS Account에 대한 MFA를 필수로 적용한다.
• Root Account는 사용하지 않는다.
• VPC를 서비스별, 단계별(Development, QA, Product)별로 나누고 독립적인 작격증명 관리 쳬게를 구축한다.
• IAM Role을 사용한다. AWS IAM 모범 사례를 참고하자.
• CloudTrail을 이용 Key의 발급/폐기/사용을 모니터링 한다.

계정 도용을 통해서 높은 권한을 획득해서 민감한 자원에 접근 할 수 있다. 클라우드 환경에서 가장 큰 위험은 계정이 털리는 거다.

어차피 어카운트 털리면 문제가 되는건 온-프레미스라고 다를 건 없다고 할 수 있겠는데, "자원의 컨트롤이 매우 쉽다는" 클라우드의 특성으로 빠르게 문제가 확산될 수 있는 차이가 있다. 예를 들어 온프레미스 환경이라고 하면, 서버 어카운트 하나 털었다고 해서 전체 서버의 권한을 획득하는 건 불가능에 가깝다. 하지만 AWS 루트 어카운트 털리면, 그걸로 끝이다. 모든 자원의 권한이 다 넘어 간다. 권한을 제한한 어카운트라고 마찬가지다, 온-프레미스와는 달리, 그 제한된 권한을 전적으로 (그것도 아주 쉽게) 행사 할 수 있기 때문에 훨씬 위험하다.

서비스 중단, 브랜드 가치 저하, 법적 책임 노출, 민감한 개인정보 유출로 이어질 수 있다.

• 클라우드 환경에서 계정 도용은 가장 심각한 위험이다.
• 심층방어 시스템을 구축하고 IAM을 엄격하게 관리해야 한다.

• MFA를 적용한다.
• IAM 관리 전략을 수립한다. AWS IAM 모범 사례를 참고하자.

내부자는 방화벽, VPN 및 기타 방어장치를 거칠 필요 없이 내부 자원(인스턴스, 데이터베이스, 스토리지)에 직접 접근 할 수 있다.

사업에 미치는 영향은 Account hijacking과 비슷하다.

• 회사의 지적재산이 손실될 수 있다.
• 내부자의 공격으로 인한 서비스 중지는 회사 생산성에 영향을 줄 수 있다.
• 데이터가 손실될 수 있다. 중요 데이터라도 포함돼 있다면, 브랜드 가치저하 정도로 끝나지 않을 것이다.
• 내부 보안 사고가 발생 할 경우 격리, 복구, 사고 대응, 조사, 분석, 의사결정 등등 관련해서 새로운 작업과 예산이 추가 될 수 있다.

• 컴퓨터 시스템, 네트워크, 모바일 장치, 백업 장치를 올바르게 구성하고 모니터링 하기 위한 보안 활동이 필요하다. 회사의 규모와 데이터에 맞는 보안팀을 구성한다. 직접 보안팀을 꾸릴 수 있는 환경이 아니라고 하더라도 매니지드 보안 서비스를 이용하고, 어느 정도의 경험과 권한을 가진 자가 보안환경을 컨트롤 하도록 한다.
• 회사 모바일 장비, 데스크탑 장치를 보호하기 위한 장치를 마련하고 직원들의 장치가 취약점에 노출되지 않도록 교육하고 모니터링 한다. 여력이 없다면 매니지드 솔류션을 이용한다.
• 클라우드와 온-프레미스에 있는 서버들을 정기적으로 감사한다. 보안설정을 코드화 하면 더 좋을 것이다.
• 최소권한 원칙을 적용한다. 귀찮다고 권한을 남발하지 않는다.
• 모든 자원에 대한 접근을 모니터링 한다. Audit Log를 남기는 것 만으로도 위협을 완화할 수 있다.

• 키 관리 시스템의 도입
• 중요 데이터 암호화
• MFA
• IAM 관리 전략의 수립
• CloudTrail로 시스템 설정 변경과 접근을 모니터링

API(Application Programming Interfaces)와 UI(User Interface)는 외부에 직접적으로 노출되는 인터넷과의 경계에 위치한다. 모두가 자유롭게 접근 할 수 있기 때문에, 인증 및 액세스 제어, 암호화, 모니터링등 우발적이거나 악의적인 보안침해 시도를 방지하기 위한 설계가 필요하다.

취약한 인터페이스, API 세트는 기밀성, 무결성, 가용성에 악영향을 줄 수 있다. API는 인터넷에 공개되기 때문에, 피해 확산속도가 매우 빠르고 치명적일 수 있다.

• 파네라 브레드(Panera Bread)는 튼튼하지 않은 API로 모바일 사용 고객 3천 7백만명의 이름, 이메일 주소, 거주지 주소, 생년월일, 신용카드 마지막 네 자리 수를 평문으로 유출시켜 버렸다.
• 모든 산업체들의 2/3 가량이 API를 외부에 공개하고 있으나 이들 조직중 3/4 이상이 API를 제대로 보호하지 않는 것으로 나타났다.
• 조직들은 평균 363개의 API를 관리하고 있다고 한다. API를 이용한 메시 서비스는 커다른 유형이며 앞으로도 계속 발전할 것으로 예상한다. 사업에 미치는 영향이 커질 수 있음을 의미한다.

• 최근의 Open API 트랜드를 따라가기 위해서 "사용성과 연결성"에 비해서 상대적으로 보안은 신경쓰지 않는 경우가 많다. API 보안에 자원을 투입하자. 테스트, Auditing, 비정상 활동을 탐지하기 위한 모니터링 시스템을 구축이 필요하다.
• API 엑세스 키를 올바르게 보호하고 재사용을 피한다. 표준 및 OCCI(Open Cloud Computing Interface) 및 CIMI(Cloud Infrastructure Management Interface)를 사용한다.

• API의 수명주기를 CICD에 통합한다. 코드와 함께 API 문서(swagger등으로 관리)를 함께 배포한다. 이 문서를 이용해서 협업개발자, 품질관리자, 보안담당자들이 API를 리뷰하고 테스트 하면서, API 리스크를 사전에 검토해볼 수 있다.
• Amazon API Gateway와 통합하자. Amazon API Gateway는 IAM(엑세스제어), 모니터링(CloudWatch), WAF(Web Application Firewall), 엑세스 키 관리, CICD와의 통합, 초당 표준 속도 제한, 초당 버스트 속도 제한, L7에서의 위조요청, L3에서의 Floods 공격등 기본적인 보안장치들을 제공한다.
• CloudWatch 같은 기본 툴을 적극 활용 한다. CloudWatch Anomaly Detection문서를 참고하자.

• Control Plane은 데이터 영역으로 흐르는 트래픽을 제어하는 영역을 의미한다.
• Data Plane는 트래픽을 전송하는 목적을 제공하는 영역이다.

Control Plane을 잘 정의하면 Data Plane에서의 데이터 안정성을 제공 할 수 있다. Control Plane이 약하면 데이터 인프라의 논리적인 구성, 보안및 검증을 완전히 제어하지 못한다.

• Control Plane이 약하면 도난 또는 손상으로 데이터가 손실될 수 있다. 데이터 손실에 따른 법적 대응이 필요 할 수도 있다.
• Control Plane이 약하면 클라우드 기반 비지니스 데이터와 응용 프로그램이 위험에 노출 될 수 있다.

• 클라우드 공급자가 제공하는 보안 제어 기능을 이용한다.
• 사용자는 주기적으로 실사를 수행하고, 클라우드 서비스에 적절한 control plane이 수립되어 있는지 확인한다.

메타스트럭처 및 응용구조의 여러 영역에서 실패가 발생 할 수 있다. 예를 들어 클라우드 서비스 제공자가 API를 잘못 구현하면 공격자에 의해서 서비스의 기밀성, 무결성, 가용성이 위협받을 수 있다. 메타스트럭처와 응용구조는 클라우드 서비스의 중요 구성요소다. 클라우드 공금자 수준에서의 기능과 관련된 오류는 모든 서비스 소비자에게 심각한 영향을 줄 수 있다. 마찬가지로 고객이 구성을 잘 못 할 수 있는데, 이 경우 재정/운영 적으로 사용자를 혼란에 빠트릴 수 있다.

• 클라우드 서비스 제공자는 고객 입장에서 투명성이 부족 할 수 있다. 클라우드 서비스 제공자는 고객에게 가시성을 확보하기 위한 여러가지 툴과 서비스를 제공해야 한다.
• 클라우드 사용자는 클라우드 네이티브 디자인 내에서 적절한 제어 기능을 구현해야 한다.
• 클라우드 서비스 제공자는 모의 침투 테스트를 수행하고 고객에게 결과를 제공해야 한다.

• IAM, Route 53(DNS), VPC(Roting Table, Security Group) 등을 코드화(IaC) 해서 관리 한다.

직원이 클라우드 접근, 사용 및 거버넌스에 익숙하지 않을 경우 민감한 회사 데이터를 공개된 혹은 개인이 사용 할 수 있는 위치에 복사해서 사용 할 수 있다.

• 거버넌스 부족. 클라우드 서드파티의 실수로 유출 사고 겪은 혼다와 유니버셜이 대표적인 사고로 AWS S3 버킷을 실수로 인터넷에 노출시키는 바람에 5만명의 개인정보가 새나갔다.
• 보안인식부족. 회사의 서비스와 서비스에서 다루는 정보에 대한 이해 없이 서비스를 사용하는 경우 그들의 정보를 제어 할 수 없다. 직원은 실수로 클라우드 서비스를 잘못 설정해서 사용 할 수 있는데, 이는 서비스와 데이터에 악영향을 미칠 수 있다. 실수가 아닌 고의로 설정을 악용 할 수 있다. 쾌적한 개발 환경을 만들기 위해서 고의로 보안정책을 무시하는 경우다. 회사에 피해를 주기 위한 목적은 아니지만 결과적으로 피해를 줄 수 있는 행위가 될 수 있다.

• 클라우드 가시성을 확보하기 위한 노력을 해야 한다. 일반적으로 사람과 프로세스, 정책, 기술과 관련된 포괄적인 솔류션을 만드는 것으로 시작한다.
• 클라우드 거버넌스, 사용 정책 및 시행에 대한 전사적 교육을 의무화 한다.
• 승인되지 않은 클라우드 서비스의 경우 클라우드 보안 설계자 또는 타사 위험 관리 부서에 검토하고 승인하는 과정을 거친다.
• CASB(Cloud Access Security Broker) 또는 SDG(Software Defined Gateway)와 같은 솔류션에 투자하여 아웃 바운드 활동을 분석하고 클라우드 사용, 위험 사용자를 발견하고 이상을 식별 할 수 있도록 한다. CASB는 2013년 가트너가 정의한 기술로 클라우드 이용에 있어서 안전을 담보해주는 중개자 기능을 제공하는 새로운 보안 레이어를 의미한다. Visibility, Compliance, Data Security, Threat Protection 영역을 다루는 솔루션이다.
• WAF에 투자하여 클라우드 서비스에 대한 모든 인바운드 연결을 분석하여 의심스러운 경향, 맬웨어, DDoS 위험을 확인한다.
• 모든 엔터프라이즈 클라우드 애플리케이션(기업 자원 계획, 기업 자원 관리 , 공급망 관리)를 모니터링하고 제어하도록 설계된 솔류션을 선택해서 의심스러운 행동을 완화한다.
• 제로 트러스트 모델을 구현한다. 제로 트러스트 모델은 네트워크의 안밖의 누구도 신뢰 할 수 없다고 가정한다. 즉, 조직의 내/외부를 막론하고 적절한 인증 절차 없이는 그 누구도 신뢰해서는 안되며, 시스템에 접속하고자 하는 자는 권한을 부여하기 전 신원확인 절차를 거쳐야한다.

• DevSecOps 활동을 수행한다. 개발, 배포, 운영의 과정에 보안이 참여함으로써 가시성을 확보 할 수 있다. 전통적으로 보안은 개발과 이해 상충 관계로 설정했다. 개발과 보안이 따로노는 형국인데, 이런 환경에서 만들어진 오래된 보안 프랙티스는 DevOps 이니셔티브를 무용지물로 만들 수 있다. 보안을 DevOps 프레임워크에 통합하는 것으로 조직의 보안수준을 점진적으로 개선해 나갈 수 있다.
• AWS WAF를 이용해서 인바운드 트래픽을 분석 할 수 있다.
• AWS Shield를 이용해서 DDoS로 부터 서비스를 보호할 수 있다.

읙의적인 목적으로 컴퓨팅 리소스를 사용하는 행위다. DDoS 공격의 시작점으로 사용, 스팸메일 피싱 캠페인, (디지털 통화를 위한)채굴, 대규모 자동클릭, 데이터베이스에 대한 무차별 대입공격, 악의적인 컨텐츠 호스팅 등이다.

• 불법적인 목적으로 클라우드 서비스가 사용 될 수 있다.
• 리소스를 크게 소비한 경우 청구서 폭탄을 맞을 수 있다.

• 내부자에 의한 보안침해 사건은 드물지 않다. 직원에 대한 모니터링이 필요하다.
• DLP(Data Loss Prvention)기술을 사용하여 무단 데이터 유출을 모니터링하고 방어한다.

• 모니터링/관제 시스템의 구축.
• CloudTrail로 자원 상태의 변경을 모니터링 한다.
• 임직원에 대한 보안 교육
• 효율적으로 업무를 수행 할 수 있는 환경. 보안틀어 막는다고 짜증난 업무환경을 구축한 바람에 보안시스템을 우회해서 업무를 수행하는 경우 상당히 많다. 문제는 보안담당자도 알면서 쉬쉬한다는 것. 개발과 보안이 통합되는 DevSecOps 활동을 고민해보자.

AWS를 기준으로 한다.

1. 클라우드 환경에서의 DevOps와 분리되는 보안은 DevOps 이니셔티브를 훼손 할 수 있다.
2. DevOps와 Security를 통합하자. 클라우드는 인프라스트럭처, 소프트웨어 뿐만 아니라 보안 툴도 함께 제공한다. 이들을 잘 통합하면, 개발에서 배포까지의 과정이 점진적으로 개발되는 것처럼 보안도 그렇게 할 수 있다.
3. AWS 보안 기술 백서를 읽어서 적용한다.
4. IaS를 적용하고, 보안 설정도 코드화 한다.
5. 핵심 툴은 아래와 같다.
   1. AWS Trusted Advisor
   2. AWS Organization, Account, IAM Multi-Factor Authentication
   3. IAM Role
   4. CloudTrail
   5. Security Group
   6. VPC, VPC Peering, PrivateLink, RoutingTable, Network ACL
   7. Logging : CloutFront, RDS, S3 객체 만료, S3 Access Log
   8. 모니터링 : CloudWatch, CloudWatch Alarm, EC2 Instanc, Simple Notification Service, Load Balancing
   9. 복원성 확보 : EBS 스냅샷, RDS 다중 AZ 설정, AWS Import/Export, Storage Gateway, 관리형 NoSQL/SQL, 다중 리전 배포, Route 53 및 DNS 장애 조회

• How to prevent the top 11 threats in cloud computing
• Control Planes vs Data Planes