Hashing is closely related to encryption, but not quite the same thing.
Often, we'll use hashing together with encryption, but
hashing for the most part is about integrity,
not about confidentiality,
even though we do hash things like a password in order to
maintain the confidentiality of the password.
The advantage, of course, of a hash is that it's a one‑way function.
We can go from a message, create a hash or digest of that message that
is a very accurate representation of that message.
Even if one bit in the original message was to be changed,
the hash will vary often by more than 40%.
The advantage of hashing is it's not reversible.
It's only one way.
So if a person has a hash, that's not going to tell them
anything about the source message. In this way, hashing becomes
a critical piece in the security chain,
working primarily for integrity and to ensure authenticity,
integrity, protection of secrets such as a password, but as we
say, it's not really cryptography. Cryptography is something we
can encrypt and we can then decrypt in what we call a two‑way
function. In the case of hashing, it's a one‑way function.
Some of the main benefits of hashing is that it's very sensitive to any changes
in a document, file, database or other entity. It's fast,
freely available, and in many ways we can say here essential for the cloud
because we need to protect the data we both transmit and store.
We combine it with asymmetric or public key encryption in order to create
digital signatures that we looked at before. A digital signature proves the
message was not altered and who it came from. Closely related to this are
the areas of masking and obfuscation.
This is the ability to hide sensitive data so it's not
going to be disclosed. For example,
we'll often replace a password or payment card number
with some type of meaningless values,
dots or hash marks, for example. It's also used to protect data in both
the use and sharing phases of the cloud data lifecycle.
In this way, the real data may be stored, say, for
example, in the database, but the user only sees the
actual hash values or obfuscated value.
We often would do this when we're going to put sensitive data
onto a screen or, for example, into a report.
Anonymization is to remove the personal identifiers,
the sensitive data within a record.
In other words, we can make the data now non‑personally identifiable, so we
remove the personally identifiable information, or PII.
We can do this a few different ways.
We can just randomly substitute the personal information for something
else, or we'll very often do an algorithmic substitution. We'll use
some type of a formula to actually substitute the values. That would
allow us to go back if we needed to. If we had done random
substitution, we may never be able to determine what the real value
was at a later time.
One of the things we always have to watch for, as we talked about before
though, is the risk of deanonymization. Is someone going to be able to
figure out who that identifier relates to in,
for example,
a small sample set? We do masking and anonymization in the cloud. For example,
in a Software as a Service application, it could be done in the services
offered by the cloud service provider, or it can be built into the
applications that we either custom build or we purchase to run in a
Platform as a Service type of environment.
In this case, it could be managed by the cloud consumer instead of the provider.
In the case of Infrastructure as a Service,
this is the responsibility of the cloud consumer. Tokenization is
something we've used for a long time where we replace this sensitive
information with something which is not valuable or not indicative of
what the sensitive information is.
For example,
we see this a lot with the use of payment card information where if I go up
to a petrol pump or a gas pump and I want to make a purchase of gasoline,
then the pump application talks to the bank, transmits the credit card
information to the bank, the bank processes that, and sends a record of this
transaction back to the gas station merchant. But the record back to the
merchant does not contain the credit card number. It only contains a token
value that only the bank knows which credit card is associated with that
token value.
So it does allow a cross reference back to the original value,
but only by the authorized people.
We have often done this with payment card information,
for example, so that you can process a credit card,
for example,
without the merchant ever actually having or knowing
what that credit card number was.
The key points review.
The protection of data in the cloud is the responsibility of the cloud consumer,
the data owner.
And it is important that steps are taken to ensure
that when I put my data on the cloud, it has been properly protected.
It needs to be protected at all times using tools such as we've looked at here.
Yeah, information rights management,
data leakage or data loss prevention, and cryptographic functions.