This feature is part of our Public Cloud Security Principles Blog Series
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, these IAM solutions are not without risk when used incorrectly, and the risk is very different (and sometimes much greater) 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 important component of public cloud security, but they aren't sufficient enough. 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 in 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 perimeter” in 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.
In 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 privilege 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 risk 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 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.
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 the production account.
Delegated trust relationships on AWS allows needs to be understood so that potential risky configurations are eliminated.
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. 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. Also, 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 global control mechanisms.
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 policy wins when there is a conflict. 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.
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 control IP ranges, 2nd factor authentication, and region restrictions.
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 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 IAM 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.
Sonrai Security cloud security platform, products and services are covered by U.S. Patent No. 10,728,307, together with other domestic and international patents pending. All rights are reserved.