최근 국내 많은 기업이 퍼블릭 클라우드 도입을 고려하고 있거나 이미 클라우드로 전환 중입니다. 정부도 2021년까지 세계 10대 클라우드 강국으로 도약한다는 목표 아래, 클라우드 이용 확대를 위한 법 개정이나 관련 제도를 개선하고 하고 있습니다.
특히, 올해부터 시행되는 개정된 전자금융감독규정에 따라 이제 금융회사의 핵심 시스템도 퍼블릭 클라우드로 전환할 수 있게 되었습니다. 그러나 이런 분위기에 찬물을 끼얹듯이 클라우드 보안 사고도 계속 발생하고 있습니다.
최근 보안 사고의 원인 중 대다수는 임직원의 보안 취약한 설정 문제
2019년 4월 페이스북의 개인정보 5억여 개가 공개된 클라우드 서버에 무방비로 노출되었던 사고가 있었습니다.1 같은 해 1월에는 미국의 금융사들이 보유하고 있던 약 2,400만 건의 개인정보가 공개된 클라우드 서버에 업로드되어 있었습니다.2 또 2018년 7월에는 중국의 텐센트의 고객 데이터 및 백업 파일이 모두 삭제되는 사고가 있었습니다.3
이 3가지 보안 사고들의 공통점은 관리자가 클라우드 자원들에 대해 보안에 취약한 설정을 해두었다는 것입니다. 한 리서치 기관 조사에 의하면 작년 클라우드 보안 사고의 62%가 클라우드 자원의 잘못된 설정에 의해 발생하였다고 합니다.4 또한 2017년 한 해 동안 잘못된 자원 설정에 의한 정보 유출만 4.4TB로 확인되었습니다.5 더욱 심각한 것은 가트너 보고서에 따르면 2023년까지 클라우드 보안 사고 원인의 99%가 임직원 실수일 것이라고 합니다.
기존의 온 프레미스 환경에서는 기업 정보를 인터넷에 오픈하기 위해서 많은 통제 절차를 거쳐야 하며 반드시 필요한 경우가 아니면 인터넷에 공개 자체를 하지 않습니다. 그러나 이미 인터넷 환경에 노출된 퍼블릭 클라우드에서는 간단한 설정만으로도 기업 데이터가 인터넷상에 노출됩니다.
그럼 실제로 어떤 잘못된 자원 설정이 보안 사고를 초래할까요? 현재 많은 기업에서 사용 중인 AWS 서비스의 사례를 통해 보안 취약한 설정에 대해서 알아보겠습니다.
AWS 서비스 및 자원의 보안 취약한 설정 사례
① AWS S3(Simple Storage Service)
AWS S3는 AWS의 가장 기본적인 서비스입니다. 단위 저장소인 버킷(Bucket)을 만들고 각 버킷에 파일 등을 업로드, 다운로드해 사용합니다. 임직원 PC의 파일이 업로드될 수도 있고, 기업 시스템에서 사용되는 데이터, 로그, 바이너리 파일 등도 저장될 수도 있습니다. 대부분의 기업은 이런 기업 정보가 기업 외부로 공개되는 것을 꺼릴 것입니다. 그러나 S3 버킷의 Public Access 권한을 모두(Everyone)에게 열어주게 되면 누구든 해당 정보에 접근이 가능합니다.
임직원의 실수로 인하여 Public 설정이 되었거나, 해당 버킷이 Public으로 되어있는지 모르는 상태에서 기업의 중요 데이터를 버킷에 등록하게 됨으로써 기업의 중요 데이터는 더는 그 기업만의 데이터가 아닙니다.
따라서 혹시 모를 데이터 유출 사고를 방지하기 위해 기업 정책상 S3 버킷은 Public Access 금지로 기본 원칙을 정하고, 필요한 경우에만 관리자의 승인을 받아 해당 기능을 사용해야 합니다. 또한 공개된 버킷 리스트는 별도로 관리되어야 하며 정기적인 점검을 해야 합니다.
② AWS EBS Snapshot
많은 기업이 장애 및 재해 시 복구를 위하여 운영 중인 서버를 백업하고 있습니다. 백업한 데이터는 절대 공개하지 않으며, 제한된 장소에 보관하고 접근 권한을 최소화하는 정책을 실시하고 있습니다.
AWS Snapshot(이하 스냅샷)은 AWS EBS(기존의 Disk를 생각하면 쉬움)의 백업 및 복구를 가능하게 해주는 서비스입니다. AWS 콘솔(AWS 인프라 관리 화면)에서 간단한 클릭 몇 번만으로 기업의 정보들을 백업할 수 있습니다.
그러나 이때 스냅샷 권한 설정을 Private가 아닌 Public으로 설정하게 되면, 스냅샷 접근 권한을 AWS를 사용하는 모든 사용자에게 부여하게 됩니다. 해커나 호기심 많은 사용자는 이 스냅샷을 이용하여 데이터를 복구하고 해당 데이터를 범죄에 이용할 수 있습니다.
그러므로 기업은 이런 사고를 사전 방지하기 위해, 가장 먼저 모든 EBS는 암호화하여 생성하는 것이 중요(암호화된 EBS는 Public 설정 불가)합니다. 또한 Public 권한 사용에 대해 정책적으로 금지하고, 스냅샷 권한 부여 기능은 최소한의 사용자에게만 부여해야 합니다. 유지 보수, 감사 등의 목적으로 다른 계정으로 해당 스냅샷을 공개할 때에는 반드시 관리자의 승인 아래 명시적으로 해당 계정 정보를 입력하여 공개 구분을 Private로 설정해야 합니다.
③ AWS Security Group
중요 정보를 보유하고 있는 모든 기업은 인터넷으로부터 기업 네트워크로의 불필요한 접근을 막기 위해 각종 보안 장비를 운영합니다. 이 중 가장 기본이면서 중요한 역할을 하는 보안 장비가 방화벽입니다. 방화벽은 허용되지 않은 IP을 차단해 악의적인 침투를 방지합니다.
AWS의 Security Group 서비스는 AWS 가상 네트워크 환경으로의 접근을 차단하는 방화벽과 같은 역할을 담당합니다. AWS 관리 화면(콘솔)을 통해 간단하게 접근 허용할 IP 목록을 입력함으로써 입력되지 않은 IP의 접근을 막을 수 있습니다.
그러나 관리 화면에서 임직원 실수로 Anywhere로 소스를 선택하게 되면, 입력했던 접근 허용 IP는 무시되고 IP가 ‘0:0:0:0/0’으로 바뀌게 됩니다. 이는 모든 IP 접근을 허용하겠다는 설정이며, 특히 이것이 인터넷과 직접 연결된 웹 서버의 원격접속을 허용하는 Security Group이라면 문제는 더 심각해집니다.
따라서 기업은 이런 사고를 방지하기 위해, Security Group Rule의 Any Open을 정책적으로 금지하며, 입력 권한을 최소한으로 부여하고 정기적인 점검 실시하여야 합니다. 또한 인터넷상에서 클라우드 서버로의 원격 접근은 반드시 별도 접근제어 솔루션이나 베스천 호스트 서버를 통해서만 가능하도록 아키텍처를 설계해야 합니다.
위에서 언급한 AWS 사례 3가지 이외에도 AWS 서비스별로 보안 취약한 설정 사례가 존재합니다. 현재 AWS에만 알려진 것이 약 50여 개가 있으며, 기업들은 해당 취약 사례별로 기업에서 도입한 클라우드 환경을 검토하고 반드시 조치해야 합니다. 그렇다면 어떤 방법으로 검토 및 조치를 할 수 있을까요?
기업 내 클라우드 자원의 더욱 안전한 설정을 위한 제언
① CIS Benchmarks의 클라우드 설정 모범 사례 활용한 자체 점검(소규모 기업 권장)
현재 CIS(Center of Internet Security) Benchmarks에서는 글로벌 3대 퍼블릭 클라우드 서비스 공급사(이하 CSP)인 AWS, Azure, GCP 별로 각각 권장되는 모범적인 자원 설정 방법을 홈페이지를 통해 무료로 공개하고 있습니다. 그러므로 퍼블릭 클라우드로 시스템을 전환하였거나, 앞으로 도입할 기업들은 반드시 기업의 클라우드 인프라 환경 설정과 모범 사례를 비교하여 보안상 취약한 설정이 있는지 반드시 점검해야 할 것입니다.
● CIS Benchmarks: 각종 시스템 및 인프라 보안 구성에 대한 모범 사례로서, 140개 이상의 기술에 사용할 수 있는 CIS 벤치마크는 전 세계의 사이버 보안 전문가 및 주제 전문가로 구성된 컨센서스 기반 프로세스를 통해 작성되고 배포됨.
(홈페이지: https://www.cisecurity.org/cis-benchmarks/)
② 자원 취약점 점검 솔루션 통한 보다 전문적인 진단 및 모니터링(중견 기업 이상 권장)
작은 규모의 기업 클라우드는 사용하는 서비스 및 자원이 적어 사용자가 직접 취약한 자원 설정을 확인하고 조치하는데 무리가 없을 것입니다. 그러나 만약 수백여 개 자원(실제 엔터프라이즈급 기업은 1,000개 이상 자원 사용) 별로 취약한 설정에 대해 건 별로 점검해야 할까요? 취약점에 대해 자동으로 점검할 수는 없을까요?
AWS, Azure 등의 CSP들은 자체적으로 이런 취약한 설정에 대해 자동으로 점검 및 관리할 수 있는 자체 솔루션(서비스)을 제공하고 있습니다. 다만, 해당 기능을 사용하기 위해서는 인프라 사용료 외 별도 비용을 지불해야 합니다.
또한 CSP 자체 기능 대비 보다 전문적이고 다양한 기능 제공을 위해 오픈 소스 및 클라우드 관련 전문 업체의 상용 솔루션을 활용할 수 있습니다.
대표적으로 Security Monkey, Scouter Suite 등의 오픈 소스가 있고, 국내•외 업체에서 개발한 상용 취약점 자동 점검 솔루션이 출시되어 있습니다. 특히 상용 솔루션의 경우에는 네트워크 관제, 멀티 클라우드 지원 등의 기능을 결합해 클라우드 통합 점검 및 모니터링 솔루션으로 출시하고 있습니다.
클라우드 자원 설정 취약점 관리는 선택이 아닌 필수
퍼블릭 클라우드의 장점 중 하나는 쉽고 빠른 인프라 환경 구현일 것입니다. 온 프레미스 환경에서 서버 증설을 위해서 영향분석 기간을 제외한 순수 장비 구입 발주•설치 등에만 1개월 이상 걸렸던 것이 클라우드 환경에서는 1시간 내(실제 콘솔에서 걸리는 시간 기준으로는 10분 내)로 증설이 가능합니다.
이러한 클라우드 장점이 동전이 앞면이라면, 그 어두운 뒷면에는 한순간의 잘못된 자원 설정으로 인하여 기업 보안의 전체가 무너지는 위험성이 있습니다.
클라우드를 올바르게 사용하기 위해서 가장 중요한 것은 해당 클라우드에 대해서 정확히 아는 것입니다. 클라우드 도입을 계획하고 있는 기업은 클라우드 보안에 앞서 클라우드 기능에 대해 정확히 이해하는 것이 중요합니다. 이를 위해서는 교육, 클라우드 환경 구성 PoC 등이 필요합니다. 클라우드 기능을 확실하게 이해를 하였다면, 클라우드 자원 설정 실수에 의한 보안 사고는 거의 일어나지 않을 것입니다.
그러나 클라우드에 능숙한 직원이라도 실수를 할 수 있습니다. 그렇기 때문에 CSP도 직접 취약 설정 모니터링, 클라우드 설정 자동화 등의 여러 가지 대안 기능을 출시하고는 있습니다. 그러나 여전히 클라우드 사고의 대부분은 취약한 자원 설정으로부터 발생합니다.
그러므로 클라우드 도입 또는 도입 예정인 기업은 클라우드 환경에 취약한 설정을 하지 못하도록 정책적으로 금지하고, 클라우드 자원을 변경할 수 있는 권한은 최소한으로 부여해야 하며, 취약한 자원 설정은 없는지 주기적인 점검 및 감사 활동을 반드시 수행하시길 당부드립니다.
글 l LG CNS 보안플랫폼팀
