This document presents the NIST Federated Cloud Reference Architecture model. This actor/role based model used the guiding principles of the NIST Cloud Computing Reference Architecture to develop an 11 component model which are described individually and how they function as an ensemble. There are many possible deployments and governance options which lend themselves to create a suite of federation options from simple to complex. The basics of cloud federation can be described through the interactions of the actors in a layered three planes representation of trust, security, and resource sharing and usage. A discussion on possible future standards and use cases are also described in great detail.
Regional cloud providers that operate data centers and associated wide-area networking across their region are well positioned to cooperatively build a global cloud infrastructure with other regional cloud providers, and thus, become a valuable party for Content and Application Providers (CPs and APs). We call the formalization of such cooperation a federated cloud. In a federated cloud, application and/or content requests placed to a cloud provider can be served locally -- e.g., by a supporting cloud provider, even when this supporting cloud provider only has an indirect relationship to the AP or CP by way of a primary cloud provider. In this case, a primary cloud provider is defined as the cloud provider with which an AP or CP has a direct contractual arrangement for cloud services. A federated cloud member simultaneously acts as a primary cloud provider and a supporting cloud provider as defined by their relationship with different APs and CPs.
In a federated cloud, part or all of each individual provider's compute, storage, and networking resources become part of a federated pool of cloud resources. Management systems of these individual (regional) cloud providers are linked to facilitate end-to-end cloud services capability. By definition, a federated cloud includes a clearing house to settle expenditures and revenues of the end-to-end cloud services based on agreed methods, interfaces, and procedures for settlement.
The concept of a Federated Cloud comprised of interconnected Service Providers (SP) was introduced in ATIS Standard ATIS-0200003, CDN Interconnection Use Case Specifications and High Level Requirements [https://global.ihs.com/doc_detail.cfm?&csf=ASA&input_doc_number=%20&inpu.... This initial standard described the role of the SPs in the cloud as distributors of content from Content Providers (CP) to End Users (EU). Thus, SPs serve as Content Distribution Network (CDN) Providers. The set of content delivery Life Cycle interactions between two CDN Providers is defined in ATIS-0200003. The method for content distribution in ATIS-0200003 was limited to Unicast Cache-based distribution.
Under certain conditions depending on network configurations and type of content, it may be advantageous to distribute content via Multicast methods. From a network perspective, Multicast is scalable and results in significant savings in efficiencies and capacity utilization.
The purpose of this ATIS Standard is to introduce Multicast-based content distribution. This standard provides the following:
Overview of the Multicast delivery mechanism
Set of content types that are suitable for delivery via Multicast methods
Description of various Multicast methods that can be deployed to interconnect two CDN Providers and distribute content.
The scope of this Standard is limited to use cases and requirements to support the interactions between two CDN Providers for content distribution via Multicast. The Use Cases describe:
Generic interactions supporting Life Cycle Multicast use between two CDN Providers.
Specific Multicast configurations/scenarios that can be deployed for interconnection and content distribution.
Multicast related specifics to support Billing, Provisioning, Reporting, and other network functions will be covered in future ATIS documents. Multicast-based content delivery to mobility-based End User devices is for further study.
The ATIS Cloud Services Forum is examining a number of services that establish the foundation for development, operations, deployment, and management of cloud-based services. These include content delivery, telepresence, and virtual desktop. Video services, including the already-present one-way and growing two-way communications, will be a substantial catalyst for additional growth and expansion of the Internet. Telepresence services provide a business model and architectural model that are foundational to cloud services, and provide important elements of the Cloud Services Data Model for Cloud Service Enablers. This specification focuses on telepresence services, recognizing that telepresence services are an integral part of a broader unified communications solution set.
There are many aspects of the telepresence service. This is an evolving document establishing a foundation for continuing work efforts. The specification explores a provider-agnostic and product-agnostic implementation, and will consider two primary aspects of the telepresence service that are detailed here by the examination of use cases deployed today and those resulting in the application of "the cloud" and other aspects of business and technology architecture guiding service evolution in the future. First, a description of the telepresence service is provided. Second, a more detailed description of the two key aspects of the telepresence service is provided. Topics 2f and 2g detail aspects of telepresence interconnectivity which will be addressed in a future specification.
With the emergence of Cloud Services spanning one or many cloud infrastructures managed by various providers, it is imperative that a checklist be developed that provides cloud services lifecycle guidance/requirements for service providers/developers as they integrate these lifecycle functions.
The goal driven checklist is to be developed with the purpose to facilitate the following six lifecycle functions from a cloud service provider. These lifecycle functions can be aggregated in the three categories of build, capture, and modify to facilitate a simpler description of the goals.
Assessment and acceptance (i.e., build) of services onto the cloud platform/infrastructure.
Ongoing audit (i.e., capture) of services on the cloud platform/infrastructure.
Augmentation, abridging, and annulment (i.e., modify) of services within the cloud platform/infrastructure.
The goal of the checklist is to realize greater efficiencies through formalization and automation of integrations between cloud service providers and their corollary actors during the cloud services lifecycle. While the focus in this document is on the cloud services lifecycle, note that the unique goal oriented approach and related paradigms described herein could also be applied elsewhere.
ATIS Standard ATIS-0200003 [https://global.ihs.com/doc_detail.cfm?&csf=ASA&input_doc_number=%20&inpu... provided initial use cases and requirements for Content Distribution Network (CDN) Interconnection between two CDN providers via Cache-based Unicast delivery method – software download was the selected content type to drive these initial use cases and requirements. ATIS Standard ATIS-0200004 [https://global.ihs.com/doc_detail.cfm?&csf=ASA&input_doc_number=%20&inpu... developed use cases and requirements for content distribution via Multicast-based delivery.
In a multi-party Federated environment (multiple Service Providers (SP) acting as CDN Providers), CDN interconnections require additional functionality from service providers beyond the straightforward interconnection of IP transport networks. The interconnection and federation of CDN Providers is expected to evolve through a series of content distribution services. These services can be provided by a variety of different mechanisms including:
Cache-based http unicast.
Multicast.
Publish subscribe mechanisms (e.g., RSS or named-data information-centric content routing).
Content aggregation (e.g., from machine-machine interconnection).
The selection of the delivery method depends on the nature and type of content that is being requested for delivery1
Thus, the purpose of this ATIS Standard is to extend the use cases and requirements developed in ATIS- 020000] and ATIS-0200004 for an environment involving multiple CDN providers joining together to form a CDN Federation with multiple available methods of content delivery. The interconnection life cycle use cases and requirements are re-examined for the impact arising from a Federation of multiple CDN providers. Additional emphasis is placed on the interconnection domain functionality such that guidance on the eventual development of Network-Network Interconnect (NNI) architectures and supporting protocol requirements can be derived.
Accordingly, the scope of this document includes the following:
Multiple SPs forming a CDN Federation for the purpose of distributing content from Content Providers (CP) to End Users (EU) that individually request the content delivery. The multi-party Federation is strictly limited to a fully meshed structure where each SP/CDN Provider directly engages with other SPs/CDN Providers for the purpose of content distribution. Other structures are excluded from consideration in this document. Examples of alternate and/or add-on structures include the presence of a third party broker/exchange as well as the role of SPs who are not Federation members but who have independent agreements for assisting in content delivery with individual Federation members (see section 5). These alternate/add-on structures are for further study.
Life cycle interactions are re-examined from the perspective of a Multi-Party Federation environment (see section 6)
The delivery methods are restricted to cache/unicast (section 7) and multicast methods (section 8). All content types that can be delivered by these methods are in scope.
Logical functionality associated with interconnection domains between pairs of CDN Providers are examined in detail (section 9). Appropriate requirements are derived in support of these functions.
Finally it should be noted that the protocol development work supporting all CDN-I functionality is being developed in the IETF. Appendix A provides a brief summary of this work. 1An infinite length stream, for example, might be best suited to multicast delivery. Files of various sizes may be suitable for cache-based delivery. Finally, small content units may be appropriate for aggregation and delivery service.
The Cloud Security Alliance Cloud Controls Matrix (CCM) is specifically designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider. The CSA CCM provides a controls framework that gives detailed understanding of security concepts and principles that are aligned to the Cloud Security Alliance guidance in 13 domains. The foundations of the Cloud Security Alliance Controls Matrix rest on its customized relationship to other industry-accepted security standards, regulations, and controls frameworks such as the ISO 27001/27002, ISACA COBIT, PCI, NIST, Jericho Forum and NERC CIP and will augment or provide internal control direction for service organization control reports attestations provided by cloud providers.
The Cloud Trust Protocol (CTP) is designed to be a mechanism by which cloud service customers can ask for and receive information related to the security of the services they use in the cloud, promoting transparency and trust.
The CTP document focuses on the definition of the CTP Data Model and Application Programming Interface (API), including:
The format of CTP messages exchanged between cloud service customers and providers.
The modelling of concepts such as “security attributes”, “objectives”, “measurement results” and “triggers” in machine readable format.
The means to define the scope of the service to which CTP monitoring queries apply.
However, the document does not provide a specification of the “security attributes” (and associated metrics) that are queried by CTP. Such a specification will be provided by the Cloud Security Alliance in a separate document, and will likely be influenced by upcoming standards such as [ISO_19086]. CTP also offers implementers the choice to define and adopt their own set of security attributes and related metrics. This document is organised as follows.
Section 2 provides some key terms and definitions that are used throughout this document, borrowing from relevant key standards.
Section 3 offers a general introductory overview of CTP.
Section 4 describes the CTP data model, defining the main concepts that are used to represent security information related to cloud services in CTP.
Section 5 specifies the RESTful CTP API that implements the model described in section 4. It also specifies the CTPScript language used in “triggers” and “objectives” and describes when they should be evaluated.
Section 6 provides requirements and recommendations for securing the CTP API.
The goal of CloudAudit is to provide a common interface and namespace that allows cloud computing providers to automate the Audit, Assertion, Assessment, and Assurance (A6) of their infrastructure (IaaS), platform (PaaS), and application (SaaS) environments and allow authorized consumers of their services to do likewise via an open, extensible and secure interface and methodology. CloudAudit provides the technical foundation to enable transparency and trust in private and public cloud systems.
Privacy Level Agreement - Version 2 is intended to be used as an appendix to a Cloud Services Agreement, and to describe the level of privacy protection that the CSP will provide. While Service Level Agreements (“SLA”) are generally used to provide metrics and other information on the performance of the services, PLAs will address information privacy and personal data protection practices.
The PLA [V2] is based only on EU personal data protection mandatory legal requirements. Coherently, the Working Group has stripped away elements derived from best practices and recommendations from the PLA [V1] (see further the ‘Methodology’ section of the standards document), and further clarifies core mandatory legal requirements.
The NIST Cloud Computing Security Working group was created to achieve broad collaboration between Federal and private stakeholders in efforts to address the security-related concerns expressed by Federal managers. One of the tasks of the NIST Cloud Computing Working Group is to design a Cloud Computing Security Reference Architecture that supplements SP 500-292: NIST Cloud Computing Reference Architecture (RA) with a formal model and identifies the core set of Security Components recommended for building a successful and secure cloud computing Ecosystem. The document provides for an understanding of the security interdependencies of cloud services, Actors, and requirements that USG agency technical planning and implementation teams and agency procurement offices should identify and address in order to acquire cloud services with security levels that meets agency needs. Under development
(The group seems to be dormant after 2013)
The adoption of cloud computing into the US Government (USG) and its implementation depend upon a variety of technical and non-technical factors. A fundamental reference point, based on the NIST definition of Cloud Computing, is needed to describe an overall framework that can be used government- wide. This document presents the NIST Cloud Computing Reference Architecture (RA) and Taxonomy (Tax) that will accurately communicate the components and offerings of cloud computing. The guiding principles used to create the RA were 1) develop a vendor-neutral architecture that is consistent with the NIST definition and 2) develop a solution that does not stifle innovation by defining a prescribed technical solution. This solution will create a level playing field for industry to discuss and compare their cloud offerings with the US Government (USG). The resulting reference architecture and taxonomy for cloud computing was developed as an Actor/Role based model that lays out the central elements of cloud computing for Federal CIOs, Procurement Officials and IT Program Managers. The cloudscape is open and diversified and the accompanying taxonomy provides a means to describe it in an unambiguous manner. The RA is presented in two parts: a complete overview of the actors and their roles and the necessary architectural components for managing and providing cloud services such as service deployment, service orchestration, cloud service management, security and privacy. The Taxonomy is presented in its own section and appendices are dedicated to terms and definitions and examples of cloud services.
The Overview of the Reference Architecture describes five major actors with their roles & responsibilities using the newly developed Cloud Computing Taxonomy. The five major participating actors are the Cloud Consumer, Cloud Provider, Cloud Broker, Cloud Auditor and Cloud Carrier. These core individuals have key roles in the realm of cloud computing. For example, a Cloud Consumer is an individual or organization that acquires and uses cloud products and services. The purveyor of products and services is the Cloud Provider. Because of the possible service offerings (Software, Platform or Infrastructure) allowed for by the cloud provider, there will be a shift in the level of responsibilities for some aspects of the scope of control, security and configuration. The Cloud Broker acts as the intermediate between consumer and provider and will help consumers through the complexity of cloud service offerings and may also create value-added cloud services as well. The Cloud Auditor provides a valuable inherent function for the government by conducting the independent performance and security monitoring of cloud services. The Cloud Carrier is the organization who has the responsibility of transferring the data akin to the power distributor for the electric grid.
The Architectural Components of the Reference Architecture describes the important aspects of service deployment and service orchestration. The overall service management of the cloud is acknowledged as an important element in the scheme of the architecture. Business Support mechanisms are in place to recognize customer management issues like contracts, accounting and pricing and are vital to cloud computing. A discussion on Provisioning and Configuration points out the requirements for cloud systems to be available as needed, metered and have proper SLA management in place. Portability and Interoperability issues for data, systems and services are crucial factors facing consumers in adopting the cloud are also undertaken here. Consumers need confidence in moving their data and services across multiple cloud environments.
As a major architectural component of the cloud, Security and Privacy concerns need to be addressed and there needs to be a level of confidence and trust in order to create an atmosphere of acceptance in the cloud‟s ability to provide a trustworthy and reliable system. Security responsibilities, security consideration for different cloud service models and deployment models are also discussed.
