cloud technology_concepts

Cloud Computing Concepts, Technology and Architecture

TUDOR MARIUS COSMIN

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

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 !

CLOUD from A to Z

virtualization

virtualization

storage net

virtualization

storage net

operations

virtualization

storage net

operations

automation

virtualization

storage net

operations

automation

business

virtualization

storage net

operations

automation

business

other virtualization

virtualization

storage net

automation

business


physical servers

operations

virtualization

storage net

business


physical servers

operations

automation

virtualization

storage net


physical servers

operations

automation

business

virtualization

storage net


physical servers

operations

automation

business

So

ftw

are

de

fin

ed

da

tac

en

ter

virtualization

storage net


physical servers

automation

business

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

virtualization

storage net


physical servers

business

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

traditional apps

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

traditional apps

PaaS

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

traditional apps

PaaS SaaS

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

traditional apps

PaaS SaaS

self service portal

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

traditional apps

PaaS SaaS

self service portal

VDI, remote apps

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

traditional apps

PaaS SaaS

self service portal

VDI, remote apps

Offline desktop

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

traditional apps

PaaS SaaS

self service portal

VDI, remote apps

Offline desktop

MDM

virtualization

storage net


physical servers

So

ftw

are

de

fin

ed

da

tac

en

ter

operations

automation

business

Hyb

rid

Clo

ud

traditional apps

PaaS SaaS

self service portal

VDI, remote apps

Offline desktop

MDMEU

C

Module 2 Overview

Cloud Computing Mechanisms

Mapping Cloud Computing Mechanisms to Cloud Characteristics

Combining Cloud Computing Mechanisms

Cloud Security Threats

Cloud Security Mechanisms

Cloud Service Implementation Mediums

Cloud Testing Considerations

Implementing Cloud Delivery Models

Standards for Data Centers

Cloud Computing

Mechanisms

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

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.

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.

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.

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


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.


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.


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.


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.


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.


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.

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.

Failover System

The failover system can make

redundant implementations of the same cloud service available to the

cloud service consumer.

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.

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

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.

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.

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


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.


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.


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.


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

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.


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.

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.

Mapping Cloud

Computing Mechanisms

to Cloud Characteristics

OverviewThe following cloud characteristics were introduced in yesterday session:

Fundamental Cloud Computing:

• On-Demand Usage

• Ubiquitous Access

• Multitenancy

• Elasticity

• Measure Usage

• Resiliency

Mechanisms and Characteristics

Mapping SummaryOn-Demand Usage

• Automated scaling listener

• Pay-to-use monitor

Ubiquitous Access

• Multi-device broker

Multitenancy

• Virtual server

• Resource replication

Measured Usage

• Pay-per-use monitor

Elasticity

• Virtual server

• Automated scaling monitor

• State management database


• Pay-per-use monitor

Resiliency

• Failover system

• State management database


Combining Cloud

Computing Mechanisms

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

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.

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.

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.

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.

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.

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

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

Cloud Security Threats

OverviewThe 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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.


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


In this example, an authorized cloud service consumer abuses it

administrative access to exploit the underlying hardware.

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.

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.

Cloud Security Mechanisms

OverviewThe 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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

The following example

demonstrates a single sign-on mechanism provided by

a cloud.

The details for each step

are provided on the next page.

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.

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.

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.

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.

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.

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.

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.


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.


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.

Cloud Testing Considerations

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

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.

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.

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

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

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.

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.

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.

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.

Implementing Cloud Delivery

Models (Cloud Provider Design

Considerations)

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

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.

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.

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

• As shown on the following page, the typical steps for assembling a PaaSenvironment 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.

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

5. Cloud consumers accesses and work the ready-made environments provided by the PaaS platforms.

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.

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.

Data Center Tier Topology

Awareness

DATA CENTER TIER TOPOLOGY

Tier Classification

Tier IIRedundant Capacity

Components

Tier IIIConcurrentlyMaintainable

Tier IVFault Tolerance

Tier IBASIC

CAPACITY

Tier IIRedundant Capacity

Components

Tier IIIConcurrentlyMaintainable

Tier IBASIC

CAPACITY

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 ;

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;

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;


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.

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;


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;

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;



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;

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;


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 .

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;



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

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;


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.

Tier Requirements Summary

Magnitude of costs between TiersC

ap

ita

l Co

sts

Tier

Significant Cost Difference

Between Tiers II & III

Tier Certification Process

Tier Certification

of Design

Documents

Tier Certification

of Constructed

Facility

Tier Certification of

Operational

Sustainability

Management

and Operations

Stamp of

Approval

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

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 )

Others Tier Aspects

Others Tier Aspects

Site Communications Path

Others Tier Aspects

For all Tiers equipment to be selected and size to meet the extreme maximum

temperatures ;

Fuel System Tier Progression :

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

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 ;

OPERATION SUSTAINABILITY

Operation Sustainability

Uptime Institute Abnormal Incident Report Database

Elements of Operational Sustainability

Management & Operations

Building

Characteristics

Site Locations

Ch

an

ge

Op

po

rtu

nity

Imp

ac

t to

Op

era

tio

ns

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

Building characteristics -

Commissioning

Site location categories

Sample evaluation table – GO/NO

GO criteria

Uptime Standards and Certification

Uptime Standards and TIA-942

Uptime Standards and TIA-942

TIA 942 IS NOT A STANDARDT FOR DATA CENTER DESIGN

TOPOLOGY AND OPERATION

TIA 942 IS A TELECOMMUNICATION STANDARD

THE WORLD HAS CHANGED!

Business Drivers: Organization Agility

“… so even elephants can walk on a tightrope”

Can a Truck Jump a Lotus Formula 1 car ?

https://www.youtube.com/watch?v=TVBcEg6klJI

https://www.youtube.com/watch?v=TVBcEg6klJI

Drifting a 200ton Mining Truck ?

https://www.youtube.com/watch?v=y7K7m7lJHrc

https://www.youtube.com/watch?v=y7K7m7lJHrc

What is the

“CLOUD”

cloud technology_concepts

Presentations & Public Speaking

cloud computing concepts

cloud roles

concepts characteristics

coffee break