What Is IAM ?

IAM Is A Crucial Aspect Of Cloud Security. All Kinds Of Businesses Require A Secure Environment Across Their Application Lifecycle. AWS Delivers A Great Baseline For Implementing A Least Rrivileged Approach To Permissions.

Identity And Access Management 

Identity And Access Management Is A Key Component Of Any Security Architecture. It Is A Framework That Ensures The Right People Can Access The Right Resources Or Services Securely. It’s All About Identifying The User And Giving The User Access To The Resources. 

How IAM Works?

Before We Create Users We Need To Understand How IAM Works. IAM Is A Global Service And Provides The Necessary Infrastructure That Can Centrally Manage The Following Elements

• Identification - Identifying The User 
• Authentication - Recognizing The User 
• Authorization - Determining If The User Is Allowed To Access The Resources  

AWS Identity And Access Management (IAM) Enables AWS Customers To Manage Users And User Permissions. AWS Has Some Specific Components Of Its IAM Systems. AWS Uses The Concept Of Principals

If You Want To Learn Practically About IAM How It Work, Types Of IAM , How To Create User , How To Create Group .Etc 

  Click Here For More Information

Principals

In AWS, A Principal Is An IAM Entity (Who Takes The Action) That Is Permitted To Access AWS Resources. AWS Further Breaks Down The Principal Concept Into Root Users, IAM Users, And Roles.

In The AWS Environment, There Are 3 Types Of Users.

• Root User 
• IAM User 
• Federated User 

Root User

The Root User Is The Owner Of The Account (The Person Who Created The AWS Account).

• The Root User Is Very Powerful And Has Full Access To All The Resources.
• The Root User Can Access The Console And Has Programmatic Access To Resources.
• The Root User Can Create Or Delete The Account And Upgrade And Downgrade The Support Plan.
• It Is Best To Use The Root User At The Time Of Creation And After That Set Up An IAM User Accounts To Use AWS Resources.

IAM User

• IAM User Is A Person Who Is Created By A Root User To Interact With AWS Resources.
• IAM User Can Sign In To The AWS Management Console And Can Make A Request To The AWS Services.
• The Newly Created IAM User Does Not Have Any Permission By Default To Access AWS Resources Root User Has To Assign Administrative Permission To The IAM User.
• IAM User Can Be Human Users Or Application Users (Called Services Users) With Associated Permission In Order To Access The AWS Services.
• A Human User Can Access AWS Resources Through The Management Console As Well As programmatically Whereas A Services user Can Access AWS Resources Only Programmatically.

IAM group

• A Group Is A Collection Of IAM Users Which Is Made To Grant Permission For The Same Kind Of User.
• If Permission Is Attached To A Group, Any User Of That Group Automatically Has The Same Permission Which Is To Manage.
• Use The Principle Of Least Privilege When Assigning Permission In A Group.
• In AWS, You Cannot Nest Group (Groups Within Groups).

IAM Roles

• In AWS We Create IAM Roles To Delegate Access.
• These Roles Are Attached To AWS Resources Which Determine What The Identity Can And Cannot Do.
• For This, We Need To Attach Permission To A IAM Role And Also Need To Specify The Trust Relationship.
• There Are No Credentials Associated With A Role (Password Or Access Keys).
• IAM Users Can Temporarily Assume A Role To Take A Permission For Specific Task.
• A Role Can Be Assigned To A Federated User Who Signs In Using An External Identity Provider.
• Temporary Credentials Are Primarily Used With IAM roles And Automatically Expire.

Example: 

Roles Are Used To Grant Permissions To Applications Running On An Instance That Need To Use A Bucket In Amazon S3. For This Kind Of Scenario, You Need To Attach Permission For IAM Roles By Creating A Policy In JSON Format.

There Are 4 Types Of IAM Roles

• Services Role 
• Services - Linked Role 
• Role For Cross Accounts Access 
• Role For Identity Provider Access 

A Service Role Is Basically A Role That Any AWS Service Assumes In Your Account On Your Behalf

 IAM Role Is Used By An AWS Service To Access Another Service,

• Example : EC2
• Accessing Dynamo DB.

Here Are Some Important Features Of IAM

Policy

• Polices Are Documents In AWS That When Associated With An Entity Or Resource , Define Their Permissions.
• Can Be Applied To Users, Groups And Roles .
• Policy Documents Are Written In JSON (Key-Value Pair That Consist Of An Attribute And A Value)
• All Permission Are Implicitly denied By Default .

AWS Supports 3 Types Of Policies

• Managed Policies 
• Customer Managed Policies 
• Inline Policies 

Managed Policy:

• Created And Administrated By AWS. 
• Used For Common Use Case.
• Can Be Attached To Multiples User, Groups And Roles.
• Cannot Change The Permission Assigned 

Customer Managed Policy:

Standalone Policy That You Create And Administer In Your Own AWS Account. (Standalone Policy Means That The Policy Has Its Own Amazon Resource Name (ARN) That Includes The Policy Name).

AWS-Managed Policies Are Designed To Provide Permissions For Many Common Use Cases

• Can Be Attached To A Multiple Users, Groups And Roles - But Only Within Your Own Accounts. 
• Can Be Created By Copying An Existing Managed Policy And Then Customizing It .
• Can Be Used Where AWS Managed Policies Don't Meet The Need Of Your Environment 

Inline Policy:

• Inline Policies Are Policies That You Can Create And Manage And Embed Directly Into A Single User, Group, Or Role To Which It Is Applied.
• Strict 1:1 Relationship Between The Entity And The Policy.
• When You Delete The User, Group, Or Role In Which The Inline Policy Is Embedded, The Policy Will Also Be Deleted.
• In Most Cases, AWS Recommends Using Managed Policies Instead Of Inline Policies.
• Inline Policies Are Useful When You Want To Be Sure That The Permissions In A Policy Are Not Assigned To Any Other User, Group, Or Role.

Identity-Based Policies –You Can Attach Managed And Inline Policies To IAM Identities (Users, Groups, And Roles).

Resource-Based Policies – Resource-Based Policies Grant Permissions To The Resource (Account, User, Role, Or Federated User) Specified As The Principal.

IAM Permissions Boundaries – Permissions Boundaries Are Used To Define The Maximum Permission That An Entity Can Have.

AWS Organizations Service Control Policies (SCPs) – Organizations SCPs Specifies The Maximum Permissions For An Organization Or Organizational Unit (OU).

Session Policies – Session Policies Are Advanced Policies That You Pass As Parameters When You Programmatically Create A Temporary Session For a Role Of A Federated User.

AWS Security Token Service

The AWS Security Token Service (STS) Is A Web Service That Enables You To Request Temporary, Limited-Privilege Credentials For IAM Users Or For Users That You Authenticate (Federated Users).

By Default, It Is A Global Service, And All AWS STS Requests Go To A Single Endpoint

You Can Send Your AWS STS Requests To Endpoints In Any Region Which Helps To Reduce Latency.

There Are A Couple Of Ways STS Can Be Used.

Scenario 1:

• Develop An Identity Broker To Communicate With LDAP (Light Weight Directory Access Protocol) And AWS STS. 
• Identity Broker Always Authenticates With LDAP First , Then With AWS STS.
• Application Then Gets Temporary Access To AWS Resources.

Scenario 2:

• Develop An Identity Broker To Communicate With LDAP And AWS STS.
• identity Broker Authentication With LDAP First , Then Gets An IAM Role Associated With The User.
• Application Then Authenticates With STS And Assumes That IAM Role.
• Application Uses That IAM Role To Interact With The Services 

To Make A Request In a Different Account The Resource In That Account Must Have An Attached Resource-Based Policy With The Permissions You Need.

Or You Must Assume A Role (Identity-Based Policy) Within That Account With The Permissions You Need.

IAM Best Practices

To Secure AWS Resources, It Is Recommended That You Follow These Best Practices:

• Lock Away Your AWS Accounts Root User Access Keys.
• Use Roles To Delegate Permission.
• Grant Least Privilege.
• Get Started Using Permission With AWS - Managed Policies.
• Validate Your Policies. 
• Use Customer - Managed Policies Instead Of Inline Policies.
• Use Access Levels To Review IAM Permission.
• Configure A Strong Password Policy For Your Users.
• Enable MFA 
• Use Role For Application That Run On Amazon EC2 Instance.
• Do Not Share Access Keys
• Rotate Credentials Regularly.
• Remove Unnecessary Credentials.

Conclusion

Security Is Everything For Any Kind Of Business, Whether You Need To Deploy A Cloud Or An On-Premises Solution, AWS Helps You Establish Trust, Protects Against Vulnerabilities, And Delivers Secure Access To Your Resources. AWS IAM Protects Against Outside And Inside Threats And Provides Security Without Affecting Efficiency. A Cloud Provider Like AWS Helps Customers To Solve Security Problems With Tools Like AWS Access Analyzer, Which Analyze And Recommend Best Practices.

If You Want To Learn AWS Cloud Practitioner And AWS Solution Architect From Scratch With All The Prerequisites, Including Linux For AWS, Docker Basics For AWS, Networking For AWS. Get Lifetime Access And 24*7 Support, As Well As Exam Preparation. Click Here For More Information Or Contact Us On +91 98257 57737 For Any Queries