AWS IAM Explained: Users, Roles, Policies & Security Best Practices
AWS IAM Explained: A Practical Guide to Securing AWS Resources
Users, Groups, Roles, Policies, MFA, Least Privilege, Temporary Credentials & Real-World Security
Cloud security ka naam aaye aur AWS Identity and Access Management (IAM) ki baat na ho, aisa mumkin nahi. Agar aap AWS, Cloud Engineering, DevOps, System Administration, ya Cybersecurity seekh rahe hain, to IAM un fundamental skills mein se ek hai jo aapko zaroor aani chahiye.
Who can do what on which AWS resource, and under what conditions?
Is article mein hum AWS IAM ko beginner-friendly lekin practical approach se samjhenge - users, groups, roles, policies, permissions, least privilege, MFA, temporary credentials, trust policies, aur real-world architecture ke saath.
What Is AWS IAM?
AWS Identity and Access Management (IAM) AWS ki service hai jo AWS resources tak access ko securely control karne mein madad karti hai. Company mein developers, administrators, applications aur servers sab AWS resources use kar sakte hain, lekin har identity ko har resource ka full access dena serious security risk ho sakta hai.
Developer ko S3 files read karne ki permission chahiye.
Application server ko sirf ek specific S3 bucket access karna hai.
Database administrator ko database-related permissions chahiye.
Junior developer ko production resources delete karne ki permission nahi honi chahiye.
IAM isi access ko controlled, auditable aur secure banane ka mechanism provide karta hai.
Authentication vs Authorization
Authentication - Who Are You?
Authentication verify karta hai ke access request karne wali identity asal mein kaun hai. Passwords, credentials, MFA, federation aur temporary security credentials authentication process ka hissa ho sakte hain.
Are you really the person or workload you claim to be?
Authorization - What Are You Allowed to Do?
Identity verify hone ke baad authorization determine karta hai ke woh identity kaun se actions perform kar sakti hai. Successful sign-in ka matlab automatically full AWS access nahi hota.
Authentication identifies you. Authorization determines what you can do.
Core Components of AWS IAM
1. IAM Users
IAM user ek AWS identity hoti hai jise specific permissions assign ki ja sakti hain. Modern AWS environments mein workforce access ke liye long-lived IAM users par unnecessarily depend karne ke bajaye federated access, AWS IAM Identity Center, roles aur temporary credentials ko prefer kiya jata hai.
AWS Account
|
+-- User: Ali
+-- User: Ahmed
+-- User: Sara2. IAM Groups
Jab multiple IAM users ko same permissions deni hon, IAM groups management ko easier aur more consistent bana dete hain.
Developers
|
+-- Ali
+-- Ahmed
+-- SaraInstead of har developer ko individually same permissions assign karne ke, relevant permissions group ke through manage ki ja sakti hain.
3. IAM Policies - The Heart of Permissions
IAM policy define karti hai ke kisi identity ko AWS environment mein kya karne ki permission hai ya kya explicitly deny kiya gaya hai. Policies generally JSON documents hoti hain.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::company-reports/*"
}
]
}Effect - Allow hai ya Deny?
Action - Kaunsa AWS operation perform ho sakta hai?
Resource - Permission kis AWS resource par apply hoti hai?
4. IAM Roles - One of the Most Important AWS Concepts
IAM role ko ek assumable identity with permissions samjhein. AWS services, applications, federated users aur cross-account access roles ke common use cases hain.
Insecure Pattern: Hard-Coded Credentials
Application
|
+-- AWS Access Key
+-- AWS Secret KeyCredentials ko source code, configuration files ya repositories mein hard-code karna security risk create kar sakta hai.
Better Pattern: Role + Temporary Credentials
EC2 Instance
|
v
IAM Role
|
v
Temporary Credentials
|
v
S3 BucketAWS workloads ke liye static credentials hard-code karne ke bajaye roles aur temporary credentials ko prefer karein.
Trust Policy vs Permissions Policy
Trust Policy
Trust policy answer karti hai: Who is allowed to assume this role?
EC2
|
v
Can assume WebServerRolePermissions Policy
Permissions policy answer karti hai: Role assume hone ke baad woh kya kar sakta hai?
WebServerRole
|
v
Can perform s3:GetObjectTrust Policy = Who can assume the role? | Permissions Policy = What can the role do?
Principle of Least Privilege
AWS security ka golden principle hai: har human ya workload ko sirf utni permissions dein jitni uske required task ke liye necessary hon.
Overly Broad Permission
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}Restricted Permission
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::company-reports/*"
}Restricted permission attack surface aur accidental damage ke risk ko reduce karti hai. Production IAM design mein least privilege ek default mindset hona chahiye.
Explicit Deny vs Allow
Agar ek applicable policy action ko Allow karti hai lekin doosri applicable policy usi action ko explicitly Deny karti hai, to explicit Deny win karta hai.
Policy A: ALLOW -> s3:DeleteObject
Policy B: DENY -> s3:DeleteObject
Final Result: ACCESS DENIEDExplicit Deny overrides Allow. Agar required Allow exist hi na kare, request normally implicitly denied hoti hai.
What Is an ARN?
ARN stands for Amazon Resource Name. AWS resources ko identify karne ke liye ARNs use kiye jate hain, aur IAM policies mein ye frequently Resource field ke andar nazar aate hain.
arn:aws:s3:::company-reports
arn:aws:iam::123456789012:role/WebServerRoleARN dekh kar sochiye: This tells AWS exactly which resource the permission applies to.
MFA: An Essential Security Layer
MFA stands for Multi-Factor Authentication. Primary authentication mechanism ke saath additional factor account security ko significantly improve kar sakta hai, especially privileged access ke liye.
Root user ko routine administrative work ke liye use na karein.
Root credentials ko securely protect karein.
MFA enable karein, especially privileged access ke liye.
Day-to-day work ke liye appropriately permissioned identities use karein.
IAM User vs IAM Role
| Aspect | IAM User | IAM Role |
|---|---|---|
| Identity type | IAM identity | Assumable IAM identity |
| Credentials | Long-term credentials possible | Commonly temporary credentials |
| Typical use | Specific or legacy scenarios | Workloads, federation, cross-account access |
| Permission model | Permissions directly assigned possible | Permissions available when role is assumed |
Real-World Example: EC2 Accessing an S3 Bucket
Suppose company ki web application EC2 instance par chal rahi hai aur usay customer-images S3 bucket se images read karni hain.
User
|
v
Web Application
|
v
EC2 Instance
|
v
WebServerRole
|
v
Temporary AWS Credentials
|
v
S3: GetObject
|
v
customer-images BucketRole Permission Example
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::customer-images/*"
}
]
}| Action | Access |
|---|---|
| Read Object | Allowed |
| Upload Object | Not allowed |
| Delete Object | Not allowed |
| Delete Bucket | Not allowed |
IAM Security Best Practices
Follow least privilege and avoid unnecessary permissions.
Minimize long-lived credentials; prefer roles and temporary credentials where appropriate.
Never hard-code access keys in source code or public repositories.
Use MFA, particularly for privileged access.
Avoid using the root user for everyday tasks.
Review permissions regularly and remove old or unnecessary access.
Understand and use roles for AWS services, applications, federation and cross-account access.
Handle explicit Deny carefully because it can override applicable Allows.
IAM Interview Questions You Should Be Ready For
What is AWS IAM?
AWS IAM is a service for securely controlling identities and their access to AWS resources.
What is the principle of least privilege?
Users and workloads ko sirf wahi permissions dena jo unke required tasks perform karne ke liye necessary hain.
What is the difference between authentication and authorization?
Authentication verifies identity; authorization determines what that identity is permitted to do.
Why use IAM roles instead of hard-coded access keys?
Roles temporary credentials provide kar sakte hain, jis se applications mein long-lived AWS credentials store aur manage karne ki zarurat reduce hoti hai.
What happens if one applicable policy allows an action while another explicitly denies it?
The explicit Deny wins.
What is the difference between a role's trust policy and permissions policy?
Trust policy determines who can assume the role, while permissions policies determine what the role can do after it is assumed.
Final Thoughts
AWS IAM sirf users aur passwords manage karne ki service nahi hai. Ye AWS security architecture ke core components mein se ek hai. Har access scenario mein five questions poochna IAM ko logical bana deta hai.
WHO
|
v
WHAT ACTION
|
v
WHICH RESOURCE
|
v
WHICH PERMISSION
|
v
WHAT CONDITIONS?The goal of good IAM design is to give every human and workload exactly the access required to do its job - securely, deliberately, and with as little unnecessary privilege as possible.
Blogger SEO Metadata
| SEO Title | AWS IAM Explained: Users, Roles, Policies & Security Best Practices |
|---|---|
| Meta Description | Learn AWS Identity and Access Management (IAM) from beginner to practical level. Understand IAM users, groups, roles, policies, MFA, least privilege, temporary credentials, trust policies, and real-world AWS security examples. |
| Suggested Labels | AWS, AWS IAM, Cloud Computing, Cloud Security, DevOps, Cybersecurity, AWS Tutorial, IAM Roles, AWS for Beginners |
Comments
Post a Comment