클라우드 보안 컨설팅 실무

SK 쉴더스 루키즈

클라우드 보안 컨설팅 실무

todayisfriday 2024. 8. 10. 01:05

클라우드컴퓨팅 개요

연구논문에서의 정의

중요 키워드 : virtualized (가상화), dynamically provisioned (동적 공급), computing resources(pool of resources) (컴퓨팅 자원), Service Level Agreements, pay-per-use model
가상화 기반 기술 : 한정적인 자원을 나눠 쓰는데도 나눠서 쓰고 있는 지 모르게 하는 것

- 예시 : 부모님(?), 도서관의 책

동적 provisioning : 미래의 필요한 양까지 예측해서 공급하는 것
자원이라는 것은 석유, 전기, 가스, 물 이런 한정적인 것들인데 이런것들을 사람들에게 체계적으로 잘 분배하는 것이 중요하다는 의미를 담고 있는 것이 resources, 이제는 자원의 pool을 만들어 사람들이 어떻게 잘 쓸 수 있고 어떻게 비즈니스를 할 수 있을 지 고민하는 시대가 됨
SLA : 서비스 퀄리티는 기본적으로 특정 기준이 있어서 그 이상이 되도록 유지해야하는데 그 이하가 되면 어떻게 보상할 것인 지에 관해 규정하는 것
사용한만큼 돈을 내는 과금 체계

NIST에서의 정의

클라우드의 특징 : on-demand self-service (요구를 기반으로 자신이 직접 만드는 것)

--> 이케아를 생각하자

- broad network access (광범위한 네트워크 접근)

--> 개발도상국에서는 쉽지 않음

- resource pooling (자원공유체계)

--> 도서관을 생각하자

- rapid elasticity (빠른 탄성력)

--> 수강신청 생각하기

- measured service (측정된 서비스)

--> 택시 미터기 생각하기

서비스 모델 : SaaS, PaaS, Iaas

- 요즘은 SaaS가 각광받는중, IaaS위에 구동되는 중

Deployment Model (배포 모델) : private cloud, community cloud, public cloud, and hybrid cloud

클라우드 컴퓨팅의 현황

디지털 트랜스포메이션 시대 : AI + IoT

- CAPEX(설치비용) 감소, OPEX(운영비용)으로 대체

- 급작스러운 서버 사용량 증가 대비해야 함

- 보안은 항상 이슈임

대용량 데이터 스토리지 및 AI/ML API

- 4차 산업혁명 기초

- IoT 서비스 : 많은 원시 데이터 생성

- AL/ML : 데이터 분석 및 데이터에서 지식 도출

클라우드 컴퓨팅의 생태계 (Eco-System)

- 네트워크 : 접근망 / Core-망

- 수많은 장비들의 데이터들이 네트워크를 타고 와서 클라우드로 가게 됨

- 우리나라가 5G에서 나름 성과가 있고, 반도체도 잘 만들어서 하드웨어로도 잘 나감

- 근데 클라우드가 많이 약함 (Azure와 AWS에 다 뺏기는 중)

- 국내 생태계 형성이 중요함

2024년 통계 결과, 71%가 클라우드를 사용한다고 답 함

- 30% 정도만 가볍게 쓰거나 안 씀

SaaS 관련 의사결정 시 클라우드 가장 많이 연관되어 있음
그 다음이 클라우드 소프트웨어 의사 결정 시 사용
이런식으로 의사 결정에 많이 관여하고 있음을 볼 수 있음
퍼블릭 클라우드에 얼마나 쓰고 있냐

- 전체 응답자의 젤 많은 비율은 $2.4M ~ $60M

- 대기업들은 비슷하게 돈을 쓰고 있는데 중소기업의 경우에는 적은 비용만 사용하고 있음

- SaaS도 600만불 정도 사용하고 있음

--> 중소기업은 60만불 정도 사용중임

클라우드 쓰면서 가장 고민하는 것 : 비용 > 보안 > 인력과 전문성의 한계

클라우드서비스 카테고리 - IaaS

스토리지, 네트워크, 서버 서비스
Pay-as-you-go Model : 스마트폰 사용료에서 나온 말, 쓴만큼 돈 내는 것
사용자 고민 : Infra structure 관리가 복잡하고 돈이 많이 듬 / 과소지원, 과대 지원

- 자원 생성하고 관리하는 것 하려면 직원이 따로 있어야 함

- 과소 : 업무불편, 과대 : 비용 낭비

CSP (서비스 제공자) 해결 : 고민들을 해결해준다~~

클라우드서비스 카테고리 - PaaS

애플리케이션 개발에 필요한 클라우드 환경 제공
API들과 실행환경들이 필요함
사용자 고민 : 앱 구동하는 데 필요한 자원을 구매하는 것에 관한 고민 / 개발하는 데 필요한 운영체제 필요성
CSP 해결 : 다양한 실행 플랫폼으로 운영체제 제공해줌 (가상머신의 형태로) / 운영체제와 시스템 소프트웨어도 플랫폼으로 제공해 줌

퍼블릭 클라우드, PaaS 사용 통계

가장 많이 사용되는 : 데이터 웨어하우스

- DB가 가장 많이 차지하고 있구나

흥미로운 것 : 인공지능은 많이 사용되고 있는 실험량은 32%로 가장 높음

- 이게 실험이 다 되고 사용할래 라고 하는 순간 1등으로 사용되게 되는 것

클라우드서비스 카테고리 - SaaS

소프트웨어와 애플리케이션을 서비스로 제공하는 것
웹 인터페이스 기반으로 동작됨
사용자 고민 : 애플리케이션 매니지먼트가 어려움 (업데이트와 fix 설치) / 실행환경과 맞지 않음(새로운 버전이 나왔는데 개발자 피씨 성능과 사용자 피씨 성능이 다름) / 데이터 관리 어려움
CSP 해결 : 업데이트하고 픽스 관리 / SLA로 실행환경 해결 / 데이터 복사본으로 관리 용이

Public Cloud Adoption 통계

AWS 마켓 쉐어가 가장 큼
그 다음이 Azure : 엄청 많이 따라 잡은 것을 넘어 능가하려 함
GCP와 Oracle, IBM, Alibaba도 기억해줘야 함

- 사실 알리바바는 다른 나라에서는 안씀 근데 중국 내수 시장만 해도 엄청 크다는 것을 기억해야한다는 것

클라우드 배포 모델 - Public

퍼블릭 클라우드 구독 (AWS, Azure, Google, Naver Cloud)
사용자는 클라우드 서비스 제공 업체에 액세스 할 수 있는 단말기만 있음
데이터 문제의 책임

- 필수 데이터 유출 시 사고 처리 힘듦

클라우드 배포 모델 - Private

클라우드 컴퓨팅 인프라를 로컬(온프레미스)에 설치
사용자가 클라우드 컴퓨팅 환경에 액세스
클라우드 컴퓨팅 환경 전문가를 고용해야 함

클라우드 배포 모델 - Hybrid

통상적으로는 하이브리드 사용함

- 공개되고 외부에서 접근 가능한 서비스 존재 (퍼블릭)

- ERP와 SCM, DOC 등은 프라이빗으로 고나리

클라우드 배포 모델 - Multi Cloud

최근에는 이거 많이 사용함
여러 퍼블릭 클라우드 서비스 구독

- 여러 클라우드 접근에 필요한 VPN 설치 필요

클라우드 전략

멀리 클라우드 사람들이 어떻게 많이 쓰는 지를 보면 89%는 멀티 클라우드 사용중(멀티 클라우드 쓰는 업체 중 73%는 하이브리드를 사용함)
하이브리드 클라우드 사용할 때 멀티플 퍼블릭, 멀티플 브라이빗 쓰는 경우가 가장 많음
현재 기업들은 AWS, Azure 그밖의 사스 어떤 걸 쓸 지는 스마트폰 어떻게 쓸 지 쇼핑하는 것이다 (다만 좀 전문적인)

- 예를 들어 컴퓨터를 사려면 컴퓨터 사양에 대해 잘 알아야 하는 것처럼

- 각각의 구성 요소들을 어디 거를 쓰는 것이 좋은 지 알아둬야 함

보안 툴과 비용 툴 가장 많이 사용함 (보안과 비용이 핵심임)

Pros and Cons

Public Cloud VS Private Cloud

클라우드 컴퓨팅 서비스 동향 (넷플릭스, 킨들)

넷플릭스

2024년 주요 통계

- 총 가입자 : 2억 9천 600만

- 새 가입자 (1분기) : 900만

- 2023년 수입 : 3370만

클라우드 관점에서의 넷플릭스

- 2009년에 AWS로 이사함

- 이사하게 된 계기 : 2007년부터 on-demand video 스트리밍을 시작함 > 근데 이전에는 DVD를 우편으로 보내주고 반납하고를 진행함 > 2008년에 데이터가 망가져서 데이터 베이스에 접근이 안되는 사고가 있었음

AWS가 Infra 관리를 진행해주니 더 중요한 것에 집중할 수 있을 것이라 생각
근데 이 이사를 하는 게 8년이 걸림
더 이상 힘들고 무관한 일을 안하고 싶었음> 핵심 가치가 고품질의 비디오 감상 경험 제공이었음
AWS 이사 후 고객이 8배가 늘어남
Core Business : UI/UX를 기준으로 한 고객들의 클릭수 점검 (머신러닝)

프로필에 따른 내용 처리

트랜스코딩

- 하나의 비디오를 여러 포맷으로 변동

- 300,000 CPU 필요

절차 : 비디오 유효성 검사 -> 미디어 파이프 라인 (70개 스텝) -> CDN으로 변환 (장치)

- 70개 스탭 : EC2를 이용해서 Parallel Processing 진행함

- 2200개의 프로필에 적합한 인코딩된 비디오 만들어짐 (대역폭과 화면 크기)

- 지역에 맞는 오디오와 자막이 들어가서 영화 하나당 1200개의 파일이 존재하게 됨

이렇게 절차를 걸쳐서 수 테라바이트가 됨
이걸 AWS에 맡기는 것 : Undifferenciated Heavylifting

CDN for Netflix (Not in AWS)

Contents Delivery Network : 사용자가 영상을 시청할 때, 사용자가 시청하는 영상 이게 결국에 CDN을 통해서 다운로드가 되는 것/ 즉, 사용자와 직접적으로 연결되어 있는 장치 혹은 그 집합
CDN도 Undifferenciated Heavylifting으로 인식하고 써드파티 씨디엔으로 2009년에 추진함
나중에 방향을 바꿔 넷플릭스가 직접해야한다고 인식함
Netflix's CDN - Open Connect : 네트워크 효율성을 최대화하도록 함

- 비용 절감하며 고객 만족도 증대

- 사용자를 우리가 잘 알고 있다 > 국가별 선호도 분석 > CDN 운용에 적용

- 전세계 고객 근처에 위치 시킴

- OCA 계층화 시킴 : Large OCA / Smaller OCA

OCA and Content Caching

OCA를 전세계에 위치 시킴

- 1000곳 이상

- 넷플릭스는 백본 네트워크를 운용하지 않음

- OCA를 ISP나 IXP에 위치 시켜서 임대료를 내는 것

Netflix는 data-driven company : 데이터를 기반으로 하는 회사

- 컨텐츠를 특정 로케이션에 미리 갖다놓는 것

Play Button을 누르면

OCA와 사용자와의 컨텐츠 딜리버리가 중요함
Play 하겠다고 하면 이 요청을 받는 앱이 있고, OCA에서 URL을 가져와 데이터를 받게 되는 것

- URL : DNS 서버 역할을 하는 애가 있는 것

플레이 플레이 버튼 요청 받는 것과 OCA에서 URL 생성해주는 것이 클라우드에 있는 것 (AWS 안에)
S3버킷, transcoding해서 S3에 넣고 OCA에 넣게 되는 것

- 이것도 클라우드에 있는 것

넷플릭스는 사용자 화면의 UI/UX, S3 버킷의 data-driven proactive caching 해서 데이터 전달 하는 것 위주로 함 > 이게 넷플릭스의 core-business
넷플릭스 일 이전까지가 Undifferenciated Heavylifting
넷플릭스가 하는 일 중 하나 빠진 것 : 컨텐츠 생산
넷플릭스가 망하는 지름기 : 3-4일동안 볼만한 것이 없는 것

Amazon Kindle - since 2008

전자책 서비스 장치 (우리나라로는 밀리의 서재)
어떤 장치로 접근해도 어디까지 읽었는 지 기록되어 있을 수 있는 것은 cloud 덕분임
하나 더 중요한 것은 아마존의 북스토어 운영이 결국에는 저작자들 (작가들)에게 수익을 체계적으로 분배해주고 극대화해주는 하나의 새로운 Eco-System을 만들었다는 것임

- 기존에는 종이책으로 출판사에서 이익을 받는 것이었는데 고품질의 앱을 제공하여 작가들이 더 많은 수익을 얻을 수 있고 양질의 컨텐츠가 만들어지는 환경이 만들어지게 된 것

하나의 생태계가 만들어지면 알아서 돌아가며 돈이 벌어지는 것이 되는데 이 체계가 클라우드를 기반으로 만든 것

모바일 클라우드 서비스에 대한 이해

모바일 클라우드 서비스의 정의

네트워크라는 것을 나눠서 생각해야 하는데 모바일 디바이스가 있고, 인터넷에 접근하기 위해서는 무선 통신 망이 있어야 함
접근망에서 해줘야하는 중요한 일 : 단말들이 코어 망을 사용할 수 있도록 중계 역할을 해주며 과금 체계를 적용해줘야 함

- 모바일 네트워크 서비스라는 것이 여러 인터넷 회사들이 과금하는 역할을 해 줌

클라우드 서비스는 모바일 서비스의 백엔드 구성 요소로 작동함
모바일 단말과 IaaS, PaaS, SaaS가 연동이 되는 것

IaaS 연동

안에 들어가는 dadtabase, APIs, web servers는 다 개발자들이 해야 함
개발자가 백엔드 아키텍처도 다 고안해야 함

- composition : 무엇이 필요하고 무엇을 해줘야하는 지 설정하는 것

Infrastrucrure는 컴퓨터를 빌려오는 것이므로 당연한 것

- 방만 빌려서 이사간 것과 같음

PaaS 연동

모바일 단말! 하면 PaaS임
전형적인 모바일 클라우드 플랫폼들이 있음

- 개발자들의 편의를 위해

- 구글에서 제공해주는 firebase

- 시간을 줄일 수 있음

SaaS 연동

서비스 개발자들이 configuration만 하면 됨

- 들어가서 그냥 스마트폰에서 어떻게 할 지만 결정하면 끝임

Google Firebase Platform

핵심적인 백엔드 요소들 : realtime database, authentication, cloud messages, storage, hosting, remote config, test lab, crash reporting

- 사용자 적을 때 돈 조금, 많을 때는 많이 내면 되는 것

Google Firebase Platform - Authentication

인증 기능 구현하려면 힘들다

- 패스워드 저장해 둔 디비, 비밀번호에 관한 해시값이 있음

- 어떤 비밀번호 들어오면 두 개의 해시값 비교해서 같으면 허용, 다르면 거부

- 단순하지만 처음부터 만든다고 생각해보자 힘들지 않냐

firebase 쓰면 firebase authentication 기능 사용할 수 있음

Google Firebase Platform - Fire Store

DBMS > NoSQL DB (data, document, collection)

- 예시 : users > alovelace > 데이터 세 개 - first : "Ada" (키:value)

복사본 만들어 줌 (지역적인 복사본)

- 데이터 가져오는 데 걸리는 지연 시간 빠르게 해 줌

멀티 리전 복사본

- 높은 접근성

Google Firebase Platform - ML Kit

이제는 플랫폼 기반으로 text, face, image, barcode 인식 모두 가능

- 근데 다 돈 내고 하는 거임

모바일 디바이스의 자원 한계 극복

5가지 정도의 체계 갖고 있음 : Primary, Background, Mainline, Hardware, Muliplicity

- 모바일이 클라우스와 연동되기 위해 어떻게 체계가 이어지고 있는 지에 관한 것

예시 : 티 맵 사용시 모바일에서는 사용자가 어디로 가는 지 어떻게 가고 싶은 건 지 입력을 받음 > 실제 경로를 계산하는 것은 클라우드에서 뭔가를 해주는 것
primary : 핵심이 되는 기능을 클라우드에 시키는 것
background : 보강해주는 것 > 독립적으로 분리해서 실행하면 좋을 만한 것 > 클라우드로 올려주는 것

- 예시 : 바이러스 스캐닝

mainline : 프라이머리와 백그라운드 중간 사이
hardware : 스마트폰의 능력을 벗어나느 수준의 수행을 하는 것 > 고성능의 시스템에게 스마트폰이 못한느 것 하라고 전달하는 것
multiplicity : 실행하는 방식을 살짝 다르게 여러 버전을 실행을 해서 가장 좋은 것을 선택해주는 것

클라우드를 사용한 계산의 이관

a, b, c를 계산해야 함
근데 b가 시간이 너무 많이 걸리는 애임

- 스마트폰이 하면 과부하가 걸릴 거 같은거지

- 클라우드로 올려서 클라우드가 실행하게 하고 결과값을 돌아오도록 함

연습문제

1# 계산 비용 : 5, 실행 횟수 : 2, 클라우드로 보내는 비용 : 3

--> 5*2>3 그래서 모바일에서 쓰는 비용 10, 클라우드로 보내는 비용 3 이므로 클라우드로 보내는 게 더 좋다

2# 계산 비용 : 2, 실행 횟수 : 2, 클라우드로 보내는 비용 : 5

-->4 < 5 , 모바일

3# 계산 비용 : 3, 실행 횟수 : 2, 클라우드로 보내는 비용 : 6

--> 6=6 , 같음

4# 계산 비용 : 2, 실행 횟수 : 4, 클라우드로 보내는 비용 : 4

--> 6 > 4 , 클라우드

5# 계산 비용 : 5, 실행 횟수 : 2, 클라우드로 보내는 비용 : 3

--> 10 > 3 , 클라우드

6# 계산 비용 : 4, 실행 횟수 : 2, 클라우드로 보내는 비용 : 6

--> 8 > 6 , 클라우드

클라우드 컴퓨팅 보안 이슈들과 책임 분담

클라우드 컴퓨팅 보안 개요

존재하지 않는 이미지입니다.

1. 저장된 데이터의 보안

2. 이동 데이터의 보안

3. 사용자 / 응용 프로그램 / 프로세스 인증

- 외부에서 내부로 점근 시 , 인증 (내가 나임을 증명)

4. 서로 다른 고객에게 속한 데이터 간의 강력한 분리

- 분리(Separation)이 아주 중요한 것 / 가상화 - 철저한 구분 필요

5. 클라우드 법률 및 규제 문제 (미국 FedRamp 한국 CSAP)

- 민간과 공공 구분 : 법과 제도로 통제

6. 사고 대응

미사용 데이터 보안

암복호화 도구

- 저장되어 있는 데이터에 자물쇠를 걸어주는 것

- 데이터의 기밀성과 무결성 보장

데이터의 중복 (잉여 자산 만들어두는 것)

- 데이터 없어져도 복구해주고 서비스 운영에 문제 없이 만드는 것

이용자에 대한 책임

- IaaS

CSP는 이 영역에 대한 역할 갖고 있음 : PaaS, SaaS

이동중인 데이터 보안

암호화 기술은 필수 : 도청 및 조작 방지 위해
클라우드 안의 가상머신 사용자들은 비교적 안전하다고 생각할 수 있음

- 트래픽이 공용 인터넷을 통과하지 않는다는 것을 보장하기가 쉽지 않음

- 예시 ) 멀티 클라우드 구축 모델

사용자의 PC와 클라우드 서버 간 공용 인터넷을 통하는 것은 불가피함

- 상대적으로 위험하고 대책 필요

사용자/응용 프로그램/프로세스 인증

클라우드 환경 관리 콘솔에 대한 사용자 최종 시스템

- 클라우드 외부에서 합법적인 엑세스만 가능하도록 해야 함

대부분의 클라우드 서비스가 웹 기반 엑세스를 하고, 웹 콘솔이 하나의 게이트웨이 역할을 하게 됨
클라우드 서비스에 엑세스 하기 위한 웹 사이트는 공개적으로 위치함

- 웹에 대한 엑세스는 특별히 관리 및 제어 필요

- 잘 정의된 인증 매커니즘 필요

서로 다른 고객에게 속한 데이터 간의 분리

물리적 시스템이 여러 가상 머신을 배포하는 데 사용되는 경우

- 한 가상 머시의 컴퓨팅 리소스를 다른 가상 머신에 공개해서는 안됨

클라우드 컴퓨팅 환경의 멀티 테넌시 특성

- 클라우드 서비스 제공업체는 각 가상 머신의 독립적인 운영을 보장해야 함 (두가지 측면)

--> 데이터 기밀 유지 / 사이드 채널 은폐

클라우드 법률 및 규제 문제

클라우드 컴퓨팅 서비스는 법적 문제를 일으킬 수 있음

- 기업이 정보 자산을 클라우드 환경으로 이전하기로 결정한 경우

정보는 다른 국가에 저장될 수 있음

- 가능한 분쟁을 처리하는 방법을 고려해야 함

사고 대응

사고는 항상 존재할 수 밖에 없고, 컴퓨팅 소스 관리하는 것은 리모팅 플레이스에 있음

- 피해는 유저에게 돌아옴

효과적인 사고 대응 절차 만들어야 함

- 사용자와 클라우드 서비스 제공자가 함께 만들어야 함

- 사고 알람도 해주고 로그 쉐어링과 증거에 대한 체계가 있어야 함

사고 대응 툴들 많이 제공 해 줌

- 사고 대응 피해 경감 시킬 수 있는 기술

- 장애 도메인 및 자동 크기 조정 기술

클라우드 내 책임 분산

Data Protection : 이중에서도 Personal Data가 중요함 (Privacy)
책임 : 설정, 조작이 가능? + 직접 정할 수 있는 권한 있?
책임 공유의 의미 : 책임 떠넘기기가 아니라 역할을 명확하게 하기 위함 ~~(그게 결국 책임전가 아닌....)~~
On-premises Case : 사내 전문가 필요함
IaaS / PaaS and SaaS : 합리적인 경계가 필요함

- 분쟁 발생 시 합리적으로 해결하기 위함

AWS (Customers & AWS) : Customer responsible for security "in" the Cloud / AWS responsible for security "of" the Cloud

- AWS가 플레이그라운드를 마련해주고 그 안에서 고객들이 마음 껏 가동할 수 있음

가상머신과 컨테이너

가상화의 정의

가상의 버전 만드는 것

- 버추어 플랫폼, 스토리지 디바이스, 컴퓨터 네트워크 리소스 등

위험한 실험적인 새 기능 구동
자원의 공유

타임 쉐어링

프로세서는 한 번에 한 프로세스만 처리 가능

- 만약 그 중 한 프로세스가 heavy duty 갖고 있다면? 다른 것들을 못 처리하겠지

그래서 일정 시간을 정해두고 시간 초과되면 다른 것 처리하고 다시 돌아가는 것이 필요함 (라운드로빈 방식)
여러 방식이 있음

- SJF : Shortest Job First

- FIFO : First In First Out

- EDD : Earliest Due Date

효율성과 공평성 추구해야 함

Resource Pooling

자원의 풀을 만드는 것이 중요하다고 얘기했었음
Dedicated Resource VS Shared Resource : DR은 프라이버시와 안전 보장하고 SR은 유연성과 효율성 제공
풀을 만들어 자원들을 공유한다는 생각이 획기적인 것

가상화

가상화가 결국 리소스 풀을 만드는 기반이 됨

- Hypervisor : 가상 리소스와 물리적 리소스를 모니터링함

--> 가상 리소스와 물리적 리소스 사이 중개 역할

요청 기반 생성
가동률 높이는 것이 중요

가상머신 VS 컨테이너

가상머신은 하드웨어, 컨테이너는 운영체제 가상화하는 것
Machine Virtualization : Heavy 하지만 안전
Containers : Light함
보안 때문에 나눠두는 것이 좋은데 그럼 가동률이 낮아짐

가상머신의 장점

자원의 효율적 관리 가능
기업이 고객의 요청에 신속하게 응답하기 위해 새로운 서버를 추가해야하는 경우, VM을 짧은 시간 내에 배포할 수 있음
예측하지 못한 사고 대비 빠르게 가능 (만들어 둔 이미지로)
VM이 특정 수준의 활용도에서 사용되지 않는 경우 관리자는 VM을 종료하고 삭제할 수 있음

Type 1&2 Virtualization

Type 1 : 하드웨어에서 실행되며 하드웨어와 하이퍼바이저 사이에 소프트웨어 계층 존재하지 않음

- 일반적으로 하이퍼바이저에 액세스하고 제어하기 위한 콘솔 소프트웨어 있음

- 유형 1 하이퍼바이저는 호스트 OS에서 작동하는 유형 2에 비해 더 나은 성능을 제공

- 유형 1 하이퍼바이저로는 VMware vSphere with ESX/ESXi, Microsoft Hyper-V 및 Citrix Hypervisor(Xen Server) 있음

Type 2 : 호스트 운영 체제에서 실행되며 가상화를 위한 추가 소프트웨어 계층으로 존재

- 운영 체제의 하이퍼바이저는 서버 운영 체제의 다른 일반 응용 프로그램과 마찬가지로 응용 프로그램으로 취급될 수 있음

- 유형 2는 호스트 시스템의 애플리케이션이 하이퍼바이저 및 게스트 OS에 위협이 될 수 있으므로 보안 수준이 낮을 수 있음

- Type 2 하이퍼바이저로 VMware Workstation Pro/VMware Fusion, Oracle VirtualBox 등이 있음

유형 1 하이퍼바이저는 VM을 프라이빗 클라우드 인프라 및 리소스 풀로 사용하려는 기업에 적합
유형 2 하이퍼바이저는 개인용으로 배포되고 실험용으로 설정

Para-Virtualization VS Full-Virtualization

유형 1, 2와 다른 것임
Full : 운영체제에 대한 업데이트가 없음

- 게스트 운영체제가 자기가 가상화 공간에서 동작되고 있다는 것을 알지 못함

- 하드 웨어에 도움을 받는 케이스가 있음 : CPU의 도움을 기반으로 함

--> Hypervisor의 일부가 CPU에서 구현되어있어서 성능이 많이 개선된 상태이고, VMM이 -1에 존재해 여전히 0에 존재하는 특성을 갖고 있음

Para : 가상의 공간에서 실행되고 있는 것을 알고 있음

- Hypercall이라는 것을 만들어서 하드웨어에 액세스 함

Protection Ring and Virtualization

Protection Ring : Ring0에 있는 Guest OS와 Virtualization Layer가 한 몸처럼 움직임
Virtualizable 하다는 것 : 리소스 하나를 여러 주체가 공유해서 사용할 수 있다는 것을 말함

- 운영 체제 위에 애플리케이션이 여러 개가 올 수 있으면 virtualizable mode임

컨테이너

컨테이너를 사용하면 파일 시스템과 사용자 공간을 분리하여 앱이 호스트의 다른 앱과 독립적일 수 있음

- 독립 앱은 운영체제에만 있는 것처럼 실행 가능

용량 작음
패치 쉽게 설치 가능

도커

컨테이너를 구동하는 데 있어서 중요한 명령어 세 가지 있음

- build : 도커 이미지 활용해서 레지스트리로 옮길 수 있는 이미지 만드는 것

- pull : 도커 이미지를 레지스트리에서 가져오는 것

- run : 실행되는 것

원본이미지 -> 기능추가 -> 새로운 이미지 만들기 -> run

연습문제

VM 및 컨테이너에서 특정 애플리케이션의 파일 I/O 기간 계산

- 읽어야 하는 파일의 크기는 50GB / 저장할 파일의 크기는 30GB

- 기본 환경 – 읽기 100MB/초, 쓰기 80MB/초

- VM은 읽기 성능 저하 65%, 쓰기 성능 저하 75%

- Docker는 쓰기에서만 15%의 성능 저하

해설과 답

	Read	Write
Native	50000/100 = 500 sec	30000/80 =375sec
VM	50000/(100*0.35) =1428.6sec	30000/(80*0.25) =1500sec
Container	500sec	30000(800.85) = 441.2sec

가상머신 보안 이슈

Risk #1 - VM Sprawl

취약점 : 파일을 복사해서 가상 머신에 띄워주면 되는 방식인데 시스템 관리자가 VM의 취약성을 인식할 수 없음
대책 : VM의 도입 프로세스를 관리하고 제어하기 위한 효과적인 정책, 지침 및 프로세스와 이를 지원하기 위한 기술도구가 필요함

Risk #2 - Sensitive Data Within a VM

취약점 : 중요한 데이터에는 암호, 개인 데이터, bash 프로필, bash 기록 파일, 암호화 키 및 라이센스 키가 포함됨

- VM의 스냅샷에는 메모리 내용이 포함되어야 하며, 중요한 데이터를 노출할 수 있는 잠재적인 채널이 될 수 있음

대책 : 이미지를 만들 때 민감한 데이터가 포함되지 않도록 하기 위한 신중한 절차를 정의해야 함 이러한 이유로 이미지와 스냅샷이 생성될 때 민감한 데이터의 암호화를 고려할 수 있음

Risk #3 – Security of Offline and Dormant VMs

취약점 : VM에는 활성(실행 중), 휴면(일시 중단됨) 및 오프라인(종료됨)과 같은 세 가지 상태가 있음

- VM이 휴면 및 오프라인 상태인 동안에는 적절한 보안 패치 및 업데이트로 업데이트되지 않을 수 있음

- 제대로 업데이트되지 않은 VM이 온라인 상태가 되면 VM이 취약한 상태가 될 수 있음

대책 : 보안 업데이트 설치 및 보안 구성 적용과 같은 적절한 보안 관리 없이 오프라인 및 휴면 VM이 온라인 상태가 되지 않도록 하려면 효과적인 정책, 지침 및 프로세스가 필요

- 보안 업데이트를 설치하고 오프라인 및 휴면 VM에 대한 보안 구성을 적용하는 기능이 있는 관리 솔루션 필요

Risk #4 - Security of Pre-Configured (Golden Image) VM / Active VMs

취약점 : VM 이미지는 인터넷이나 USB 메모리 스틱을 통해 전송되는 동안 파일로 존재하기 때문에 해당 VM 이미지를 손상시키기 위해 악의적으로 가로챌 가능성이 있음

- 특정 환경이나 일정 기간 동안 널리 사용되는 골든 VM 이미지가 있는 경우 피해를 입는 영역이 더 넓어질 수 있음

대책 : 모든 VM 이미지에 대한 무결성 체크섬 메커니즘을 구현 필요

- VM 이미지 암호화가 효과적인 보안 대책이 될 수 있음

Risk #5 – Lack of Visibility Into and Control Over Virtual Networks

취약점 : 엔지니어가 가상 네트워크의 보안 정책을 파악하는 것은 일반적이지 않음

- 엔지니어는 소프트웨어 기반 가상 네트워크에 보안 대책을 배포하기 위해 더 많은 연구를 해야 함

- 트래픽 모니터링 도구는 VM-VM 채널의 트래픽을 인식할 수 없음

대책 : 보안 관리자는 가상 머신 간의 트래픽을 모니터링하기 위한 특수 도구를 조사해야 함

- 물리적 시스템용 도구와 통합된 방식으로 기술 도구를 배포

Risk #6 – Resource Exhaustion

취약점 : 만약 동시에 바이러스 검사한다면 전체 성능이 느려질 수 있음
대책 : 리소스 집약적인 소프트웨어 사용은 가상 머신 환경에서 제어되어야 함

Risk #7 – Hypervisor Security

Risk #8 - Unauthorized Access to Hypervisor

취약점 : 해커는 하이퍼바이저를 겨냥하여 VM에 대한 무단 액세스 권한을 얻는 데 성공할 수 있음

- 하이퍼바이저에 액세스하는 방법은 다양하며 하이퍼바이저에 따라 다름

- 하이퍼바이저에 대한 액세스 제어는 공급업체의 특정 하이퍼바이저를 잘 관리하는 엔지니어의 전문 지식임

- 하나의 VM에 먼저 침투하여 VM을 디딤돌로 삼아 하이퍼바이저를 공격하는 "하이퍼재킹"이라는 악성코드가 있음

대책 : 공급업체에서 제공한 모범 사례를 따르기

- 모범 사례에는 VM 간 메모리 공유 비활성화, 부팅 시 자체 무결성 검사 수행 등 하이퍼바이저 보안을 위한 모든 종류의 구성이 포함됨

- 보안 하이퍼바이저 유형을 선택할 때는 유형 2보다는 유형 1 하이퍼바이저를 사용하는 것이 좋음

- 하이퍼바이저에 대한 액세스 관리와 관련하여 잘 정의된 정책과 충분한 정책 테스트를 통해 역할 기반 액세스 제어를 배포하는 것이 더 나음

Risk #10 – Workloads of Different Trust Levels Located on the Same Server

취약점 : 물리적 시스템의 VM 중 하나가 중요 업무용 워크로드를 처리함

- 동일한 물리적 시스템의 다른 VM이 덜 중요한 워크로드 처리함

--> 중요 업무용 VM에서 부채널 또는 서비스 거부를 통해 예기치 않은 데이터 유출이 발생할 수 있음

- 즉, 낮은 보안수준의 일 처리하다가 높은 보안수준 일에 문제 생길 수 있다는 것

대책 : 다양한 보안 분류에 따라 워크로드를 분류하는 정책을 구현해야 함

- 서로 다른 보안 수준의 워크로드는 서로 다른 물리적 시스템과 서로 다른 물리적 및 가상 네트워크에 할당되어야 함

- 보안 관리자는 사용 유형 및 프로덕션 단계에 따라 보안 영역을 정의해야 함

- 보안 영역에는 여러 VM이 포함되며 워크로드 보안 분류를 보안 영역의 목적과 일치시켜 워크로드를 VM에 할당함

CSAP 소개

클라우드 관련 정부 정책

클라우드컴퓨팅 시대 도래 (HW와 SW 직접 구매 및 설치 대신 서비스로 이용) => Cloud First Policy

- 선진국은 클라우드 우선 정책

클라우드 컴퓨팅 법 제정 (15년 3월) : 클라우드 컴퓨팅 발전 기본 계획 수립 및 시행

- 전문기업, 기술 및 인력 취약

- 보안우려, 인식 부재

- 클라우드 이용 제한 제도 관행

잠재된 위협보다 더 큰 기회 가능성

- 클라우드 시대에는 절대강자 부재

- 적은 투자로 글로벌화 간으

클라우드 관련 법령

클라우드 컴퓨팅 발전 및 이용자 보호에 관한 법률

- 정부의 클라우드 육성 지원 근거 마련

- 규제 개선을 통한 공공/민간의 클라우드 이용 활성화 근거 말녀

- 안전한 클라우드를 위한 이용자 보호 근거 마련 : 정보통신망법 및 개인정보보호법

고시 제정 : 클라우드컴퓨팅서비스의 안전성 및 신뢰성 향상에 필요한 정보보호 기준의구체적인 내용 정함

- 고시 제 7조 : "보안인증제"시행을 위해 클라우드컴퓨팅서비스 제공자가 그 서비스가 이 기준 준수하는 지와 한국인터넷 진흥원 장이 그 서비스 조사 또는 시험 및 평가하여 인증 가능

보안인증 관련 정책

공공부문 민간 클라우드 서비스 도입

- 16년 5월 가이드라인 개정되면서 보안인증제에 따라 인증된 클라우드 서비스 도입할 수 있게 함

- 클라우드 서비스 보안인증제 시행

- 보안 인증제 확대 시행

- SaaS 분야 보안 인증 등급제 시행

- DaaS 분야 확대 시행

- 22년 3월에 고시 제정

법률 개정

- 국가기관 등의 보안인증 받은 클라우드컴퓨팅서비스 우선 고려 : 국가와 지방자치단체도 클라우드컴퓨팅서비스를 적극적으로 이용

- 정보보호에 관한 기준을 보안인증기준으로 사용 : 정보보호호에 관한 기준을 보안인증기준으로 사용

- 클라우드 보안인증, 인증취소 등 보안인증제도의 법적 근거 마련

클라우드 보안 인증제도 개요

목적 : 공공기관에게 안전성 및 신뢰성이 검증된 민간 클라우드서비스 공급
근거 : 고시 제 7조 정보보호 기준의 준수 여부 확인
기준 : 관리적, 물리적, 기술적 보호 조치 및 공공기관용 추가 보호 조치 총 14개 부문 117개 통제항목으로 구성
평가 방법 : 서면 / 현장 평가 + 취약점 점검 (CCE, CVE, 소스코드) + 모의침투 테스트
인증대상 : IaaS (컴퓨팅 자원, 스토리지 등 정보 시스템의 인프라를 제공하는 서비스), SaaS(인프라 외에 각종 응용프로그램을 제공하는 서비스), PaaS (클라우드 관련 서비스를 개발하는 환경 제공), DaaS(가상 PC 제공을 위한 서비스)
예시 ) SaaS 평가 인증 대상 : 보안 인증을 받은 IaaS 서비스 환경에 구축, SaaS 등급 유형은 표준(중요 데이터 다루는 SaaS)과 간편, 다수의 기관을 대상으로 퍼블릭 형태로 소프트웨어를 제공하는 서비스 대상

평가 및 인증 절차

최초 평가 --1년--> 사후평가 --1년--> 사후평가 --1년--> 갱신평가
준비단계 (30-60일) > 평가단계 (30일-120일) > 인증단계 (15일) > 사후관리단계

SaaS 보안 인증 점검 사항

관리적 / 기술적 점검 사항 : 정책, 지침, 절차 잘 따랐는 지 / 취약점 점검, 소스코드 점검, 모의 침투
사업자 준비사항 : 관리적 점검 / 기술적 점검