About the Client
A leading Australian telco engaged Sourced Group an Amdocs Company (Sourced) to support its maturation of cloud security on Amazon Web Services (AWS). This ongoing partnership involves close collaboration between Sourced and the client’s in-house team to identify and prioritise areas for improvement.
In this case study, user permission management was singled out for an uplift utilising AWS Security Best Practices.
Challenge: Improving User Permissions Management in a Large and Complex Environment
With a complex and large environment, as well as a history of some manual processes, the management of user permissions was struggling in two key areas:
- Management of Permission Guardrails using AWS Security Control Policies (SCPs) : Over a number of years the number of accounts within the AWS Organization had risen to over 250, including a range of workload accounts and foundational accounts arranged by Organization Units (OUs). These OUs had multiple SCPs attached providing guardrails common across the organization and bespoke to the OU. A manual process of managing these SCPs had become ineffective as proposed changes were not tested and were inconsistently applied, sometimes leading to production impact as misconfigurations occurred.
- Identification of appropriate roles for users: The customer used prebaked roles that were available in each AWS workload account, as well as roles developed for individual accounts. Users were struggling to select the correct roles when requesting access. This would lead to delays as developers would have to reapply when they found they had the wrong set of permissions or would consume the time of the platform team as they frequently raised requests as to why they could not perform some actions.
Solution: New Procedures Boost Control and Enhance Visibility
Sourced developed and delivered a solution which made best use of AWS capabilities to minimise risk without compromising users’ productivity and efficiency.
For SCP management a clear process was developed and documented on the customer wiki for requesting and execution of deployment of SCPs into OUs and accounts. This included:
- Proposed code changes to SCPs are raised in a git repository, reviewed by the security team and then pushed into a development branch. Code is written using AWS CloudFormation Templates.
- AWS Code Pipeline running in a restricted automation account, picks up the code change and, using AWS CFNGuard, ensures there are no security concerns before assuming a deployment role within the AWS management account . This assumed role deployed the SCPs via CloudFormation to a set of test OUs and development environment OUs.
- Testing is conducted in accounts within the OUs, including basic functional testing and user acceptance testing. These SCPs are then left in place for a minimum of 24 hours as an additional safeguard as any issues that might be raised would be quickly identified in an environment that does not impact production systems.
- Once testing is complete and the changed has been signed off, the code change is pushed to the production branch, where AWS Code Pipeline then deploys the SCP changes to the production OUs via CloudFormation in the management account.
Next, steps were taken to strengthen and streamline processes surrounding permissions granted to individual roles, following the AWS Best Practise principle of minimum privilege. Key to this was improving transparency. Sourced introduced measures enabling the client to clearly see the effective overall permissions for any deployed IAM role which lead to the user being able easily compare the permissions of different roles. This involved:
- Gathering data from all accounts around roles, attached policies, boundary policies and SCPs applied to those accounts. This was achieved through a python script running in a AWS Elastic Container Service (ECS) container. The script would assume an IAM audit role deployed to every account via CloudFormation StackSets, query the account for roles, gather permissions (including boundary permissions). Lastly it would gather SCP permissions from the management account.
- The Python script would then analyse the permissions by role and determine the effective set of permissions for that role, before storing this data in an Amazon RDS Postgres database. This was repeated on a weekly basis.
- Code was then written as a plugin for a dashboard running out of ECS that provided a self-service menu for users to look at and compare roles before they requested access for the correct role.
Outcome: Strong Foundations for Compliant Container-led Migration
Effective implementation of cloud-native approaches and proven AWS Best Practices enabled us to drive the maturation of a critical aspect of cloud security for this customer. Some of the outcomes for the customer this has achieved includes:
- Streamlining a complex permissions structure, improved visibility, and raising the bar on security measures surrounding access management.
- Developers able to work with greater confidence and velocity, managing their own permissions within the boundaries defined by guardrails.
- Platform support teams able to work with greater efficiency and less time wasted on repeated requests for explanation of permissions by users.
- Addressing some of the risks in the IT Risk Register related to misconfiguration impacting security and business.
