2. Timetable
Session 2 - 06 March:
Session 1 - 09 : 15 AM – 11:00 AM
Coffee break – 11:00 AM – 11:20 AM
Session 2 – 11:20 AM – 12:30 PM
3. Session 1 Overview
A Brief History of Cloud Computing
Fundamental Terminology and Concepts
Characteristics of a cloud
Roles and Boundaries
Cloud Delivery Models
Cloud Deployment Models
Benefits of Cloud Computing
Challenges of Cloud Computing
Business Cost Metrics
Service Level Agreements (SLAs)
The world has chaged !
31. Overview
Cloud Computing mechanisms are a common moving parts of a
cloud-based technology architecture that work together to establish a
cohesive function. In this section, we describe the following
fundamental cloud computing mechanisms:
Virtual Server
Ready-Made Environment
Automated Scaling Listener
Failover System
Multi-Device Broker
Pay-Per-Use Monitor
State Management Database
Resource Replication
32. Virtual Server
A virtual server is a form of virtualization software that emulates a
physical computer (a physical server).
Virtual servers are used to establish virtualization environments
(defined previously) that are used by cloud providers to share the
same physical IT resource with multiple cloud consumers.
To a cloud consumer, a virtual server appears as an independent
physical server.
33. Virtual Server
Virtual servers are the most common type of cloud-based IT resource
accessed directly by human-driven cloud service consumers.
Generally, humans access virtual servers for governance purposes to
setup or maintain applications or services that belong to the cloud
consumer.
Note that although a virtual server is always based on a physical server,
diagrams in these courses do not always display the corresponding
physical server symbol.
34. Virtual Server
Virtual servers can host applications that are accessed via separate cloud
services with published contracts. For example, Cloud Service Consumer A
can access the virtual server to deploy and maintain an application that
can then be accessed by Cloud Service Consumer B, via the published
contract of a separate cloud service.
35. Note
The definition of the term “virtual server” can vary depending
on the cloud computing vendor. The term “virtual machine” is
also commonly used, although some vendors make a further
distinction between a virtual machine and a virtual server.
For the purpose of this workshop, the term “virtual server” is
synonymous with “virtual machine”.
36. Ready-Made Environment
A ready-made environment is a pre-defined cloud-based platform
comprised of a set of already installed IT resources, ready to be
used and customized by a cloud consumer.
These environments are used by cloud consumers to remotely
develop and deploy their own services and applications within a
cloud.
Typical ready-made environments include pre-installed IT resources,
such as databases, development tools and governance tools.
37. Ready-Made Environment
A ready –made environment is typically hosted and accessed via a virtual
server. Ready-made environments are most commonly associated with
the PaaS cloud delivery model.
38. Automated Scaling Listener
An automated scaling listener is a service agent that monitors and
keeps track of communication between cloud service consumers
and cloud services for load balancing purposes.
An automated scaling listener is considered a specialized type of
cloud usage monitor.
This listener resides within the cloud, typically near the firewall, from
where it automatically tracks load status information.
39. Automated Scaling Listener
Automated scaling listeners can provide different types of responses to
load fluctuation conditions, for example:
The listener can automatically scale out or scale in IT resources
based on parameters previously defined by the cloud consumer
(commonly referred to as auto-scaling).
The listener can automatically notify the cloud consumer when
loads exceed current thresholds or are falling below allocated
resources. This way, the cloud consumer can choose to adjust its IT
resource allocation.
Note that different cloud provider vendors have different names for
service agents acting as automated scaling listeners.
40. Automated Scaling Listener
In this example, the automated scaling listener scales available IT
resources based on pre-defined settings.
The numbered steps are explained on the next page.
41. Automated Scaling Listener
1. Three cloud service consumers attempt to concurrently access the cloud
service.
2. The automated scaling listener scales out by initiating the creation of three
redundant instances of the cloud service.
3. A fourth cloud service consumer attempts to access the cloud service.
4. The automated scaling listener, which is programmed to allow the use of
up to three instances of the cloud service, rejects the fourth attempt and
notifies the cloud consumer that an attempt was made to exceed the
concurrent usage limit.
5. The cloud consumer accesses the remote administration environment to
adjust the provisioning setup in order to increase the allowable limit of
concurrent cloud service consumers.
42. Failover System
A failover system increases reliability and availability by using established
clustering technology to provide redundant implementations of software
programs.
Failover systems are commonly used for mission-critical programs or for
reusable services that can introduce a single point of failure for multiple
applications.
A failover system can span more than one geographical region so that
each location hosts one or more redundant implementations of the same
IT resource.
43. Failover System
The failover system can make
redundant implementations of the
same cloud service available to the
cloud service consumer.
44. Multi-Device Broker
An individual cloud service may need to be accessed by different types of
cloud service consumers, some of which may be incompatible with the
cloud service’s published service contract.
Disparate cloud service consumers may be differentiated by their hosting
hardware devices and/or may have different types of communication
requirements.
To overcome incompatibilities between a cloud service and a disparate
cloud service consumer, mapping logic needs to be created to transform
(or convert) information that is exchanged at runtime.
45. Multi-Device Broker
Common types of runtime transformation carried out by multi-device
brokers include transformation of:
• transport protocol
• messaging protocols
• storage device protocols
• schemas and data models
46. Pay-Per-Use Monitor
Because cloud consumers can often self-provision cloud based IT
resources, an automated means of monitoring usage is required.
A pay-per-use monitor is a service agent that measures the usage of a
cloud-based IT resource by a given cloud consumer for billing purposes.
The pay-per-use monitor is generally configured to focus on key usage
parameters in order to determine that the pay-per-use contractual
commitments of the cloud consumer are satisfied.
The pay-per-use monitor is considered a specialized type of cloud monitor.
47. Pay-Per-Use Monitor
For example, the pay-per-use monitor can be
positioned as a service agent that tracks usage
to a cloud service.
Based on the generated logs, the charges for
the cloud service consumers are calculated.
The numbered steps are explained on the next
page.
48. Pay-Per-Use Monitor
A cloud consumer requests the creation of a new instance of a cloud service
(1).
The IT resource is instantiated and the pay-per-use monitor receives a “start”
event notification from the resource software (2).
The pay-per-use monitor stores the value timestamp in the log database (3).
The cloud consumer later requests that the cloud service instance be stopped
(4).
The pay-per-use monitor receives a “stop” event notification from the
resourcesoftware (5) and stores the value timestamp in the log database (6).
49. State Management Database
A state management database is a database used to temporarily persist
state data for software programs.
As an alternative to caching state data in memory, software programs
can off-load state data to the database in order to reduce the amount of
runtime memory they consume.
By doing so, the software programs and the surrounding infrastructure are
more scalable.
State management database are commonly used by cloud services,
especially those involved in long-running runtime activities.
50. State Management Database
For example, a cloud
service consumer
working with a ready-
made environment may
pause activity, causing
the environment to off-
load cached state
data.
The details for each
step are provided on
the next page.
51. State Management Database
1. The cloud service consumer accesses the ready-made environment and
requires three virtual servers to perform all activities.
2. The cloud service consumer pauses activity. All of the state data needs to be
preserved for future access to the ready-made environment.
3. The underlying infrastructure is automatically scaled in by reducing the number
of virtual servers. State data is saved in the state management database.
(Note that one virtual server remains active to allow for future logins by the
cloud consumer).
4. At a later point, the cloud service consumer logs in and accesses the ready-
made environment to continue work.
5. The underlying infrastructure is automatically scaled out by increasing the
number of virtual servers and by retrieving the state data from the state
management database.
52. Resource Replication
► Using the technology provided by a virtualization environment, resource
replication mechanisms can be used to replicate entire cloud-based IT
resources themselves.
► A replicated IT resource can be considered a virtualized IT resource that
shares underlying physical resources with another replicated IT resources.
► Therefore, resource replication can be considered the mechanism that
performs the task of virtualizing IT resources.
53. Resource Replication
► The most common form of replicated IT resources the virtual server
that is replicated from a physical server (as shown in the diagram).
► The resource replication mechanism can encompass what is often
referred to as a hypervisor (or virtual machine manager), which
enforces multitenancy at a low level by isolating virtualized IT
resources.
► For example, a hypervisor can independently manage and monitor
the virtualization of multiple virtual servers and the image of each
virtual server can be persisted via a cloud storage device.
See the diagram on the following page for an example.
54. Resource Replication
A cloud resource
administrator first configures
the hypervisor to store
virtual server images via a
storage device.
Upon a request of a cloud
service consumer to access
a cloud service hosted by
one of the virtual servers,
the hypervisor uses resource
replication to provide the
virtual server image for use
by the cloud service
consumer.
55. Storage Devices & Mechanisms
Another common type of mechanism in cloud environments is the
cloud storage mechanism, which represents a category of specialized
mechanisms and devices .
For the purpose of this course module, databases and other forms of
storage devices are not defined and explored as cloud computing
mechanisms. The one exception is the state management database
mechanisms covered previously in this section.
60. Overview
► Cloud computing mechanisms are commonly combined to create custom
cloud-based solutions.
► Understanding cloud computing technology therefore requires an
understanding of fundamental mechanisms and how they can relate to each
other.
► This section describes the following two examples of mechanism combinations:
- Cloud Balancing
(automated scaling listener + failover system).
- Cloud Bursting
(automated scaling listener + resource replication).
61. Cloud Balancing
► Cloud balancing is a form of dynamic routing whereby a cloud service
consumer’s request is redirected to one of several redundant IT resources
located on different clouds.
► The most common use of cloud balancing is for load balancing purposes,
to increase the performances and scalability of IT resources beyond what
can be guaranteed by a single cloud environment.
► Cloud balancing can also be used to increase the availability or reliability
of an IT resource, especially when the clouds are geographically
distributed.
62. Cloud Balancing
► Other custom variations of the routing criteria used for cloud balancing
can be created. For example, the routing logic can be based on business
or environment factors.
► To achieve cloud balancing the automated scaling listener and failover
system mechanisms can be combined. (See the example scenario on the
following page).
► For cloud balancing purposes, a special type of automated scaling
listener is used as this mechanism needs to be aware of the redundant
implementations of IT resources and any special criteria or algorithm it
needs to perform the runtime routing of messages from cloud service
consumers.
63. In this scenario, the automated scaling listener is located in a separate
cloud from the redundantly deployed cloud services. Alternatively, the
automated scaling listener cloud be located together with one of the
redundant cloud service implementations.
64. Cloud Balancing
► Depending on the solution architecture, cloud balancing can be
established by either redundantly deploying IT resources in advance
or by configuring cloud environments to dynamically generate
redundant instances of IT resources on-demand.
► The Cloud Resource Administrator is typically responsible for ensuring
that the redundantly deployed cloud services are kept synch with
each other, either manually or via the use of a cross-cloud resource
replication mechanism.
65. Cloud Bursting
► Cloud bursting is a form of dynamic scaling whereby on-premise IT
resources can scale (or “burst”) into a cloud when pre-defined thresholds
are reached.
► The corresponding cloud-based IT resources are redundantly pre-deployed
on the cloud but are not active or idle until an actual cloud burst occurs.
After they are used, they are released and return to an inactive state.
► Cloud bursting is a flexible scaling model whereby the cloud consumer can
continue to maintain on-premise IT resources and only needs to use (and
pay for) cloud based IT resources when required by usage demands.
66. Cloud Bursting
► Cloud bursting can be achieved by combining the automated scaling
listener and resource replication mechanisms.
► As shown in the scenario on the following page:
- The automated scaling listener determines when to redirect requests to
cloud-based IT resources
- Resource replication is used to maintain synchronicity between on-premise
and cloud–based IT resources, especially in relation to state information
67. Cloud Bursting
In this scenario, the automated scaling listener is deployed at the cloud
consume premises, but is designed to interact with an external cloud in
order to carry out cloud bursts.
1- when Service Consumer
C tries to access Service A,
the automated scaling
listener determines that the
threshold has been
exceeded ant therefore
redirects the request to
Cloud Service A, witch is
dynamically instantiated
2- resource replication is
used to keep the state
information used by Service
A and Cloud Service A in
sync
69. Overview
The following is a list of common security threats encountered by service-
based technology architectures:
Data-Oriented Threats
• Buffer Overrun
• Information Leakage
• XML Parser Attack
• Malicious Intermediary
Access-Oriented Threats
• Denial of Service
• Virtualization Attack
• Insufficient Authorization
• Overlapping Trust Boundaries
70. Overview
► Although all of the aforementioned threats apply to public, private and
community clouds, they are most prevalent with public cloud
environments.
► A fundamental an common concern with all of the threats explained in the
upcoming sections is that a successful attack on IT resources within a public
cloud can impact multiple cloud consumers sharing those IT resources.
► This overarching consideration magnifies the importance of building cloud
technology architectures with preventative security measures.
71. Overview
In the upcoming sections, two types of attacking cloud service consumers are
referenced:
• The anonymous attacker, with is a non-trusted cloud service consumer
without permission in the cloud. (Represented by a red-colored software
program symbol with a red bolt).
• The legitimate cloud service consumer that is trusted and has permissions
within the cloud, but still poses a threat. (Depicted as by a blue software
program symbol with a red bolt).
72. Malicious Intermediary
► The malicious intermediary threat arises when messages being sent from a
service consumer are intercepted and altered by an intermediary service
(or service agent) with malicious logic.
The intermediary may compromise the messages confidentiality and/or
integrity.
The intermediary may also insert harmful data into the message before
forwarding it to its destination.
A variation of this attack, known as Traffic Eavesdropping, involves a
malicious service agent that only listens to but does not alter message
contents.
73. Malicious Intermediary
In this example, a malicious service agent (acting as the intermediary)
accesses and modifies a message by inserting harmful data. It then forwards
the message to the cloud where it successfully damages a virtual server.
74. Denial of Service
► In a Denial of Service attack, the attacker causes increased loads on hosting
servers and/or the network by overloading them with external
communication requests.
► As a result, the servers become either unavailable or response times
degrade considerably.
► This attack can also be performed by engaging the server (or a software
program that it is hosting) in a task that results in excessive memory and
processor usage.
► As a result, the server may become unavailable while it attempts to process
the malicious requests.
75. Denial of Service
► In a cloud environment, the attack of shared IT resources can compromise
the runtime performance of all the cloud service consumers that access or
rely on the IT resources.
► Alternatively, malicious cloud service consumers can target IT resources to
attack specific cloud consumers only.
► Furthermore, when a pay-per-use mechanism is in place, a denial of service
attack can target IT resources leased to a specific cloud consumer being
charged for the extra usage.
76. Denial of Service
In this example, two cloud
service consumers are
accessing virtual servers
hosted by the same
underlying physical server.
The virtual server being
attacked by Cloud Service
Consumer A generates too
much load upon the
physical server, resulting in
the virtual server being
used by Cloud Consumer B
becoming unavailable.
77. Insufficient Authorization
► The insufficient authorization attack occurs when access is granted to an
attacker erroneously or too broadly, resulting in the attacker getting access
to IT resources that are normally protected.
► This is often a result of the attacker gaining direct access to IT resources
that were implemented under the assumption that they would only be
accessed by trusted consumer programs.
► A variation of this attack, known as weak authentication, can result when
weak passwords or shared accounts are used to protect IT resources.
► Within cloud environments, these types of attacks can lead to significant
impacts depending on the range of IT resources and the range of access
to those IT resources that attacker gains.
78. Insufficient Authorization
The following example illustrates an attacker (Cloud Service Consumer A)that
gains access to a database that was implemented under the assumption
that it would only be accessed through a Web service with a published
service contract (as shown by Cloud Service Consumer B).
79. Insufficient Authorization (Weak
Authentication)
In this example, an
attacker has cracked
a weak password
used by Cloud Service
Consumer A.
As a result , a
malicious cloud
service consumer
(owned by the
attacker) is designed
to pose as Cloud
Service Consumer A in
order to gain access
to the cloud-based IT
resource.
80. Virtualization Attack
► As explained in Module 1, virtualization technologies are employed to
serve multiple cloud consumers in a multi-tenancy model.
► This model can lead to attacks on physical IT resources by both trusted
and non-trusted cloud service consumers.
► With public clouds, where a single physical IT resource may be providing
virtualized IT resources to multiple cloud consumers, such an attack can
have significant repercussions.
81. Virtualization Attack
► There is the danger that malicious cloud service consumers can find a way
to bypass authentication mechanisms imposed by virtual IT resources, in
order to gain unauthorized access to cloud-based physical IT resources.
► Because clod providers grant cloud consumers administrative access to
virtualized IT resources (such as virtual servers), there is an inherent risk that
cloud consumers could abuse this access to attack the underlying
physical IT resources.
82. Virtualization Attack
In this example, an authorized cloud service consumer abuses it
administrative access to exploit the underlying hardware.
83. Overlapping Trust Boundaries
► If physical IT resources within a cloud are shared by different cloud service
consumers, these cloud service consumers have overlapping trust
boundaries.
► Malicious cloud service consumers can target shared resources with the
intention of compromising cloud consumers or other IT resources that share
the same trust boundary.
► The consequence is that some or all of the other cloud service consumers
could be impacted by the attack and/or the attacker could use virtual IT
resources against other internal cloud-based IT resources that happen to
also share the same trust boundary.
84. Overlapping Trust Boundaries
In the following example,
Cloud Service Consumer A
and B share virtual servers
hosted by the same physical
server and their respective trust
boundaries overlap.
Cloud Service Consumer A is
trusted by the cloud and
therefore gains access to its
virtual server which it then
attacks with the intention of
attacking the underlying
physical server and the virtual
server used by Cloud Service
Consumer B.
86. Overview
The following is a list of common security mechanisms used to secure service-
based technology architectures:
Data-Oriented Security Mechanisms
• Encryption
• Hashing
• Digital Signatures
Access-Oriented Security Mechanisms
• Identity and Access Management (IAM)
• Public Key Infrastructure
• Digital Certificates, Certificate Authority
• Single Sign-On
• Cloud–based Security Groups
• Hardened Virtual Server Images
87. Encryption
► Encryption is a means by which confidentiality can be realized.
► The field of encryption is called cryptography.
► Information that is not encrypted is referred to as plaintext or cleartext.
► Information that is encrypted is referred to as ciphertext.
► An encrypted message is rendered unreadable except by those in
possession of a secret.
► The secret is typically in the form of a key.
88. Encryption
The use of encryption ensures that the
privacy of a message remains protected
during transit, even while in the possession
of intermediary service agents and
services.
Encryption of sensitive data is typically
supported by cloud providers and is
commonly used to help protect remote
message exchanges between cloud
service consumers.
The malicious intermediary is unable to
compromise the confidentiality of the
message data because it is encrypted.
89. Due to overlapping trust boundaries, encrypted messages received by
external cloud service consumers can remain protected via encryption within
cloud environments until they reach their final destinations. Also, data
exchanged or stored by internal cloud-based IT resources can be protected
via encryption.
Cloud Service Consumer A
attacks the cloud with the
intention of stealing message
data.
However, the attack is
unsuccessful because all the
messages exchanged within
the cloud (even between
virtual servers) are encrypted.
90. Encryption
The encryption mechanism helps mitigate the following threats:
• Malicious Intermediary – The confidentiality of message data received by
intermediaries is protected.
• Insufficient Authorization – If the intention of the attacker is to steal sensitive
data, encryption will protect the data’s confidentiality.
• Overlapping Trust Boundaries – Encryption can be applied to data
exchanged or residing within overlapping trust boundaries, thereby
preventing access by attackers that target these trust boundaries.
91. Digital Signatures
► Digital signatures are a means of realizing authentication and integrity:
- Authentication: Who signed the message?
- Integrity: Has the message been altered since it was signed?
► A digital signature is data that proves that:
- a message was sent by the intended sender
- a message was not altered
► Digital signatures use encryption and hashing technologies.
92. In the following example, a malicious intermediary inserts harmful data into a
message. However, the message is rejected by the cloud because it contains
a digital signature that was used to detect that the message had been
altered since it was originally sent by the cloud service consumer.
93. In this example, malicious cloud consumer has altered the message by
accessing the message from within the cloud. Because the message was
digitally signed it enables the virtual server to still detect that its contents were
altered.
As a result the message is rejected before it can do any harm.
94. Digital Signatures
The digital signature mechanism helps mitigate the following threats:
• Malicious Intermediary – the integrity of message data received by
intermediaries is protected.
• Insufficient Authorization – If the intention of the attacker is to alter
message data, the use of digital signatures provides a means by which
alterations can be detected.
• Overlapping Trust Boundaries – Digital signatures can be used for
messages exchanged within overlapping trust boundaries and between IT
resources.
95. Identity and Access Management
(IAM)
► Just about any security infrastructure will require a repository (referred to as an
identity store) that houses the identity information used by programs to carry out
authentication and authorization upon receiving credentials.
► An identity and access management (IAM) system establishes a central identity
store along with roles and access control rules for the defined identities (as well
as various tools used to administer the identities and rules).
► The cloud provider will typically pre-define a set of identities and related roles
and access control rules that are enforced for a given set of IT resources.
► An IAM is fundamental to cloud security in that it provides the means by which
the cloud and/or its IT resources can perform authentication and authorization.
96. Identity and Access Management
(IAM)
The identity and access management mechanisms helps mitigate the
following threats:
• Denial of Service – Attackers cannot execute denial of service attackers
unless they can gain access to a cloud or its IT resources.
• Insufficient Authorization – Although this threats can still exist when the IAM
mechanism is poorly implemented, the proper use of the IAM will help
counter this threat.
• Overlapping Trust Boundaries – Enforcing identity and access roles helps
avoid the exploitation of overlapping trust boundaries.
97. Single Sign-On
► Propagating the authentication and authorization information for a cloud
service consumer across multiple cloud services can be a challenge,
especially if multiple cloud services or cloud-based IT resources need to be
invoked as part of the same overall runtime activity.
► The single sign-on mechanism enables one cloud service consumer to be
authenticated by a security broker, which establishes a security context
that is persisted while the cloud service consumer accesses other cloud
services or cloud-based IT resources.
► Otherwise, the service consumer would need to re-authenticate itself with
every subsequent request.
98. The following example
demonstrates a single sign-
on mechanism provided by
a cloud.
The details for each step
are provided on the next
page.
99. Single Sign-On
1. The cloud service consumer sends its authentication credentials to the
security broker.
2. After successful authentication, the security broker responds with an
authentication token (represented by the dark colored message
symbols).
3. The cloud service consumer accesses other cloud services or cloud-
based IT resources with the authentication token.
100. Single Sign-On
► The single sign-on mechanism is commonly used by public cloud providers
to establish a security broker that supports single sign-on for multiple IT
resources within the same cloud.
► The single sign-on mechanism relies on the identity and access
management mechanism to provide am identity store that is used by the
security broker.
► The single sign-on mechanism does not directly counter any of the
previously described threats.
101. Cloud-based Security Groups
► Network segmentation is an established approach for improving security
within a network by splitting the network into a series of sub-networks.
► Due to the need for cloud consumers to establish overlapping trust
boundaries, network segmentation is not applicable in cloud
environments.
► An alternative approach suitable for cloud environments is the use of
cloud-based security groups.
102. Cloud-based Security Groups
► With cloud-based security groups, the separation of network segments is
performed logically (not physically).
► Each IT resource becomes a member of one or more logical security
groups.
► Each group is assigned specific rules that govern how and with what it is
allowed to communicate.
► Because the separation is logical, multiple virtual servers running on the
same physical server can be members of different logical network
segments.
► For example, the virtual servers can be separated into public and private
groups (segments)or development and production groups.
103. In this example,
two cloud–based
security groups for
Cloud Service
Consumers A and
B are established.
Each IT resource
can only
communicate
with other IT
resources in the
same security
group.
104. Cloud-based Security Groups
The cloud-based security group mechanism helps mitigate the following
threats:
• Denial of Service - Attackers may find it more difficult to successfully carry
out this attack and even when they do, the security groups can prevent its
proliferation within the cloud.
• Insufficient Authorization - Because security groups restrict IT resource
communication, attackers that breach the perimeter authentication and
authorization mechanisms may still be challenged when attempting to
compromise IT resources.
• Overlapping Trust Boundaries - This mechanism directly counters the
vulnerabilities resulting from overlapping trust boundaries.
105. Hardened Virtual Server Imagines
• Virtual servers mirror a template configuration established on an underlying
physical server.
• This standard configuration is often called a virtual server image (or virtual
machine image) and forms the basis for all virtual servers created from this
image.
• Hardening is the security practice of trimming away unnecessary software
programs and functions in order to minimize potential security vulnerabilities.
• A hardened virtual server image therefore establishes a template for virtual
servers that is inherently more secure.
The symbol used to represent a hardened virtual server image.
106. Hardened Virtual Server Imagines
Common means by which hardening can be applied to virtual servers:
• Minimize the functions that the virtual server can perform.
• Enable only those operating system services and user accounts that are
necessary to support the virtual server's functions.
• Ensure that configuration files used by the virtual server have the most
secure settings.
• Ensure that operating system services on the virtual server are configured to
run under a user account that has no administrator rights.
107. Hardened Virtual Server Imagines
The hardened virtual server image mechanism helps mitigate the following
threats:
• Denial of Service - The less functionality provided by a virtual server, the less
opportunity for an attacker to overload the virtual server.
• Insufficient Authorization - If an attacker breaches a virtual server due to
inadequate authentication or authorization, there is less opportunity to perform
harmful actions due to a lower quantity of available functions.
• Overlapping Trust Boundaries - Hardened virtual servers are not as easily
compromised by attackers attempting to exploit overlapping trust boundaries.
109. Overview
• Testing cloud-based IT resources is essential, especially for those
that will be positioned as shared cloud services.
• Cloud providers are responsible for testing the IT resources in the
clouds they own and govern.
• Cloud consumers may also need to test cloud- based IT resources
prior to enrolling with a cloud provider in order to assess the quality and
compatibility of cloud services first-hand (and to validate the
guarantees made in the SLAs).
110. Black Box and White Box Testing
• There are two types of established testing practices:
- black box testing
- white box testing
• Black box testing refers to a technique where testers assess the
functionality of an IT resource without visibility into how the functionality
is provided.
• White box testing refers to a technique where the testers have
complete visibility into how the functionality of the IT resource is
provided.
111. Availability and Reliability Testing
Because testing is related to and often planned around the SLA of a
given cloud-based IT resource, the primary areas of testing are focused
on the following characteristics:
• availability
• reliability
• performance
• security
The extent to which these characteristics can be tested by cloud
consumers depends on the type of cloud delivery model being used.
112. Availability and Reliability Testing
• For example, because white box testing is possible with laaS and PaaS
environments, all characteristics can, to certain extents, be measured.
• However, because only black box testing is generally allowed for
SaaS offerings, it can be difficult to fully test the availability and reliability
of cloud-based IT resources.
• For all three delivery models (but especially for SaaS), cloud
consumers have to rely on SLA guarantees provided by the cloud
provider.
• This is because inspection over a long period of time is essential to
collecting valid reliability and availability statistics (and this is information
collected by the cloud provider).
113. Additional Testing Areas
In addition to whatever extent of availability and reliability testing is
possible, cloud consumers typically also focus on the following testing
areas:
• performance testing
• stress testing
• integration testing
114. Performance Testing
• Performance testing is focused primarily on the speed and
responsiveness of an IT resource.
• Performance testing is usually carried out with a black box testing
approach that involves the use of automated testing software (to simulate
various high-demand scenarios).
• With the cooperation of the cloud provider, the cloud consumer can
subject cloud-based IT resources on a public cloud to various
performance tests.
115. Stress Testing
• Stress testing is focused primarily on the stability and reliability of an IT
resource when subjected to loads beyond its allocated capacity.
• As with performance testing, stress testing is also generally carried out
with a black box testing approach that may involve automated testing
software.
• In addition to testing how an IT resource handles overload conditions
(and related exceptions), stress testing can help further test cloud-based
mechanisms, such as the automated scaling listener, to ensure that
scaling-related behavior occurs as expected.
116. Integration Testing
• Integration testing is focused on verifying the functionality, reliability
and runtime performance of two or more aggregated IT resources.
• For example, a service composition comprised of an on-premise
service and a cloud service would undergo integration testing to ensure
that the two services can adequately interact.
• Integration testing is traditionally carried with some extent of white box
testing, depending on the cloud delivery model being used.
117. Integration Testing
In this example, three different
cloud service consumer programs
are being integration tested against
the Reports cloud service, which is
an SaaS product.
The Reports cloud service itself relies
on the Client and Invoice services
that are also hosted within the
cloud.
If the cloud consumer is not aware
of the existence of the Client and
Invoice services, then its integration
testing efforts may be limited to the
black box testing approach.
119. Overview
The following topic areas are covered in the upcoming pages:
• Assembling an laaS Environment
• Assembling a PaaS Environment
• Implementing an SaaS Product
• Combining Cloud Delivery Models
• laaS + PaaS
• laaS + PaaS + SaaS
120. Assembling an IaaS Environment
• An laaS environment is the simplest deployment model to implement
because the cloud provider is responsible only for providing IT resources
comprised of raw infrastructure.
• The effort lies with the cloud consumer to set up, configure, and
operate the laaS environment.
• As shown on the following page, the typical steps for assembling an
laaS environment are comprised of allocating physical servers, installing a
virtualization environment, and providing virtual servers that can be
leased by the cloud consumer.
121. Assembling an IaaS Environment
The steps :
1. The cloud provider deploys or
allocates physical servers (along
with software that establishes a
virtualization environment).
2. The cloud provider creates the
necessary self- provisioning virtual
servers.
3. The cloud consumer arranges
the leasing of the virtual servers with
the cloud provider.
4. The cloud consumer uses the
leased virtual servers.
122. Assembling a PaaS Environment
• As explained in Module 1, it is the implementation ot the ready-made
environment mechanism that primarily defines and distinguishes the PaaS
delivery model.
• As shown on the following page, the typical steps for assembling a PaaS
environment include steps similar to assembling an laaS environment.
• Subsequent to the allocation of the servers, the cloud provider must also
establish a ready-made environment, pre-configured for use by the cloud
consumer.
• Note that the upcoming steps assume that the cloud provider is making
PaaS available via virtual servers. Alternatively, dedicated physical servers can
also be used.
123. Assembling a PaaS Environment
The steps :
1. The cloud provider deploys or
allocates physical servers with operating
systems (along with software that
establishes a virtualization environment).
2. The cloud provider deploys a
necessary amount of virtual servers
3. The cloud provider deploys ready-
made environments on the virtual servers
and enables self-provisioning of these
environments.
4. Cloud consumers lease the PaaS
platforms.
5. Cloud consumers accesses and work
the ready-made environments provided
by the PaaS platforms.
124. Implementing a SaaS Product
• As explained in Module 1, the SaaS delivery model enables the
provisioning of a cloud service as a commercial product that can be
publicly accessed and used for a cost.
• As shown on the following two pages, the common steps for
implementing an SaaS product involve steps that are similar to assembling
PaaS and laaS environments.
• Although the upcoming diagram depicts an SaaS cloud service as
being hosted by one virtual server and one physical server, the actual
scope and quantity of the underlying server resources can vary
dramatically, depending on the usage demands and scalability
requirements of the cloud service.
125. Implementing a SaaS Product
The steps :
1. The cloud provider installs or
allocates the one or more necessary
physical servers (along with software that
establishes a virtualization environment).
2. The cloud provider deploys a one or
more necessary virtual servers.
3. The cloud provider installs an
already developed cloud service that is
being offered as a SaaS product and
enables self-provisioning.
4. Cloud consumers purchase access
to the SaaS product from the cloud
provider.
5. Cloud consumers access and use
the SaaS product.
129. Tier I – Basic Capacity
Requirements:
Non-redundant capacity components and a single, non-redundant distribution path;
Space, Power, and Cooling Systems allocated for Critical Environment;
12 hours of on-site fuel storage for engine generator(s);
Operations and Maintenance Considerations :
Site infrastructure and Critical Environments must be shut down for annual maintenance
and repair work;
Installation or construction of capacity may disrupt the Critical Environment;
Operational Risks :
Any capacity component or distribution path element failure will disrupt the Critical
Environment;
All or portions of the Critical Environment are susceptible to disruption due to planned and
unplanned activities;
Operations (Human) errors have high likelihood of site disruption;
Deferred maintenance to avoid downtime increases the risk and severity of disruptions in
the Critical Environment ;
130. Tier I – Basic Capacity
Appropriate for firms such as:
Small businesses where information technology primarily enhances
internal business process;
Companies whose principal use of a web-presence is as a passive
marketing tool;
Internet-based start-up companies without finically enforceable
customer quality-of-service commitments;
131. Tier II – Redundant Components
Operational Risks :
All or portions of the Critical Environment are susceptible to disruption due to planned
and unplanned activities;
Operations (human) errors have high likelihood of site disruption;
Deferred maintenance to avoid downtime increases the risk and severity of
disruptions in the Critical Environment;
Appropriate for firms such as:
A call centers where multiple sites are available;
Internet-based companies without serious financial penalties for quality-of-service
commitments ;
Small businesses whose information technology requirements are mostly limited to
traditional normal business hours, allowing system shutdown during off hours;
Scientific research, e.g., chip design, oil exploration, seismic processing, or long-term
weather modeling, which typically does not have to provide online or real-time
service deliveries.
132. Tier II – Redundant Components
Requirements:
Redundant capacity components (N+R) (Engine generators, UPS modules and IT & UPS
cooling;
Single distribution path;
12 hours of on-site fuel storage for “N” capacity;
Operations and Maintenance Considerations :
Some capacity components can be maintained or repaired with limited impact to the
Critical Environment;
Site infrastructure and Critical Environments must be shut down for annual maintenance
and repair work;
Installation or replacement of capacity components may disrupt the Critical Environment;
Operational Risks :
Any capacity component or distribution path element failure will disrupt the Critical
Environment;
A distribution path element failure will disrupt the Critical Environment;
133. Tier III – Concurrently Maintainable
Requirements:
Redundant capacity components and independent distribution paths;
Elements of a distribution path may be inactive;
Predicated on Fault Tolerant (dual-cord) IT equipment;
No runtime limits on engine-generator capacity at design load;
12 hours of on-site fuel storage for “N” capacity;
Operations and Maintenance Considerations :
Each and Every capacity component and distribution path element can be taken
out of service for maintenance, repair, or replacement without impacting the Critical
Environment or IT processes;
Single Points-of-Failure are not eliminated;
Operational Risks :
All or portions of the Critical Environment are susceptible to disruption due to failures
or unplanned activities;
134. Tier III – Concurrently Maintainable
Operational Risks :
Scheduled maintenance activities occur on redundant components, distribution
paths, and systems—which will reduce redundancy and may elevate risk of
disruption;
Operations (human) errors may lead to site disruption ;
Single-cord IT equipment or incorrect installation may defeat Tier Ill infrastructure;
Appropriate for firms such as:
Companies that support internal and external clients 24×7, such as service centers
and help desks, but where short periods with limited service due to a site failure can
be acceptable;
Businesses that have IT resources that support automated business processes, so the
impact on clients of system shutdowns can be managed or accepted ;
Companies that span multiple time zones with clients and employees spanning
regional areas ;
Internet-based companies or co-location providers that have quality-of-service
commitments with serious financial ramifications .
135. Tier IV – Fault Tolerant
Requirements:
Redundant, physically isolated (Compartmentalization)
Redundant capacity components
Redundant independent active distribution paths
Continuous Cooling for critical IT and UPS systems;
Autonomous response (N after any failure);
No runtime limits on engine-generator capacity at design load;
12 hours of on-site fuel storage for “N” capacity;
Operations and Maintenance Considerations :
Each and Every capacity component and distribution path element can sustain a failure, error,
planned, or unplanned event without impacting the Critical Environment or IT processes;
Single event with consequential impact;
Design considerations for Continuous Cooling are consistent with UPS for IT equipment
power;
Tier IV protects against some human errors except for
Accidental EPO activation
Intentional sabotage
136. Tier IV – Fault Tolerant
Operational Risks :
The Critical Environment is not susceptible to disruption due to failure of any single capacity
component, distribution element, site infrastructure system, or single human error;
Scheduled maintenance activities occur on redundant components, elements, and
systems which may create a risk of disruption;
Operation of the EPO system, activation of the fire protection system, or malicious human
interaction may lead to site disruption;
Single-cord IT equipment or incorrect installation may defeat Tier IV infrastructure;
Appropriate for firms such as:
Companies with an international market presence delivering “24 by forever” services in a
client-facing market space where there is high competition or where processes are
continuous (international in-and outbound wire transfers, etc.);
Business that are based on financial settlement processes, market transactions, or E-
commerce;
Large, global companies where client access to applications and employee exploitation
of information technology is a competitive advantage;
Internet-based companies or co-location providers that have to commit to quality-of-
service and would have serious financial ramifications.
138. Magnitude of costs between TiersCapitalCosts
Tier
Significant Cost Difference
Between Tiers II & III
139. Tier Certification Process
Tier Certification
of Design
Documents
Tier Certification
of Constructed
Facility
Tier Certification of
Operational
Sustainability
Management
and Operations
Stamp of
Approval
140. Others Tier Aspects
NO direct relationship between N" and Tiers ;
N+R or 2N does not guarantee functionality;
For Tier III and IV, engine-generator systems are considered the source of reliable
power for the data center (utility power is an economic alternative);
The utility power system does not have to be Concurrently Maintainable
Multiple utility feeds for redundancy are NOT required for any Tier ( multiple utility
feeds may be required for capacity) ;
Engine generators major components refer to :
Bulk Fuel Storage Tanks
Fuel piping
Day Tanks or Belly Tanks
141. Others Tier Aspects
No Tier requires engine generators to operate all the time;
Tier Ill and Tier IV engine-generator capacity is based on manufacturers'
Continuous Rating (Standby and Prime ratings acceptable for Tier I and
Tier II);
Tier IV requires physical isolation to prevent a single event from
simultaneously impacting more than the number of redundant
components or systems ; Each compartment shall contain no more than
the number of redundant components (Where there are N+R
components, no more than R components inside a single room )
144. Others Tier Aspects
For all Tiers equipment to be selected and size to meet the extreme maximum
temperatures ;
Fuel System Tier Progression :
145. Others Tier Aspects
Fuel system tier criteria
Tier Ill requires that the Critical Environment must NOT be
impacted by any fire detection/suppression component taken
out of service for calibration, repair, or replacement on a
scheduled basis
146. Others Tier Aspects
Operator intervention shall NOT he required to respond to single system failure ;
All Tier levels require that each and every critical component is uniquely labeled ;
149. Elements of Operational Sustainability
Management & Operations
Building
Characteristics
Site Locations
ChangeOpportunity
ImpacttoOperations
150. Elements of operational sustainability
Management & Operations
•Staffing and Organization
•Maintenance
•Training
•Planning, Coordination and Management
Building characteristics
•Building features
•Infrastructure
•Operating conditions
•Pre-Operational
Site Locations
•Natural disasters
•Man-Made disasters
