클라우드 보안 설정 실수 8가지 — 지금 당장 확인할 체크리스트 (2026)

2025년 1월, 한 보안 연구팀(Wiz)이 DeepSeek의 데이터베이스 하나를 찾아냈다. 비밀번호도, 방화벽도 없었다. URL만 알면 누구나 브라우저로 들어가 사용자 채팅 로그와 API 키를 그대로 볼 수 있었다. 공격자가 무언가를 "뚫은" 게 아니다. 문이 처음부터 열려 있었을 뿐이다.

우리는 데이터 유출 소식을 들으면 반사적으로 "해킹당했다"고 말한다. 그런데 클라우드에서는 그 표현이 대부분 틀렸다. 침입(intrusion)이 아니라 노출(exposure)이다. 시장조사기관 Gartner는 일찍이 "2025년까지 클라우드 보안 실패의 99%는 클라우드 제공사가 아니라 고객 측 책임이며, 그 핵심은 설정 오류"라고 못 박았다. 2026년이 된 지금도 이 진단은 거의 그대로 유효하다.

그렇다면 중소 팀이나 혼자 서버를 운영하는 사람이 오늘 점검해야 할 건 무엇일까. 화려한 제로트러스트 전략이 아니라, 콘솔에서 클릭 몇 번이면 닫히는 문 여덟 개다.

사고의 99%는 침입이 아니라 노출이다

이 차이가 왜 중요할까. 침입이라면 더 두꺼운 벽, 즉 더 비싼 보안 장비가 답일 것이다. 하지만 노출이라면 답은 정반대다. 이미 가진 설정을 제대로 잠그는 일이 먼저다.

숫자가 이 방향을 가리킨다. 보안업체 SentinelOne 분석에서 클라우드 보안 실패의 95%는 소프트웨어 결함이 아니라 사람의 설정 실수에서 비롯됐다. Datadog의 2024년 클라우드 보안 리포트는 전체 AWS S3 버킷의 1.48%가 "사실상 공개" 상태라고 측정했다. 1.48%가 작아 보이는가. 전 세계 버킷 수를 떠올리면 수십만 개의 저장소가 인터넷에 열려 있다는 뜻이다. Tenable의 2025년 조사에서는 공개 접근이 가능한 클라우드 스토리지의 9%가 실제 민감 데이터를 담고 있었다.

이게 추상적인 통계만은 아니다. 2024년 호주축구협회(Football Australia)는 웹사이트 소스코드에 평문 키를 그대로 노출했고, 그 키 하나로 127개의 스토리지 컨테이너 — 선수 개인정보까지 — 가 열렸다(CSA Top Threats Deep Dive 2025). 같은 해 페가수스항공은 잘못 설정된 S3 버킷에서 6.5TB가 빠져나갔다. 공통점은 하나다. 누가 침입한 게 아니라, 내부에서 문을 열어둔 채 잊어버렸다는 것.

지금 당장 점검할 설정 실수 8가지

아래 표를 먼저 훑어보자. 콘솔을 열고 위에서부터 하나씩 확인하면 된다. 대부분 몇 분이면 닫힌다.

여덟 개가 모두 똑같이 급한 건 아니다. 실제 사고 빈도와 피해 규모로 보면 1·2·3번이 압도적이다. 이 셋만 깊게 보자.

① 버킷 공개 — "혹시" 말고 지금 확인

가장 흔하고 가장 치명적이다. 문제는 사람들이 버킷을 일부러 공개하지 않는다는 데 있다. 정적 파일 하나 테스트하려고 잠깐 열어두고 잊는다. 그 "잠깐"이 몇 달이 된다. AWS라면 계정 전체에 S3 Block Public Access를 켜는 게 1차 방어선이다. 개별 버킷 정책보다 계정 단위 설정이 우선이라, 실수로 버킷을 공개해도 막아준다.

aws s3api get-public-access-block --bucket my-bucket
aws s3api put-public-access-block --bucket my-bucket \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

설정 방법은 AWS 공식 문서에 정리돼 있다. GCP·Azure도 각각 "공개 액세스 방지" 옵션이 있으니 이름만 다를 뿐 동일하게 켜자.

② 키 하드코딩 — 지우는 게 아니라 폐기하는 것

여기서 가장 많이 하는 착각. 키를 실수로 커밋한 걸 발견하면 사람들은 그 줄을 지우고 다시 커밋한다. 소용없다. 깃 히스토리에는 그대로 남고, 포크된 저장소엔 영구 보존된다. 게다가 공개 저장소는 커밋 후 수 분 안에 자동화된 봇이 스캔한다. 그래서 유출이 의심되면 순서가 정해져 있다. 삭제가 아니라 폐기(revoke)부터.

③ MFA — 비밀번호 하나에 회사를 거는 일

특히 루트 계정. 루트는 모든 권한을 가지므로, 여기에 MFA가 없으면 비밀번호 하나가 곧 회사 전체다. 무료다. 5분이면 끝난다. 그런데 의외로 1인 운영자·소규모 팀에서 가장 자주 빠진다. "나중에 해야지" 하고 미뤄둔 그 계정이 보통 가장 위험하다. 루트는 평소 쓰지 말고, 일상 작업은 권한을 좁힌 IAM 사용자로 — 그 사용자에게도 MFA를.

그래도 뚫렸다면 — 처음 10분

예방이 전부 막아주진 않는다. 온라인에서 크게 화제가 된 사례 하나. 한 학생 개발자가 Gemini API 키를 GitHub에 실수로 올렸다. 키가 노출된 동안 외부에서 비정상 호출이 폭증했고, 청구서에는 약 55,444달러(8,150만 원)가 찍혔다. 다행히 유출 정황이 입증돼 전액 면제됐지만, 모두가 이렇게 운이 좋진 않다. 사고가 터졌을 때 첫 10분에 할 일은 이렇다.

7번(로깅)을 가장 지루한 항목으로 미뤄두는 사람이 많다. 하지만 사고가 났을 때 로그가 없으면, 무엇이 털렸는지조차 영원히 알 수 없다. 평소엔 안 보이다가 그 순간에만 가치가 드러난다.

도구를 더 사기 전에

여기서 솔직해지자. 보안 사고가 나면 가장 먼저 떠오르는 건 "솔루션을 도입하자"다. 그런데 통계는 다른 말을 한다. Fortinet의 2026년 조사에서 응답 기업의 69%가 이미 도구 과잉(tool sprawl)을 보안의 가장 큰 장벽으로 꼽았다. 도구가 모자라서가 아니라, 너무 많아서 무엇이 켜져 있는지 모르는 상태인 것이다.

물론 CSPM 같은 자동 점검 도구는 규모가 커지면 분명 필요하다. 다만 순서가 있다. 위 8가지는 전부 제공사 콘솔의 기본 기능이고, 대부분 무료이며, 추가 솔루션 없이 오늘 닫을 수 있다. 비싼 자물쇠를 사기 전에, 이미 달려 있는 자물쇠부터 잠그는 게 먼저다. 보안 일반에 관심이 있다면 JUNAI 블로그의 다른 인프라·보안 글도 함께 참고할 만하다.

마무리

다시 처음의 DeepSeek 데이터베이스로 돌아가 보자. 그 사고를 막는 데 필요했던 건 최신 위협 인텔리전스도, 전담 보안팀도 아니었다. 인증을 켜는 것, 단 하나였다.

지금 이 글을 읽는 당신의 계정에도 아마 열려 있는 문이 하나쯤 있을 것이다. 루트에 MFA는 켜져 있는가. 작년에 테스트하려고 잠깐 열어둔 그 버킷은 닫았는가. 가장 위험한 건 모르는 위협이 아니라, 알면서 "나중에" 미뤄둔 익숙한 설정이다. 오늘 표의 여덟 줄 중, 한 줄이라도 지금 확인해보길.

참고 자료: Gartner Cloud Security Prediction · IBM Cost of a Data Breach Report 2025 · Datadog State of Cloud Security 2024 · Tenable 2025 Cloud Security Risk Report · Cloud Security Alliance Top Threats Deep Dive 2025. 본문 수치는 작성일(2026-06) 기준 공개 자료를 인용했으며, 클라우드 제공사별 설정 명칭은 다를 수 있습니다.