AWS Iden)ty And Access Management (IAM) Manohar Rapolu

Transcription

1 AWS Iden)ty And Access Management (IAM) Manohar Rapolu Topics Introduc5on Principals Authen5ca5on Authoriza5on Other Key Feature -> Mul5 Factor Authen5ca5on -> Rota5ng Keys -> Resolving Mul5ple Permissions Introduc)on IAM is one of the AWS service that allows you to control how users and applica5ons are allowed to manipulate your AWS infrastructure. IAM uses tradi5onal iden5ty concepts such as users, groups, and access control policies to control who can use your AWS account, what services and resources they can use, and how they can use them. IAM is not an iden5ty store/authoriza5on system for your applica5ons. IAM is not opera5ng system iden5ty management. 1

2 In brief, the below table can give you a brief idea on which role is played by different Authen5ca5on systems in your AWS environment. IAM is controlled like most other AWS Cloud services: Through the AWS Management Console With the CLI Via the AWS SDKs Eventually you may start wri5ng your own tools and complex processes by manipula5ng IAM directly through the REST API via one of several SDKs. Principals It is an IAM en5ty that is allowed to interact with AWS resources. A principal can be permanent or temporary, and it can represent a human or an applica5on. There are three types of principals: root users, IAM users, and roles/temporary security tokens. Roles and temporary security tokens enable a number of use cases: Amazon EC2 Roles Gran5ng permissions to applica5ons running on an Amazon EC2 instance. Cross-Account Access Gran5ng permissions to users from other AWS accounts, whether you control those accounts or not. Federa6on Gran5ng permissions to users authen5cated by a trusted external system. Authen)ca)on There are three ways that IAM authen6cates a principal: User Name/Password Access Key Access Key/Session Token 2

3 Authoriza)on AXer IAM has authen5cated a principal, it must then manage the access of that principal to protect your AWS infrastructure. The process of specifying exactly what ac5ons a principal can and cannot perform is called authoriza6on. Authoriza5on is handled in IAM by defining specific privileges in policies and associa5ng those policies with principals. Policies : A policy is a JSON document that fully defines a set of permissions to access and manipulate AWS resources. Policy documents contain one or more permissions, with each permission defining: Effect,Service, Resource "arn:aws:service:region:account-id:[resourcetype:]resource is the format in which the resource should be defined. And we can specify the required ac5ons and condi5ons which will limit the user to perform certain opera5ons only. Sample policy that allows a principal to list the objects in a specific bucket and to retrieve those objects, but only if the call comes from a specific IP address. Associa5ng Policies with principals - A policy can be associated directly with an IAM user in one of two ways: User Policy Managed Policies 3

4 The other common method for associa5ng policies with users is with the IAM groups feature. And there are two ways a policy can be associated with an IAM group: Group Policy Managed Policies Other Key Features Mul$ Factor Authen$ca$on: It adds an extra layer of security to your infrastructure by adding a second method of authen5ca5on beyond just a password or access key. With MFA, authen5ca5on also requires entering a One-Time Password (OTP) from a small device. The MFA device can be either a small hardware device you carry with you or a virtual device via an app on your smart phone (for example, the AWS Virtual MFA app). Rota$ng Keys : The security risk of any creden5al increases with the age of the creden5al. To this end, it is a security best prac5ce to rotate access keys associated with your IAM users. IAM facilitates this process by allowing two ac5ve access keys at a 5me. Steps for rota5ng keys: 1. Create a new access key for the user. 2. Reconfigure all applica5ons to use the new access key. 3. Disable the original access key (disabling instead of dele5ng at this stage is cri5cal, as it allows rollback to the original key if there are issues with the rota5on). 4. Verify the opera5on of all applica5ons. 5. Delete the original access key. Resolving Mul$ple Permissions Occasionally, mul5ple permissions will be applicable when determining whether a principal has the privilege to perform some ac5on. These permissions may come from mul5ple policies associated with a principal or resource policies afached to the AWS resource in ques5on. 4

5 It is important to know how conflicts between these permissions are resolved: 1. Ini5ally the request is denied by default. 2. All the appropriate policies are evaluated; if there is an explicit deny found in any policy, the request is denied and evalua5on stops. 3. If no explicit deny is found and an explicit allow is found in any policy, the request is allowed. 4. If there are no explicit allow or deny permissions found, then the default deny is maintained and the request is denied. The only excep5on to this rule is if an AssumeRole call includes a role and a policy, the policy cannot expand the privileges of the role (for example, the policy cannot override any permission that is denied by default in the role). Any Ques)ons? Thank you 5