Identity and Access Management (IAM) is one of the most important and challenging components of the software system. The lack of proper identity and access management in our application may lead us to a software disaster be it in terms of security, application usage, or programming.
AWS has done a really impressive job in that aspect. AWS IAM is undoubtedly the major component of security AWS offers to its consumers. This blog focuses on the takeaways we, as developers, can get from AWS IAM implementation.
To explain each takeaway better, I am going to draw the analogy of access management of AWS IAM with a ToDo app with the following fields.
The application should be divided in such a way that all the entities should have different access. In AWS, services have different granular level access controls. The action items associated with secret manager are:
- GetRandomPassword ... and so on
In the same way, other services provided by AWS have different action items and access controls. If a user is granted the access of CancelRotateSecret in secret manager, they will have the access of that particular action item only and not of others.
The possible action items associated with the ToDo app are:
- List all the ToDos
- Create a ToDo
- Retrieve a single ToDo with identifier
- Update a single ToDo with identifier
- Delete a single ToDo with identifier
The above illustrates a basic list of access that can be associated with the ToDo app. According to the complexity of software applications developed, the accesses can be defined.
Individual or Group Access
Both individual users and groups can be granted access to action items for application services to utilize. In AWS IAM, it is possible to create a user to whom access is given. It is also possible to create a group with access controls and add individual users to the group. In the context of the ToDo app, the possible groups are:
In the table above, users: Person A and B are in the group: Developer. The access provided through group accesses is i. List all the ToDos, ii. Retrieve a single ToDo with identifier and iii. Create a ToDo. If Person A is to be given access to create a ToDo without other users in the developer group having the access, the user-level access control should be given to Person A.
Group access saves the time of admins having to grant access to each newly added user to the system.
User-defined or Built-In Access controls
In a complicated system like AWS, there is a high chance that admins get confused because of hundreds and thousands of access controls. The admin might have to go through the documentation and add multiple action items of a single resource for granting access to a small task to a user in their group. Therefore, as a system like AWS, providing the flexibility to admins to use built-in access controls or create their own controls is a good design of the IAM.
For example: In AWS IAM,
arn:aws:iam::aws:policy/IAMReadOnlyAccess is an AWS managed policy (built-in policy) with following actions attached:
Admin of AWS infrastructure can directly attach an above-mentioned policy to a user or group. If such built-in policies are not available in the access management policies, an admin can create an inline policy(user-defined) for granting the access.
Least privilege model
By default, all the users in the software application should be denied access to resources. The admin should explicitly grant the user access to resources or add the user to the group. For example: If Person E is added to the development team of software ToDo, the admin might decide to add them to the Developer group. This way, there are few security risks and accidents as users are provided access only if required.
These are some of the takeaways we can implement in our system. If you are thinking of more, feel free to share.