본문으로 이동
메뉴 여닫기
환경 설정 메뉴 여닫기
개인 메뉴 여닫기
로그인하지 않음
지금 편집한다면 당신의 IP 주소가 공개될 수 있습니다.
Cloud Security; 클라우드 보안
클라우드 서비스 제공자와 이용자가 책임을 나눠 클라우드에 올린 데이터, 워크로드, 계정, 설정을 보호하는 활동

NIST SP 800-145는 클라우드 컴퓨팅을 공유된 컴퓨팅 자원 풀에 네트워크로 언제든 편리하게 접근하고, 최소한의 관리 노력으로 빠르게 할당·반납하는 모델로 정의하고, 5가지 필수 특성(주문형 셀프서비스, 광범위한 네트워크 접근, 자원 풀링, 신속한 탄력성, 측정되는 서비스), 3가지 서비스 모델(IaaS, PaaS, SaaS), 4가지 배치 모델(사설, 커뮤니티, 공용, 하이브리드)로 설명한다. 클라우드 보안의 출발점은 누가 무엇을 책임지는가를 서비스 모델별로 분명히 하는 것이다. 사업자가 아무리 안전한 인프라를 제공해도 이용자가 저장소를 공개로 설정하거나 관리자 계정을 허술하게 관리하면 사고가 난다.

클라우드 서비스 유형에 따른 역할 및 책임(예시)

클라우드 서비스 유형 클라우드 서비스 제공자 클라우드 서비스 이용자
IaaS
  • 물리적 영역의 시설 보안 및 접근통제
  • 호스트 OS에 대한 보안 패치
  • 하이퍼바이저 등 가상머신에 대한 보안 관리 등
  • 게스트 OS, 미들웨어 및 애플리케이션 보안 패치
  • 게스트 OS, 미들웨어, 애플리케이션, 사설 네트워크 영역에 대한 보안 구성 및 설정
  • 데이터 보안
  • 관리자, 사용자 권한 관리 등
PaaS
  • IaaS 영역에서 클라우드 서비스 제공자의 역할 및 책임
  • 네트워크 영역의 보안 설정
  • 게스트 OS 및 미들웨어 영역에 대한 보안패치, 보안 구성 및 설정
  • 애플리케이션 보안 패치 및 보안 설정
  • 데이터 보안
  • 관리자, 사용자 권한관리 등
SaaS
  • IaaS, PaaS 영역에서 클라우드 서비스 제공자의 역할 및 책임
  • 애플리케이션 보안 패치 및 보안 설정
  • 데이터 보안(데이터 레벨의 접근통제, 암호화 등) 등
  • 애플리케이션 관리자, 사용자 권한 관리 등

※ 클라우드 서비스 사업자, 서비스 구성 및 특성 등에 따라 달라질 수 있음.

서비스 모델별 공동 책임

편집 원본 편집

위 표를 계층별로 다시 정리하면 다음과 같다. 서비스 모델이 IaaS에서 SaaS로 갈수록 제공자 책임이 늘지만, 데이터, 계정·권한, 접근 정책에 대한 책임은 어느 모델에서도 이용자에게 남는다.

계층 온프레미스 IaaS PaaS SaaS
데이터 분류·보호 이용자 이용자 이용자 이용자
계정·권한(IAM) 이용자 이용자 이용자 이용자
애플리케이션 이용자 이용자 이용자 제공자(설정은 이용자)
미들웨어·런타임 이용자 이용자 제공자 제공자
게스트 OS 이용자 이용자 제공자 제공자
가상 네트워크 설정 이용자 이용자 공동 제공자
하이퍼바이저·호스트 이용자 제공자 제공자 제공자
물리 시설·하드웨어 이용자 제공자 제공자 제공자

아마존 웹 서비스의 구분 방식은 AWS 공동 책임 모델을 참고한다. 책임은 계약으로 나눌 수 있지만 법적·관리적 책임(accountability)은 이용 조직에 남는다는 점이 중요하다. 개인정보 처리를 위탁해도 위탁자가 관리·감독 책임을 지는 것과 같은 구조이다.

클라우드 보안 연합(CSA, Cloud Security Alliance)의 "Top Threats to Cloud Computing 2024"는 500명 이상 전문가 설문으로 11개 위협을 꼽았다. 설정 오류와 부적절한 변경 통제, 신원·접근 관리(IAM), 안전하지 않은 인터페이스와 API, 부적절한 클라우드 보안 전략, 안전하지 않은 제3자 자원, 안전하지 않은 소프트웨어 개발, 우발적인 클라우드 데이터 공개, 시스템 취약점, 제한된 가시성, 인증 없는 자원 공유, 지능형 지속 위협(APT)이다.

위협 예 주요 대책
설정 오류(misconfiguration) 객체 저장소 공개 설정, 관리 포트 전체 개방, 로깅 꺼짐, 기본 설정 방치 CSPM, 코드형 인프라와 정책 검사, 변경 관리
계정 탈취 유출된 접근 키, 피싱으로 탈취한 콘솔 계정, 과도한 권한의 서비스 계정 다중 인증, 최소 권한, 장기 접근 키 금지, 서비스 계정 관리
안전하지 않은 API 인증·권한 검사 결함, 과도한 데이터 반환, 속도 제한 부재 API 보안, API 게이트웨이, 인증 토큰 관리
데이터 유출 공개 저장소·스냅숏 노출, 내부자 반출, 백업 사본 방치 데이터 분류, 암호화와 KMS, DLP, CASB
공유 기술 취약점 하이퍼바이저·CPU 결함으로 다른 테넌트의 데이터 노출, 다중 테넌트 격리 실패 제공자의 패치·격리 보증 확인, 전용 호스트 선택, 가상화 보안
가시성 부족 섀도 IT, 계정별로 흩어진 로그 중앙 로그 수집, SIEM, CASB
통제 정식 명칭 역할
CSPM Cloud Security Posture Management, 클라우드 보안 형상 관리 클라우드 계정의 설정을 지속적으로 점검해 공개 저장소, 과도한 권한, 암호화 미적용 같은 설정 오류를 찾고 기준(CIS 벤치마크, 내부 정책) 위반을 알린다
CWPP Cloud Workload Protection Platform VM, 컨테이너, 서버리스 함수 같은 워크로드 자체를 보호한다. 취약점 스캔, 런타임 감시, 무결성 감시
CASB Cloud Access Security Broker 이용자와 SaaS 사이에서 사용 가시성, 섀도 IT 탐지, 데이터 유출 방지, 접근 정책을 적용한다
KMS Key Management Service 암호 키 생성·보관·교체·폐기를 관리한다. 고객 관리 키(CMK)나 자체 키 반입(BYOK), HSM 기반 키 보관으로 제공자로부터의 독립성을 높인다(암호 키 관리)
IAM Identity and Access Management 사용자·역할·정책으로 클라우드 자원 접근을 통제한다. 최소 권한, 역할 위임, 임시 자격 증명, 루트 계정 봉인이 핵심이다

CSPM과 CWPP를 하나의 플랫폼으로 묶은 것을 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP)이라 부르기도 한다.

클라우드 감사와 인증

편집 원본 편집

이용자는 제공자의 데이터 센터를 직접 감사하기 어렵기 때문에 제3자 인증과 감사 보고서로 통제 수준을 확인한다.

제도 내용
CSA STAR CSA의 보안 신뢰·보증·위험(Security, Trust, Assurance and Risk) 레지스트리. 1단계는 자체 평가(CAIQ 질문서) 공개, 2단계는 제3자 인증 또는 증명이다. 통제 기준은 클라우드 통제 매트릭스(CCM)이다. AI 서비스를 위해 AI 통제 매트릭스(AICM)와 ISO/IEC 42001을 바탕으로 한 STAR for AI도 운영한다
ISO/IEC 27017 ISO/IEC 27002를 바탕으로 클라우드 서비스 제공자와 이용자 양쪽을 위한 클라우드 보안 통제 지침을 더한 표준
ISO/IEC 27018 공용 클라우드에서 개인정보 처리자 역할을 하는 제공자를 위한 개인정보(PII) 보호 지침
SOC 보고서 AICPA 기준의 서비스 조직 통제 보고서. SOC 2 Type II는 일정 기간 동안 통제가 실제로 운영되었는지를 보여 준다
CSAP 한국인터넷진흥원이 운영하는 클라우드 서비스 보안인증. 공공기관에 클라우드 서비스를 제공하려는 사업자가 받는다
FedRAMP 미국 연방정부 기관이 쓰는 클라우드 서비스의 보안 평가·승인 제도
ISMS-P 인증 기준에 클라우드 보안 항목이 있어 클라우드 이용 조직도 책임 분담과 설정 관리를 점검받는다
  • 어떤 서비스 모델이든 데이터와 계정·접근 관리 책임은 이용자에게 남는다. "SaaS이므로 데이터 보호는 제공자 책임"은 흔한 오답이다.
  • 책임(responsibility)은 계약으로 넘길 수 있어도 최종 책임(accountability)은 넘길 수 없다.
  • 클라우드 사고의 가장 흔한 원인은 이용자 쪽 설정 오류이다. 설정 오류를 지속적으로 찾는 도구는 CSPM, SaaS 사용을 통제하는 도구는 CASB, 워크로드를 보호하는 도구는 CWPP로 구분한다.
  • 제공자를 직접 감사할 수 없으면 SOC 2 Type II, ISO/IEC 27001·27017·27018, CSA STAR 같은 제3자 보증을 요구한다. 감사권 조항은 계약 단계에서 넣는다.
  • 키를 제공자로부터 분리하려면 고객 관리 키, BYOK, HSM을 고른다. 암호화 키를 데이터와 같은 곳에 두지 않는다.
  • 클라우드 서비스를 해지할 때의 데이터 삭제와 데이터 잔존 문제는 이용자가 계약과 암호 삭제(crypto-shredding)로 대비한다.