Cloud Security Refrence model

There are a plethora of different reference architectures, models and frameworks for Cloud Computing. Which one should an organization adopt? Of course there’s no straightforward answer to that question and in this research note we provide guidance on how to organize some of the best ideas that are emerging in a practical structure that should stand the test of time.

Reference ‘Things’

A Reference Architecture (RA) “should” provide a blueprint or template architecture that can be reused by others wishing to adopt a similar solution. A Reference Model (RM) should explain the concepts and relationships that underlie the RA. At Everware-CBDI we then use the term Reference Framework (RF) as a container for both. Reference architectures, models and frameworks help to make sense of Cloud Computing.

Unfortunately, such formality is absent from the various reference architectures, models and frameworks that have been published for Cloud Computing; these frequently mix elements of architecture and model, and then apply one of the terms seemingly at random.

In developing the CBDI-Service Architecture and Engineering Reference Framework (SAE) in support of SOA (Service Oriented Architecture) Everware-CBDI separated out various parts as shown in figure 1. We developed a detailed RA for SOA and a RM for SOA, with particular emphasis on a rich and detailed Meta Model for SOA and a Maturity Model for SOA. We also developed a detailed process and task decomposition for SOA activities.

But the RF is easily generalized, as shown in figure 1, where the various elements could be applied to any domain, and explicit references for example to “SOA Meta Model” or “SOA Standards” etc., can be removed.

Figure 1 – Generalized Reference Framework

The benefit of this approach is that elements of the framework can then be mapped to each other in different ways to support alternative perspectives such as different usage or adoption scenarios, or the viewpoint of an individual participant or organization.  Whereas most of the Cloud Computing Reference architectures, models and frameworks proposed today apply to a single perspective.

Current Cloud Computing Reference Architecture, Models and Frameworks

As discussed there are many frameworks and models to choose from. It is not our intention to detail and critique them all individually. Credit must go to  NIST who have already done much of that in their 2010 Survey of Cloud Architecture Reference Models.

We may classify Cloud reference models as one of two styles, either

• Role-Based. Where activities or capabilities are mapped to roles such as cloud provider or consumer. For example,
  1. DMTF Cloud Service Reference Architecture
  2. IBM Cloud Computing Reference Architecture (which has been submitted to the Open Group)
  3. NIST Cloud Computing Reference Architecture
• Layer-based. Where activities or capabilities are mapped to layers in an architecture such as application or resource layers or to the service management architecture or security architecture
  • Cloud Security Alliance Reference Model is one of many layered models showing the cloud ‘stack’
  • CISCO Cloud Reference Architecture Framework is an architecture of architecture, placing Cloud on top of layers of Service, Security and Technology architectures
  • IEFT Cloud Reference Framework goes into more depth, showing the capabilities for each layer.

Analysis of the these shows that they typically contain,

• Roles – that  would be better placed in the Organization section of an RF
• Activities – which would be part of the Process Model
• Layered Architecture – which would be part in the Reference Architecture

Used this way, the generalized RF in figure 1 becomes a useful tool to analyze proposed Cloud Computing Reference architectures, models and frameworks in terms of understanding better what they actually contain, and a basis for development of an enterprise specific framework.

Everware-CBDI recommend that is more useful to model the capabilities required for Cloud Computing rather than to list them all as activities - as that may imply processes and tasks which is not always the case. Across the industry capability modeling is rapidly becoming the de facto standard approach to business design, and it seems highly appropriate to use the technique in planning Cloud frameworks. Using this technique capabilities are separated from the processes that use them and from roles that possess them, and consequently mapped in different ways to show different scenarios. The capability model would be in the RM section of the RF and should be used extensively in disciplines such as roadmap planning, process improvement, technology planning, service management etc.  

A useful source of capabilities is provided by the Cloud Computing Reference Model/Architecture in The Role of Enterprise Architecture in Federal Cloud Computing published by the American Council for Technology.

Figure 2 takes the various elements from these different architectures, models and framework and places them into a generic RF. The intention here is not to reinvent the wheel, but consolidate the elements contained across the different reference architectures, models and frameworks for Cloud Computing into a unified framework.

Figure 2 - Cloud Computing Elements Placed in Generic Reference Frameworks

Elements highlighted in green are usually covered by existing Cloud Computing reference architectures, models and frameworks. These focus primarily on the operational state of the life cycle, and the implementation and deployment architectures.

Mapping

Once the various elements have been placed into their appropriate part of the RF, then you can start mapping them to suit different scenarios. For example activities in the process decomposition can be mapped against roles – either organizational roles or people roles - perhaps using RAEW, as shown in Table 1.

RAEW	Consumer	Provider	Broker	Auditor	Carrier
Consume
Provide
Manage
Enable

Table 1 – Mapping Process Activities to Roles

At a high level, table 1 may appear a bit obvious, but at a more detailed level it helps to understand where and by whom these activities will be performed in your organization, or how it might differ in specific scenarios from the proposed reference architectures mentioned so far.

In some scenarios it may be required that the cloud consumer performs certain cloud management activities not just the provider.  Whilst the cloud provider may be required to provide the necessary management capabilities, both the consumer and provider perform management activities.

Hence mapping capabilities to role in table 2 is another useful exercise, understanding who provides and who uses various capabilities. Whilst the NIST, IBM and other reference architectures do show this, as mentioned earlier their view is focused primarily on the operational state, and on the mapping of capabilities required in the operational infrastructure. As table 2 shows the span of responsibility and capability is very much wider than the operational perspective!

Capability Streams	Consumer	Provider	Broker	Auditor	Carrier
Architecture
Framework and Process
Lifecycle Infrastructure
Operational Infrastructure
Organization
Projects and Programs
Management

Table 2 – Mapping Capabilities to Roles

For more detail check the link that i have used that is  http://everware-cbdi.com/ccrfam

for some more detail refer to NIST link http://bigdatawg.nist.gov/_uploadfiles/M0007_v1_3376532289.pdf and http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/Meeting1AReferenceArchitecture011011/NIST_CCRATWG_004_ExistentReferenceModels_010311.pdf