Member-only story
AWS Accounts as Security Boundaries — 97+Ways Data Can be Shared Across Accounts
TL;DR
Just want to see a list of services and how their data can be shared across AWS accounts? Click here. Spreadsheet version here.
Background
There are many strategies for organizing AWS accounts. Some organizations use a separate account for each environment — one for development, another for staging, and a third for production. Others prefer to put each team or project in its own AWS account, resulting in hundreds or even thousands of accounts across the company. Still others prefer to lump every team, project, and environment into a single AWS account in what I like to call “the kitchen sink strategy.”
Regardless of the approach, most of these practices assume that the AWS account itself acts as a security boundary. Given the IAM service name-spacing and AWS’s own documentation, this is a logical assumption. However, through a series of features and dedicated services, creating configurations that enable crossing these boundaries has become relatively easy. Relying on it to provide a security boundary may not be a safe decision without extensive controls and monitoring in place. With cross-account IAM roles, cross-resource sharing, global namespaces, and other features, it is easier than ever to turn a once-isolated account into a mesh full of access holes and webs of cross-account relationships.
Let’s start with the basics — by itself, when properly configured, an AWS account is a secure boundary. This post is not being written to discuss exploits or security vulnerabilities within AWS itself. Instead, we will be exploring the plethora of access practices, features, and misconfigurations that can quickly turn an isolated AWS account into a porous attack surface.
We’ll break these risks into three main categories: poor isolation practices, risks from external attackers leveraging misconfigurations, and supported cross-account resource sharing.
Poor Isolation Practices
Single Points of Failure
Perhaps the easiest way to break the account security boundary is simply by giving a single resource access to more than one account. Consider, for…
