If you're working Amazon internet Services (AWS), it's necessary to know AWS Identity and Access Management (IAM). IAM enables you to regulate access to AWS resources.
AWS Identity and Access Management (IAM) is a web service for securely controlling access to AWS services. With IAM, you can centrally manage users, security credentials such as access keys, and permissions that control which AWS resources users and applications can access.
Img credit: AWS
Enable MFA
Use IAM roles to provide temporary credentials for human users and workloads using your AWS services. MFA should be required for added protection in situations where you need IAM or root users for your account. Users that utilise MFA have a device at their disposal that can respond to an authentication challenge. To sign in, each user must provide their credentials and a device-generated response.
Access resource using IAM roles (Choose IAM Roles over IAM Users)
The handling of credentials is made easier by IAM roles. You may reduce your concern over key rotation and the possibility of your credentials ending up in the wrong hands by always utilising temporary credentials. Furthermore, by letting AWS handle the management of your access credentials, you may avoid developing the systems necessary for encrypting and decrypting credentials when they need to be shared among several workstations.
Use AWS Single Sign-on/AWS IAM Identity Centre
Provide users with single sign-on access to all of their assigned Amazon Web Services (AWS) accounts and business apps from a single location with the help of AWS SSO, which makes it simple to centrally manage access to several AWS accounts and business applications.
AWS SSO is tightly integrated with AWS Organizations, and runs in your AWS Organizations management account. This integration enables AWS SSO to retrieve and manage permission sets across your AWS Organizations configuration.
Rotate access keys
Create temporary credentials rather than permanent ones like access keys. However, it is advised to rotate access keys, with the exception of access keys for external plugins, service accounts for the CICD tool, and other service accounts where you need IAM users to have long-term credentials and programmatic access.
Follow least privilege permission principle
You may create rules based on your access activity that is recorded in AWS CloudTrail to provide just the permissions necessary to complete a job. IAM Access Analyzer creates a fine-grained policy for you after examining the services and operations that your IAM roles use. Each created policy may be tested before being deployed to your production system. By doing this, you can make sure that your workloads only receive the rights they need.
In the DevOps environment, the security team's responsibility is to give developers the resources and tools they need to carry out their duties securely and within the bounds of what is permitted.
Least privilege role design states that every specific IAM policy should only allow the following actions:
- Actual use throughout the access time
- Are allowed to utilise the activities in accordance with their function or corporate policy.
Effective use IAM Access Analyzer
IAM Access Analyzer policy validation may be used to verify your policies to make sure they follow IAM best practises and the IAM policy language (JSON). To assist you in creating safe and useful rules, IAM Access Analyzer offers more than 100 policy checks and actionable recommendations.
By examining the resource-based policies connected to the cloud resources inside your zone of trust, Access Analyzer assists you in identifying possible security issues in your AWS environment. Access started by principals established inside your zone of trust (i.e., your AWS account) is regarded as trustworthy. IAM Access Analyzer generates a finding if it discovers a policy that permits access to your resources from outside of your zone of trust. To ascertain if the access is planned or accidental, you may utilise the information provided by the finding, such as the name and type of the resource, the access level, and the external principal who has access to the resource.
Organization service control policies (SCPs)
SCPs can be used to manage permissions in your organization, but not to grant permission. SCPs, a feature of AWS Organizations, let you to designate the highest level of permissions for member accounts inside the organisation. You may limit the AWS services, resources, and specific API operations that the users and roles in each member account can access by using SCPs. Additionally, you may provide criteria for when to limit access to AWS services, resources, and API operations.
SCPs can be attached to the organization root, OUs, or individual accounts. However try to attach SCPs at OUs rather than to individual accounts as best practice. AWS strongly recommends to not attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts.
E.g. SCP to deny changes to GuardDuty
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyGDResourceAccess1",
"Effect": "Deny",
"Action": [
"guardduty:UpdateDetector",
"guardduty:DeleteDetector"
],
"Resource": "arn:aws:guardduty:*:*:detector/admin-detector-*"
},
{
"Sid": "DenyGDResourceAccess2",
"Effect": "Deny",
"Action": [
"guardduty:DisassociateFromMasterAccount",
"guardduty:StopMonitoringMembers"
],
"Resource": "*"
}
]
}
IAM permissions boundaries
A permissions boundary is meant to limit the rights granted to IAM principals, such as roles, so that they do not exceed the scope of the original design. The permissions boundary restricts access using an AWS or customer controlled policy, and because it contains resource, action, and effect statements, it is comparable to other IAM policies you are already acquainted with. Access to anything is not granted by a permissions barrier alone. Instead, it enforces a limit that cannot be crossed, even if other policies related to the job give larger rights. Permissions restrictions serve as a preventative barrier rather than something that identifies and resolves a problem. You can give rights using identity-based policies or resource-based rules (like S3 bucket policies).
"Sid": "AllowRoleCreationWithAttachedPermissionsBoundary",
"Effect": "Allow",
"Action": "iam:CreateRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::<YourAccount_ID>:policy/<DevelopersPermissionsBoundary>"
}
}
I hope this blog helps you to learn. Feel free to reach out to me on linkedin or twitter-@YogeshS4289 or comment in the blog. If you like my blog please don't forget to like the article. It will encourage me to write more helpful articles.
Top comments (0)