Powerful identity and access management (IAM) models of public cloud providers like AWS, Microsoft Azure, and Google Cloud platform; enable the deployment of applications and data with far greater protection than what is possible in traditional cloud security. However, these IAM solutions are not without risk when misused. The risk is very different (and sometimes much higher) than old-world enterprise IAM leading to identities becoming the new perimeter.
We are going to outline some of these differences and risks
For many years, defense in depth was dominated by network controls. Traditional network security controls remain an essential component of public cloud security, but they aren’t sufficient. AWS, Azure, GCP, and others offer a rich service portfolio that exposes pubic HTTPS endpoints by default. IAM controls are the primary method of protection. However, not all of these services allow IP based access control list (ACL) rules. Additionally, IP based ACLs are coarse and inflexible controls for modern microservice-based cloud applications. The foundation of information security is in the public cloud focuses on identity-based security that controls access to cloud-based resources and data. Security professionals recognize that “identity is the new perimeter” for securing data in public clouds, and consequently, proper identity security is crucial to managing access related errors. At Sonrai security we offer updated webinars to guide you on this journey of cloud security. Public cloud IAM models introduce many identity-to-data trust relationship configuration options that, although powerful, can come with risk. For example, poorly used access IAM controls leave significant attack vectors to sensitive data. The public cloud IAM examples below are based on AWS, but similar options exist on Microsoft Azure and GCP.
Excess privilege and privilege escalation risks are higher with public cloud
In a public cloud, highly privileged users can ‘delete’ your infrastructure, data, and backups necessitating data governance to govern usability, availability, and data security. An AWS user with a granted permission like iam: AttachUserPolicy (and many others that enable the creation/modification of users, groups, keys, policies, roles, etc.) can quickly self-escalate privilege or grant more access to other users or resources. This powerful AWS permission has been recognized by security teams as one to fully understand and manage because it can quickly introduce a security risk. After all, the person with the permission “can escalate their privileges by attaching the Administrator Access managed policy to themselves, giving them the full access to the account.”
The highest identity risk lies with “entities,” not users
The ability to delegate roles can become quite problematic in a public cloud. Management controls must be adapted to address concerns around privilege delegation to an EC2 compute instance or Lambda function. Compute, containers, and serverless functions in AWS can assume a role that is configured with permission to perform specific tasks and access certain data.
Here’s an AWS lambda get function example:
“A user with the iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction permissions can escalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the relevant AWS library to their programming language of choice, then use it to perform actions of their choice. The code can then be run by invoking the function through the AWS API.”
Granting an assumed role to a service can be your friend when your public cloud is architected correctly by a knowledgeable IT security and cloud team. It eliminates the unfortunate programming habit of storing service account credentials in configuration files or worse in the code. However, the delegation of a dominant role to a service must be fit for purpose with a focus on least-privilege.
Relationships and delegation rules are as meaningful as individual IAM policies
The AWS IAM model allows for numerous delegation options across cloud accounts or services that can introduce complex attack vectors. For example, a user in one account with an unrestricted STS: AssumeRole permission will get access to a role in another account that trusts the account of that user. A simple mistake is allowing this type of trust relationship from a development account to the production account.
Delegated trust relationships on AWS needs to be understood so that potential risky configurations are eliminated.
Global policies add a dimension to identity that must be modeled
AWS service control policies (SCPs) enable a company to define an overarching set of policies across an organization. AWS SCP policies are a powerful way to exert global control and to restrict services and sandbox type accounts. On the flip side, global policies have limitations in the agile cloud world where a policy change could expose an obscure risk in another account. A full picture of risk is not possible without understanding interactions between account-specific policies and global SCP policies. Microsoft Azure and Google Cloud Platform have similar universal control mechanisms.
Identity policy requires an understanding of conflict resolution rules
Another wrinkle in the flexible AWS IAM security model provided is that conflicts can arise between access policies and resource policies (for example, AWS S3 bucket policy). Automated logic defined by AWS will determine which system wins when there is a conflict. For many scenarios, AWS defines how policy evaluation conflicts are resolved.
Organizations must ensure cloud security teams have adequate training and solutions that help them understand the IAM trust relationships in place and provide that automated conflict resolution does not introduce inadvertent attack vectors to data.
Buyer beware – understand default policy before using
AWS provides many default IAM effective policies. However, it’s essential to review each default policy before implementing them. In many cases, they will be over allowed for the intended purpose, and they will completely lack resource restrictions of conditional access, which control IP ranges, 2nd-factor authentication, and region restrictions.
Similar IAM complexity introduced by Azure & GCP
Azure and GCP also have sophisticated IAM configuration frameworks that introduce similar challenges.
Public cloud IAM security models are a 2-edged sword. One edge provides excellent promise with the ability to architect strong IAM based security into applications that significantly improve data protection. Unfortunately, the other side can introduce attack vectors if not correctly architected and configured. In this article, we highlight just a handful of cloud IAM concepts that can expose data to a breach when misused.
Contact us today at Sonrai Security and download one of our many eBooks that provides more detailed information regarding cloud security
Editor’s note: This blog was originally published on August 29, 2019 by Brian Melham and has been updated for completeness.
Read the latest news and insights
06.17.2020
In the wake of the largest data breach in CIA history,...
04.14.2020
Understand the benefits and challenges of identity...
11.20.2019
Explore the past and learn the future history of identity...
