Private Cloud Security Considerations Guide–Introduction and Overview
The purpose of this document is to provide you with design considerations and architectural view for designing effective 
security within a private cloud environment.
Table of Contents (this article)
2 Introduction to Private Cloud Security
3 Private Cloud Security Domain
Authors:
Yuri Diogenes - Microsoft
Tom Shinder - Microsoft
Anthony Stevens – Content Master
Reviewers (for the updated version):
Clint Rousseau – Microsoft
Avery Spates – Microsoft
Jeremy Girven – Microsoft
Jim Dial—Microsoft
Fernando Cima – Microsoft
Frank Koch – Microsoft Corporation
Scott Culp – Microsoft Corporation
Allen Brokken – Microsoft Corporation
The Private Cloud Security v-team, Microsoft Corporation
This article is part of the Private Cloud Security Considerations Guide. The intent behind this article is to provide a web-based resource for the same information that is contained in the Private Cloud Security Considerations Guide downloadable Word document. The following sections from the downloadable Word document are available for reading online:
- Private Cloud Security Considerations Guide – Introduction and Overview
- Private Cloud Security Considerations Guide – Security Design Considerations
- Private Cloud Security Considerations Guide – Private Cloud Security Challenges
1.0 Introduction
Cloud computing is no longer a promise that will change the way companies operate and leverage IT resources, it is now adopted by a great number of business, both large and small. According to Hosting and Cloud Go Mainstream: 2014, a Microsoft Corp.-commissioned study conducted by 451 Research LLC. The new study showed that more than 45 percent of organizations surveyed are beyond the pilot phase, and 32 percent now possess a formal cloud computing plan as part of their overall IT and business strategy.
These businesses already embraced cloud computing and are ready to make the most of their IT budgets in order to maximize return of investment. Cloud computing can assist companies to resolve some of the major challenges that they face, such as cost, flexibility and accessibility. As mentioned in this business article from Microsoft, the top five benefits of cloud computing are the following ones:
- Lower capital expenditure
- Easier maintenance and upgrades
- Greater flexibility and mobility
- Continuity of business
- Improved IT Security
Although these are decision factors around cloud computing adoption and Public Cloud adoption is growing in North America and Western Europe, the choice for Private Cloud is still the preference in emerging markets, according to Gartner (2013). With increasing numbers of organizations looking to create cloud-based environments or to implement cloud technologies within their existing data centers, business and technology decision-makers are looking closely at the possibilities and practicalities that these changes involve. Although the increase in business agility coupled with greater flexibility of service provisioning are convincing arguments in favor of moving to the private and hybrid cloud models, significant deployment blockers remain.
By using the private cloud delivery model, companies can retain the governance and hosting of corporate data in trusted environments while transitioning those environments to use the five essentials characteristics of cloud computing defined by the United States National Institute of Standards and Technology (NIST). Private cloud computing can provide both reduced costs and increased robustness.
To be successful, enterprises must consider security from the starting point of the private cloud designing process. At the same time, it is essential to address data sovereignty, or regulatory compliance demands. Security becomes an essential aspect of the planning and architecture phases.
1.1 Document audience
The primary audience for this document is the system architect or system designer who is interested in understanding the security implications that need to be considered before implementing a Private Cloud infrastructure. Others that might be interested in this document include IT implementers and enterprise security specialists.
1.2 Document purpose
The purpose of this document is to provide you with design considerations and an architectural view for designing effective security within a private cloud environment. This document does not cover security considerations for Public Cloud services, such as Microsoft Azure, Office 365, Dynamics CRM Online or offering from other vendors.
Although public cloud services are not covered, the services mentioned above participate in the Cloud Security Alliance (CSA) STAR Registry program, which allows customers to compare the compliance posture of participating cloud services. In order to participate, Microsoft must be in accordance with the CSA Cloud Controls Matrix (CCM), which outlines fundamental security principles to guide cloud vendors and to assist prospective customers in assessing the overall security risk of a cloud provider.
Detailed papers that discuss how our services fulfill the security, privacy, compliance, and risk management requirements defined in the CCM are published in the CSA’s Security Trust and Assurance Registry (STAR). For more information about Microsoft approach to cloud transparency, read this paper.
Note:
You can download the latest version of the Cloud Controls Matrix from CSA here.
2.0 Introduction to Private Cloud Security
Implementing a private cloud environment requires IT departments to re-evaluate many aspects of how they interact with their organization. A noticeable trend has been for business units to circumvent IT departments and source services direct from an external hosted provider. Hence, IT departments are increasingly considering themselves as a separate business unit whose job is to provide reliable IT services to the organization. In consequence, IT departments find themselves in competition with public cloud providers and are therefore considering hosting private clouds to complete against these public offerings.
This change in the relationship between IT department and host organization has often been hindered by the inability to account for the cost of the services that the IT department provides. In fact, many organizations struggle to implement proper cost accounting for their IT services. Private cloud computing provides the ability to allocate costs in a fair and metered manner to the service user in proportion to the user’s demand for those services. Knowing exactly which services are being used, what IT is costing, and where to allocate the costs brings considerable business benefits.
Private cloud implementations also affect the way in which IT departments should view security. Security should not be viewed as a discrete silo that contains traditional capabilities such as authentication, authorization, auditing, and so on. Instead, security should be considered as a wrapper around every element of a computing environment. Migrating to private cloud gives organizations the opportunity to redesign their security to this integrated arrangement.
3.0 Private Cloud Security Problem Domain
The following problems or challenges are typically the ones encountered by companies trying to address security concerns regarding private cloud:
- Ensure that data partitioning for tenants is in place for data hosted in the private cloud.
- Authenticate and authorize access to resources according to user’s rights to access those resources.
- Secure provision of resources for tenants.
- Provide Perception of unlimited resources while preserving availability and integrity of the private cloud infrastructure.
- Enable users to secure access private cloud resources from anywhere.
3.1 Conceptual Design
To solve the problems previously identified and assist organizations to design a secure model for their private cloud we encourage to follow the private cloud security model showed in the figure below:
This security model shows that to approach any part of the cloud environment is to have security as the foundation for the entire strategy. Additionally, all communication between layers in the cloud model (for example, between infrastructure, storage, networking and virtualization layers) must also have security as the foundation.
Security also applies with intra-layer communications, for example between in-memory processes and associated storage. Multi-tenancy security must also provide secure isolation between tenants within a database, Virtual Machine or application instance. In summary, security is a universal factor that applies to every element of cloud operations. Designers, implementers, and operators must consider security factors in every interaction for each physical or logical component of the cloud environment.
Security Architect’s Alert:
Not all capabilities in this security foundation will apply to each component of the security model. For example, intrusion detection is unlikely to be applied between the management stack and the infrastructure as a service layer. The model merely serves to highlight the all-pervasive nature of security and to emphasize the level at which you should include security.
This requirement for pervasive security results from changing organizational perspectives around the delivery of IT services. Increasingly, IT departments are breaking out from the traditional firewalled datacenter approach and having to act as one of many possible service providers that host the organization’s IT services. Business units no longer have to contract with the internal provider and often source these services from external providers, such as public cloud vendors and internal IT departments must recognize this change.
3.2 Design Principles
In a traditional data center environment, the demarcation of security responsibilities between the data center operator and the service user was relatively well defined. Generally, the responsibility was aligned with ownership of the physical component, whether that was a server, a networking device or the overall network infrastructure; if the IT department owned and administered the server, then that department also managed and updated security on that asset.
For the private cloud, the key security principle that drives an effective design is that your design should seek to build a system of controls, rather than a collection of controls. This unified system of controls is more than just the individual security technologies and methodologies – each part integrates with each other to provide an overall defense.
This unified security approach would include the following design principles:
- Apply generic security best practices
- Understand that isolation is key
- Consider security as a the foundation for the entire solution
- Assume attackers are authenticated and authorized
- Assume all data locations are accessible
- Use established strong cryptographic technologies
- Automate security operations
- Reduce attack surface
- Restrict intra-application communication
- Audit extensively
- Implement effective governance, risk management and compliance
- Create data classification zones
3.2.1 Apply Generic Security Best Practices
Private clouds use existing technologies such as virtualization and extend the infrastructure designs current in many organizations. As such, you should maintain existing security practices as part of the security design for your private cloud.
For example, you should continue to:
- Keep IT infrastructure systems in a secure and controlled location.
- Implement the principles of least privilege and defense in depth.
- Use firewalls and use separate NICs for management functions.
- Carry out penetration testing and to audit your security processes.
- Segment and provide access controls on the network using network firewalls
However, private cloud architectures introduce new potential vulnerabilities and you must modify and add to your existing design to mitigate these new threats.
3.2.2 Isolation is Key
Typically, private cloud implementations use virtualization technologies to make infrastructure, platform, and software resources available to clients within the enterprise. Tenants may be other business units within the enterprise, or other sections of the IT department using private cloud resources to deliver services to client business units. Even though private cloud tenants are part of the same organization, you must ensure isolation of their resources.
For example, confidential human resources data must not be generally accessible even though the human resources systems could be running on the same physical server as the company intranet.
Security Alert:
This is not just an issue of confidentiality. In the IaaS, PaaS, and SaaS service delivery models, you may not know which tenant services are co-hosted on the same physical devices at any particular time. In consequence, a problem in one tenant service could affect the performance, network connectivity, or network availability of other tenant services on the same physical hardware. Your design must ensure isolation between tenants in both the physical and virtual environments that make up the private cloud.
If your private cloud is partially or wholly hosted by a third party, then you must be assured that the cloud infrastructure used by the third party also guarantees isolation, both between your services and between your services and any other organization's services that the third party also hosts.
Private Cloud isolation should separate access to all cloud services including:
- Service Catalog – contains VMs, application templates, service offerings and automation scripts
- Service Catalog Library – the physical location of source files, software library and virtual disks
- Tenant compute – access to compute resources controlled by capacity, type or location controlled using templates
- Tenant Storage – access to storage resources controlled by capacity, data type, or location controlled using templates
- Tenant networking – access to networks controlled by network purpose, and classification
- Backup and recovery – access to backed up resources and data controlled through automation
3.2.3 Consider Security as the Foundation for your Design Decisions
You should consider security as the foundation for all elements of your private cloud architecture. The private cloud security model in the figure above shows how security concerns are relevant to all elements in all layers and stacks within the architecture:
- Infrastructure
- Platform
- Software
- Service delivery
- Management
A private cloud typically hosts services in virtualized environments, with multiple services co-located on the same physical device. The security foundation functions must be applied to both the physical and virtual environments because in a private cloud architecture you cannot assume that by protecting the physical environment you automatically protect the virtual 
environment, and vice versa.
If an attacker gains access to the physical infrastructure, they can disrupt not only the infrastructure, but also potentially gain access to the virtualized resources hosted in the cloud. If attackers manage to compromise a virtualized environment, they can potentially use the compromised environment as a platform to attack other virtualized environments within the cloud or to attack the infrastructure.
Although your design should consider security as the foundation around all elements in the architecture, your design should take into account the possibility that responsibility for security may be split between the CSP and the tenants. Considering security as the foundation for your design decision should be part of your defense in depth strategy for securing your private cloud.
3.2.4 Assume Attackers are Authenticated and Authorized
In the private cloud, you may delegate some of the responsibility for managing the security of the environment to the tenant. A tenant may provision resources through a self-service portal in order to run its tenant application or service in the private cloud. The cloud service provider may have little or no control over how the tenant configures and uses its virtual resources and this includes control over how the tenant grants access to its services to its end users.
Because of this, you must assume that attackers can be authenticated users with authorized access to a virtual machine running in your data center. The attacker could be an untrustworthy employee, someone using stolen credentials, or an attacker using elevated credentials.
Security Alert:
You should consider this route of attack from within a virtual machine in your data center in addition to more traditional attacks that may be mounted from outside your organization in an attempt to exploit weaknesses in your external defenses. Attackers will now attempt to find weaknesses that they can exploit in the virtual environment.
For example, an attacker might try to gain access to the hypervisor from within the hosted virtual machine, a type of exploit known as hyper-jacking.
3.2.5 Assume All Data Locations are Accessible
This point closely relates to the previous point about authenticated and authorized attackers. In private cloud architectures, many data locations are exposed as services. For example, virtual machines may mount virtual hard disks from a storage resource, or they may use virtual queues, virtual tables, or virtual binary large object (BLOB) storage. A tenant may provision these resources through an automated self-service portal as part of the infrastructure or platform services provisioning process. If an attacker can gain access to a tenant's virtual environment, you must assume that they may also gain access to the tenant's data locations.
Because of this, you should consider when and how to encrypt data and how to store and manage the encryption keys that enable access to the data stored in the cloud. The exposure of multiple data location make creating and protecting data classification zones an important design consideration.
3.2.6 Do Not Trust Client Information
You cannot make any assumptions about the security of any of the client applications that access the tenant services hosted in the private cloud. This proviso is especially important when the tenant wants to enable broad network access to the tenant service from multiple device types and from multiple locations. Poorly designed client applications could accidently reveal credentials or keys, and may perform limited validation on the data that they send to the services hosted in the cloud. Therefore, cloud management services and tenant services must perform their own validation of data sent from all client applications.
In contrast, you have more control over the client applications and tools that you use to manage the cloud infrastructure. For example, you may limit access to cloud management functions to client applications running on the corporate intranet, or use certificates to identify client applications. However, some cloud management operations may require calls to published APIs, which themselves may not require full validation of the data sent to the cloud and could be invoked from a custom application created by a developer.
3.2.7 Use Established Strong Cryptographic Techniques
Encryption of data at rest, in transit, and during processing can help to ensure that the data is only visible to those who should be able to see it. Therefore using encryption can help to preserve the isolation of tenants' resources and help to mitigate the threat that attackers may be authenticated users with access to the locations where the application or service stores its data.
Security Architect’s Punch List:
You should ensure that your infrastructure uses established, strong encryption techniques wherever it uses encryption. Tenants should also be encouraged or mandated to use established, strong encryption techniques in their own cloud-hosted applications and services.
Implementing cryptographic algorithms securely is complex and difficult. Using strong, established cryptographic algorithms and cryptographic systems rather than "rolling your own" helps to validate your approach to encryption, and makes your cryptographic processes auditable. Remember that attackers will only bother attacking the algorithm itself if they recognize it as weak – typically, they go after the keys.
3.2.8 Automate Security Operations
The size of private clouds, self-service provisioning, and virtualization all combine to make it essential to automate operational activities such as collecting and correlating monitoring data, responding to security related incidents, and allocating resources to tenants to prevent denial of service situations.
A typical private cloud hosts a large number of tenant services and supports a large number of end users. To ensure effective and timely responses to security issues, you must automate those responses as far as possible.
Automated security responses rely on monitoring, so your design must include monitoring services that enable you to automatically identify and act on possible security issues. The automated response procedures must send notifications to the staff that are responsible for security and create a full audit trail of their actions. You should evaluate and review these procedures regularly.
Security Alert:
When configuring security monitoring, you must also not let yourself be swamped by security responses and turn off monitoring altogether. Better to build up a feel for what is important by enabling rules more slowly. When you have a baseline and an understanding for your environment, you can then add the automation.
If you are building your virtualization host and guest environments from standard templates or images, you should ensure that those templates and images include configuration of the monitoring on which your automated responses will rely. This also applies to service catalogue, which also include catalogues for:
- Templates
- Applications
- Databases
- Automation
Your private cloud design should include a comprehensive automation platform that will enable operational activities such as those outlined above. You should also ensure that the security monitoring and response automation can cope with cloud-based environments and with virtual machines that can be rapidly provisioned and deprovisioned.
3.2.9 Reduce Attack Surface
As with all computer systems, reducing the attack surface is a key element to preventing attacks from succeeding. If the attacker only has a very small area to attempt to access, then he or she has far fewer options to find a successful exploit.
Within a private cloud environment where you are likely to be using virtualization, you must ensure that you reduce attack surface wherever possible on both host and guest computers. You should only enable the ports, services, and features that are essential to your operations. Your risk assessment should identify all unnecessary components and you should then remove or disable these components.
For Hypervisors, it is recommended to run the minimum features necessary for virtualization only. The hypervisor should be the only feature on the OS or networking (MPIO, SAN) software should be installed. The default installation for the hypervisor role should be without a GUI, which also helps to reduce the operating system footprint.
Security Operators Punch List:
For companies using Microsoft Windows Server Hyper-V, the installation or use of anti-malware in the management operating system is not recommended, for more information see Hardening the Hyper-V host.
3.2.10 Restrict Intra-Application Communications
Anytime data transitions though the private cloud, it adds another possible place that an attacker might be able to access or tamper with that data. Your private cloud design should limit the number of nodes that data must pass through to reach its destination as a part of the overall design goal to reduce the attack surface.
Learn by example:
For example, if a tenant is deploying a three-tier application to the private cloud, they should be able to configure the application so that the individual tiers can communicate directly with each other without the data passing through a shared broker component unless there is a specific requirement for this to happen.
Additionally, more complex application communication requires more complex monitoring, and the more difficult it becomes to understand the flow of data within the already complex cloud environment.
Virtualization adds additional application mobility that may need enhanced security controls. For example by default Hyper-V Live Migration or VMWare vMotion traffic is not encrypted and could possibly be intercepted. Ensure that either this traffic is encrypted or is used in a secure private VLAN.
3.2.11 Audit Extensively
The private cloud will be access by a range of users with differing levels of permissions. IT administrators will have direct access the physical and logical data and systems. All activity including request, provisioning, and usage and decommissioning should audited and logged to a secure location. Weekly and Monthly activity reports should be created and reviewed. Further, regular security audits should be performed to validate that the current security design includes mitigations for known threats. If not already applicable, you should consider gaining consider certifications such as ISO/IEC 27001and SAS 70 Type II.
ISO/IEC 27001 is an international standard has been prepared to provide a model for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving an Information Security Management System (ISMS). This International Standard can assess conformance by interested internal and external parties. For more information, visit https://www.iso.org.
Statement on Auditing Standards No. 70 (SAS 70) is an international auditing standard that enables businesses that provide services to other organizations to provide an independent, trustworthy account of their internal control practices. An independent auditor performs the SAS 70 audit and generates the resulting SAS 70 report, which the service provider supplies to its customers and clients for use when they themselves undergo auditing. For more information, visit https://www.aicpa.org.
3.2.12 Implement Effective Governance, Risk Management and Compliance
In a private cloud, because ownership of and responsibility for services hosted in the cloud is split between various parties, the SLAs between the parties must make clear where those responsibilities lie and what the different parties should expect from each other.
The set of SLAs that you must consider will depend, in part, on the particular cloud model adopted by your organization:
- If you chose to adopt a hybrid cloud model, or chose to host your private cloud with a third-party organization, then the enterprise CSP will have SLAs with the third-party cloud service provider and with the client business units within the organization. In these scenarios, the IT department is acting as a broker to deliver and manage cloud services provided by an external entity, to internal clients.
- If you are hosting the private cloud on premises, you must then negotiate SLAs between the IT department and the client business units.
If you are using a third party to provide some or all of the private cloud services in the enterprise, then you must ensure that the SLAs with the third party provider enable you to meet your SLAs with your internal clients. This requires a detailed understanding of what the third party SLAs offer in terms of security.
For example:
- How do they guarantee isolation between tenants?
- What do they guarantee in terms availability and disaster recovery?
- How do they ensure the integrity of your applications and data?
- What steps do they take to ensure the physical security of your data such as vetting employees who have access to the physical environment and hardware disposal procedures?
Regardless of whether you choose to host the private cloud externally with a third party, on premises, or adopt a hybrid approach, you will still need SLAs between the your IT department and the tenants within the organization. The on-demand, self-service attribute of the private cloud, means that there may be some delegation of responsibility for managing the security of the virtualized environment to the tenant.
In addition to the guarantees made to the tenant by the cloud service provider, SLAs may also need to specify requirements related to security that the tenant must fulfill. For example, an SLA might specify the encryption technologies that the tenant service should use to protect data, or that the tenant should use the enterprise directory for identity management through federation services provided by the CSP.
Layer 8 Security Functions:
How much delegation of responsibility occurs will vary between organizations and between tenants. For some organizations, the primary motive behind adopting a private cloud model will be to make more efficient use resources by pooling them. The IT department will still deploy and manage applications and services on behalf of the client business units. In this scenario, the on-demand, self-service characteristic is not significant to the relationship between the cloud service provider and the client business unit, and SLAs will cover traditional areas such as availability, disaster recovery, and performance.
However in some scenarios, tenants will make use of the on-demand, self-service functionality of the private cloud to obtain and manage infrastructure or platform resources to run their own applications and services. In this case, the split in responsibility for security features such as identity and access management or data protection may be more complex and the SLAs must include clear definitions that are understood and agreed upon by all the concerned parties.
Scenarios that are more complex are also possible. For example, in addition to managing the private cloud infrastructure, the IT department may also commission, procure, or develop applications for other business units within the organization. In this scenario, one part of the IT department may use the on-demand, self-service capability of the private cloud to acquire infrastructure or platform services on behalf of the client business unit and also handle some or all of the ongoing management of the service on behalf of the client business unit.
This arrangement creates a situation where there are two SLAs:
- One between the cloud service provider one between the service provider sections of the IT department
- One between the service provider part of the IT department and the client business unit
In a private cloud, all parties must have an explicit understanding of their obligations and responsibilities and agree to them. Depending on the model adopted by your organization, the list of parties involved might include:
- Third-party cloud services providers
- Internal cloud-services provider
- Application and software providers who are a part of the IT department and who consume private cloud services
- Client business units within the organization whose applications and services are hosted in the private cloud
When you are negotiating and drafting SLAs you must ensure that:
- You cover all aspects of security for all hosted services and applications and there are no gaps in responsibility.
- Your SLAs with third party providers enable you to meet the SLAs with your tenants.
3.2.13 Create Data Classification Zones
Modern private clouds allow you to create logical grouping of resources (Compute, Storage and Networking) to which role based access rights and data classifications attributes can be assigned. Data classifications zones can be created to enforce business and compliance rules to govern which types of data may be used, stored and transmitted in that zone. For example, let’s consider a financial company that needs to categorize data on a shared private cloud infrastructure by isolating federally regulated applications and systems from non-regulated applications (Protected).
Further, let’s consider that the financial company also needs to ensure that all data is encrypted at all times for applications that process credit card information (Secure). The financial company would need to create at least three data classifications zones in the private cloud. Each zone will have its unique data privacy and protection rules enforced by well-known security measures.
General Data Zone
- This zone contains general purpose VMs, application or databases configurations. All users may be permitted to view, deploy and access systems in this zone.
Protected Data Zone
- Sample Requirements - only applications and data used for federally regulated purposes can be deployed to this zone. All OS images and Database Servers must be configured to federally regulated standards prior to deployment. All access and activity in this zone must be audited. The Zone should support categorization of data by security impact level of Low, Medium and High. For more information see on Federally regulated Information Systems requirements, and design considerations for information categorization in for private cloud see the FISMA website https://csrc.nist.gov/groups/SMA/fisma/index.html
- Implementation – All VM templates, application templates, OS images and library files will be restricted for use in this zone. OS images will be configured using federal configuration standards. Only users with access to these catalog items will be permitted to deploy to this zone. All request, provisioning, usage and retirement activity in the zone will be audited at the host and management level.
Secure Data Zone
- SampleRequirements– any financial or customer data must be protected via strong encryption measures in transit, during processing and at rest. OS images and databases servers that run validated financial applications are hardened according to regulations standards. All access and activity in this zone must be audited. For more information on payment industry Information Systems requirements see
- Implementation – All VM templates, application templates, OS images and library files will be restricted for use in this zone. OS images will be configured using financial industry configuration standards. Only users with access to these catalog items will be permitted to deploy to this zone. All request, provisioning, usage and retirement activity in the zone will be audited at the host and management level.
When designing your security zone, ensure to address the following considerations:
- Self Service Catalog – contains protected, secure and general use VM and application templates. Access to the catalog should use role based access controls to restrict what users are allowed to view and use. For example users with only General Zone access should not see templates and files that are restricted to Secure or Protected Zone use.
- Automation – is used during the provisioning, de-provision process should be restricted and treated as data that needs to be classified. For automation scripts that installs and configures a SQL database should only be made available to users that have access to the templates for the appropriate data classification zone.
- Templates – in the private cloud become the primary method of enforcing deployment standards, with validated configurations for VMs and application. Templates should be planned and created as part of the audit compliance validation process for regulated systems. Unique templates should be created for each VM, application or database server for each zone type. Templates with different data classifications should be stored in separate directories in the shared library, and access controls limit which user and IT administrators have access to create or use those templates. VM templates should be used to create a deployment configuration policy for a zone. For example, a Secure Zone VM Template should contain:
- VM OS Image configured for Secure use
- Hardware configuration that uses encrypted disk drives (in guest encryption)
- Network configuration that only allows deployment to VLANs that support encrypted traffic
- Storage configurations that only allow deployment to SANs that have encrypted volumes by default, and are classified for zone use.
The figure below shows an example of how to perform logical and physical segmentation while preserving the data classification zone:
3.3 Security Responsibilities
In a traditional data center environment, the demarcation of security responsibilities between the data center operator and the
service user was relatively well defined. Generally, the responsibility was aligned with ownership of the physical component, whether that was a server, a networking device or the overall network infrastructure; if the IT department owned and administered the server, then that department also managed and updated security on that asset.
With cloud models, security responsibility has altered, in that departments may be responsible for a portion of the security on the service that they pay for, depending on the service provisioning model in use. Figure 4 shows the split of security responsibility for the three main cloud provision models.
Summary
In this first section of the Private Cloud Security Considerations guide you were provided an introduction to the private cloud security domain. This included discussions around conceptual design, private cloud security principles and delegation of responsibility. In the next section, we’ll drill down and look at some of the details of the private cloud security considerations.
