As a designer of a private cloud solution, how do I design access control for the services hosted in the cloud? Who can request services and how much can they request?image

Security Functionality

Figure 1 lists a number of capabilities that the security wrapper should include in the private cloud such as:

  • Identity and access management
  • Data protection
  • Monitoring
  • Management
  • Authentication
  • Authorization
  • Role-based access control
  • Auditing

This section describes how these capabilities relate to the on-demand self-service attribute of private clouds. The following sections will describe how your design should apply these capabilities at each layer in the private cloud architecture.

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. Provisioning new virtual servers and storage services may be done in minutes rather than the weeks or months it can take to procure and commission a physical server and storage, and this means that the IT department is able to provide a significantly better service to its client business units within the organization.


Note:
This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Solution for Private Cloud is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this document, please include your name and any contact information you wish to share at the bottom of this page


A key benefit of the cloud is that IT resources are treated as a utility that can be metered and billed for, so the decision about who can make and approve those requests will be similar to the decision about who can make and approve other purchasing decisions. You should consider integrating the cloud provisioning portal with any existing purchasing system that includes an approval process and auditable workflow.

Another benefit of the cloud is the elasticity of the supply of resources. Any authorization to use cloud resources should define the value of the resources that may be consumed, record total usage and report on the total cost of consuming the services for a given time period. The self-service service provisioning system should use policies to specify quotas for these limits.

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.

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. Additionally, the provisioning process must correctly configure the security environment for the resource, for example: creating any necessary VLANs, granting access to storage, and setting up the required security monitoring and logging. 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.

In the IaaS model, tenants will access cloud-based resources through a virtualized environment. The provisioning process automatically creates the virtual machine and may configure it with an operating system for the tenant to use. The provisioning process must ensure that the security configuration of the virtual machine allows access for the tenant and no one else. If the provisioning process also installs an operating system on the virtual infrastructure, then the provisioning system must ensure that the operating system has a base-line security configuration applied for the tenant. The tenant owns the virtualized environment, and may now be responsible for designing, implementing, and managing the security in the virtualized environment. 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.

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. In this situation, you will need to 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.

Software Security

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. For example, 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.

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

In the IaaS and PaaS models, the tenant is responsible for the design of the security features of their infra or application. The tenant should be encouraged to adopt best practice and any corporate standards in this area, for example:

  • Follow best practice for development by adopting a methodology such as SDL.
  • Use existing enterprise security features included in directory services solutions such as Active Directory. Instead of building their own identity and access management features, a tenant application can integrate with the existing identity providers using federation with ADFS.
  • Specify security standards with which the purchased software must comply.
  • Use special test and staging environments in the cloud to verify the security of their applications and services.
  • Use secure platform key management services for keys used by the tenant's hosted service or application.

Management Security

Your design for authentication and authorization systems for private cloud management must support:

  • Role-based access control for the self-service provisioning system to control who, in your organization, can make a provisioning request for cloud services (it may be that client business units have this ability, it may be that only the IT department can use this functionality)
  • Role-based access control  for the various cloud services that you make available to tenants for use in their own hosted services (for example,  identity federation services that may be used by a tenant to integrate with the enterprise directory to handle authentication in the tenant's service)
  • Role-based access control for managing the cloud infrastructure itself (for example, who can view the infrastructure monitoring data from a virtual machine host)

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. 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.

Other recommendations for management security in the private cloud include:

  • Use role-based access control for all cloud management functions (for example, financial management, capacity management, and fabric management).
  • Use roles to control what level of access tenants have to any management functionality. 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.
  • 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 also 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. For example, if 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.  

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. Therefore, 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.

Legal Issues

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

REFERENCES:

 

ACKNOWLEDGEMENTS LIST:
If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:
[Enter your name here and include any contact information you would like to share]

Return to Private Cloud Security Challenges

Return to Design Guide for Private Cloud Security


Return to A Solution for Private Cloud Security

Return to Reference Architecture for Private Cloud

Move forward to Private Cloud Security Challenges - Rapid Elasticity

Table of Contents for A Solution for Private Cloud Security