The document outlines a private cloud reference model that defines the problem space, requirements, and interaction layers necessary for developing a private cloud architecture. It serves as a foundational guide for contributors and decision-makers, integrating technology with service management and emphasizing a collaborative approach to improve architectural documentation. The model decomposes the private cloud into various layers—service delivery, software, platform, infrastructure, service operations, and management—each addressing specific aspects of cloud service delivery and operational processes.

1. Private Cloud Reference Model
1 Introduction
This document gives an overview of a Private Cloud Reference Model. For the purposes of
this document, a Reference Model is defined as the problem definition, requirements, and
scope for a specific domain including the identification of all layers (or subdomains) and
any interactions or dependencies between the components.
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 the
quality of this document. 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.
An updated version of this article is now available as part of the Cloud Services
Foundation Reference Architecture article set.
This Reference Model forms the basis, or cornerstone, for all Reference Architecture in a
Private Cloud. It not only defines the domain but also sets taxonomy and drives
coherency of approach amongst the many authors who contribute to the Private Cloud
Reference Architecture documentation set. Every contributor and reviewer of the
Reference Architecture documentation should use the Reference Model to understand the
broad landscape of the problem domain before being able to decide if the existing
guidance meets their needs or identify what new guidance may be required.
The Reference Model will initially be depicted as a single diagram and the remainder of
the document will decompose each layer and describe its components.
This is a general purpose document that provides foundational context and approach for
the development of Reference Architecture documentation. Therefore, the first audience
for this document are all those people who are involved in the development of any Private
Cloud Reference Architecture. All reviewers of the Reference Architecture materials can use
this document to determine “fit for purpose” for their materials. The applicability of this
guidance is much broader than the development activity as any architect, service manager,
or technical decision maker will benefit from an understanding of the problem domain and
the approach to producing the Reference Architecture.
Table of Contents
• 1 Introduction
• 2 Reference Model
o 2.1 Service Delivery Layer
o 2.2 Software Layer
o 2.3 Platform Layer
o 2.4 Infrastructure Layer
o 2.5 Service Operations Layer
o 2.6 Management Layer
2 Reference Model
The Private Cloud Reference Model defines the scope and the problem space for its
domain. The model acts as the “guide-rails” to assist architects’ efforts to holistically
address the development of a private cloud architecture. Additionally, it provides a
common vocabulary and shared understanding across all constituencies.
The Reference Model below depicts a number of layers, which are further decomposed
into specific problem spaces or components.
1

2. Figure 1: The Private Cloud Reference Model
The Reference Model is split into the following layers:
• The Software, Platform, and Infrastructure Layers represent the technology
stack, where each provides services to the layer above.
• The Service Operations and Management Layers represent the process
perspective and includes the management tooling required to implement aspects
of the process.
• The Service Delivery Layer represents the alignment between business and
Information Technology (IT).
It is a deliberate attempt to blend technology and process (for example, Information
Technology Infrastructure Library (ITIL )) perspectives because Cloud Computing is
as much about the Service Management as it is about the technologies involved in it.
At first it may not seem much different from traditional IT; but remember, this is not a
Reference Architecture, it is a Reference Model and is defined as the problem
domain . Many of IT’s problems continue to be the same, from both a technology
and operational perspective; however, the differences now include some enabling
technologies and radical approaches based on the experience and concepts associated
with Cloud Computing. From an operational perspective, the desire to adopt good IT
Service Management practices has also been around for a long time. But many
organizations have not been effective in implementing these best practices and this
hinders their success. Cloud Computing is driving a new emphasis on operational rigor,
casting a fresh light on best-practices and forcing IT to re-think some of its fundamental
concepts.
The layers are further defined as follows:
• Service Delivery Layer: Represents those Service Management activities that
require input and interaction with the business and service owner. The
components are not only responsible for that interaction, but also the translation
of business requirement into technology and operational capabilities. This layer
represents the business perspective on the basis of IT.
• Software Layer: Provides the applications and software that support a business
activity (for example, CRM). The Software Layer consumes Virtual Machines (VM)
services from the Infrastructure Layer and may consume application services from
the Platform Layer.
• Platform Layer: Provides a set of platform-level (above operating system level)
building blocks which can be consumed by the Software Layer. It consumes
hypervisor services from the Infrastructure Layer and is managed by the
Management Layer.
• Infrastructure Layer: Provides resilient hypervisor services to the Platform Layer
and is managed by the Management Layer. The Infrastructure, Platform, and
Software Layers represent the enabling technology perspective within IT.
• Service Operations Layer: Represents Service Management and operational
processes carried out by IT operations and support staff.
• Management Layer: Provides management services to the Infrastructure,
Platform, and Software Layers. It is comprised of the suite of management tools
necessary to support IT Service and Operations Layer and implements the
operational processes. The Management Layer provides a baseline set of
capabilities to the Infrastructure Layer and an incremental set to the Platform
Layer and the Software Layer. The Operations and Management Layers represent
the operational perspective within IT.
2.1 Service Delivery Layer
The Service Delivery layer is the interface between business and IT. It serves as the conduit
for translating business requirements into IT services and is responsible for managing
2

3. ongoing delivery of those services. These capabilities are common to all services:
Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service
(SaaS).
Figure 2: Service Delivery Layer Components
As the primary interface with the business, the Service Delivery Layer is expected to know
or obtain answers the following questions:
• What services does the business want?
• What level of service are business decision-makers willing to pay for?
• How can private cloud move IT from being a cost center to becoming a strategic
partner to the business?
With these questions in mind, there are two main problems within the Service Layer that IT
must address:
• How do we provide a cloud-like platform for business services that meets
business objectives?
• How do we adopt an easily understood, usage-based cost model that can be
used to influence business decisions?
An organization must adopt the following private cloud principles in order to meet
the business objectives of a cloud-like service:
• Perception of Infinite Capacity: From an end user’s perspective, cloud services
appear to have no capacity constraints; and there is no limit to the volume of
service users can consume.
• Perception of Continuous Availability: An end user should never observe any
interruption in cloud services, even if failures occur within the cloud environment.
• Resiliency over Redundancy Mindset: Provider focus is on maintaining service
availability through resiliency instead of redundancy.
• Service Provider's Approach in Delivering Infrastructure: IT organizations
should adopt a service provider model based on infrastructure service definitions
with clear capabilities from provider and consumer perspectives.
• Drive Predictability: Remove as much variation from the environment as
possible to increase predictability.
• Minimize Human Involvement: A highly automated environment is required to
achieve resiliency.
• Optimization of Resource Usage: From the provider’s perspective, resources
should be optimized to maximize utilization and minimize waste, driving
efficiency and reducing cost.
• Encourage Desired Consumer Behavior: Use cost, quality, and agility to
influence consumer behavior in ways congruent with principles.
The components of the Service Delivery Layer are:
• Financial Management: Financial Management incorporates the functions and
processes used to meet a service provider’s budgeting, accounting, metering, and
charging requirements. The primary concerns around Financial Management in
a private cloud are providing cost transparency to the business and structuring a
usage-based cost model for the consumer. Achieving these goals is a basic
precursor to achieving the principle of encouraging desired consumer behavior.
• Demand Management: Demand Management involves understanding and
influencing customer demands for services, plus the provision of capacity to meet
these demands. The principles of perceived infinite capacity and continuous
availability are fundamental to stimulating customer demand for cloud-based
services. A resilient, predictable environment and predictable capacity
management are necessary to adhere to these principles. Cost, quality, and agility
factors influence consumer demand for these services.
• Business Relationship Management: Business Relationship Management is the
strategic interface between the business and IT. If an IT department is to adhere
to the principle that it must act as a service provider, mature Business
Relationship Management is critical. The business should define the functionality
of required services and partner with IT on solution procurement. The business
will also need to work closely with IT to define future capacity requirements to
continue adhering to the principle of perceived infinite capacity.
• Service Catalog: The output of Demand and Business Relationship Management
will be a list of services or service classes offered and documented in the service
catalog. This catalog describes each service class, eligibility requirements for each
service class, service-level attributes, targets included with each service class (such
as availability targets), and cost models for each service class. The catalog must
be managed over time to reflect changing business needs and objectives.
• Service Life Cycle Management: Service Life Cycle Management takes an end-
to-end management view of a service. A typical journey starts with identification
of a business need, through Business Relationship Management, to the time
when that service becomes available. Service strategy drives service design. After
launch, the service is transitioned to operations and refined through continual
3

4. service improvement. Taking a service provider’s approach is key to successful
Service Life Cycle Management.
• Service-Level Management: Service-Level Management is the process of
negotiating Service-Level Agreements (SLAs) and making sure the agreements
are met. SLAs define target levels for cost, quality, and agility by service class as
well as the metrics for measuring actual performance. Managing SLAs is
necessary for achieving the perception of infinite capacity and continuous
availability. This, too, requires a service provider’s approach by IT.
• Continuity and Availability Management: Availability Management defines
processes necessary to achieve the perception of continuous availability.
Continuity Management defines how risk will be managed in a disaster scenario
to make sure minimum service-levels are maintained. The principles of resiliency
and automation are fundamental here.
• Capacity Management: Capacity Management defines the processes necessary
to achieve the perception of infinite capacity. Capacity must be managed to meet
existing and future peak demand while controlling under-utilization. Business
Relationship and Demand Management are key inputs into effective Capacity
Management and require a service provider’s approach. Predictability and
optimization of resource usage are primary principles in achieving Capacity
Management objectives.
• Information Security Management: Information Security Management strives
to make sure that all requirements are met for confidentiality, integrity, and
availability of the organization’s assets, information, data, and services. An
organization’s particular information security policies will drive the architecture,
design, and operations of a private cloud. Resource segmentation and multi-
tenancy requirements are important factors to consider during this process.
2.2 Software Layer
The Software Layer provides the business applications with solution-specific runtime
components necessary to deliver a business service. It will consume hypervisor services
from the Infrastructure Layer and may consume application services from the Platform
Layer. The Software Layer provides interfaces to end-users.
2.3 Platform Layer
The Platform Layer provides application services to the Software Layer and consumes
hypervisor services from the Infrastructure Layer. Platform Layer interfaces will vary; some
examples of Platform Layer interface include Hypertext Transfer Protocol (HTTP) and
Representational State Transfer (REST).
2.4 Infrastructure Layer
The Infrastructure Layer provides hypervisor services (VM resources) to the Platform and
Software Layers. It defines the capabilities necessary for these VMs to execute; it includes
hypervisor, physical servers, network devices, storage systems, and facilities (which include
space, power, cooling, and physical interconnects).
Figure 3: Infrastructure Layer Components
Infrastructure Layer components include:
• Network: Network services provide addressing and packet delivery for the
provider’s physical infrastructure and the consumer’s VMs. Network capability
includes physical and virtual network switches, routers, firewalls, and Virtual Local
Area Network (VLAN).
• Compute: Compute services supply the physical resources such as CPU, Random
Access Memory (RAM), NIC, Video, and Storage used by the provider to deliver
VMs to consumers. It contains the physical server hardware and parent OS.
• Storage: Storage provides physical storage devices to the provider, which
exposes these services to consumers as virtual disks. Storage should be
connected to a network for VM portability.
• Hypervisor: The hypervisor provides VM services by partitioning and presenting
compute, network, and storage services.
• Facilities: Facilities represent the physical building, racks, power, cooling, and
physical interconnects.
2.5 Service Operations Layer
The Service Operations Layer defines the operational processes and procedures necessary
to deliver IT as a Service. This layer uses IT Service Management concepts that can be
found in prevailing best practice such as ITIL or Microsoft Operations Framework (MOF).
The main focus of the Service Operations Layer is to execute the business requirements
defined at the Service Delivery layer. Cloud-like service attributes cannot be achieved
through technology alone; mature IT service management is also required.
The Service Operations capabilities are common to all three services; IaaS, PaaS, and SaaS.
4

5. Figure 4: Service Operations Layer Components
The components of the Service Operations Layer include:
• Change Management: Change Management is responsible for controlling the
life cycle of all changes. Its primary objective is to implement beneficial changes
with minimum disruption to the perception of continuous availability. Change
Management determines the cost and risk of making changes and balances them
against the benefits to the business or service. Driving predictability and
minimizing human involvement are the core principles behind a mature Change
Management process.
• Service Asset and Configuration Management: Service Asset and Configuration
Management maintains information on the assets, components, and
infrastructure needed to provide a service. Accurate configuration data for each
component, and its relationship to other components, must be captured and
maintained. This data should include historical and expected future states in
addition to the current state, and be easily available to those who need it. Mature
Service Asset and Configuration Management processes are necessary for
achieving predictability.
• Release and Deployment Management: Release and Deployment Management
is responsible for seeing that changes to a service are built, tested, and deployed
with minimal disruption to the service or production environment. Change
Management provides the approval mechanism (determining what will be
changed and why), but Release and Deployment Management is the mechanism
for determining how changes are implemented. Driving predictability and
minimizing human involvement in the release and deployment process are key to
achieving cost, quality, and agility goals.
• Knowledge Management: Knowledge Management is responsible for gathering,
analyzing, storing, and sharing information within an organization. Mature
Knowledge Management processes are necessary to achieve a service provider’s
approach and a key element of IT service management.
• Incident and Problem Management: The goal of Incident and Problem
Management is to resolve disruptive, or potentially disruptive, events with
maximum speed and minimum disruption. Problem Management also identifies
root causes of past incidents and seeks to identify and prevent (or minimize the
impact of) future ones. In a private cloud, the resiliency of the infrastructure helps
make sure that faults, when they occur, have minimal impact on service
availability. Resilient design promotes rapid restoration of service continuity.
Driving predictability and minimizing human involvement are necessary to
achieve this resiliency.
• Request Fulfillment: The goal of Request Fulfillment is to manage user requests
for services. As IT adopts a service provider’s approach, it should define available
services in a service catalog based on business functionality. The catalog should
encourage desired user behavior by exposing cost, quality, and agility factors to
the user. Self-service portals, when appropriate, can assist the drive towards
minimal human involvement.
• Access Management: The goal of Access Management is to deny access to
unauthorized users while making sure that authorized users have access to
needed services. Access Management implements security policies defined by
Information Security Management at the Service Delivery Layer. Maintaining
smooth access for authorized users is critical to achieving the perception of
continuous availability. Adopting a service provider’s approach to Access
Management will also make sure that resource segmentation and multi-tenancy
are addressed.
• Systems Administration: The goal of System Administration is to perform the
daily, weekly, monthly, and as-needed tasks required for system health. A mature
approach to Systems Administration is required for achieving a service provider’s
approach and for driving predictability. The vast majority of Systems
Administration tasks should be automated.
2.6 Management Layer
The Management Layer defines the capabilities required to execute and implement the
Operation and Service Layer processes and procedures to support IaaS, PaaS, and SaaS.
These capabilities are incremental moving up through the Infrastructure, Platform and
Software Layers.
Figure 5: Management Layer Components Related to Infrastructure
The components of the Management Layer related to the Infrastructure Layer are:
• Service Reporting: Service Reporting is the mechanism for producing and
delivering performance reports on Service Levels. The system requirements for
5

6. the service reporting toolset should be driven by the service-level requirements
defined by Service-Level Management in the IT Service Layer.
• Service Management System: A Service Management System is a set of tools
designed to facilitate Service Management processes. Ideally, these tools should
be able to integrate data and information from the entire set of tools found in
the Management Layer. It should also be capable of processing and present the
data as needed. At a minimum, the Service Management System should be linked
to the Configuration Management System (CMS), commonly known as the
Configuration Management Database (CMDB), and should log and track
incidents, problems, and changes. It is also preferred that the Service
Management System be integrated with the Service Health Modeling system so
that incident tickets can be auto-generated.
• Service Health Monitoring: The Service Health Monitoring system makes sure
that services meet all service-level targets. This system should be aware of each
component required to provide a service – and its relationship and dependencies
on other components. The Service Health Monitoring system should identify
when a service is approaching a performance threshold or component failure and
either resolve the issue itself or alert Operations.
• Configuration Management System: A Configuration Management System
(CMS) is the definitive hub for collecting, storing, managing, updating, and
presenting data about all Configuration Items (CIs) and their relationships. A CMS
is composed of a number of Configuration Management Databases (CMDBs),
each of which manages a subset of configuration data. A CMS should ideally
integrate and correlate the information from the CMDBs for processing, analysis,
and presentation. The CMS should also have configuration monitoring capability
to identify, report, and repair when configurations fall out of the desired state.
• Fabric Management: Fabric Management is the toolset responsible for
managing workloads of virtual hosts, virtual networks, and storage. Fabric
Management provides the orchestration necessary to manage the life cycle of a
consumer’s workload (one or more VMs that collectively deliver a service;
Microsoft Office SharePoint Portal being one example).
• Deployment and Provisioning Management: Deployment and Provisioning
Management is the toolset used to carry out the processes defined by Release
and Deployment Management in the Operations Layer. Deployment results in
creation or installation of a computer unit or service component in generic,
unequipped fashion; provisioning is the process of applying service-specific and
instance-specific attributes to the deployed resource.
• Data Protection: Data Protection provides the capability to backup and restore
data, hosts, and infrastructure and service components. Data protection policies
should be defined in the IT Service Layer by Service-Level Management and
Information Security Management.
• Network Management: Network Management manages the underlying network
fabric, including VLANs, switch ports, load balancers, and firewall rules. Network
Management also includes a set of network services that support IaaS; for
example, Dynamic Host Configuration Protocol (DHCP), Domain Name System
(DNS), and Pre-Boot Execution Environment (PXE).
• Security Management: Security Management defines and reports on the
security policies (for example, password complexity levels) that apply to the
infrastructure. It provides security services such as a directory, authentication, and
authorization.
As this content series continues each element of the Reference Model will be expanded to
expose the details of each layer resulting in a complete Reference Architecture for Private
Cloud. Note that that Security (which includes identity and access management) is not
represented in the Reference Model. This was not by omission but rather recognition that
the security domain is a cross-cutting concern that influences every aspect of the
architecture. Rather than show a security block with arrows throughout the diagram we
just recognize the cross cutting nature of security on the architecture and will address it in
the Cloud Security Architecture
Private Cloud Security Model - Client Side Security
With private cloud environments, you have three options for client security:
• Secure trusted client. A secure trusted client one that exists on the internal network and
has a security trust relationship with the cloud domain. You would provide appropriate
levels of protection to these client computers by using anti-virus protection, two-factor
authentication, hardware computer security, and integral data protection. Connections to
the private cloud network must be made over a protected communications channel with a
quarantine process to ensure that the client computer has the latest security updates, anti-
virus definitions, personal firewall enabled and so on before being allowed to access the
service endpoints.
• Insecure untrusted client. Here, you do not trust the client computers at all and assume
that every input that you receive from the client is suspect. You then check the input for
type, range, length, and format. Your application design ensures that no sensitive data is
stored locally on the client, which can be a desktop, tablet, mobile device, or even a
browser on a public kiosk computer.
• Secure untrusted client. With this option, you provide as much local security as possible
to the client as with the secure trusted client example. However, you do not set up any
6

7. form of inherent trust relationship between the client and the cloud environment, as
would be explicit with domain membership. Authentication would be through federation
and your cloud-based applications would treat all client input as suspect and thoroughly
check this information before accepting it.
The option for insecure trusted client is not considered further for obvious reasons.
An example of a secure untrusted client would be a laptop with integrated disk encryption, either
hardware or software-based. It would require two-factor authentication to log on, using either a
smart card or fingerprint recognition and would not be domain-joined. Authentication to the cloud
service would also be two-factor and the device might include a geographic locating device to assist
with recovery in case of theft.
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
One area that may change with private and hybrid cloud implementations is domain membership,
which is no longer a pre-requisite if the client uses federated authentication to identify themselves
to cloud –based applications using the cloud directory service as their home realm. It should be
noted that implementing federated authentication on a standalone computer rather than adding that
computer to the domain changes the profile of network services available to the clients.
In reality, most organizations running private cloud environments will probably attempt to secure
their client computers as much as possible. However, as previously discussed, if an attacker can
gain physical possession of a hardware device, your attempts to protect the data on it must be
extremely effective and render the stored data functionally inaccessible. There must certainly be no
inherent degradation of the security of your private cloud environment if a client computer is stolen
and compromised. And if a client computer is stolen and compromised, the effects of this
compromise on your environment must be carefully assessed.
Unfortunately, the only person who is likely to know the difference between a stolen laptop and a
stolen and compromised one will be the attacker. In consequence, you must either be absolutely
sure that a stolen client laptop is as close to an inert lump of plastic and metal from the attacker’s
perspective or that you can rapidly make any changes to your own environment that may be
required (for example, reissuing trusted root certificates and revoking ones on the stolen equipment)
resulting from the possible compromise.
Having a in place auditing policy for the endpoint device is a security best practice. If you use by
example Wyse client device then making a central store to distribute a standard configuration or if
using mobile device then a standard auditing list would be:
What type (Android, Apple, Windows), OS's version and if it's uptodate, Check if it's jailbreaked,
Be sure the equipement lock after a period of time, If an antivirus is available for that mobile device
then be sure it's installed.
Never forget that usually the auditing will take place when you configure the VPN software. If your
customers setup themselft the VPN connection then some VPN softwares allow rule to check the
host if it has an antivirus installed and if it's uptodate. If it's in-house then you can have a control by
restricting the DHCP (like an example there). With all that setup the only way to be more sure the
device is not stolen is by adding a token authentification + NIP (like with RSA key) for the VPN.
Private Cloud Security Model - Platform Security
Having applied effective security to your infrastructure, you can start to examine security at the
platform level. Good platform security is essential for high levels of
application security in the software layer. Unless you have addressed potential attack points
at the platform level, you are potentially compromising security of all your applications. You also
need to consider security between the platform and the infrastructure layers. Figure 1 summarizes
these security considerations.
Figure 1: Private cloud platform security issues
The first part of platform security is at the virtualization level; here you must protect the virtual
machines from each other and from the host computers. The host computers must also be protected
from the virtual machines.
7

8. 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
To achieve high levels of security, you must consider each virtual machine as having its own
defensive perimeter. These defenses will consist of a guest firewall, anti-virus, system policies, and
IPsec-secured communications. In addition, you may also want to apply intrusion detection and
security monitoring on the guest virtual machine, using either an agent-based or agentless
mechanism. In effect, you are applying server security best practice to the virtual machines.
To support the rapid elasticity attribute of private cloud environments, virtual machines are
typically provisioned from templates. As a virtual machine is provisioned, it must have the latest
security updates applied, the anti-virus definitions updated, any policy changes implemented, and
monitoring agents brought up to the latest release. A machine certificate needs to be installed and
IPsec policies applied before bringing the virtual machine online in the production environment.
Virtual networking simplifies this process, as the provisioning system can switch the virtual
machine into a limited access security update virtual network to carry out this updating before
switching it across to the production environment network.
Note: As mentioned in the infrastructure section, if the provider does not have access to the virtual
machines in a PaaS environment, then there needs to be a mechanism for applying security updates
to these virtual machines.
Security updates to the virtual machines should also address other platform components, such as
application frameworks, user experience (UX) services, integration services, queuing services, and
so on. If you are providing PaaS for your consumers, then at the end of this provisioning process,
they should be able to connect to the virtual machines and start developing applications. If you are
providing SaaS, you can start installing your applications and running services.
Data Security
The platform layer also includes access to data services, so you should consider security aspects of
this storage as well. Because of the generalized increased threat levels (not just to private cloud
implementations) it is important that you take the view that all data is accessible, wherever it is
stored. The principle of security through obscurity is well and truly discredited, as attackers with
administrator rights can gain access to all levels of a private cloud environment. If a data bit is
stored, you must assume an attacker can access it. Only the combination of encryption, ACLs,
monitoring and auditing can provide effective levels of security.
Other considerations with data security require you to consider the lifecycle of a data bit. Within
private cloud environments, data bits are not written just to one location on a single hard drive. The
requirement for resilience results in that information being replicated to multiple locations. In
addition, this data may appear on caching disk controllers, in temporary files, or in other stores
through application-level or operating system replication.
Finally, data at rest is always more vulnerable than data in transit. There are technologies that
enable attackers to intercept data in transit between two hosts, but it may not be possible or
practicable to reconstruct that data. In any event, data intercepted in transit can only compromise
that individual transmission, whereas accessing data at rest can provide the entire data set.
Hence data security is a key factor that requires extensive investigation. Although the user
perception of cloud services is that their data is “somewhere out there”, as an operator you cannot
afford to take such a lax view. You must implement strict data security and review where your data
resides from the moment of writing it to disk to the point at which it is scrubbed or encrypted
beyond recovery.
Application Framework Security
Your choice of application framework will depend on the type of applications and the development
environment that your cloud environment will support. Hence, you will need to ensure that you
apply strict standards in terms of what application framework types and versions are available, how
those frameworks can be used, and how you update them.
Development Environment Security
Your provision of development environment may result from your customer requirements or may
be something that you impose as an organizational standard. However, the larger the number of
development environments that you support, the greater the challenge of providing adequate
security.
Whatever development environment you provide, it is important that your consumers implement
best security practices into the applications that they create following the principles of SDL. Factors
such as using appropriate class design to reduce attack surface area, developing robust exception
management, avoiding threading vulnerabilities and so on apply even more in a private cloud
environment. Providing consumers with a sandboxed environment can significantly reduce the
threat from poorly secured code that your customers create.
When tenants deploy their applications, strict application partitioning is essential. Each tenant’s
application must be completely bounded within its environment and not able to access other tenant
applications or data. Any attempts to do so must be detected and that application instance
suspended until you can complete your forensic analysis.
Update Security
Update security in the platform layer shares similar factors as the infrastructure layer. Updates need
to be tested and deployed rapidly while minimizing downtime. Virtualization and virtual machine
snapshots can assist in this process by creating fallback positions so that platform components can
be updated. Private cloud environments simplify this process in that updates to development
environments can be carried out when the development environment is not in use by the consumer.
Again, you must consider the circumstances in which you might not have access to the virtual
machines to make these updates.
Private Cloud Security Model - Service Delivery Security
The purpose of the service delivery layer is to make the services in the private cloud environment
available to the consumer. The service delivery layer also provides
the interface through which consumers can
connect. Capabilities that the service delivery layer provides are:
• Service end-points – provides the connection points to the SaaS, PaaS or IaaS hosted
services.
• Self-service portal – enables consumers to request cloud resources and to return those
resources to the general pool when no longer required.
• Service catalog – lists the services to which consumers can connect.
8

9. • Service provisioning – enables consumers to provision virtual machines, development
environments, or applications.
• Billing – converts service usage into cost values and dispatches bills automatically.
• Service contracts – publishes and maintains a register of SLAs and operating level
agreements (OLAs) for each tenant.
• Metering - accounts for consumers’ usage of cloud resources and sends this information
to the billing capability.
• Service reporting – reports on the service levels actually provided and compares these
levels to SLAs.
As this layer provides the service connection to the consumer, security is a critical issue with all
these capabilities. Figure 1 shows the elements of the service delivery layer that require this
security.
Figure 1: Service Delivery Security
As with the software, platform, and infrastructure layers, the security capabilities of IdAM, data
protection, security monitoring, security management, authentication, authorization, RBAC and
auditing all apply to the service delivery layer.
Connection Security
Connection security is a key element in securing the delivery of services, as consumers will always be accessing
these services using a remote network connection. With private cloud environments, this paper has
highlighted why you should consider the internal network as an untrusted network alongside the
Internet. Hence, all client connections should be treated with the same level of minimal trust.
Establishing a secure connection to a client helps to ensure integrity of the data and makes it more
difficult for an attacker to compromise the data stream. Hence, techniques such as TLS/SSL
encryption using a minimum of 2048-bit public/private key pairs and 128-bit bulk encryption keys
are essential.
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
Authentication is also a key requirement, as your private cloud environment should typically
not be accepting unauthenticated requests. If you have a public web site that accepts
anonymous requests, then this site should be hosted separately by a commercial hosting
provider.
Certificates used for TLS/SSL traffic can be third-party or generated automatically by your
internal CA. Regardless of the process that you use, clients should have the root certificate
stored in their trusted root certification store to prevent error messages on connection. Users
should be trained to be immediately suspicious if they receive a certificate error when
connecting to a private cloud resource.
9

10. Note that if you have implemented an SSL inspection mechanism, then this mechanism can
assist by also providing other validations, such as CA authenticity, certificate revocation list
(CRL) checking, chaining, and other security tests on the certificate.
Connections from the service delivery layer to the software, platform, or infrastructure layer
also need encryption and mutual authentication, typically by use of TLS/SSL or IPsec
encryption.
Service End-Point Security
Even though the role of the perimeter network has diminished in private cloud
implementations, the point at which the consumer connects to the service delivery layer is still
a significant security boundary. Hence, your security defenses should aim to prevent the most
common forms of attack from succeeding.
The security techniques of port and protocol restrictions combined with packet inspections,
traffic analysis, intrusion detection systems, and honey traps are not unique to private cloud
environments; what changes is the degree of automation that is necessary to respond to attacks.
Defenses of any kind are useless if they are not actively protected and the increasing threat
profile from more sophisticated attacks makes passive defense no longer effective in protecting
your environment. Hence your perimeter defenses need to be closely monitored, with
immediate follow-up action on any intrusion.
Authentication, authorization, and audit controls must apply at the point of contact. Links to
federated identity providers must be secure from tampering or interception.
Private Cloud Security Model - Management Security
The management stack contains a range of linked capabilities that provide the ability to manage
the service delivery layers. Typically, these are capabilities to which
the provider connects rather than the
consumer. However, some of the reporting output from the management stack can appear in the
service delivery layer and form the basis for information that the consumer can access.
The provider’s contact with the management layer goes through the same levels of
authentication, authorization, and auditing as the consumer’s approach to the service delivery
layer. Although you might expect that you should be able to trust your administrators more,
their greater levels of control mean that you have to be more aware of what your administrators
are up to and in consequence, can afford to trust them less.
Management Tools
The exact management tools that you use in a private cloud environment will depend on your
organizational policy, operating system and virtualization platforms, training, and personal
preference. Tools with specific security functionality cover the following capabilities:
• Deployment and Provisioning Management
• Capacity Management
• Change and Configuration Management
• Release and Deployment Management
• Network Management
• Fabric Management
• Incident and Problem Management
Authentication, Authorization, Auditing and Role-Based Access Control
The management stack must fully integrate with the highest levels of authentication available
within your private cloud environment. Typically, you would implement two-factor
authentication alongside federation to identity-enable individual management applications
within the cloud.
Management Isolation from User Data
In a fully service-oriented private or hybrid cloud implementation, you treat your
organization’s business units as separate tenants. In consequence, your administrators are a
separate tenant and access rights to other tenants’ data should be restricted.
In consequence, auditing for administrators must look for unexpected behaviors, such as
changing permissions to give access to tenant resources. This response to such incidents
(whether concerning administrator accounts or not) should be gradated, in that an attempt to
view a general document in a particular business unit does not necessarily need to be treated in
the same way as an attempt to access a spreadsheet of company salaries and bonuses owned by
the Finance department. As with any business asset, there should be a sanity check to establish
if the administrator has valid reasons to change permissions on a particular file.
Private Cloud Security Model - Software Security
As the highest level of the private cloud service provision layers, software security brings its
own specific security challenges that are unique to an environment that
hosts live applications. Figure 1 shows these areas
diagrammatically.
10

11. Figure 1. Security in the software layer of the private cloud
Application Security
Application security in private cloud implementations has many commonalities with data
center application hosting. All the usual best practices about making applications secure by
design and secure by default apply equally in the private cloud. However, there are the
following issues that are specific to the cloud.
• Application partitioning. The requirement for a multi-tenant support in private cloud
environments requires strict application partitioning, where provisioned applications
only service requests from users within the provisioning consumer’s organizational
unit or virtual team. Supporting this multi-tenant model requires full integration
between each running application and the authentication and authorization
mechanisms. Typically, authentication would be carried out through federated
identities, using an industry-standard federation model such as Security Assertion
Markup Language (SAML) token exchange.
• Client trust levels. With private cloud implementations, you may not have the same
level of control over client types, operating systems, browser types, update levels and
anti-virus security as with a more tightly-controlled network, particularly if you are
making use of the universal connectivity aspect of cloud provision. In consequence,
applications that you create should validate and constrain all client input by checking
it for type, range, length, and format.
Update Security
Update security in the software layer involves similar considerations to updates in the platform
layer. Again, the deployment flexibility and virtualization features assist with installing
application security updates and rolling back a complete application if an update fails.
Private Cloud Security Model
The private cloud security model uses the same design as the private cloud reference
model but replaces the capabilities with mechanisms for implementing security. Figure
1 shows how these mechanisms tie in to the different layers of the private cloud
reference model.
Figure 1. The Private Cloud Security Model (operations layer not depicted - please
see Private Cloud Reference Model for full reference model coverage)
The remainder of this paper builds up this security model by considering each
component of the private cloud reference model and analyzing the factors that apply
at each layer and stack and includes the following discussions:
• Private Cloud Secuirty Wrapper Functionality
• Infrastructure Security
• Platfrom Security
• Software Security
• Service Delivery Security
• Management Security
• Client Security
• Legal Issues
11