The first pillar for well-architected AWS cloud security — IAM (identity access management)
This is the second in a series of seven on the five pillars for well-architected AWS security. For the entire series, visit the Five pillars – AWS blog page here.
Traditionally, customers look at IAM from the standpoint of users. Users, which can be further categorized into groups, will also have associated roles, and permissions associated to these roles.
Even within similar organizations – example, a company may have multiple groups within a larger development organization, with different permissions associated both to the roles those users have and the groups to which they belong. It is not necessarily a linear relationship.
Similarly, companies in the cloud have come to understand that services can be subject to the same IAM as users. This is an important construct when organizations look to leverage cloud services for transformation – those services need to be understood in terms of how they are accessed and managed.
Within AWS, IAM will allow authorized IT administrators to take action on specific resources and provide those administrators with visibility and control across that whole infrastructure. This can quickly get complex, with hundreds of organizations, workgroups, and projects. IAM becomes the first “window” into who’s doing what.
In the AWS infrastructure, privilege management is primarily supported by the AWS Identity and Access Management (IAM) service, which allows you to control user and programmatic access to AWS services and resources. Within AWS, you should also require strong password practices, such as complexity level, avoid re-use, and enforce multi-factor authentication (MFA).
Traditionally, customers look at IAM from the standpoint of users. Users, which can be further categorized into groups, will also have associated roles, and permissions associated to these roles.
Even within similar organizations – example, a company may have multiple groups within a larger development organization, with different permissions associated both to the roles those users have and the groups to which they belong. It is not necessarily a linear relationship.
Similarly, companies in the cloud have come to understand that services can be subject to the same IAM as users. This is an important construct when organizations look to leverage cloud services for transformation – those services need to be understood in terms of how they are accessed and managed.
Within AWS, IAM will allow authorized IT administrators to take action on specific resources and provide those administrators with visibility and control across that whole infrastructure. This can quickly get complex, with hundreds of organizations, workgroups, and projects. IAM becomes the first “window” into who’s doing what.
In the AWS infrastructure, privilege management is primarily supported by the AWS Identity and Access Management (IAM) service, which allows you to control user and programmatic access to AWS services and resources. Within AWS, you should also require strong password practices, such as complexity level, avoid re-use, and enforce multi-factor authentication (MFA).
To develop a well-architected IAM pillar, customers must:
- Manage credentials and authentication
- Control human access
- Control programmatic access
To read more on AWS Well-Architected Cloud Security, visit Managing Credentials and Authentication in the AWS Well-Architected Labs documentation series.
Next week we’ll take a look at Detective Controls and how they are implemented in AWS. To follow this series in its entirety, visit the Five Pillars – AWS blog page here.
Search the blog
Subscribe to the Barracuda Blog.
Sign up to receive threat spotlights, industry commentary, and more.
