One of the foundations of any security program is
really identity and access management.
Let's look at some of the basics of identity.
We can see that identity management is really made up of
four phases, though we often call it the AAA model, and the
four phases are identification, authentication,
authorization and accounting, though it's sometimes called auditing.
Identity management really starts with a person claiming an identity.
This is who I am.
That should be a unique type of identifier, and it should only be issued to
people that we know should have an identity on the system.
A person should not be able to create fake IDs, so there
should be some type of secure registration process. Ideally,
identities should never be shared.
We shouldn't have an administrator account that 10 or 12 people are using.
And of course, this applies to all entities that interface their systems.
That means both individuals or people, but also processes.
So every process running on our system also has a
unique identifier. So a person said, hey, I'm Tony.
The next step is to authenticate or validate that that
person really is who they claim to be.
Are they really Tony? If they are, then they should know Tony's
password. We'll call that a knowledge‑based type of authentication, or
they may have Tony's key fob or Tony's ID badge.
That is what I have. And of course, they may have Tony's
fingerprint, and that is something we are.
So these are three ways that we normally will then
authenticate a person's identity.
When we take a look at each of those three, their weakness,
their weaknesses, the problem is that a person could
learn somebody else's password,
steal their badge or get a copy of their fingerprint.
So we realize today that we must practice what we call strong authentication.
That is based on the idea of MFA, or multifactor authentication.
We will require a combination of two or more of those authentication
factors in order to allow a person to be authenticated and thereby
increase the reliability of the authentication process.
So a person must have the key fob plus, for example, a PIN number.
We said that this is often called strong authentication, and we see the term
MFA used very often today as a way to try to increase this whole level of trust
we can have in identification and authentication.
When we set up a person's identity,
we give them certain levels of authorization. Authorization says what
can a person do? Now that they are an authenticated user, what are
the rights or privileges on the system?
This includes concepts such as least privilege, only giving a
person the level of privilege they need to do their job and
only for the time they need it.
Putting in the concept of need to know, don't share information
with a person who doesn't require that in order to do their job.
And of course, we often deploy what we call separation or sometimes
known as segregation of duties.
That means it takes two people to accomplish a task.
The two people may have to work together in something we would call dual
control, or it could be that if one person has input data,
a different person has to approve it, and that's what we
call mutex, or mutual exclusivity.
When we look at the way we manage authorization,
we quite often do it based on rules.
You can do this, you can't do that. We do this with individuals.
We also do it with a more common generic,
for example, the firewall that blocks access to certain sites.
We then, of course, can limit a person's access according to what their
job role is, and this is what we often call role‑based access control. But
we have something else that's known as ABAC,
attribute‑based access control.
And attribute‑based is another layer of protection on top of rules or roles.
For example,
a person might have the right to read that file, but
only if they are in the office, not if they're working remotely.
So that was what we would call a location‑based attribute. Or a
person may be able to log into the system,
but only during normal working hours, and they couldn't log
in at 2:00 in the morning, and that's what we call a
temporal or time‑based attribute.
We implement authorization through many different tools,
directory services, for example, such as Lightweight Directory Access Protocol,
Microsoft's Active Directory, and we set out the schema or the
structure of how a person's access should be managed.
We also, of course, allow the replication so that if
there is damage to an Active Directory,
we would be able to copy that from another location.
We also use things like email addresses and different types of directory
standards such as the X500 and as a way to identify a person. And
there's a number of vendor products out there,
of course,
that also can help us to set up the proper
authorizations for our authenticated users.
The final step of this IAAA is accounting or auditing.
This is where we keep a record.
We log all of the activity on the system.
The idea is that all of that activity should be linked
back or associated with a known identity.
That is why it's important that those identities are unique so we can
identify who actually made that change, for example. An important part of
this is to keep the logs as long as we might need them,
either for compliance with legal requirements or compliance with business needs.
It could be that those logs are going to be key information we need if
we're going to do some type of investigation. So we want to preserve the
integrity of the log and, of course, prevent unauthorized access to the
log or a person might delete it,
for example. The idea of identity management is almost always
the responsibility of the cloud consumer.
The cloud consumer determines who gets access to the various applications.
Now obviously,
the cloud service provider also plays a role because they
manage the access given to their staff,
but it's the cloud consumer that manages the access rights of their
users, and we can say here the cloud service provider then manages
access to the equipment or components that they actually manage as
part of the cloud service.