Identity and Access Management Concept

Identity and Access Management is the concept behind controlling access to assets, including information, systems and devices. IAM focuses on issues related to granting and revoking privileges to access data or perform actions on systems. The goal of IAM is to provide the right people with the right access to the right resources at the right time. Controlling access to assets is a central theme of security. All assets should be protected, but with different levels of protection depending on the system context or criticality.

IAM can be broken down into four core interconnected concepts.

• Identification
• Authentication
• Authorization
• Auditing and Accountability

Various regulations require that all activities of identification, authentication, and authorization are monitored through audit or security logs to provide accountability and support forensic analysis if security issues occur.

Identification

• Identification is the process of a user claiming an identity. 
• A user is an active entity that accesses a system to receive information or perform an action. 
• Users can be persons, programs, services, or anything else that can access a resource. 
• A user must provide an identity to a system to start the authentication, authorization, and accountability processes. 
• Providing an identity might entail typing a username, swiping a smartcard, or positioning your hand, face or finger in front of a scanning device. 
• Identification is usually integrated with user management. 
• User management involves creating and managing user identities, bundling them into groups for effective management and assigning users and groups to roles. 
• User management operations include creating, modifying, and deleting user identities, as well as granting and revoking credentials and roles.

Authentication

• Authentication is the process of validating the identity of a user. 
• The three basic methods of authentication are as follows. 
• Type one authentication factor is something you know, this may be a password or a phrase, or a personal identification number or pin. 
• Type two authentication factor is something you have. Physical devices that a user possesses can help them provide authentication. Examples include a one-time password generator, smartcard, or hardware token. 
• Type three authentication factor is something you are. It is a physical characteristic of a person identified with different types of biometrics. Examples include fingerprints, voice prints, and retina patterns. 
• Multi-factor authentication involves using two or more authentication factors. For example, combining something you know, with something you have. 
• Ideally, the factors should be from different categories. This method increases security as it requires a malicious user to break multiple authentication methods to break the schemes.

Authorization

• Authorization defines what users are allowed to access after authenticating, unauthorized users should not be able to access business assets or perform critical functions. 
• Authorization can be controlled by policies. For example, it could be time of day restrictions, length of time restrictions, file or folder access rights and more. 
• Setting the right authorizations is critical to ensure data protection, prevent fraud, and for regulatory compliance in general. 
• Here are some important authorization principles to consider. 
• Firstly, the principle of least privilege means giving a user or process only those privileges which are essential to perform its intended function. 
• Secondly, separation of duty as a security principle, has as its primary objective, the prevention of fraud and errors. This objective is achieved by disseminating the tasks and associated privileges for a specific business process among multiple users.

Auditing and Accountability

• The final piece of the IAM puzzle is auditing and accountability. 
• The process of tracking users and their activities to provide accountability. 
• If a user misuses privileges or compromise is suspected, we can investigate and ensure that the user is held accountable based on collected audit logs. 
• These capabilities ensure users are accountable for their actions, verify that the security policies are enforced and can be used as forensic tools. 
• Auditing capabilities are also necessary to fulfil regulatory or compliance activities.

Challenges

There are several challenges that may result from insecure implementation of identification, authentication, authorization, and accounting systems. 
Some examples are:

• Identity theft
• Attacks on authentication
• Trusting the means of authentication
• Improper or missing authorization checks
• Incorrect permission assignments
• Unprotected or unencrypted API and external calls
• Untraceable access
• Missing logs of security events
• Unnecessary usage or storage of personal data.

IAM - Identity and Access Management for AWS

IAM: Users & Groups

• IAM = Identity and Access Management, Global service.
• It is a global service because in IAM, we are going to create our users and assign them to group.
• So, we've already used IAM without knowing, when we created an account, we created a root accounts, and has been created by default.
• Root account created by default, shouldn’t be used, or shared.
• Users are people within your organization and can be grouped.
• Groups only contain users, not other groups.
• Users don’t have to belong to a group, and user can belong to multiple groups.

So, let's take an example we have an organization with six people.
You have Alice, Bob, Charles, David, Edward and Fred so all these people are in your organization.

• Now Alice, Bob, and Charles they work together. They're all developers.
• So, we're going to create a group called the group developers who regrouping Alice, Bob, and Charles.
• And it turns out that David and Edward also work together. So, we're going to create an operations group.
• Now we have two groups within IAM.
• Now groups can only contain users, not other groups.
• So, this is something very important to understand. Groups only contain users.
• Now, some users don't have to belong to a group. For example, Fred right here is alone, he does not correspond to any group. That is not best practice.
• But it is something you can do in AWS.
• And also, a user can belong to multiple groups.
• That means that for example, if you know that Charles and David worked together, and they're part of your audit team, you can create a third group with Charles and David.
• And as you can see, now, in this example, Charles and David are part of two different groups.
• So, this is the possible configurations for IAM.

IAM: Permissions

• So why do we create users and why do we create groups?
• Well, because we want to allow them to use our AWS accounts and to allow them to do so, we have to give them permissions.
• So, users or groups can be assigned what's called a JSON document. I'll show you right now what it means called a policy, an IAM policy.
• So, it looks just like this.

• So, in this example, we can see that we allow people to use the EC2 to service and do describe on it, to use the elastic load balancing service and to describe on it and to use CloudWatch.
• We are allowing our users to use some services in AWS. So, these policies will help us define permissions of our users.
• And so, in AWS, you don't allow everyone to do everything that would be catastrophic, because a new user could basically launch so many services and they will cost you a lot of money or would be valid for security.
• So, in AWS, you apply a principle called the least privilege principle.
• So, you don't give more permissions than a user needs.
• Okay, so if a user just needs access to three services, just create a permission for that user.

 IAM Policies Structure

• Consists of
• Version: policy language version, always include “2012-10-17”
• Id: an identifier for the policy (optional)
• Statement: one or more individual statements (required)
• Statements consists of
• Sid: an identifier for the statement (optional)
• Effect: whether the statement allows or denies access (Allow, Deny)
• Principal: account/user/role to which this policy applied to
• Action: list of actions this policy allows or denies
• Resource: list of resources to which the actions applied to
• Condition: conditions for when this policy is in effect (optional)

IAM – Password Policy

• Strong passwords = higher security for your account
• In AWS, you can setup a password policy:
• Set a minimum password length
• Require specific character types:
• including uppercase letters
• lowercase letters
• numbers
• non-alphanumeric characters
• Allow all IAM users to change their own passwords
• Require users to change their password after some time (password expiration)
• Prevent password re-use

Multi Factor Authentication - MFA

• Users have access to your account and can possibly change configurations or delete resources in your AWS account
• You want to protect your Root Accounts and IAM users
• MFA = password you know + security device you own

• Main benefit of MFA:
• if a password is stolen or hacked, the account is not compromised

MFA devices options in AWS

Virtual MFA device

• It has Google Authenticator, which will be just working on one phone at a time
• Other is Authy which is multi-device. You can use it on my computer and on my phones. So, for Authy you have support for multiple tokens on a single device.

                           

Universal 2nd Factor or U2F Security Key

• This is a physical device
• For example, a YubiKey by Yubico and Yubico is a 3rd party to AWS.
• So, this YubiKey supports multiple roots and IAM users using a single security

Then your other options, you have a Hardware Key Fob MFA device, for example this one provided by Gemalto which is also a third party to AWS, and finally if you are using the cloud of the government in the US, the AWS GovCloud then you have a special Key Fob, that looks like this, that is provided by SurePassID which is also a 3rd party.

How can users access AWS?

To access AWS, you have three options:

• AWS Management Console (protected by password + MFA)
• AWS Command Line Interface (CLI): protected by access keys
• This is something we will set up on our computer, and this is protected by access keys, and access keys our credentials that will allow us to access AWS from our terminal.
• AWS Software Developer Kit (SDK) - for code: protected by access keys
• This is used whenever you want to call APIs from AWS from within your application code. And again, these will be protected by the exact same access keys.

Access Keys are generated through the AWS Console
Users manage their own access keys
Access Keys are secret, just like a password. Don’t share them
Access Key ID is just like username
Secret Access Key is just like password

Example (Fake) Access Keys

• Access key ID: AKIASK4E37PV4983d6C
• Secret Access Key: AZPN3zojWozWCndIjhB0Unh8239a1bzbzO5fqqkZq
• Remember: don’t share your access keys

What’s the AWS CLI?

A tool that enables you to interact with AWS services using commands in your command-line shell
Direct access to the public APIs of AWS services
You can develop scripts to manage your resources
The CLI is open source, you can find all the source code on GitHub: https://github.com/aws/aws-cli
Alternative to using AWS Management Console

What’s the AWS SDK?

• AWS Software Development Kit (AWS SDK
• Language-specific APIs (set of libraries)
• Enables you to access and manage AWS services programmatically
• Embedded within your application: SDK is not something that you use within your terminal, it is something that you embedded within your application that you have to code. So, your application will have the AWS SDK from within them.

• Supports
• SDKs (JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++)
• Mobile SDKs (Android, iOS, …)
• IoT Device SDKs (Embedded C, Arduino, …)
• Example: AWS CLI is built on AWS SDK for Python

Let talk to you about an alternative to using the terminal to issue commands against AWS, and this is AWS Cloudshell.

What is AWS CloudShell?

AWS CloudShell is a browser-based, pre-authenticated shell that you can launch directly from the AWS Management Console. You can run AWS CLI commands against AWS services using your preferred shell, such as Bash, PowerShell, or Z shell. And you can do this without needing to download or install command line tools.
When you launch AWS CloudShell, a compute environment that's based on Amazon Linux 2 is created. Within this environment, you can access an extensive range of pre-installed development tools, options for uploading and downloading files, and file storage that persists between sessions.

AWS CloudShell features

• AWS Command Line Interface
• Shells and development tools: With the shell that's created for AWS CloudShell sessions, you can switch seamlessly between your preferred command-line shells.
• Persistent storage: With AWS CloudShell, you can use up to 1 GB of persistent storage for each AWS Region at no additional cost.
• Security
• Customization options: You can customize your AWS CloudShell experience by changing screen layouts (multiple tabs), text sizes, and light/dark interface themes.
• Session restores: The session restore functionality restores sessions that you were running across single or multiple browser tabs in the CloudShell terminal. If you refresh or reopen recently closed browser tabs, this functionality resumes the session until the shell is stopped because of inactive session. To continue using your CloudShell session, press any key within the terminal window.

Bottom of the line, cloud shell is only available in some regions. So maybe try to choose one of the regions where cloud shell is available.

IAM Roles for Services

• Some AWS service will need to perform actions on your behalf
• To do so, we will assign permissions to AWS services with IAM Roles
• As some AWS services that we'll be launching will need to perform actions on our behalf, on our account. And for this to do these actions, they're just like users, they will need some kind of permissions. So, we need to assign permissions to AWS services and to do so, we're going to create what's called an IAM Role. So, these IAM role will be just like a user, but they are intended to be used not by physical people, but instead they will be used by AWS services. 

For example, we are going to create, an EC2 Instance.

• An EC2 Instance is just like a virtual server.
• But so, this EC2 Instance may want to perform some actions on AWS and to do so, we need to give permissions to our EC2 Instance. 
• To do so, we're going to create an IAM Role and together they're going to make one entity. 
• And together, once the EC2 Instance is trying to access some information from AWS, then it will use the IAM Role. 
• And if the permission assigned to the IAM Role is correct, then we're going to get access to the call we're trying to make.

Common roles:

• EC2 Instance Roles
• Lambda Function Roles
• Roles for CloudFormation

IAM Security Tools

• IAM Credentials Report (account-level): A report that lists all your account's users and the status of their various credentials
• IAM Access Advisor (user-level)
• Access advisor shows the service permissions granted to a user and when those services were last accessed.
• You can use this information to revise your policies.
• This will be very helpful because we are talking already about the principle of least privilege, and so using this tool, we're able to see which permissions are not used and reduce the permission a user can get to be inline with the principle of least privilege.

IAM Guidelines & Best Practices

• Don’t use the root account except for AWS account setup
• One physical user = One AWS user
• Assign users to groups and assign permissions to groups
• Create a strong password policy
• Use and enforce the use of Multi Factor Authentication (MFA)
• Create and use Roles for giving permissions to AWS services
• Use Access Keys for Programmatic Access (CLI / SDK)
• Audit permissions of your account with the IAM Credentials Report
• Never share IAM users & Access Keys                       

Shared Responsibility Model for IAM

Summary

• Users: mapped to a physical user, has a password for AWS Console
• Groups: contains users only
• Policies: JSON document that outlines permissions for users or groups
• Roles: for EC2 instances or AWS services
• Security: MFA + Password Policy
• AWS CLI: manage your AWS services using the command-line
• AWS SDK: manage your AWS services using a programming language
• Access Keys: access AWS using the CLI or SDK
• Audit: IAM Credential Reports & IAM Access Advisor