[MUSIC PLAYING]
So one of the areas we're going to start
looking at when it comes to designing
our secure architecture is going to be our user controls.
Things like authentication and authorization controls
are going to be the main focus of this.
So we're going to dive deeper into a couple of topics
that we've just touched on in some of the earlier videos
in this course.
So first of all, let's talk about authentication
and authorization and the differences between those two.
So authentication-- this really just begins
with identification, basically someone saying, I am so-and-so,
I am Bob, in this case.
That's where the authentication process starts.
But then you have to go through, and that identity
needs to be verified usually with some sort of credentials,
like a password, or something like that.
So the verification part of that is really
the key to the authentication you identify,
and then you verify that is who you are.
It's basically proving that you are who you say you are.
That is the key behind authentication.
Normally, it's done with, like I said,
a username and a password.
But you can also add some form of MFA
in there, Multifactor Authentication,
basically makes the authentication
and the verification a little better
because you're proving who you are in multiple different ways.
You're using a password, then you're
using either biometrics or a token code that's
displayed on a device that only you have,
multiple forms of authentication and multiple different ways
of proving who you are.
And this is different from authorization.
Authorization is basically, you've
already proven who you are.
You've already verified the identity.
But now you're looking at, what sort of permissions
do you have to access whatever it
is you need to access, whatever resource or assets
you need to perform whatever job or action you're trying to do?
This is usually implemented with some sort
of access controls, which we'll get into here in a minute.
But ideally, you want to use some form of role-based access
controls here.
This will make it a lot easier to manage
your access and your permissions,
and we'll talk about why here in just a couple of minutes also.
So let's introduce a concept known as separation of duties.
We've talked about this a little bit, but let's dive into it
a little deeper here.
So at the core of an organization,
the core of a business, the organizations
will place some level of trust in their employees.
They have to in order to actually employ them and trust
them to do their job.
So the trust is normally placed for some sort
of specific role, whatever their job duties may entail.
And in turn, their access should reflect whatever
their specific role is.
Access levels should be determined
by their job role and whatever duties
they have within the organization.
Boils down to, no one person in the organization
has all of the responsibility, unless we're
talking about a business that has one employee.
But we're not.
But no one person really has all their responsibility.
So in turn, no one should have all of the access rights.
No one should have any more access rights
than they need to do their job.
That's introducing another concept.
They should only have access to what they need to do their job.
This is known as least privilege.
This ties in very well with separation of duties.
And separation of duties is, you have the permissions
to do what you need for your job, and not additional roles
as well.
You separate out the responsibilities among people
so that not everybody has all of the access.
A lot of this is done using the setup
of roles and groups, which is where role-based access
controls come in as well.
So give you an example of what I mean here
by separation of duties-- let's take an example of, let's say,
Sally and Bob both work in accounting.
Sally is in charge of, we'll say,
monthly reports and audits for the accounting
for the entire business.
But Bob is in charge of things like individuals,
expense reports, and reimbursements,
and things like that.
So Bob and Sally work in the same department,
but they have completely different duties
in that department and job roles in that apartment.
They have similar roles in that they're both in accounting.
They both work in the financial data,
but they have completely different responsibilities
and roles.
So they shouldn't have the same level of access.
That's what's known as separation
of duties, which ties in very closely
with the concept of least privilege.
In general, it's a lot easier to give more access
than is needed.
The reason for this is it's easier.
It helps reduce support calls.
It really makes administration much easier.
If you just give people a lot of access,
chances are they don't need all that access.
Their regular jobs don't require that access.
But it prevents them from having problems down the road.
But this is a bad way to do this.
Giving people more access than they need
is usually not a good thing.
This is where you get security breaches and things
like that from people having too much access.
The concept of least privilege, again,
ties very closely into separation of duties.
You're granting access to accounts
and to users only based on what they need to do their job
and nothing more.
You give them the least amount of privilege that they need.
This is built on a concept of the need to know.
What does an employee-- excuse me--
what do they need to know in order
to perform their job duties and their roles
and their responsibilities in the company?
What do they need to know?
What access do they need in order
to be able to accomplish those responsibilities?
That's built in the concept of need to know.
So let's take another example here.
We'll say, John works in facilities management,
and he is responsible for making sure all
the generators for the facility are working properly,
all the backup emergency generators,
things like that-- make sure they're working properly.
As part of that and it's inspections,
there's certain reporting requirements and documentation
that he is expected to do as he's doing these inspections
and making sure these generators run properly.
So John only needs access to that specific folder
that contains those documents.
He does not need access, or full access, to all of the files
for the facilities department.
The only access he needs is what is needed in order
to do his job, in this case, the paperwork and the forms
for doing these inspections and making sure the generators are
running properly.
Now, one of the easiest ways to implement concepts,
such as separation of duties and least privilege,
actually putting these concepts in to action,
is what's known as role-based access control.
This is where you assign permissions and access rights
and controls based on roles in the company, which usually tie
closely in to job roles, not assigning permissions directly
to individual users and their individual accounts.
Now, this does require that roles are very carefully
defined in the company.
But again, once you have these roles defined,
you can assign these permissions to the role and not
the individual people, so the process of assigning
permissions here in this case.
So groups are created in whatever authentication system
you are using.
Say you're using Active Directory,
so you would create a series of groups that are tied
to whatever the job roles are.
Then you assign permissions to those groups
to give whatever that job role is access to whatever it
needs in order to do its job.
And then you place the individual users
into those groups.
So in this case, the users are being assigned to roles.
Permissions are being assigned to roles.
So in turn, the individual user accounts get those permissions.
There's a few different reasons we want to do this,
and we'll get into that here in just a second.
But first, another example.
Let's go back to John and facilities management,
doing his generator reporting and maintenance, and things
like that.
He is assigned to a role called generator reporting in Active
Directory.
So there's a role called generator reporting.
He is assigned to that role.
That role has permission to edit files
in the folder that contains all the paperwork that John
needs in order to do his job.
So the generator reporting role has permissions
to this file, only edit permissions to this folder.
Excuse me.
And then John is added in to that group in Active Directory,
so John gets those permissions.
You also have a director of the department.
That's added into another role called facilities
management, another group that is in Active Directory called
facilities management that ties in to a role, that
ties in to the director of what he actually needs to do.
That role, that group is granted full access
to the entire facilities department,
to the entire department folder.
So the facilities management role
has a lot more permissions to that file folder
than the generator reporting role does.
So this is where you're separating out the roles
into individual groups, assigning permissions
to the groups, and then assigning users to the group.
So the users will inherit whatever permissions
that the group has as well.
We do this to try and prevent what's
known as authorization creep, or auth. creep you may hear it
abbreviated as.
The reason for this is employees very often
change departments, get promotions, change positions,
get new job responsibilities, whatever.
But as those job roles change, their access requirements
change as well.
A lot of times, this results in their access needs changing.
But the necessarily-- the granted access does not change.
Maybe they're granted more access
as they change job roles, but their old permissions
aren't removed.
And this is what's known as authorization creep.
As they go on, they're granted more and more and more access.
But their old access is not cleaned up,
so their authorization just creeps forward over time.
Similar to least privilege, it's much easier to give more access
than needed.
And a lot of times, it's difficult, especially
if you're assigning permissions individually to user accounts.
That user changes job roles--
you may not know what permissions on that account
need to be removed, because they're no longer in that job
role.
And this is where role-based access controls really
can help authorization creep.
And Role-Based Access, a lot of times, is--
or several, a lot of time, really-- it's
abbreviated as RBAC.
So you may hear it referred to as RBAC as well.
It's a lot easier to remove and add roles to a user,
especially when those roles are labeled
as things as generator reporting,
or facilities management.
Instead of looking and going, OK, these seven
folders that he had edit access to before--
he doesn't need those permissions anymore,
but he does need to be granted full permissions to these 27
folders over here, it's a lot easier
to just assign those permissions to a role
and then remove that role from the user as their needs change.
Now, this does require a well-thought out
and properly designed Identity and Access Management system,
or IAM, which an IAM system can really
help with a lot of the provisioning and the automation
of this.
A lot of times, these systems will tie into HR systems.
So when a user changes a job role, or gets promoted,
or whatever the case may be, that's
updated in the HR system, ties in to something
like say Active Directory, which automatically
manages their roles and what they have permissions to.
An IAM system can make that process a lot easier.
So you couple this with role-based access control,
and this really makes administration of permissions
and rights and everything else a lot easier
and helps prevent things like authorization creep.
So another thing I want to talk about
with how we want to secure our users
is a concept known as privacy by design.
We talked about this a little bit in a previous video.
Boils down to, organizations have a responsibility
to safeguard whatever private data they may have.
Whatever this may be, whether it's
user data, employee data, customer data,
anything that's private, organizations
have a responsibility to safeguard and protect
that data.
Bringing in privacy as an afterthought
and not directly into the design of the secure architecture
makes securing that data lot more difficult.
Privacy should be built in to all of your systems
and all of your applications and all of your processes
from the very beginning.
That is a very important part of designing
a secure architecture, is building that privacy in there,
having privacy by design, not as an afterthought.
Now, something like GDPR, which is an EU regulation
specifically around data privacy,
is based on the principle of privacy by design.
You want to embed privacy into your design
from the very beginning, and this
can apply to things like server configurations.
How are you going to protect the data on those servers?
File storage-- [INAUDIBLE] easy way
to protect data there is to encrypt
the data when it's at rest and when it's in transit.
Your access controls can help with privacy
by design using things like least privilege,
separation of duties, in addition to role-based access
controls that can help maintain and restrict
what data people have access to if they don't have a need
to know the information.
Application development privacy should be built in.
If your organization is doing any software development, is
writing any applications, or anything like that,
data privacy needs to be baked into that design
from the very beginning.
And especially on any publicly accessible systems, especially
websites, privacy needs to be a forefront
in that conversation on how those systems are designed.
So privacy by design, role-based access control,
least privilege, separation of duties--
these are all important concepts to keep in mind when
you are designing your secure architecture, especially
around your authorization, your authentication,
and all of your user controls to keep everything more
secure from the very start.