Share via

Private Cloud Security Model - Wrapper Functionality

  • Article

As discussed earlier in this paper, the private cloud must implement security as a wrapper. Every transaction then must pass through this security wrapper on any datahttp://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-85-24-metablogapi/5658.image_5F00_64BCDD48.png transition within the cloud, for example:

  • Client to the service delivery layer
  • Service delivery layer to the software layer
  • Software to platform layers
  • Platform to infrastructure layers
  • Provider to the management stack
  • Management stack to the software, platform, or infrastructure layers

In addition, security applies to all intra-layer communications/, to data being processed, and to data at rest. The exact security mechanism applied will depend on the data type, the source and destination layers, or the environment in which that data is being transmitted, processed or stored. For example, software developed for cloud implementations should follow the security development lifecycle (SDL) guidelines. For more information on these guidelines, see Microsoft Security Development Lifecycle, at http://www.microsoft.com/security/sdl/default.aspx.

This final section of the paper links these mechanisms to the private cloud reference model capabilities and discusses the security concepts and issues that apply to each capability.

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

Identity and Access Management

Identity and access management (IdAM) covers the overarching issue of establishing identity and then using that identity to control access to resources. Identity and access management is fundamental to private cloud design, as you must be able to establish the identity of a cloud consumer and then manage their access to resources within the cloud environment. However, it is important to remember that IdAM also applies to administrators and to services that may access your private cloud.

IdAM can include the following security topics:

  • Authentication
  • Authorization
  • Auditing
  • Directory service
  • Federation
  • Security policies
  • RBAC
  • Credential management

Authentication

The first functionality that your IdAM framework must provide is that of establishing identity through the process of authentication, for example by requiring a user to enter a user name and a password. These credentials are then checked with a directory service, metadirectory, or other authentication mechanism, typically by using some form of hashing algorithm so that the user’s password is not transmitted across the network. If the authenticating mechanism validates the user credentials, then the operating system or federation environment generates a token. This token may contain information about the user and the groups of which that user is a member. Alternatively, in a federated environment, the token may contain one or more claims about the user. Note that this token does not contain any permissions.

For higher levels of security in your private or hybrid cloud environment, you may want to implement two-factor authentication, such as with a smartcard and personal information number (PIN) combination, a biometric sensor such as a fingerprint reader or retinal scanner, or a hardware device that generates a unique code at logon. Two-factor authentication requires the user to have possession of a physical item (the card, finger, or eye) and the corresponding PIN. You can implement two-factor authentication as a client authentication mechanism or as part of a federated login process.

Whichever authentication mechanisms you select, you will need to consider how you will support password resets, PIN unblocking, hardware device failure or Crossover Error Rate (CER. The identity provider (typically a directory service) must support two-factor authentication and there must also be a suitable mechanism for passing the authentication or federation tokens to the requested services.

Authorization

The second part of IdAM is the access management part, which includes the process of authorization. Authorization and authentication have to work together both to identify users and control the resources that they access.

In server-based computing, authorization typically involves setting permissions on objects, such as files, folders, shares, and processes. In virtualized environments, you also need to set permissions on virtual machines and virtual networks. In private cloud implementations, you should also control compute resources, storage groups, and service end points.

Access to a resource comes from comparing a user’s access token with the permissions set on the resource. Typically, these resource permissions are cumulative, so a user with read permission from their own account and read and write permission resulting from group member ship has read and write access to the resource. Deny permissions trump allow permissions, so a user with read and write permission from their personal account but who is a member of a group that is denied access to the resource will not have access to the resource.

In private and hybrid cloud environments, identity must be able to flow dynamically between resources that may not have any common mechanism for exchanging identity information. You can accomplish this task by use of federation technologies, which implement claims-based authentication to a centralized identity store, such as a directory service. Services, applications, and other resources can then use these claims to check the user’s identity, based on a federation trust model between two or more federation providers.

Role-Based Access Control

Private cloud implementations also require use of RBAC mechanisms for controlling what actions a user or service can carry out. Because private and hybrid cloud implementations tend to consist of loosely-coupled components, you need to establish a common framework for defining roles, scoping the rights that apply to each role, and then ensuring that these rights and roles apply consistently to each cloud component, depending on whether that component is hosted internally or externally.

Anonymous Permissions

A key element with authorization in private cloud environments is the control of anonymous permissions. Anonymous permissions enable unauthenticated users or services to access resources. Many operating systems allow anonymous logons, which are typically used for public access to web sites. With most private cloud implementations, users would typically be known to the organization and therefore authenticated. However, there are scenarios where anonymous access might be required, for example to enable members of the public to interact with an online communication session as a guest. In all cases, there should be strict partitioning between any resource that allows anonymous access and ones that require authenticated access.

Federation and Claims

Federation is a mechanism for authenticating users from one security domain and authenticating them on another domain without the requirement for an intrinsic trust relationship between the two organizations. The organizations themselves may be running different operating systems, directory services, certification authorities, and security protocols. Hence, this approach is particularly useful in hybrid cloud implementations and is carried out using claims-based authentication.

A claim is a collection of assertions about a user, such as their user name, email address, or groups of which they are a member. Claims are generated by a security token service (STS) in one organization where that user is able to authenticate against that organization’s directory service. Claims are electronically signed to prevent tampering in transit and the communication channel over which claims are exchanged may also be encrypted.

To exchange authentication information, the two organizations establish a public key infrastructure (PKI) trust between the STS in one organization and the STS in the other organization. When a user wants to authenticate to a resource controlled by the other organization, their logon request is redirected to their home realm and authenticated by the IdAM system in that realm. After authentication, the home STS generates the cryptographically signed security token containing the claims about the authenticated user. This token is then submitted to the requested service at the other organization.

Because the home realm has authenticated that user and the cryptographic signing guarantees that the token has not been altered in transit, then the target service accepts the token and, depending on the claims in that token, authorizes that user to access the service.

Federation is particularly important in both private and hybrid cloud environments, as services may run in completely different security contexts. In the case of private cloud implementations, the home realm for every user may be the organization’s directory service and applications or services can be configured to establish federated trust relationships with that STS. The services at the service delivery layer, the applications in the software layer, the virtual machines within the platform layer, the operating systems integral to the infrastructure layer, and the management consoles and services forming the management stack can then all use this federated environment for authentication, authorization, and RBAC.

Auditing

Together with authentication and authorization, auditing is an essential component of your private cloud IdAM environment, particularly with regard to establishing compliance and implementing effective governance. With public cloud implementations, you are also likely to want to achieve Auditing Standards (SAS) Type I or II accreditation or possibly ISO 27001 compliance to demonstrate to your customers that you take security seriously.

With private cloud implementations, showing compliance with external auditing standards may not be so important. What you will want are the answers the following types of questions:

  • Which user accounts have been locked out over the last day, week, or month?
  • Who has attempted to access resources to which they do not have permission?
  • Have any administrators changed access permissions that would enable them to view consumer data?

These are in effect relatively straightforward questions to answer and a central auditing system should help you identify when these events occur. But there are questions that might require more sophisticated analysis:

  • Are any users or administrators behaving in a suspicious manner?
  • Are access requests for one resource being redirected to another resource?
  • Are attempts being made to communicate between virtual machines or between virtual machines and host computers?

As mentioned earlier in this paper, a significant change in private cloud implementations is that you can no longer assume that attackers are unauthenticated. Hence your auditing implementation must be able to identify unexpected or suspicious activity and be able to filter out that activity from the thousands of regular operations without imposing an unacceptable performance burden or generating excessive numbers of false positives.

Typically, the starting point for auditing is the directory service and most commercial directory services implement effective monitoring capabilities. However, you are also going to need to monitor at other levels within your private cloud infrastructure. These levels include monitoring the following resources:

  • Firewall
  • Service endpoint
  • Application
  • Database
  • Virtual machine monitoring through the operating system
  • Host computer operating system
  • Network
  • Storage
  • Management

You can use an audit collection and collation service to forward these events to a centralized database. To ensure that events do not swamp the database, you would implement event filtering so that only events of particular interest are collated. Analysis tools can then interrogate this database to identify suspicious activities.

Auditing must be of sufficient precision and granularity to be able to track the actions of a single individual right the way through the entire private cloud environment. This end-to-end auditing of individuals is vital for checking up on the actions of your administrators.  

The auditing database itself also requires auditing and management. Unless properly managed, the number of events can cause the database to grow excessively.

Finally, the auditing output must directly support any compliance requirements that apply to your organization. Ideally, this information would be displayed as a dashboard, with easily-assimilated indicators showing current and historic levels of compliance.

Data Protection at Rest

The main aim of security in cloud environments is to protect data both at rest and in transit. Hence, data protection is a major factor that needs to be incorporated into the very fabric of your private cloud service blueprint. Data protection at rest includes consideration of the following factors:

  • Software encryption or hardware encryption
  • File and folder encryption or full disk encryption
  • ACLs and access control entries (ACEs)
  • Storage policies

Protection of data at rest requires that information to be encrypted. This encryption can be applied in a number of ways, depending on factors such as cost, performance, and ease of configuration.

Hardware Disk Encryption

There are two forms of hardware-based disk encryption. One uses a specialized microprocessor that is part of the disk hardware; the other uses either the main processor or a host bus adaptor (HBA). In both cases, hardware encryption enables the entire disk to be encrypted, which gives rise to the term full or whole disk encryption. Full disk encryption protects the master boot record (MBR), the files and folders, the folder structure and the partition table.

Performance for a disk with dedicated hardware-based encryption is similar to that for a non-encrypted device. Hardware-based encryption with external processing may perform less well if the main processor is busy.

As the whole disk is encrypted, this arrangement protects the disks if they are physically removed from the private cloud environment. As private cloud architectures stress resiliency over redundancy and tend to use arrays of hard disks, this approach prevents data from failed drives being read and also ensures that an attacker cannot read a hard disk that they have physically removed from the environment. Administrators can instantly and irretrievably wipe a hard disk by using the cryptographic disk erasure process. This process generates a new key for the hard disk, thus making all the old data inaccessible in milliseconds, compared to several minutes for a repeated disk wipe.

The key for hardware disk encryption is typically 32 bytes or 256 bits in length, which gives 2256 or 1.16x1077 combinations and makes a successful brute force attack highly unlikely. However, after the disk is mounted, the operating system has full access to all parts of the disk as the encryption is now provided transparently by the hardware. Hence, the limitation with hardware-based encryption in a private cloud environment is that it only uses one key to encrypt the whole disk and you cannot use the hardware key to partition data on the disk between different tenants.

Software Disk Encryption

Software-based encryption can work in two ways; it can encrypt either the full disk or just a set of specified files and folders. Unlike hardware-based full disk encryption, software-based full disk encryption of the boot disk does not encrypt the MBR. Performance is also reduced compared to dedicated hardware-based encryption, as the operating system needs to decrypt data on the partition.

File and folder-based software encryption does not encrypt an entire volume but enables you to encrypt individual files and folders. The advantage of file and folder-based software encryption is that you can encrypt different folders with differing encryption keys, thus enabling data partitioning between users or business units that is not possible with full disk encryption.

When you create your design, you will need to consider whether you need disk encryption and then how to apply that disk encryption. Note that you can combine dedicated hardware-based full disk encryption with software-based file and folder encryption to reap the benefits of both systems.

Data Protection in Transit

Data protection in transit is a different proposition to data protection at rest and requires you to consider a range of approaches and technologies to provide effective security. While very few organizations would not consider implementing data encryption for data transiting the Internet, many are still not implementing equivalent levels of encryption and data protection within their organizations. Private cloud environments should also seek to improve security by implementing encryption for every transaction, not just those from the client to the service endpoint. Hence, your design must consider encryption of the following data transit paths:

  • Service endpoint to software layer
  • Software layer internal communications
  • Software layer to platform layer
  • Platform layer internal communications
  • Platform layer to infrastructure layer
  • Infrastructure layer internal communications
  • Management layer to service delivery, software, platform and infrastructure layers
  • Private cloud to public cloud environment (for hybrid implementations)

To use encryption to protect your data in transit, you may consider the following technologies:

  • Secure Sockets Layer (SSL) or Transport Layer Security (TLS)
  • IP security (IPsec)
  • Virtual private networking (VPN)

All of these encryption approaches use symmetric key bulk encryption combined with asymmetric public/private key pair encryption to exchange the bulk symmetric key between the sending and receiving parties. This approach ensures that encryption does not place too great a processing load on the hosts at either end of the encrypted link. If a private cloud implementation requires the service delivery layer to accept large numbers of simultaneous encrypted connections, specialized SSL offload processors are available to offload the initial handshake process that then sets up the symmetric bulk encryption session.

Although SSL 3.0 has been widely accepted as the basis for securing web browsing sessions, this version of the protocol is now seen as less secure than later implementations. The introduction of TLS 1.0 (SSL 3.1) in 1999 further improved security and the latest version of this protocol is now TLS 1.2 (SSL 3.3), which was implemented as RFC5246 and published in 2008. TLS operates at the transport layer of the Internet protocol suite, which includes Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Stream Control Transmission Protocol (SCTP). In your private or hybrid cloud design, you will most probably use TLS to secure the client or provider to service delivery layer traffic and the service delivery layer to software layer connection.

IPsec is a protocol suite that provides encryption, mutual authentication, and cryptographic key exchange during a communication session between two hosts.  IPsec operates at the Internet layer of the Internet protocol suite.

VPNs are most commonly used to create secure tunnels through public networks. The advantage with VPN technologies is that after the VPN is created, it acts like a physical network, directing outgoing traffic to the VPN default gateway regardless of the intervening network appliances. VPNs can use a range of technologies, including Point to Point Tunneling Protocol (PPTP) and a combination of IPsec and Layer 2 Tunneling Protocol (L2TP).

Applications that can’t connect over Internet protocols can typically connect quite happily by using VPNs. Hence you can use VPN connections as part of your private cloud implementation to connect consoles in the management stack to managed services in the software, platform, or infrastructure layers.

Key length has a direct effect both on the speed of encryption and the security of the resulting data exchange. For bulk encryption of SSL/TLS traffic, a 40-bit symmetric key length is woefully inadequate and even the 56-bit Data Encryption Standard (DES) key length is regarded as obsolete. 128-bit encryption is still judged strong enough for private cloud use but many implementations now use 192 or 256-bit symmetric key lengths specified in the more secure implementations of Advanced Encryption Standard (AES).

Note:
There are still restrictions in relation to the export of cryptographic technology. You should check if these restrictions apply to your location, as you may not be able to use longer key lengths.

To exchange the symmetric key, you need to use an asymmetric key pair with equivalent computational security. Because public-private key pairs can be broken by integer factorization as well as brute force, asymmetric keys must be considerably longer than the symmetric key that they are protecting. The following table shows the key lengths that provide equivalent protection for symmetric and asymmetric key types using the Rivest-Shamir-Aldeman (RSA) algorithm:

Symmetric Key Length

RSA Asymmetric Key Length

112-bit

2048-bit

128-bit

3072-bit

256-bit

15360-bit

 

Note that 1024-bit asymmetric keys are now regarded as insecure.

For private cloud implementations, the best balance between security and key length is a combination of 128-bit symmetric keys protected by 2048 or 3072-bit asymmetric keys.

For the highest levels of transport security, you may need to consider data tokenization. This approach is typically used in Payment Card Industry (PCI) environments that must conform to the PCI Data Security Standard. Tokenization replaces the confidential data with values that are not confidential. The confidential data is not transmitted but the token can be used to reference that information from the tokenization data store. This approach is also widely used for medical records, bank transactions, vehicle registration details, and credit card payment information.

Certificates

In a private cloud implementation, you may need to use digital certificates for TLS/SSL encryption, for client authentication, server authentication, and for a range of other security-related purposes. In common with non-cloud implementations, you will most probably use X.509 v3 certificates for these activities. However, a significant difference with a private cloud environment will be the requirement to create large numbers of certificates as part of the provisioning process.

For example, if you want to provision a secure web server within a virtual machine, then that web server will require a host name and corresponding IP address. To implement TLS/SSL encryption, the provisioning process must also create an X.509 certificate with a common name that matches the host name of the default web site on the virtual machine.

In consequence, you will need to create certificates and bind them to web sites or applications as part of your provisioning process. This requirement is likely to mean that you need to implement an internal certification authority (CA) to generate these certificates or connect to a public CA and request a new certificate for each provisioning action that requires encryption support.

In public cloud implementations, the certificates that you provision would have to show a certificate chain relationship to a root certificate issued by a trusted CA. The client computer would have this root certificate installed in its trusted root certificate store.

With private cloud implementations, you have the option of using a private CA within your cloud infrastructure to respond to these provisioning requests. However, you would then have to ensure that your client computers trusted the issued certificates. This trust is automatically established with domain membership in Microsoft Windows if the root CA certificate is published in Active Directory, but with non-domain-joined computers and mobile devices you would have to arrange for the root certificate to be installed in each client’s trusted root store.

Security Monitoring and Response

Just as security needs to be pervasive in private cloud environments, so does your security monitoring. This security monitoring also needs to be tightly integrated with your overall monitoring environment.

Effective security monitoring must not only be integral to your private cloud operation but it must be able to cope with the rapid expansion and self-service elements of private cloud operation. For example, because consumers can provision and deprovision resources rapidly, you may not know exactly how many virtual machines are currently in operation or how many applications you are hosting. And if you don’t know what resources are online at any one time, you can’t secure those resources.

When a virtual machine is started up, you need to ensure that either agent-based or agentless monitoring starts as soon as the virtual machine is operational and that the results of that security monitoring are run through the intrusion detection system and collated in the auditing database. You also need to be able to confirm that the virtual machine conforms to your security policies and are not acting suspiciously.

Auditing and security monitoring by themselves are not enough; you also need to respond to incidents in a timely manner and take decisive action to contain a security breach. In cloud-based environments, this requirement may mean implementing tools that take automatic action rather than wait for human intervention. For example, if a user appears to be acting suspiciously, your security management software should be able to terminate that user’s session and disable his or her account before alerting an administrator.

Security Management

Security management is the overall capability that provides the ability to manage and control all security aspects of your private cloud implementation. You will need to consider the following factors when creating your private cloud service blueprint:

Proactive and reactive management: In private cloud environments, security management needs to be both proactive and reactive. You must implement proactive security through risk assessments, threat modeling, data classification, security policies, preconfigured virtual machine templates, access rights, update procedures, reduced attack surfaces and so on. You will also need to implement reactive security management by using security monitoring and automated security responses.

  • Risk assessments. By identifying the types of risk inherent to your operations, you can identify the major security threats to your private cloud infrastructure.
  • Threat modeling. From your risk assessment, you can model the threats and classify them according to severity. As has been pointed out already, private cloud environments change the nature of the threat as well as provide new and different potential attack vectors.
  • Data classification. Not all data requires classification at the same security level. For example, your organization’s published policy statement on sustainable IT does not require the same protection as a spreadsheet with financial projections for a new product launch. Your security management must allow for these differences and afford the correct level of protection for different data types.
  • Security policies. Security policies need to be defined, created, applied, monitored, adjusted, and maintained. These policies should apply enough protection in a loosely-coupled environment to secure the data without hindering employees from carrying out their work.
  • Attack Surface Reduction. Attach surface reduction is important at every level within the private cloud architecture. This principle also applies to virtual machines.
  • Update procedures. Your security management environment must implement processes for updating host operating systems, virtual machines, development environments and applications rapidly and reliably. With private cloud environments, you have additional options which may involve provisioning or cloning a virtual machine, applying security updates to the clone, and then reverting back to the original if the updates cause malfunctioning.

Note that in certain situations, compliance or application requirements may dictate that the provider does not have access to the virtual machines before provisioning. Hence, the provisioning, updating, and mounting process must be fully automated.

Your security management environment must control these processes where possible and verify that any changes that take place do not affect the operational integrity of your environment. In addition, your security management environment must not introduce additional security vulnerabilities, so principles such as encrypted communications with IPsec, RBAC, two-factor authentication and attack profiling must apply to the management environment as well.

RESOURCES:

 

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 Model[

Return to Blueprint for A Solution for Private Cloud Security](http://social.technet.microsoft.com/wiki/contents/articles/blueprint-for-a-solution-for-private-cloud-security.aspx)

Return to A Solution for Private Cloud Security

Return to Reference Architecture for Private Cloud

Move Forward to Private Cloud Security Model - Infrastructure Security

Table of Contents for A Solution for Private Cloud Security