클라우드 컴퓨팅 강의 3. 클라우드 컴퓨팅 기술

1. 클라우드 컴퓨팅 강의3. 클라우드 컴퓨팅 기술 2011년 04월 02일(3주차)

2. Contents 3.1 클라우드 컴퓨팅 구조 3.2 가상화 기술 3.3 클러스터 3.4 분산 시스템 3.5 서비스 지향 아키텍처 3.6 SaaS 플랫폼 3.7 보안 3.8 그린 컴퓨팅 명지대학교

3. 3.1 클라우드 컴퓨팅 구조 • Cloud Computing 요소기술개념구조 PaaS SaaS IaaS Saas[Software as a Service] : 웹 기반 원격 접근 App. PaaS[Platform as a Service] : 개발환경 OS, 서버 Iaas [Infrastructure as a Service] : 가상 원격 컴퓨팅 자원 Cloud Computing Utility Computing Utility Computing : 사용자가 사용한 컴퓨팅자원(CPU,메모리,디스크I/O 등)에 대해서만 과금이 가능한 컴퓨팅 아키텍처  Grid Computing : 대규모 분산 컴퓨팅 아키텍처(계산/협업/데이터 그리드로 분류) ※ Cloud Computing에는 서버/스토리지 가상화 기술 적용이 필수 적임 Grid Computing Cluster Computing Super Computing 명지대학교

4. 3.2 가상화 기술 Partitioning,하이퍼바이저, I/O가상화 시스템(서버) 가상화 • 가상화기술의분류 컨트롤러/블록/Tape/ File(System)가상화 스토리지 가상화 인프라(자원) 가상화 네트워크 가상화 VirtualIP, 802.1Q(VLAN) 파일 가상화 클러스터/그리드파일시스템 SOI2) 기반 가상화 정보 가상화 데이터 가상화 데이터연합&통합, (데이터)그리드 트랜잭션 가상화 데이터연합&통합, (데이터)그리드 워크로드 가상화 테스크 가상화 JVM로드밸런싱 실리콘이중막웨이퍼(SOI:Silicon On Insulator) 트랜지스터와 트랜지스터간에 인위적인 절연막을 형성시켜 반도체 칩의 성능은 높이면서 전력소모량을 크게 낮출 수 있는 실리콘이중막웨이퍼(SOI:Silicon On Insulator)기술 프리젠테이션 가상화 SBC 명지대학교

5. 3.2 가상화 기술 • 가상화 기술 종류 및 특징 명지대학교

6. 3.2 가상화 기술 • 가상화 기술 종류 및 특징 명지대학교

7. 3.2 가상화 기술 • 가상화 기술 종류 및 특징 명지대학교

8. 3.2 가상화 기술 • 가상화 기술 종류 및 특징 명지대학교

9. 3.2 가상화 기술 • 가상화 기술 종류 및 특징 멀티 테넌시(Multi-tenancy) : 하나의 시스템을 여러 고객(기업)이 사용하는 형태를 명지대학교

10. 3.2 가상화 기술 • 주요 IT 목적에서의 가상화 기술의 위치 Mobile and Remote Working VolP and UC Agility ITIL and Process Improvement Virtualization and Consolidation Microsoft Migrations T/I&O Modernization Economics Service Quality Green IT/I&O 명지대학교

11. 3.2 가상화 기술 • IT 발전 방향에서의 가상화 기술의 위치 IT/ I&O Modernization Virtualization and Consolidation ITIL and Process Improvement Microsoft Migrations Green IT/I&O Mobile and Remote Working VoIP and UC ITIL: 정보 기술(IT) 서비스를 지원, 구축, 관리하는 프레임워크. 효과적인 IT 서비스 관리를 위한 일종의 교본 명지대학교

12. 3.2 가상화 기술 • 가상화의 종류 • 완전 가상화 Full Virtualization • 운영체제 계층 가상화 OS level Virtualization • 반가상화 Para-Virtualization • 어플리케이션 가상화 Application Virtualization VMM : Virtual Machine Monitor = Hypervisor 프로세서나 메모리와 같은 다양한 컴퓨터 자원에 서로 다른 각종 OS의 접근 방법을 가상화하여 통제하는 얇은 계층의 소프트웨어, 가상화 레이어. 호스트 컴퓨터에서 다수의 운영 체제(operating system)를 동시에 실행하기 위한 가상 플랫폼(platform)을 말한다. 명지대학교

13. 3.2 가상화 기술 • 가상화의 종류(완전 가상화 Full Virtualization) • VMware • Micro SoftVirtual PC • KVM (Kernel-based Virtual Machine, Linux용 Open Source) • Hypervisor Architecture 사용 • 다양한 OS를 수정 없이 가상 Server상에 Install 가능 • 단점 : Hypervisor에 의해 Processor에 큰 Overhead 발생 명지대학교

14. 3.2 가상화 기술 • 가상화의 종류(운영체제 계층 가상화 OS Level Virtualization) • 단일 OS내에서 가상화가 이루어짐 (별도의 가상시스템이 미 존재) • 가볍고 속도가 빨라 효율적, 대량의 가상 인스턴스 지원 • 단점 : 인스턴스 격리와 보안문제, 가상 인스턴스는 반드시 동일OS지원 필요 명지대학교

15. 3.2 가상화 기술 • 가상화의 종류(반 가상화 Para-Virtualization) • Xen (open source) • 물리적 하드웨어의 수정 복사본으로 서버 하드웨어와 동일한 아키텍처 • Guest OS를 수정하여 Near-native speed구현 가능 (hypercall) • 단점 : hypercall의 구현을 위해서는 guest OS의 수정이 필요 명지대학교

16. 3.2 가상화 기술 • 가상화의 종류(어플리케이션 가상화 Application Virtualization) Application Virtualization Layer • 물리적 플랫폼으로부터 완전히 분리되어 가상화 계층과 상호 작용 • 주문형 애플리케이션 스트리밍 애플리케이션 구축속도 향상 • 단점 : 가상 시스템 지원에 따른 부담 런타임/네이티브 환경 실행속도 저하 가상화 가능한 소프트웨어가 제한적 명지대학교

17. 3.3 클러스터 • 클러스터관리기술개요 원활한 서비스 제공을 위하여,그 자체가 방대한 컴퓨터 클러스터 시스템인 클라우드 컴퓨팅 인프라에 대한 노드 관리,자동 업데이트 및 자동 설치, 프로비저닝, 그리고 로드 밸런싱 및 자동 확장성 제공이 필요함 • 컴퓨터 클러스터의 정의 많은 양의 계산을 하거나 데이터를 저장하기 위해 여러대의 컴퓨팅 자원을 하나로 묶어 놓은 시스템 ※클라우드 컴퓨팅 서비스를 제공하는 클라우드 시스템 역시 매우 방대한 개수의 시스템들의 집합인 클러스터 시스템으로 정의할 수 있음 명지대학교

18. 3.3 클러스터 • 클러스터관리기술개요 • 컴퓨터클러스터의분류 명지대학교

19. 3.3 클러스터 • 주요요구기능 명지대학교

20. 3.4 분산 시스템 • 분산데이터관리 분산 데이터 관리 시스템(DDMS : Distributed Data Management System)은 대규모의 구조화된 데이터를 여러 부분으로 나눈 후,분산 저장/관리하는 클라우드 컴퓨팅 구현의 필수 구성 요소임 인터넷 응용 기반 클라우드 컴퓨팅의 분산 데이터 관리 요구 사항 확장 성 데이터 사용 요구 및 데이터 양 급증에 대응하여 동적으로 관련 시스템을 추가할 수 있는 유연성 고가용 성 동일 Data Set 복제 본을 다수의 분산된 위치에 저장하여 데이터 유실 및 서비스 중단 방지 고속처리 단순화된 데이터베이스 조회 연산으로 사용자 요청의 고속 처리 지원 • 분산병렬처리 • 네트워크를 경유하여 연결된 다수의 시스템들 간에 연산 작업을 병렬로(동시에) 수행하는 기술 • 대용량 데이터를(비즈니스에) 적정한 시간 내에 가공/분석하기 위하여 분산 병렬 처리 기술이 • 활용됨 명지대학교

21. 3.5 서비스 지향 아키텍처 • SOA 필요성 증대 • 통신 회사(KT,SKT 등) 및 금융권(하나은행 등)의 차세대 시스템의 SOA 아키텍처 도입 증대 • SOA 투자로 인한 직간접적인 프로젝트 증대로 매출 순위의 뒤바뀜 (세계 SI 시장 1위 탈환) 명지대학교

22. Business 목표 IT 아키텍처 서비스 지향 IT 아키텍처 비즈니스 전략 (PI, BPR) • 비즈니스 변화에 대응하는 서비스 중심으로 IT 응답성 제고 3.5 서비스 지향 아키텍처 비즈니스 요구사항 경영 환경 변화 요인 (동인) 아키텍처 요구사항 비즈니스  서비스 • 변화하는 비즈니스 환경에신속하게 대응 • 비즈니스 효율성과 성능을 향상 • 기업 내 각 부서, 비즈니스 단위, 비즈니스 파트너와의 통합운영 • 변화하는 비즈니스의 우선 순위를 신속히 적용할 수 있는 정보기술 체계 필요 • IT를 비즈니스 전략에 보다 밀접하게 연관시킴 • 비용 효율적 구조 • 안전하고 관리 가능한 환경을 제공 SOA 명지대학교

23. 3.5 서비스 지향 아키텍처 • SOA Position • Gartner 곡선에 의하면 SOA는 안정화 단계 및 실현 단계로 5-10년 사이 main stream이 될 것으로, SOA는 피할 수 없는 현실이며, 기업의 SOA Transformation이 중요해질 것으로 예상하고 있음

24. 3.5 서비스 지향 아키텍처 • SOA(Service Oriented Architecture) 개념 • IT 시스템의 유연한 아키텍처를 서비스로 재구성함 • Service는 비즈니스 서비스와 함께 IT 서비스로 분리 가능하며 • 이를 총괄적으로 구성 Enterprise Service 관리 방안이 있어야 함 비즈니스 관점 Service Oriented Alignment Service 정의 Architecture IT 관점

25. 3.5 서비스 지향 아키텍처 • SOA 목적 • 기업의 비즈니스 변화에 IT 가 빠르게 대응할 수 있도록 고객의 비즈니스와 이를 뒷받침하는 Enterprise IT 아키텍처를 밀접하게 Align 시키도록 Principle, Framework, Methodology 를 제공함 SOA Goal Business And IT IT 비즈니스 Concept and Principle Framework Methodology

26. 3.5 서비스 지향 아키텍처 • Service Oriented Architecture(서비스 지향 아키텍처 )란 ? • - 서비스 요청자(Client)와 제공자(Server)로 이루어진어플리케이션 소프트웨어 설계방식 • - 표준기반의 공통사용(재사용)이 가능한 서비스들의 관계를 느슨한 관계로 모델링하여 소프트웨어의 서비스화를 지향하는 아키텍처 ☞ 웹 서비스(Web Service)는 SOA의 구현을 위한 현존하는 최적의 기술 대안 SOA 의 비즈니스 관점 및 서비스 관점 …whereby business activity components are packaged as well-defined services, accessible electronically by partners, suppliers and others …which is implemented within an architectural technology framework optimized for this purpose + Technology Focus (Architecture) Business Focus (Service Oriented)

27. 3.5 서비스 지향 아키텍처 • 기본요건 • SOA 는 표준화에 따른 서비스 구성을 통해 Layered 구조를 이루게 하며, 재사용 가능한 서비스 모듈의 사용 방안을 제공하여 서비스간 Loosely-coupled되어 통신하도록 하여 유연한 비즈니스 대응을 가능하게 함

28. 3.5 서비스 지향 아키텍처 • 서비스 지향 아키텍처의 특징 • 느슨한 연결 (Loosely Coupling) : 기민하게 각 서비스의 내부 구조 및 구현의 변화에 대응 • 굵은 입도 (Coarse Granularity) : IT환경의 기술적인 복잡성을 덮어줌 • 재사용 (Reuse) : 개발기간 단축, 비용 절감 • 민첩성 (Agility)향상: 서로 다른 환경에서 개발된 시스템의 통합이 쉬우며, 변경 요청 발생時 • 신속 대응이 가능해짐 • 개발 생산성 행상 : 개발자는 자신이 개발하는 시스템에서 어떤 서비스를 요청할 것인가만 • 신경을 쓰면 되고, 요청한 서비스가 어떻게 처리되는지는 몰라도 됨 사용자 사용자 SOA 주문 처리 업무 서비스 고객 모듈 재고 모듈 송장 모듈 배송 모듈 실적 모듈 고객 관리 재고 관리 송장 관리 배송 관리 실적 관리 주문 처리 업무

29. 3.5 서비스 지향 아키텍처 • 1) 상호 운용성(Interoperable) • Universal Interface 인 Web Services 기술을 이용하여, • 기존의 독점적인 “Lock and Key” 디자인이 아니라, • 어디에서든 통하는 전기 socket과 같은 Interface를 통해 다수의 응용 어플리케이션과 쉽게 결합할 수 있는 기반을 제공함 • 예) 전자 제품 과 Wall-Sockets / USB 와 USB Device

30. Applications composed of Services 3.5 서비스 지향 아키텍처 • 2) 조합 가능성(Composable) • Web Services 기술은 WSDL을 이용하여 자신의 묘사가 가능하며 이런 “Self-Describing” 특성과 SOAP을 통한 상호 운용성은 Software 솔루션을 서비스 조합으로 가능하게 함 • 서비스의 Building Block 화

31. <description> <types> </types> <interface name = “..”> </interface> <binding name = “..”> </binding> <service name= “..” interface = “..”> </service> </description> 3.5 서비스 지향 아키텍처 • 3) 재사용성 (Reusable) • 서비스는 자신을 설명하는WSDL (Web Services Description Language)를 갖고 있는 단위 소프트웨어로 SOAP 메시지 통신을 통해 언제 어디서든 호출 가능함 • 이런 특징을 갖는 서비스는 재사용이 가능하며, 따라서 Repository에서 관리되어 짐 WSDL is a Key Request Service Response Repository / UDDI *) UDDI = Universal Description, Discovery and Integration

32. 3.5 서비스 지향 아키텍처 • 4) 느슨한 결합 (Loosely-coupled) • 서비스 간 연동은 웹 서비스를 Wrapper로 사용하여 Loosely 하게 연동하도록 함 • 중요 비즈니스 서비스의 인터페이스를 웹 서비스로 노출하고, 호출 시 또한 웹 서비스를 활용, 플랫폼 및 기술에 독립적인 Coupling을 이루게 함 X Order Web Service I_SalesOrder_Create Sales Order Application Platform Z Order Service Procurement Application Web Service Interface Platform X

33. Abstraction ServiceWrapper ServiceWrapper InfrastructureServices ExistingApplication ExternalServices ExistingApplication 3.5 서비스 지향 아키텍처 • 서비스 Granularity(입자성) 및 Abstraction(추상성) • 입자가 굵은(Coarse Grained) Business Service와 입자가 작은(Fine Grained) Impl. Service의 적절한 조합(Aggregation)및 추상성을 통해 서비스 기반의 비즈니스환경 구축 가능 • 고려요소 • 굵은 입자성 • 외부에서 사용의 적절성 ) • 느슨한 연결 / 디자인 • Low level 서비스와 Business 서비스의 조합 Aggregation Fine Grained Implementation-Based Services

34. 3.5 서비스 지향 아키텍처 • 서비스 통한 신속한 개발 가능 • 새로운 비즈니스인 교육 사업을 위한 Course Management Application 프로그램 개발 시 이미 개발되어 사용되어지는 서비스를 호출하여 구성 가능하며, 새롭게 개발되는 Room Availability 서비스는 또 다른 비즈니스 or 어플리케이션에서 호출하여 사용 가능함 새로운 어플리케이션은 쉽게 사용 가능한 서비스를 찾을 수 있음 주문 처리 어플리케이션 (Order Processing Application) 과정 관리 어플리케이션 (Course Management Application) 새로운 서비스는 또한 다른 Application에서 사용 가능함 고객 찾기 Service 신용 체크 Service 물품 처리 Service 재고 체크 Service Room Availability Service

35. 3.5 서비스 지향 아키텍처 • 서비스 Communication • SOA Infrastructure에 의해 서비스의 프로토콜과 data 변환이 가능하여 확장 성을 보장 가능 Order Processing Application SOA Infrastructure 는 어플리케이션과 서비스 사이의 통신 메커니즘을 제공함 SOA Infrastructure 서비스의 변경 사항은 기존 서비스를 사용하는 Application에 영향을 미치지 않음 고객 찾기 Service 신용 체크 Service 물품 처리 Service 재고 체크 Service

36. 3.5 서비스 지향 아키텍처 • Service Legacy 연계 • 서비스 기반의 infrastructure를 통해 Legacy 시스템과의 연결을 표준화함. 어플리케이션은 SOA Infrastructure를 통해 Legacy의 서비스를 연동함으로, 신뢰성 있는 환경을 제공할 수 있음 Order Processing Application 어플리케이션은 서비스를 표준화된 방식으로 access 함. SOA Infrastructure 레가시 시스템의 복잡함과 다양함을 단순하고 명쾌하게 함 고객 찾기 Service 신용 체크 Service 물품 찾기 Service 재고 체크 Service 레가시 시스템을 호출하는 것이 서비스의 역할임 Manufacturing System Customer Management System

37. 3.5 서비스 지향 아키텍처 • SOA 구성 • SOA 아키텍처는 기본적으로 Service Provider, Service Consumer, Service Broker로 이루어진 구조 • 자기 설명적인 (Self describing) 인터페이스를 (WSDL)를 가진 서비스는 플랫폼 독립적인 XML 형식으로 Formally하게 정의되어, Service Broker를 통해 서비스로 등록하고 관리되어 애플리케이션 수가 증가해도 서비스를 찾을 수 있는 방안이 제공됨 (UDDI) Service Broker Find Register Service Contract Service Consumer Service Provider Bind Client Service ※ UDDI(Universal Description, Discovery, and Integration) - 인터넷에서 전 세계의 비즈니스 업체 목록에 자신의 목록을 등록하기 위한, XML기반의 규격 37

38. 3.6 SaaS 플랫폼 SaaS 개념 소프트웨어 구축 및 유지보수 비용이 증대하고, 비즈니스 변화에 신속히 대응할 수 있는 소프트웨 어에 대한 요구가 높아짐에 따라 SaaS 모델이 등장하였음 소프트웨어 전달 방식의 변화 On-Demand Business Services On-Demand Business Services 􀂄 사용량 기반 􀂄 비즈니스 프로세스에 초점 SaaS 􀂄 구독료 모델 􀂄 신속한 솔루션 적용 􀂄 낮은 버전 및 성능 컨트롤 􀂄 IT 자원 투입 적음 Software as a Service On-Premise Software 􀂄 라이센스 모델 􀂄 데이터 센터에 인스톨하거나 호스팅 􀂄 버전 컨트롤, 성능 컨트롤 필요 􀂄 IT 구축에 많은 자원 투입 􀂄 긴 업그레이드 사이클 Software as a Product 38

39. 3.6 SaaS 플랫폼 고객의 프로세스 민첩성에 대한 요구, 소프트웨어 업계의 안정적인 수익 창출 요구, SOA 기술의 발전에 힘입어 SaaS 도입에 대한 관심이 높아지고 있음 고객 측면 시장 측면 • 고객의 Agility 확보 니즈 • • 프로세스 민첩성 및 유연성 확보가 최대 이슈인 상황에서 • 현재의 방식은 부담 • • 초기 도입 비용의 부담을 줄이고, 업그레이드/유지보수 • 고민에서 상당 부분 해방 • SW 업계의 수익 구조 개편 요구 • • 보다 안정적이며 지속적인 수익 구조 확보를 위해 • 비즈니스 모델 전환 필요 • • 제3의 서비스 업체 없이 또한 이들의 역할이 최소화된 • 상태에서 직접 제공 가능함으로써 현재의 수익 구조를 • 획기적으로 개선 기술 측면 미래의 고도화된 SaaS 모델 • SOA 기술의 발달 • • SOA 기술의 발달은 비즈니스 요구 사항에 따라 동적으로 어플리케이션을 모델링하여 사용할 수 있게 함 • - Web2.0으로의 진화 • • 플랫폼으로서의 웹으로 발전함에 따라 웹을 통한 • 어플리케이션 서비스 가시화 39

40. 3.6 SaaS 플랫폼 ASP와 SaaS 서비스는 서비스/관리 방식이나 비용청구 방식에서는 유사하나, 아키텍쳐/커스터마 이징, 기능/성능 개선방식, 서비스 제공자 등 다양한 분야에서 차이를 나타내고 있음 40

41. 3.6 SaaS 플랫폼 SaaS Maturity Model • Level 1: Ad Hoc/Custom • 1990s • 개별 고객을 위해 소스 코드를 수정한 SW 제공 • SW 인스턴스는 완전한 독립 유지 • Client-server architecture • Level 2: Configurable • 동일한 소스 코드 사용, but 고객별 환경 설정 가능 • 여전히 인스턴스 분리 • 대폭적인 SW Architecture 수정 필요 • Level 3: Configurable, Multi-Tenannt-Efficient • 단일 인스턴스를 통해 모든 고객 서비스, 메타데이터를 • 통 해 고객 환경 설정 가능 • 권한제어, 보안 정책에 의한 컨트롤 필요 • 효율적인 자원 사용을 통한 운영 비용 절감 가능 • Level 4: Scalable, Configurable, Multi-Tenant-Efficient • 인스턴스들의 로드 밸런싱이 가능함 • Scalability 보장(고객 수에 따라 서버, 인스턴스 증감 • 가능) 41

42. 3.6 SaaS 플랫폼 Gartner는 SaaS서비스의 모델을 6계층으로 나누고 있으며, 그 중 플랫폼 계층은 SaaS화하기 위해 필요한 모든 Hardware와 Software 구성요소로 정의함 42

43. 3.6 SaaS 플랫폼 해외는 대기업 사업부에서 시작하여 중견, 중소 기업으로 도입이 확산되는 경향을 보이며, 국내는 중소기업 정보화등의 영향으로 중소기업 중심이었으며 향후 중견, 대기업 사업부 등으로 확산될 것으로 예상됨 43

44. 3.6 SaaS 플랫폼 SaaS 종합 종합 이슈 <고객에게 주는 가치> 􀂃Core Competency에 집중 􀂃위험 감소 - Zero IT - Low TCO - Pay as you go 􀂃작업 환경 개선 - Security - Uptime(Access Anytime) - Global Access(Access Anywhere) 􀂃혁신 지원 - 고객이 주도하는 애플리케이션 기능 강화 - 잦은 업그레이드 <벤더에게 주는 가치> 􀂃예측 가능한 수익 􀂃개발 및 지원 비용 절감 􀂃판매 및 마케팅 비용 절감 􀂃고객 친화도 증가 <SaaS 벤더가 풀어야할 문제> 􀂃Business Continuity “ 데이터를 영원히 잃어버릴 가능성” 􀂃Data security and privacy “내 데이터가 안전성과 비밀 보장성” 􀂃Accessibility “내 데이터에 지금 접근 가능성” 􀂃Functional Limitation “서비스 재구성 가능성” 􀂃Legacy Integration “레거시 업무 시스템과 유연한 연동” 􀂃Application Performance 44

45. 3.6 SaaS 플랫폼 SaaS 향후 과제 • 􀂃TCO 증명 • 􀂃SW 제작 • – Consulting • – Multi-tenant Architecting Principles • – Database, Application, Control • – Quick & Easy SW Creation Tool • 􀂃유통 • – SW 가격 책정 방안 • 􀂃서비스 • – SaaS Enabled Platform 국산화 • – Metadata 관리 방안(UI, Process, Data, Control, Version) • 􀂃과금 • – 서비스 가격 책정, 사용량 측정, 과금 방안 • 􀂃유지 보수 45

46. 3.7 보안 • 보안의 필요성 보안 성능 가용성 기존 IT기기와 통합이 어렵다 커스터 마이징 능력이 충분하지 않음 On-demand로 인한 과다비용 발생 가능성 다른 곳으로 저장 하기 어려움 클라우드 관련 법적 규제 주요 제공업체수가 적음 80% 60% 20% 40% 46 46

47. 3.7 보안 • 보안위협 1) MalWare 공격 가상머신의 취약점을 이용하여 공격자가 권한을 획득하거나 기타 경로를 통해 임의의 악성코드가 실행되는 경우, 악성코드는 가상머신의 상호 커뮤니케이션 과정에서 다른 사용자의 영역에 악성코드를 감염 시킬 수 있다. APP APP APP APP 2차감염 Guest OS Guest OS Guest OS 1차감염 Virtualization Layer Host OS Hardware CPU Memory NIC Disk 악성코드 감염 경로 47

48. 3.7 보안 • 보안위협 2) 정보 유출 가상머신의 취약점을 이용하여 허가되지 않은 권한을 획득한 경우에는 물리적 디스크에 대한 접근이 가능하고 이로 인한 정보 유출이 가능해진다. 3) 서비스 거부 하나의 가상머신에서 자원을 남용하거나 또는 가상머신에서 실행되는 프로그램이 가상머신 계층을 통과하여 Host의 권한을 획득하여 악의적인 행위를 하는 경우에는 Host 또는 다른 가상 머신에 서비스 거부가 발생할 수 있다. 4) 가상머신 인증 가상환경에서는 가상머신이 인증되지 않은 자에 의해 변경됨으로써 보안 위협이 발생되기도 한다. 악의적인 목적을 가진 공격자 또는 사용자가 가상머신을 실행하여 임의로 설정을 변경하고 권한을 획득하는 경우가 해당된다. 48

49. 3.7 보안 • 보안위협 5) 하이퍼바이저 보안 • 하이퍼바이저는 가상화를 가능하게 하는 핵심 기술로서 Host 컴퓨터에서 다수의 운영체제가 • 동시에 실행되기 위한 가상 플랫폼을 의미한다. • 하이퍼바이저 보안은 현재 가상화 기술에서 가장 중요하게 제기되고 있는 보안 이슈로서 보안 • 전문가들은 하이퍼바이저의 취약점 노출로 인한 공격 발생을 우려하고 있다. • 하이퍼바이저가 위협에 노출될 경우 아래의 그림과 같이 가상머신 또한 그대로 위협에 노출되기 때문이다. Virtual Machine APP OS 보안위협 Hypervisor Hardware CPU Memory NIC Disk 악성코드 감염 경로 49

50. 3.7 보안 • 보안위협 가상인프라에서 보안 이슈 • 전통적 보안으로 가상 인프라 보호는 비용 및 복잡성을 증가 시킬 수 있다. 전통적인 보안 보완 사항 Network IPS 네트워크 경계에서 위협 및 공격만을 차단 네트워트 경계뿐만 아니라 VM간의 경계에도 위협으로 부터 보호되어야 함 Server Protection 에이전트의 관리 기능으로 단일 물리적 서버를 보호 물리적 서버에 시간과 비용을 투자하는 것과 같이 각각의 VM에서의 서버에도 필요 System Patching 개별 서버 또는 네트워크의 중요 취약점 패치 패치, 트래킹 그리고 VMs의 임의 사용을 통제 정책이 각 네트워크 세그먼트나 서버의 중요 어플리케이션에 국한 정책이 더욱 포괄적(웹, 데이터, OS영역, DB)등으로 적용되어야 하며 VMs과 함께 이동 되어야 함 Security Policies 50