developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

클라우드 서비스: 위험 완화, 가용성 유지보수

클라우드 서비스 보안 정책을 사용하여 클라우드 환경에서 고가용성 유지보수

Judith Myerson, 시스템 엔지니어 겸 아키텍트

Judith M. Myerson은 시스템 아키텍트이자 엔지니어다. 관심 분야는 미들웨어 기술, 엔터프라이즈 수준의 시스템, 데이터베이스 기술, 애플리케이션 개발, 네트워크 관리, 보안, RFID 기술, 프로젝트 관리 등이다.

요약： 비즈니스 및 정부 기관들은 지속적인 운영적 가용성을 보장하기 위해 더 나은 보안을 제공하는 클라우드 서비스를 요구합니다. 이를 실현하기 위해 위험 완화 면에서 클라우드 서비스 정책을 공식화해야 할 것입니다. 클라우드 서비스 보안과 클라우드 환경에서 높은 가동시간 가용성 및 보안을 보장하기 위해 클라우드 서비스로 위험을 완화하는 방법에 대해 학습합니다.

여기에 태그 달기!

기사 게재일： 2011 년 11 월 08 일
난이도： 중급
원문： 보기
PDF： A4 and Letter (38KB | 11 pages)Get Adobe® Reader®
페이지뷰： 953 회
의견：

클라우드 서비스 보안 정책은 참조하고 있는 전달 모델 구성에 따라 클라우드 보안의 다른 측면에 집중한다. — 즉, 이는 다음과 같은 SaaS, PaaS 또는 IaaS이다.

SaaS(Software as a Service) 정책은 이용자들이 사적인 개인, 비즈니스 또는 정부 기관인지 여부에 관계없이 이용자에게 임대한 특정 애플리케이션에 액세스를 관리하는 것에 주목한다. 이는 악성 인스턴스 자원을 할당하는 맬웨어 애플리케이션의 공격에 취약한 SaaS 애플리케이션의 위험을 완화하는 것을 처리해야 한다. 예를 들어, 권한이 부여된 치과 보조원이 치과 기록을 다운로드하도록 애플리케이션이 허용한 지정된 사무실 영업 시간이 해커의 편의를 위해 이른 아침 시간으로 악성으로 변경될 수 있다.
PaaS(Platform as a Service) 정책은 데이터를 보호하는 것에 주목할 뿐만 아니라 독립 소프트웨어 벤더, 신설 또는 대기업 단위로 작성되고 호스트되는 전체 비즈니스 라이프 사이클에서 애플리케이션에 액세스를 관리하는 것에 주목한다. 해당 정책은 가령 치과 기록을 망치기 위해 맬웨어 애플리케이션을 설치할 때 사용하는 봇네트(botnet)의 직접적인 운영에 Command and Control 센터로 사용되는 PaaS의 위험을 완화해야 한다.
IaaS(Infrastructure as a Service) 정책은 가상 머신을 관리하는 것에 집중할 뿐만 아니라 데이터를 보호하고 클라우드 환경에서 가상 머신을 내재한 기존 컴퓨팅 자원의 인프라로 액세스를 관리하는 것에 주목한다. 이러한 정책은 가상 머신으로 위험을 완화하는 면에서 거버넌스 프레임워크를 처리해야 한다. IaaS는 가상 머신 내 그리고 이에 걸쳐서 인프라의 악성 업데이트에서 사용하기 위해 봇네트(botnet)의 직접적인 운영에 Command and Control 센터로 사용되었다.

이 기사에서는 클라우드 서비스 보안 문제의 중요한 측면을 간략하게 다룬 다음에 위험 평가 프로그램의 일부가 되는 위험 완화에 대해 설명한다.

클라우드 서비스 보안

클라우드 서비스 보안은 다음으로 위협받을 수 있다.

결함이 있는 하이퍼바이저
누락한 임계값 정책
비대해진 로드 밸런싱
안전하지 않은 암호화

각 항목을 더 자세히 살펴보자.

결함이 있는 하이퍼바이저

모든 클라우드 서비스 유형은 단일 하드웨어 호스트를 공유하기 위해 여러 운영 체제를 허용하는 기본 하이퍼바이저 위에 가상 머신을 실행한다. 이는 사용자, 테넌트 및 클라우드 관리자와 같이 다른 신뢰 레벨 당사자가 액세스한다. 예를 들어, 테넌트는 서비스로서 특정 소프트웨어에 액세스하기 위해 1000명 사용자 라이센스 계약을 가질 수 있다.

하이퍼바이저가 결함이 있거나 위태롭게 되면, 모든 인스턴스 자원 및 데이터 요청 큐가 위태롭게 된다. 이는 워크로드의 수요가 급증하는 동안 인스턴스 자원 및 데이터 요청 큐의 소비를 모니터하는 데 사용되는 임계값 정책에 악성으로 영향을 줄 수 있다[자세히 읽기]. 가상 머신들 사이에 통신하는 데 사용되는 내부 가상 네트워크에서 제어는 보안 정책을 강제할 만큼 가시적이지 않다. 가상 머신의 네트워크 및 보안 제어에 대한 의무는 잘 분리되지 않을 수 있다.

해커는 관리 제어를 갖춘 높은 권한의 사용자가 되어 가상 머신을 벗어나 하이퍼바이저에서 악성 프로그램을 실행할 수 있다. 예를 들어, 디렉토리 파일에 액세스하여 다른 가상 머신으로 인스턴스 자원을 악성으로 다시 지정할 수 있다. 그리고, 동일한 가상 머신의 테넌트들 사이에서 평판, 라우팅, 메모리, 스토리지를 분리하는 메커니즘에 실패를 유발시킬 수 있다.

해커는 가상 머신 내에서 재할당된 인스턴스 자원으로부터 제거되지 않은 상주 데이터에서 민감한 정보를 훔칠 수 있다. 해커는 건전한 가상 머신의 이웃을 식별하고 이들의 활동을 모니터하기 위해 결함이 있는 하이퍼바이저를 사용할 수 있다. 또한 이웃의 가상 머신 내에 들어가서 PaaS 애플리케이션에 악성 코드를 추가할 수 있다.

누락한 임계값 정책

일반 사용자는 관계로 들어가기 전에 서비스 제공자의 보안 정책을 평가해야 한다. 클라우드 컴퓨팅의 보안 태도를 사내 구축형 환경과 비교해야 하고 클라우드에서 인스턴스 자원, 사용자 및 데이터 요청 임계값 정책이 보안 정책으로부터 누락되지 않도록 해야 한다.

자원 임계값 정책은 추가 인스턴스 자원이 워크로드의 요구가 급증하는 동안 어떻게 소모되는지를 모니터하는 데 유용하다. 사용자 임계값 정책은 얼마나 많은 사용자들이 동시에 클라우드 서비스에 로그인하고 로그오프하는지 확인하고 라이센스에 지정된 대로 최대 사용자 수에 접근하는지 여부를 확인한다.

이러한 정책을 수립하지 않으면 다음과 같은 위험이 있다.

자원 임계값 정책이 없으면 독자의 인스턴스 자원이 클라우드 서비스 제공자가 경고 없이 서비스를 종료하도록 야기하는 최대 용량에 악성으로 도달하는지 여부를 알지 못한다.
사용자 임계값 정책이 없으면 동시 사용자 수가 최대에 접근하는지 여부 그리고 얼마나 많은 사용자들이 클라우드 서비스를 마쳤을 때 로그 오프하지 않았는지 알지 못한다. 해커는 이러한 사용자를 식별할 수 있다.
데이터 요청 임계값 정책이 없으면 데이터 요청의 큐의 크기를 알지 못한다. 해커는 큐를 악성 데이터 요청(예: SQL 주입된 요청)으로 넘치게 할 수 있어, 이러한 큐가 최대 용량에 도달하게 된다.

비대해진 로드 밸런싱

로드 밸런싱은 인스턴스 자원과 데이터 요청을 분배하는 데 사용된다. 예를 들어, 각 인스턴스 자원은 용량의 최대 50퍼센트까지 로드되어야 하므로 하나의 인스턴스가 실패하면 건전한 인스턴스가 실패한 자원 인스턴스에서부터 비즈니스 트랜잭션을 인계한다.

각 큐는 큐 용량의 최대 50퍼센트까지 데이터 요청으로 로드되어야 하므로 하나의 큐가 실패하면 건전한 큐는 원래 실패한 큐를 위해 지정된 데이터 요청을 인계한다.

인스턴스 자원의 로드 밸런싱이 가상 머신에서 맬웨어 애플리케이션에 의해 악성으로 결함이 있을 때, 각 자원을 용량의 100퍼센트까지 채운 악성 트랜잭션으로 이러한 자원을 넘치게 할 수 있다.

실패한 자원 인스턴스에서 건전한 인스턴스로 비즈니스 트랜잭션을 이동하는 것은 불가능하다. 비대해진 로드 밸런싱은 인스턴스 자원 또는 로드 공유 중복성과 같은 장애 복구 메커니즘을 구현하는 데 사용될 수 없다.

안전하지 않은 암호화

일부 암호화의 형태는 데이터의 기밀성과 무결성을 보호하는 데 필요하다. 데이터가 민감하지 않거나 개인적이지 않더라도 클라우드로 그리고 클라우드에서부터 전송되고 클라우드에서 조작될 때 암호화로 안전해야 한다.

해커는 암호화 알고리즘을 불안전하게 렌더링하기 위해 암호 해독 또는 악성 인스턴스 자원 면에서 발전을 활용할 수 있다. 이들은 강력한 암호화를 약한 암호화로 변환하기 위해 이를 악성으로 수정하기 전에 암호화 알고리즘에서 결함을 탐색할 수 있다.

해커는 암호화 알고리즘의 최신 버전을 발견하여 더 나아갈 수 있고 그 다음에 자체 머신에서 알고리즘이 작동하는 방법을 배우기 위해 역엔지니어링을 수행할 수 있다.

위로

클라우드 서비스로 위험 완화하기

비용 효율적인 방식에서는 보안 제어를 적용하여 위험을 완화할 수 있으므로 자산의 취약성이 악용되어 구현 방식에 위협을 초래할 확률을 낮출 수 있다.

위험을 완화하려고 시도하기 전에 보호되는 자산을 식별해야 한다. 가장 간단한 위험 평가 접근방식은 다음을 목표로 한다.

자산 식별
위험 분석
보안 대책 적용
사후 실행 또는 사후 이벤트 평가 수행

기억할 핵심적인 개념은 나중에 추가되거나 인식하지 않은 변수를 통합하기 위해 어느 스테이지에서나 단계를 통해 루프백할 수 있다는 점이다.

자산 식별로 시작한다 — 하드웨어, 소프트웨어, 네트워크 컴포넌트, 인력, 사용자, 문서, 기능: 이와 함께 클라우드 서비스 유형의 직접적인 일부가 되는 다른 자산들. 이를 식별하고 위험을 완화하려고 시도하며 제외한 특정 자산을 발견할 때, 자산의 인벤토리를 업데이트하기 위해 항상 이 첫 단계로 돌아올 수 있고 그 다음에 두 번째 단계를 반복할 수 있다.

보안 대책을 분석하는 세 번째 단계 도중에 특정 위험이 처리되지 않았음을 발견한 경우 이를 포함하여 위협이 취약성을 악용하는 각 위험의 손실 잠재성 또는 확률을 판별하도록 두 번째 단계로 돌아갈 수 있다. 보호되는 자산의 인벤토리를 업데이트하기 위해 세 번째 단계에서 첫 번째 단계로 돌아갈 수 있다.

네 번째 단계에서 새로운 위험, 비용 효율적인 보안제어, 신흥 인프라 기술 및 새로운 법안의 영향을 받는 위험 평가 프로그램을 정기적으로 재평가한다.

각 항목을 더 자세히 살펴보자.

1단계. 자산 식별

클라우드 이용자와 제공자는 둘 다 하드웨어 및 소프트웨어 자산을 식별하고 각 자산을 대체하기 위한 비용을 예측해야 한다. 이들은 조직 재편성, 보다 더 에너지 효율적인 기술, 더 우수한 장애 복구 메커니즘 및 관할 경계에 걸쳐서 데이터 개인정보 보호정책의 전문가에 대한 새로운 법안의 결과로 변화할 수 있는 자산의 인벤토리를 유지보수하고 정기적으로 업데이트해야 한다.

SaaS 제공자로부터 서비스를 임대할 때 이용자가 식별해야 하는 하드웨어 및 소프트웨어 자산의 수는 PaaS 모델을 사용하여 이용자가 제어를 더 많이 보유할 때보다 훨씬 더 적고 IaaS를 사용할 때에는 더 커진다.

이제 각 클라우드 서비스 유형에 대해 어느 자산이 식별되어야 하는지를 살펴보자.

SaaS 자산
클라우드 이용자가 보유한 유일한 제어가 데스크탑, 노트북 또는 모바일 디바이스로부터 애플리케이션에 액세스하는 것이므로 식별해야 하는 자산은 모바일 디바이스 운영 체제, 애플리케이션 및 기본 프로그램이다. 이러한 이유로 SaaS로 사용하기 위해 프로그램 및 애플리케이션으로 디바이스 자산의 인벤토리를 제한하는 것이 중요하다. 개인적인 사용(예를 들어, 다운로드한 게임)을 위한 프로그램과 SaaS에 액세스하는 데 필요한 프로그램을 동일한 디바이스에서 혼합하는 것은 바람직한 생각이 아니다.

클라우드 제공자는 최소한 다음 자산들을 제어해야 한다.

운영 체제
하드웨어
네트워크 인프라
액세스 관리 애플리케이션
인스턴스 자원
SaaS 애플리케이션 업그레이드 및 패치

이용자가 이를 식별할 책임은 없다.

PaaS 자산
클라우드 이용자가 식별해야 하는 자산은 그가 제어할 수 있는 자산이다. 즉, 플랫폼의 전체 비즈니스 라이프사이클에서 모든 애플리케이션(예를 들어, 스프레드시트, 워드 프로세서, 백업, 청구, 급여 처리 및 송장 처리).

PaaS 설정 시 클라우드 제공자는 최소한 다음 자산들을 제어해야 한다.

운영 체제
하드웨어
네트워크 인프라
인스턴스 자원

클라우드 이용자가 이러한 자산을 식별할 책임은 없다.

IaaS 자산
클라우드 이용자가 식별해야 하는 자산은 그가 제어할 수 있는 자산이다. 즉, 이는 운영 체제, 네트워크 장비 및 가상 머신 레벨에서 배치된 애플리케이션이다. 이용자는 인스턴스 자원의 수 및 가상 서버 또는 스토리지 영역의 블록을 많거나 적게 규모 조정할 수 있다.

클라우드 이용자는 인프라와 내재된 컴포넌트를 제어할 수 없다. 제공자가 이러한 자산을 식별해야 한다.

2단계. 위험 분석

위험은 위협이 클라우드 서비스의 취약성을 악용할 것이라는 손실 잠재성 또는 확률이다. 비용 효율적인 대책이 준비되면, 클라우드 서비스가 악용되면 위협을 실행할 수 있는 취약성에 영향받기 쉽다.

자산에 위험의 손실 잠재성은 각 자산에 위험의 영향에 따라 다르다(다시 말해서, 사용자에게 항상 사용 가능한 문서 자산에 대해 없음 또는 제로에서 적절한 대책 없이 클라우드 환경에서 인스턴스 자원 자산에 대해 0.96의 높은 등급 사이). 자산에 위험의 손실 잠재성도 1년 시간 프레임 안에 얼마나 자주 위협이 발생할 수 있는 지에 따라 다르다.

취약성이 악용될 수 있는 방법
다음 취약성이 해커가 인스턴스 자원의 자산에 대해 공격을 실행하기 위해 어떻게 총괄적으로 악용될 수 있는지 간단한 예제를 살펴보자. 취약성은 다음과 같다.

애플리케이션으로부터 누락한 임계값 모듈
인스턴스 자원 내에 상주하는 데이터
가상화된 네트워크에서 충분하지 않은 네트워크 기반 제어
부적절한 권한을 갖춘 사용자 모니터링

훌륭한 애플리케이션은 태스크 또는 태스크 순서를 수행하기 위해 다른 애플리케이션과 상호작용하는 모듈로 나눠진다. 즉, 이렇게 하면 개발자가 기존 모듈을 재사용하거나 새로운 모듈을 추가하여 애플리케이션으로 모듈을 추가하기에 더 간편해진다. 애플리케이션이 임계값 모듈을 누락할 때 — 인스턴스 자원의 최대 용량 및 데이터 요청의 또다른 레벨 아래로 설정 — 이용자 및 제공자는 인스턴스 자원 또는 데이터 요청이 최대 용량에 도달했는지 여부를 알 수 없다. 이들은 해커가 건전한 가상 머신을 수용하는 동일한 실제 서버에서 악성 가상 머신을 작성했는지 여부를 너무 늦을 때까지(예를 들어, 서비스 공격의 거부가 발생한 후까지) 알지 못한다. 해커는 악성 인스턴스 자원 및 악성 데이터 요청 큐로 악성 가상 머신의 이웃을 넘치게 하여 이를 달성한다. 또한 실제 서버의 최대 용량에 도달할 때까지 공격 대상자가 가상 머신의 수를 늘리도록 유혹한다.

상주 데이터는 이전에 할당된 인스턴스 자원이 동일하거나 다른 사용자에게 다시 할당되기 전에 데이터가 완전히 제거되지 않을 때 발생한다. 인스턴스 자원은 메모리, 캐시, 프로세스, 세션, 임계값 및 스토리지 자원을 포함한다. 해커는 공격 대상자의 개인 정보를 얻기 위해 인스턴스 자원의 내부를 찾는다.

네트워크 레벨에서 작업하는 보안 제어가 IaaS 네트워크 인프라에서 작업할 수 없을 때 가상화된 네트워크에서 충분하지 않은 네트워크 기반 제어가 발생한다. 이는 인프라로 권한 부여된 관리자 액세스를 제한한다. 해커는 IaaS 관리자가 가상화된 네트워크에서 IP 기반 네트워크 영역 설정과 같은 표준 제어를 적용할 수 없다는 사실을 활용한다. IaaS 제공자는 호의적인 네트워크 스캔을 공격 활동과 구별하는 방법이 없기 때문에 네트워크 기반 취약성 스캐닝을 허용하지 않을 수 있다. 가상화된 네트워크에서부터 실제 네트워크에 트래픽을 구별하기 위한 제어도 충분하지 않다(예를 들어, 동일한 서버에서 하이퍼바이저 위에 두 개 이상의 가상 머신 사이에 통신).

적절하지 않은 권한을 가진 사용자 모니터링은 제공자가 관리 액세스 제어를 갖춘 권한이 있는 사용자로 위장하여 하이퍼바이저에서부터 가상 머신으로 액세스를 확보한 해커의 악성 활동을 부적절하게 모니터할 때 발생한다. 예를 들어, 이러한 액세스를 갖춘 해커는 해커가 무엇을 하는지 인식하는 제공자 없이 데이터 요청의 큐 및 악성 인스턴스 자원을 작성할 수 있다. 또 다른 예제는 건전한 인스턴스 자원의 인스턴스 자원을 악성 인스턴스 자원으로 하나의 가상 머신에서부터 다른 가상 머신에 악성 인스턴스 자원으로 다시 지정하는 것이다.

악용의 심각도 잠재성 순위
물론, 악용의 다른 유형의 자체 시스템 또는 손실 잠재성의 순위 지정을 개발해야 하지만, 필자는 다음 우선순위의 순서로 다양한 악용의 손실 잠재성을 순위 지정한다.

해커가 침입할 수 있는 방법
해커가 찾고 있는 것
해커가 보유한 도구

예를 들어, 해커는 관리 액세스 제어를 갖춘 권한이 있는 사용자로 위장하여 들어올 수 있고 합법적인 시스템 관리자가 처음에 인식하지 못한 악성 활동을 수행할 수 있다. 해커는 파일 이름을 찾기 위해 SQL 삽입을 전송하여 침입할 수 있고 이러한 파일에서 상주하는 데이터를 찾을 수 있다.

해커가 가상 머신 내에 있으면 호의적인 네트워크 스캔으로 위장하여 악성 네트워크 스캐닝 공격 활동을 실행하기 위해 해커의 도구를 사용할 수 있다. 공격 활동은 각 애플리케이션 내에서 모듈의 목록을 포함할 수 있다. 해커가 임계값 모듈을 포함하지 않은 이 애플리케이션을 발견하면, 최대 용량에 도달할 때까지 인스턴스 자원을 작성하기 위한 도구를 사용하거나 작성할 수 있다.

3단계. 보안 대책 적용

위험 평가에서 다음 단계는 개념상 상대적으로 간편하고, 다른 많은 것들과 마찬가지로 실전에서는 약간 더 어렵다 — 이는 위험을 완화하는 대책이 비용 효율적인지 발견하는 면에서 그렇다. 그러므로 이러한 이점은 대책을 구현하는 비용보다 더 크다. 위협이 취약성을 악용할 위험의 확률은 낮아지고 ROI는 개선된다.

이 다음 단계는 중요하다. 즉, 대책이 비용 효율적이지 않다는 것을 알게 되면 상주하는 위험이 유지되어 이러한 위험이 완화될 수 없다. 이러한 상황을 받아들이고 더 이상의 비용을 들이지 않도록 학습해야 한다. 이는 위험 평가/완화에서 채택할 가장 어려운 개념 중 하나이다. 즉, 이러한 일부 위험은 제공하는 이점에 대해 완화하기에 너무 비용이 많이 든다.

하지만, 상주 위험이 너무 많고 비용 효율적인 대책이 너무 적은 경우, 다음 몇 가지 이유로 위험 평가의 단계를 반복해야 한다.

이번이 위험 평가/완화에서 첫 시도 중 하나라면 자산 식별, 위험 분석 및 이해 그리고 잠재적 대책의 전체적인 폭과 깊이 및 적용할 수 있는 다양한 방법의 판별 면에서 기술을 정교하게 만들기 위한 연습을 몇 번 반복하려 할 수 있다.
또한 새로운 대책 및 들어가는 비용보다 더 많은 이점을 가져오는 클라우드 인프라 기술에 대해 주의를 놓치지 않으려고 한다.
또한, 대책을 구현하는 것보다 더 저렴한 경우 일부 상주 위험을 전송하기 위해 보험을 구입하는 것도 고려해야 한다.

필자가 이 기사에서 언급하는 일부 대책 예제는 다음을 포함한다.

인스턴스 자원, 사용 자 및 데이터 요청 임계값 정책이 준비되도록 보장하기.
다시 할당되기 전에 인스턴스 자원으로부터 상주 데이터 제거하기.
장애 복구 메커니즘, 비즈니스 연속성 및 재해 복구에 대한 계획을 구현하기.
권한을 갖춘 사용자 모니터링, 즉 이러한 사용자의 백그라운드 및 로깅 활동과 실제 모니터링 서버, 네트워크 및 인프라의 다른 컴포넌트의 상태 확인하기.
위험 완화 및 대책의 이점에 대해 이용자 및 제공자 교육하기.

4단계. 사후 평가 수행

위험 평가가 3년마다 정기적으로 수행되어야 하는 반면, 다음 조건이 발생하는 경우에 위험을 더 자주 재평가해야 할 수 있다.

소프트웨어, 하드웨어 및 네트워크 자산에 영향을 줄 수 있는 새로운 클라우드 서비스 기술이 나타난다.
새로운 취약성 및 새로운 위협이 부상한다.
이전에 상주로 분류되어 위험을 효율적으로 완화할 수 있는 새로운 대책이 사용 가능하게 된다.
새로운 위험 완화 접근방식이 구상된다.
모든 분류에서 자산에 대한 조직적 변경(예: 인수)의 결과로 나타난 주요 영향.
관할에 걸친 법률 및 준수 규제 주요 변경.

실제로 독자가 조직의 클라우드 서비스에 대해 위험 평가 및 완화를 처리할 책임이 있는 경우, 약 일주일에 한 번씩 이러한 조건에 대한 정보는 인포스트림을 반드시 확인해야 한다. 새로운 위협과 취약성에 대한 뉴스피드를 설정하는 것을 고려하자.

위로

결론

클라우드 서비스로 위험을 완화하는 동시에 높은 가동 시간 가용성을 유지보수하는 것은 각 클라우드 유형에 대해 어느 자산을 식별하는지, 분석할 위험이 무엇인지, 어느 대책이 비용 효율적인지 그리고 위험이 완화된 이후에 평가해야 하는 것이 무엇인지에 대한 문제를 해결하기 위해 사전 예방적인 위험 계획이 필요하다. 개발자, 사용자 및 비즈니스 분석가의 팀이 클라우드 서비스로 상주 위험을 줄이기 위해 함께 협력해야 한다. 이러한 팀은 클라우드 서비스로 위험을 완화하는 작업을 훨씬 더 간편하게 만드는 문제 해결을 찾을 것이다.

참고자료

교육