- In this lesson, 10.3, we're gonna focus in
on the cloud infrastructure.
As a refresher, when we previously talked about cloud,
we define cloud computing as a delivery
of computing services over the internet, the cloud,
that scale to business needs.
Now, in the last lesson,
we talked about four cloud deployment models
and three cloud service models.
In this lesson, we're gonna look
at five defining characteristics
of the cloud infrastructure, on demand self-service,
broad network access, resource pooling,
rapid elasticity, and measured service.
So let's go through each
of those five defining cloud characteristics.
On-demand self-service means
that the customers can unilaterally
provision computing capabilities as needed,
really, automatically.
Broad network access is
that we can have a variety of heterogeneous,
thin or thick client platforms that access the cloud.
Resource pooling is really about all
of the resources that are available
in the cloud environment,
that the provider's computing resources are pooled together
to serve multiple consumers using a multi-tenant model
with different physical and virtual resources.
And we have location independence and location abstraction,
whether that's country, state, or the data center.
We'll be talking more
about resource pooling in just a moment.
Rapid elasticity is all about adapting
to the changing workload demand by auto provisioning
and de-provisioning these pooled resources
to match the current demand, right?
So our cloud provider has all of these resources, right?
Virtual and logical resources.
And in rapid elasticity,
constantly kind of moving resources around, right,
to meet the demand of the customers.
And then measured service really refers
to metering capability.
And that's particularly important
in environments where there's chargeback or pay per use.
Now the cloud infrastructure itself is comprised
of two layers, a physical layer and a virtual layer.
Sometimes that virtual layer is referred to
as an abstracted layer.
Now the physical layer really has all
of the components that build the cloud's resource pool,
processors, memory, connectivity, and storage.
And the virtual or the abstracted layer, right,
is where we kind of pool those resources together
and divide them up.
So all clouds utilize some form of virtual networking
to abstract that physical network
and create a network resource pool.
Now, typically,
the cloud user will provision desired networking resources
from that pool,
which can then be configured, right, within the limits
of whatever virtualization technique is being used.
So how do we handle security?
We've got cloud security groups
that form these logical network parameters.
Now each cloud resource is going to be assigned
to at least one logical cloud-based security group.
Each logical cloud-based security group is going
to be assigned specific rules
that govern the communication between the security groups.
Those rules are gonna function
at the TCP and IP layers, really, in regard to ports,
and then source and destination IP addresses.
Now, often in the cloud,
what we're gonna find are containers.
Containers offer this logical packaging mechanism
in which applications can be abstracted
from the environment in which they run.
Now, containers can virtualize CPU, memory, storage,
network, and resources at an operating system level,
and sometimes referred to as being lightweight.
Now, containers give developers the ability
to create these really predictable environments
that are isolated from other applications.
The term container orchestration really refers
to the process of managing how containers are created
and how they are connected.
Now, a open source platform
that you may have heard of that is used to deploy
and manage virtualized containers is Docker.
And a really interesting one to get to know.
And if you wanna know how popular containers are,
well, from Gmail to YouTube to search,
everything at Google runs in containers.
So let's look at some geographic concepts related
to the cloud environment.
And bear in mind,
this whole lesson is just really high level,
sort of conceptual things
that happen in the cloud environment.
We could spend an entire 40 hours, 80 hours,
120 hours, just talking about the design, you know,
of the cloud environment
and how it's really structured and architected.
So we think about geographic concepts, right?
We talk about regions, availability zones, and geography.
A region is just a set
of connected cloud data centers deployed
within a defined perimeter.
An availability zone is a zone made up
of one or more data centers equipped
with independent power, cooling, and networking.
And geography is an area
of the world containing at least one region.
Remember, a region was a set of connected data centers.
These are cloud data centers deployed
within a defined perimeter.
So geography can define a discreet market
that preserves data residency
or sovereignty and compliance boundaries.
So based on geography, you could say, "Okay,
I'm going to use this cloud provider
but my data has to stay in a particular geography."
Geographies allow customers with specific data residency
and compliance needs to keep that data close,
because they've been able to specify where it is.
Now, geographies are also designed to be fault tolerant
to withstand complete region failure
through their connection
to dedicated high-capacity networking infrastructure.
Now we depend on the cloud.
So having high availability
in the cloud is extraordinarily important.
So we want high availability fault tolerance.
The high availability,
that you'll sometimes see abbreviated as HA,
provides for redundancy and automatic failover capability
in the cloud environment.
So what we have here is what's known as a cloud instance.
A cloud instance just refers to a virtual server.
And a high availability cloud configuration is referred to
as a regional instance,
and that's designed to provide data redundancy.
Now, within a regional instance,
the configuration is made up
of a primary instance and a standby instance.
And through synchronous replication
to each zone's persistent disks,
all writes that are made to the primary instance
are also made to the standby instance.
And in the event of an instance or zone failure,
the standby instance will be able to take over.
Now, if all of this sounds pretty familiar,
you're thinking this sounds a lot like networking
in my local data center.
Well, it really is, other than in the cloud environment,
we just use some different terminology.
So let's look at a high availability flowchart.
The primary instance sends a per second heartbeat signal.
And so it's always saying, "I'm working,
I'm working, I'm working, I'm working."
And then we have a primary instance or a zone failure,
and it doesn't really say anymore, "I'm not working."
It just stops beating.
So the heartbeat ceases.
The standby instance measures that unresponsiveness.
Was it just a yawn, just a hiccup,
or did that heartbeat really stop?
The standby instance will declare an outage.
"I declare," right,
"that that primary instance is no longer working."
And the standby instance will take over at that point.
And reversal can either be automatic or manual.
So the reversal meaning
that it was automatic for the standby to take place
but when we reverse back to the primary,
it may be automatic or may be manual,
just depending upon how the infrastructure is configured.
All right, that my friends was a very, very high level look
at the cloud infrastructure.
So let's do a three second challenge together.
This mechanism virtualizes, CPU,
memory storage, and network resources
at the operating system level.
1, 2, 3.
That's a container.
Number two, provisioning and deprovisioning pooled resources
to match current demand.
How do we describe that?
1, 2, 3.
That's rapid elasticity.
Number three, a set of connected data centers deployed
within a defined perimeter.
1, 2, 3.
That's a region.
Number four, location within a region
with independent power, cooling, and networking.
1, 2, 3.
And that's an availability zone.
And lastly, number five, comprised
of a primary instance and a standby instance.
1, 2, 3.
And that's a regional instance.
So that brings us to a security-in-action.
This one's about data residency.
So let's see what we got here in our case study.
You work at a mid-size financial institution.
The most recent audit report cited the primary data center
no longer able to handle the operating capacity.
In response, your team is advocating migrating most
of the in-house infrastructure to the cloud.
Now, you present this option to executive management.
Their primary concern is regulatory compliance,
specifically control
over where customer information is stored and processed.
So how are you gonna respond to their concern?
Okay, so you're at a financial institution.
We had an audit and the audit said, "Boy,
your data center, really, it's outdated.
And the backup data center is really no longer able
to handle the operating capacity."
So your team says, "Okay, well,
let's not have to redo everything here.
Let's go up to the cloud."
And executive management says, "Well, okay,
but we're a financial institution
and we have regulatory compliance we have to think about,
and specifically, we need to have control
over where our customer information is stored and processed.
We need to know where that's happening."
So how are you gonna respond to their concerns?
Go ahead and put me on pause, jot down some notes,
and then come back and tell me about your response.
Well, major providers
define a discrete market or geographies
that preserve data residency and compliance boundaries.
Now, geographies allow customers
with specific data residency and compliance needs
to control their data
and application storage and processing location.
So it's important if you're gonna do an RFP, right,
and any subsequent contract,
clearly, clearly define this requirement,
not all providers are gonna offer it
and it's not gonna be offered by default.
So you wanna make sure, right,
that whoever providers you're considering,
and that's why you would do it
in your RFP, request for proposal,
can you meet this need?
Explain to us how you do it.
And then we wanna make sure in the subsequent contract,
once we have chosen a provider,
that it is also clearly defined,
it becomes a contractual obligation.
So being able to see kind of all
of these options and alternate ways of doing things
and having these discussions, these conversations,
I know I use the word conversations over and over again
but so much of what we do
as security practitioners is having conversations
about security with other people.
Well, doing all that, definitely security-in-action.
There's your word cloud.
I think for many of you,
most of these terms are gonna be new.
Don't get too hung up
on how much you need to know about the cloud infrastructure.
I just need you to have sort
of this high level conceptual view.
So take a look at these and then when you're ready,
head on over to the next lesson.
I'll see you there.