2022년 3월 22일
Thyaga Vasudevan - 제품 관리 부사장, Skyhigh Security
엔터프라이즈 애플리케이션을 클라우드 네이티브 아키텍처로 전환하면 서버 인프라 패치 및 업그레이드와 같은 번거로운 작업의 부담을 덜어주면서 확장성과 민첩성을 높여 엄청난 비즈니스 가치를 창출할 수 있습니다.
그러나 AWS(Amazon Web Services), Azure, Google Cloud 등 모든 클라우드 환경에는 새로운 범주의 위험이 존재합니다. 클라우드 네이티브 위협은 클라우드 환경의 새로운 컨텍스트와 구성 요구사항에서 비롯됩니다. 지금까지는 스토리지 개체에 대한 공개 액세스와 같은 기본 설정으로 인해 민감한 데이터가 공개적으로 노출되어 이러한 약점을 노리는 사람이 쉽게 훔칠 수 있었습니다.
클라우드 제공업체에서 새로운 기능을 추가함에 따라 새로운 설정이 계속 도입되는 새로운 환경에서는 실수를 저지르기 쉽습니다. 클라우드 환경의 구성은 항상 사용자의 책임입니다. AWS 및 기타 제공업체는 사용자의 서비스 사용 방법을 통제할 수 없습니다. 이들은 여러분이 구축할 수 있는 템플릿일 뿐입니다.
구성의 결과와 클라우드 네이티브 애플리케이션을 구축하는 방법을 이해하지 못하면 치명적인 결과를 초래할 수 있습니다. 아무리 능숙한 클라우드 고객이라도 이러한 결과로 인해 어려움을 겪을 수 있습니다.
한 예로, 거의 3년 전에 공격자가 미국인 1억 명의 사회보장번호와 캐나다인 6백만 명의 사회보험번호에 액세스했던 Capital One의 침해 사고가 있습니다. 공격자는 데이터에 액세스하기 위해 여러 가지 기술을 사용했지만, 이 공격에서 얻은 중요한 교훈은 가상 머신(Elastic Compute Cloud 또는 EC 인스턴스)에 대한 액세스를 보호하도록 설계된 보안 기능이 공격자를 추가했다는 것이었습니다. 이 기능을 인스턴스 메타데이터 서비스 또는 IMDS라고 합니다.
인스턴스 메타데이터 공격
2012년에는 EC2 인스턴스가 다른 AWS 서비스와 보다 안전하게 상호 작용할 수 있도록 하기 위해 IMDS 버전 1(IMDSv1)이 출시되었습니다. 이제 고객은 인스턴스에 AWS 키를 남겨두는 대신 EC2 인스턴스가 메타데이터 서비스를 쿼리하여 자격 증명을 얻고 다른 AWS 서비스에 대한 AWS API 호출을 할 수 있게 되었습니다. 예를 들어, EC2 인스턴스가 일부 고객 데이터를 확보한 경우, IMDSv1을 사용해 해당 데이터를 Amazon S3 버킷에 저장할 수 있습니다. 공격자가 Capital One 고객에 대한 정보를 저장하는 데 사용되는 S3 버킷에서 민감한 정보를 가져오는 데 사용한 것이 바로 이 기능입니다.
자체 테스트에서 이러한 데이터 추출이 모든 애플리케이션에서 어떻게 작동하는지 복제할 수 있었습니다. 이 예에서는 한 전염병학 팀이 바이러스 게놈 분석 진행 상황을 보여주는 데이터를 시각적으로 표시하는 공개 대시보드가 포함된 클라우드 네이티브 애플리케이션을 AWS에 구축했습니다.
이 애플리케이션의 개발 단계에서 팀은 난관에 부딪혔습니다. 가상 프라이빗 클라우드(VPC)에 있는 대부분의 리소스는 인터넷에서 숨겨져 있어야 했습니다. VPC에서 공개적으로 볼 수 있는 유일한 리소스는 대시보드뿐이었습니다.
데이터를 호스팅하는 S3 버킷은 비공개로 유지해야 했습니다. S3에서 공개 대시보드로 데이터를 가져오기 위해 중개자 역할을 하는 역방향 프록시를 추가했습니다. 간단한 Google 검색과 몇 줄의 코드만 있으면 애플리케이션에 이 기능을 추가할 수 있었습니다.
역학 연구팀에게 역방향 프록시는 사용 사례에 완벽하게 작동하는 기본적이고 우아한 솔루션이었습니다. 하지만 역학팀은 이 솔루션이 대규모 보안 침해에 대비할 수 있다는 사실을 깨닫지 못했습니다.
역방향 프록시를 실행하는 컴퓨팅 인스턴스에는 비공개 S3 버킷에 액세스할 수 있는 권한이 있는 IAM 역할이 할당되었습니다. 역방향 프록시가 S3에 액세스하기 위한 자격 증명은 인스턴스 메타데이터에서 가져왔습니다.
사이트를 방문하여 데이터에 관심이 있는 공격자는 팀이 대시보드에서 리버스 프록시의 IP 주소를 참조한 것을 발견했습니다. 그런 다음 공격자는 이 주소에 연결할 수 있는지 확인했습니다. 연결이 확인된 후 공격자는 역방향 프록시를 통해 인스턴스 메타데이터에 액세스할 수 있는지 확인했습니다. 성공했습니다.
공격자는 역방향 프록시와 인스턴스 메타데이터를 통해 팀의 비공개 S3 스토리지 버킷에 대한 자격 증명을 알아냈습니다.
이제 공격자는 S3 버킷에 액세스하여 팀이 애플리케이션을 위해 저장해 둔 매우 민감한 데이터를 훔칠 수 있었습니다. 공격자는 공격 대상 S3 버킷을 다른 AWS 계정에 있는 자신의 S3 버킷에 동기화하기만 하면 데이터가 자신의 것이 되었습니다.
이러한 유형의 공격은 MITRE가 클라우드 환경을 위한 ATT&CK 프레임워크에서 설명하는 43가지 기법 중 하나에 불과합니다( https://attack.mitre.org/matrices/enterprise/cloud/).
AWS가 인스턴스 메타데이터 공격을 완화하는 방법
이 서비스의 보안을 개선하기 위해 AWS는 몇 가지 새로운 보호 계층을 추가하는 IMDSv2를 출시했습니다.
IMDSv2에서는 외부 사용자가 자격 증명을 받지 못하도록 차단하여 애플리케이션 리소스만 자격 증명을 받을 수 있도록 합니다. 이 보호 계층과 IMDSv2에 대한 자세한 내용은 https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ 참조하세요.
그러나 IMDSv1이 여전히 살아 있다는 문제는 여전히 남아 있습니다. AWS에는 고객이 IMDSv1을 사용하는 것을 막는 어떤 것도 없으며, 모든 EC2 인스턴스에서 여전히 기본적으로 사용할 수 있습니다. 앞서 언급했듯이, 클라우드를 안전하게 사용하는지 확인하는 것은 AWS의 책임이 아닙니다. 그 책임은 전적으로 고객에게 있습니다.
방금 설명한 공격에서는 역방향 프록시가 외부 요청이 내부 리소스에 도달할 수 있도록 잘못 구성되었습니다. 만약 팀이 컴퓨팅 인스턴스를 IMDSv2를 사용하도록 구성했다면 외부 위협 행위자의 무단 액세스가 차단되었을 것입니다.
스카이하이 클라우드 네이티브 애플리케이션 보호의 지원 방법
Skyhigh Security 에서 이와 같은 공격을 탐지하고 예방하는 데 도움이 되는 몇 가지 접근 방식을 확인할 수 있습니다. Skyhigh 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP)은 여기에서 확인할 수 있는 다양한 추가 보안 조치와 함께 AWS, Azure, GCP의 구성을 모니터링하고 업데이트할 수 있는 클라우드 네이티브 보안 플랫폼입니다.
AWS와의 직접 API 통합을 통해 Skyhigh CNAPP는 애플리케이션 및 인프라 모니터링 서비스인 Amazon CloudWatch를 지속적으로 모니터링하여 모든 EC2 인스턴스에서 사용 중인 IMDS 버전을 표시합니다.
CloudWatch가 IMDSv1을 사용하는 인스턴스를 적극적으로 로그하면, Skyhigh CNAPP는 보안 인시던트를 생성하여 외부 사용자의 자격 증명에 대한 무단 액세스를 방지할 수 있는 IMDSv2로 구성을 업데이트하라는 알림을 보냅니다.
IMDS 버전 구성을 위한 스카이하이 CNAPP 정책 인시던트
모든 로컬 코드 및 사용자에 대해 EC2 인스턴스에서 IMDSv2를 적용하는 것이 가장 좋습니다. IMDSv2를 사용하도록 지정하면 IMDSv1은 더 이상 작동하지 않습니다. AWS는 여기에서 IMDSv2를 사용하도록 인스턴스를 구성하는 방법에 대한 단계별 지침을 제공합니다.
이 공격 예시 외에도 Skyhigh CNAPP을 사용하면 클라우드 네이티브 애플리케이션을 보호하기 위한 일련의 모범 사례를 구현할 수 있습니다:
- 구성을 지속적으로 감사하세요. Skyhigh CNAPP을 사용하면 프로덕션에 들어가기 전에 AWS CloudFormation 템플릿을 스캔한 다음 시간이 지남에 따라 구성의 '드리프트'를 감지할 수 있습니다. 이를 통해 잘못된 구성을 감지하고 리소스 권한에 대해 최소 권한 모델을 적용할 수 있습니다.
- 제로 트러스트 적용. 특정 리소스만 실행하고 서로 통신할 수 있도록 허용하는 제로 트러스트를 방법론으로 사용하세요. 그 외의 모든 것은 차단됩니다.
- 코드 취약점을 스캔하세요. 특히 Docker와 같은 공개 소프트웨어 배포 모델의 경우 애플리케이션 리소스에 대한 취약점을 지속적으로 모니터링하는 것이 중요합니다.
- 이상 징후 및 위협 탐지. UEBA(사용자 및 엔터티 행동 분석)를 사용하면 수백만 개의 클라우드 이벤트를 평가하여 비정상적인 활동과 자격 증명 도용과 같은 실제 위협을 발견할 수 있습니다.
- 스토리지 개체에서 DLP 실행. 승인하는 다른 클라우드 서비스, 네트워크 또는 엔드포인트와 마찬가지로 AWS 내에서도 S3 내에서 데이터를 분류하고 data loss prevention 을 실행하여 유출 시도를 차단할 수 있으며, 그렇게 해야 합니다.
귀사의 조직에서 이러한 조치를 구현하는 방법에 대해 문의하세요.
블로그로 돌아가기