In the last blog, we talked about AWS IAM challenges usually encountered while setting it up. We also talked about AWS IAM best practices which help us understand why there is a need for multiple options & practices through which we can satisfy our needs. When we talk about AWS IAM, there is an important term called security which plays an important role while setting up AWS IAM. We covered lots of approaches which generally are not related to AWS IAM security. We bring to you this blog that covers many aspects of security related to AWS IAM.
This blog will help you understand multiple options provided by AWS IAM through which we can set up secured infrastructure. Most of the options provided by AWS IAM are also covered as security best practices. Let’s explore some of the options.
Security options
This blog will not cover all the security options provided by AWS IAM. Instead, we will cover other options in the upcoming security blog. Before starting, there are no pre-requisites for this blog but to have basic information about IAM & its policy. If you want to know more about IAM & its options, please check out our previous blog “AWS IAM: The challenge” of this AWS IAM series. Without further ado let’s dive into the AWS IAM: security edition and some of the major options.
MFA Enforce
In IAM, when we talk about security, there are multiple approaches taken at admin or server-side but it’s important some parts of security is covered at the user end as well. MFA [ multi-factor authentication ] is one of those aspects. By default, MFA is not enabled. AWS admin has to enable this to make sure user scan set up MFA for their AWS account user.
But for a large organisation having lots of employees, IAM specialists cannot depend on users to enable MFA by themselves because some of the users may skip it which will defeat the purpose.
To overcome this issue, AWS provided MFA enforcing documentation in which user has to enable MFA before accessing any resource. Otherwise, they won’t be able to access any resource as AWS IAM policy will throw permission or access denied issues.
Official documentation shows an AWS IAM policy. This policy provides users to get basic account access like get their account information. This policy also provides users to create their own MFA and an important one is to deny all resources access if no MFA enable found. Accordingly, users can remove or add extra parts in this policy. You can check the below policy which only contains deny policy if no MFA is enabled.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllExceptListedIfNoMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
}
}
]
}Limited access
When we talk about limited access, we can divide it into two categories.
First, we can restrict access on the basis of usability like if there is only a need for ACCESS_KEY/SECRET_KEY but not console access & vice versa. We can limit access on the basis of these by disabling options that are not required by user.
Second, we can restrict on the basis of permission/policy, by limiting and removing unnecessary permission. Unnecessary permission leads to a huge impact on security.
Whitelisting of IPs
When we talk about resources in the cloud or managing everything in the cloud, generally organisations isolate environments & resources to a specific network. VPN is one of the cases, through which organisations can restrict resource accessibility to a specific pool of IP addresses.
For resources like EC2, RDS & other compute resources, we can set restrictions on the basis of source IP address using security group and this is very helpful for resources which support security group but when we talk about general AWS resource accessibility, we cannot set up security group to specific AWS IAM user or group.
AWS IAM policy provides functionality to restrict AWS resource accessibility on the basis of source IP address. Source IP address can be VPN IP, restricted network IP or remote bastion IP, depending on the use-cases, AWS IAM policy will restrict the accessibility of resources to a specific IP address or pool.
AWS official documentation provided basic policy to restrict resources on the basis of source IP address, further we can modify these policies accordingly. Below is the policy through which we can start with IP restriction policy.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
},
"Bool": {"aws:ViaAWSService": "false"}
}
}
}Rotate credentials regularly
Rotation policy is not only for AWS IAM, but it’s a very important & very useful option to have. In security, rotation gives flexibility to rotate credentials at specific time. These rotation credentials can consider of following things:
1. password rotation policy
2. Access keys rotation
If we talk about password rotation policy, AWS IAM provides a global option to set password expiration under password policy. This allows users to modify their key after a certain interval of time.
In the case of Access key rotation, Access keys are one of the important aspects of IAM users. This is same as the IAM user password and this thing needs to be taken care of.
This generally is not an option or feature provided by AWS IAM. We need external resources to set this thing up using AWS Lambda & automation scripts [ compute ] depending on the nature & supporting nature of resource, user can use boto3 & AWS CLI.
Summary
It is imperative to not only consider AWS IAM Security, or security in general, on the server-side but set up, manage & enforce from the client end too. When we talk about enforcing, we can have multiple options and some of the options we covered like MFA & source IP which is configured through AWS IAM policy.
When we talk about credentials like passwords & keys, we can rotate these credentials to make sure no one can get access through old keys and this is the best security practice. Also, when we talk about user credentials, we generally skip the permission scope of user which can lead to huge impact in security, by limiting access to specific resources and access type.
If you are new here, you can check out our previous blog of the AWS IAM series which cover AWS IAM introduction, best practices & options:
This blog didn’t cover other security options, we will cover other options in the upcoming blog of security edition. Let us know in the comment section if you have comments or suggestions, not only related to AWS IAM security but also related to AWS IAM.
Blog Pundit: Naveen Verma and Adeel Ahmad
Opstree is an End to End DevOps solution provider
Connect Us
DEVOPS DONE RIGHT 
One thought on “AWS IAM: Security edition [Part-1]”