Freigeben über

Private Cloud Security Considerations Guide-Security Challenges

  • Artikel

This section of the Private Cloud Security Considerations Guide covers a number of security design challenges that you willimage need to address when considering options for making the best decisions for securing your private cloud .

Table of Contents

5 Private cloud Security Challenges

   5.1 Resource Pooling Security Considerations

   5.2 Broad Network Access Security Considerations

   5.3 On-demand Self-Service Security Considerations

   5.4 Rapid Elasticity Security Considerations

   5.5 Measured Service Security Considerations

   5.6 Mitigating Security Risks 

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:

5.0 Private Cloud Security Challenges

The previous section outlined the private cloud security problem domain, design principles that should apply at all levels of the private cloud design and design considerations. This section examines the key attributes that characterize cloud architectures: resource pooling, broad network access, on-demand self-service, rapid elasticity, and measured services. For each of these attributes, this section will analyze the security considerations in order to:

  • Identifies the potential impact of the attribute on the design of the security functionality in your private cloud.
  • Describes how the cloud security design principles apply to the detailed design of the features that support the cloud attribute.

As described in section 3.3.3 of the Private Cloud Security Considerations Guide, security should be the foundation for the entire design process. The private cloud security model presented in figure 1 shows how security concerns are relevant to all elements in all layers and stacks within the architecture:

  • Infrastructure
  • Platform
  • Software
  • Service delivery
  • Management

The sections that it follows will use those security capabilities as the foundation for the private cloud attributes security considerations.

5.1 Resource Pooling Security Considerations

Resource pooling in a private cloud enables virtualized resources to reassign dynamically to other tenants and to optimize resource usage. Your virtualization solution must clean any resources, especially storage and memory, before reassigning them to another tenant so that data belonging to the original tenant is not exposed to the new tenant. In the private cloud, automated processes typically handle the cleaning and allocation of resources to tenants.

In a typical cloud, the resources that a tenant uses could be hosted on any of the physical devices in the cloud that offer that resource.

Learn by Example:
For example, when a client provisions and starts a virtual machine in the private cloud, that virtual machine could be hosted on any of the physical servers in the cloud. One consequence that follows from this arrangement is that the same physical machine could host applications and services with different levels of business criticality, and that those applications and services may themselves include very different security features, such as those that govern authentication.

Logical separation of shared resource pools should be performed with cloud management toolsets like Microsoft Virtual Machine Manager. VMM allows IT administrators to create logical grouping of physical resources (compute, store and networking) in to resource pools. Then tenant data classification bounds can be set.

When designing your private cloud security and defining the resource pooling capability it is important to have a solution that uses a pool of resources that can be allocated to many different tenants, while ensuring the proper isolation of resources (network, compute, memory, storage) between tenants. The significant aspects of resource pooling in a private cloud that will affect your security design are:

  • Reuse of resources by different tenant applications
  • Co-location of services belonging to different tenants on the same physical server
  • The automated processes that handle the allocation and de-allocation of resources

Identity and access management systems will help you to manage the authentication and authorization that will control access to virtual resources by their owners. Within the enterprise, a single identity and access management system, will simplify the task of configuring and managing authentication and authorization for tenant applications and services, especially when there is a requirement to integrate several tenant applications with each other. If multiple identity and access management systems exist, then you can use federation services, such as those provided by ADFS, to integrate them where necessary.

Although you can use authentication, authorization, and role-based controls to manage access to resources, in a private cloud you must also assume that credentials can be stolen or abused and that someone can gain access to resources that they should not be able to reach.

Data protection services will help to preserve the confidentiality of data stored in virtual environments. Monitoring combined with automated responses will enable you to handle possible attacks in this complex environment, and logging will enable you to investigate and analyze problems and provide evidence to auditors.

5.1.1 Infrastructure Security

Your design must address the risk that that a low business impact service might be more easily compromised by an attacker and the attacker can then exploit that weakness to attack the high business impact service running on the same physical server. An attack may involve trying to gain access to the high business impact service's data, or simply making the high value service unavailable by overloading the low value service.

To address this issue, you could:

  • Consider dividing the infrastructure into pools so that you can segregate the hosted applications, for example, running high business impact applications and services in their own pool. That pool may have more stringent security controls applied at the infrastructure layer or might only run applications and services with integrated security controls. This arrangement might affect service billing, with high security pools demanding premium billing. With high capacity servers resources spools can support dozens of VMs while using data classification zone to provide tenant and data type isolation.
  • Specify limits on the type of application that you will allow to run in the private cloud. For example, no services classified as being high business impact can run on the private cloud infrastructure.

The infrastructure layer typically includes network traffic monitoring in network devices such as switches. This type of monitoring can identify unusual traffic that may indicate that an attack on the infrastructure is in progress or that some element in the cloud is compromised. Table 1 has also core infrastructure components and its security considerations for private cloud.

Table 1 Infrastructure security considerations for resource pooling

Component

Security Considerations

Important Notes

Network Virtualization
  • Primarily route all network traffic through your physical network devices unless your virtualization solution provides virtual network inspection built in or via third party component.
  • Add additional monitoring functionality to each server to monitor each virtual network.
  • Use a virtualization solution that enables virtualized network traffic monitoring devices.
  • Ensure that network traffic between virtual machines is encrypted to protect it as it is moves through the cloud infrastructure.
  • Assign encrypted networks to specific VLANs that will allow networks to be used for secure data to be assigned to secure resource pools or data classification zones.
  • Encrypting traffic on the wire means that intrusion detection systems and intrusion prevention systems will not be able to inspect the traffic. However, you can still use IPsec to provide authentication (for example by using AuthIP and ESP-NULL), which enables the parties to be sure of each other's identities, detect any tampering of the payload, and optionally guard against replay attacks.

Storage
  • Perform whole volume encryption to protect physical storage media in case an attacker gains access to the underlying physical storage infrastructure from within a virtual environment. Virtual machines should only have access to the virtual storage devices allocated to them.
  • As always, evaluate the trade-off between performance and security that arises with any encryption technique. Different encryption algorithms offer different performance characteristics and different levels of protection. Keep in mind that not all traffic needs to be authenticated and encrypted – design over-the-wire encryption into your plan where it makes the most sense.

Virtualization
  • Isolate your host environment from the guest workloads and ensure isolation between the virtualized guest environments
  • Allowing access from the guest to the host could allow an attacker access to the private cloud infrastructure. Potentially, this would enable the attacker to damage or disrupt the entire cloud infrastructure, or to launch an attack on other virtual environments hosted in the cloud.

5.1.2 Platform Security

Although controls should be in place in the infrastructure layer to protect the hosted virtual environments, you should adopt the defense in depth principle and assume that an attacker could discover a weakness in the infrastructure security and try to gain access to the platform (or virtualized operating system) that hosts the tenant application or service. Table 2 has other considerations regarding virtualization platform.

Table 2 Platform security considerations for resource pooling

Component

Security Considerations

Important Notes

Virtualization
  • All virtual machines have a host-based firewall configured to protect them from network attacks from the external world, other virtual machines, or the underlying infrastructure.
  • All host-based firewalls only allow inbound and outbound traffic from and to the specific machines with which they must communicate.
  • You can also use IPsec to logically isolate groups of hosted virtual machines so that they cannot communicate outside of the group with other hosts on the network. For example, if you have a multi-tier application hosted in your private cloud, then you could use IPsec to ensure that the database server can only be reached from the middle-tier server, and that the middle-tier server can only be reached from the front-end web server.

Application/ Service
  • Tenant application or service in a private cloud consists of virtual compute, memory, storage, and network resources. The virtualization solution that you adopt must ensure the isolation of all of these resources (and any others that may be used) for each tenant.
  • If two or more tenant applications hosted in different virtual machines do require access to a shared resource, such as when two hosted applications may require network connectivity or access to the same database server, this sharing must be managed such that only the participating applications have access, and the shared use is actively monitored.

All administrative access from operations staff and the owner of the virtual resource should be fully authenticated, authorized, logged, and audited.

5.1.3 Software Security

Applications and services running in the private cloud can protect their data in a number of ways. The design of these securityimage features will be the responsibility of the application designer, not the designer of the cloud infrastructure. However, the cloud service provider (CSP) should take steps to ensure that the application designer is aware of the data protection services and other security features that are provided by the cloud infrastructure, and of any specific features of the cloud infrastructure that might influence the design of the application or service.

Some specific issues that an application or service designer should address include the encryption techniques they use to protect their data and how the disaster recovery planning services provided by the cloud work with their application.

Learn by Example:
For example, the infrastructure layer may use whole volume encryption to provide protection for data stored on that volume in the event that an attacker gains direct access to the underlying storage. From within a virtual machine, applications can access their stored data without decrypting it because the infrastructure performs the decryption on behalf of the virtualized environment. Because of this feature, an application hosted in a virtual machine in the cloud may require its own encryption services for sensitive data so that if an attacker gains access to the virtual machine, he or she will be unable to access the sensitive data.

A tenant application may encrypt data in storage, data in memory, and data during processing to make it more difficult for someone to read, intercept, or tamper with it in a tenant application or service even if they have gained authenticated and authorized access to the tenant's environment. However, all encryption techniques rely on the existence of a private key to perform both encryption and decryption in the case of a symmetric encryption algorithm, or decryption in the case of an asymmetric algorithm. However strong the encryption algorithm, it is useless if someone gains unauthorized access to the private key. Table 3 has other considerations regarding software security.

Table 3 Software security considerations for resource pooling

Component

Security Considerations

Important Notes

Encryption
  • Any encryption technique must use private or secret keys to decrypt encrypted data. In a virtual machine, this private or secret key must be stored somewhere inside of the virtual machine so that the application can decrypt its data.
  • The owner of the application that uses data encryption within the virtual machine must take steps to protect any private or secret encryption keys. This protection must be effective when the virtual machine is running or dormant, and must be effective for any backup or archive copies of the virtual environment.
  • Tenants should use any secure key storage facilities offered by the platform or virtualized operating systems to store the private keys used by their application.
  • Tenants should follow strict procedures to protect keys from being discovery outside of the virtual environment.
  • Clients should also consider encrypting data during processing in their tenant application.
  • If attackers gain access to the virtual machine, they may be able to gain access to any private keys stored inside the virtual machine, rendering any encryption worthless.
  • Tenants should use separate keys during development and test, and securely delete local copies of keys after they have been uploaded and installed in the virtual environment where they will be used.
  • Data stored temporarily in a queue or data stored in memory could become visible in a memory dump if a server or virtual machine experiences a stop error

Development Methodology
  • Private cloud tenants should be encouraged to use a security development lifecycle for the applications that will be hosted in this environment.
  • Using Microsoft SDL as development methodology can assist developers to create apps that can mitigate potential risks exposed in a shared environment like private cloud.

Auditing and Logging
  • Developers must decide to use HTTP or HTTPS depending on the contents of the logs. If an application is logging a large amount of data that won’t be of interest to outside parties or eavesdroppers, then HTTP can be used for a faster transfer.
  • However, Microsoft recommends protecting all log data in transit to public cloud providers by using HTTPS.

Request Throttling / Input Sanitization
  • Developers must do application-level throttling of incoming requests for any kind of complex, time-intensive operation.
  • The Microsoft Security Development Lifecycle (SDL) portal at https://www.microsoft.com/sdl provides resources on fuzzing parsers. If a service is parsing a proprietary file or request format (perhaps encapsulated inside HTTP), then fuzz test it to ensure the code can correctly accommodate malformed input.

In a private cloud, the cloud infrastructure may move tenant applications to different physical servers or even different data centers to maintain availability in the face of hardware failures or to optimize performance or resource utilization. Any encryption techniques used by tenant applications to protect data must continue to be effective in these scenarios. Any automated processes that move applications and services to different physical devices must ensure that any keys used to protect application data continue to be available to the applications and services that need them; if this approach requires keys to be copied between locations, the automated process must ensure that this transfer process is secure.

5.1.4 Management Security

SLAs between the cloud service provider and the client business units should specify what level of access to client data in what circumstances is permitted to operations staff. All management operations, whether performed by the cloud service provider or consumer must be logged and be auditable.

In many regions, there is legislation that relates to data protection and privacy. In a private cloud, you must ensure that it is clear who within the organization is responsible for compliance. For example, the IT department might be responsible for ensuring proper isolation between the virtual environments used by the different business units, but a business unit might be responsible for ensuring that their application or service is compliant.

Hybrid clouds or the use of distributed clouds across different geographic regions to provide better performance or more resilience might also complicate the issue of monitoring for compliance: it may not be permissible to move some data across geographic regions, legal data protection and privacy requirements might be different in different regions. In these scenarios, you must enable a client business unit to specify where their cloud-hosted application or service can run.

5.2 Broad Network Access Security Considerations

As a designer of a private cloud solution, it is important to provide appropriate authentication and authorization services for the broad range of users accessing the cloud. Different services have different security requirements, such as different levels of security, access from multiple locations, or self-provisioning of users. This section describes how these capabilities relate to the broad network access attribute of private clouds.

There is in an increasing demand from business users to enable support for a wider range of client devices such as mobile phones and tablets. These devices, along with more traditional clients, may be used both internally and externally to access corporate systems. These requirements, combined with the fact that private clouds may also enable on-demand self-service access to resources and have an infrastructure that is built to support virtualization and resource pooling, give rise to the following concerns that you should address in your private cloud design:

  • There is a much broader attack surface available to potential attackers, not only from outside the organization, but also from within. For example, if an attacker manages to compromise a guest operating system hosted within the private cloud, in effect you have an attacker operating within your data center.
  • Tenants may manage some aspects of the security of their virtual environments, including authentication and authorization.
  • There is no longer a clearly identifiable perimeter around your resources: an attack on a hosted service could potentially come from an external source, another hosted service, or from the infrastructure.

To mitigate these threats, you need to ensure that access to resources, applications, services is authenticated and authorized, and that all access is monitored, logged, and auditable. This must happen consistently regardless of the client device type. You may require different strengths of authentication (password, certificate, multifactor) based in the location of the client (private cloud, intranet, extranet, internet) and the sensitivity of the application's data (personally identifiable information, company confidential information, publicly available information).

5.2.1 Infrastructure Security

The use of virtualization technologies to build private cloud infrastructures means that there are new potential targets for attackers. By targeting the hypervisor technology that underpins the virtualization in a private cloud, an attacker may be able to disrupt the entire cloud or use the hypervisor to gain access to other virtual machines hosted in the cloud. Table 4 has other considerations regarding infrastructure security.

Table 4 Infrastructure security considerations for broad network access

Component

Security Considerations

Important Notes

Hypervisor
  • Ensure that hypervisors and host operating systems are not accessible from the guest operating systems controlled by the tenants.
  • Consider dividing your infrastructure resources into pools
  • Consider potential attacks originating from guest operating systems running within your data center as well as more traditional threats from outside your security perimeters.
  • This approach may affect the efficiency of your resource utilization in the cloud because certain tenant applications are constrained to run in a particular pool of hypervisors, but it does enable you to build security boundaries between the pools to limit the scope of any attack on the hypervisor infrastructure

Hardware
  • Consider using hardware security features to detect unauthorized changes to the hypervisor

Network
  • Minimize routing network traffic within the cloud infrastructure.
  • By using this approach you will minimize the number of locations where the infrastructure might be exposed to attack

5.2.2 Platform Security

In the IaaS and PaaS private cloud models, the platform is typically a virtual machine hosted on the cloud infrastructure. The platform hosts the tenant's service or application, and client applications will access these services or applications from within the corporate network, from outside the corporate network, or potentially from other virtual machines running in the cloud. Supporting broad network access to the virtual machines in the platform means a greater potential attack surface. Table 5 has other considerations regarding platform security.

Table 5 Platform security considerations for broad network access

Component

Security Considerations

Important Notes

Host
  • Assume that the host operating system could gain access to the virtual machine
  • Every host must run its own anti-malware software
  • You may have a different assumption depending on the hardening level for the host and how your virtualization platform handles this access.

Network
  • Every virtual environment must be protected by its own firewall
  • Protecting inbound and outbound traffic from the virtual environment is a very important consideration.

5.2.3 Software Security

In the IaaS and PaaS service delivery models, tenants may be wholly or partly responsible for the management of the applications and services that they chose to host in the cloud. Although there will be security features protecting the infrastructure and platform directly, a defense in depth approach means that the cloud service provider should not rely solely on these security features.

By making it harder for an attacker to compromise a virtual environment managed by a tenant, the cloud service provider makes it harder for an attacker to use this route to attack the private cloud infrastructure. Table 6 has other considerations regarding software security.

Table 6 Software security considerations for broad network access

Component

Security Considerations

Important Notes

Access Control
  • Apply strict controls to the software that tenants may run in their virtual environments.
  • An example of that will be limiting the available APIs or the permitted programming languages that they can use to develop hosted applications and services

Overall Configuration
  • Lock down the security configuration.
  • An example of that will be firewall settings, in the platform or virtualized operating system such that the tenant cannot modify them

Deployment
  • Validate the tenant's software before they can deploy it to the private cloud.
  • Validation process should be done in a isolated environment to not interfere with the production network.

Development Framework
  • Use corporate policies to specify guidelines or methodologies that tenants must follow when they develop, commission, or purchase applications to run in the cloud.
  • For example, corporate policy may mandate development teams within the organization to use the SDL methodology to improve the overall security of their products. This approach helps to shift the responsibility to the tenant, but you will still need to audit compliance.

SLA
  • SLAs between the cloud service provider and the tenants should make clear who is responsible for which aspects of software security in the virtual environment.
  • Ensure that there is a common agreement and this agreement is documented in the SLA before put any software in production.

All of these considerations may limit the utility of the private cloud solution because they conflict with the provision of other cloud attributes, especially the on-demand self-service attribute. These controls may also require completion of additional complex manual steps before the tenant's software can be deployed and used. It is also important to encourage tenants to use existing services as part of their solution wherever possible.

The cloud service provider can manage the security of some enterprise wide services in the cloud, so that tenants do not haveimage to re-implement them.

Learn by Example:
For example, the CSF can provide identity federation services (such as Active Directory Federation Services or ADFS) in the cloud, you can make it easier for tenants to participate in single sign-on, and utilize your existing security infrastructure for identity management and access control rather than creating their own authentication and authorization mechanisms and expanding the available attack surface.

As you move through the cloud service delivery models from IaaS, through PaaS, to SaaS, the cloud service provider takes more responsibility for the security of the hosted application or service, and the tenant gives up more control of the environment and loses some degree of flexibility. The PaaS and SaaS models therefore make it easier for the cloud service provider to ensure consistent standards of security and to reduce the threat to the virtual environments.

5.2.4 Service Delivery Security

Supporting broad network access to the cloud will tend to reduce the amount of filtering and monitoring that the cloud service provider can apply at this layer as it must allow traffic from a wider range of devices and locations through this layer. Table 7 has other considerations regarding service delivery security.

Table 7 Service delivery security considerations for broad network access

Component

Security Considerations

Important Notes

Service endpoint
  • Tenants may need the ability to configure their service endpoints to make their applications and services available to a broad audience who use a broad array of devices.
  • An example will be opening the necessary ports and configuring SSL. The CSP will need to consider the inbound and outbound traffic requirements of tenant services and have an automated method to enable and disable this traffic, as appropriate.

Service controls
  • CSP can specify the controls that must be in place on the services that you and the tenants use.
  • One example of service will be the self-service portal for requesting cloud resources or billing services.

5.2.5 Management Security

Tenants may require the ability to perform some management operations from client applications and devices of their choice. Table 8 highlights some key considerations regarding management security.

Table 8 Management security considerations for broad network access

Component

Security Considerations

Important Notes

Authentication
  • All access to cloud management services should be authenticated.

Attack Surface
  • Reduce the available attack surface by restricting access to management services to specific client devices in specific locations.
  • One example of service will be the self-service portal for requesting cloud resources or billing services.

Access Control
  • In case tenants do have access to some cloud management tools, then there should be role-based access controls in place to limit who can perform the management operations.
  • Assigning individual users to the relevant roles should be a part of the provisioning process for cloud resources.

These considerations will largely be driven by determining what access, if any; tenants should have to any of the cloud management tools.

5.2.6 Client Security

In a private cloud, business units within the enterprise may have responsibility for and ownership of the tenant services and applications hosted in the cloud. In this is the case, the business unit will also determine whether there are any controls over the client applications used to access the cloud-hosted service. Table 9 highlights some key considerations regarding client security.

Table 9 Client security considerations for broad network access

Component

Security Considerations

Important Notes

SLA
  • SLAs can mandate that certain security features are included in client applications.
  • Service model often makes it possible to discover the service API, so it is always possible that someone could build their own client application to exploit vulnerabilities in the service API using known or discovered credentials for the service.

Application Scope
  • Limit the client applications that can act as a client to the service is to use a certificate-based mechanism. A consumer, service, or computer must present a valid certificate before it can invoke any service operations.
  • This approach is dependent on robust Public Key Infrastructure (PKI) and well managed policies to ensure that someone who wants to impersonate an existing, approved, user cannot discover and purloin the certificate.

It is also important to mention that client devices can cache data for performance, enable the user to export data to save locally, or simply enable a user to screenshot data. All of these features, and many others, make it difficult to protect the data that client applications make available to the end user. Unless you can apply strict controls to the client environment, it is difficult to mitigate these risks.

You must determine if any local laws or regulations place restrictions on where the data may be located, or whether the clients must include any particular security features. If the client business unit is responsible for the service, the SLA between the IT department and the business unit must specify where responsibility for compliance lies.

5.3 On-demand Self-Service Security Considerations

As a designer of a private cloud solution, you should design access control for the services hosted in the cloud. You should also determine who can request services and how much they can request. This section describes how these capabilities relate to the on-demand self-service attribute of private clouds.

The on-demand, self-service characteristic of a public cloud implies that anyone with a credit card can purchase the resources they need as and when they require them. For the private cloud, you must determine who within the enterprise should have the authority to request resources from your private cloud (and who has the authority to release those resources when they are no longer required).

The key issues associated with the on-demand self-service attribute of the private cloud are therefore:

  • Authentication, authorization, and role-based access controls that control who, within the organization, may provision and manage cloud-based resources.
  • Monitoring and auditing the use of a provisioning portal to ensure that controls are applied effectively.

In a private cloud, the client who requests the resources may not be a separate business unit within the organization but can be the IT department itself, acquiring resources from the cloud on behalf of a client business unit. In this scenario, one of the benefits derived by the organization is the ability of the IT department to make new infrastructure resources available much faster than in a more traditional architecture.

5.3.1 Infrastructure Security

Apart from being able to initiate requests to provision and de-provision cloud resources, tenants should have no access to the private cloud physical infrastructure. If your private cloud supports the IaaS service delivery model, then your self-service provisioning portal should enable clients to request virtual infrastructure resources.

5.3.2 Platform Security

Although from the perspective of the tenant the request for a resource such as a virtual machine to host a departmental application may appear to be a single operation, the provisioning process is more complex. The tenant must be granted access to the resource they have requested and typically this will include some administrative rights for the resource. Table 10 highlights some key considerations regarding platform security.

Table 10 Platform security considerations for On-demand Self-service

Component

Security Considerations

Important Notes

Provisioning
  • Provisioning process must correctly configure the security environment for the resource.
  • Ensure that the security configuration of the virtual machine allows access for the tenant and no one else.
  • Ensure that the operating system has a base-line security configuration applied for the tenant
  • Create any necessary VLANs, granting access to storage, and setting up the required security monitoring and logging.
  • This consideration is important because the provisioning process automatically creates the virtual machine and may configure it with an operating system for the tenant to use.
  • This consideration is appropriate if the provisioning process also installs an operating system on the virtual infrastructure.
  • Data isolation and protection
  • The design should specify any security settings that must be applied to protect the tenant's data, and to protect the host environment in case the guest environment is compromised.
  • This consideration is particularly important for the IaaS model where tenants will access cloud-based resources through a virtualized environment.

SLA
  • The SLA associated with the virtual resources must specify precisely what aspects of security in the virtual machine the cloud service provider manages, and what aspects the tenant manages.
  • The tenant owns the virtualized environment, and may now be responsible for designing, implementing, and managing the security in the virtualized environment.

Security Controls
  • Identify what a compromised host might be able to do in terms of attacking memory, compute, networking and storage to the cloud infrastructure and put controls in place to limit the impact of a compromised guest virtual machine on the entire infrastructure.
  • Consider the fact that even though these virtual machine templates will have a base desired security configuration, the cloud consumer is going to have complete control after the initial deployment.

5.3.3 Software Security

Although from the perspective of the tenant the process of software development might abstract itself from the private cloud infrastructure, there are still security considerations that should be taken when developing and guiding developers to create new apps for this environment. Table 11 highlights some key considerations regarding software security.

Table 11 Software security considerations for On-demand Self-service

Component

Security Considerations

Important Notes

Authentication and Authorization
  • Clients should be encouraged to use the existing enterprise security features such as authentication and authorization instead of building their own custom implementations into their tenant services.
  • By using identity federation services you can enable tenant services to participate in a single sign-on environment and use existing role memberships from the enterprise directory to determine authorization in their applications.

SLA
  • The private cloud provider is responsible managing the security of the service (in a SaaS model). However, the agreement between the provider and the consumer may specify that the consumer is responsible for some aspects of the security.
  • The SLA may state that the consumer should not share their credentials with another user and must take reasonable steps to protect their password.

Methodology
  • Follow best practice for development by adopting a methodology such as SDL
  • This consideration is particularly important in the IaaS and PaaS models, where the tenant is responsible for the design of the security features of their infra or application.

Identity and Access Management
  • Use existing enterprise security features included in directory services solutions such as Active Directory.
  • Leveraging current resources is important, instead of building their own identity and access management features, a tenant application should integrate with the existing identity providers using federation with ADFS.

Software acquisition
  • Specify security standards with which the purchased software must comply.
  • If tenants are purchasing third party software they should comply with the Enterprise security standards.

Validation
  • Use special test and staging environments in the cloud to verify the security of their applications and services
  • The validation/test environment should be isolated from the private cloud infrastructure to avoid that a rogue program start demanding more resources that it needs, which could affect other tenants in production.

Key Management
  • Use secure platform key management services for keys used by the tenant's hosted service or application
  • This consideration is particularly important in the IaaS and PaaS models, where the tenant is responsible for the design of the security features of their infra or application.

5.3.4 Management Security

Designing administrative security for managing the cloud infrastructure should follow best practice in terms of using role-based access control and the principle of least privilege. However, you must take into account the fact that with the cloud infrastructure it is difficult to identify where services and data physically reside.

Learn by Example:
For example, a role that enables members of the role to make a configuration change on a host server may have the ability to make the change on any host server in the cloud. Table 12 highlights some key considerations regarding software security.

Table 12 Management security considerations for On-demand Self-service

Component

Security Considerations

Important Notes

Authentication and Authorization
  • Role-based access control for the self-service provisioning system to control who, in your organization, can make a provisioning request for cloud services.
  • Role-based access control for the various cloud services that you make available to tenants for use in their own hosted services.
  • Role-based access control for managing the cloud infrastructure itself.
  • Use role-based access control for all cloud management functions
  • Use roles to control what level of access tenants have to any management functionality.
  • Take into consideration that client business units have this ability; it may be that only the IT department can use this functionality.
  • Consider using identity federation services that may be used by a tenant to integrate with the enterprise directory to handle authentication in the tenant's service
  • Consider who can view the infrastructure monitoring data from a virtual machine host.
  • In a private cloud infrastructure you might have many cloud management functions, for example financial management, capacity management, and fabric management.
  • Different tenants may require different levels of access and different users associated with a tenant may require different levels of access. Tenants should only be able to manage their own hosted environments and services.

Administrative Privileges
  • Ensure that you always use the principle of least privilege.
  • Start with no privilege and add only what it is necessary to perform the job. However, you must take into consideration the fact that with the cloud infrastructure it is difficult to identify where services and data physically reside. For example, a role that enables members of the role to make a configuration change on a host server may have the ability to make the change on any host server in the cloud.

SLA
  • SLAs should specify what management functions the tenant can perform on their resources, and what management functions the cloud service provider can perform on the tenant's resources.
  • SLAs should specify in what circumstances the cloud service provider can shut down a virtualized environment owned and managed by a client business unit, and what notification should be given that this is happening.
  • Explicitly stating the function that the tenant can perform is key security component at the same time that sets the correct expectation for the tenant.
  • An example of that is a scenario where monitoring within the cloud determines that a virtual operating system has been compromised by an attacker and is trying to gain access to other virtual environments in the cloud, automatic management procedures should close the compromised environment immediately and notify cloud operators and the client. Note that you might consider implementing mitigation procedures that would allow a temporary increase in resources to the workload while the tenant attempts to rectify the problem with the service still online.

Operations
  • When the cloud service provider performs a management operation, that operation may potentially affect all tenant services or some subset of tenant services. Because of the way that a cloud pools resources it may not be easy to predict which tenants experience disruption to services.
  • Consider that for some management operations, you must assume that it will affect mission-critical services in the cloud. You must design membership of your administrative roles accordingly.

Responsibility for compliance with any local legislation (for example in relation to traceability of actions) may lie with either imagethe cloud service provider or the tenant. SLAs should specify where that responsibility lies.

5.4 Rapid Elasticity Security Considerations

Among other concerns that a designer of a private cloud solution should have, one of the most relevant concerns related to the essential characteristic called rapid elasticity is that a rogue application, client, or DoS attack might destabilize the data center by requesting a large amount of resources. It is important to balance the requirement that individual consumers/tenants have the perception of infinite capacity with the reality of limited shared resources.

Cloud architectures offer elasticity of resources to clients and hosted applications and services. From the tenant’s perspective, the cloud offers an unlimited pool of resources. If the consumer of the cloud service anticipates a burst in demand for their service, the client can request more resources from the cloud to ensure that the service is capable of meeting that demand.

A more sophisticated hosted application or service can monitor demand and automatically request additional resources from the cloud using an API. Clients and client applications can also release resources back into the pool when they are no longer required.

The key issues associated with the rapid elasticity attribute of the private cloud are therefore:

  • Authentication, authorization, and role-based access controls that control who or what, within the organization, may request additional resources from the pool or return resources that are no longer required to the pool.
  • Monitoring and auditing requests to allocate and de-allocate resources to ensure that quotas are respected and that the availability of individual services, hardware devices, and the private cloud is maintained.
  • Ensuring data destruction with pooled resources so that session information from one tenant is not available to another tenant.

5.4.1 Infrastructure Security

Monitoring is equally important for both provisioning and de-provisioning requests: an attacker may attempt to destabilize the private cloud by shutting down resources. As has also been discussed, the provisioning and de-provisioning processes must ensure that the resources available in the pool for reuse do not contain any sensitive data that could be exploited by the application or service that next acquires the resource.

From the perspective of the tenants, the private cloud is an unlimited pool of resources, available on demand. From the perspective of the cloud service provider, the private cloud is fixed size pool of shared resources used by client business units who have expectations of the quality of service they will receive from the cloud.

You may also offer different sizes of resource to clients (for example small, medium, and large virtual machines), and in order to maintain availability for all clients you might need to limit the number of certain sizes of virtual machine in your cloud so that 10% of virtual machines are large, 60% are medium, and 30% are small. Table 13 highlights some key considerations regarding infrastructure security.

Table 13 Infrastructure security considerations for Rapid Elasticity

Component

Security Considerations

Important Notes

Quota
  • Define quotas to mediate access to the cloud resources.
  • Ensure that these quotas are specified in the SLA.
  • Determine the appropriate granularity of the resource quotas and determine whether the quotas may be adjusted.
  • The intent is to avoid that client or attacker can accidentally or deliberately overwhelm the cloud infrastructure with provisioning requests or grab a large share of the available resources to the detriment of the service availability to other clients.
  • Transparency as a service provider an essential element to gain trust, therefore to implement such quotas you must be able to tell which client made the provisioning request (remembering that the request itself may be made automatically by a running service), dynamically monitor the resource utilization by client, and enforce the quota.
  • This recommendation is important for scenarios where a client requests a higher quota for a service that is particularly resource intensive; or a in a case where the client requests a lower quota for a lower priority service or ask for limits on the costs associated with running the service.

·

Availability
  • Maintain availability for all clients.
  • Use dynamic load balancing for the applications and services hosted in the cloud as demand for those services changes and as services scales in or out
  • To ensure availability, the cloud infrastructure must be able to handle provisioning requests in a timely manner.
  • Dynamic load balancing may require running virtualized environments to move between physical servers or even between data centers. In addition to maintaining availability, the automated procedures that handle this process must maintain the confidentiality and integrity of these virtualized environments.

Logging
  • All requests to provision or de-prevision resources for a client must be logged and auditable.
  • While logging is important, be able to use those logs to audit resources and usability is an important practice.

Although the considerations mentioned in Table 13 are important, you must remember that when overall demand is high for cloud resources, any load balancing and quota-based rationing of resources must guarantee availability of systems as specified by any SLAs with the client business units.

If demand for private cloud resources is highly elastic and you cannot maintain the availability of the hosted services with your existing capacity, you can adopt a hybrid model and extend your private cloud to infrastructure provided by a third party (sometimes referred to as “cloud bursting”). In this scenario, you must consider what impact, if any, does hosting a service in the third party's infrastructure instead of your own will have on:

  • The SLAs with your client business units.
  • The integration of a tenants application with other services hosted in your private cloud.
  • The legal requirements that relate to the hosted application.

5.4.2 Software Security

Software that can scale in a private cloud faces two security related issues:

  • Although the private cloud infrastructure can enable rapid elasticity in the supply of virtual resources, hosted applications and services must be designed correctly if they are to function securely when they are scaled out.
  • Hosted applications and services that initiate scaling requests automatically based on monitored demand or a timetable must perform these operations without impacting their own or other services availability within the cloud.

Table 14 highlights some additional considerations regarding software security.

Table 14 Infrastructure security considerations for Rapid Elasticity

Component

Security Considerations

Important Notes

Scalability

· Applications that are designed to scale may require some mechanism to share user state across instances.

· SLAs or corporate policies may define how to accomplish shared state securely; for example, specifying requirements for cookie encryption.

Availability

· Poorly designed auto-scaling algorithms used in a hosted service could affect the availability of other services.

· The cloud infrastructure should include checks within the auto-scaling service to prevent repeated resource requests and enable tenants to specify upper and lower limits on their resource requirements.

· This behavior can occur by a continuous request to provision and then deprovision a resource, or by continuing to request resources indefinitely.

· Adding this capability will help to prevent that poorly designed auto-scaling algorithm inadvertently shut a service down completely, making it unavailable.

5.4.3 Management Security

Provisioning and deprovisioning requests and scale in and out requests are made through a cloud management interface, implemented either as a GUI or through an API. Access to these functions should be protected through role-based access control policies and their use fully logged. Additionally, these interfaces should implement any quota checks on resource allocation that you want to enforce.

Certain applications may need to guarantee availability or meet targets for response time or throughput to meet legal or corporate policy requirements. The private cloud's enablement of rapid elasticity in meeting demand for services, must ensure that any such legal or corporate requirements are met without comprising the confidentiality, integrity, or availability of those or any other services hosted in the cloud.

5.5 Measured Service Security Considerations

As a designer for a private cloud you want to ensure that all applications and services running in the cloud are measured and accounted for. Protecting the measurement and billing services in the private cloud it is an important task. Securing measured services will enable tenants to understand what they are paying for and to be able to identify any resources that they are paying for that they did not explicitly approve. You also need to understand how these capabilities relate to the measured service attribute of private clouds.

In a private cloud environment, it is important for the CSP to track all chargeable use of the cloud services by its tenants so that it can bill tem accordingly. A concern of the private cloud service provider here is to ensure that tenants cannot bypass the monitoring systems in any way to reduce the amount they have to pay. Although it is unlikely that a business unit within an enterprise would try to steal cloud services from the enterprise private cloud in this way, there is the risk that someone could try to use the private cloud resources for their own purposes.

Learn by Example:
For example, an employee could run a private web server in the corporate cloud (often hosting explicit adult material) or someone from outside who gained access to the private cloud could run a private mail server. To achieve this without being detected, the person or entity using the private cloud resources would either have to bypass the measuring and billing in the private cloud, or arrange for their use to be paid for by a legitimate client such as a business unit.

The measured service attribute of private clouds also affects the overall availability of resources in the private cloud. By measuring and charging for the use of resources in the private cloud, the cloud service provider encourages tenants to return resources to the pool when they have finished with them. Without this cost incentive, tenants may hang on to resources indefinitely even though they are not using them, reducing the overall availability of the private cloud's resource pool.

5.5.1 Infrastructure, Platform, and Software Security

You must ensure that all monitoring and logging features that measure resource usage and charge tenants accordingly are protected from tampering. Such logging must always be accurate and must always correctly identify who is using the resource.

5.5.2 Management Security

Tenants should be able to access their own billing information through the financial management services in the private cloud with enough detail to enable them to identify any possible unauthorized usage of resources on their behalf. The cost of resources should provide a sufficient incentive for client business units to monitor their resource usage.

5.6 Mitigating Security Risks

Taking the private cloud reference model as the basis for analysis, you can identify threats to the private cloud infrastructure and place these threats into appropriate places within the model. This approach provides a basis for threat modeling and risk analysis.

Hence, you can classify attacks according to the layer or stack that the attack targets. The figure below highlights the primary areas in the private cloud where these individual attack types can target. Note that this diagram is not showing responsibilities but listing the different types of attacks that might take place against the management stack, the infrastructure layer and so on.

You should also note that some of these areas may be out of control of the private cloud provider, such as client security. A later section discusses the implications of changes to the client security relationship.

image

Security Alert:
This figure only summarizes the threats that may exist at the different levels of the cloud architecture. For an explanation of each of these threats and applicable countermeasures, see Cloud Security Threats and Countermeasures at a Glance, at https://blogs.msdn.com/b/jmeier/archive/2010/07/08/cloud-security-threats-and-countermeasures-at-a-glance.aspx.

5.6.1 Shared Tenant Model

A key differentiator with public cloud environments is that the service is provided on a shared tenant basis and multiple tenants use the same services. The public cloud implementation then applies authentication, authorization, and access controls to create logical partitions between the tenants so that individual tenants are isolated from each other and cannot see other tenants’ data.

Security Alert:
In private cloud terminology, a tenant is a client, typically a business unit within the organization, who is using the private cloud to run their applications and services.

The perception of a private cloud is that it is only hosting one organization, and in consequence, security partitioning is not required. In reality, organizations may have good reasons to want to implement such partitioning, such as between different business groups or between the finance department and the rest of the organization. In consequence, a private cloud model may also be a shared tenant model with similar requirements for effective security partitioning between different business units as with public cloud implementations.

5.6.2 Virtualization

Virtualization is not an absolutely essential component of private cloud architectures, as organizations can use blade server arrays or other compute-dense configurations to provide cloud-based services. However, the advantages of improved server utilization and greater operational flexibility that virtualization platforms provide have led to very high uptake of this technology in both cloud environments and in the predecessor architecture to the cloud, the dynamic data center.

Security Automation Note:
Virtualization radically changes the way an organization secures and manages their data center. Because workloads are mobile and can move from host to host based on optimization algorithms that require no human involvement, security policies linked to physical location are no longer effective, so security policies must be independent of network or hardware topologies.

Although estimates of data center server virtualization indicate that this technology has reached adoption levels of over 50%,image management and security tools for virtualized environments are still catching up with the physical systems that they replace. The presence of the new hypervisor layer provides additional attack vectors and new opportunities for security breaches.

One example of the new attack vectors occurs when virtual machines running on the same physical host typically use virtual networking components to communicate between these guest operating systems. In consequence, virtual machines can be communicating with each other without those communications being picked up by monitoring tools on the physical network. IT staff must be able to identify when inter-virtual machine traffic is occurring and apply policies and monitoring to that traffic.

A key factor for implementing effective security in virtualized environments will be virtualization of the security controls themselves. As these virtualized controls become available, they should as a minimum meet the following criteria:

  • Fully integrate with the private cloud fabric
  • Provide separate configuration interfaces
  • Provide programmable, on-demand services in an elastic manner
  • Consist of policies that govern logical attributes, rather than policies that are tied to physical instances
  • Enable the creation of trust zones that can separate multiple tenants in a dynamic environment

In summary, security in private cloud environment must be adaptive and natively implemented into a fabric where resources are allocated dynamically. Any security functionality that is tied to a server, an internet protocol (IP) address, a media access control (MAC) address, port, or other physical instance will no longer be as effective as in purely physical environments.

Summary

This brings us to the end of the Private Cloud Security Considerations Guide. We hope you enjoyed this deep dive and architectural perspective for planning and designing security for private cloud environments. If you have questions or would like to see additional material in this area, please feel free to write Tom Shinder at <tomsh@microsoft..com>. And please, feel free to make comments in the comments section of this article. Thanks from all of us! –Tom.

Go Social with Building Clouds! Building Clouds blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Building Clouds Twitter account Private Cloud Architecture LinkedIn Group Building Clouds Google+ Community Cloud TechNet forums TechNet Cloud and Datacenter Solutions Site Cloud and Datacenter Solutions on the TechNet Wiki image