INTEROPERABILITY AND PORTABILITY
Gaining the benefits of more elastic environment requires both interoperability and portability to be the design goals of any cloud-implemented system, from IaaS through to SaaS.
At one end of the scale, Interoperability and Portability allows you to scale a service across multiple disparate providers on a global scale and have that system operate and appear as one system.
At the other end, Interoperability and Portability allows the easy movement of data and applications from one platform to another, or from one service provider to another.
Portability and interoperability are not considerations unique to cloud environments and their related security aspects are not new concepts brought about by cloud computing.
However, the open and often shared processing environments that exist within the cloud bring a need for even greater precautions than are required for traditional processing models.
Multi-tenancy means data and applications reside with data and applications of other companies and that access to confidential data (intended or unintended) is possible through shared platforms, shared storage, and shared networks.
6.1 An Introduction to Interoperability
Interoperability is the requirement for the components of a cloud eco-system to work together to achieve their intended result.
In a cloud computing eco-system the components may well come from different sources, both cloud and traditional, public and private cloud implementations (known as hybrid-cloud).
Interoperability mandates that those components should be replaceable by new or different components from different providers and continue to work, as should the exchange of data between systems.
Businesses, over time, will make decisions that lead to the desire to change providers.
Reasons for this desired change include:
(A) An unacceptable increase in cost at contract renewal time
(B) The ability to get the same service at a cheaper price
(C) A provider ceases business operations
(D) A provider suddenly closes one or more services being used without acceptable migration plans
(E) Unacceptable decrease in service quality, such as a failure to meet key performance requirements or achieve service level agreements (SLA’s)
(F) A business dispute between cloud customer and provider
** A lack of interoperability (and also portability) can lead to being locked to a particular cloud service provider.
The degree to which interoperability can be achieved or maintained when considering a cloud project often will depend on the degree to which a cloud provider uses open, or published, architectures and standard protocols and standard API’s.
Though many vendors of “open” and “standards based” cloud provision provide propriety hooks and extensions (e.g. Eucalyptus) and enhancements that can impede both interoperability and portability.
6.2 An Introduction to Portability
Portability defines the ease of ability to which application components are moved and reused elsewhere regardless of provider, platform, OS, infrastructure, location, storage, the format of data, or API’s.
Portability and interoperability must be considered whether the cloud migration is to public, private, or hybrid cloud deployment solutions.
They are important elements to consider for service model selection regardless of whether a migration strategy is to Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS).
Portability is a key aspect to consider when selecting cloud providers since it can both help prevent vendor lock-in and deliver business benefits by allowing identical cloud deployments to occur in different cloud provider solutions, either for the purposes of disaster recovery or for the global deployment of a distributed single solution.
Achieving portability for a cloud service is generally reliant on the two services operating in the same architectural octant of the Cloud Cube, as defined in Domain One. Where services operate in different octants, then porting a service usually means migrating the service back “in-house” before re-outsourcing it to an alternative cloud service.
Failure to appropriately address portability and interoperability in a cloud migration may result in failure to achieve the desired benefits of moving to the cloud and can result in costly problems or project delays due to factors that should be avoided such as:
(A) Application, vendor, or provider lock-in – choice of a particular cloud solution may restrict the ability to move to another cloud offering or to another vendor
(B) Processing incompatibility and conflicts causing disruption of service – provider, platform, or application differences may expose incompatibilities that cause applications to malfunction within a different cloud infrastructure
(C) Unexpected application re-engineering or business process change – moving to a new cloud provider can introduce a need to rework how a process functions or require coding changes to retain original behaviors
(D) Costly data migration or data conversion — lack of interoperable and portable formats may lead to unplanned data changes when moving to a new provider
(E) Retraining or retooling new application or management software
(F) Loss of data or application security – different security policy or control, key management or data protection between providers may open undiscovered security gaps when moving to a new provider or platform
Moving services to the cloud is a form of outsourcing; the golden rule of outsourcing is “understand up-front and plan for how to exit the contract”. Portability (and to an extent interoperability) should therefore be a key criterion of any organizations strategy to move into cloud services, allowing for a viable exit strategy to be developed.
6.3 Recommendations
6.3.1 Interoperability Recommendations
Hardware – Physical Computer Hardware
The hardware will inevitably vary or change over time and from provider to provider leaving unavoidable interoperability gaps if direct hardware access is required.
(A) Whenever possible, use virtualization to remove many hardware level concerns, remembering that virtualization doesn’t necessarily remove all hardware concerns, especially on current systems.
(B) If hardware must be directly addressed, it is important to ensure that the same or better physical and administrative security controls exist when moving from one provider to another.
Physical Network Devices
The network devices including security devices will be different from service providers to service providers along with its API and configuration process.
(A) To maintain interoperability the Network physical hardware and network & security abstraction should be in virtual domain. As far as possible API’s should have the same functionally.
Virtualization
While virtualization can help to remove concerns about physical hardware, distinct differences exist between common hypervisors (such as ZEN, VMware and others).
(A) Using open virtualization formats such as OVF to help ensure interoperability.
(B) Document and understand which specific virtualization hooks are used no matter the format. It still may not work on another hypervisor.
Frameworks
Different platform providers offer different cloud application frameworks and differences do exist between them that affect interoperability.
(A) Investigate the API’s to determine where differences lie and plan for any changes necessary that may be required to application processing when moving to a new provider.
(B) Use open and published API’s to ensure the broadest support for interoperability between components and to facilitate migrating applications and data should changing a service provider become necessary.
(C) Applications in the cloud often interoperate over the Internet and outages can be anticipated to occur. Determine how failure in one component (or a slow response) will impact others and avoid stateful dependencies that may risk system data integrity when a remote component fails.
Storage
Storage requirements will vary for different types of data.
Structured data will most often require a database system, or require application specific formats.
Unstructured data will typically follow any of a number of common application formats used by Word Processors, Spreadsheets and Presentation Managers.
Here the concern should be to move data stored with one service to another seamlessly.
(A) Store unstructured data in an established portable format.
(B) Assess the need for encryption for the data in transit.
(C) Check for compatible database systems and assess conversion requirements if needed.
Security
Data and applications in the cloud reside on systems the user doesn’t own and likely has only limited control over.
A number of important items to consider for interoperable security include:
(A) Use SAML or WS-Security for authentication so the controls can be interoperable with other standards-based systems.
(B) Encrypting data before it is placed into the cloud will ensure that it cannot be accessed inappropriately within cloud environments.
(C) When encryption keys are in use, investigate how and where keys are stored to ensure access to existing encrypted data is retained.
(D) Understand your responsibilities and liabilities should a compromise occur due to unanticipated “gaps” in protection methods offered by your service provider.
(D) Log file information should be handled with the same level of security as all other data moving to the cloud. Ensure that log files are interoperable to ensure continuity of log analysis pre-and post move as well as compatibility with whatever log management system is in use.
(E) When completing a move ensure that all data, logs, and other information is deleted from the original system.
6.3.2 Portability Recommendations
Portability considerations and recommendations that impact moving to the cloud include :
(A) Service Level : SLA’s will differ across providers, and there is a need to understand how this may affect your ability to change providers.
(B) Different architectures : Systems in the cloud may reside on disparate platform architectures.
It is important to be aware of how these will limit portability by understanding service and platform dependencies, which may include API’s, hypervisors, application logic, and other restrictions.
(C) Security integration : Cloud systems introduce unique portability concerns for maintaining security, including:
- Authentication and identity mechanisms for user or process access to systems now must operate across all components of a cloud system.
- Using open standards for Identity such as SAML will help to ensure portability.
- Developing internal IAM system to support SAML assertions and internal system to accept SAML will aid future portability of system to the cloud.
- Encryption keys should be escrowed locally, and when possible maintained locally
- Metadata is an aspect of digital information that is often and easily overlooked as (typically) metadata is not directly visible when working with files and documents.
- Metadata becomes an important consideration in the cloud, because metadata moves with the document. When moving files and their metadata to new cloud environments ensure copies of file metadata are securely removed to prevent this information from remaining behind and opening a possible opportunity for compromise.
(B) Different architectures : Systems in the cloud may reside on disparate platform architectures.
It is important to be aware of how these will limit portability by understanding service and platform dependencies, which may include API’s, hypervisors, application logic, and other restrictions.
(C) Security integration : Cloud systems introduce unique portability concerns for maintaining security, including:
- Authentication and identity mechanisms for user or process access to systems now must operate across all components of a cloud system.
- Using open standards for Identity such as SAML will help to ensure portability.
- Developing internal IAM system to support SAML assertions and internal system to accept SAML will aid future portability of system to the cloud.
- Encryption keys should be escrowed locally, and when possible maintained locally
- Metadata is an aspect of digital information that is often and easily overlooked as (typically) metadata is not directly visible when working with files and documents.
- Metadata becomes an important consideration in the cloud, because metadata moves with the document. When moving files and their metadata to new cloud environments ensure copies of file metadata are securely removed to prevent this information from remaining behind and opening a possible opportunity for compromise.
6.3.3 Recommendations for Different Cloud Models
There are a number of generic risks and recommendations that are common to all cloud models.
(I) When substituting cloud providers it is normal to expect resistance from the legacy cloud provider. This must be planned for in the contractual process as outlined in Domain 3, in your Business Continuity Program as outlined in Domain 7, and as a part of your overall governance in Domain 2.
(II) Understand the size of data sets hosted at a cloud provider. The sheer size of data may cause an interruption of service during a transition, or a longer transition period than anticipated. Many customers have found that using a courier to ship hard drives is faster than electronic transmission for large data sets.
(III) Document the security architecture and configuration of individual component security controls so they can be used to support internal audits, as well as to facilitate migration to new providers and aid the validation of the new environment.
Infrastructure as a Service (IaaS)
Where the responsibility of the cloud provider is to provide basic computing utilities such as storage, computing power, etc., the cloud customer is responsible for a majority of application design tasks related to interoperability.
The cloud provider should provide standardized hardware and computing resources that can interact with various disparate systems with minimal efforts.
The cloud provider should strictly adhere to industry standards to maintain interoperability. The provider should be able to support complex scenarios such as cloud brokerage, cloud bursting, hybrid clouds, multi- cloud federation, etc.
The cloud provider should provide standardized hardware and computing resources that can interact with various disparate systems with minimal efforts.
The cloud provider should strictly adhere to industry standards to maintain interoperability. The provider should be able to support complex scenarios such as cloud brokerage, cloud bursting, hybrid clouds, multi- cloud federation, etc.
(A) Understand how virtual machine images can be captured and ported to new cloud providers and who may use different virtualization technologies.
Example: Distributed Management Task Force (DMTF) Open Virtualization format (OVF).
(B) Identify and eliminate (or at least document) any provider-specific extensions to the virtual machine environment.
Example: Distributed Management Task Force (DMTF) Open Virtualization format (OVF).
(B) Identify and eliminate (or at least document) any provider-specific extensions to the virtual machine environment.
(C) Understand what practices are in place to make sure appropriate de-provisioning of VM images occurs after an application is ported from the cloud provider.
(D) Understand the practices used for decommissioning of disks and storage devices.
(E) Understand hardware/platform based dependencies that need to be identified before migration of the application/data.
(D) Understand the practices used for decommissioning of disks and storage devices.
(E) Understand hardware/platform based dependencies that need to be identified before migration of the application/data.
(F) Ask for access to system logs, traces, and access and billing records from the legacy cloud provider.
(G) Identify options to resume or extend service with the legacy cloud provider in part or in whole if new service proves to be inferior.
(H) Determine if there are any management-level functions, interfaces, or API’s being used that are incompatible with or unimplemented by the new provider.
(I) Understand costs involved for moving data to and from a cloud provider
(J) Determine what means are supported for moving data as efficiently to the cloud as possible through using standard capabilities such as data compression.
(K) Understand what security is provided and who maintains access to encryption keys.
(H) Determine if there are any management-level functions, interfaces, or API’s being used that are incompatible with or unimplemented by the new provider.
(I) Understand costs involved for moving data to and from a cloud provider
(J) Determine what means are supported for moving data as efficiently to the cloud as possible through using standard capabilities such as data compression.
(K) Understand what security is provided and who maintains access to encryption keys.
Platform as a Service (PaaS)
The cloud provider is responsible to provide a platform on which the consumers can build their systems. They provide with a runtime environment and an integrated application stack.
It allows developers to quickly develop and deploy custom applications on the offered platforms without the need to build the infrastructure.
The cloud provider provides the entire infrastructure and its maintenance to its consumers.
(A) When possible, use platform components with a standard syntax, open API’s, and open standards,
e.g. Open Cloud Computing Interface (OCCI)
(B) Understand what tools are available for secure data transfer, backup, and restore.
(C) Understand and document application components and modules specific to the PaaS provider and develop application architecture with layers of abstraction to minimize direct access to proprietary modules.
(D) Understand how base services like monitoring, logging, and auditing would transfer over to a new vendor.
(E) Understand what protections are provided for data placed into the cloud and data generated and maintained in the cloud.
(F) Understand control functions provided by the legacy cloud provider and how they would translate to the new provider.
(G) When migrating to a new platform, understand the impacts on performance and availability of the application and how these impacts will be measured.
o Understand how testing will be completed prior to and after migration to verify that the services or applications are operating correctly. Ensure that both provider and user responsibilities for testing are well known and documented.
The cloud provider provides the entire infrastructure and its maintenance to its consumers.
(A) When possible, use platform components with a standard syntax, open API’s, and open standards,
e.g. Open Cloud Computing Interface (OCCI)
(B) Understand what tools are available for secure data transfer, backup, and restore.
(C) Understand and document application components and modules specific to the PaaS provider and develop application architecture with layers of abstraction to minimize direct access to proprietary modules.
(D) Understand how base services like monitoring, logging, and auditing would transfer over to a new vendor.
(E) Understand what protections are provided for data placed into the cloud and data generated and maintained in the cloud.
(F) Understand control functions provided by the legacy cloud provider and how they would translate to the new provider.
(G) When migrating to a new platform, understand the impacts on performance and availability of the application and how these impacts will be measured.
o Understand how testing will be completed prior to and after migration to verify that the services or applications are operating correctly. Ensure that both provider and user responsibilities for testing are well known and documented.
Software as a Service (SaaS)
The cloud provider provides application capabilities over the cloud, and the client just manages his/her operations and the information flowing in and out of the system.
The client needs a browser, and majority of the administrative at all the levels rests with the provider.
(A) Perform regular data extractions and backups to a format that is usable without the SaaS provider.
(B) Understand whether metadata can be preserved and migrated.
(C) If needed use data escrow services.
(D) Understand that any custom tools will have to be redeveloped, or the new vendor must provide those tools, or commit to port (and support) these tools.
(E) Review and audit to ensure the consistency of control effectiveness across old and new providers.
The cloud provider provides application capabilities over the cloud, and the client just manages his/her operations and the information flowing in and out of the system.
The client needs a browser, and majority of the administrative at all the levels rests with the provider.
(A) Perform regular data extractions and backups to a format that is usable without the SaaS provider.
(B) Understand whether metadata can be preserved and migrated.
(C) If needed use data escrow services.
(D) Understand that any custom tools will have to be redeveloped, or the new vendor must provide those tools, or commit to port (and support) these tools.
(E) Review and audit to ensure the consistency of control effectiveness across old and new providers.
(F) Ensure backups and other copies of logs, access records, and any other pertinent information which may be required for legal and compliance reasons can be migrated.
(G) Understand the management, monitoring, and reporting interfaces and their integration between environments.
(H) Test and evaluate all applications before migration, and dual run if feasible prior to cut-over.
Private Cloud
Private cloud is when the consumer runs a cloud environment / service within their enterprise or uses private cloud offering from the cloud providers (typically extending the internal network into a service providers hosting centre).
(A) Ensure interoperability exists between common hypervisors such as KVM, VMware, Xen.
(B) Ensure standard API’s are used for management functions such as users and their privilege management, VM image management, Virtual Machine management, Virtual Network management, Service management, Storage management, Infrastructure management, Information Management, etc.
Public Cloud
Interoperability in public cloud means exposing most common cloud interfaces. They may be vendor specific or open specifications and interfaces such as OCCI, libcloud, etc.
(A) Ensure that the cloud providers expose common and/or open interfaces to access all cloud functions in their service offering.
Hybrid Cloud
In this scenario the consumer’s local private infrastructure should have the capability to work with external cloud providers.
A common scenario is “cloud bursting”, where an enterprise shares the load with external cloud providers to meet peak demands.
(A) Ensure that the cloud providers expose common and/or open interfaces to access all cloud functions in their service offering.
(B) Ensure the ability to federate with different cloud providers to enable higher levels of scalability.
---=== || END ||===----
No comments:
Post a Comment