AWS·Azure·GCP 클라우드 보안 설정 실수 Top 7

클라우드는 편리하지만 설정이 잘못되면 순식간에 전체 인프라가 노출될 수 있다. Gartner는 클라우드 보안 실패의 대부분이 제공업체가 아닌 고객 측 설정 오류에서 비롯될 것이라고 오래전부터 전망해 왔다. 실제 2026년 조사에서도 취약한 IAM 통제와 로깅 누락이 계정의 80~98%에 영향을 미치는 것으로 나타났다. 실제 사고로 이어진 대표적인 설정 실수 7가지를 살펴본다.

① S3 버킷 / Blob Storage 퍼블릭 공개

가장 고전적이면서도 여전히 발생하는 실수다. 개발 편의를 위해 버킷 접근 권한을 Public으로 설정한 채 운영 환경에 그대로 배포하는 경우가 많다.

• Block Public Access 옵션 계정 레벨에서 강제 활성화
• 버킷 정책에 aws:SecureTransport: false 차단 조건 추가
• AWS Config 규칙으로 퍼블릭 버킷 자동 탐지·알람

② IAM 과도한 권한 부여 (Overprivileged IAM)

서비스에 Administrator 권한을 부여하거나 *:* 와일드카드 정책을 사용하는 것은 사고 발생 시 피해를 폭발적으로 확산시킨다. 최소 권한 원칙(PoLP)을 철저히 적용해야 한다.

• IAM Access Analyzer로 미사용 권한 주기적 정리
• 서비스 계정에 PassRole·AssumeRole 권한 최소화
• 권한 경계(Permission Boundary) 설정으로 상위 권한 상승 차단

③ CloudTrail·감사 로그 비활성화

비용 절감을 이유로 로깅을 끄는 경우가 있다. 침해 발생 시 공격 경로 추적이 불가능해진다. CloudTrail은 반드시 All-region, Management Events 전체를 활성화해야 한다.

④ 루트 계정 상시 사용 및 MFA 미적용

AWS 루트 계정은 모든 권한을 가진 계정이다. 일상 업무에 사용하지 말고 MFA 디바이스를 반드시 연결해야 한다. 루트 계정 로그인 자체에 알람을 설정하는 것을 권장한다.

⑤ 보안 그룹 0.0.0.0/0 전면 개방

RDP(3389), SSH(22), DB 포트(3306, 5432, 1433)를 인터넷 전체에 개방하는 것은 자동화 스캐너의 즉각적인 표적이 된다.

⑥ 암호화 미적용 — 저장 데이터 & 전송 데이터

S3 버킷 서버사이드 암호화(SSE), RDS 스토리지 암호화, EBS 볼륨 암호화는 기본값으로 활성화해야 한다. 내부 서비스 간 통신도 TLS 1.2 이상을 강제해야 한다.

⑦ 멀티 계정 전략 미적용 및 환경 미분리

개발·스테이징·운영 환경을 동일 AWS 계정에서 운영하면 개발자 실수 또는 개발 환경 침해가 운영 환경까지 전파된다. AWS Organizations를 활용해 환경별 계정을 분리하고 SCP(서비스 제어 정책)를 적용해야 한다.

클라우드 보안 기본 도구

• AWS: Security Hub, Config, GuardDuty, Access Analyzer
• Azure: Defender for Cloud, Policy, Sentinel
• GCP: Security Command Center, Cloud Armor
• 멀티클라우드: Wiz, Orca Security, CSPM 전문 도구