클라우드 설정 오류: APAC에서 눈앞에 숨은 위험

클라우드는 속도에 보상을 줍니다. 한 팀이 하루 오후 만에 완전한 프로덕션 환경을 세울 수 있습니다. 컴퓨트, 스토리지, 데이터베이스, 로드밸런서 전부 CLI 명령 하나나 Terraform 파일 하나로요. 같은 속도가 실수에도 적용됩니다. 데모하려 공개해두고 되돌리지 않은 스토리지 버킷, 마감 전 연결 문제를 "고치려" 0.0.0.0/0으로 열어버린 보안 그룹, Slack 채널에 붙여넣어진 관리자 크리덴셜. 각각 몇 초면 충분하고, 각각이 비즈니스 전체를 노출할 수 있습니다.

그것이 클라우드 보안의 핵심 비대칭입니다. 온프레미스에서 실수 하나는 보통 한 네트워크 안의 한 서버에만 영향을 줍니다. 클라우드에서는 단일 설정이 종종 기본값으로 전 세계에서 접근 가능하고, 모든 대륙의 자동화 스캐너가 그런 설정을 밤낮으로 찾아다닙니다. 요즘 공격자들은 잘 침입하지 않습니다. 누군가 닫는 걸 잊은 문으로 로그인합니다.

왜 설정 오류가 클라우드 사고를 지배하는가 #

공개된 침해 기록을 읽으면 패턴이 보입니다. 대다수 클라우드 데이터 유출은 새로운 익스플로잇 때문이 아닙니다. 알려져 있고 문서화되어 있던 설정들이 불안전한 채 방치된 결과입니다:

• 공개된 오브젝트 스토리지. 고객 기록, 백업, DB 덤프를 담은 버킷이 플래그 하나로 인터넷에 열림.
• 과도하게 넓은 IAM. Resource: "*" 위의 Action: "*" 같은 정책이 프로젝트 편의상 부여된 뒤 좁혀지지 않음.
• 어디서든 닿는 관리 콘솔. IP 제한 없음, MFA 강제 없음, 어느 나라에서나 통하는 크리덴셜.
• 암호화 안 된 데이터 저장소. 식별자만 얻으면 누구나 읽을 수 있는 스냅샷과 볼륨.
• 코드 속 시크릿. 리포지토리에 커밋된 API 키, 자동화 스크레이퍼가 몇 분 만에 발견.

어느 것도 악용하는 데 정교함이 필요 없습니다. 모두 평범한 주의만으로 예방 가능합니다. 그래서 중요합니다: 플랫폼이 문서로 설명하는 것과 바쁜 엔지니어링 팀이 검증할 시간 사이의 틈새에 있기 때문입니다.

보이지 않는 건 고칠 수 없습니다 #

대부분의 engagement에서 첫 번째 정직한 걸음은 표면이 실제 얼마나 넓은지 인정하는 것입니다. 중견 조직이 여러 계정, 리전, 구독에 걸쳐 수천 개의 클라우드 리소스를 갖고 있는 게 보통입니다. 다른 팀들이 몇 년에 걸쳐 쌓아온 것이죠. 전체 그림을 머리에 담은 사람은 없고, 스프레드시트는 작성 후 몇 주 만에 낡습니다.

연속적 모니터링이 가치를 입증하는 지점입니다. 원칙은 간단합니다. 구성 상태를 애플리케이션 헬스처럼 다루세요. 매년 감사하는 게 아니라 계속 관찰하는 것입니다.

CSPM: 유용한 도구, 단 조건이 있습니다 #

Cloud Security Posture Management 도구는 그 관찰을 자동화하기 위해 존재합니다. 실제 구성을 CIS 벤치마크와 벤더 모범 사례 프레임워크와 비교하고 심각도 등급을 매긴 finding을 올립니다. 주요 클라우드마다 네이티브 옵션이 있습니다(AWS Security Hub, Azure Secure Score, Google Security Command Centre). 서드파티 도구는 멀티클라우드 커버와 더 깊은 맥락을 더합니다.

잘 쓰면 정말 가치 있습니다. 무작정 쓰면 다른 문제를 만듭니다. 아무도 안 읽을 만큼 긴 finding 대기열 말입니다. 두 결과를 가르는 세 가지 습관:

1. 인터넷 향한 노출부터 시작. 공개 스토리지, 열린 관리 포트, 인증 없는 서비스가 먼저입니다. 언젠가 아니라 이번 주에 사고가 되는 finding들입니다.
2. 리소스만 고치지 말고 근원을 고치세요. 손으로 고쳐도 Terraform 모듈이 여전히 불안전하게 만든다면 청소 한 바퀴 산 겁니다. 모듈을 바꾸세요. 그러면 finding이 쓰이는 모든 곳에서 영구적으로 사라집니다.
3. 멈추지 않고 조율하세요. 아키텍처에 해당하지 않는 finding은 근거를 적어 억제하세요. 누군가 행동할 finding만 남은 대기열이 아무도 안 읽는 완벽한 대기열보다 값집니다.

CSPM이 하지 않는 것도 기억하세요. 관찰하지 강제하지 않습니다. 퍼블릭 버킷을 거부하는 서비스 컨트롤 정책, 리전 확산을 막는 조직 차원 정책 같은 가드레일은 생성 시점에 실수를 막습니다. 가장 강한 프로그램은 둘 다 결합합니다. 알려진 위험엔 가드레일, 나머지엔 모니터링.

최선의 통제는 이해하는 엔지니어 #

위의 모든 기술 계층은 궁극적으로 사람들이 설정이 왜 중요한지 이해하는 데 의존합니다. 오브젝트 스토리지 ACL이 라우팅과 독립적임을 아는 엔지니어는 빠른 데모를 위해 버킷을 전 세계에 공개하기 전에 잠시 멈칫합니다. 보여준 적 없는 사람은 클릭하고 넘어갑니다.

실제 엔지니어링 문화에 맞는 실용적 조치:

• 안전한 경로를 쉬운 경로로 만드세요. 골든 Terraform 모듈, 사전 승인된 아키텍처 패턴, 암호화와 로깅이 기본 켜진 내부 모듈이 어떤 정책 문서보다 이깁니다.
• 짧고 실습형 세션. 우리 환경으로, 우리 CSPF finding을 함께 읽으며 하는 90분이 일반적인 클라우드 보안 슬라이드 하루보다 많이 가르칩니다.
• 아슬아슬했던 사건엔 무책임 포스트모템. 동료가 공격자 전에 발견한 노출된 버킷은 공짜 교훈입니다. 기록하고 널리 공유하고 허용한 모듈을 바꾸세요.
• 엔지니어를 스코핑 회의에 일찍 들이세요. 설계 시점의 보안 검토는 시간 단위 비용입니다. 출시 이후엔 재작업 비용입니다.

관리 교육은 도구의 물러난 대체재가 아니라 구매하는 모든 통제의 배수입니다.

이번 분기에 시작하기 #

이 글에서 한 가지만 가져간다면: 클라우드 설정 오류 위험을 실질적으로 줄이는 데 플랫폼 변혁은 필요 없습니다. 현실적인 90일 순서:

1. 1~2주: 모든 계정, 구독, 프로젝트를 목록화하세요. 네이티브 포스트처 도구가 꺼져 있다면 켜세요.
2. 3~6주: 인터넷 향한 모든 노출을 분류하고 해결하세요. 이 목록은 짧지만 항상 가치 있습니다.
3. 7~12주: IaC에서 반복되는 최상위 finding을 근원에서 수정하고, 완전히 차단할 범주에는 가드레일을 더하고, 우리 자신의 finding으로 첫 엔지니어링 교육 세션을 돌리세요.

클라우드 사고를 피하는 조직은 도구가 가장 많은 곳이 아닙니다. 엔지니어가 설정의 의미를 아는 곳, 파이프라인이 안전한 선택을 기본 선택으로 만드는 곳입니다.

외부 시선이 필요하신가요? 저희 구성 및 아키텍처 평가가 CIS 벤치마크와 귀사 아키텍처의 의도에 비추어 클라우드 자산을 검토하고, schedule an Engineering & Scoping Session으로 복구 순서를 팀과 함께 계획합니다.