IAM for Enterprises: How Vanguard Matured IAM Controls to Support Micro Accounts (SEC324) - AWS re:Invent 2018

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
IAM for Enterprises:
How Vanguard Has Matured Their IAM
Controls to Support a Micro Account Strategy
S E C 3 2 4
Ilya Epshteyn
Principal Solutions Architect
Amazon
Rajeev Sharma
Senior Application Security Architect
Vanguard

Agenda
• AWS Identity and Access Management (IAM) primer
• Micro account strategy, blast radius
• AWS Security Token Service (AWS STS) federation, common IAM
roles
• Keeping DevOps teams inside their boundary
• Agility to developers

Request
Actions, resources, principals,
environment data, resource data
IAM primer
Principals
Users
(and Groups)
Roles
(assumed, delegated,
federated, service-linked)
Applications
Authentication
Resources
Authorization
Resource-based policies Other policies
(Trust, permissions
boundary)
Identity-based policies

AWS STS assume role
prod@example.com
Acct ID: 111122223333
ddb-role
dev@example.com
Acct ID: 123456789012
Call AWS APIs using
temporary security
credentials
of ddb-role
IAM user: Alice
Get temporary
security credentials
for ddb-role
Authenticate with
Anders’ access keys
ddb-role trusts IAM users from the
AWS account dev@example.com (123456789012)
{ "Statement": [
{
"Effect":"Allow",
"Principal":{"AWS":"123456789012"},
"Action":"sts:AssumeRole"
}]}
Permissions assigned to Anders granting him permission
to assume ddb-role in account B
{ "Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/ddb-role"
}]}
Permissions assigned to ddb-role
{ "Statement": [
{ "Action":
[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:ListTables"
],
"Effect": "Allow",
"Resource":"arn:aws:dynamodb:us-east-1:
123456789012:table/books"
}]}
books

Userlogsinto
Portal
Corporate Data Center
Enterprise (Identity Provider) AWS (Service Provider)
Browser interface
Identity
Store
Portal
1
3
2
4
5
AWS Sign-in
User
authenticated
Receiveresponse
(SAMLassertion)
Post the SAML
assertion to sign-in
Redirected to AWS
Management
Console
Identity federation

Permissions boundary
Limit the maximum permissions of the principals created by delegated admins
• Certain IAM permissions (such
as PutUserPolicy,
AttachRolePolicy) were
essentially god-like
• Self-service permissions
management required non-
trivial automation
• Administrator can grant
previously god-like permissions,
but specify a permissions
boundary
• Allow developers the ability to
create principals and attach
policies but only within the
boundary

Account Admin Step 1: create a permissions boundary policy preventing deletion of critical logs (CompanyBoundary)
IAM delegated administration
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ServiceBoundaries",
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*",
"dynamodb:*",
“lambda:*”,
"iam:ListUsers"
],
"Resource": "*"
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::cloudtraililya",
"arn:aws:s3:::cloudtraililya/*"
]
}...

Account Admin Step 2: create a permissions Policy allowing creation of IAM roles but only if CompanyBoundary is specified. Attach
permission policy to delegated IAM Admin principal.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"SetPermissionsBoundary",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy"
],
"Resource":"arn:aws:iam::123456789012:role/AppRoles/*",
"Condition":{
"StringEquals":{
"iam:PermissionsBoundary":"arn:aws:iam::123456789012:policy/CompanyBoundary"
}
}
},
{
"Sid":"CreateAndEditPermissionsPolicy",
"Effect":"Allow",
"Action":[
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion"
],
"Resource":"arn:aws:iam::123456789012:policy/AppPolicies/*"
}
]
}

Delegated IAM Admin Step 1: create an IAM role specifying a path and a permissions boundary
aws iam create-role
--role-name MyTestAppRole
--path /AppRoles/
--permissions-boundary arn:aws:iam::123456789012:policy/CompanyBoundary
--assume-role-policy-document file://Role_Trust_Policy_Text.json
Delegated IAM Admin Step 2: create a permission policy allowing full access to S3
aws iam create-policy
--policy-name MyTestAppPermissions
--path /AppPolicies/
--policy-document file://MyTestAppPermissions.json
Delegated IAM Admin Step 3: attach policy to the newly created role
aws iam attach-role-policy
--role-name MyTestAppRole
--policy-arn arn:aws:iam::705582597265:policy/AppPolicies/MyTestAppPermissions
{
"Effect":"Allow",
"Action":"s3:*",
"Resource":"*"
}

Effective permission
Permission policy
{
"Effect":"Allow",
"Action":"s3:*",
"Resource":"*"
}
Permission boundary
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::cloudtraililya",
"arn:aws:s3:::cloudtraililya/*"
]
}...

Effective permission
Permissions
boundary
Permission
policy
Allow: S3:* Allow: SQS:*
Allow: EC2:*Allow: EC2:*

A1 A3
M Master account
Organizational unit (OU)
Service control
policies
Dev Test Prod
AWS Organizations
AWS AccountsA5A4A2 A7A6

• Enables you to control which AWS service APIs are accessible
o Define the list of APIs that are allowed or
o Define the list of APIs that must be blocked
• Cannot be overridden by local administrator
• Necessary but not sufficient!
• Effective permission on IAM user/role is the intersection between
the SCP and assigned IAM permissions
Service control policies (SCP)

SQS:*S3:*
EC2:*
SNS:*
Organizations and permissions boundaries
Service control policy Permissions boundary
Permissions policy

Policy evaluation
No
Deny Evaluation –
Implicit Deny, look
for an Explicit Deny
Yes
Organizations
Boundaries (SCP) –
is there an Allow?
Yes
Principal Boundaries
(Permissions
Boundaries) –
is there an Allow?
Yes
AWS STS assume
role policies –
is there an Allow?
Yes
Permissions –
is there an Allow?
(Identity-based,
resource-based)
Final Decision Allow

Related breakouts
Tuesday, Nov 27, 11:30 AM
NET323 - How Vanguard and Bloomberg Use AWS PrivateLink
11:30AM – 12:30AM | Aria East
Monday, Nov 26
SEC316-R – Become an IAM Policy Master in 60 Minutes or Less
Monday, Nov 26
ENT302 - Optimizing Costs as You Scale on AWS

Vanguard―Background
Began
Operations―
May 1, 1975, in
Valley Forge, PA
One of the world's largest investment
companies, offering a large selection of low-cost
mutual funds, ETFs, advice, and related services
Wall ST

The Goals
• DevOps:
• Flatten speed bumps to get product to market
safely and quickly
• Traditional IAM:
• Audit who is doing what when, and where are
they coming from
• Future IAM:
• Systematically keep users within their boundary

What you will learn
• Example of a custom federation
• Using permission boundaries on the current role
• Using preventative IAM controls
• Using an operating system level control

Vanguard’s account strategy―2016
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
AWS Account
VPC
DC1 DC2 DCx

Federation to accounts
Original 2016 approach used a custom IdP and 1:1 role mapping
corporate data center
corporate
LDAP IdP Service AWS Sign-in
Endpoint
LDAP ROLE = AWS ROLE
Assume Role

Federation to accounts
Every new account requires new mappings

Using custom AWS STS IdP (2016)
Custom AWS STS IdP ReST API
$ curl https://customidp.vanguard.com/rest/tokensByRole/DevOps/111111111111
{
"accessKey": "ASIAEXAMPLE123456789" ,
"alias": "CorpStagingAccountOne" ,
"secretAccessKey": "asdfasdfexamplexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ,
"sessionKey": "qwertyqwertyeXaMpLe//////////1337……………wxy&z=" ,
"expiration": "Fri Jan 1 02:03:04 UTC 2018" ,
"consoleURL":
"https://signin.aws.amazon.com/federation?Action=login&Issuer=http%3A%2F%2F
example.com%3A8090%2Fdisplay%2FCS%2FIdP&Destination=https%3A%2F%2Fconsole.a
ws.amazon.com%2F&SigninToken=-abc123"
}

Issues with the original 2016 approach
• Large accounts
• Many IAM roles
• Manual process to setup
accounts
• Federation and
entitlement granting is
complex
Dev Ops Sec Biz
LOB 1 Data Center
LOB 1 Non-Prod LOB 1 Prod
Subnet
Subnet
Subnet
Subnet

The Vanguard Cloud Registry Service
AWS
Organizations
Create Account
SCP
SCP
SCP

Benefits of micro accounts
Blast radius
Simple IAM
Declarative networking (private link) instead of VPC Peering
AWS cloud account BAWS cloud account A

Benefits of the VCRS
Self service account creation
IAM policies do not need explicit Conditions

Problems with direct mapping
Large amount of AD roles
Entitlement granting required every time a new account is created

Indirect mapping to accounts using OU
Fewer AD roles
Entitlement granting simplicity
Administrators automatically get access on new accounts
Scalability
Role lifecycle management

Federation to groups of accounts by OU
Use AWS STS to create custom mappings, based on Organizations OU
corporate data center
corporate
LDAP IdP Service AWS Sign-in
Endpoint
LDAP ROLE = AWS OU
Assume Roles
Organization
List Roles by OU

Federation to groups of accounts by OU
Automatic access by OU

New AWS STS IdP User Description memberOf
Inan IAM Admin RootOU
Bob Retail DevOps DevRetailOU
Alice Prod Support ProdOU

Using custom AWS STS IdP (new)
Custom AWS STS IdP ReST API
$ curl https://customidp.vanguard.com/rest/tokensByOU/DevOps/OU1
[{
"alias": "CorpStagingAccountOne",
…
},
{
"alias": "CorpStagingAccountThree",
…
},
…
]

Common roles for each new account
• Administrator/Privileged
• Bootstrap
• Network engineer
• IAM Admin
• Non administrator
• Auditor
• DevOps
• Fraud
• Third-party monitoring

Example day in the life for DevOps
Create an Amazon Simple Storage Service (Amazon S3) bucket
Create an IAM role
Put an IAM policy on the role with a specific S3 bucket as a resource
Put a bucket policy on the bucket restricting access to only the IAM role
Deploy a AWS Lambda or Amazon Elastic Compute Cloud (Amazon EC2)
with an IAM Role

DevOps permissions
AWS IAM Policy attached to the
Execution Role’s IAM Role
DevOps IAM Role
• Full access to Lambda & EC2
• Limited IAM & S3
• Ability to tightly couple the Lambda
Function to the S3 bucket
Amazon Lambda
S3 Bucket "FAQ"
Execution Role’s Policy
" " "arn:aws:s3:::FAQ"
" " "AROAEXMPLEID"
Bucket Policy

Allow actions
"Statement": [
{
"Sid": "DevOpsMasterStmt",
"Effect": "Allow",
"Action": [
"lambda:*",
"ec2:*",
"iam:CreateInstanceProfile",
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetGroup",
"iam:ListAccessKeys",
"iam:PassRole",
"iam:PutRolePolicy",
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject”,
"s3:PutBucketPolicy"
],
"Resource": "*"
}
]
DevOps
Allow Policy of the
DevOps IAM Role

Implicit denies are not enough in DevOps role
Only the Security team can manage IAM User, Internet Gateway (IGW),
Amazon Virtual Private Cloud (Amazon VPC) Peer, or AWS CloudTrail.
What happens if a user can manage:
• IAM Users – Attacker can masquerade as another person
• IGW – Attacker can cause a data breach, or create a phishing site
• VPC Peer – Attacker can leak data to an unsanctioned AWS account
• CloudTrail – Attacker can stop CloudTrail logging and hide their tracks

1st Degree – Escaping implicit deny
"Statement": [
{
"Sid": "DevOpsMasterStmt",
"Effect": "Allow",
"Action": [
"lambda:*",
"ec2:*",
"iam:CreateInstanceProfile",
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetGroup",
"iam:ListAccessKeys",
"iam:PassRole",
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject",
"s3:PutBucketPolicy",
"s3:List*"
],
"Resource": "*"
}
]
DevOps
Allow Policy of the
DevOps IAM Role

Typical IAM enforcement
"Statement": [
{
"Sid": "RestrictedActions",
"Effect": "Deny",
"Action": [
"iam:AttachUserPolicy",
"iam:CreateAccessKey",
"iam:CreateUser",
"ec2:AcceptVpcPeeringConnection",
"ec2:CreateInternetGateway",
"ec2:CreateVpcPeeringConnection",
"cloudtrail:DeleteTrail",
"cloudtrail:StopLogging",
"cloudtrail:UpdateTrail"
],
"Resource": "*"
}
]
DevOps
Add Explicit Deny to the IAM Role

1st degree – Using the deny on self
{
"Sid": "DenySelfRoleModification",
"Effect": "Deny",
"Action": [
"iam:DeleteRolePolicy",
"iam:DeleteRole",
"iam:DetachRolePolicy"
],
"Resource": [
"arn:aws:iam::012345678912:role/DevOps",
]
}

2nd degree – Use Lambda to launch an attack
DevOps AWS
Lambda
AWS
Role
Create Role
Create Lambda
Update code and Execution Role
Invoke Lambda
create-access-key
Identity and Access
Management

2nd degree – Lambda code
import json
import boto3
def lambda_handler(event, context):
i = boto3.client("iam")
usr = "eve"
arn = "arn:aws:iam::aws:policy/AdministratorAccess"
resp1 = i.create_user( UserName=usr,)
resp2 = i.attach_user_policy( UserName=usr,PolicyArn=arn)
resp3 = i.create_access_key(UserName=usr)
return {
"statusCode": 200,
"body": json.dumps(resp3, indent=4, sort_keys=True, default=str)
}

Mitigation
Use Permission Boundaries to prevent Lambda escaping the boundary
Move the IAM Deny statements into the Permission Boundary instead
Add a condition so that DevOps cannot remove the boundary

2nd degree – Mitigation of Lambda launched attack
DevOps AWS
Lambda
AWS
Role
Set Permission Boundary
on DevOps Role { PB }
Create Lambda
Update code and Execution Role { PB }
Invoke Lambda
create-access-key
IAM
Administrator
Create Role { PB }

Mitigation – Use a Boundary Policy
Allow
"s3:*",
"ec2:*",
“lambda:*",
"iam:CreateInstanceProfile", ...
{ "Sid": " ",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
“iam:PutRolePermissionsBoundary”
],
"Condition": {"StringEquals":
{"iam:PermissionsBoundary":
"arn:aws:iam::123456789012:policy/boundaries"
},
"Resource":"*"
},
{ "Sid": "NoBoundaryPolicyEdit",
"Effect": "Deny",
"Action": [
"iam:CreatePolicyVersion",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:SetDefaultPolicyVersion”
],
"Resource":
"arn:aws:iam::123456789012:policy/boundaries”
},
{ "Sid": "NoBoundaryRoleDelete",
"Effect": "Deny",
"Action": "iam:DeleteRolePermissionsBoundary",
"Resource": "*”
}
]
}
}
Avoid
Overlap

2nd degree - Use EC2 to launch an attack
• IAM and Permission Boundaries
• Only apply to the AWS API plane
• Do not apply over SSH ‘data’ plane
• Attackers can use this to their advantage
• IAM PassRole can be locked down, but it’s difficult to rely on naming
conventions in a Micro Account

Mitigation
IP Tables to block metadata for interactive users
"sudo chkconfig iptables on",
"sudo service iptables start",
"sudo iptables -A OUTPUT -m owner --uid-owner root -d 169.254.169.254 -j ACCEPT",
"sudo iptables -A OUTPUT -m owner --uid-owner apache -d 169.254.169.254 -j ACCEPT",
"sudo iptables -A OUTPUT -d 169.254.169.254 -j REJECT",
"sudo iptables -F INPUT",
"sudo service iptables save"

Takeaways
• Use Permission Boundaries
• Automate account creation
• Include Role creation if federating
• Give DevOps teams maximum flexibility & autonomy
• Allows for Innovation
• Many challenges are addressed using IAM preventative controls
• Use IAM Policies to prevent Principals from changing their own permissions
• Use IAM Permission Boundaries to limit privileges of new compute
• Use OS level control, like IPTables, to limit access to powerful Instance Profiles

Thank you!
Ilya Epshteyn Rajeev Sharma

IAM for Enterprises: How Vanguard Matured IAM Controls to Support Micro Accounts (SEC324) - AWS re:Invent 2018

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IAM for Enterprises: How Vanguard Matured IAM Controls to Support Micro Accounts (SEC324) - AWS re:Invent 2018

Similar to IAM for Enterprises: How Vanguard Matured IAM Controls to Support Micro Accounts (SEC324) - AWS re:Invent 2018 (20)

More from Amazon Web Services

More from Amazon Web Services (20)

IAM for Enterprises: How Vanguard Matured IAM Controls to Support Micro Accounts (SEC324) - AWS re:Invent 2018