COMPX527 Week 5
Identity and Access
Management
1
Identity and Access Management
2
Identity and Access Management
• Identity and access management are often discussed
together, but it’s important to understand that they
are two distinct concepts:
– Each entity (such as a user, administrator, or an
application) needs an identity. The process of verifying that
identity is called authentication
– Access management is about ensuring that entities can
perform only the tasks they need to perform. The process
of checking what access an entity should have is called
authorization
3
….but wait
• We do Authentication and Authorization in non-cloud
environments too.
• In cloud environments
– No Perimeter
• No physical controls, No perimeter firewalls and other network based controls
– Improper access control on a service exposes it to the entire world
– In additional to authenticating users and employees for your business,
you also authenticate to the cloud services.
– In traditional IT, Identity management is sometimes substituted for
access control
4
Identity Life Cycle
5
Authentication
• Three levels of authentication in cloud
– Authenticating your organization’s employees with your cloud
providers
• generically business-to-business, and often called something like “Cloud IAM” by
cloud providers
– Authenticating your organization’s employees with your own
applications
• Called business-to-employee
– Authenticating your organization’s customers with your own
applications
• Called business-to-consumer
6
Cloud IAM
• Many cloud providers offer IAM services at no
additional charge for accessing their cloud
services.
• These systems allow you to have one central
location to manage identities of cloud user
and administrators in your organization
• Enables you to manage the access that you
have granted those identities to all of the
services that cloud provider offers.
7
Business-to-Consumer & Business-
to-Employee
• In addition to the identities your organization
uses for accessing cloud provider services, you
may also need to manage identities for your
end users, whether they are external
customers or your own employees.
8
Business-to-Consumer & Business-
to-Employee
• Setup your own ID Management System
– Users may have to juggle yet another set of credentials
– Sometimes necessary
• Use an external identity service. This may be an internal
identity service for your employees or your customer’s
employees. For end customers, it may also be an external
service such as Facebook, Google, or LinkedIn.
• Use customer identities specific to your application, and use a
cloud service to manage these customer identities.
9
External Identity providers
• An identity provider (IdP) is a service that stores and manages digital
identities
• You may want to give your users the freedom to choose which Identity
Provider they use to sign in to your application
• Helps avoid password fatigue for the users
• Greater security by leveraging resources of experts
• Must learn how to use the APIs securely!
• Must understand how the IdP validates identity.
10
ID as a service
• IDaaS services manage user identities and
provide integration with cloud services
11
Authenticating Applications
• Can’t do MFA
• Four different ways
– Approach 1
• Store credentials in the deployment system, using
features designed to hold secrets
• Tightly control access to the deployment system
• Nobody sees the credentials by default, and only
authorized individuals have the technical ability to view
or change them in the deployment system.
12
Authenticating Applications
• Approach 2
– Use a credentials server to hold credentials.
– Either the deployment server or the deployed application contacts the credentials
server to get the necessary credentials and use them.
– In many cases the credentials are still visible in the configuration files of the
running application after deployment, so operations personnel may be able to
easily view them.
• Approach 3
– Deployment server only able to get a one time token and pass it to the application,
which then retrieves the credentials and holds them in memory.
– This protects you from having the credentials to the secrets server or the
application credentials themselves intercepted.
• Approach 4
– The cloud provider provides trusted identity documents and metadata that the
credentials server can use to decide which credentials to provide to each
application.
13
Authorization
• Once you’ve completed the authentication phase and you
know who your users are, it’s time to make sure they are
limited to performing only the actions they are supposed to
perform. Some examples of authorization may be
– Permission to access an application at all
– Permission to access an application with write access
– Permission to access a portion of the network
– Permission to access the cloud console etc.
• The most important concepts to remember for authorization
are least privilege and separation of duties
14
Least Privilege
• Least Privilege
– The principle of least privilege simply states that people or
applications should be able to access only what they need
to do their jobs, and no more.
• for example, an application accessing a database should not use
credentials that allow write access to the database if write access
isn’t needed.
– A practical application of least privilege often means that
your access policies are deny by default. That is, users are
granted no (or very few) privileges by default, and they
need to go through the request and approval process for
any privileges they require.
15
Separation of Duties
• Separation of duties
– Ensuring that one individual does not have all
necessary permissions to be able to complete a
malicious action.
• this could be an action such as using a key to access and
decrypt data which that user should not normally have
access to
– Practically it means that more than one person is
needed to complete a task that involves sensitive
information such as granting or revoking access to
services.
16
Policy
• Access Control is performed using policies
• A policy defines who can perform what action
on which resource and under what condition
• Policies often have two parts
– Specification: define the access policy
– Enforcement: evaluate and implement the policy
17
Types of Policies
• Identity based policies
• Resource based policies
• Access control lists
• Role based policies
• Attribute based policies
• CSPs often have variations of these as well as
other types of policies specific to their cloud
18
Identity based policies
• Identity-based policies control what actions an identity (users,
groups of users, and roles) can perform, on which resources,
and under what conditions
19
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “s3:ListAllMyBuckets”,
“Resource”: “*”,
“Condition”: {
“DateGreaterThan”: {“aws:CurrentTime”: “2020-04-01T00:00:00Z”},
“DateLessThan”: {“aws:CurrentTime”: “2020-06-30T23:59:59Z”}
}
}
]
}
Resource Based Policies
20
• Resource-based policies are attached to specific resources
such as an Amazon S3 bucket. These policies grant the
specified principals permissions to perform specific actions on
that resource and defines under what conditions this applies.
Role Based Access Control
21
• Create Roles and apply permissions to roles rather than
individual identities
• Assign roles to identities
• Many to many relationship between roles and identities