Permissions allow you to control who has access to what and under what conditions. Permissions for people and machine identities that require access to AWS and your workload should be carefully managed to improve your security. In this article, we will discuss AWS recommended best practices on permissions for both people and machines.
- Defining access requirements nEach one of the components or resources that make up the whole of your workload needs to be accessed by different parties, such as administrators, end-users, or other components. The first step to strengthening your security should be to have a clear understanding of who or what needs to have access to each component in your workload. Then, you should choose the appropriate identity type and method of authentication and authorization. You should define resource access and its conditions based on the user’s job function, role, and responsibilities. Grouping users with common requirements together will make the delegation of policies easier.
Useful resources:
IAM use cases,
Keep Reading | ,6 ways to seeking to optimal performance on AWS - Granting least-privilege access nOnly least-privilege access should be granted. This means that each user or machine should only have access to those resources that are absolutely necessary for the performance of their tasks, no more and no less. You can rely on groups and identity attributes to dynamically set scalable permissions rather than defining permissions for each individual user. nnYou should also make a habit out of removing unnecessary permissions regularly. In addition, you should consider permission boundaries. These are advanced features for using a managed policy that sets the maximum permissions an identity-based policy can grant to an IAM entity. An entity’s permissions boundary will be able to ensure the said entity is able to perform only the interactions that are allowed by a combination of their identity-based policies and their permissions boundaries. Lastly, you should consider leveraging tags to control access to any of your AWS resources that support tagging. IAM users and roles can also be tagged to control what they can access.
Useful resources:
Grant least privilege
Reducing policy scope by viewing user activity
View role access
Attribute-based access control (ABAC) - Establishing emergency access processesnIn the unlikely event of an automated process or pipeline issue, there should be a process in place that allows emergency access to your workload. While you will be relying on least privilege access most of the time, having an emergency access process established will ensure that users can obtain the right level of access when they need it in an emergency situation. The best way to do this is to pre-provision a role for emergency access from a trusted account, for example, one that is in use by the security team. This will help you gain access quickly in a threatening scenario so that you can respond in a timely manner.
Useful resources:
Tutorial: Delegate Access Across AWS Accounts Using IAM Rolesn - Reducing permissions continuously nIt is best practice to regularly review your teams and workloads to determine access needs. Permissions that are no longer in use should be removed and replaced with new processes to achieve least-privilege permissions. Unused identities and permissions should be continuously monitored and reduced to improve security. You can achieve this by configuring IAM Access Analyzer, which helps you identify the resources in your organization and accounts that are shared with an external entity. nn
Useful resources:
AWS IAM Access Analyzer - Defining permission guardrails for your organizationnYou should establish common controls that restrict access to all identities in your organization. You can, for example, prevent members of your team from deleting common resources. You should take into account your organization’s unique requirements to define common restrictions that apply to every entity in your organization. To do this, you can use AWS Organizations.
Useful resources:
AWS Organizations Service Control Policies - Managing access based on life cycle nAccess controls should be integrated with operator and application lifecycle and your centralized federation provider. This means, for example, that a user’s access will be removed when they leave the organization or change roles. You should implement a user access life cycle policy for all possible situations, including new users joining, job function changes, and users leaving to facilitate that only current users have access.
- Analyzing public and cross-account accessnYou should continuously monitor findings highlighting public and cross-account access. Only resources that specifically require it, no matter if they are people or machines, should have public or cross-account access. To make sure this is the case, you can use IAM Access Analyzer, which helps you identify the resources in your organization and accounts that are shared with any external entity.
- Sharing resources securely nThe consumption of shared resources across accounts or within your AWS organizations should be carefully monitored and kept under control. You can achieve this by using AWS Resource Access Manager (RAM), a service that enables you to easily and securely share AWS resources with any AWS account that is part of your organization.
Useful resources:
AWS Resource Access Manager
