AWS 보안 문제가 계속 헤드라인을 장식하고 있으며, 패턴은 놀라울 정도로 일관되게 나타납니다: 클라우드 플랫폼 자체가 근본 원인이 되는 경우는 드뭅니다. Intruder의 2026 Cloud Security Index에 따르면, 구성 오류는 제공업체 전반에서 클라우드 계정의 80%에서 98%에 영향을 미치며, AWS는 6개 구성 오류 범주 중 5개에서 선두를 달리고 있습니다. 가장 일반적인 AWS 보안 문제 — 공개 S3 버킷, 과도하게 관대한 IAM, MFA 누락, 노출된 서비스 — 은 AWS 플랫폼 결함이 아닌 고객 측 구성 문제입니다.
이 가이드는 AWS 보안 문제의 주요 사항과 예방 방법을 다루며, 2025-2026년 침해 보고서와 CIS AWS Foundations Benchmark 감사에서 가장 자주 나타나는 문제를 매핑하고, 각각이 지속되는 이유를 설명하고, 위반이 되기 전에 각각을 예방하는 방법을 보여줍니다. AWS 공유 책임 모델에서 시작합니다. 그 경계가 대부분의 AWS 보안 위험이 실제로 시작되는 곳이기 때문입니다.
AWS 공유 책임 모델 이해
AWS 보안 문제를 논의할 때 기본 개념은 AWS 공유 책임 모델입니다. 이 모델은 AWS 생태계에서 누가 무엇을 보호하는지 정의하며, 놀라운 수의 AWS 보안 문제가 플랫폼 취약점이 아닌 이 경계의 오해 또는 오용에서 발생합니다.
AWS 공유 책임 모델이란
AWS 공유 책임 모델은 AWS가 보호하는 환경의 측면과 고객의 제어 하에 있는 측면을 명확히 개요를 보여줍니다:
- AWS는 클라우드 ‘의’ 보안을 담당 — 글로벌 클라우드 인프라스트럭처, 물리적 데이터 센터, 네트워크 하드웨어, 하이퍼바이저, 기반 서비스 계층.
- 고객은 클라우드 ‘내’ 보안을 담당 — 애플리케이션, 데이터, IAM 정책, 구성, 액세스 제어, 암호화, 배포 또는 관리하는 모든 것의 패치.
모델은 간단해 보이지만, 많은 AWS 보안 문제는 AWS의 책임이 끝나고 고객의 책임이 시작되는 위치에 대한 잘못된 가정에서 발생합니다.
AWS의 책임: 클라우드 ‘의’ 보안
AWS는 모든 서비스를 지원하는 코어 인프라스트럭처를 보호합니다:
- 데이터 센터의 물리적 보안
- 중복 전원, 네트워킹, HVAC 시스템
- 네트워크 세그멘테이션 및 DDoS 완화
- 하이퍼바이저 및 기반 서비스 계층
AWS는 이 인프라스트럭처를 지속적으로 모니터링, 테스트, 감사하여 ISO 27001, SOC 1/2/3, PCI DSS를 포함한 규정 준수 인증을 유지합니다. 그러나 이 강력한 기반이 있어도 고객 계층이 제대로 보호되지 않으면 보안 격차가 여전히 발생합니다.
고객의 책임: 클라우드 ‘내’ 보안
고객은 클라우드 애플리케이션, 데이터, 구성의 보안에 책임이 있습니다:
- S3, EC2, RDS와 같은 서비스의 적절한 구성
- Identity and Access Management(IAM) 정책 및 역할
- 입력 검증 및 안전한 코딩과 같은 애플리케이션 수준 보안(AWS 강화를 보완하는 애플리케이션 계층 제어에 대해서는 Node.js 보안 모범 사례 및 프로덕션 Node.js 보안 심층 분석 참조)
- 운영 체제 및 소프트웨어 스택의 패치 및 유지 관리
- 저장 시 및 전송 시 암호화를 통한 민감한 데이터 보호
AWS에서 생성, 관리 또는 구성할 수 있다면 그것을 보호할 책임이 있을 가능성이 높습니다. 이것이 AWS 보안 문제의 대부분이 발생하는 곳입니다. 공개 읽기 또는 쓰기 액세스를 허용하는 잘못 구성된 S3 버킷은 AWS의 잘못이 아닌 고객 측 구성 오류입니다.
위험으로 이어지는 오해
AWS 보안 문제의 상당 부분은 정교한 공격이나 제로데이 익스플로잇이 아닌 인적 오류와 책임 모델의 오해로 인해 발생합니다. 많은 조직은 AWS가 “모든 것을 처리한다”는 잘못된 믿음으로 운영되고 있으며, 이는 사실이 아닙니다.
일반적인 예는 다음과 같습니다:
- S3 버킷 유출 — 제어 없이 공개 액세스가 활성화되어 민감한 데이터가 노출됩니다.
- IAM 역할 남용 —
"Action": "*"、"Resource": "*"와 같은 과도하게 관대한 정책이 권한 상승의 문을 엽니다. - 패치되지 않은 EC2 인스턴스 — 공격자가 발견 후 몇 분 내에 악용하는 알려진 CVE가 있는 오래된 운영 체제.
AWS가 모든 수준에서 보안을 처리할 것이라고 가정하는 것은 위험한 사고방식이며 예방 가능한 보안 실패로 직결됩니다.
현실 세계의 비유
AWS를 안전한 아파트 건물로 생각해 보십시오. AWS는 정문 잠금장치가 작동하고, 화재 경보가 작동하며, 건물에 24시간 보안이 있는지 확인합니다. 아파트(클라우드 계정 또는 리소스)를 임대하면 창문을 잠그고, 블라인드를 닫고, 필요시 금고를 설치하는 것은 귀하의 몫입니다. 이러한 책임을 무시하면 정문을 열어두는 것과 마찬가지로 침해로 이어집니다.
교육이 중요한 이유
클라우드 환경은 빠르게 움직이고 배포 주기는 짧습니다. AWS 책임에 대한 적절한 교육이 없으면 선의의 엔지니어도 서비스를 노출하거나 부적절하게 구성하여 심각한 AWS 보안 위험을 도입할 수 있습니다. AWS는 정기적으로 새로운 서비스와 기능을 도입하며, 적응하지 못하면 종종 오래된 관행으로 이어집니다 — 클라우드 보안 과제의 또 다른 원인입니다.
2025-2026년 주요 AWS 보안 문제
AWS가 가장 안전한 클라우드 플랫폼 중 하나임에도 불구하고 AWS 보안 위험은 여전히 자주 발생합니다 — 플랫폼 결함이 아닌 사용자가 클라우드 환경을 구성하고 관리하는 방식 때문입니다. 아래는 실제 영향과 예방 전략을 포함한 가장 시급하고 일반적으로 발생하는 문제입니다.
1. S3 버킷 구성 오류
가장 악명 높은 AWS 보안 위험은 Amazon S3 버킷의 구성 오류입니다. 이러한 스토리지 리소스는 강력하지만 제대로 보호되지 않으면 위험합니다.
많은 침해에서 S3 버킷이 의도치 않게 공개 액세스를 허용하도록 설정되어 URL을 가진 사람은 누구나 데이터를 읽고 때로는 쓸 수 있습니다. Verizon과 Accenture는 이 문제로 유명한 데이터 유출을 겪었습니다.
중요한 업데이트: 2023년 4월 5일부터 AWS는 새 버킷에 대해 S3 Block Public Access를 활성화하고 ACL을 기본적으로 비활성화합니다. 그러나 이 기본값은 소급되지 않습니다. 그 날짜 이전에 생성된 버킷은 Block Public Access를 명시적으로 활성화하지 않는 한 원래의 공개 액세스 설정을 유지합니다. 2023년 이전 버킷은 여전히 S3 데이터 유출의 일반적인 원인입니다.
Verizon 사례와 Accenture 사례를 참조하십시오.
왜 발생하는가
- 2023년 이전 버킷의 기본 또는 상속된 권한
- 공개 액세스 설정에 대한 가시성 부족
- AWS 액세스 정책 경고 간과
예방 방법
- 계정 수준에서 S3 Block Public Access 활성화 — 2023년 이전 버킷을 포함한 모든 버킷을 커버합니다
- AWS Config를 사용하여 오픈 버킷 모니터링
- 최소 권한 원칙을 따르는 버킷 정책 적용
- S3 버킷의 기본 암호화 활성화
2. 과도하게 관대한 IAM 정책
AWS 보안 문제의 또 다른 일반적인 벡터는 광범위하거나 관대한 IAM 정책의 사용입니다. 많은 팀이 "Effect": "Allow"、"Action": "*"、"Resource": "*"로 정책을 할당합니다 — 이는 사실상 무제한 액세스를 부여합니다.
이 설정은 보안 시한폭탄을 만들어 내부 또는 외부 행위자가 권한을 높이거나 의도하지 않은 리소스에 액세스할 수 있게 합니다. 2026 Cloud Security Index에 따르면 IAM Policy Allows Privilege Escalation은 AWS 계정의 83%에 영향을 미치고 IAM Access Key Not Rotated는 71%에 영향을 미칩니다.
결과에는 다음이 포함됩니다
- 완전한 계정 탈취
- 무단 데이터 액세스
- 서비스 간 측면 이동
모범 사례
- 최소 권한 액세스 구현 — 권한 없이 시작하고 필요한 것만 추가
- IAM Access Analyzer로 IAM 역할 및 정책 정기 감사
- 중앙 집중식 사용자 액세스를 위한 AWS Identity Center(이전 SSO) 사용
- 정책을 사용자에게 직접 첨부하지 않고 역할 사용
3. 루트 및 IAM 사용자의 MFA 누락
다중 인증(MFA)은 AWS에서 가장 간단하고 효과적인 제어 중 하나이지만 여전히 충분히 시행되지 않고 있습니다. 2026 Cloud Security Index는 Root Access Not Centrally Managed가 AWS 계정의 72%에 영향을 미친다는 것을 발견했습니다.
AWS 루트 계정은 계정의 모든 리소스에 대한 완전하고 무제한적인 액세스 권한을 가집니다. 공격자가 MFA 없이 루트 자격 증명을 손상시키면 계정은 사실상 손실됩니다. 관리자 권한을 가진 IAM 사용자에게도 동일하게 적용됩니다.
예방 방법
- 루트 계정에서 MFA를 즉시 활성화하고 복구 코드를 안전하게 저장
- 관리자 또는 쓰기 액세스 권한이 있는 모든 IAM 사용자에 MFA 강제
- AWS Identity Center를 사용하여 조직 전체에서 MFA를 중앙에서 강제
- 루트 사용자의 IAM 액세스 키를 비활성화하거나 제거 — 루트는 콘솔 + MFA만 사용해야 함
4. 암호화 누락
암호화를 간과하는 것은 심각한 AWS 보안 문제입니다. 저장 시 또는 전송 시 데이터를 암호화하지 않으면 가로채기, 조작, 노출의 문이 열립니다. AWS는 KMS(Key Management Service) 및 전송 시 TLS와 같은 서비스를 제공하지만 암호화는 항상 기본적으로 적용되지 않습니다.
암호화가 자주 건너뛰어지는 곳
- EBS 볼륨
- RDS 스냅샷
- Lambda 환경 변수
- 2023년 이전 버킷의 S3 객체
완화 팁
- 계정 또는 서비스 수준에서 S3, EBS, RDS의 기본 암호화 활성화
- 키 회전 및 액세스에 대한 더 엄격한 제어를 위해 고객 관리형 키(CMK) 사용
- KMS를 통해 암호화 키를 정기적으로 회전
- 모든 API 호출 및 데이터베이스 연결에 대한 전송 시 TLS 강제
5. 안전하지 않은 API 및 노출된 엔드포인트
조직이 마이크로서비스 및 서버리스 아키텍처를 채택함에 따라 AWS 보안 위험의 공격 표면이 증가합니다. API Gateway 및 Lambda 엔드포인트는 이 표면이 성장하는 주요 방법입니다.
보호되지 않거나 약하게 인증된 API는 자동 스캔 도구를 사용하는 공격자에 의해 발견되고 악용될 수 있습니다. 발견되면 데이터 추출, 무차별 대입 공격 또는 서비스 중단에 사용될 수 있습니다. 2026 Cloud Security Index는 76%의 AWS 계정이 적어도 하나의 공개 서비스를 가지고 있다는 것을 발견했습니다.
기여 요인
- 인증 없음 또는 약한 API 키 사용
- 속도 제한 또는 스로틀링 부족
- 과도하게 노출된 CORS 정책
API를 보호하는 방법
- Amazon Cognito 또는 IAM 기반 인증 활성화
- WAF(Web Application Firewall) 규칙 구현
- AWS CloudWatch 및 GuardDuty로 모니터링
- API Gateway 수준에서 속도 제한 및 요청 스로틀링 적용
6. 패치되지 않은 EC2 인스턴스 및 AMI
AWS가 물리적 인프라를 처리하더라도 EC2 인스턴스는 여전히 고객의 책임입니다. 이들은 부적절한 패치 관리로 인한 AWS 보안 위험의 가장 일반적인 원인 중 하나를 나타냅니다.
인스턴스가 오래된 운영 체제 또는 취약한 소프트웨어를 실행하면 공격자는 알려진 CVE(Common Vulnerabilities and Exposures)를 악용할 수 있습니다. 이러한 취약점은 종종 발견 후 몇 분 내에 대상이 됩니다.
일반적인 원인
- 업데이트 없는 오래된 AMI 사용
- 패치 자동화 부족
- 공급업체 보안 게시판 무시
수정 방법
- AWS Systems Manager Patch Manager를 사용하여 패치 자동화
- AMI를 정기적으로 업데이트 및 회전
- 가능한 경우 자동 보안 업데이트 적용
- AWS Security Bulletins 구독
7. 최소 권한 원칙 무시
너무 자주 조직은 사용자와 서비스에 필요 이상의 액세스를 부여합니다. 우발적이든 악의적이든 이는 오용 가능성을 높입니다. 이는 AWS 보안 위험에 조용하지만 중요한 기여 요인입니다.
결과에는 다음이 포함됩니다
- 위협 행위자에 의한 권한 상승
- 범위가 넓은 역할로 인한 데이터 유출
- 침해 시 blast radius 증가
해결하려면
- IAM Access Analyzer로 IAM 권한 정기 검토
- 권한 경계 및 속성 기반 액세스 제어(ABAC) 사용
- 최소 권한 강제를 CI/CD 파이프라인에 통합
- deny-by-default 자세를 채택하고 정당화될 때만 권한 추가
8. 보안 그룹 및 네트워크 ACL 구성 오류
더 미묘하지만 위험한 AWS 보안 위험 중 하나는 Amazon VPC 내에서 잘못 구성된 보안 그룹 및 네트워크 액세스 제어 목록(ACL)을 포함합니다.
많은 조직이 포트를 넓게 열어 두며, 특히 SSH(포트 22), RDP(포트 3389) 또는 0.0.0.0/0과 같은 CIDR 블록 전체를 열어 둡니다. 2026 Cloud Security Index는 Permissive Ingress to Sensitive Ports가 AWS 계정의 84%에 영향을 미치고 VPC Subnet Auto-Assigns Public IP가 72%에 영향을 미친다는 것을 발견했습니다.
자주 발생하는 문제
- “모두 허용” 규칙의 과도한 사용
- 아웃바운드 트래픽 제한을 잊음
- 내부 서비스의 적절한 세그멘테이션 부족
- 프라이빗이어야 할 서브넷에 공개 IP 자동 할당
주요 안전장치
- default deny 접근 방식을 적용하고 알려진 CIDR의 필요한 포트만 허용
- VPC 플로우 로그를 사용하여 트래픽 패턴 감사
- 민감한 서비스에 Network Firewall 및 PrivateLink 구현
- 프라이빗 서브넷에서 공개 IP 자동 할당 비활성화
AWS 보안 모범 사례
AWS 보안 위험을 예방하는 것은 바퀴를 재발명할 필요가 없습니다. 일관성, 가시성, 입증된 모범 사례 준수가 필요합니다. 아래 전략을 사전에 구현함으로써 조직은 AWS에서 구성 오류 및 규정 준수 실패의 가능성을 극적으로 줄일 수 있습니다.
최소 권한 원칙 강제
AWS 보안 위험의 반복적인 근본 원인은 과도한 액세스입니다. 항상 최소 권한 원칙을 따르십시오: 사용자와 서비스는 절대적으로 필요한 권한만 받아야 합니다. IAM 역할, 권한 경계 및 세분화된 액세스 제어를 사용하여 각 엔티티가 수행할 수 있는 작업을 제한합니다.
팁: IAM Access Analyzer를 사용하여 의도하지 않은 액세스를 탐지하고 수정합니다.
로깅 및 지속적인 모니터링 활성화
많은 조직이 적절한 가시성이 없어 침해 탐지가 지연됩니다. AWS CloudTrail, Amazon GuardDuty, AWS Config를 활성화하면 환경 전체에서 활동을 추적하고 이상을 탐지하며 내부 정책과 외부 규정 모두에 대한 규정 준수를 유지할 수 있습니다.
주요 이점: 잠재적인 AWS 보안 위험이 에스컬레이션되기 전에 실시간 알림을 받습니다.
보안 검사 자동화
수동 검토는 클라우드 환경에서 확장 가능하지 않습니다. AWS Config Rules, Inspector, Security Hub를 사용하여 기준 보안 구성을 자동으로 강제할 수 있습니다. 이러한 도구는 오픈 포트, 암호화 누락, 공개적으로 액세스 가능한 리소스와 같은 보안 구성 오류를 탐지합니다.
보너스: 개발 중 조기 탐지를 위해 이러한 검사를 CI/CD 파이프라인에 통합합니다.
모든 것을 암호화 — 항상
암호화는 가장 간단하지만 가장 효과적인 방어 형태 중 하나입니다. AWS Key Management Service(KMS) 또는 고객 관리형 키를 사용하여 저장 시 및 전송 시 모든 데이터를 암호화하십시오. S3, RDS, EBS 볼륨과 같은 서비스에 대한 기본 암호화를 활성화합니다.
리마인더: 암호화 누락은 유명한 AWS 보안 사건의 반복되는 주제입니다.
자격 증명을 정기적으로 감사 및 회전
오래된 자격 증명과 회전되지 않은 키는 손상 위험을 높입니다. 2026 Cloud Security Index는 IAM Access Key Not Rotated가 AWS 계정의 71%에 영향을 미친다는 것을 발견했습니다. IAM 사용자를 정기적으로 감사하고 사용하지 않는 계정을 비활성화하고 AWS Secrets Manager를 사용하여 비밀을 회전합니다.
이러한 관행을 운영화하는 방법에 대한 보다 넓은 프로그램 수준 보기는 클라우드 보안 관리 서비스 가이드를 참조하십시오. AWS에서 AI 워크로드도 구축하고 있다면 에이전트 AI용 LLM 보안 가이드는 AI 게이트웨이와 에이전트가 도입하는 추가 위험을 다룹니다.
AWS 보안을 강화하는 도구 및 리소스
AWS 보안 위험을 최소화하는 데 있어 적절한 도구가 모든 차이를 만듭니다. AWS는 요구 사항에 가장 적합한 서비스를 선택할 수 있는 강력한 네이티브 서비스 생태계를 제공합니다.
AWS Security Hub
AWS Security Hub는 GuardDuty, Inspector, 서드파티 도구와 같은 여러 서비스의 결과를 단일 대시보드로 집계합니다. CIS AWS Foundations Benchmark와 같은 업계 표준을 사용하여 환경을 평가하고 중요한 AWS 보안 위험을 식별합니다.
핵심 이점
- AWS 계정 전반에 걸친 통합 가시성
- 자동화된 규정 준수 검사
- 티켓팅 시스템 및 SOAR 도구와의 통합
Amazon GuardDuty
이 위협 탐지 서비스는 포트 스캔, 자격 증명 손상 시도, 악성 IP 주소의 액세스와 같은 비정상적인 활동을 식별하기 위해 머신 러닝을 사용합니다. AWS의 실시간 위협에 대한 최초의 방어선 중 하나입니다.
사용 이유
- 성능에 영향 없음
- 계정 손상, EC2 남용 등 탐지
- EventBridge를 통해 실행 가능한 알림 전송
AWS Config 및 Config Rules
보안 구성 오류는 AWS Config로 조기에 탐지할 수 있습니다. 이 도구는 AWS 리소스의 변경 사항을 추적하고 사전 정의된 또는 사용자 정의 규칙에 대해 평가합니다. 공개 S3 버킷 또는 암호화되지 않은 볼륨과 같은 보안 문제를 거의 실시간으로 식별할 수 있습니다.
사용 사례
- 기준 구성에서의 드리프트 탐지
- Lambda 함수를 사용한 자동 수정
- 거버넌스를 위한 감사 추적
IAM Access Analyzer
가장 일반적인 AWS 보안 위험 중 하나는 과도하게 관대한 액세스입니다. IAM Access Analyzer는 외부와 공유된 리소스 또는 과도하게 광범위한 권한을 가진 리소스를 발견하는 데 도움이 됩니다.
주요 기능
- IAM 역할, 정책, 리소스 공유 스캔
- 과도한 권한 플래그
- AWS Organizations와 통합
CloudTrail 및 CloudWatch
포렌식 분석 및 활동 추적을 위해 CloudTrail은 AWS 환경에서 수행된 모든 API 호출을 로깅합니다. CloudWatch는 모니터링 및 알림 기능을 제공합니다.
결합하여 가능한 작업
- 무단 액세스 시도 탐지
- 보안 관련 작업에 대한 알람 설정
- 감사 및 규정 준수 요구 사항 충족
AWS Trusted Advisor
AWS Trusted Advisor는 노출된 포트, 루트 계정의 MFA, IAM 사용과 같은 보안 구성 검사를 포함한 AWS 모범 사례에 기반한 인사이트를 제공합니다.
관련성
- AWS Business 및 Enterprise Support 플랜에 내장
- 보안, 비용, 내결함성, 성능 커버
- 수정 작업 우선순위 지정 도움
AWS 보안 문제의 현실 세계 사례
이론을 이해하는 것은 한 가지입니다; 현실 세계에서 결과를 보는 것은 교훈을 훨씬 구체적으로 만듭니다. 이러한 사건은 모두 더 나은 관행으로 피할 수 있었던 AWS 보안 위험에서 비롯되었습니다.
Capital One 데이터 침해(2019): IAM 구성 오류 및 SSRF
역사상 가장 악명 높은 AWS 보안 문제 중 하나는 Capital One과 관련되어 있으며, 전직 AWS 직원이 취약점을 악용하여 1억 개 이상의 고객 레코드에 액세스했습니다.
잘못된 것
- EC2 인스턴스에 과도하게 관대한 IAM 역할이 있어 민감한 S3 버킷에 대한 액세스를 허용했습니다.
- 공격자는 **서버 측 요청 위조(SSRF)**를 사용하여 인스턴스에 자격 증명을 발행하도록 속였습니다.
- 로깅이 완전히 중앙 집중화되지 않아 탐지가 지연되었습니다.
교훈: 항상 IAM 역할을 검토하고, 최소 권한 원칙을 적용하고, 비정상적인 요청 패턴을 모니터링하십시오.
Accenture의 S3 노출(2017): 공개 버킷이 민감한 데이터 노출
글로벌 IT 컨설팅 회사 Accenture는 여러 S3 버킷을 공개적으로 액세스 가능하게 남겨두었으며, 내부 액세스 키, API 데이터, 고객 자격 증명을 포함하고 있었습니다. 이러한 구성 오류는 버킷 수준 액세스 정책 및 모니터링 부족에서 비롯되었습니다.
수정: 엄격한 액세스 제어를 가진 S3 버킷 정책을 사용하고 AWS Config를 활용하여 실시간으로 공개 노출을 탐지합니다.
Booz Allen Hamilton 유출(2017): 정부 데이터가 포함된 오픈 S3 버킷
또 다른 주요 컨설팅 회사 Booz Allen Hamilton은 오픈 S3 버킷으로 인해 분류된 군사 파일 및 자격 증명을 무심코 유출했습니다. 침해는 내부 모니터링 도구가 아닌 보안 연구원에 의해 발견되었습니다.
배운 교훈: 의도적이고 감사된 결정 없이는 인터넷에 리소스를 노출시켜서는 안 됩니다. Default-deny 정책과 자동 수정 도구는 유사한 AWS 보안 위험을 방지할 수 있습니다.
공급망 자격 증명 유출(2026): AI 게이트웨이가 AWS 자격 증명 노출
2026년, 위협 인텔리전스 회사 CloudSEK은 인기 있는 AI 게이트웨이 라이브러리를 통한 공급망 공격을 추적하여 2,500개 이상의 조직과 약 434,000개의 CI/CD 파이프라인에서 클라우드 자격 증명, SSH 키, Kubernetes 토큰을 노출시켰습니다. AWS 플랫폼 결함은 아니지만 이 사건은 AWS 자격 증명이 서드파티 도구를 통해 유출될 수 있음을 보여줍니다 — AWS 콘솔을 넘어서는 비밀 관리 및 자격 증명 위생이 중요함을 상기시킵니다.
배운 교훈: AWS 자격 증명을 비밀 관리자에 저장하고 리포지토리에 커밋된 환경 파일에 저장하지 않으며 키를 정기적으로 회전합니다. 클라우드 자격 증명에 액세스하는 서드파티 라이브러리를 공격 표면의 일부로 취급합니다.
AWS 보안 체크리스트
이 체크리스트를 사용하여 AWS 환경을 가장 일반적인 AWS 보안 위험에 대해 감사하십시오:
- 계정 수준에서 S3 Block Public Access 활성화(2023년 이전 버킷도 커버)
- 루트 계정에서 MFA 강제 및 쓰기 액세스가 있는 모든 IAM 사용자
- 최소 권한 IAM 적용 —
"Action": "*", "Resource": "*"정책 없음 - 기본 암호화를 S3, EBS, RDS에서 활성화
- 보안 그룹 제한 — SSH, RDP 또는 데이터베이스 포트에
0.0.0.0/0없음 - 공개 IP 자동 할당을 프라이빗 서브넷에서 비활성화
- 모든 리전에서 CloudTrail 활성화하여 API 호출 로깅
- 위협 탐지를 위해 GuardDuty 활성화
- CIS AWS Foundations Benchmark 규칙으로 AWS Config 활성화
- Security Hub를 실행하여 계정 간 결과 집계
- IAM 액세스 키를 최소 90일마다 회전
- 애플리케이션 비밀에 AWS Secrets Manager 사용, 리포지토리의
.env파일이 아닌 - Systems Manager Patch Manager로 EC2 인스턴스 패치
- AWS Security Bulletins 구독 및 중요 CVE에 대응
자주 묻는 질문
가장 일반적인 AWS 보안 문제는 무엇입니까?
가장 일반적인 AWS 보안 문제는 S3 버킷 구성 오류, 과도하게 관대한 IAM 정책, 루트 및 IAM 사용자의 MFA 누락, 저장 시 및 전송 시 데이터 암호화 누락, 노출된 API 및 엔드포인트, 패치되지 않은 EC2 인스턴스, 보안 그룹 및 네트워크 ACL 구성 오류입니다. 이들 대부분은 AWS 플랫폼 결함이 아닌 고객 측 구성 오류에서 비롯됩니다.
AWS 공유 책임 모델이란 무엇입니까?
AWS 공유 책임 모델은 AWS가 무엇을 보호하고 고객이 무엇을 보호하는지 정의합니다: AWS는 클라우드 ‘의’ 보안(물리적 데이터 센터, 네트워크 하드웨어, 하이퍼바이저, 기반 서비스)을 담당하고, 고객은 클라우드 ‘내’ 보안(애플리케이션, 데이터, IAM, 구성, 암호화, 패치)을 담당합니다. 대부분의 AWS 보안 문제는 이 경계의 오해에서 발생합니다.
AWS 보안 문제를 어떻게 예방합니까?
AWS 보안 문제를 예방하려면 최소 권한 IAM을 강제하고, 모든 사용자에게 MFA를 활성화하고, 계정 수준에서 S3 Block Public Access를 활성화하고, 저장 시 및 전송 시 데이터를 암호화하고, CloudTrail 및 GuardDuty로 지속적으로 모니터링하고, AWS Config 및 Security Hub로 보안 검사를 자동화하고, IAM 액세스 키 및 비밀을 정기적으로 회전시킵니다.
AWS는 기본적으로 안전합니까?
AWS는 기본적으로 안전하지 않지만 완전히 안전하지도 않습니다. AWS는 기반 인프라를 보호하지만, 2023년 4월 이전에 생성된 S3 버킷, IAM 정책, 보안 그룹, 암호화 설정과 같은 많은 서비스는 고객이 안전한 구성을 적용해야 합니다. 기본 설정이 개선되었지만 고객 측 구성 오류가 여전히 AWS 침해의 주요 원인입니다.
Capital One AWS 침해는 무엇입니까?
2019년 Capital One 침해는 1억 개 이상의 고객 레코드를 노출시켰습니다. 공격자는 과도하게 관대한 IAM 역할을 가진 EC2 인스턴스의 서버 측 요청 위조(SSRF) 취약점을 악용한 다음 인스턴스의 자격 증명을 사용하여 민감한 S3 데이터를 읽었습니다. 근본 원인은 SSRF, 과도한 IAM 권한, 지연된 탐지의 조합 — 모두 고객 측 AWS 보안 문제였습니다.
AWS Block Public Access가 기본적으로 S3 유출을 방지합니까?
2023년 4월 5일부터 AWS는 새 버킷에 대해 S3 Block Public Access를 활성화하고 ACL을 기본적으로 비활성화합니다. 그러나 이 기본값은 소급되지 않습니다 — 그 날짜 이전에 생성된 버킷은 계정 또는 버킷 수준에서 Block Public Access를 명시적으로 활성화하지 않는 한 원래의 공개 액세스 설정을 유지합니다. 2023년 이전 버킷은 여전히 S3 데이터 유출의 일반적인 원인입니다.
결론
AWS 환경을 보호하는 것은 AWS의 내장 보호에 의존하는 것 이상을 필요로 합니다. 이 가이드가 보여주듯이, 2025-2026년의 가장 일반적인 AWS 보안 문제 — S3 구성 오류, 과도하게 관대한 IAM, MFA 누락, 노출된 서비스, 패치되지 않은 인스턴스, 약한 네트워크 제어 — 는 고객 측 문제이며 고객 측 규율로 예방할 수 있습니다. AWS 공유 책임 모델에서 시작하고, 최소 권한을 강제하고, 모든 것을 암호화하고, 보안 검사를 자동화하고, 자격 증명을 공격 표면의 일부로 취급하십시오. 위의 체크리스트는 실용적인 출발점입니다; 오늘 계정에 대해 실행하십시오.
AWS 환경 강화 또는 안전한 클라우드 워크로드 구축에 도움이 필요하시면 HDWEBSOFT는 AWS 개발 서비스 및 사이버 보안 서비스를 제공합니다.
