AWS मध्ये कोण काय करू शकतो, हे शाळेच्या ओळखपत्र कार्यालयाच्या रूपात शिकवले आहे: कार्डे, याद्या, परवानगी चिठ्ठ्या, उसनी टोपी आणि एक नोंदवही. प्रत्येक धडा म्हणजे एक शाळेची गोष्ट, सोबत काढलेली आकृती आणि एक lab — आणि ओळखपत्र कार्यालय repo मध्येच आहे: AWS च्या policy evaluation चे शुद्ध Python मधले शिकवणी model (iam/evaluate.py, शून्य dependencies), ज्याला प्रत्येक धडा प्रश्न विचारतो, तपासतो आणि मोडतो.
🪪 ओळख (identities)📝 policies⚖️ निर्णय (evaluation)🎩 roles & STS🤖 OIDC🏷️ ABAC🚧 SCPs & boundaries🤝 cross-account🧾 CloudTrail
🪪 भाग 1 — ओळखपत्र कार्यालय (1–6)
प्रत्येक request वर सही का असते आणि ती का तपासली जाते 🪪
कार्डे, याद्या आणि मास्टर चावी 👥
परवानगी चिठ्ठी आणि नियमपुस्तकाचा क्रम 📝⚖️
उसन्या टोप्या आणि robot बिल्ले 🎩🤖
🛡️ भाग 2 — सुरक्षितपणे चालवणे (7–12)
फक्त जेव्हा…: MFA, networks, tags 🏷️
फक्त काढून घेणारी छते 🚧
दोन शाळा, दोन दरवाजे 🤝
एक login, कमीत कमी अधिकार, नोंदवही 🏢✂️🧾
# the 60-second wow — every lesson's decision, live:
git clone https://github.com/BaluRaut/learn-iam-school.git && cd learn-iam-school
python3 iam/demo.py # 12 lessons, every decision with its reason
python3 iam/test_iam.py # 12 checks, one per lesson
तुम्हाला काय दिसायला हवे (छाटलेले — यश असे दिसते):
═══ why ═══
── every request is signed: WHO is asking, WHAT action, on WHICH thing — the ID office decides
🚫 aishwarya, no policies yet → s3:GetObject IMPLICIT DENY — no policy allows it — AWS denies by default
🧾 CloudTrail writes one line per request: time · who · action · resource · decision
🗝️ the root account is NOT evaluated by these rules — it can do everything; lock it away with MFA
═══ users ═══
── the teachers group carries the policies; people only join or leave the list
✅ aishwarya (teachers) reads a report ALLOW — identity policy read-reports#ReadReports allows it
✅ katrina (teachers) reads a report ALLOW — identity policy read-reports#ReadReports allows it
🚫 dipika (no groups) reads a report IMPLICIT DENY — no policy allows it — AWS denies by default
✅ dipika joins teachers → reads a report ALLOW — identity policy read-reports#ReadReports allows it
═══ policies ═══
── one statement, four fields: {"Sid": "OwnFolderOnly", "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::school-homework/${aws:username}/*"}
✅ aishwarya puts school-homework/aishwarya/essay.txt ALLOW — identity policy own-homework-folder#OwnFolderOnly allows it
🚫 aishwarya puts school-homework/katrina/essay.txt IMPLICIT DENY — no policy allows it — AWS denies by default
${aws:username} is filled in per caller — one policy, a private folder for every teacher
═══ decide ═══
── start at DENY · an Allow opens the door · an explicit Deny slams it, whatever else says yes
✅ katrina, admin policy → DeleteObject report ALLOW — identity policy admin#Everything allows it
⛔ katrina, admin + deny-delete → DeleteObject DENY — explicit Deny in identity policy deny-delete-reports#NeverDeleteReports — nothing overrides it
✅ katrina, admin + deny-delete → GetObject ALLOW — identity policy admin#Everything allows it
🚫 dipika, nothing attached → GetObject IMPLICIT DENY — no policy allows it — AWS denies by default
═══ roles ═══
🎩 ci-robot asks to wear ci-deployer → trust policy lets them ✅
🎩 dipika asks to wear ci-deployer → trust policy refuses 🚫
🎟️ temporary credentials (an example): AccessKeyId ASIAEXAMPLECIDEPLOY · SessionToken … · Expiration +1 hour — nothing long-lived to leak
✅ role session → ecr:PutImage ALLOW — identity policy ci-deploy#PushImages allows it
🚫 same session + read-only session policy IMPLICIT DENY — outside the session policy passed to AssumeRole
═══ machines ═══
── GitHub Actions shows a signed OIDC token; the role's trust policy checks its claims — no stored AWS key at all
✅ token sub = repo:BaluRaut/school-app:ref:refs/heads/main → role assumed, 1-hour credentials
🚫 token sub = repo:BaluRaut/school-app:ref:refs/heads/feature-x → refused
🚫 token sub = repo:someone/fork:ref:refs/heads/main → refused
EC2: instance profile · Lambda: execution role · EKS: IRSA / Pod Identity — same idea: the platform hands out the badge
═══ conditions ═══
🚫 aishwarya, no MFA → iam:CreateUser IMPLICIT DENY — no policy allows it — AWS denies by default
✅ aishwarya, with MFA → iam:CreateUser ALLOW — identity policy iam-needs-mfa#IamOnlyWithMfa allows it
✅ katrina from the office 203.0.113.40 ALLOW — identity policy read-reports#ReadReports allows it
⛔ katrina from a café 198.51.100.9 DENY — explicit Deny in identity policy office-network-only#DenyOutsideOffice — nothing overrides it
✅ team=maths stops a team=maths instance ALLOW — identity policy abac-own-team#StartStopOwnTeam allows it
🚫 team=maths stops a team=science instance IMPLICIT DENY — no policy allows it — AWS denies by default
ABAC: one policy, tags decide — a new team needs a tag, not a new policy
═══ guardrails ═══
✅ dev with admin, no boundary → iam:CreateUser ALLOW — identity policy admin#Everything allows it
🚫 dev with admin + boundary → iam:CreateUser IMPLICIT DENY — outside the permission boundary — the boundary is a ceiling, not a grant
✅ dev with admin + boundary → s3:PutObject ALLOW — identity policy admin#Everything allows it
✅ admin in the org, ap-south-1 → RunInstances ALLOW — identity policy admin#Everything allows it
⛔ admin in the org, sa-east-1 → RunInstances DENY — explicit Deny in SCP scp-two-regions#OnlyMumbaiAndVirginia — nothing overrides it
effective = identity ∩ boundary ∩ session ∩ SCP — guardrails only ever take away
═══ crossaccount ═══
✅ partner auditor: both sides allow ALLOW — cross-account: identity policy partner-auditor-identity#ReadSchoolReports AND resource policy bucket-policy-reports#PartnerAuditorReads both allow
🚫 partner auditor: bucket policy only IMPLICIT DENY — cross-account needs BOTH sides to allow — the caller's identity policy does not
🚫 partner auditor: identity policy only IMPLICIT DENY — cross-account needs BOTH sides to allow — the resource policy in the other account does not
🚫 partner auditor tries DeleteObject IMPLICIT DENY — cross-account needs BOTH sides to allow — the caller's identity policy does not
two doors, two keys: the partner's account AND the school's bucket must both say yes
═══ people ═══
── IAM Identity Center: one login for people; permission sets become roles in every account
👥 teachers-group → permission set Teachers → role arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Teachers_…
👥 it-group → permission set Admins → role arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Admins_…
👥 it-group → permission set Admins → role arn:aws:iam::444455556666:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Admins_…
✅ aishwarya via SSO (Teachers) → read a report ALLOW — identity policy read-reports#ReadReports allows it
🚫 aishwarya via SSO (Teachers) → terminate EC2 IMPLICIT DENY — no policy allows it — AWS denies by default
no IAM users for people, no long-lived keys — a leaver is disabled once, in one place
═══ leastpriv ═══
── granted: ['s3:*', 'ec2:*', 'dynamodb:*'] · actually used in 90 days: ['s3:GetObject', 's3:ListBucket', 's3:PutObject', 'ec2:DescribeInstances']
💤 services granted but never used: ['dynamodb:*'] — remove them
✂️ generated policy from what was used: ["ec2:DescribeInstances", "s3:GetObject", "s3:ListBucket", "s3:PutObject"]
✅ narrowed policy → s3:GetObject ALLOW — identity policy narrowed#0 allows it
🚫 narrowed policy → dynamodb:DeleteTable IMPLICIT DENY — no policy allows it — AWS denies by default
then narrow Resource from * to the real bucket — Access Analyzer's policy generation does these steps from CloudTrail
═══ audit ═══
── the credential report (iam/data/credential-report.csv), read like an auditor
✅ <root_account> fine
✅ aishwarya fine
⚠️ katrina password without MFA, key 329 days old
⚠️ dipika password without MFA, key 931 days old, key unused > 90 days → delete
✅ ci-robot fine
── CloudTrail (iam/data/cloudtrail.json): a key used from a new country at 2 a.m.
2026-09-26T09:12:04Z katrina GetObject ap-south-1 203.0.113.40
2026-09-26T09:40:11Z katrina ListBuckets ap-south-1 203.0.113.40
🚨 2026-09-27T02:03:55Z katrina GetCallerIdentity us-east-1 198.51.100.77
🚨 2026-09-27T02:04:20Z katrina RunInstances sa-east-1 198.51.100.77 AccessDenied
🚨 2026-09-27T02:04:31Z katrina CreateUser us-east-1 198.51.100.77 AccessDenied
2026-09-27T08:15:00Z aishwarya GetObject ap-south-1 203.0.113.12
runbook: 1 deactivate AKIAEXAMPLEKATRINA01 · 2 revoke sessions · 3 look for what it created · 4 rotate · 5 find how it leaked
✅ done — every decision above came from iam/evaluate.py
🎒 धडा 01 आधी: तुम्हाला फक्त Python 3 हवे — दुसरे काही नाही; AWS account नको, SDK नको. हा lab म्हणजे AWS च्या documented policy evaluation चे शिकवणी model आहे — खऱ्या policies IAM Policy Simulator ने किंवा aws iam simulate-principal-policy ने तपासा. चांगले शेजारी: EC2 शाळा (हे बिल्ले घालणारे बाक) आणि AWS शाळा (संपूर्ण परिसर एकाच कोर्समध्ये).
एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. प्रत्येक निर्णय iam/evaluate.py घेतो — AWS account ची गरज नाही.
1
🪪 IAM का
शाळेचे ओळखपत्र कार्यालय — प्रत्येक request वर सही असते, ती तपासली जाते आणि लिहून ठेवली जाते; कोणी हो म्हणेपर्यंत काहीच परवानगी नाही.lesson-01-why-iamधडा वाचा →आकृती पहा ↗
2
👥 Users, groups & root
कार्डे यादीत सामील होतात — परवानग्या group ला जोडल्या जातात, लोक येतात आणि जातात; मास्टर चावी तिजोरीतच राहते.lesson-02-users-groups-rootधडा वाचा →आकृती पहा ↗
3
📝 Policies
परवानगी चिठ्ठी — Effect, Action, Resource, Condition; ARNs, wildcards आणि ${aws:username}.lesson-03-policiesधडा वाचा →आकृती पहा ↗
4
⚖️ AWS कसा निर्णय घेतो
नियमपुस्तकाचा क्रम — मूळ नियम deny, एक Allow दरवाजा उघडतो, एक स्पष्ट Deny तो धाडकन बंद करतो, बाकी कोणीही हो म्हणो.lesson-04-how-aws-decidesधडा वाचा →आकृती पहा ↗
5
🎩 Roles & STS
उसनी घेतलेली टोपी — trust policy सांगते कोण ती घालू शकतो, permissions सांगतात ती काय करू शकते, पास संपतो.lesson-05-roles-stsधडा वाचा →आकृती पहा ↗
6
🤖 मशीनच्या ओळखी
robots ना बिल्ले मिळतात, कधीच keys नाहीत — instance profiles, Lambda roles, GitHub OIDC, EKS Pod Identity.lesson-06-machine-identitiesधडा वाचा →आकृती पहा ↗
🛡️ भाग 2 — ओळखपत्र कार्यालय सुरक्षितपणे चालवणे (धडे 7–12)
खऱ्या AWS accounts ना काय लागते: conditions, organization guardrails, cross-account access, single sign-on, कमीत कमी अधिकार आणि incident runbook.
7
🏷️ Conditions & ABAC
फक्त जेव्हा… — MFA, कार्यालयाचे network, आणि जुळणारे tags: प्रत्येक team साठी एकच policy.lesson-07-conditions-abacधडा वाचा →आकृती पहा ↗
8
🚧 Guardrails
छते, देणग्या नाहीत — permission boundaries, SCPs आणि session policies फक्त काढूनच घेतात.lesson-08-guardrailsधडा वाचा →आकृती पहा ↗
9
🤝 Cross-account आणि resource policies
दोन शाळा, दोन दरवाजे — बोलावणाऱ्याचे account आणि resource ची policy, दोघांनीही हो म्हणायला हवे.lesson-09-cross-accountधडा वाचा →आकृती पहा ↗
10
🏢 मोठ्या प्रमाणावर लोक
प्रत्येक account साठी एकच login — IAM Identity Center, groups, permission sets; सोडून जाणाऱ्याला एकदाच बंद केले जाते.lesson-10-people-at-scaleधडा वाचा →आकृती पहा ↗
11
✂️ कमीत कमी अधिकार
दिलेले विरुद्ध वापरलेले — कोणी न वापरलेले शोधा, अरुंद policy तयार करा, Access Analyzer ने ती अरुंदच ठेवा.lesson-11-least-privilegeधडा वाचा →आकृती पहा ↗
12
🧾 Audit & incident response
कार्यालयाची नोंदवही — credential reports, CloudTrail, आणि key फुटल्यावरच्या पाच पायऱ्या.lesson-12-audit-incidentsधडा वाचा →आकृती पहा ↗
🗣️ मोठ्याने समजावून सांगा — धडा 12 नंतर: (1) स्पष्ट Deny हा Allow वर का भारी पडतो, आणि "implicit deny" म्हणजे काय? (2) role ची trust policy आणि तिची permission policy — कोणती "कोण" चे उत्तर देते आणि कोणती "काय" चे? (3) permission boundary काहीच का देऊ शकत नाही? (4) partner account ला तुमचा bucket वाचता यावा म्हणून कोणत्या दोन गोष्टी खऱ्या असायला हव्यात? (5) साठवलेल्या key शिवाय GitHub Actions AWS मध्ये कसे येते? (6) एक key रात्री 2 वाजता नव्या देशातून वापरली गेली — पाच पायऱ्या सांगा.
🎓 याच शाळेतून:EC2 · AWS · Kubernetes · CI/CD — तेच उपमांचे विश्व, तीच branch-दर-branch पद्धत.
📐 धड्यांच्या आकृत्या — क्रमांक अनुसरा
प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.
1 🪪 IAM का
शाळेचे ओळखपत्र कार्यालय — प्रत्येक request वर सही असते, ती तपासली जाते आणि लिहून ठेवली जाते; कोणी हो म्हणेपर्यंत काहीच परवानगी नाही.
🧒 सोप्या शब्दांत
शाळेत फक्त हसून ग्रंथालयात किंवा प्रयोगशाळेत जाता येत नाही. दार ओळखपत्र कार्यालयाला विचारते: तू कोण, तुला काय करायचे, कोणती खोली? कार्यालय प्रत्येक उत्तर 'नाही' पासून सुरू करते, लिखित नियम परवानगी देत असेल तरच 'हो' म्हणते, आणि प्रत्येक प्रश्न नोंदवहीत लिहिते. AWS मध्ये प्रत्येक request साठी IAM हेच कार्यालय आहे.
📖 नवे शब्दIAM — प्रत्येक AWS request साठी कोण विचारतोय आणि त्याला परवानगी आहे का ते तपासणारे ओळखपत्र कार्यालयauthentication — तुम्ही कोण आहात ते सिद्ध करणे, जसे स्वतःचे ओळखपत्र दाखवणेauthorization — लिखित नियम वाचून ती व्यक्ती ही गोष्ट करू शकते का ते ठरवणेimplicit deny — मूळ उत्तर: कोणत्याही नियमाने हो म्हटले नाही, म्हणून उत्तर नाहीCloudTrail — प्रत्येक request लिहून ठेवणारी नोंदवही: कोण, काय, कशावर आणि कधी
⏪ आधी
ओळखपत्र कार्यालयाशिवाय key असलेला कोणीही कोणताही AWS API call करू शकला असता, आणि काय कोणी delete केले ते कधीच कळले नसते.
💡 काय
IAM म्हणजे ओळखपत्र कार्यालय: प्रत्येक request ही कोण, काय आणि कशावर सांगणारी सही केलेली चिठ्ठी असते, आणि काहीही घडण्याआधी IAM निर्णय देतो.
⚙️ कसे
अजून एकही policy नसलेली aishwarya school-reports/term1.pdf वर s3:GetObject मागते: तिची सही बरोबर ठरते, पण उत्तर IMPLICIT DENY.
🎯 का
उत्तर 'नाही' पासून सुरू होते म्हणून विसरलेला नियम सुरक्षितच ठरतो, आणि CloudTrail प्रत्येक request ची एक ओळ लिहितो: वेळ, कोण, action, resource.
🚀 पुढे
पुढचा धडा कार्डे वाटतो: users aishwarya, katrina आणि dipika, एक teachers group, आणि MFA सह तिजोरीत बंद केलेला root user.
🧪 Try it here — ओळखपत्र कार्यालयाला एक सही केलेली request पाठवा — कोण विचारतोय, काय, कोणत्या गोष्टीवर
कार्डे यादीत सामील होतात — परवानग्या group ला जोडल्या जातात, लोक येतात आणि जातात; मास्टर चावी तिजोरीतच राहते.
🧒 सोप्या शब्दांत
नवीन शिक्षिका आली की कार्यालय तिच्या कार्डवर प्रत्येक परवानगी असलेली खोली लिहीत नाही. तिला teachers यादीत टाकते, आणि नियम त्या यादीला लावलेले असतात. Dipika यादीत नव्हती, म्हणून reports च्या कपाटाने नाही म्हटले; ती सामील होताच हो म्हटले. सगळे उघडणारी मास्टर चावी दुसऱ्या कुलुपासह तिजोरीतच राहते.
📖 नवे शब्दIAM user — एका व्यक्तीचे स्वतःचे कार्ड, password सह आणि कदाचित access key सहgroup — users ची नाव असलेली यादी, जसे teachers; तिला लावलेले नियम यादीतील सगळ्यांना लागू होतातroot user — account बनवताना तयार झालेली मास्टर चावी; ती सगळे करू शकते, म्हणून ती बंद करून ठेवाMFA — दुसरे कुलूप: password सोबत phone वरचा code
⏪ आधी
प्रत्येकाच्या कार्डवर लिहिलेले नियम भरकटतात: शिक्षक काम बदलतो पण जुने अधिकार ठेवतो, सोडून गेलेल्याकडे चालू key राहते.
💡 काय
IAM user म्हणजे एका व्यक्तीचे कार्ड; group म्हणजे यादी, जिच्या policies यादीतील सगळ्यांना लागू होतात. Group स्वतः request वर सही करू शकत नाही.
⚙️ कसे
read-reports ही teachers ला जोडलेली आहे: aishwarya आणि katrina ला ALLOW, कोणत्याही group मध्ये नसलेल्या dipika ला IMPLICIT DENY, सामील होताच ALLOW.
🎯 का
Policy न बदलता फक्त यादीत येऊन किंवा जाऊन access बदलतो, आणि root ची मास्टर चावी MFA सह तिजोरीत राहते.
🚀 पुढे
पुढचा धडा यादीला लावलेल्या चिठ्ठ्या उघडतो: Effect, Action, Resource आणि Condition, आणि ${aws:username} ही रिकामी जागा.
🧪 Try it here — teachers यादीत कोण आहे ते निवडा, मग ओळखपत्र कार्यालयाला सगळ्यांसाठी एकदम विचारा
परवानगी चिठ्ठी — Effect, Action, Resource, Condition; ARNs, wildcards आणि ${aws:username}.
🧒 सोप्या शब्दांत
कार्यालयातील परवानगी चिठ्ठीवर चार ओळी असतात: हो की नाही, काय करू शकता, कशावर, आणि फक्त केव्हा. एक चिठ्ठी सांगते 'स्वतःचे नाव असलेले homework चे कप्पे वापरू शकता'. Aishwarya च्या प्रतीवर aishwarya आणि Katrina च्या प्रतीवर katrina, म्हणून एकच चिठ्ठी प्रत्येक शिक्षकाला चालते आणि कोणीही दुसऱ्याच्या कप्प्यापर्यंत पोहोचत नाही.
📖 नवे शब्दpolicy — कोण कशावर काय करू शकतो ते सांगणारी JSON मधील लिखित परवानगी चिठ्ठीEffect — चिठ्ठीवरचा निकाल: Allow किंवा DenyAction — तुम्हाला करायची गोष्ट, service:Verb असे लिहिलेली, जसे s3:PutObjectARN — एका AWS वस्तूचा पूर्ण पत्ता, जसे arn:aws:s3:::school-reports/term1.pdf${aws:username} — चिठ्ठीवरची रिकामी जागा, जी विचारणाऱ्याच्या स्वतःच्या नावाने भरते
⏪ आधी
नेमक्या चिठ्ठ्यांशिवाय 'शिक्षक homework वापरू शकतात' म्हणजे एकतर प्रत्येक folder उघडा, किंवा प्रत्येक शिक्षकासाठी वेगळा हाताने लिहिलेला नियम.
💡 काय
Policy statement मध्ये चार fields: Effect (Allow किंवा Deny), Action (s3:PutObject), Resource (एक ARN) आणि ऐच्छिक Condition.
⚙️ कसे
OwnFolderOnly फक्त school-homework/${aws:username}/* ला परवानगी देते: aishwarya ने aishwarya/essay.txt लिहिले तर ALLOW, katrina/essay.txt ला IMPLICIT DENY.
🎯 का
एकच छोटी policy प्रत्येक शिक्षकाला खाजगी folder देते, आणि चुकीच्या जागी एक * किंवा राहिलेले /* data कोण पाहू शकतो ते बदलते.
🚀 पुढे
पुढचा धडा विचारतो, एक चिठ्ठी हो आणि दुसरी नाही म्हणाली तर काय: AWS प्रत्येक policy कोणत्या क्रमाने वाचतो.
🧪 Try it here — own-homework-folder.json: username आणि path टाइप करा — ${aws:username} भरताना पाहा
नियमपुस्तकाचा क्रम — मूळ नियम deny, एक Allow दरवाजा उघडतो, एक स्पष्ट Deny तो धाडकन बंद करतो, बाकी कोणीही हो म्हणो.
🧒 सोप्या शब्दांत
Katrina कडे 'सगळे करू शकते' अशी चिठ्ठी आहे. मग मुख्याध्यापक दुसरी चिठ्ठी लावतात: 'report cards कधीच फेकायचे नाहीत'. Katrina एखादे फेकायला जाते तेव्हा कारकून आधी कोणतीही 'कधीच नाही' चिठ्ठी शोधतो आणि तिथेच थांबतो. ती reports अजूनही वाचू शकते, कारण 'कधीच नाही' चिठ्ठी फक्त फेकण्याबद्दल बोलते.
📖 नवे शब्दexplicit Deny — नाही, कधीच नाही म्हणणारी चिठ्ठी; कोणत्याही क्रमात ती प्रत्येक हो वर मात करतेAllow — हो म्हणणारी चिठ्ठी; कोणताही Deny जुळत नसेल तरच ती दार उघडतेimplicit deny — कोणत्याही चिठ्ठीने हो म्हटले नाही, म्हणून दार आपोआप बंदच राहतेPolicy Simulator — खरी policy काय निर्णय देईल ते तपासण्याचे AWS चे स्वतःचे tool
⏪ आधी
ठरलेल्या क्रमाशिवाय admin policy आणि 'reports कधीच delete करू नका' हा नियम भांडले असते, आणि कोण जिंकेल हे नशिबावर असते.
💡 काय
AWS evaluation: सुरुवात deny पासून, Allow दार उघडते, आणि कोणत्याही policy मधला स्पष्ट Deny ते बंद करतो, बाकी कोणीही हो म्हणो.
⚙️ कसे
katrina कडे admin आहे: DeleteObject ला ALLOW; deny-delete-reports जोडताच ते DENY होते, पण term1.pdf वरचे GetObject ALLOW च राहते.
🎯 का
प्रत्येक 'मला नकार का?' चे उत्तर दोनपैकी एक: शोधायचा असलेला स्पष्ट Deny, किंवा नेमकेपणाने जोडायचा राहिलेला Allow.
🚀 पुढे
पुढचा धडा कायमच्या कार्डांऐवजी टोप्या देतो: roles, trust policies आणि एका तासात संपणारी STS credentials.
🧪 Try it here — katrina ला चिठ्ठ्या जोडा आणि एक request निवडा — सहापैकी कोणती तपासणी उत्तर देते ते पाहा
उसनी घेतलेली टोपी — trust policy सांगते कोण ती घालू शकतो, permissions सांगतात ती काय करू शकते, पास संपतो.
🧒 सोप्या शब्दांत
परीक्षा हॉल फक्त पर्यवेक्षकाची टोपी घातलेल्यासाठीच उघडतो. टोपी कोणाच्याच मालकीची नाही: तुम्ही कार्यालयाला विचारता, ते टोपीच्या लेबलवरील नावे तपासते, आणि एका तासासाठी देते. CI robot लेबलवर आहे; Dipika नाही. टोपीवरचा sticker 'आज फक्त पाहा' सांगू शकतो, जो परवानग्या कमी करतो पण कधीच वाढवत नाही.
📖 नवे शब्दrole — परवानगी असलेला कोणीही काही वेळ घालू शकेल अशी टोपी; तिला password किंवा कायमची key नसतेtrust policy — टोपीवरचे लेबल, जे ती कोण घालू शकतो ते सांगतेSTS — टोपी देणारी आणि ठराविक वेळेत, बहुधा एका तासात, संपणारा pass देणारी खिडकीsession policy — एका session साठी लावलेला sticker, जो फक्त परवानग्या कमी करू शकतो
⏪ आधी
दीर्घकाळ चालणारी access key असलेल्या robot ची key git, logs आणि laptops मध्ये वर्षानुवर्षे चालू राहते, कोणाला गळती दिसेपर्यंत.
💡 काय
Role म्हणजे टोपी: trust policy सांगते ती कोण घालू शकतो, permission policy सांगते ती काय करू शकते, आणि STS वेळेचा pass देतो.
⚙️ कसे
ci-robot ला ci-deployer घालता येते पण dipika ला नाही; session ला 1 तासासाठी ASIA… keys मिळतात, आणि ecr:PutImage ला ALLOW.
🎯 का
तात्पुरती credentials आपोआप संपतात, CloudTrail मध्ये session चे नाव घेऊन जातात, आणि session policy त्यांना फक्त कमी करू शकते.
🚀 पुढे
पुढचा धडा साठवलेल्या key शिवाय robots ना टोपी देतो: GitHub OIDC, EC2, Lambda आणि EKS roles.
🧪 Try it here — ci-deployer टोपी घालायला मागा, मग तिकीट वापरा — ते संपण्याआधी आणि नंतर
robots ना बिल्ले मिळतात, कधीच keys नाहीत — instance profiles, Lambda roles, GitHub OIDC, EKS Pod Identity.
🧒 सोप्या शब्दांत
शाळेचा delivery robot शहराच्या दुसऱ्या टोकावरच्या company कडून येतो. त्याला चावीची प्रत देण्याऐवजी company प्रत्येक फेरीसाठी सही केलेले पत्र देते: 'main मार्गावरचा robot, आज'. कार्यालय सही आणि मार्ग तपासते, मग एका तासासाठी टोपी देते. दुसऱ्या मार्गाचे किंवा दुसऱ्या company चे पत्र असेल तर काहीच मिळत नाही.
📖 नवे शब्दOIDC token — job कोणत्या repo आणि branch वर चालतो ते सांगणारे GitHub चे सही केलेले पत्रsub claim — पत्रातील repo आणि branch चे नाव सांगणारी ओळ, जी trust policy तपासतेfederation — key साठवण्याऐवजी दुसऱ्या system च्या सही केलेल्या पत्रांवर विश्वास ठेवणेinstance profile — EC2 server ला role देणारा badge, म्हणजे त्याच्या code ला key लागत नाही
⏪ आधी
CI pipeline मध्ये AWS access key secret म्हणून ठेवलेली असे, जी प्रत्येक workflow आणि maintainer ला मिळू शकत असे, आणि फक्त हाताने rotate होत असे.
💡 काय
Machine identities keys नाही, badges वापरतात: सही केलेला OIDC token किंवा platform स्वतः workload ला role ची credentials देतो.
⚙️ कसे
trust-github-oidc फक्त sub repo:BaluRaut/school-app:ref:refs/heads/main स्वीकारते; feature-x branch आणि fork नाकारले जातात.
🎯 का
GitHub मध्ये किंवा image मध्ये कोणतेही secret नसते, आणि प्रत्येक run ची credentials एका तासात संपतात, फक्त एका repo आणि एका branch साठी.
🚀 पुढे
पुढचा धडा 'फक्त तेव्हाच…' जोडतो: MFA, कार्यालयाचे network आणि जुळणारे tags यांसाठी Conditions, म्हणजेच ABAC.
🧪 Try it here — STS ला GitHub OIDC token दाखवा — फक्त BaluRaut/school-app चा main deploy करू शकतो
फक्त जेव्हा… — MFA, कार्यालयाचे network, आणि जुळणारे tags: प्रत्येक team साठी एकच policy.
🧒 सोप्या शब्दांत
काही नियमांच्या शेवटी 'फक्त तेव्हाच' असते. कार्ड आणि phone वरचा code दोन्ही दाखवले तरच ओळखपत्र नोंदी बदलता येतात. Report cards फक्त शाळेच्या इमारतीतूनच उघडतात, café मधून नाही. Lab मधील computer चा sticker तुमच्या badge च्या रंगाशी जुळला तरच तो बंद करता येतो, म्हणून एकच नियम प्रत्येक team ला चालतो.
📖 नवे शब्दCondition — नियमातील 'फक्त तेव्हाच…' भाग, जो request च्या माहितीवर तपासला जातोMFA — phone वरचा code, जो password खरेच तुम्हीच वापरत आहात हे सिद्ध करतोsource IP — request ज्या network पत्त्यावरून येते तो, जसे शाळेच्या कार्यालयाचे networktag — व्यक्तीवर किंवा वस्तूवर लावलेले team=maths सारखे लेबलABAC — tags जुळवून ठरणारा access, म्हणजे एकच नियम प्रत्येक team ला चालतो
⏪ आधी
तुम्ही कोण आहात एवढेच उत्तर होते, म्हणून फक्त चोरलेल्या password ने कोणत्याही café मधून, कोणत्याही team च्या machines वर IAM बदलता येत असे.
💡 काय
Condition statement ला 'फक्त तेव्हाच…' जोडते: MFA असेल तर, ठराविक source IP मधून, किंवा resource चा tag तुमच्या tag शी जुळला तर.
⚙️ कसे
MFA शिवाय aishwarya चे iam:CreateUser IMPLICIT DENY, MFA सह ALLOW; café 198.51.100.9 मधून katrina ला DenyOutsideOffice मुळे DENY.
🎯 का
MFA धोकादायक actions चे रक्षण करते, आणि ABAC ची एकच policy प्रत्येक team ला चालते: नव्या team ला नवी policy नाही, नवा tag लागतो.
🚀 पुढे
पुढचा धडा सगळ्यांवर छत ठेवतो: permission boundaries आणि SCPs, जे admin policy सुद्धा ओलांडू शकत नाही.
🧪 Try it here — request चा संदर्भ बदला — MFA, source IP, tags — आणि तीन policies ना पुन्हा विचारा
छते, देणग्या नाहीत — permission boundaries, SCPs आणि session policies फक्त काढूनच घेतात.
🧒 सोप्या शब्दांत
नव्या lab सहाय्यकाला 'lab मध्ये काहीही करू शकतो' असे कार्ड मिळते. समन्वयक त्यावर छत ठेवतात: उपकरणे आणि नोंदवह्यांपलीकडे काहीच नाही. शाळा मंडळ प्रत्येक शाळेसाठी स्वतःचा नियम ठेवते: दोन शहरांबाहेर नवी शाखा नाही. कार्डवर अजूनही 'काहीही' लिहिलेले आहे, पण छताच्या वरचे सगळे आवाक्याबाहेरच राहते.
📖 नवे शब्दpermission boundary — एका user किंवा role वरचे छत: चिठ्ठ्या काहीही म्हणोत, तो जास्तीत जास्त एवढेच करू शकतोSCP — संपूर्ण account वरचा शाळा मंडळाचा नियम; तो फक्त कमी करू शकतो, कधीच देत नाहीguardrail — admins नासुद्धा मर्यादा घालून चुका थांबवणारा नियमeffective permissions — प्रत्येक छत लावल्यानंतर उरलेले: सगळे थर जे allow करतात तेवढेच
⏪ आधी
Admin policy म्हणजे खरोखर सगळे: developer स्वतःपेक्षा ताकदवान user बनवू शकत असे, किंवा कोणत्याही region मध्ये servers सुरू करू शकत असे.
💡 काय
Guardrails म्हणजे छत: एका identity वर permission boundary, संपूर्ण account वर SCP, आणि एका session वर session policy.
⚙️ कसे
developers boundary खाली dipika चे admin: iam:CreateUser ला IMPLICIT DENY, s3:PutObject ला ALLOW; sa-east-1 मध्ये katrina ला SCP मुळे DENY.
🎯 का
प्रत्यक्ष access = identity ∩ boundary ∩ session ∩ SCP, म्हणून admins साठीसुद्धा 'कृपया करू नका' चे 'करताच येत नाही' होते.
🚀 पुढे
पुढचा धडा दुसऱ्या account चे दार उघडतो: partner auditor, bucket policy, आणि दोन्ही बाजूंनी हो का म्हणायला हवे.
🧪 Try it here — dipika च्या developer session कडे admin आहे — कुंपणे चालू-बंद करून पहा
दोन शाळा, दोन दरवाजे — बोलावणाऱ्याचे account आणि resource ची policy, दोघांनीही हो म्हणायला हवे.
🧒 सोप्या शब्दांत
Partner शाळेच्या auditor ला तुमचे report cards वाचायचे आहेत. तिच्या स्वतःच्या शाळेने ती इतर शाळांचे reports वाचू शकते असे म्हणायला हवे, आणि तुमच्या शाळेने reports च्या कपाटावर तिचे नाव असलेली चिठ्ठी लावायला हवी. दोन दारे, दोन चाव्या: एकाच बाजूने हो म्हटले तर ती बाहेरच राहते. एकाच शाळेत, शिक्षकाचे नाव असलेली चिठ्ठी पुरेशी असते.
📖 नवे शब्दresource policy — वस्तूवरच लावलेली चिठ्ठी, जी ती कोण वापरू शकतो ते सांगतेbucket policy — S3 bucket वरची resource policy, जशी reports च्या कपाटावरची चिठ्ठीcross-account — एका AWS account मधील caller दुसऱ्या account च्या वस्तूचा वापर करतोPrincipal — resource policy मधील field, जे चिठ्ठी कोणासाठी आहे ते सांगते
⏪ आधी
Partner सोबत reports वाटायचे म्हणजे बाहेरच्यांसाठी users आणि keys बनवणे, किंवा bucket खूपच जास्त उघडे करणे.
💡 काय
Resource policy त्या वस्तूवरच असते आणि Principal चे नाव घेते; accounts ओलांडताना caller ची बाजू आणि resource दोघांनी allow करायला हवे.
⚙️ कसे
444455556666 मधला role/partner-auditor term1.pdf तेव्हाच वाचू शकतो जेव्हा त्याची identity policy आणि PartnerAuditorReads दोन्ही allow करतात.
🎯 का
Accounts credentials न देता share करतात, आणि Principal '*' असलेली bucket policy public-data गळती म्हणून लगेच दिसते.
🚀 पुढे
पुढचा धडा लोकांना मोठ्या प्रमाणावर हाताळतो: IAM Identity Center चे एक sign-in, permission sets, आणि प्रत्येक दिलेल्या account मध्ये role.
🧪 Try it here — भागीदार auditor (444455556666) शाळेचा bucket (111122223333) वाचतो — प्रत्येक दार उघडा किंवा बंद करा
प्रत्येक account साठी एकच login — IAM Identity Center, groups, permission sets; सोडून जाणाऱ्याला एकदाच बंद केले जाते.
🧒 सोप्या शब्दांत
शाळा समूह आता अनेक शाळा चालवतो. प्रत्येक शाळेत वेगळे कार्ड देण्याऐवजी शिक्षक एकाच front desk वर एकदाच sign in करतात. Desk ला कर्मचारी याद्या आणि कोणत्या यादीला कोणत्या शाळेत कोणती टोपी मिळते हे माहीत असते. शिक्षिका सोडून गेली की desk तिचे नाव एकदाच खोडते, आणि प्रत्येक शाळेचे दार तिच्यासाठी उघडणे बंद होते.
📖 नवे शब्दIAM Identity Center — एकच front desk, जिथे लोक एकदा sign in करून अनेक AWS accounts पर्यंत पोहोचतातpermission set — Teachers सारखा टोपीचा नमुना, जो प्रत्येक निवडलेल्या account मध्ये role बनतोSSO — single sign-on: अनेक दारे उघडणारे एकच loginaccount assignment — कोणत्या यादीला कोणत्या account मध्ये कोणती टोपी मिळते ते सांगणारा तक्ता
⏪ आधी
प्रत्येक व्यक्तीचा प्रत्येक account मध्ये IAM user होता, म्हणून कोणी सोडून गेले की दहा ठिकाणी passwords आणि keys शोधाव्या लागत.
💡 काय
IAM Identity Center म्हणजे एकच front desk: groups ना permission sets मिळतात, जे प्रत्येक account मध्ये AWSReservedSSO roles बनतात.
⚙️ कसे
teachers-group ला 111122223333 मध्ये Teachers, it-group ला दोन्हीकडे Admins; SSO ने aishwarya report वाचू शकते पण EC2 terminate करू शकत नाही.
🎯 का
लोकांना keys ऐवजी अल्पकाळाचे role sessions मिळतात, आणि directory मधून एकदा काढले की सगळीकडून access जातो.
🚀 पुढे
पुढचा धडा विचारतो, लोकांकडे जास्त तर नाही ना: दिलेले आणि वापरलेले यांची तुलना करा, आणि पुराव्यासह कमी करा.
🧪 Try it here — Identity Center मधून sign in करा, एक account निवडा आणि काहीतरी करून पहा
दिलेले विरुद्ध वापरलेले — कोणी न वापरलेले शोधा, अरुंद policy तयार करा, Access Analyzer ने ती अरुंदच ठेवा.
🧒 सोप्या शब्दांत
शिक्षकांच्या कार्डवर एकदा 'प्रत्येक खोली: ग्रंथालय, lab, स्वयंपाकघर, boiler खोली' लिहिले होते, कारण ते पटकन होते. तीन महिन्यांनी भेट नोंदवही दाखवते की boiler खोलीत कोणीच गेले नाही. म्हणून कार्यालय नोंदवहीत दिसते तेवढेच कार्डवर ठेवते, आणि मग प्रत्येक शिक्षक खरे काम अजूनही करू शकतो का ते तपासते.
📖 नवे शब्दleast privilege — कामाला लागते तेवढेच देणे, जास्त काहीच नाहीlast accessed — प्रत्येक परवानगी खरोखर केव्हा वापरली गेली त्याची नोंदwildcard — 'इथे काहीही' म्हणणारा *, जसे प्रत्येक S3 action साठी s3:*Access Analyzer — न वापरलेला access शोधणारे आणि खऱ्या वापरावरून अरुंद policies बनवणारे AWS tool
⏪ आधी
'लवकर व्हावे' म्हणून policies नी s3:*, ec2:* आणि dynamodb:* दिले, आणि काम बिघडेल या भीतीने कोणीच काही काढायला धजावले नाही.
💡 काय
Least privilege म्हणजे कामाला लागतील तेवढ्याच actions, resources आणि conditions, खऱ्या वापरावरून मोजून कमी केलेल्या.
⚙️ कसे
90 दिवसांचा data 4 actions वापरलेल्या आणि dynamodb:* कधीच नाही असे दाखवतो; नवी policy s3:GetObject ला ALLOW, dynamodb:DeleteTable ला नकार.
🎯 का
न वापरलेली परवानगी चोरलेली credentials असलेल्या attacker शिवाय कोणालाच मदत करत नाही, आणि पुराव्यामुळे कमी करणे सुरक्षित होते.
🚀 पुढे
Access Analyzer CI मध्ये ते अरुंदच ठेवतो; पुढचा धडा नोंदवही वाचतो आणि key फुटल्यानंतरचा पहिला तास हाताळतो.
🧪 Try it here — teachers role: काय दिले, काय वापरले, आणि अरुंद केलेली चिठ्ठी
कार्यालयाची नोंदवही — credential reports, CloudTrail, आणि key फुटल्यावरच्या पाच पायऱ्या.
🧒 सोप्या शब्दांत
दर शुक्रवारी कार्यालय स्वतःच्या नोंदी वाचते: कोणाकडे जास्तीची key आहे, ती किती जुनी आहे, कोणाला दुसरे कुलूप नाही. एका रात्री नोंदवही दाखवते की Katrina ची key रात्री 2 वाजता दुसऱ्या शहरातून वापरली गेली, ती कधीच न जाणाऱ्या खोल्या उघडायचा प्रयत्न करत. कार्यालय key बंद करते, आधीच दिलेले passes रद्द करते, काय हाताळले गेले ते तपासते, नवी key देते आणि ती कशी फुटली ते शोधते.
📖 नवे शब्दcredential report — प्रत्येक user चा password, MFA आणि key ची स्थिती दाखवणारी यादी, auditor सारखी वाचायचीaccess key — program requests वर सही करण्यासाठी वापरतो ते दीर्घकाळाचे secret; ते AKIA ने सुरू होतेCloudTrail — प्रत्येक request ची नोंदवही, जिथे चोरलेली key दिसून येतेGuardDuty — विचित्र patterns ओळखणारा AWS alarm, जसे रात्री नव्या देशातून वापरलेली keyrunbook — काही चुकले तर क्रमाने पाळायच्या लिखित पायऱ्या
⏪ आधी
जुन्या keys आणि नसलेले MFA कोणाच्या लक्षात येत नसत, आणि कोणी नोंदवही वाचेपर्यंत चोरलेली key तासन्तास चाचपणी करू शकत असे.
💡 काय
Audit म्हणजे credential report आणि CloudTrail वाचणे; incident response म्हणजे फुटलेल्या key साठी सराव केलेला runbook.
⚙️ कसे
katrina ची AKIAEXAMPLEKATRINA01 02:03 ला 198.51.100.77 मधून दिसते: आधी GetCallerIdentity, मग RunInstances आणि CreateUser, दोन्ही नाकारलेले.
🎯 का
जलद आणि क्रमाने केलेल्या पायऱ्यांमुळे घाबरवणारा प्रसंग फक्त एक नोंद ठरतो: deactivate, sessions revoke, त्याने काय बनवले ते शोधा, rotate, गळती कुठून ते शोधा.
🚀 पुढे
Production मध्ये GuardDuty असे patterns पकडतो, आणि roles, OIDC व SSO मुळे फुटायला दीर्घकाळाची key उरतच नाही.
🧪 Try it here — auditor बना: credential-report ची एक ओळ वाचा, CloudTrail तपासा, runbook चालवा