4 mins to read
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 data centers. However, if used incorrectly, these IAM solutions are not without risk, and the risk is very different (and sometimes much greater) than old-world enterprise IAM. Identity is the new security perimeter in the cloud — not networks and firewalls.
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 important component of public cloud security, but they aren’t sufficient enough. AWS, Azure, GCP, and others offer a rich service portfolio that exposes public 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 in the public cloud is squarely focused on identity-based security that controls access to cloud-based resources and data. Security professionals recognize that “identity is the new security perimeter” in the public cloud. 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 greater with public cloud
In the public cloud, highly privileged users can ‘delete’ your infrastructure, data, and backups. 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 higher privileges 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 security risks because 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 greatest identity risk lies with “entities,” not users
The ability to delegate roles can become quite problematic in the public cloud because 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 has been configured with permission to perform certain 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 using it perform actions of their choice. The code could 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 properly by a knowledgeable IT security and cloud team. It eliminates the poor programming habit of storing service account credentials in configuration files or worse in the code. However, the delegation of a powerful role to a service must be fit for purpose with a focus on least privilege.
Relationships and delegation rules are as important 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 that could occur is allowing this type of trust relationship from a development account to a production account.
Delegated trust relationships on AWS allows need 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 entire organization. AWS SCP policies are a powerful way to exert global control and to restrict services and sandbox-type accounts. Conversely, global policies have limitations in the agile cloud world where a policy change could expose an obscure risk in another account. Also, a full picture of risk is impossible without understanding the interactions between account-specific and global SCP policies. Microsoft Azure and Google Cloud Platform have similar global control mechanisms.
Identity policy requires an understanding of conflict resolution rules
Another wrinkle in the flexible AWS IAM security model is that conflicts can arise between access and resource policies (for example, AWS S3 bucket policy). Automated logic defined by AWS will determine which policy wins when conflict arises. For many scenarios, AWS defines how policy evaluation conflicts are resolved.
Organizations must ensure cloud security teams have effective training and solutions that help them understand the IAM trust relationships in place and ensure that automated conflict resolution does not introduce inadvertent attack vectors to data.
Buyer beware – understand default policy before using
AWS provides numerous default IAM policies that are helpful. However, it’s important to review each default policy before implementing them. In many cases, they will be over-permissioned for the intended purpose, and they will completely lack resource restrictions of conditional access, which controls 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 as identity is the new security perimeter in the cloud.
Public cloud IAM security models are a double-edged sword. One edge provides great promise with the ability to architect strong IAM-based security into applications that greatly improve data protection. Unfortunately, the other edge can introduce attack vectors if not properly architected and configured. In this article, we highlighted just a handful of cloud identity security concepts that, when used improperly, can expose data to a breach.
Helping organizations better understand and manage cloud IAM policies and associated risks is some of what Sonrai’s Cloud Data Control platform can do. Let us know if you would like to see for yourself.
