Secure individual and group access to AWS resources Can be used to manage
New users no access to services. Permissions need to be granted IAM not used for application authentication: use AD or SAML or cognito etc, or other identity providers (identity federation) without creating IAM account.
Best practice: MFA for all users, and use U2F or hardware MFA for privileged users IAM is global Don;t use root account for anything other than billing
IAM users are a person or a service Applications can use IAM, that's a service account. Groups: collections of users. One level only. Can be assigned a policy.
Use least privilege when assigning permissions.
Roles: assumed by a trusted entity. Mean can delegate permissions to resources for users and services without using permanent credentials (user name and password) so don't need to embed access keys
IAM policies: define permissions for user, group, role. All permissions implicitly denied, most restrictive applied.
Best practices
Used with web and mobile apps Offers user pools and identity pools.
User pools are user directories which provide sign up and sign in options for app users Sign in with various providers (federated) e.g. google, facebook, SAML, OpenID Choose e.g. password policy, MFA, attributes, user id type etc
Identity pools provide AWS credentials to grant users access to AWS services. Temporary credentials.
Customer master keys
Create a customer managed key, choose to gt from KMS or external. Define key usage permissions IAM users, roles etc Can rotate every year When want to delete, needs to be delayed by 7 to 30 days
Application firewall Lets you monitor HTTP and HTTPS requests Integrates with cloudfront, API Gateway, ALB, GraphQ API Based on conditions (e.g. query strings, IP address) responds with either requested content or 403 (Forbidden).
Conditions
Basically create a Web ACL from these conditions. Set e.g. cloudfront to use this Web ACL.
Provides DDOS protection. Standard and advanced: Standard is free, advanced more features, but costs 3000 pm If you use some AWS services, get DDOS protection anyway. Minimise attack surface area, so only resources needing internet are exposed Architect for resilience: architecture can absorb spikes Can use AWS WAF access control lists (Web ACLs) to minimize DDOS. Shield on top of WAF.
for WAF across accounts
Centrally manage multiple accounts Manage billing, access, compliance, security. Share resources across AWS Accounts Automate account creation apply policies to all accounts Single payment method for all accounts Create hierarchy of accounts
Discounts for certain levels, e.g. S3 costs Consolidate and get more discounts.
SCP control rights that can be granted e.g. if SCP says can't create EC2, then whatever the account permissions you can't do it. e.g. deny Run EC2 where instance not t2.micro Where multiple policies, the most restrictive applies (e.g. a deny rule trumps allow) Set tag policy across all accounts
Create organisation Create / invite accounts emails invites to other accounts Create multiple organisational units Attach SCP to an organisational unit, inherited by units below.
Allows users to come from other identity providers and use AWS services e.g. corporate user directory using Active Directory, or any SAML 2.0 source Active Directory uses LDAP to query user database. Local directory access provider. OpenID connect is known as Web Identity Federation Means users can be managed by an identity provider outside of AWS and then use AWS resources. Don't need to manage sign in code. Don't need to embed security credentials in your app. User doesn't need to create a user in your app. Works with identity providers compatible with OpenID Connect, or SAML 2.
Mobile apps: best off using AWS Cognito If authenticating users to an AWS account on corporate network, use SAML. If going to give access to multiple accounts, use single sign on
Single sign on so single user identity has access to multiple services, don't need to enter passwords repeatedly. Identity sources can be AWS SSO, or provider using SAML. Centrally manage access to multiple AWS accounts Can use SSO to manage access and user permissions Can customise permissions
Key scenario: company has own identity source (active directory) want to configure single sign on to multiple accounts, use AWS SSO.
AWS managed microsoft active directory
Fully featured AD in AWS. Set up trust relationship between 2 active directories e.g. with on prem active directory So keep users in one please, but allow them to authenticate to AWS. Can e.g. connect to EC2 instances, Amazon workdocs etc
Best choice if > 5000 users, or if need to set up trust relationships
Runs on windows Can use with SQL Server, .NET apps etc Requires VPN or Direct connect
Simple Active Directory
Stand alone fully managed Active Directory in AWS Cheap, less features, good for lower user numbers Compatible with AWS Workdocs etc 2 editions: small to 500 users, large to 5000 users Highly available Doesn't support some AD features: SQL Server, schema extensions etc DOesn't support trust relationships with AD on prem
AD Connector
Connect your on prem AD to AWS for seamless connection between AWS services and AD. Map AD identity to IAM role. Noting cached to the cloud so more secure Best choice when want to use existing AD with AWS
One more case: AS on prem, add a second in AWS EC2. Means low latency authentication in cloud. But needs synchronizing and identities copying, so not ideal.
Share resources between account. Share: Aurora, EC2, Codebuild, Route 53, subnets, etc. Useful where e.g. share between test and development accounts.
Create a resource share: e.g. subnet, then visible in RAM for the other user.
Users in groups Create roles Assign permissions to roles Assign users or instances to roles for a temporary period to do something
Created and administered by AWS, has an ARN, designed for common use cases, cant change them e.g. DynamoDbFullAccess Some for job specific functions, e.g. data scientist
You create your own, attach to multiple principal entities when attach , you give the entity permissions in the policy
Use when job specific functions, or where permissions in a managed policy are ok but want to customise.
These 2 are key:
Identity based policy: apply to user, group role
Resource based policy: apply to e.g. S3
inline policies: Attached directly to the identity, not to a role.
IAM permissions boundary: limit of what you can grant to IAM
AWS Organisations SCP: specify max permissions for an org or OU
Session policies: pass as parameters for a session role
Main thing is that identity based and resource based can have explicit allows
Container for a single IAM role that you can set for an EC2 instance at startup These are visible in EC2 instance details screen on startup
Use this when user in one account wants to access resource in another account e.g. production and development accounts, just sign into console and switch roles in console or can add resource permissions
Stored in ~.aws/credentials includes region