혼란스러운 AWS 접근 제어, 데이터 노출의 원인…라이트스핀

아마존 웹 서비스 IAM(Identity and Access Management) 메커니즘은 복잡하다. 그리고 구체적인 특징을 제대로 이해하지 못해 구성을 잘못하고, 클라우드 자산이 노출되는 경우가 많다. 클라우드 보안업체인 라이트스핀(Lightspin) 연구진은 많은 관리자 사이에 혼동을 불러오는 S3 버킷 권한의 특이한 특징들을 규명했다.
 

S3 버킷에 저장된 데이터에 대한 접근을 승인하거나 제한할 몇 가지 방법이 있다. 다른 방법보다 더 세밀한 방법이 있지만, 모두 상호의존적이다. 시간이 지나면서 개별 정책을 바꾸고, 이것이 무단 사용자에 데이터를 노출시키거나, 스토리지 버킷을 개방시킬 수 있다. 특히 수천 또는 수만 객체를 가진 큰 버킷을 다룰 때 이런 경우가 많다. 

라이트스핀 연구진에 따르면, 관리자가 문제를 정확히 파악할 수 있을 정도로 AWS 경고 메시지가 명확하지 않거나 자세하지 않은 문제가 있다. 이런 이유로 AWS는 퍼블릭 액세스(public access)과 계정 교차(Cross-account) 공격 문제를 파악할 수 있는 오픈소스 S3 버킷 스캐너를 개발해 출시했다. 

객체가 퍼블릭으로 공개될 수 있지만, 정확히 어떤 객체일까?

S3 버킷을 다룰 때 퍼블릭 액세스를 제한하는 3가지 방법이 있다. ▲전체 버킷에 적용되는 버킷 ACL(Access Control Lists) ▲개별 객체에 적용되는 객체 ACL ▲S3 버킷 IAM 정책이 여기에 해당된다. 또 AWS는 관리자가 기존 ACL을 무시하는 방법으로 버킷을 안전하게 만들 수 있도록 도움을 주는 S3 블록 퍼블릭 액세스(Block Public Access) 기능을 제공한다. 그러나 이 기능에는 영향이 다른 4개 옵션이 있다. 이 옵션은 관리자에게 유연성을 주지만, 동시에 혼동을 초래할 수도 있다.

첫째, S3 ACL의 퍼블릭 액세스는 모든 사용자(AllUsers)나 자격증명 사용자(AuthenticatedUsers) 그룹 구성원에게 주어진 읽기, 또는 쓰기 권한을 가리킨다. 자격증명 사용자는 동일한 조직의 계정만이 아닌, AWS 계정을 가진 모든 사람을 의미한다.
 
라이트스핀 연구원인 노가 얌 아미타이에 따르면, S3 블록 퍼블릭 액세스 기능의 4가지 옵션과 각각의 영향은 다음과 같다. 
 

• BlockPublicAcls: TRUE로 설정하면 새로운 ACL 정의는 허용되지 않지만, 기존 정의는 계속 적용된다. 퍼블릭 액세스를 허용하는 ACL을 가진 기존 버킷이 있다면, BlockPublicAcls가 여기에 영향을 미치지 않는다.
• IgnorePublicAcls: TRUE로 설정하면, 아마존 S3는 버킷과 포함된 객체의 모든 퍼블릭 ACL을 무시한다. 버킷이나 객체 ACL이 승인한 퍼블릭 액세스가 적용되지 않는다는 의미다.
• BlockPublicPolicy: TRUE로 설정하면, 버킷에 새로운 정책을 추가할 수 없지만, 기존의 것은 계속 적용된다. 퍼블릭 액세스를 허용하는 기존 버킷 정책이 있다면, BlockPublicAcls는 여기에 영향을 미치지 않는다.
• RestrictPublicBuckets: TRUE로 설정할 경우, 퍼블릭 액세스를 허용하는 정책이 있다면, AWS 서비스 책임자(Principals)과 버킷 소유자 계정 내 승인된 사용자로 제한된다.

아마존 측은 모든 S3 액세스 포인트, 버킷, 객체의 퍼블릭 액세스를 차단하려면 4개 설정을 모두 활성화해야 한다고 설명한다. 그러나 현실적으로 봤을 때, 기업들은 각기 다른 애플리케이션에 대한 퍼블릭 및 퍼블릭이 아닌 데이터를 저장하는 데 동일한 버킷을 사용할 수 있다. 따라서 전체 버킷을 대상으로 모든 퍼블릭 액세스를 차단하는 것이 실용적이지 않을 수도 있다. 이런 점에서 관리자가 4개 설정을 다양하게 조합해 효과적으로 사용하는 방법을 이해 및 파악하는 것이 아주 중요하다.

AWS 관리 콘솔은 ‘Public’, ‘Bucket and objects not public’, ‘Only authorized users of this account’, ‘Objects can be public’이라는 4가지 상태로 버킷 정책을 평가할 수 있도록 지원한다.

얌 아미타이는 “이 4가지 액세스 옵션이 자신의 객체가 퍼블릭인지 여부, 어떤 버킷이 안전하지 여부에 대해 명확히 답을 주는 것은 아니다. ‘Public’과 ‘Bucket and objects not public’은 명확한 편이지만, 나머지 두 가지는 혼란을 초래한다. 특히 ‘Objects can be public’은 보안 팀이 항목이 접근 가능한지 여부에 대해 현명한 판단을 내리기 어렵도록 만든다”라고 말했다.

개발자가 S3 버킷을 설정하고, 민감하지 않은 정보가 든 폴더를 만든 다음, ACL을 사용해 콘텐츠를 퍼블릭으로 설정한다고 가정하자. 이 개발자는 나중에 같은 폴더에 일부 민감한 데이터를 저장한 후 전체 버킷을 퍼블릭이 아닌 상태로 바꾸기로 결정을 내렸다. 목적이 변경되었기 때문이다. 이에 IgonorePublicACL 설정을 사용했다. 기존의 모든 퍼블릭 ACL은 영향을 받지 않는 설정이다.

몇 개월이 지나고 이 개발자는 다른 회사로 떠났고, 새 개발자가 와서 동일한 버킷에 새로운 애플리케이션을 위해 또 다른 퍼블릭 폴더를 저장하기로 결정을 내렸다. 이 개발자는 버킷에서 IgonorePublicACL 설정을 없애고, 새 폴더를 만든 후, 객체 ACL을 사용해 내용이 공개되도록 설정했다. 이제 버킷 상태는 ‘Objects can be public’이 될 것이다. 이는 경고를 하지 않는다. 새 개발자가 이제 막 퍼블릭 폴더를 만들었기 때문이다. 그러나 이 개발자는 자신도 모르게 이전 개발자가 만든 기존 폴더를 노출시킨 것이다. 민감한 데이터가 포함된 폴더일 수 있다.

이는 클라우드 배포에서 아주 자주 발생하는 구성 드리프트(Configuration drift)라는 문제이다. 클라우드 보안업체 애큐릭스(Accurics)가 발표한 보고서에 따르면, 프로덕션 환경에서 파악한 클라우드 보안 문제 가운데 15% 이상이 스토리지 버킷을 잘못 구성한 것과 관련이 있다. 또한 90%의 기업이 구성 템플릿이 아닌 런타임에서 구성 변경을 허용하고 있다. 이로 인해 기존 보안 기준선에서 구성 드리프트가 발생한다.

라이트스핀은 최근 4만 개의 S3 버킷을 스캔한 후, 평균적인 기업들은 버킷의 4%를 퍼블릭으로 구성하고 있지만, 약 42%는 상태가 ‘Objects can be public’이었다. 이는 구성이 잘못되었을 수도 있다는 점을 알려준다. 지난 몇 년 동안 여러 기업에서 잘못 구성된 S3 버킷 때문에 중대한 데이터 침해 사고 및 고객 데이터 노출 사고가 발생했다.

와일드카드(Wildcard) 사용으로 인한 계정 교차 공격

라이트스핀 연구진은 S3 보안 연구 동안 발생할 확률이 높고, 악의적 사용자가 자신이 것이 아닌 S3 버킷에 데이터를 쓸 수 있도록 만드는 또 다른 ‘잘못된 구성’ 문제 한 가지를 발견했다.

아마존은 AWS Config나 CloudTrail 같은 서비스로 실행되는 몇몇 구성, 감사, 기타 도구들을 고객에게 제공한다. 이런 서비스는 자신이 생성한 데이터를 S3 버킷에 기록하며, 이런 버킷 선택은 고객에게 달려있다. 전용 버킷을 생성하거나, 자신의 계정에 있는 기존 버킷을 사용하거나, 서비스가 다른 계정의 버킷에 기록을 하도록 만들 수 있다. 후자는 여러 AWS 계정을 갖고 있고, 모든 로깅과 감사에 전용 버킷을 사용하기 원하는 기업에 해당되는 사례이다.

여러 계정이 기록을 할 수 있도록 정책을 통해 수동으로 버킷을 구성하는 방법은 계정의 수가 많지 않을 때 효과가 있다. 그러나 계정의 수가 많다면 통상 리소스 경로와 와일드카드를 사용해 명령줄 인터페이스를 통해 자동화로 처리해야 한다.

라이트스핀의 아자르자르 CTO는 CSO에 “기업에 수천 또는 수만 AWS 계정이 있다면 각각을 모두 조사해 권한을 줄 수는 없다. 이와 관련, 와일드카드를 사용하는 기업에 반복되는 패턴이 있다. 이런 기업들은 AWS 계정 가운데 하나에 와일드카드가 있고(로깅이나 감사에 사용하는 중앙화 된), 이것이 기업에 귀속되어 있다면, 조직 내 계정들만 여기에 접근할 수 있다고 생각한다. 그러나 우리가 알아낸 것에 따르면, 다른 AWS 계정도 이런 버킷 내부에 데이터나 로그를 기록할 수 있다”라고 설명했다.

다음은 와일드 카드를 사용하고, 버킷이 외부 계정에 대해 쓰기 접근권한을 허용하도록 만드는 문제가 되는 경로들의 예이다.
  

• arn:aws:s3:::{bucket-name}/*
• arn:aws:s3:::{bucket-name}/AWSLogs/*
• arn:aws:s3:::{bucket-name}/AWSLogs/*/Config/*

이 경우의 잘못된 구성과 관련된 위험은 제한적이다. 외부 계정이 읽기가 아닌 쓰기 접근 권한만 갖기 때문이다. 이들 계정은 아마존 서비스가 생성한 로그, 구성 등의 데이터만 기록할 수 있다. 그러나 아자르자르는 로그 포이즈닝(Log poisoning)의 경로가 될 수 있다고 지적했다. 보안 시스템은 잠재적인 악성 행위를 탐지하기 위해 AWS 감사 서비스가 생성한 정보를 사용한다. 공격자는 이런 잘못된 구성을 악용, 악성 로그를 주입해 데이터를 중독시키거나, 모니터링 시스템이 기업 계정에 대한 공격을 탐지하지 못하도록 만들 수 있다.

라이트스핀의 최근 연구 및 조사는 AWS 컨피그(AWS Config)와 클라우드트레일(CloudTrail)에 초점이 맞춰져 있다. 그러나 S3 버킷에 데이터를 저장할 수 있는 AWS 서비스는 이 둘에 국한되지 않는다. 다른 서비스도 읽기 권한을 요구할 수 있고, 이것이 더 심각한 데이터 침해 사고를 초래할 수도 있다. 아자르자르에 따르면, 연구원들은 분석 활동을 계속하고 확대할 계획이다.

IAM 그룹과 사용자의 권한 오용

이번 S3 연구 발표가 있기 전에, 아자르자르는 IAM 그룹 및 사용자에 대한 AWS 권한 논리와 관련해 혼동을 초래할 수 있는 또 다른 부분을 발견했다. IAM은 관리자가 사용자 그룹을 정의, 전체 그룹을 대상으로 ID 기반의 정책을 적용할 수 있도록 지원한다. 그러나 정책들을 적용할 수 있는 특정 작업들이 그룹과 개별 사용자 간 다르다. 윈도우 액티브 디렉터리(Windows Active Directory)나 리눅스(Linux) 같은 다른 환경과 비교했을 때 다소 특이한 부분이다.

아자르자르는 기업 AWS 계정에 완전히 접근할 수 있어야 하는 글로벌 AWS 관리자 3명이 있는 기업을 예로 들었다. 계정 관리자는 ‘managers’ 그룹을 만들고, 여기에 ‘AdministratorAccess’ 정책을 적용하고, 그룹에 3명의 사용자를 추가한다. 관리자는 그룹과 3명의 관리자를 관리자 권한 계정이 하이재킹 당했을 때 대처하기 위해 ‘ProtectManagers’라는 정책을 만든다. 관리자 그룹에 대한 모든 작업에 DENY 규칙을 적용하는 정책이다. 그리고 관리자가 아닌 다른 모든 사용자와 그룹에 이 정책을 적용한다.

AWS IAM에서 DENY 정책은 기존 ALLOW 정책을 무시한다. 따라서 iam:UpdateLoginProfile 작업(사용자 비밀번호 변경에 사용되는)을 수행할 수 있는 AWS 계정이 있다면, 그리고 ProtectManagers 정책이 이 계정에 적용되어 있다면, 이 계정은 관리자 그룹 구성원의 비밀번호는 변경할 수 없어야 한다. 

그러나 그렇지가 않다. 이 정책은 그룹에 특정적인 작업만 수행하지 못하도록 만드는 정책이다. 그런데 UpdaeLoginProfile은 사용자에 특정적인(User-specific) 작업이다. 즉, 관리자 그룹 사용자의 비밀번호가 변경되지 않도록 보호하려면 관리자 그룹 사용자 각각에 대해 별개 DENY 정책을 생성한 후 이런 정책을 관리자가 아닌 다른 모든 사용자에게 적용해야 한다는 의미다.

또 다른 특이점은 정책 와일드카드의 리소스 경로가 맥락에 따라 다른 의미를 가질 수 있다는 부분이다. 예를 들어, 리소스 arn: aws: s3:::: customersdata/*에 적용되는 ID 기반 정책은 customersdata로 불리는 S3 버킷의 모든 객체에 적용된다는 것이다. 그러나 아자르자르에 따르면, 경로 arn:aws:iam::123456789012:group/managers2/*에 대해 정책을 정의하면 managers2 그룹의 모든 사용자에게 적용이 되지 않을 것이다. 그룹 자체만 객체로 적용되는 데, 이는 비직관적이다.

아자르자르는 블로그 게시글에서 “이에 대해 우리는 AWS에게 질문했다. AWS는 오류가 아닌 설계부터 이런 방식으로 접근했다고 대답했다. DENY 규칙의 경우, AWS는 그룹을 별개 객체로 취급하며, 사용자를 그룹의 일부로 취급하지 않는다. 이는 IAM이 애저의 액티브 디렉터리와 동일하게 작동한다고 생각하는 기업에 심각한 취약점을 초래할 수 있다. 우리는 이 문제에 관심을 기울일 필요가 있다고 판단한다”라고 설명했다.

아자르자르는 본지와의 인터뷰에서 “그룹을 만드는 이유는 이를 사용자를 위한 컨테이너로 활용하기 위해서이다. 그런데 모든 장소에서 동일한 방식으로 작동하지 않으면 큰 혼동이 초래된다. 액티브 디렉터리에서 AWS IAM으로, 또는 리눅스에서 AWS IAM으로 옮기는 보안 책임자 대부분이 기대하는 ‘상식’이 있다. 그룹이 있고, 이 그룹에 대한 접근을 거부하거나 특정 자산에 대한 그룹 접근을 거부했다면, 그룹의 객체(사용자)에도 동일한 정책이 적용될 것이라고 기대한다. 그러나 이런 방식으로 작동하지 않는다”라고 말했다.

그룹이 작동하는 방식을 변경하는 것도 문제의 소지가 있다. 많은 기존 정책을 망가뜨리기 때문이다. 그러나 AWS IAM은 리소스와 사용자에 대한 태그를 기반으로 접근 정책을 정의하는 기능을 지원한다. 이를 사용, 그룹에 통상적으로 기대하는 행위를 만들 수 있다.

하지만 태그로 그룹 구조를 복제하고, 사용하기 원하는 전용 사용자 리스트를 크게 만든다면, 무엇을 위해 그룹이 필요할까? 아자르자르는 “이는 혼란을 초래한다. 또 환경을 안전하게 만들기 위해 다른 부분에서 더 많은 일을 해야 한다”라고 지적했다. editor@itworld.co.kr