클라우드 컴퓨팅 번역(영어 원본)AN EDITORIAL NOTE ON RISK
Throughout this Guidance we make extensive recommendations on reducing your risk when adopting cloud computing, but not all the recommendations are necessary or even realistic for all cloud deployments. As we compiled information from the different working groups during the editorial process, we quickly realized there simply wasn’t enough space to provide fully nuanced recommendations for all possible risk scenarios. Just as a critical application might be too important to move to a public cloud provider, there might be little or no reason to apply extensive security controls to low-value data migrating to cloud-based storage.
With so many different cloud deployment options — including the SPI service models (SPI refers to Software as a Service, Platform as a Service, or Infrastructure as a Service, explained in depth in Domain 1); public vs. private deployments, internal vs. external hosting, and various hybrid permutations — no list of security controls can cover all circumstances. As with any security area, organizations should adopt a risk-based approach to moving to the cloud and selecting security options. The following is a simple framework to help evaluate initial cloud risks and inform security decisions.
This process is not a full risk assessment framework, nor a methodology for determining all your security requirements. It’s a quick method for evaluating your tolerance for moving an asset to various cloud computing models.
Identify the Asset for the Cloud Deployment
At the simplest, assets supported by the cloud fall into two general categories:
1. Data
2. Applications/Functions/Processes
We are either moving information into the cloud, or transactions/processing (from partial functions all the way up to full applications).
With cloud computing our data and applications don’t need to reside in the same location, and we can choose to shift only parts of functions to the cloud. For example, we can host our application and data in our own data center, while still outsourcing a portion of its functionality to the cloud through a Platform as a Service.
The first step in evaluating risk for the cloud is to determine exactly what data or function is being considered for the cloud. This should include potential uses of the asset once it moves to the cloud to account for scope creep. Data and transaction volumes are often higher than expected.
Evaluate the Asset
The next step is to determine how important the data or function is to the organization. You don’t need to perform a detailed valuation exercise unless your organization has a process for that, but you do need at least a rough assessment of how sensitive an asset is, and how important an application/function/process is.
For each asset, ask the following questions:
1. How would we be harmed if the asset became widely public and widely distributed?
2. How would we be harmed if an employee of our cloud provider accessed the asset?
3. How would we be harmed if the process or function were manipulated by an outsider?
4. How would we be harmed if the process or function failed to provide expected results?
5. How would we be harmed if the information/data were unexpectedly changed?
6. How would we be harmed if the asset were unavailable for a period of time?
Essentially we are assessing confidentiality, integrity, and availability requirements for the asset; and how the risk changes if all or part of the asset is handled in the cloud. It’s very similar to assessing a potential outsourcing project, except that with cloud computing we have a wider array of deployment options, including internal models.
Map the Asset to Potential Cloud Deployment Models
Now we should have an understanding of the asset’s importance. Our next step is to determine which deployment models we are comfortable with. Before we start looking at potential providers, we should know if we can accept the risks implicit to the various deployment models: private, public, community, or hybrid; and hosting scenarios: internal, external, or combined.
For the asset, determine if you are willing to accept the following options:
1. Public.
2. Private, internal/on-premises.
3. Private, external (including dedicated or shared infrastructure).
4. Community; taking into account the hosting location, potential service provider, and identification of other community members.
5. Hybrid. To effectively evaluate a potential hybrid deployment, you must have in mind at least a rough architecture of where components, functions, and data will reside.
At this stage you should have a good idea of your comfort level for transitioning to the cloud, and which deployment models and locations fit your security and risk requirements. |
클라우드 컴퓨팅 번역(한국어 번역본)위험성에 관한 편집자 노트
본 지침에서 우리는 클라우드 컴퓨팅 채택 시 위험성을 감소시킬 수 있는 권고안을 폭넓게 제시하지만 권고안 전체가 모든 클라우드 배치에 필수적이거나 현실적인 것은 아니다. 우리는 편집을 하는 동안 다양한 비즈니스 그룹들로부터 정보를 수집했기 때문에 있을 수 있는 모든 위험성 시나리오와 관련해 권고안을 완벽하게 제시하기란 공간이 충분하지 않음을 깨달았다. 중요한 어플리케이션을 공용 클라우드 공급자에게로 이동시키는 것이 무엇보다 중요한 만큼 클라우드 기반 저장소로 옮기려는 저가 데이터에 광범위한 보안 통제를 적용할 이유는 거의 없을 것이다.
클라우드 배치 옵션 – SPI 서비스 모델 (SPI란 도메인 1에서 심도 깊게 설명된 서비스형 소프트웨어나 서비스형 플랫폼 또는 서비스형 인프라를 말한다); 공용 대 사설 배치, 내부 대 외부 호스팅, 다양한 하이브리드 치환을 포함해 – 은 대단히 다양하기 때문에 보안 통제 목록으로 모든 상황을 다루기란 불가능하다. 보안 영역에 따라 조직은 위험성 기반 접근법을 채택해 보안 옵션을 선택하고 클라우드로 이동시킬 것이다. 다음은 초기 클라우드 위험성을 평가하고 보안 결정을 통지하는데 도움이 되는 간단한 프레임워크이다.
이러한 과정은 완전한 위험성 평가 프레임워크가 아니며, 모든 보안 요건을 결정할 수 있는 방법도 아니다. 이는 다양한 클라우드 컴퓨팅 모델로 자산을 옮길 경우 감내도(tolerance)를 신속하게 평가할 수 있는 방법이다.
클라우드 배치를 위한 자산 확인
클라우드에 의해 지원되는 자산은 간단하게 두 개의 일반적인 범주로 분류될 수 있다.
1. 데이터
2. 어플리케이션/기능/프로세스
우리는 클라우드로 정보를 옮기거나 트랜잭션/프로세싱하고 있다 (부분적 기능에서 완전한 어플리케이션까지).
클라우드 컴퓨팅을 이용하면 자료와 어플리케이션이 같은 위치에 있을 필요가 없으며, 기능의 일부만을 클라우드로 이동시키기로 할 수도 있다. 예를 들어, 서비스형 플랫폼을 통해 클라우드로 기능성의 일부를 아웃소싱하면서 동시에 자신의 데이터 센터에서도 자신의 어플리케이션과 데이터를 호스트할 수 있다.
클라우드에 대한 위험성을 평가하는 첫 번째 단계는 클라우드와 관련해 고려하고 있는 데이터나 기능이 무엇인지 정확하게 결정하는 것이다. 이는 범위 크립을 밝히기 위해 클라우드로 이동되므로 여기에는 자산의 잠재적인 이용이 포함된다. 데이터와 트랜잭션 볼륨은 대개 예상하는 것보다 높다.
자산 평가
다음 단계는 데이터나 기능이 조직에 얼마나 중요한 것인지를 결정하는 것이다. 조직에 평가를 위한 프로세스가 없다면 상세한 평가 활동을 실시하지 않아도 되지만, 적어도 자산이 얼마나 민감한 것인지 그리고 어플리케이션/기능/프로세스가 얼마나 중요한지는 대략적으로 평가하여야 한다.
각각의 자산에 대해 다음의 질문들을 한다.
1. 자산이 광범위하게 공개되고 광범위하게 배포되었다면, 우리에게 해가 되었겠는가?
2. 클라우드 공급자의 직원이 자산에 접근했었다면, 우리에게 해가 되었겠는가?
3. 프로세스나 기능이 외부인에 의해 조작되었다면, 우리에게 해가 되었겠는가?
4. 프로세스나 기능이 예상 결과를 산출하지 못했다면, 우리에게 해가 되었겠는가?
5. 정보/데이터가 예상치 못하게 변경되었다면, 우리에게 해가 되었겠는가?
6. 얼마의 기간 동안 자산을 이용할 수 없었다면, 우리에게 해가 되었겠는가?
본질적으로 우리는 자산에 대한 기밀성, 보전성, 이용 가능성 요건과 자산의 일체 또는 일부를 클라우드에서 취급하는 경우, 위험성이 어떻게 변하는지를 평가하고 있다. 이는 내부 모델을 포함해 클라우드 컴퓨팅으로 배치 옵션을 광범위하게 배열할 수 있는 경우를 제외하고 잠재적인 아웃소싱 프로젝트와 매우 유사하다.
잠재적 클라우드 배치 모델까지 자산 맵 작성
이제 우리는 자산의 중요성을 알게 되었다. 다음 단계는 어떤 배치 모델이 편리한지를 결정하는 것이다. 잠재적 공급자를 조사하기 전에 사설, 공용, 커뮤니티, 하이브리드, 호스팅 시나리오, 내부, 외부 또는 혼합 등 다양한 배치 모델에 내재해 있는 위험성을 허용할 수 있는지 알아야 한다.
자산에 대해 다음의 옵션들을 용인할 지 결정한다.
1. 공용
2. 사설, 내부/사내
3. 사설, 외부 (전용 인프라 또는 공유 인프라 포함)
4. 커뮤니티; 호스팅 위치, 잠재적 서비스 공급자, 기타 커뮤니티 성원의 신원 확인을 고려
5. 하이브리드. 잠재적 하이브리드 배치를 효과적으로 평가하려면 최소한 구성 요소, 기능, 데이터가 있게 될 위치의 대략적인 아키텍처를 염두에 두고 있어야 한다.
이 단계에서 클라우드 이행을 위한 안심 수준과 어떤 배치 모델과 위치가 보안 및 위험성 요건에 적합한지를 생각해 두어야 한다. |
