당신의 클라우드 보안 체크리스트는 생각과 다르게 작동하고 있다

여러 클라우드 제공사에 걸쳐 보안을 관리하는 것도 충분히 어렵지만, 각 제공사는 서로 다른 방식으로 취약점을 드러냅니다. Intruder는 2026 Cloud Security Index를 위해 AWS, Azure, Google Cloud를 사용하는 3,000개 조직의 설정 오류 데이터를 분석했으며, 제공사 간 위험 프로파일이 거의 공통점이 없다는 사실을 발견했습니다. 데이터를 살펴보겠습니다.

클라우드 제공사별 위험의 차이

Intruder는 모든 설정 오류를 여섯 가지 범주로 분류했습니다: 취약한 IAM(계정 접근 권한 관리), 로그 미수집, 서비스 오설정, 허술한 방화벽, 서비스 노출, 약한 암호화. 각 범주별로 세 제공사에서 적어도 하나 이상의 문제가 있는 계정 비율을 비교했습니다.

취약한 IAM 통제와 로그 미수집은 제공사에 관계없이 80~98%의 계정에서 발견되어 사실상 보편적입니다. 나머지 네 범주에서는 편차가 크게 벌어집니다.

• 서비스 노출: AWS (76%), Azure (64%), Google Cloud (8%)
• 허술한 방화벽: AWS (83%), Azure (45%), Google Cloud (34%)
• 약한 암호화: AWS (49%), Azure (35%), Google Cloud (8%)
• 서비스 오설정: AWS (68%), Azure (80%), Google Cloud (37%)

가장 큰 격차는 서비스 노출 항목으로, AWS 76% 대 Google Cloud 8%입니다. 허술한 방화벽과 약한 암호화도 AWS가 가장 높고 Google Cloud가 가장 낮은 동일한 패턴을 보입니다. 서비스 오설정은 예외로, Azure가 80%로 1위이고 Google Cloud가 37%로 가장 낮습니다.

AWS가 여섯 개 범주 중 다섯 개에서 가장 높은 비율을 보이는 이유 중 하나는 서비스 종류가 가장 많기 때문입니다. 서비스가 많을수록 설정 옵션이 많아지고, 오설정의 기회도 늘어납니다.

Google Cloud는 다섯 개 범주에서 가장 낮은 비율을 보입니다 — 동시에 서비스 종류도 가장 적습니다. 낮은 비율은 공동 책임 모델에 대한 다른 접근 방식으로도 설명할 수 있습니다. Google Cloud의 Shared Fate 모델은 네트워크 노출과 암호화를 중심으로 더 안전한 기본값을 제공합니다.

각 플랫폼에서 이러한 범주가 실제로 어떤 설정 오류로 나타나는지 살펴보겠습니다.

AWS: 방화벽과 암호화

AWS 계정에서 가장 자주 발생하는 오류:

1. S3가 HTTPS를 강제하지 않음 — 87%
2. ACL을 통한 민감한 포트의 과도한 인바운드 허용 — 84%
3. 과도하게 허용적인 네트워크 ACL — 83%
4. 권한 상승을 허용하는 IAM 정책 — 83%
5. EC2용 VPC 엔드포인트 미설정 — 82%

S3 버킷에서 HTTPS를 강제하지 않는 것이 가장 많은 AWS 계정에 영향을 미치는 문제입니다. S3는 가장 널리 사용되는 클라우드 스토리지 서비스 중 하나이며, 중간자 공격(man-in-the-middle attack)이 드물긴 하지만 평문 HTTP를 열어둘 이유는 거의 없습니다.

권한 상승을 허용하는 IAM 정책은 83%의 계정에 영향을 미칩니다. AWS IAM은 복잡하기로 악명이 높으며, 안전해 보이는 관리형 정책도 의도보다 광범위한 권한을 부여할 수 있습니다. 최근 한 사건에서는 공격자가 노출된 자격 증명으로 시작하여 10분 만에 관리자 권한을 획득하여 AWS 보안 주체(principal) 19개를 침해했습니다.

Azure: 스토리지와 계정 보안

Azure 계정에서 가장 흔한 설정 오류:

1. 스토리지 계정 키 교체 미설정 — 67%
2. 스토리지 계정 액세스 키 활성화 — 66%
3. 스토리지 계정 공용 네트워크 접근 허용 — 61%
4. MFA(다중 인증)가 없는 Entra 사용자 — 55%
5. Trusted Launch 미설정 — 45%

상위 세 가지 문제는 모두 Azure Storage Account와 관련이 있으며, 이 서비스는 PII(개인 식별 정보)와 같은 민감한 데이터를 자주 보관합니다. 세 문제가 비슷한 비율의 계정에 영향을 미친다는 것은, 스토리지 계정이 강화되지 않은 곳에서는 여러 보안 통제가 동시에 빠져 있는 경향이 있음을 시사합니다.

절반 이상의 계정에서 MFA가 없는 Entra ID 사용자가 발견됐습니다. Entra ID는 클라우드 리소스뿐만 아니라 Microsoft 365, 서드파티 SaaS 앱, 온프레미스 시스템에 대한 접근까지 관장하기 때문에 주목할 필요가 있습니다. 2024년 Midnight Blizzard의 Microsoft 내부 네트워크 침해는 MFA가 없는 레거시 테스트 계정을 대상으로 한 비밀번호 스프레이 공격에서 시작됐습니다.

Google Cloud: IAM

Google Cloud의 상위 문제는 거의 모두 IAM으로 귀결됩니다:

1. OS Login MFA 미설정 — 77%
2. OS Login 미설정 — 76%
3. 미사용 서비스 계정 — 75%
4. 과도하게 허용적인 서비스 계정 — 53%
5. 민감한 포트에 대한 허용적인 인바운드 — 34%

3/4 이상의 계정에서 OS Login 통제가 누락되어 있으며, 이는 기존 SSH보다 안전한 대안 인증 수단입니다.

조직 규모에 따른 변화

대부분의 범주에서 조직이 클수록 문제 발생 비율이 낮아집니다. 대형 기업은 허술한 방화벽, 서비스 노출, 약한 암호화 문제가 상대적으로 적습니다.

예외는 IAM입니다. 취약한 IAM 통제는 중소기업(250명 미만)의 87%, 중간 규모 조직(2511만 명)의 95%, 대기업(1만10만 명 이상)의 98%에 영향을 미칩니다. 과도한 권한을 가진 계정 하나가 다른 곳에서 강화된 통제를 우회하기에 충분하다는 점에서 이는 중요한 사안입니다.

중간 규모 조직은 클라우드 문제 해결에도 평균 35일로 가장 오래 걸렸으며, 이는 소규모 기업의 8~16일, 대기업의 10일과 비교됩니다. 중간 규모 팀이 대기업 수준의 클라우드 복잡성을 전담 리소스 없이 관리하고 있음을 시사합니다.

보안팀을 위한 시사점

여러 제공사를 운영하는 팀에게 어려운 점은, 한정된 시간과 리소스를 올바른 곳에 투입하기 위해 전체 환경에서 어떤 위험이 가장 중요한지 파악하는 것입니다. 보안팀은 실제 문제를 해결하는 데 필요한 플랫폼별 세부 사항을 유지하면서도, 제공사 전반의 보안 상태를 일관되게 평가할 수 있는 방법이 필요합니다.

플랫폼별 상위 10개 설정 오류와 조직 규모별 클라우드 보안 현황을 포함한 전체 보고서는 Intruder의 2026 Cloud Security Index에서 확인할 수 있습니다.