AWS STS β Security Token Service
β’ Allows to grant limited and temporary access to AWS resources.
β’ Token is valid for up to one hour (must be refreshed)
β’ Within your own account: for enhanced security
β’ Cross Account Access: assume role in target account to perform actions there
β’ AssumeRoleWithSAML
β’ return credentials for users logged with SAML
β’ AssumeRoleWithWebIdentity
β’ return creds for users logged with an IdP (Facebook Login, Google Login, OIDC compatibleβ¦)
β’ AWS recommends against using this, and using Cognito instead
β’ GetSessionToken
β’ for MFA, from a user or AWS account root user
Using STS to Assume a Role
β’ Define an IAM Role within your account or cross-account
β’ Define which principals can access this IAM Role
β’ Use AWS STS (Security Token Service) to retrieve credentials and impersonate the IAM Role you have access to (AssumeRole API)
β’ Temporary credentials can be valid between 15 minutes to 1 hour
Identity Federation in AWS
β’ Federation lets users outside of AWS to assume temporary role for accessing AWS resources.
β’ These users assume identity provided access role.
β’ Federations can have many flavors:
β’ SAML 2.0
β’ Custom Identity Broker
β’ Web Identity Federation with Amazon Cognito
β’ Web Identity Federation without Amazon Cognito
β’ Single Sign On
β’ Non-SAML with AWS Microsoft AD
β’ Using federation, you donβt need to create IAM users (user management is outside of AWS)
SAML 2.0 Federation
β’ To integrate Active Directory / ADFS with AWS (or any SAML 2.0)
β’ Provides access to AWS Console or CLI (through temporary creds)
β’ No need to create an IAM user for each of your employees
SAML 2.0 Federation
β’ Needs to setup a trust between AWS IAM and SAML (both ways)
β’ SAML 2.0 enables web-based, cross domain SSO
β’ Uses the STS API: AssumeRoleWithSAML
β’ Note federation through SAML is the βold wayβ of doing things
β’ Amazon Single Sign On (SSO) Federation is the new managed and simpler way
β’ Read more here:
https://aws.amazon.com/blogs/security/enabling-federation-toaws-using-windows-active-directory-adfs-and-saml-2-0/
Custom Identity Broker Application
β’ Use only if identity provider is not compatible with SAML 2.0
β’ The identity broker must determine the appropriate IAM policy
β’ Uses the STS API: AssumeRole or GetFederationToken
Web Identity Federation β AssumeRoleWithWebIdentity
β’ Not recommended by AWS β use Cognito instead (allows for anonymous users, data synchronization, MFA)
β’ Provide direct access to AWS Resources from the Client Side (mobile, web app)
β’ provide (temporary) access to write to S3 bucket using Facebook Login
β’ We donβt want to create IAM users for our app users
β’ Log in to federated identity provider β or remain anonymous
β’ Get temporary AWS credentials back from the Federated Identity Pool
β’ These credentials come with a pre-defined IAM policy stating their permissions
What is Microsoft Active Directory (AD)?
β’ Found on any Windows Server with AD Domain Services
β’ Database of objects: User Accounts, Computers, Printers, File Shares, Security Groups
β’ Centralized security management, create account, assign permissions
β’ Objects are organized in trees
β’ A group of trees is a forest
AWS Directory Services
β’ AWS Managed Microsoft AD
β’ Create your own AD in AWS, manage users locally, supports MFA
β’ Establish βtrustβ connections with your on- premises AD
β’ AD Connector
β’ Directory Gateway (proxy) to redirect to on- premises AD, supports MFA
β’ Users are managed on the on-premises AD
β’ AD-compatible managed directory on AWS
β’ Cannot be joined with on-premises AD
AWS Organizations
β’ Global service
β’ Allows to manage multiple AWS accounts
β’ The main account is the master account β you canβt change it
β’ Other accounts are member accounts
β’ Member accounts can only be part of one organization
β’ Consolidated Billing across all accounts - single payment method
β’ Pricing benefits from aggregated usage (volume discount for EC2, S3β¦)
β’ API is available to automate AWS account creation
Multi Account Strategies
β’ Create accounts per department, per cost center, per dev / test / prod, based on regulatory restrictions (using SCP), for better resource isolation (ex: VPC), to have separate per-account service limits, isolated account for logging
β’ Multi Account vs One Account Multi VPC
β’ Use tagging standards for billing purposes
β’ Enable CloudTrail on all accounts, send logs to central S3 account
β’ Send CloudWatch Logs to central logging account
β’ Establish Cross Account Roles for Admin purposes
AWS Organization
Service Control Policies (SCP)
β’ Whitelist or blacklist IAM actions
β’ Applied at the OU or Account level
β’ Does not apply to the Master Account
β’ SCP is applied to all the Users and Roles of the Account, including Root user
β’ The SCP does not affect service-linked roles
β’ Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs.
β’ SCP must have an explicit Allow (does not allow anything by default)
β’ Use cases:
β’ Restrict access to certain services (for example: canβt use EMR)
β’ Enforce PCI compliance by explicitly disabling services
AWS Organization β Moving Accounts
To migrate accounts from one organization to another
Remove the member account from the old organization
Send an invite to the new organization
Accept the invite to the new organization from the member account
If you want the master account of the old organization to also join the new organization, do the following:
Remove the member accounts from the organizations using procedure above
Delete the old organization
Repeat the process above to invite the old master account to the new org
β’ ListBucket permission applies to arn:aws:s3:::test
β’ => bucket level permission
β’ GetObject, PutObject, DeleteObject applies to arn:awn:s3:::test/*
β’ => object level permission
IAM Roles vs Resource Based Policies
β’ When you assume a role (user, application or service), you give up your original permissions and take the permissions assigned to the role
β’ When using a resource based policy, the principal doesnβt have to give up his permissions
β’ Example: User in account A needs to scan a DynamoDB table in Account A and dump it in an S3 bucket in Account B.
β’ Supported by: Amazon S3 buckets, SNS topics, SQS queues, etcβ¦
IAM Permission Boundaries \ baΕa dΓΌΕmedim
β’ IAM Permission Boundaries are supported for users and roles (not groups)
β’ Advanced feature to use a managed policy to set the maximum permissions an IAM entity can get.
IAM Permission Boundaries
β’ Can be used in combinations of AWS Organizations SCP
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
Use cases
β’ Delegate responsibilities to non administrators within their permission boundaries, for example create new IAM users
β’ Allow developers to self-assign policies and manage their own permissions, while making sure they canβt βescalateβ their privileges (= make themselves admin)
β’ Useful to restrict one specific user (instead of a whole account using Organizations & SCP
Example IAM Policy
β’ Can you perform sqs:CreateQueue?
β’ Can you perform sqs:DeleteQueue?
β’ Can you perform ec2:DescribeInstances?
\
AWS Resource Access Manager (RAM)
β’ Share AWS resources that you own with other AWS accounts
β’ Share with any account or within your Organization
β’ Avoid resource duplication!
β’ VPC Subnets:
β’ allow to have all the resources launched in the same subnets
β’ must be from the same AWS Organizations.
β’ Cannot share security groups and default VPC
β’ Participants can manage their own resources in there
β’ Participants can't view, modify, delete resources that belong to other participants or the owner
β’ AWS Transit Gateway
β’ Route53 Resolver Rules
β’ License Manager Configuration
Resource Access Manager βVPC example
β’ Each accountβ¦
β’ is responsible for its own resources
β’ cannot view, modify or delete other resources in other accounts
β’ Network is shared soβ¦
β’ Anything deployed in the VPC can talk to other resources in the VPC
β’ Applications are accessed easily across accounts, using private IP!
β’ Security groups from other accounts can be referenced for maximum security
AWS Single Sign-On (SSO)
β’ Centrally manage Single Sign-On to access multiple accounts and 3rd-party business applications.
β’ Integrated with AWS Organizations
β’ Supports SAML 2.0 markup
β’ Integration with on-premises Active Directory
β’ Centralized permission management
β’ Centralized auditing with CloudTrail
https://aws.amazon.com/blogs/security/introducing-aws-single-sign-on/
