클라우드 보안, 공유 책임 모델에서 아이덴티티·데이터·네트워크까지

클라우드 보안을 공유 책임 모델부터 아이덴티티·데이터·네트워크·탐지 대응까지 계층별로 설계하는 방법과 배포 모델별 통제 차이를 정리한다.

2026-08-13 · 최초 발행 2025-11-26

공유 책임 모델이 보안 설계의 출발점인 이유

클라우드 보안 사고 상당수는 새로운 공격 기법이 아니라 "이 부분은 클라우드 사업자가 책임진다"는 착각에서 시작된다. IaaS/PaaS/SaaS 환경에서 자산·정체성·데이터·서비스를 보호하는 일은 정책·기술·프로세스의 집합이지만, 그 출발점은 항상 공유 책임 모델이다. 클라우드 사업자는 물리 인프라·하이퍼바이저·코어 서비스를 책임지고, 고객은 데이터·구성·IAM을 책임진다. 서비스 모델이 IaaS에서 PaaS, SaaS로 갈수록 고객이 직접 통제해야 할 범위는 줄어들지만, 동시에 "내 책임이 아니라고 생각했던 설정"이 사고 원인이 되는 지점도 그만큼 이동한다.

이 구조를 보안 거버넌스로 옮기면 계정 구조 설계, 정책 표준화, 암호화·로깅 같은 필수 통제의 강제 적용으로 이어진다. 가시성 확보와 승인 흐름 자동화가 뒷받침되지 않으면 책임 경계는 문서로만 존재하고 실제 운영에서는 무너진다.

아이덴티티가 첫 번째 통제선인 이유

클라우드 보안에서 아이덴티티 및 접근 관리(IAM)를 첫 번째 통제선으로 두는 이유는 단순하다 — 대부분의 자원이 API 뒤에 있고, API 접근은 결국 자격 증명 하나로 결정되기 때문이다. 최소 권한 원칙과 역할 기반 접근 제어(RBAC/ABAC), 페더레이션(SSO) 중심 설계가 기본이며, 세션은 짧게 유지하고 MFA는 필수화하며 키는 주기적으로 순환시킨다.

교차 계정 접근에는 임시 자격 증명(STS)을 쓰는 편이 안전하다. 다만 IAM 정책은 즉시 전파되지 않는다(eventual consistency). 이 지연을 고려하지 않고 배포 순서를 짜면, 정책이 아직 반영되지 않은 상태에서 요청이 거부되거나 반대로 이전 권한이 남아 있는 창이 생긴다. 배포 순서와 롤백 설계에 이 지연을 반영해야 한다.

데이터를 지키는 방법: 암호화와 키 수명주기

데이터는 저장(At-rest)·전송(In-transit)·사용(In-use) 세 상태 모두에서 보호 대상이다. 기본 암호화를 활성화하고, 고객 관리형 키(CMK)나 HSM/KMS를 사용하는 것이 출발점이다. 여기서 끝이 아니라 키의 생성→배포→회전→폐기로 이어지는 수명주기 전체를 자동화하고 접근을 감사해야 실효성이 생긴다. 암호화는 성능 오버헤드를 동반하므로, 데이터 핫패스에는 하드웨어 가속을 적용해 보안과 성능 사이의 트레이드오프를 줄이는 설계가 필요하다.

네트워크와 엣지에서 노출 면을 줄이는 법

세그먼테이션(VPC/Subnet), 보안 그룹/ACL, 프라이빗 엔드포인트, egress 제어는 모두 같은 목적을 향한다 — 노출을 최소화하는 것. 엣지 레이어에는 WAF/Anti-DDoS/Bot 관리를 적용한다. 다만 L7 정책이 복잡해질수록 운영 난이도가 올라가므로, 정책 테스트와 카나리 배포 없이 규칙을 바로 프로덕션에 반영하는 것은 피해야 한다.

가시성에서 자동 대응까지: 탐지·대응 파이프라인

설정 취약점과 과도한 권한은 CSPM/CIEM으로 잡아내고, 워크로드·애플리케이션 위험은 CWPP/DAST/SCA로 탐지한다. 이렇게 모인 신호는 SIEM으로 수집·상관분석하고, SOAR가 플레이북 기반으로 자동 대응한다. 과탐지가 SOAR 자동화의 가장 흔한 실패 지점이므로, 위험을 점수화하고 티어드 대응 체계(경고 → 조사 → 자동 격리)를 나눠 설계하는 편이 안전하다.

이 흐름을 요청 단위로 그리면 다음과 같다.

허용성공실패허용거부아니오성공 거부/오류이상정상입력: 사용자/서비스 요청엣지: WAF/DDoS인증 AuthN: SSO/MFA인가 AuthZ: IAM/ABAC출력: 차단/알림정책 평가: PaC/OPA데이터 접근?암호화/키요청: KMS/HSM로깅/감사:CloudTrail/Activity Log출력: 격리/재시도탐지: CSPM/CWPP/SIEM 규칙SOAR: 티켓/격리/자동 대응출력: 서비스 응답

IAM 정책 전파 지연을 감안해 캐시 만료·재시도 로직을 이 파이프라인 안에 넣어야 이상 탐지와 정상 요청 지연을 혼동하지 않는다.

배포 모델에 따라 달라지는 보안 책임 범위

같은 통제라도 온프레미스와 IaaS, PaaS, SaaS에서 운영 방식은 전혀 다르다.

모델 성능 확장성 일관성 안정성 운영 편의
온프레미스 하드웨어 직접 최적화 가능, 초기 고성능 증설 리드타임 길음 표준화 난이도 높음 장애 영향 범위 큼 수작업 많음, 자동화 성숙도 의존
IaaS 인스턴스·가속기 선택 유연 수평 확장 용이 IaC로 형상 일관성 확보 AZ/Region 활용 고가용성 도구 다변, 거버넌스 필요
PaaS 관리형 서비스 최적화 서비스 단위 자동 확장 제공자 표준 기반 일관성 높음 패치·백업 내장 추상화 이점, 벤더 종속 리스크
SaaS 제공사 최적화 성능 테넌트 수준 확장 기능·정책 일관성 매우 높음 SLA 기반 고신뢰 설정 중심, 세부 통제 제한

설계 원칙과 트레이드오프

Identity-first 보안(사람·워크로드 아이덴티티 분리, 단기 자격증명, 권한 상향 승인)은 빈번한 재인증으로 사용자 경험을 떨어뜨릴 수 있다. 조건부 접근과 세션 캐시로 이 트레이드오프를 완화한다. Encryption-by-default(저장·전송 기본 암호화, 키 소유권 고객화)는 비용·지연 증가를 동반하므로 데이터 핫패스에 하드웨어 가속을 붙인다. 네트워크 최소 노출(프라이빗 엔드포인트·프록시 전환, egress 허용 목록)은 트러블슈팅 복잡도를 키우기 때문에 별도 옵저버빌리티 채널이 필요하다. 탐지·대응 자동화(SOAR 표준 플레이북, 카나리 격리)는 오탐 자동조치 위험이 있으므로 단계별 승인과 세이프가드를 넣는다.

이 통제들을 실제로 갖추면 효과는 수치로도 드러난다. 미구성·과다권한 탐지만으로 보안 사고 위험이 3060% 수준 낮아지고, SOAR 기반 자동화로 MTTR이 3050% 단축되며, IaC/PaC 일관 배포로 형상 드리프트가 70% 이상 줄어든 사례가 보고된다. 감사·사고 대응 비용까지 포함하면 총소유비용(TCO)이 15~30% 절감되는 효과도 함께 나타난다.

산업별 적용 양상

금융권은 조직 단위 계정 분리와 SCP로 암호화·로깅·지역 제한 같은 필수 통제를 강제하는 다계정 거버넌스, 제로 트러스트 조합을 쓴다. 민감 데이터는 BYOK/HYOK와 HSM으로 보호하고, 거래 API는 WAF와 봇 방어(BFL)로 차단하며 이상 징후 시 리스크 기반 인증을 강화한다.

제조/IoT는 디바이스 아이덴티티를 PKI로 발급하고 메시지 계층에 TLS 상호 인증을 적용한다. 텔레메트리는 전용 수신 엔드포인트와 사전 서명 검증을 거치고, 이상 패턴이 잡히면 SOAR가 현장 네트워크를 격리한다.

게임/미디어는 프론트 도메인에 Anycast DDoS 보호와 자동 조정되는 WAF 레이트 리미트를 두고, 릴리스 파이프라인에 IaC 정적 분석과 런타임 방어(CWPP)를 연동한다.

공공/의료는 PaC로 HIPAA·ISMS 기준을 정책화해 배포 전후 규정 적합성을 검증하고, 로그는 변경 불가 스토리지에 보관하며 민감 이벤트는 실시간 경보와 의무 통지 워크플로로 연결한다.

Terraform으로 최소 가드레일 구현하기

전제는 Terraform v1.6+, AWS Provider v5.x, 조직 차원 CloudTrail 활성화다.

# 기본 암호화 및 퍼블릭 차단 S3 버킷
resource "aws_s3_bucket" "secure_log" {
  bucket = "org-secure-log-bucket"
  force_destroy = false
}

resource "aws_s3_bucket_public_access_block" "block" {
  bucket                  = aws_s3_bucket.secure_log.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "sse" {
  bucket = aws_s3_bucket.secure_log.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
      kms_master_key_id = aws_kms_key.log_key.arn
    }
  }
}

resource "aws_kms_key" "log_key" {
  description             = "Log bucket CMK"
  enable_key_rotation     = true
  deletion_window_in_days = 30
}

# CloudTrail: 모든 계정 활동 로깅
resource "aws_cloudtrail" "org_trail" {
  name                          = "org-trail"
  s3_bucket_name                = aws_s3_bucket.secure_log.bucket
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true
}

배포 단계에서는 PaC(OPA/Conftest 등)로 퍼블릭 리소스·비암호화 리소스 금지 정책을 선검증하는 편이 사후 교정보다 싸게 먹힌다. IAM 정책 전파 지연을 고려해 점진 배포와 재시도 백오프를 넣고, 감사 로그는 보존·무결성 검증과 함께 보안 계정 전용 권한으로 접근을 분리해 둔다.

클라우드 보안공유책임모델IAM제로트러스트CSPM