Identity and Access Management in AWS DevSecOps

Amazon Web services (AWS) is a trailblazer in the cloud platform space and purpose-built for DevOps. Its rich feature set provides developers with the tools needed to build sophisticated development, deployment, and operations DevOps pipelines. To mitigate the risk introduced by accelerated development and delivery cycles, AWS provides two powerful security features that every organization should prioritize - leveraging access controls to manage user access policies and creating security policies to control user privileges.

Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) service allows you to centrally create and manage multiple users and application accounts by assigning each its own username and password and, optionally, a multi-factor authentication method. Most importantly, AWS can also use federated authentication so that you can use single sign-on (SSO) to access your AWS accounts using credentials from your corporate directory.

IAM controls access through identities which are those users or services that will access your AWS resources. These identities can be:

• AWS Root User - this is the primary account used to sign up for AWS services. It is the most sensitive account and should only be used initially to establish individual administrator accounts.
• IAM Users - are the basic accounts you establish for users and services, sometimes called principals, to access resources. It is a user account that authenticates to AWS either through the web console, via API, or using the CLI to gain access.  
• IAM Groups - a collection of users that makes it easier for bulk management
• IAM Roles - similar to a user but meant for temporary permissions. For example, if an EC2 instance needs to perform a task, you can use a role to give that instance the necessary permissions until no longer required or the instance stops.

IAM Policies

In AWS, managed policies are a good opportunity to practice the Principle of Least Privilege (POLP). They provide precise control over many actions you can perform on AWS. Since every user starts with no privileges, they let you establish only the minimal rights required for any specific user, group, or role. Policies are critical for DevSecOps as they allow for the quick assignment and consistent management of security privileges across an account’s resources.

There are three primary types of managed policies you can use:

1. AWS managed policies - pre-built policies created and managed by AWS. They provide quick access to common roles and job functions. AmazonEC2ReadOnlyAccess and SecurityAudit, for example, are two AWS-managed policies.
2. Customer managed policies - custom policies you build to provide more granularity or mixed roles that the AWS managed policies do not cover.
3. Inline policies - allow you to embed a custom policy directly in a principal entity, such as a user, group, or role. You should avoid using Inline policies as they do not provide the reusability, change management, versioning, and delegation that customer-managed policies offer.

Securing Resources with IAM

Mostly everything you do in AWS is based on accessing a resource such as S3 Buckets, EC2 Instances, or Route 53 zones. IAM policies restrict access to resources based on services, actions available in hose services, and resources that can be acted upon. For example, you could create a policy for S3, which is a service that allows only privileged users to perform the upload, which is an action, of new files to a specific bucket, which is the resource.

To properly secure a DevOps pipeline on AWS, determine the groups and roles necessary for each task, and assign users to the appropriate groups. Next, attach either AWS-managed policies or create custom policies for each group. To assist you in creating and testing policies, you can use the AWS policy generator and the AWS Policy Simulator. For existing users, groups, and roles, you can use the Access Adviser tab for the principal to view which services they have accessed. This allows you to refine access rights and remove permissions to services and resources never accessed.

While IAM should be the primary method of establishing security policies, individual services often have their own security considerations. For example, EC2 has security groups for controlling access to network ports. OpsWorks lets you designate who has sudo and SSH access in Linux and RDP access in Windows. And resource-oriented services such as S3 are better suited for defining permissions at the resource itself.

Permissions Boundaries

Part of the effectiveness of DevOps is the blurring of the line between development and operations teams. Often, this means delegating the ability to create and manage users, resources, and permissions. However, you don’t want to make every user an administrator. Permissions boundaries allow you to delegate permissions but set limits on the extent of those permissions. AWS enforces these limits, even if granted permission beyond those limits, given by an attached policy. You can, for example, provide a development group administrative access but limit the boundaries of that access to a single AWS service. Permission boundaries help limit permissions to prevent accidentally or intentionally granting a user too many permissions.

Security with Tags

IAM uses an authorization model called role-based access control, or RBAC. RBAC allows you to define permissions based on groups and roles rather than individually managing each user’s permissions. However, RBAC can be cumbersome in rapidly growing or changing DevOps environments.

Through the use of tags, AWS provides a form of attribute-based access control (ABAC) to provide more dynamic and easier-to-manage permissions for complex environments. These tags are attributes you assign to both principles and resources to describe their roles, jobs, departments, location, projects, or any other attributes that make sense for your organization.

Furthermore, you can automatically link tags based on attributes in your authenticating directory if using federated authentication. The process is relatively simple: create a policy that requires both a user and resource to be tagged with the same attribute values. Therefore, you can place a user in a group such as database administrators, but they will only have access to those databases with matching tags. Using tags can significantly simplify managing permissions, requires fewer policies, and provides granular permissions that help follow the principles of least privilege.

Much of information security focuses on protecting resources. Typically, this begins with authentication and authorization, identifying users through their credentials, and determining which resources they can access. Getting this right within AWS is critical to protecting your enterprise.

About Ed Adams, CEO

Ed Adams is a software quality and security expert with over 20 years of experience in the field. He served as a member of the Security Innovation Board of Directors since 2002 and as CEO since 2003. Ed has held senior management positions at Rational Software, Lionbridge, Ipswitch, and MathSoft. He was also an engineer for the US Army and Foster-Miller earlier in his career.

Ed is a Ponemon Institute Research Fellow, Privacy by Design Ambassador by the Information & Privacy Commissioner of Canada, Forbes Technology Council Member, and recipient of multiple SC Magazine’s Reboot Leadership Awards. He sits on the board of Cyversity, a non-profit committed to advancing minorities in the field of cyber security,  and is a BoSTEM Advisory Committee member.