IAM is the AWS core infrastructure service which is used to provide users or applications fine-grained controlled access to what they can do with which service. It can also be used to create templates that users or applications can temporarily assume.
In this guide, you'll be creating users and roles with Principle of Least Privilege in mind.
AWS Console Home Page
In the Search bar, type IAM.
Click on the IAM service.
From the IAM Dashboard side panel:
Click on Users
Click on Create user
Specify User Details page
User details
User name: <name_of_user>
Provide user access to the AWS Management Console: <check>
I want to create an IAM user: <check>
Autogenerated password: <check>
User must create a new password at next sign-in: <check>
- This gives the user access to the online AWS Management console in the browser.
Click Next
Set Permissions page
You can choose which AWS User Groups you want to assign the user to.
You can either choose an existing group, or create a new one directly from this page.
In this guide, we won't be assigning our user to any groups, so don't choose any and leave options as is.
Click Next
Review and create page
Role Details
Review the chosen fields for the new user.
Notice that the Permissions Summary box only includes the IAMUserChangePassword policy.
This is explicitly created when we checked the option to choose password at next sign-in earlier.
Click Create User
Retrieve password page
This page gives you post-creation option to directly send the user credentials to the person's E-mail. This E-mail includes the sign-in URL and the username. The password will need to be provided directly by you, the admin.
If the password was auto-generated, you'll need to view it before navigating away from this page.
Copy/paste the password, and send it over an encrypted channel.
If you forget to, the password can be reset from the user's page:
Users -> Security credentials -> Manage console access
IAM Users page
Click on the newly created user.
Permissions -> click Add permissions -> click Create inline policy
Now attach the policy to the user
Specify Permissions page
Click on the JSON button.
Delete all the code in the JSON editor.
Copy/paste the following policy into the JSON editor:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswords",
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnAccessKeys",
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:ListAccessKeys",
"iam:UpdateAccessKey",
"iam:GetAccessKeyLastUsed"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSigningCertificates",
"Effect": "Allow",
"Action": [
"iam:DeleteSigningCertificate",
"iam:ListSigningCertificates",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSSHPublicKeys",
"Effect": "Allow",
"Action": [
"iam:DeleteSSHPublicKey",
"iam:GetSSHPublicKey",
"iam:ListSSHPublicKeys",
"iam:UpdateSSHPublicKey",
"iam:UploadSSHPublicKey"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnGitCredentials",
"Effect": "Allow",
"Action": [
"iam:CreateServiceSpecificCredential",
"iam:DeleteServiceSpecificCredential",
"iam:ListServiceSpecificCredentials",
"iam:ResetServiceSpecificCredential",
"iam:UpdateServiceSpecificCredential"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/*"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "DenyAllExceptListedIfNoMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:GetMFADevice",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken",
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
NOTE: You would get an error if you tried to sign in with the policy provided in the official AWS documentation. This is because you didn't remove the restriction of changing your password due to the MFA requirement. with the FORCE_MFA policy attached, you've added the following clauses to the "Deny" statement's "NotAction" property: "iam:ChangePassword" and "iam:GetUser".
The user can now log in.
The user now needs to add the MFA device before they're allowed to do anything else.
They can do this by navigating to:
IAM Dashboard -> click Add MFA
MFA device name: <enter_device_name>
MFA device: Authenticator app
Click Next
Set up device page
The user can now either scan the code, or use the secret key, in their authenticator application.
They can now enter two consecutive codes. They might have to wait for a refresh for the second code.
Click Add MFA
Congrats! The user is now set up with MFA.
AWS Console Home Page
In the Search bar, type IAM.
Click on the IAM service.
For this SOC environment, you'll be creating four new roles, with the following permissions:
- SOC Analyst: AmazonEC2ReadOnlyAccess, AmazonVPCReadOnlyAccess, IAMReadOnlyAccess, CloudWatchReadOnlyAccess,
Grants read-only access to AWS services and resources, allowing SOC analysts to view configurations, logs, and other information for monitoring and analysis purposes without the ability to modify resources. This policy should include permissions to list EC2 instances, VPC configurations, IAM users, and CloudTrail logs.
Access to Monitoring and Alerting Tools: Grant permissions to access monitoring and alerting tools such as CloudWatch, GuardDuty, and CloudTrail. This includes the ability to view metrics, set up alarms, and access log data for security monitoring and incident detection purposes.
Limited EC2 Permissions: Provide permissions to start and stop EC2 instances for troubleshooting purposes. However, limit the ability to modify or terminate instances to prevent accidental or malicious actions.
- SOC Engineer: SecurityAudit
Grants permissions necessary for performing security-related operations, including access to CloudTrail logs, Config history, and other security monitoring tools. This policy is suitable for SOC engineers who need to investigate security incidents and make configuration changes to improve security posture.
Full Access to Monitoring and Alerting Tools: SOC engineers may require elevated permissions compared to analysts to configure and manage monitoring and alerting tools effectively. Grant them permissions to create and modify CloudWatch alarms, configure GuardDuty settings, and access detailed CloudTrail logs for forensic analysis.
Limited EC2 and VPC Permissions: In addition to the permissions granted to analysts, SOC engineers may require permissions to manage EC2 instances and VPC configurations for deploying security tools and performing network analysis. However, restrict permissions to sensitive actions such as instance termination and VPC deletion.
- SOC Manager: IAMReadOnlyAccess, AWSCloudTrailReadOnlyAccess
Provides read-only access to IAM resources and CloudTrail logs, allowing SOC managers to oversee user permissions, audit trails, and compliance-related activities without the ability to modify resources directly. Additionally, you may want to customize permissions based on specific managerial responsibilities.
Admin-Level Access: SOC managers may need broader access to AWS resources to oversee SOC operations and manage security incidents effectively. Assign them IAM policies with administrative-level permissions, such as the AWS managed policy "AdministratorAccess" or a custom policy with equivalent permissions.
Full Access to Security Tools: Provide SOC managers with full access to security monitoring and management tools, including the ability to configure and fine-tune settings for CloudWatch, GuardDuty, and other security services.
Limited IAM Permissions: While SOC managers require administrative access to AWS resources, limit their IAM permissions to prevent unauthorized changes to user accounts, roles, and policies. Grant permissions only for IAM actions necessary for managing user accounts and access permissions within the SOC team.
- SOC Administrator: AdministratorAccess
Grants full access to all AWS services and resources, allowing SOC administrators to perform tasks such as provisioning resources, managing IAM users and roles, configuring security settings, and responding to security incidents effectively. This policy should be assigned with caution due to its broad scope of permissions.
IAM Management: Assign IAM policies that allow SOC administrators to create, modify, and delete IAM users, groups, roles, and policies as needed. This includes permissions to manage user passwords, access keys, and MFA devices.
VPC and Security Group Management: SOC administrators may require permissions to manage VPC configurations and security groups for network segmentation and access control purposes. Grant them permissions to create and modify VPCs, subnets, route tables, and security group rules as necessary.
From the IAM Dashboard side panel:
Click on Roles
Click on Create role
Trusted entity type: AWS account
An AWS account: This account | Require MFA
- This specifies that the role can only be assumed by IAM users of this account.
- It requires MFA for additional security. Click Next
Add Permissions page
You can add whichever AWS managed permissions you want to attach to the role.
You'll be typing which AWS managed policies you'd like to add to the current role.
Here are the AWS Managed Policies that each role should have:
- SOC Analyst: AmazonEC2ReadOnlyAccess, AmazonVPCReadOnlyAccess, IAMReadOnlyAccess, CloudWatchReadOnlyAccess
- SOC Engineer: SecurityAudit
- SOC Manager: IAMReadOnlyAccess, AWSCloudTrailReadOnlyAccess
- SOC Administrator: AdministratorAccess
Name, review, and create page
Role Details
Role name: SOC_Analyst | SOC_Engineer | SOC_Manager | SOC_Administrator
Select trusted entities: here you can edit the policy to allow the user to assume the role.
Click Create Role
Navigate to the Roles page.
Click on the desired role from the list.
In the Summary section, you'll find the link to switch roles. Click on the copy icon.
Open a new tab in your browser, and paste the copied link.
You should be directed a Switch Role page. The fields are automatically populated.
Click Switch Role
Follow the same steps for the other 3 roles.
AWS Console Home Page
In the Search bar, type IAM.
Click on the IAM service.
From the IAM Dashboard side panel:
Click on User groups
Click on Create group
Create User Group page
Name the group
User group name: SOC_Admins
Add users to the group
Click on the users that should have this group's permissions.
Attach permissions policies
Select the policies that will give this group required permissions.
Type them into the search bar for quick visibility.
For SOC_Admins, this will be:
AmazonVPCFullAccess, AmazonEC2FullAccess, AmazonS3ReadOnlyAccess, CloudWatchFullAccessV2, AWSCloudTrail_FullAccess, IAMReadOnlyAccess, AWSArtifactReportsReadOnlyAccess
Click Create user group
Users selected for the SOC_Admins policy will have
Congrats! You've just created the User Group SOC_Admins.