Monday, July 20, 2020

IAM – Identity Access Management


IAM – Identity Access Management
Features
-         https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
-         Global service
-         Granular permission management – per user/service
-         Secure access to AWS resources for applications that run on Amazon EC2
-         Multi-factor authentication (MFA)
-         Identity federation
          §  can allow users with outside credentials access to AWS services
-         Identity information for assurance
          §  If you use AWS CloudTrail, you receive log records that include information about those who made requests for resources in your account.
-         PCI DSS Compliance
          §  IAM supports the processing, storage, and transmission of credit card data by a merchant or service provider, and has been validated as being compliant with Payment Card Industry (PCI) Data Security Standard (DSS).
-         Eventually Consistent
          §  IAM achieves high availability by replicating data across multiple servers within Amazon's data centers around the world.
-         Free to use
-         Security Token Service – STS
          §  Provision of temporary credentials
Elements
1.      Principal (user / federated user / role / resource / application) submits Request;
         a.      AWS collects request context – IP, nature of request, associated resources
2.      Authentication follows – process of letting principal in
         a.      Name/pwd, access/secret key, MFA
3.      Authorization – determining access levels – what Actions on what Resources are allowed
         a.      Check request context against matching policies
         b.      Policy (JSON): user-based and resource-based
                  i.     Implicit deny – by default nothing is allowed
                  ii.     Explicit allow – if at least one Allow policy and no denies are present, access is allowed
                  iii.     Explicit deny – if at least one Deny is present on top of any number of Allows – access is denied
                  iv.     Example: cross-account S3 bucket access permissions – can achieve this with a user policy; need to use resource-based policy on the bucket or IAM User Role on the bucket-owner account
4.      Resource – entity within a service
5.      IAM Access – via console, CLI, SDK, API
 
Identity Federation
-         Users authenticated on by the network level (logged into the corporate network) – their identity can be replaced with the temporarily identity in the corporate AWS account. No need to re-identify with AWS once logged into the corporate AD. Trust relationship between AWS AD and the corporate AD is required 
-         SAML 2.0 federation – Security Assertion Mark Up Language – SSO access to AWS from corporate if the corporate AD supports SAML. If SAML 2.0 is not supported – can set up a broker application in the middle
-         OIDC federation – OpenID Connect – used by web-apps to identify themselves with AWS. AWS Cognito is the recommended service for this.
 
IAM Identities
-         Identity – user / group / role – provides authentication
-         Role – similar to IAM user (has permission policies) but with no password or access key
          §  Can be assigned to a user / federated user
-         User – person or application; username / password or up to 2 access key IDs (Access Key + Secret Key)
-         User Group – collection of users; can set permissions on the group level, but not an “identity” – can’t be a Principal in a permission policy
          §  Max 300 groups per account
          §  User can be a member of 10 IAM groups max
-         Temporary credentials - STS – used primarily with IAM roles; can have a restrictive set of permissions than a standard user. STS credentials expire after given period.
 
Access managements
-         Permissions are granted through policies; policies are attached to users / groups / roles
-         “Everything is denied by default”
-         Policy – document defining actions, resources, conditions
          §  Actions not explicitly allowed – denied by default
          §  Users / groups can have multiple policies attached
-         Example: can created a role with specific permissions for federated users only
-         Resource-based policy - can be attached to a resource (ex: S3 bucket)
          §  Unlike on user-based roles, need to specify a principal – who is allowed actions
          §  Specify what actions are permitted
 
IAM Users
-         GLOBAL entities – need not to specify region
-         Credentials:
          §  Console – access with username / password;
          §  MFA – available on all interfaces
          §  CLI / API –
                 §  Access key (access key ID + secret key); secret key can be downloaded only once – upon creation; no key recovery available – re-create; user can have two access keys at a time
                 §  Console password - console is just the user interface for the API
                 §  Signing certificates - some AWS services use X.509 signing certificates to validate requests that are signed with a corresponding private key. Can upload a X.509 signing certificate and associates it with the specified IAM user. Used mainly for SOAP-based interfaces and tools.
                 §  https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html
                 §  https://docs.aws.amazon.com/IAM/latest/APIReference/API_UploadSigningCertificate.html
-         New user – no permissions / credentials assigned by default
-         Service account – IA user that represents an application that needs access to AWS
-         5000 users max per account
-         User has:
                 §  “Friendly name”
                 §  ARN – Amazon Resource Name – internal identifier
                 §  Unique ID – only visible via CLI / API / Windows PowerShell tools; not console
-         Password changes:
                 §  Can allow all users to change their passwords
                 §  Can allow inly specific users to change their passwords – disable all-user option (on global policy); use IAM policy to allow changes – assign policy to user 
IAM Role
-         Set of permission – permissions are assigned to a role, not a user
-         Role has no long-term credentials (user has) – STS (temp credentials) are created and dynamically assigned to a user
-         Role can be used by:
                 §  User in same AWS account
                 §  User in a different AWS account
                 §  A service by AWS
                 §  External federated user
-         Role can be assumed via:
                 §  Console – when a user assumes a role in a remote account, his local permissions do not apply in the remote account ???
                 §  Programmatically via CLI, PowerShell, API – an application can request temp credentials for a role; this helps avoid creating long-term credentials
-         When a user assumes a role, he temporarily gives up his current permissions – gains those back when exists the role
-         Resource-based policy
                 §  assigned to a resource; specifies who (account id) has access to the resource
                 §  Cross-account access
                         §  advantage of using resource-based policy is that the trusted account user does not have to give up his local permissions
                         §  disadvantage – not all resources support resource-based policies
-         Service Role – permissions needed for a service to access AWS resources
                 §  Ex: an app in EC2 using IAM role to manage temporary credentials to access services
                 §  Better choice than saving access key on EC2
                 §  Can attach a role during EC2 launch or once EC is already running
                 §  EC2 – exception case; AWS automatically provides temp credentials attached to a role; new credentials are provided 5 min before the previous set is expired  
                 §  Only one role can be assigned to EC2 at a time
-         Instance profile - container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts. Cannot attach a role to an EC2 instance – thus use of an instance profile
                 §  https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html
                 §  An instance profile can contain only one IAM role, although a role can be included in multiple instance profiles
                 §  Only one role can be assigned to EC2 at a time
                 §  Creating role on console – corresponding instance profile is created automatically, same name as role
                 §  CLI or API – need to create role and profile separately; when launching – specify the instance profile name and not the role
                 §  Benefits of using a role
                 §  no need to manually manage credentials
                 §  if using a role across multiple EC2 – need to make changes only once, to a role
                 §  Best to use an IAM Roles when running an app on EC2 – rather than create an IAM user for the app and hard-code access credentials in the app. The role will have temporary credentials attached as well as permissions

Role Delegation
-         Account A – trusting; Account B – trusted
-         Delegation – setting up trust between Trusting and Trusted
-         Trusting (A) initiates the trust relationship
-         IAM Role with two policies required:
                 §  On Trusting
                 §  Permission policy (JSON) – WHAT - lists allowed actions and resources
                 §  Trust policy (JSON) – WHO – lists Trusted entity (Account NOT user) as Principal – cannot be “*”
                 §  On Trusted
                 §  Permission policy to switch to assume the trusting role
 
Cross-Account Access
-         https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console/
-         Two options:
                 §  Assign a Resource-based Policy to the resource naming the Trusted account as Principal
                 §  Advantage: user from the Trusted account will keep his permissions while operating in Trusted account AND assume permissions defined in the policy while operating in the Trusting account
                 §  Allowed on:
                        §  S3
                        §  Glacier
                        §  SNS
                 §  Create a Role – a user can switch a role. Under the new role the incoming user will run with only the permissions defined by the Role – his original permissions are suspended until he exits the new role.
 
Role – Use Cases
Don’t create IAM Users, use Roles:
-         App on EC2 - best to use an IAM Roles when running an app on EC2 – rather than create an IAM user for the app and hard-code access credentials in the app. The role will have temporary credentials attached as well as permissions
-         Mobile App – use Login with Amazon or Cognito or a 3rd party authentication (Facebook / Google / etc.)
-         Corporate users authenticating with on-premises AD – federate into AWS:
                 §  Is SAML 2.0 is supported by the AD – stablish a trust relationship w AWS
                 §  Create a custom proxy that translates the on-premise AD identities into AWS roles and provides temp credentials
 
Logging – CloudTrail
-         CloudTrail – not CloudWatch
-         Regional and Global sign-in endpoints exist depending on the nature of service (ex: S3 global)
 
Best Practice
-         Keep credentials safe
-         Create dedicated IAM users
-         Use AWS pre-defined policies whenever possible
-         Assign permissions on Group level
-         Do not over-assign permissions
-         AWS service access levels: Read, Write, List, Permission management
-         Define strong password policy
-         Use MFA
-         Use Roles for applications on EC2 – do not create a user for EC2 and save credentials on the instance
-         Share a Role and not credentials (role has credentials associated)
-         Rotate credentials
-         Remove unused logins
-         Use Policy Conditions – ex: allow an action on a resource when request comes from a specific source only
-         Monitor activity on the account

No comments:

Post a Comment