Activity: AWS Security Best Practice:

image source: LinkedIn learning

Scenario

You are part of an organization running a simple static website on AWS using Amazon S3 and Route 53 services.   

Tasks:

• Research the service and security requirements for hosting a static website on AWS
• Identify and discuss what users, groups, roles and policies required to set up with IAM
• Identify and discuss best practice security recommendations
• Write a blog about your solution

NOTE: Consider security best practice when architecting your project solutions.

Research the service and security requirements for hosting a static website on AWS:

A static website is usually written in HTML, Amazon S3 can be used to host a static website. To proceed first of all you will require internet access , a your AWS account, a HTML editor and a domain name.

In order to host a static website on Amazon S3 first you will have to configure an Amazon S3 bucket as a static website and upload the website content into it. When a bucket is configured as a static website it enables web hosting, sets permissions. You are also able to configure options such as redirects, web traffic logging and customer error documents.

The AWS Management Console can be used to configure a bucket for static website hosting without writing any code, the website configurations can be updated and deleted by using the AWS SDKs.

( Erick Brito, slideshare LinkedIn Corporation, AWS static webhosting, 2020, https://www.slideshare.net/ErickBrito5/aws-static-web-hosting )

Identify and discuss what users, groups, roles and policies required to set up with IAM:

IAM Users:

When an AWS account is first created, the initial step would be to create a single identity is not recommended for a root user to engage in the day to day tasks an IAM user is created.

One of main uses of IAM users is to provide the people with the ability to sign in to the AWS Management console to interact and make programmatic requests to the AWS using the API or CLI, An IAM user is grated a name and a password that has considerable permissions and access privilege, these privileges of an existing IAM user can be cloned and the new members would be able to enjoy the same privileges.

IAM USERs

Service accounts are IAM users that are created to represent applications, you are able to have a maximum of 5000 users per AWS account and each user account has a unique name and an ARN, individual IAM accounts need to be created for each user as it is best not to share accounts.

The secret access key and access key ID are not exactly the same as a password and can be generated only once and if lost it has to be regenerated. These cannot be used to login to the AWS console.

Rules can be bought usage of a password regarding its length and complexity and also rules regarding the ability to change the password.

IAM Group:

A collection of IAM users is called an IAM Group, here privileges and specific password authorities can be given to a group of people. For example for a group for admins you can assign them with admin privileges, while a group of executives would have the privilege to approve documents, and when a staff member shifts from one group to another you will just have to remove him from the old group and add him to the new group.

·       IAM Groups are a collections of IAM users and have certain policies attached to them.

·       A group is not an identity and cannot be identified as a principal in an IAM policy.

·       Groups can be used to assign permissions to users.

·       When assigning permissions the principal of least privilege should be used.

·       You are not allowed to have groups within groups (nest groups) .

IAM Role:

An IAM Role is an identity with approved policies that determines as to what an IAM can and cannot do in AWS, temporary roles can be given to IAM users with restricted privileges to perform various tasks these would expire automatically after a set period of time.

Roles are created and then “assumed” by trusted entities and define a set of permissions for making AWS service requests.

With IAM Roles you are able to grant permissions to various resources for users without giving them permanent credentials and you are able to delegate various functions using roles

There are no passwords or access keys in roles.

IAM users are able to take temporary roles where they are given permission temporarily for a particular task.

Temporary passwords and access keys are mainly used with IAM Roles and they expire automatically after a certain time period

Roles can be assigned temporarily through the console or programmatically with the AWS CLI, Tools for Windows PowerShell or API.

IAM roles with EC2 instances:

• IAM roles could be used to grant applications running on EC2 instances permission to AWS API requests using instance profiles.
• Only one role can be assigned to an EC2 instance at a time.
• A role can be assigned at the EC2 instance creation time or at any time afterwards.
• When using the AWS CLI or API instance profiles  it must be created manually
• Applications retrieve temporary security credentials from the instance metadata.

Role Delegation:

• IAM role is to be created with two main policies:

·        Permissions policy – the user of the role will be grated the necessary permission for a particular resource.

·        Trust policy – specifies the trusted accounts that are allowed to assume the role.

• Wildcards (*) cannot be specified as a principal.
• A permissions policy must also be attached to the user in the trusted account.

IAM policies:

A policy is a document of set of guide lines that, defines various permissions and these can be applied to users, groups and roles. You are also able to custom define policies and these could then be attached to identities such as users, groups and roles in your AWS. Policy documents are written in JSON (key value pair that consists of an attribute and a value).

The effects of access control policies can be tested, validated and understood using the IAM policy stimulator.

A policy that is attached to an identity in IAM is known as an identity-based policy.

There are 3 types of policies:

• Managed policies.
• Customer managed policies.
• Inline policies.

Managed Policy:

Managed policies are created and are administered by AWS, The can be attached to users .groups, or roles but cannot be changed, it saves time since you will not have to create any policy but these are used for common use and are not specific

Customer Managed Policy:

These are standalone policies that you create yourself in order to administer your AWS account these can also be attached to multiple users, roles and groups in your account, these can be customized according to the need of the present environment.

Inline Policy:

 An inline policy a policy which is created by you and embed directly to an IAM group, user, or role, these policies cannot be reused on other identities, when a user, role or group is deleted the policy would be deleted as well, inline policies are useful when you want ensure that permissions in a policy are not inadvertently assigned to any other user, role or group

It is recommended to use customer managed polices instead of both other polices as customer managed policies have a more specific details regarding security and performance of certain jobs

You can use the AWS Management Console, AWS CLI, or AWS API to create customer managed policies in IAM.

(AWS ,Creating IAM poilicies, 2020 , https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html )

(AWS, AWS Identity and Access Management, 2020, https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html )

POLICIES

The diagram below provides some more information on the relationship between IAM roles, users, groups and policies.

( Digital Cloud Training,2020,

https://digitalcloud.training/certification-training/aws-developer-associate/aws-security-identity-and-compliance/amazon-iam/ )

Identify and discuss best practice security recommendations:

Creation of a strong password: 

In order to be a strong password it needs to be a combination of letters special characters and numbers.

Use a group email alias with your AWS Account:

Using a group email alias enables you to delegate the management of the account to a trusted member of your organization while you are away.

Enable multi factor authentication:

Multi factor authentication is an additional level of security provided other the usual user name and password, it consists of an additional piece of information that is only known to you.

Setup AWS IAM users, groups, and roles for daily account access:

Through creating IAM users, groups and roles, it will enable to grant limited and controlled access to information and privileges to each and every unit or individual.

Delete your accounts access keys:

Using the access key related to your root account is not recommended rather it is better to create a IAM  user and grant the user the permission needed for the API’s you plan to call and then use the IAM user to issue access keys.

Enable CloudTail in all AWS regions:

You will be able to tract of the activities in your AWS by using AWS Cloud Tail