오늘날 가장 넓은 공격면은 귀사의 클라우드입니다.
AWS, Azure, GCP의 설정과 권한, 분리 상태를 점검합니다. 클라우드 사고 대부분은 사업자 장애로 시작하지 않습니다. 지나치게 넓은 권한, 의도치 않게 열린 자원, 잊힌 비밀값에서 시작합니다.
클라우드에서 잘못은 사업자 쪽인 경우가 드뭅니다
책임 공유 모델은 일을 나눕니다. 인프라 보안은 사업자가 맡고, 설정은 귀사의 몫입니다. 사고는 귀사 쪽에서 일어납니다. 시험 편의를 위해 열어 둔 버킷, 급한 김에 관리자 권한을 준 역할, 일정에 쫓겨 분리하지 않은 네트워크. 어느 것도 스캔에서 취약점으로 나타나지 않습니다. 아무도 다시 들여다보지 않은 설정상의 결정으로 나타날 뿐입니다.
- 임시 조치로 준 권한은 나중에 회수되는 일이 거의 없습니다.
- 표준 절차를 거치지 않고 만든 자원은 그 절차가 주는 보호를 물려받지 않습니다.
- 환경 변수와 저장소에 남은 비밀값은 여전히 안으로 들어가는 가장 짧은 길입니다.
- 분리가 없으면 거점 하나가 서로 떨어져 있어야 할 계정과 환경까지 닿습니다.
포함되는 범위
아래 범위는 일반적인 프로젝트의 기본값입니다. 범위 협의 단계에서 모두 조정할 수 있으며, 별도 비용은 없습니다.
- 지나치게 넓은 정책과 동작·자원의 와일드카드
- 위임 가능한 역할과 권한 상승 연쇄
- 장기간 유효한 접근 키와 교체 주기
- 연합 인증, 인증 제공자, 세션
- 서비스 계정과 워크로드 권한
- 관리 업무와 운영 업무의 분리
- 객체와 컨테이너의 공개 노출
- 저장 시 암호화와 키 관리
- 접근 정책과 계정 간 공유
- 버전 관리, 보존 기간, 삭제 방지
- 백업과 복구 시험
- 본래 저장 위치를 벗어난 민감 데이터
- 인터넷 전체에 열린 인바운드 규칙
- 환경 간·계정 간 분리
- 로드밸런서, 게이트웨이, 트래픽 종단
- 외부에서 닿는 관리용 서비스
- 사설 연결과 네트워크 피어링
- 컨테이너와 오케스트레이션 공격면
- 모든 리전에 켜진 감사 추적
- 로그 자체의 보존과 보호
- 컨트롤 플레인 이벤트 적용 범위
- 민감 권한 변경에 대한 경보
- 별도 계정으로의 집중 수집
- 기존 모니터링과의 연동
- IAM, 역할, 정책, 계정 연합
- VPC, 보안 그룹, NACL, 피어링, 공개 노출
- S3, RDS, DynamoDB, Blob Storage, Cloud Storage
- EC2, Lambda, ECS, EKS, AKS, GKE
- CloudTrail, AWS Config, Microsoft Sentinel, Security Command Center
- 인증 제공자와 연합 SSO
수행 방식
범위에 맞춰 조정설정 점검
읽기 전용 감사 역할로 환경을 체계적으로 훑습니다. 계정, 네트워크, 스토리지, 로그, 데이터 보호를 사업자 자체 문서와 공개 기준선에 견주어 봅니다.
경로 검증
설정을 나열하는 대신, 있음 직한 출발점—애플리케이션 자격 증명, 장악된 컨테이너, 평범한 사용자—에서 시작해 환경 안에서 어디까지 닿는지를 확인합니다.
지속 점검과 코드형 인프라
환경을 만들어 내는 템플릿과 모듈을 분석하고, 주기적인 확인 절차를 둡니다. 근원에서 고쳐야 같은 이탈이 새 계정, 새 프로젝트, 새 배포마다 되돌아오지 않습니다.
클라우드 환경을 점검할 시점
클라우드 설정은 여러 사람 손을 거쳐 날마다 바뀝니다. 어떤 시점은 다른 때보다 위험이 몰립니다.
급하게 옮긴 환경에는 전환을 통과시키려 열어 둔 넓은 권한이 남기 마련입니다. 나중에 조이겠다는 약속과 함께—그 나중은 좀처럼 오지 않습니다.
팀마다 하나, 프로젝트마다 또 하나. 중심이 되는 기준이 없으면 보호 수준이 갈라지고, 전체를 보는 사람도 없어집니다.
이상 비용은 낭비일 때도 있고, 만들 권한이 없어야 할 사람이 만든 자원일 때도 있습니다. 어느 쪽인지는 알아 둘 값어치가 있습니다.
클라우드 통제에 대한 증빙은 이제 대다수 점검표의 기본 항목입니다. 심사자보다 먼저 빈틈을 찾아 두는 편이 낫습니다.
진행 방식
[진행 절차]환경 파악
무엇이 있는지에서 출발합니다. 계정, 구독, 프로젝트, 사용 중인 리전과 자원. 클라우드 환경은 거의 언제나 문서보다 큽니다. 그리고 목록에서 빠진 자원이 대개 보호되지 않은 그 자원입니다.
계정과 권한 분석
누가 무엇을 할 수 있는지를, 상속과 역할 위임으로 가능해지는 범위까지 포함해 정리합니다. 중요한 것은 문서에 적힌 정책이 아니라 실제로 작동하는 권한이며, 그것은 대개 권한을 준 사람이 짐작하는 것보다 훨씬 넓습니다.
설정 검토
스토리지, 네트워크, 암호화, 로그, 백업, 관리형 서비스를 사업자 문서와 공개된 안전 설정 기준선에 대조합니다. 이탈마다 이 환경에서 왜 문제가 되는지를 함께 기록합니다.
도달 범위 확인
현실적인 출발 지점을 재현해 각각이 어디까지 닿는지 잽니다. 애플리케이션 자격 증명으로 무엇을 읽을 수 있는지, 장악된 컨테이너가 무엇에 닿는지, 한 환경에서 다른 환경으로 건너갈 수 있는지. 이것이 이탈 목록을 입증된 위험으로 바꿉니다.
로그와 경보 평가
저희가 수행한 동작이 흔적을 남겼는지, 그 흔적이 삭제로부터 보호되는지, 민감한 권한 변경에 경보가 뜨는지 확인합니다. 믿을 만한 흔적이 없는 환경은 사고 뒤에 조사가 불가능합니다.
보고와 조치 계획
이탈은 자원별이 아니라 원인별로 묶습니다. 정책 하나에서 비롯된 열 건은 열 번의 수정이 아니라 한 번입니다. 각 묶음에 적용 가능한 지침과, 근원에서 재발을 막는 제안을 붙입니다.
작업의 근거가 되는 공개 기준
점검은 사업자 자체 문서와 공개된 설정 기준선에 기대며, 그래서 모든 항목을 독립적으로 검증할 수 있습니다.
- CIS Benchmarks
- AWS, Azure, GCP를 위한 설정 기준선입니다. 환경의 상태를 견주어 볼 항목별 객관적 참조가 됩니다.
- Well-Architected(보안 기둥)
- 각 사업자의 아키텍처 지침은 그들이 권장하는 방식을 명시합니다. 권고의 출처를 두고 다툴 여지가 없어집니다.
- 책임 공유 모델
- 사업자의 책임이 어디서 끝나고 귀사의 책임이 어디서 시작되는지를 정확히 규정합니다. 사고 대부분이 벌어지는 바로 그 경계입니다.
- MITRE ATT&CK for Cloud
- 클라우드에 특화된 표로, 계정 악용과 지속성 확보, 데이터 수집 기법에 이름을 붙입니다. 탐지 적용 범위를 평가하는 데 씁니다.
- NIST SP 800-53
- 통제 항목 목록은 기술적 발견과, 거버넌스·감사가 이미 쓰는 언어를 잇는 다리입니다.
- 최소 권한
- 표준이 아니라 권한 분석을 이끄는 기준입니다. 모든 계정은 필요한 만큼만 닿아야 하고, 거기서 벗어나려면 명시적인 사유가 있어야 합니다.
- Azure Security Benchmark
- 마이크로소프트가 만든 Azure 기준선입니다. 환경이 주로 Azure이고 감사 측이 이 참조를 기대할 때 씁니다.
- CSA 클라우드 통제 매트릭스
- 클라우드 보안 연합의 매트릭스로 클라우드 보안 영역을 정리하고 다른 표준과의 대응 관계도 보여줍니다. 고객사 점검표가 길 때 도움이 됩니다.
- ISO/IEC 27017과 27018
- 클라우드 보안과 클라우드상의 개인정보에 특화된 표준으로, 기업 계약에서 자주 인용됩니다.
- 데이터 보호 법규·PCI-DSS와의 대응
- 환경이 개인정보나 카드 데이터를 다룬다면 각 발견 사항을 해당 요구사항에도 연결해, 그대로 증빙으로 쓸 수 있게 합니다.
산출물
두 갈래 · NDA실재하는 것들의 목록
계정, 프로젝트, 리전, 가동 중인 자원의 실제 목록입니다. 아무도 자기 것인 줄 몰랐던 환경이 드러나기 때문에, 많은 팀에게는 이것이 첫 번째로 쓸모 있는 산출물입니다.
실효 권한 지도
실제로 누가 무엇에 닿는지. 상속과 역할 위임을 통한 간접 경로까지 포함합니다. 설정 목록보다 놀라운 경우가 보통입니다.
원인별로 묶은 이탈
같은 출처로 정리한 발견 사항에 각각 공개 근거를 붙입니다. 원인을 고치면 여러 항목이 한 번에 닫히고 재발도 막힙니다.
입증된 경로
중요한 위험에 대해서는 구체적인 길을 보여줍니다. 어디서 시작해 무엇에 닿고 왜 문제가 되는지. 설정 이탈이 비전문가도 무게를 가늠할 수 있는 위험으로 바뀝니다.
흔적과 탐지 평가
수행한 동작 중 무엇이 기록됐는지, 무엇이 꺼져 있었는지, 그리고 지금이라면 어떤 민감한 변경이 아무도 모르게 지나가는지.
우선순위를 매긴 조치 계획
위험과 품을 함께 저울질한 작업 순서이며, 설정에서 고칠 것과 되돌아오지 않도록 코드형 인프라에서 바꿔야 할 것을 구분합니다.
자주 묻는 질문
필요하지 않습니다. 점검은 읽기 전용 감사 역할로 진행하며, 세 사업자 모두 기본으로 제공합니다. 도달 범위 검증에 쓸 자격 증명은 따로, 범위를 좁혀 합의하고 권한 범위와 기간을 서면으로 정합니다.
대체가 아니라 보완입니다. 태세 도구는 물량을 감당하고 설정 이탈을 계속 추적합니다. 그 점은 값집니다. 다만 권한을 엮어서, 애플리케이션 자격 증명이 격리돼 있어야 할 데이터에 닿는다는 사실을 보여주지는 못합니다. 우선순위를 바꾸는 것은 바로 그 입증입니다.
됩니다. 오히려 섞여 있는 쪽이 흔하고, 사업자 간 비교는 대개 고르지 못한 보호 수준을 드러냅니다. 같은 종류의 자원이 한쪽은 잠겨 있고 다른 쪽은 열려 있는 식인데, 만든 팀이 다르기 때문입니다.
오케스트레이션도 범위에 들어갑니다. 역할과 바인딩, 컨테이너 보안 컨텍스트, 서비스 간 네트워크 정책, 컨트롤 플레인 노출, 비밀값 관리, 그리고 클러스터 계정과 클라우드 계정의 연결—흔한 권한 상승 경로입니다.
최소한 운영을 떠받치는 범위입니다. 개발과 스테이징 계정도 네트워크나 계정 경로로 운영과 이어져 있다면 포함할 값어치가 있습니다. 생각보다 흔한 경우이고, 하필 그쪽 보호가 가장 느슨한 편입니다.
근원에서 고쳐야 합니다. 환경이 코드형 인프라로 만들어진다면 수정은 모듈에 넣고, 이후 모든 배포에 적용됩니다. 보고서는 이탈 묶음마다 자원에서 다룰지, 그것을 만들어 내는 템플릿에서 다룰지 밝힙니다.
쓸 수 있습니다. 각 항목에 공개 근거와 관찰된 설정의 증적이 붙어 있어, 감사인이 분석을 되풀이하지 않고도 스스로 검증할 수 있는 형태입니다.