CompTIA SY0-701: 클라우드, 가상화 및 컨테이너 보안 — 학습 가이드

다음의 일부입니다: CompTIA Security+ SY0-701 — 학습 가이드. 검증된 답안으로 연습하기: CompTIA 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

현대의 기업이 독립된 단일 데이터 센터에서만 운영되는 경우는 드뭅니다. 워크로드는 퍼블릭 클라우드 제공업체, 프라이빗 가상화 클러스터, 컨테이너 오케스트레이터, 그리고 임시적인 서버리스 함수에 걸쳐 있습니다. 각 추상화 계층은 위협 모델, 제어 영역, 그리고 결정적으로 누가 어떤 보안 제어에 대한 책임을 지는지를 변화시킵니다.

공동 책임 모델

모든 주요 클라우드 제공업체는 고객과 클라우드 서비스 제공업체(CSP) 간의 보안 의무를 나누는 공동 책임 모델을 발표합니다. 이 구분선은 서비스 계층에 따라 달라집니다.

서비스형 인프라(IaaS) — Amazon EC2, Azure Virtual Machines, Google Compute Engine — 에서는 CSP가 물리적 시설, 하드웨어, 하이퍼바이저, 네트워크 패브릭을 보호합니다. 하이퍼바이저 위의 모든 것은 고객의 책임입니다: 게스트 운영 체제, 패치, 호스트 기반 방화벽, 미들웨어, 런타임, 애플리케이션 코드, 자격 증명 구성 및 데이터 자체입니다. 만약 회사가 EC2 인스턴스에 MySQL 데이터베이스를 배포한다면, 해당 데이터베이스를 보호하는 것은 전적으로 고객의 책임입니다.

서비스형 플랫폼(PaaS) — AWS RDS, Azure App Service, Google App Engine — 에서는 제공업체가 추가로 운영 체제, 데이터베이스 엔진 패치, 런타임을 관리합니다. 고객은 애플리케이션 코드, 데이터 분류, 접근 제어, 네트워크 노출 규칙, 자격 증명 관리에 대한 책임을 계속 집니다.

서비스형 소프트웨어(SaaS) — Microsoft 365, Salesforce, Workday — 에서는 제공업체가 거의 전체 스택을 처리합니다. 고객에게 남은 책임도 중요합니다: 계정 프로비저닝 및 디프로비저닝, MFA 강제, 데이터 분류, 공유 권한, DLP 구성, 그리고 기업 ID 제공업체와의 통합입니다. 급여 데이터를 “모든 사람"에게 노출하도록 잘못 구성된 SharePoint 사이트는 Microsoft의 보안 침해가 아니라 테넌트 관리자의 실수입니다.

클라우드로 마이그레이션하면 모든 보안 책임이 제공업체에게 이전된다는 것은 계속되는 오해입니다. 잘못 구성된 S3 버킷, 노출된 Elasticsearch 클러스터, 유출된 API 키와 관련된 데이터 유출은 거의 예외 없이 CSP의 침해가 아닌 고객 측의 실수에서 비롯됩니다.

가상화와 하이퍼바이저 위험

가상화는 하이퍼바이저를 사용하여 물리적 하드웨어를 논리적 게스트로 풀링합니다. 타입 1(베어메탈) 하이퍼바이저(예: VMware ESXi, Microsoft Hyper-V, KVM)는 하드웨어에서 직접 실행됩니다. 타입 2(호스트형) 하이퍼바이저(예: VirtualBox)는 범용 OS 위에서 실행되며 프로덕션 워크로드에는 적합하지 않습니다.

가상화 관련 주요 위협은 **VM 탈출(escape)**과 하이퍼바이저 침해입니다. VM 탈출은 게스트 내부의 악성 코드가 가상화 경계를 벗어나 하이퍼바이저나 인접 VM에서 실행될 때 발생합니다. 과거 사례로는 CVE-2015-3456(QEMU의 플로피 컨트롤러에 있던 VENOM)과 다양한 VMware Tools 취약점이 있습니다. 단일 하이퍼바이저가 여러 신뢰 영역에 걸쳐 수백 개의 워크로드를 호스팅할 수 있으므로, 탈출에 성공하면 막대한 접근 권한을 얻게 됩니다.

완화 조치로는 엄격한 하이퍼바이저 패치, 게스트 추가 기능 및 미사용 에뮬레이트 하드웨어 최소화, 민감도에 따라 워크로드를 별개의 클러스터로 분리, 그리고 관리 플레인 격리가 있습니다. vCenter 서버, ESXi 관리 인터페이스, 클러스터 API는 MFA가 적용된 권한 있는 점프 호스트에서만 접근할 수 있는 전용 관리 네트워크에 위치해야 합니다.

추가적인 우려 사항으로는 VM sprawl(시간이 지남에 따라 방치되고 패치되지 않은 VM이 쌓이는 현상)과, 사용 중지된 VM의 메모리나 스토리지가 다른 테넌트에게 할당되기 전에 제대로 초기화(zeroed)되지 않는 리소스 재사용이 있습니다.

컨테이너, 마이크로서비스, 커널 공유

컨테이너는 애플리케이션과 그 종속성을 함께 패키징하지만, VM과 달리 호스트 운영 체제의 커널을 공유합니다. Docker, containerd, CRI-O는 컨테이너 생명주기를 관리하고, Kubernetes는 이를 대규모로 오케스트레이션합니다. 이러한 경량 격리는 밀리초 단위의 시작, 높은 집적도라는 장점이 있지만, 동시에 주된 위험 요소이기도 합니다.

컨테이너 격리는 VM 격리와 동일하지 않습니다. 컨테이너 내부에서 커널 취약점을 악용하면 호스트와 그 위의 다른 모든 컨테이너가 침해될 수 있습니다. 네임스페이스(PID, network, mount, UTS, IPC, user)와 cgroups가 격리를 제공하지만, 이는 단일 공격 표면을 공유하는 소프트웨어 구조입니다.

컨테이너 보안은 파이프라인 전반에 걸친 제어가 필요합니다:

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

이미지는 배포 전에 취약점 검사를 받아야 하고(Trivy, Snyk, Clair), 최소한의 기본 이미지(distroless 또는 Alpine)로 빌드해야 하며, 이미지 서명이 강제된 신뢰할 수 있는 레지스트리에서만 가져와야 합니다(Cosign, Notary). 런타임 보호 도구(Falco, Aqua, Sysdig)는 컨테이너 동작을 모니터링하고 예상치 못한 프로세스 실행이나 네트워크 연결과 같은 이상 징후를 경고합니다.

클라우드 보안 태세와 IAM

클라우드 IAM은 여러 중요한 면에서 온프레미스 Active Directory와 다릅니다. AWS에서 IAM 정책은 사용자, 그룹 또는 역할에 연결된 JSON 문서이며, 유효 권한은 자격 증명 기반 정책과 리소스 기반 정책의 교집합으로 결정되며, 명시적 거부(deny)가 항상 우선합니다:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

클라우드 보안 태세 관리(CSPM) 도구는 보안 벤치마크(CIS AWS Foundations, NIST)에 따라 클라우드 구성을 지속적으로 스캔하여, 공개된 S3 버킷, 과도하게 허용적인 보안 그룹, 비활성화된 CloudTrail 로깅, 암호화되지 않은 EBS 볼륨 등을 찾아냅니다. **클라우드 접근 보안 중개(CASB)**는 사용자와 클라우드 서비스 사이에 위치하여 SaaS 애플리케이션에 대한 DLP, 접근 정책, 위협 탐지를 강제합니다.

실용 시나리오: 잘못된 구성으로 PII를 노출한 S3 버킷

한 헬스케어 스타트업이 개발 스프린트 중 퍼블릭 읽기 액세스 권한으로 생성된 S3 버킷에 환자 접수 양식을 저장했습니다. 이 버킷은 프로덕션 환경으로 전환되기 전에 잠금 조치가 이루어지지 않았습니다. 이 버킷은 한 보안 연구원에 의해 DNS 무차별 대입(brute-forcing)과 AWS S3 버킷 열거(enumeration) 기법의 조합을 통해 발견되었습니다. 약 87,000개의 환자 기록(이름, 생년월일, 보험 ID, 주호소 내용 포함)이 인증 없이 액세스 가능했습니다. 이 스타트업은 CSPM 도구나 자동화된 구성 스캔 기능이 없었습니다. 기본적인 AWS Config 규칙인 s3-bucket-public-read-prohibited만 있었더라도 생성 후 몇 분 내에 잘못된 구성을 발견했을 것입니다. 이 사건으로 인해 HHS(미국 보건복지부)의 조사를 받았고, 45만 달러의 합의금을 지불했으며, 회사가 낮은 가치에 인수되는 원인이 된 평판 손상을 입었습니다.



애플리케이션 및 웹 보안 · 모든 도메인 · 데이터 보안

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

시험 합격하기 →

Related guides

올인원 액세스

하나의 구독. 모든 시험.

모든 플랜은 무제한 답변 검색, 모의고사, AI 해설, 전체 자료 라이브러리를 20개 이상의 언어로 잠금 해제합니다.

월간
24.87
Just €0.83/day
모든 포함:
  • 무제한 답변 검색
  • 무제한 모의고사
  • AI 기반 해설
  • 전체 자료 라이브러리
  • 20개 이상의 언어
  • 주간 콘텐츠 업데이트
  • 보상 및 추천
  • 우선 지원
무료 체험 시작

신용카드 필요 없음*

최고의 가치
12개월
179.87
Just €0.49/daySave 40%
모든 포함:
  • 무제한 답변 검색
  • 무제한 모의고사
  • AI 기반 해설
  • 전체 자료 라이브러리
  • 20개 이상의 언어
  • 주간 콘텐츠 업데이트
  • 보상 및 추천
  • 우선 지원
무료 체험 시작

신용카드 필요 없음*

✓ 무료 플랜 포함 · ✓ 언제든지 취소 가능 · ✓ 모든 플랜은 전체 제품을 잠금 해제합니다