Amazon Web Services (AWS) Role and Policy Governance

Vibhuti Sinha

Vibhuti Sinha

Chief Product Officer, Workforce Identity & Intelligence
83AWS-Role-and-Policy-Governance-Guiding-Principles-blog-768x518

AWS IAM Policy and IAM Roles lay the foundation and form the core of “Access” on AWS objects. From an Identity Governance and Administration view , AWS Policy and Role objects are fine grained entitlements and thereby should follow and adhere to entitlements lifecycle processes.

Considering the large number of AWS Accounts in an enterprise losing control of “Who has access to what” and “What does that access secure” via AWS Policies and Roles is incredibly easy.

In the absence of a robust and well-defined governance framework, getting “Access Visibility” and “Controlling Access” in the AWS ecosystem for Security Administrators can become a really daunting task. 

This post lays down some of the key challenges in this area. It also attempts to lay out the evaluation criteria / guiding principles while designing/evaluating solutions/frameworks for IGA (Identity Governance and Administration) products.

1. Aim for “Stars”

Problem Statement – Let’s accept the fact, that policy statements like below are a given and will continue to exist considering “Speed of Delivery” often supersedes beyond everything.

“Statement”: [

{

“Action”: “ec2:*”,

“Effect”: “Allow”,

“Resource”: “*”

}

Solution – Custom Solutions/frameworks/Products should pull and mine AWS policies which “defines star based resources or actions” and then trigger workflows/actions for administrators to remediate such policies.

“Minimal Access on Targeted Resources with specific Actions” is the mantra for effective Policy design”

2. Prevention of Roles and Policies Explosion

Problem Statement – Creation of run time/dynamic/fine-grained AWS policies via AWS SAML feature is not feasible

Quint Van Deman, rightly mentioned in his AWS reinvent session (Watch the Video) – “Choose a custom identity broker if you prefer to increase federation involvement for the ultimate control”

Organizations access needs on AWS evolve over a period of time and usage of dynamic policies become a necessity eventually.

Solution – Investing in a Custom Identity Broker becomes imperative if your AWS ecosystem requires “dynamic policies” and “complex access decisions” thereby preventing the proliferation of Roles and Policies in your AWS accounts

3. Policy and Role Ownership

Problem Statement – Concept of “ownership” do not exist in AWS.  Creating an IAM policy to assign permissions for AWS IAM objects is a crude way to manage ownership.

Managing roles and policy changes via assignment of owners is critical from a governance standpoint to ensure only the “authorized” set of owners/users can perform “CRUD (Create/Update/Delete)” or “Role/Policy Assignment” operations in AWS

Solution – Frameworks/products should allow to define single/multiple owner/s for AWS policies and Roles.  The owners would eventually be responsible for the lifecycle of roles, policies, their associations and assignment to AWS or federated users/groups

4. Automated Provisioning from AD Groups to AWS Roles

Problem Statement – Federation setup including providers and roles is basic and requires manual setups in AWS. Needless to say, this limits the scalability for enterprises having large number of AWS Accounts

Provisioning of users to AWS ecosystem need to follow similar principles and process as per the onboarding processes to any enterprise application, for ex. Active Directory.  Needs to be automated, workflow based with approval and escalation stages.  Changes to AWS access (assignment to roles or policies) should be automated and triggered based on certain events viz. Change in User’s Role, department transfer etc.

Solution – Frameworks/products should support automated provisioning and mapping of AD groups to AWS Roles, as part of the user’s onboarding workflow. Detection of HR events like job code change, should lead to automated trigger of access rules which lead to changed access on AWS objects.

5. De-Provisioning of AWS Access

Problem Statement – Non-Federated AWS Environments require manual steps for de-provisioning of AWS Users and their access on AWS objects

Consider users having separate enterprise identity and AWS identity. In case of de-provisioning of such users from HR system in the event of termination or job change, can lead to “Residual Access” in AWS and has to be removed manually.

Solution – Frameworks/Products should support integration of HR accounts and their association to AWS User Accounts, Policies and Roles to ensure a “cleaner and automated de-provisioning process  “

6. Attestation of AWS policies and Roles

Problem Statement – Attestation of AWS policies and Roles feature is absent in AWS

From a governance standpoint, attestation lifecycle which are Periodic, Policy and Role Owner based or Event Based is critical to ensure only authorized users are getting access to AWS Objects. However, with the significant number of AWS accounts, large number of policy objects and roles, this process can easily turn into a “Rubber-Stamping” process.

Solution – Frameworks/Products should support intelligence with their attestation and certification processes by inducing peer and outlier analysis and associating risks to your AWS policies and roles.  This empowers approvers to make right decisions while attesting for the access to and reducing the overhead of a typical attestation lifecycle for AWS accounts.

7. Privileged Role and Policy Monitoring

Problem Statement – Roles and Policies cannot be defined as high privileged by default in AWS. Also, monitoring the same for changes using CloudTrail logs is extremely difficult and time consuming

Risk Score/Definition needs to be defined based on the resources and actions which a policy defines and the roles which are associated to such policies or critical AWS Accounts (cross-account roles).

Solution – Frameworks/Products should support defining “metadata and glossary definition” to AWS Roles and Policies provide a very powerful view of the “kind-of” access a Policy or Role provides.  Based on the access permissions,  AWS Roles and Policies should be classified, tagged and then monitored for changes.  Monitoring changes to AWS policies, would certainly require integration of the framework/product with CloudTrail using BigData technologies viz. Spark, ElasticSearch.

Hope this post helped you in understanding the challenges and also give an idea on the design principles.

Schedule a Demo

Ready to see our solution in action?
Sign up for your demo today.

Saviynt named a Gartner® Peer Insights™ Customers’ Choice: IGA Learn More >