When it comes to securing data in the cloud,
we know that there are a number of things we have to do to
ensure our data is properly protected.
And, in fact, domain two of this course,
Data Security in the Cloud, is the most heavily weighted domain.
But let's look at this from a high‑level overview before we get
into more detail in the next module of the course.
One of the things that leads to security of our data is to do planning,
a well architected framework, for example,
and to follow some of the practices out there,
say from the cloud security alliance, their enterprise architecture.
We know that SANS also has put out a number of good
security principles we can follow.
The cloud security alliance has defined the data lifecycle in this way.
Create, store, use, share, archive, and delete.
So we need to pay attention to the protection of data
all the way through the lifecycle.
That includes ensuring the secure deletion of the
data at the end of life as well.
But we secure it when we store it, classifying it,
for example, and we make sure that only authorized people can use it or share it.
We keep it as long as we're required with archiving.
In order to protect data, it's important that we,
first of all, know what data we have,
and those are the various types of data elements.
Which of those data elements are sensitive or
critical and need additional protection?
Where they used and what is the location where that data could be found,
not only physically but on various types of reports,
systems, access according to roles and responsibilities as well?
A big part of protecting data is to determine who is accountable.
In other words, the data owner.
Then the data owner will oversee the creation of a data classification scheme.
The purpose of data classification is to specify
how a data must be then handled.
How we set in place the rules for the handling, use, and deletion of the data.
Securing data consistently means we protect it all the way
through that data lifecycle we looked at.
This includes data in all forms, electronic data,
paper, and things like logs, data when it's being stored,
when it's being transmitted, and of course,
when it's being displayed.
We must protect data consistently in all of those and then at end
of life have what we call secure destruction.
This is also known as defensible destruction because it refers to the
fact that we are able to defend or make that statement.
This data has been destroyed.
We have then reviewed the practices used for that.
Another important part of protecting data of course is
protecting who has access to it.
And identity and access management is a key part of
any type of IT system security.
We must make sure that only authorized entities have access,
but also that they only have the appropriate level of access as well.
The problem can come when the person's access continues to
grow as they longer in the organization,
they move from department to department or from system to system.
And we have what we could call then access creep,
a level of access that goes far beyond what a
person needs for their current job.
We also have to look at who manages the access and how up to
date and current are they in that management?
We have to make sure that we have differentiation between the various users,
what a user could do as compared to what a manager can do.
What are the levels of access actually then granted to these people?
One of the areas that's always a concern is the person who has higher levels
of privilege and the person who's the administrator is,
of course, the person where the highest risk also lies.
Who has administrator access?
Are we keeping on top of whether or not that access is
removed when they no longer need it?
Now,
one of the things we saw in the earlier module is that
we have shared responsibilities,
and responsibilities for many things could be shared depending on whether we're
dealing with Platform as a Service or Software as a Service,
for example.
We know though that in all cases whereas some of the things like user
permissions might be managed by the consumer and the cloud service
provider deal with the administrators, that's not always the case.
And therefore,
we have to know who is responsible for the protection of our systems,
system access, and data access depending on the model we are dealing with.
When we look at the idea of access control,
we often call this the IAAA, the identification,
authentication, authorization, and accounting,
or sometimes accounting is called auditing.
We will look at this in more detail,
but we want to make sure that we identify who is
able to access our data or systems,
we prove their identity through authentication,
we only grant them the correct level of authorization,
and of course with practices like need to know and least privilege,
and we have a record of all the access and what they did,
and that, of course, is accounting.
The concepts behind access control is to ensure that a person
has the access they need to do their job.
Denying access is easy, just turn the system off.
Know the challenge of access control is to provide
the appropriate level of access.
In alignment with principles such as only giving a person the lowest
level of access or privilege they need to do their job,
we'll call that least privilege,
and we could say even only for the time they require that access.
We also bring in the ideas of separation or
sometimes called segregation of duties.
No one person controls a sensitive transaction right
from its initiation to its completion.
No,
instead we have others that must review and approve to
try to prevent mistakes or even fraud.
This applies not only to our employees as a cloud consumer,
but also very much to the staff of the cloud service provider.
Do they make sure that their employees can't access data they shouldn't see?
And maybe they're limited to only being able to see access data for
certain companies and not for their competitors.
We also bring in the idea of need to know.
And this is where sometimes obfuscation tokenization is good,
where a person doesn't know the real data,
they don't need to, so therefore, we hide it from them.
And this, of course,
includes the protection or storage of sensitive data if we
deal with something like a payment card,
a credit card, debit card, other types of personal information,
we want to make sure that is protected from unauthorized disclosure as well.
One of the ways we protect our data is through encryption.
Encryption can do two main benefits for us and that is one,
protect it from unauthorized disclosure,
but also protect our data from unauthorized or improper modification.
But when we deal with encryption,
the secret to encryption is the protection of the key
according to Kirchoff's principle.
Therefore,
one of the most important things here is that we have good key management.
That means we know who holds the keys,
and maybe we keep them in escrow with a trusted third‑party,
or maybe we have them on something like a hardware security module,
though many hardware security modules are now software as well.
But we also can use the idea of cryptographic erase.
We encrypt all the data we store on the cloud,
and if we ever move to a different cloud provider,
all we have to do to make that data inaccessible is to destroy the key.
And that is cryptographic erase.
Now, the way we protect data is different for each service model.
In Software as a Service,
for example the cloud service provider has full access to our data,
they handle the encryption.
Whereas in Platform as a Service,
we might handle the encryption out to an endpoint,
but the cloud service provider on say, for example,
the actual storage units themselves.
We use encryption in many places in the cloud.
We use it within the applications themselves,
within a database, and certainly when we're transmitting data over network,
something like wireless.
At the end of life, we need to make sure our data is,
as we said, securely or defensively destroyed.
That means that when it comes to hardware that's had sensitive data on it,
there should be agreements in place to make sure that
hardware has been properly destroyed.
We know that the best way to protect data is to destroy the actual hardware,
not to just overwrite or purge it, for example,
because there are still opportunities to recover that data
if we have enough resources available.
So the best is, we can say here, the actual physical destruction of our hardware.
This is where we need to know what is the arrangement we
have in place with the cloud service provider to ensure the
hardware is properly disposed of.
The problem with overwriting in the cloud is we can say,
well we'll just override our data yeah,
but we have no control over where our data is being written.
We might think we're overwriting,
but not even into the place where our data originally was stored.
And over the months that our data was on the cloud,
it could have been on a number of different units moved
around from this piece of hardware to another.
So that is why the idea of cryptographic erase is good.
Encrypt all the data we have in the cloud at all times,
and then if we ever needed to destroy that data,
all we have to do is destroy the key.
The key points review.
In the end, security is security.
Information security is just information security.
But in the cloud, there are some essential things that must be looked at.
We need to acknowledge where these risks are and address
those as part of our security plan.