Authentication, Authorization, and Access Control

AAA in AWS

Authentication

Authentication define and verify an identity. The authentication process is comprised of two parts of information:

Authentication is not just for verifying human access to systems or areas. It is also used between:

Authorization

Authorization determines the access level or type. Authorization only takes place once an identity has been authenticated, so there is a clear order as to which these two operate. Basically, these are:

Access Control

Access control defines the method and process of granting access. Specifically, these are logical access control. Some examples of access control:

Authentication Mechanisms in AWS

The following are the available authentication mechanisms in AWS.

Username-Password Authentications + MFA

This is the most basic authentication. \

Programmatic Authentication

Instead of granting access to the AWS Management Console, users can also eb granted access from a programmatic perspective. This can be granted for users who are using the following:

Identity is not prompted to log into the console. Instead, it uses access keys which are composed of two parts:

Note that it’s not possible to retrieve lost access keys as AWS does not retain copies of these for security reasons to prevent them from being compromised. Once you have the access keys and AWS CLI installed in your terminal, you can then configure your AWS CLI with the keys:

$ sudo vi ~/.aws/credentials 

[any-name-for-profile]
aws_access_key_id = AKIAxxxxxxxxxxxx
aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxxx

To use the AWS profile, simply export it.

export AWS_PROFILE=any-name-for-profile

Lifecycle of Access Keys

Access Keys should be rotated to decrease the likelihood of our environment being compromised.

IAM Roles

IAM roles are objects created within IAM and have a defined set of permissions associated to them, much like a normal user or user group would have.

To learn more, check out AWS Identity and Access Management.

Keypairs

The process of authenticating to newly created EC2 instances is slightly different for Linux and Windows Operating Systems but the underlying method is fundamentally the same through the use of key pairs.

Private Keys and Public Keys

The public key uses public key cryptography to encrypt data such as the username and password. For Windows instances, the private key is used to decrypt the administrative password allowing you to gain access to the login credentials including the password using RDP.

For Linux instances, the private key is used to SSH onto the instance, and the public key is held and kept by AWS.

The private key is our responsibility to keep and to ensure that it is not lost.

To learn more, check out EC2 Keypairs.

Identity Federation

AWS allows you to access and manage AWS resources even if you don’t have a user account within IAM through the use of identity federation. Identity federation allows users from identity providers, IDPs, which are external to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account.

There are two parties in a federation process:

When the identity provider has been selected, and the user is authenticated by that provider, an assertion is sent back to the service provider. This assertion is a message that contains metadata and attributes about the user such as their username. It allows the service provider to authorize access to their services.

AWS supports two types of identity providers:

Identity Federation Standards

AWS Services that support Identity Federation

Authorization Controls in AWS

AWS IAM

AWS Identity and Access Management os the main service responsible for managing and maintaining what an AWS identity is authorized to access. When an identity is authenticated to AWS, the way in which permissions are given to the identity varies depending on the identities own user permissions and its association with other IAM groups and roles.

Important concepts:

To lean more, check out: AWS Identity and Access Management

Amazon S3

There are multiple ways identities can be authorized to access an object within S3, some of which overlap with the IAM mechanisms. These methods are:

NACLs

Network Access Control Lists or NACLs are a way of authorizing network packets to enter and leave different parts of your VPC.

If you haven’t created a custom NACL, then your subnets will automatically be associated with your VPC’s default NACL, and in this instance, the default allows all traffic to flow in and out of the network, as opposed to denying it.

NACLs are Stateless NACLs are stateless, which means when create your rules, you’ll need to apply an outbound reply rule to permit responses to inbound requests.

NACL Rules The rule set itself is very simple, and has both an inbound and outbound list of rules, and these rules are comprised of the following:

Security Groups

AWS security groups are associated with EC2 instances, and provide security at the protocol and port access level.

Security Groups are Stateful Security groups are stateful, meaning you do not need the same rules for both inbound and outbound traffic for response traffic, unlike, NACLs, which are stateless. Therefore, any rule that authorizes traffic into an EC2 instance will allow any response to be returned without an explicit rule in the outbound ruleset.

Security Group Rules Each rule set is composed of the following fields:

Photo courtesy of CloudAcademy course, [Authorization Controls in AWS](https://cloudacademy.com/course/authorization-controls-aws-2723/security-groups/)