Correctly Managing Access Requires Rigor
Account access has long been seen as a key security vector. AWS best practices dictate organizations should follow the principle of “least privilege”—users of AWS accounts should receive privileges that allow them to perform only their required tasks.

In practice, this has meant organizations wishing to follow this principle needed to establish an access policy governing who can access what, then task a team or individual with the responsibility of enforcing it.

This means they will receive requests for access to various AWS accounts for all manner of (valid) reasons, in all manner of permutations. For example:

  • A new employee is onboarded to Development Team A.
  • Dev team A needs write access to their AWS accounts, but read-only access to the rest of the AWS accounts owned by the business.
  • A developer from Dev Team A has been seconded to work on a project with Dev Team B, so needs write access to that team's AWS accounts, as well as their existing access to Dev Team A.
  • This developer then resigns, so needs to be offboarded from all the AWS accounts for which they had any access.
  • Meanwhile, the finance team needs access to all AWS accounts in order to correctly report on expenditure.
It can get complicated. Depending on the level of rigor applied, managing any of these changes could take a day or week per account. This can lead to two things: a high level of operational overhead, and inevitable mistakes—which in turn make security breaches more likely.

The Risk of Misconfiguration
An attacker only needs access to one over-permissioned account to wreak havoc. Misconfiguration of access policies is dangerous, but easy to do, and the result is a team member who has access to too many AWS accounts or not enough. In another scenario, when a developer leaves their role, their access is not revoked. This is a big problem in the industry: more than 40% of AWS roles were reported as inactive or over-permissioned, according to one report.

As well as a risk of external attackers, there is also the ongoing risk that comes from human error. An inexperienced engineer or non-specialist who has too much unnecessary access to critical systems could cause major problems with your AWS environment. We don’t want finance team members to have access to production workloads, just as we don’t allow engineers to have access to company budgets.

Permission Sets Streamlines Access Management in AWS
We have released a new feature for Stax aimed at solving this issue: Permission Sets. The feature allows for the granting of tailored levels of access for users who log in to Stax-managed AWS accounts. The aim is to make it easier to manage AWS access, reduce the overhead and level of complexity, and help companies to make AWS access more closely mirror organizational structure.

Learn more about how the feature works in our documentation.

If managing access has been a source of frustration or confusion, and you’re worried about the security risk if you get it wrong, get in touch with our team to learn more, and to request a demo.
By Lucas Chan Read Stax Product Owner Lucas Chan's insights into major issues surrounding access in AWS.