Identities Are The New Perimeter For Securing Data In Public Cloud

Sonrai Security Marketing

August 29, 2019

This feature is part of our Public Cloud Security Principle Blog Series

Powerful identity and access (IAM) models of public cloud providers like AWS, Azure, and GCP, 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. 

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 IAM controls leave significant attack vectors to sensitive data. The examples below are based on AWS, but similar options exist on Azure and GCP.

Powerful identity and access (IAM) models of public cloud providers like AWS, Azure, and GCP, 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. 

Excess privilege and privilege escalation risks are greater with
public cloud

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 AdministratorAccess 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 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 example:

A user with the iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction permissions can escalate privileges bypassing 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 architected properly by a knowledgeable security 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 the production account. 

Delegated trust relationships on AWS allows 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 entire organization. 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. Azure and GCP have similar global control mechanisms. 

Identity policy requires an understanding of conflict resolution rules
Another wrinkle in the flexible IAM security model provided by AWS is that conflicts can arise between access policies and resource policies (ie, 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.

Buyer beware – understand default policy before using

AWS provides numerous default 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 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 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 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