← कोर्सच्या मुख्य पानाकडे परत

📐 12 धडे आकृत्यांमध्ये

भाग 1: ओळखपत्र कार्यालय (जांभळा, 1–6) · भाग 2: ते सुरक्षितपणे चालवणे (लाल, 7–12). प्रत्येक आकृती खऱ्या lab वरून काढली आहे — iam/demo.py छापत असलेले users, policies, निर्णय आणि log ओळी — आणि प्रत्येकीखाली एक lab आहे जिथे निर्णय तुम्ही स्वतः घेता. वर्तुळातील क्रमांकांनुसार जा 1 → 2 → 3.

1 🪪 IAM का

शाळेचे ओळखपत्र कार्यालय — प्रत्येक request वर सही असते, ती तपासली जाते आणि लिहून ठेवली जाते; कोणी हो म्हणेपर्यंत काहीच परवानगी नाही.

🧒 सोप्या शब्दांत

शाळेत फक्त हसून ग्रंथालयात किंवा प्रयोगशाळेत जाता येत नाही. दार ओळखपत्र कार्यालयाला विचारते: तू कोण, तुला काय करायचे, कोणती खोली? कार्यालय प्रत्येक उत्तर 'नाही' पासून सुरू करते, लिखित नियम परवानगी देत असेल तरच 'हो' म्हणते, आणि प्रत्येक प्रश्न नोंदवहीत लिहिते. AWS मध्ये प्रत्येक request साठी IAM हेच कार्यालय आहे.

📖 नवे शब्दIAM — प्रत्येक AWS request साठी कोण विचारतोय आणि त्याला परवानगी आहे का ते तपासणारे ओळखपत्र कार्यालयauthentication — तुम्ही कोण आहात ते सिद्ध करणे, जसे स्वतःचे ओळखपत्र दाखवणेauthorization — लिखित नियम वाचून ती व्यक्ती ही गोष्ट करू शकते का ते ठरवणेimplicit deny — मूळ उत्तर: कोणत्याही नियमाने हो म्हटले नाही, म्हणून उत्तर नाहीCloudTrail — प्रत्येक request लिहून ठेवणारी नोंदवही: कोण, काय, कशावर आणि कधी
1✉️ प्रत्येक request ही सही केलेली चिठ्ठी — कोण · काय · कोणते — आणि ओळखपत्र कार्यालय निर्णय घेते🪪 IAM USERaishwaryaarn:aws:iam::111122223333:user/aishwaryaaishwarya "download term1.pdf" वर click करते(console, CLI किंवा SDK — तीच request)WHO arn:aws:iam::111122223333:user/aishwaryaWHAT s3:GetObjectWHICH arn:aws:s3:::school-reports/term1.pdfWHEN 2026-09-27T08:15:00Z🔏 SigV4 signature 9f2c…e41arequest ची चिठ्ठी🏢 ओळखपत्र कार्यालय — IAM1authentication — ही खरंच aishwarya आहे का?सही aishwarya च्या key शी जुळते ✓2authorization — aishwarya ला हे करण्याची परवानगी आहे का?तिच्या कार्डवरची प्रत्येक policy वाचतो … अजून एकही नाहीIMPLICIT DENYकोणतीही policy परवानगी देत नाही — AWS मूळ नियमाने नाकारतो🧾 → CloudTrailएक ओळ, खालीauthentication = तुम्ही कोण आहात (password + MFA, key, token)authorization = तुम्ही काय करू शकता (policies)दोन वेगळे प्रश्न — IAM प्रत्येक call वर दोन्हींची उत्तरे देतो🧪 python3 iam/demo.py why → "aishwarya, no policies yet → s3:GetObject IMPLICIT DENY"2🗝️ root — मास्टर चावी, तिजोरीत बंद731204root = account चा sign-up emailकोणतीही policy तपासत नाही — तोसगळे काही करू शकतो, account बंदसुद्धा✓ MFA चालू ✓ access keys नाहीत✓ प्रत्येक root sign-in वर alarm✓ वर्षातून मोजक्याच वेळा वापर3🚪 मूळ नियम deny — प्रत्येक दरवाजा सुरुवातीला बंदकोणीच हो म्हणत नाही🚫 IMPLICIT DENYएखादे Allow request शी जुळते✅ ALLOWस्पष्ट Deny जुळते — प्रत्येक Allow वर भारी⛔ DENYओळखपत्र कार्यालयNO पासून सुरू होतेआणि हो म्हणायलात्याला कारण लागतेहो4🧾 CloudTrail — प्रत्येक request ची एक ओळ: कोण · काय · कुठून · कधी (iam/data/cloudtrail.json)eventTimeuserIdentityaccessKeyeventNameawsRegionsourceIPAddresserrorCode2026-09-26T09:12:04ZkatrinaAKIAEXAMPLEKATRINA01GetObjectap-south-1203.0.113.40—2026-09-26T09:40:11ZkatrinaAKIAEXAMPLEKATRINA01ListBucketsap-south-1203.0.113.40—2026-09-27T08:15:00ZaishwaryaASIAEXAMPLEAISHWAR01GetObjectap-south-1203.0.113.12—प्रत्येक call वर नाव असते — धडा 12 या ओळी वाचून रात्री 02:03 ला चोरलेली key पकडतो
⏪ आधी

ओळखपत्र कार्यालयाशिवाय 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 पाठवा — कोण विचारतोय, काय, कोणत्या गोष्टीवर

संपूर्ण धडा 01 वाचा →

2 👥 Users, groups & root

कार्डे यादीत सामील होतात — परवानग्या group ला जोडल्या जातात, लोक येतात आणि जातात; मास्टर चावी तिजोरीतच राहते.

🧒 सोप्या शब्दांत

नवीन शिक्षिका आली की कार्यालय तिच्या कार्डवर प्रत्येक परवानगी असलेली खोली लिहीत नाही. तिला teachers यादीत टाकते, आणि नियम त्या यादीला लावलेले असतात. Dipika यादीत नव्हती, म्हणून reports च्या कपाटाने नाही म्हटले; ती सामील होताच हो म्हटले. सगळे उघडणारी मास्टर चावी दुसऱ्या कुलुपासह तिजोरीतच राहते.

📖 नवे शब्दIAM user — एका व्यक्तीचे स्वतःचे कार्ड, password सह आणि कदाचित access key सहgroup — users ची नाव असलेली यादी, जसे teachers; तिला लावलेले नियम यादीतील सगळ्यांना लागू होतातroot user — account बनवताना तयार झालेली मास्टर चावी; ती सगळे करू शकते, म्हणून ती बंद करून ठेवाMFA — दुसरे कुलूप: password सोबत phone वरचा code
1👥 कार्डे यादीत सामील होतात — policies यादीला लटकतात, व्यक्तीला कधीच नाही🪪 IAM USERaishwaryaarn:aws:iam::111122223333:user/aishwarya🪪 IAM USERkatrinaarn:aws:iam::111122223333:user/katrina🪪 IAM USERdipikaarn:aws:iam::111122223333:user/dipika👥 group: शिक्षक (teachers)aishwaryakatrinadipika त्यात नाहीअजूनarn:…:group/teachers📝 read-reportsAllow s3:GetObject s3:ListBucketschool-reports वर school-reports/*📝 own-homework-folderAllow s3:GetObject s3:PutObjectschool-homework/ वर ${aws:username}/*GROUP ला जोडले — एकदाचGetObject term1.pdfaishwarya (teachers)✅ ALLOWkatrina (teachers)✅ ALLOWdipika (एकही group नाही)🚫 IMPLICIT DENYdipika teachers मध्ये सामील होते✅ ALLOW2🗝️ root विरुद्ध 🪪 IAM user🗝️ ROOTroot usersign-up email🪪 IAM USERaishwaryaarn:aws:iam::111122223333:user/aishwarya🗝️ root🪪 IAM userpolicies ने मर्यादित?नाही — कधीच नाहीहो — Allow शिवाय काहीच नाहीहा कोण आहे?account चा मालकएक नावाची व्यक्तीरोजचे काम?कधीच नाहीहो (किंवा SSO, धडा 10)MFA?आवश्यकआवश्यक3🔐 user कडे असू शकणारी दोन प्रकारची credentialsconsolepassword ••••••••+492817MFA codeदर 30 सेकंदांनीबदलतोचोरलेला पासवर्ड एकटा काहीच उघडत नाहीCLI · SDKAccessKeyId AKIAEXAMPLEKATRINA01SecretAccessKey wJalr••••••••••••••••AKIA… = दीर्घकाळ टिकणारी user keyASIA… = तात्पुरती (roles, L5)⚠️ katrina ची key शेवटची 329 दिवसांपूर्वी बदलली — धडा 12 ती शोधतोलोकांनी SSO ने sign in करावे (L10), machines नी roles वापरावे (L6)4⌨️ सामील होणे आणि सोडणे एका ओळीचे काम — policies कधीच बदलत नाहीत$ aws iam attach-group-policy --group-name teachers --policy-arn arn:aws:iam::111122223333:policy/read-reports$ aws iam add-user-to-group --group-name teachers --user-name dipika$ aws iam remove-user-from-group --group-name teachers --user-name dipika50 शिक्षक × प्रत्येकी 2 चिठ्ठ्या = 100चुकण्याच्या गोष्टी · 1 group × 2चिठ्ठ्या = 2 · नवा शिक्षक = एक ओळ
⏪ आधी

प्रत्येकाच्या कार्डवर लिहिलेले नियम भरकटतात: शिक्षक काम बदलतो पण जुने अधिकार ठेवतो, सोडून गेलेल्याकडे चालू 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 यादीत कोण आहे ते निवडा, मग ओळखपत्र कार्यालयाला सगळ्यांसाठी एकदम विचारा

संपूर्ण धडा 02 वाचा →

3 📝 Policies

परवानगी चिठ्ठी — 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} — चिठ्ठीवरची रिकामी जागा, जी विचारणाऱ्याच्या स्वतःच्या नावाने भरते
1📝 परवानगी चिठ्ठी — एक statement, चार fields{ "Sid": "OwnFolderOnly", "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::school-homework/${aws:username}/*"}iam/policies/own-homework-folder.json"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}… एक Condition, iam-needs-mfa.json मधून (धडा 7)1EffectAllow किंवा Deny — ही चिठ्ठी देणारा निकाल2Actionक्रियापद: service:Operation — s3:PutObject3Resourceकोणती गोष्ट, ARN स्वरूपात — wildcards चालतात4Conditionऐच्छिक: फक्त जेव्हा … MFA, IP, tag, वेळ2🔖 ARN — एका गोष्टीचा संपूर्ण पोस्टाचा पत्ताprefixpartitionसेवाregionखातेresourcearnawss3school-homework/aishwarya/essay.txtarnawsiam111122223333user/aishwaryaarnawsec2ap-south-1111122223333instance/i-0abcarn:aws:s3:::school-homework/aishwarya/essay.txtarn:aws:iam::111122223333:user/aishwaryaarn:aws:ec2:ap-south-1:111122223333:instance/i-0abcS3 आणि IAM global आहेत → रिकामे fields, colons तसेच ठेवतात3✳️ wildcards — * कितीही अक्षरे, ? एक अक्षरpatternविनंतीs3:*s3:PutObjects3:Get*s3:GetObjects3:Get*s3:PutObjectec2:Describe*ec2:DescribeInstancesschool-reports/*school-reports/term1.pdfschool-reports/*school-reports (bucket स्वतः)s3:ListBucket हे BUCKET वर चालते, s3:GetObject त्यातील objects वर —म्हणूनच read-reports मध्ये school-reports आणि school-reports/* दोन्ही आहेत4🙋 ${aws:username} — एक चिठ्ठी, प्रत्येकाला खाजगी folderschool-homework/${aws:username}/*प्रत्येक बोलावणाऱ्यासाठी भरले जाते: aishwaryaschool-homework/aishwarya/*🪣 school-homeworkaishwarya/katrina/dipika/प्रत्येक शिक्षकाला एक folderaishwarya school-homework/aishwarya/essay.txt ठेवते✅ ALLOWOwnFolderOnly जुळतेaishwarya school-homework/katrina/essay.txt ठेवते🚫 IMPLICIT DENYaishwarya साठी katrina/ शी कोणतीही चिठ्ठी जुळत नाहीएक policy, एकदाच जोडलेली, प्रत्येक शिक्षकासाठी बरोबर — नवा शिक्षक, शून्य बदल
⏪ आधी

नेमक्या चिठ्ठ्यांशिवाय 'शिक्षक 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} भरताना पाहा

संपूर्ण धडा 03 वाचा →

4 ⚖️ AWS कसा निर्णय घेतो

नियमपुस्तकाचा क्रम — मूळ नियम deny, एक Allow दरवाजा उघडतो, एक स्पष्ट Deny तो धाडकन बंद करतो, बाकी कोणीही हो म्हणो.

🧒 सोप्या शब्दांत

Katrina कडे 'सगळे करू शकते' अशी चिठ्ठी आहे. मग मुख्याध्यापक दुसरी चिठ्ठी लावतात: 'report cards कधीच फेकायचे नाहीत'. Katrina एखादे फेकायला जाते तेव्हा कारकून आधी कोणतीही 'कधीच नाही' चिठ्ठी शोधतो आणि तिथेच थांबतो. ती reports अजूनही वाचू शकते, कारण 'कधीच नाही' चिठ्ठी फक्त फेकण्याबद्दल बोलते.

📖 नवे शब्दexplicit Deny — नाही, कधीच नाही म्हणणारी चिठ्ठी; कोणत्याही क्रमात ती प्रत्येक हो वर मात करतेAllow — हो म्हणणारी चिठ्ठी; कोणताही Deny जुळत नसेल तरच ती दार उघडतेimplicit deny — कोणत्याही चिठ्ठीने हो म्हटले नाही, म्हणून दार आपोआप बंदच राहतेPolicy Simulator — खरी policy काय निर्णय देईल ते तपासण्याचे AWS चे स्वतःचे tool
1⚖️ सहा तपासण्या, क्रमाने — जी पहिली उत्तर देते ती request संपवतेkatrinas3:DeleteObjectschool-reports/term1.pdf✉️ सही केलेली request येते1कुठेही स्पष्ट Deny?SCP · resource · boundary · session · identityहो⛔ DENYकाहीच त्याला मागे टाकत नाहीनाही2SCPs परवानगी देतात?फक्त account Organization मध्ये असेल तरनाही🚫 IMPLICIT DENYorg चे guardrail नाही म्हणतेहो / लागू नाही3resource policy मध्ये बोलावणाऱ्याचे नाव आहे?त्याच account चा user: फक्त एवढेच पुरेसेहो✅ ALLOWउदा. bucket policyनाही4permission boundary परवानगी देते?फक्त boundary लावली असेल तरनाही🚫 IMPLICIT DENYएक छत, कधीच देणगी नाहीहो / लागू नाही5session policy परवानगी देते?फक्त ज्या role sessions ना ती दिली त्यांच्यासाठीनाही🚫 IMPLICIT DENYAssumeRole वेळी अरुंद केलेलीहो / लागू नाही6identity policy परवानगी देते?user · group · role policiesहो✅ ALLOWरोजचा मार्गनाही🚫 IMPLICIT DENY — मूळ नियमकोणतीही policy परवानगी देत नाही — AWS मूळ नियमाने नाकारतोतीन संभाव्य उत्तरे✅ ALLOWएक Allow, Deny नाही⛔ DENYएक Deny statement लागले🚫 IMPLICIT DENYकोणीच हो म्हटले नाहीदोन्ही denies अडवतात — फक्त शब्द वेगळे🌉 cross-account (धडा 9):बोलावणाऱ्याच्या स्वतःच्या account ने परवानगी द्यायला हवी(तपासण्या 2, 4–6) आणि resourcepolicy ने परवानगी द्यायला हवी — दोन्ही दरवाजे.🗝️ root इथे कधीच तपासला जात नाही.2🧪 katrina कडे दोन चिठ्ठ्या: admin (सगळ्याला Allow) + deny-delete-reports📝 admin.json"Sid": "Everything","Effect": "Allow","Action": "*","Resource": "*"📝 deny-delete-reports.json"Sid": "NeverDeleteReports","Effect": "Deny","Action": "s3:DeleteObject","Resource": "…school-reports/*"कोण · चिठ्ठ्याterm1.pdf वरची कृतीkatrina · फक्त admins3:DeleteObjectkatrina · admin + deny-deletes3:DeleteObjectkatrina · admin + deny-deletes3:GetObjectdipika · काहीच जोडलेले नाहीs3:GetObjectउत्तर — कारण (iam/demo.py decide मधून)✅ ALLOWidentity policy admin#Everything परवानगी देते⛔ DENYस्पष्ट Deny … #NeverDeleteReports — काहीच त्याला मागे टाकत नाही✅ ALLOWidentity policy admin#Everything परवानगी देते🚫 IMPLICIT DENYकोणतीही policy परवानगी देत नाही — AWS मूळ नियमाने नाकारतो
⏪ आधी

ठरलेल्या क्रमाशिवाय 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 निवडा — सहापैकी कोणती तपासणी उत्तर देते ते पाहा

संपूर्ण धडा 04 वाचा →

5 🎩 Roles & STS

उसनी घेतलेली टोपी — trust policy सांगते कोण ती घालू शकतो, permissions सांगतात ती काय करू शकते, पास संपतो.

🧒 सोप्या शब्दांत

परीक्षा हॉल फक्त पर्यवेक्षकाची टोपी घातलेल्यासाठीच उघडतो. टोपी कोणाच्याच मालकीची नाही: तुम्ही कार्यालयाला विचारता, ते टोपीच्या लेबलवरील नावे तपासते, आणि एका तासासाठी देते. CI robot लेबलवर आहे; Dipika नाही. टोपीवरचा sticker 'आज फक्त पाहा' सांगू शकतो, जो परवानग्या कमी करतो पण कधीच वाढवत नाही.

📖 नवे शब्दrole — परवानगी असलेला कोणीही काही वेळ घालू शकेल अशी टोपी; तिला password किंवा कायमची key नसतेtrust policy — टोपीवरचे लेबल, जे ती कोण घालू शकतो ते सांगतेSTS — टोपी देणारी आणि ठराविक वेळेत, बहुधा एका तासात, संपणारा pass देणारी खिडकीsession policy — एका session साठी लावलेला sticker, जो फक्त परवानग्या कमी करू शकतो
1🎩 role म्हणजे दोन लेबलांची टोपी — कोण ती घालू शकतो · ती काय करू शकते🎩 role/ci-deployerarn:aws:iam::111122223333:role/ci-deployerpassword नाही, स्वतःची key नाही🤝 trust policy — कोण ती घालू शकतो"Effect": "Allow","Principal": {"AWS": "arn:aws:iam::111122223333:user/ci-robot"},"Action": "sts:AssumeRole"ci-robot ती घालायला मागतो✅ trust policy परवानगी देतेdipika ती घालायला मागते🚫 trust policy नाकारते📝 permission policy ci-deploy — काय"Sid": "PushImages", "Effect": "Allow","Action": [ "ecr:PutImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload", "ecr:BatchCheckLayerAvailability", "ecr:GetAuthorizationToken"],"Resource": "*"इतर कोणत्याही policy प्रमाणे role ला जोडलेली2🎟️ sts:AssumeRole — टोपी उसनी घ्या, संपणारे तिकीट मिळवा🤖 ci-robot☁️ AWS STS🗄️ ECR school-apists:AssumeRole role/ci-deployer session build-42trust: ci-robot ✓तात्पुरती credentialsAccessKeyId ASIAEXAMPLECIDEPLOYSessionToken IQoJb3JpZ2luX2Vj…Expiration +1 तासecr:PutImage as arn:aws:sts::111122223333:assumed-role/ci-deployer/build-42✅ ALLOW — identity policy ci-deploy#PushImages परवानगी देतेASIA… = तात्पुरती key — तिच्यासोबतsession token आणि संपण्याची वेळ येतेCloudTrail टोपी आणि session दोन्हींचे नाव लिहितो:assumed-role/ci-deployer/build-42एक तासनंतर:ExpiredToken3✂️ session policy एका session ला अरुंद करते — कधीच रुंद करू शकत नाही🎩 टोपी (ci-deploy)ecr: …PutImageInitiateLayerUploadUploadLayerPartCompleteLayerUploadBatchCheckLayerAvailabilityGetAuthorizationToken✂️ session-read-onlyAssumeRole वेळी दिलेलीBatchCheckLayerAvailabilityGetAuthorizationToken🎟️ या session ला मिळतेदोन्हींमधला सामायिक भागPutImageInitiateLayerUploadUploadLayerPartCompleteLayerUploadBatchCheckLayerAvailabilityGetAuthorizationTokenत्याच session ने ecr:PutImage बोलावले →🚫 IMPLICIT DENYAssumeRole ला दिलेल्या session policy च्या बाहेर
⏪ आधी

दीर्घकाळ चालणारी 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 टोपी घालायला मागा, मग तिकीट वापरा — ते संपण्याआधी आणि नंतर

संपूर्ण धडा 05 वाचा →

6 🤖 Machine identities

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 लागत नाही
1🐙 साठवलेल्या key शिवाय GitHub Actions → AWS — job कुठे चालतो ते token सिद्ध करतोGitHub Actionsmain वरचा jobpermissions: id-token: write- uses: aws-actions/ configure-aws-credentials🔏 OIDC token (JWT) — GitHub ने सही केलेलाiss: token.actions.githubusercontent.comaud: sts.amazonaws.comsub: repo:BaluRaut/school-app: ref:refs/heads/main☁️ AWS STSAssumeRoleWithWebIdentity🤝 trust-github-oidc.json"Federated": …oidc-provider/ token.actions.githubuser…"StringEquals": aud = sts.amazonaws.com"StringLike": sub = repo:BaluRaut/school-app :ref:refs/heads/mainSTS सही तपासतो, मग प्रत्येक claim role च्या trust policy शी पडताळतोtoken चा sub claimSTS काय करतोrepo:BaluRaut/school-app:ref:refs/heads/main✅ role मिळाला, 1 तासाची credentialsrepo:BaluRaut/school-app:ref:refs/heads/feature-x🚫 नाकारलेfeature-x ≠ mainrepo:someone/fork:ref:refs/heads/main🚫 नाकारलेsomeone/fork ≠ BaluRaut/school-app2🖥️ EC2 — instance profile3λ Lambda — execution role4☸️ EKS — IRSA / Pod Identityi-0abcrole: school-web169.254.169.254metadata सेवा$ curl …/iam/security-credentials/ school-web"AccessKeyId": "ASIA…","Token": "IQoJ…","Expiration": "…T14:05:00Z"SDK तुमच्यासाठी विचारतो, आणिcredentials संपण्याआधी नवी आणतोλ report-mailerexecution roleसुरुवातीला घेतला जातो# environment inside the functionAWS_ACCESS_KEY_ID=ASIA…AWS_SECRET_ACCESS_KEY=…AWS_SESSION_TOKEN=IQoJ…AWS_REGION=ap-south-1Lambda role ची तात्पुरतीcredentials environment मध्ये ठेवतो🪑 podschool-apiServiceAccountschool-apieks.amazonaws.com/role-arn: arn:aws:iam::111122223333: role/school-apiIRSA — annotation + cluster OIDCPod Identity — association, annotation नाहीकोणत्याही मार्गाने pod ला स्वतःचा role मिळतो —node चा नाही5🔑 काय नाहीसे होते: साठवलेली key# .env (committed by mistake)AWS_ACCESS_KEY_ID=AKIA…AWS_SECRET_ACCESS_KEY=wJalr…platform त्याऐवजी बिल्ला देतो🔑 साठवलेली key🎩 role credentialsकुठे राहतेrotationकुठून फुटू शकतेकोणी delete करेपर्यंतमिनिटे ते तासहाताने, कधी केलेच तरआपोआपgit, laptops, CI logsफुटायला काहीच साठवलेले नाही
⏪ आधी

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 करू शकतो

संपूर्ण धडा 06 वाचा →

7 🏷️ Conditions & ABAC

फक्त जेव्हा… — 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 ला चालतो
1📱 MFA — code नाही, तर IAM बदल नाहीत"Sid": "IamOnlyWithMfa","Effect": "Allow", "Action": "iam:*","Condition": {"Bool": { "aws:MultiFactorAuthPresent": "true"}}iam-needs-mfa.jsonaishwarya✗aishwarya → iam:CreateUseraws:MultiFactorAuthPresent = false🚫 IMPLICIT DENYCondition अयशस्वी — Allow नाहीaishwarya492817aishwarya → iam:CreateUseraws:MultiFactorAuthPresent = true✅ ALLOWIamOnlyWithMfa परवानगी देतेpassword ने कोण ते सिद्ध केले; फोन सिद्ध करतो की ती खरंच तीच व्यक्ती आहे2🌐 source IP — कार्यालय विरुद्ध café"Sid": "DenyOutsideOffice","Effect": "Deny", "Action": "*", "Resource": "*","Condition": {"NotIpAddress": {"aws:SourceIp": "203.0.113.0/24"}}office-network-only.json + read-reports.json🏫कार्यालय 203.0.113.0/24katrina 203.0.113.40 वरून → GetObjectrange च्या आत✅ ALLOWread-reports#ReadReports परवानगी देतो☕कॅफेचे wifikatrina 198.51.100.9 वरून → GetObject203.0.113.0/24 मध्ये नाही⛔ DENYDenyOutsideOffice — त्याला काहीही डावलू शकत नाहीअटीसह Deny: Allow तरीही कुठूनतरी यावाच लागतो3🏷️ ABAC — tags ठरवतात, म्हणून एकच चिठ्ठी प्रत्येक टीमला पुरते🪪 IAM USERaishwaryateam=mathsarn:aws:iam::111122223333:user/aishwaryaaws:PrincipalTag/team = maths"Sid": "StartStopOwnTeam","Action": ["ec2:StartInstances", "ec2:StopInstances"],"Condition": {"StringEquals": { "aws:ResourceTag/team": "${aws:PrincipalTag/team}"}}abac-own-team.json${aws:PrincipalTag/team} → "maths" (aishwarya च्या कार्डावरून वाचले)🪪 पुढील सत्रनवा कर्मचारीteam=physics← फक्त एक tagनवी टीम? लोकांना आणिinstances ना tag लावा — नवी policy नकोaishwarya → ec2:StopInstancesi-0abcap-south-1team=maths✅ ALLOWmaths = mathsaishwarya → ec2:StopInstancesi-0defap-south-1team=science🚫 IMPLICIT DENYscience ≠ maths — Allow नाहीABAC = गुणधर्मांवर आधारित: विचारणाऱ्यावर आणि वस्तूवर tags · RBAC = प्रत्येक role साठी एक policy — दोन्ही चालतात, ABAC टीम्स वाढल्या तरी पुरते
⏪ आधी

तुम्ही कोण आहात एवढेच उत्तर होते, म्हणून फक्त चोरलेल्या 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 ना पुन्हा विचारा

संपूर्ण धडा 07 वाचा →

8 🚧 संरक्षक कुंपणे (Guardrails)

छते, देणग्या नाहीत — permission boundaries, SCPs आणि session policies फक्त काढूनच घेतात.

🧒 सोप्या शब्दांत

नव्या lab सहाय्यकाला 'lab मध्ये काहीही करू शकतो' असे कार्ड मिळते. समन्वयक त्यावर छत ठेवतात: उपकरणे आणि नोंदवह्यांपलीकडे काहीच नाही. शाळा मंडळ प्रत्येक शाळेसाठी स्वतःचा नियम ठेवते: दोन शहरांबाहेर नवी शाखा नाही. कार्डवर अजूनही 'काहीही' लिहिलेले आहे, पण छताच्या वरचे सगळे आवाक्याबाहेरच राहते.

📖 नवे शब्दpermission boundary — एका user किंवा role वरचे छत: चिठ्ठ्या काहीही म्हणोत, तो जास्तीत जास्त एवढेच करू शकतोSCP — संपूर्ण account वरचा शाळा मंडळाचा नियम; तो फक्त कमी करू शकतो, कधीच देत नाहीguardrail — admins नासुद्धा मर्यादा घालून चुका थांबवणारा नियमeffective permissions — प्रत्येक छत लावल्यानंतर उरलेले: सगळे थर जे allow करतात तेवढेच
1🧺 एकावर एक चाळण्या — dipika कडे admin चिठ्ठी आहे, पण प्रत्येक थर फक्त काढून घेऊ शकतोiam:CreateUserglobal (IAM)s3:PutObjectdev-scratch/xec2:RunInstancesap-south-1ec2:RunInstancessa-east-1ec2:DescribeInstancesap-south-1🪪 ओळख: adminAllow * on *🌍 SCP: two-regionsap-south-1, us-east-1 बाहेर Denyपकडले🧱 boundary: developerss3 · logs · cloudwatch · ec2:Describe*पकडलेपकडले✂️ session policyकाहीही दिली नाही — हा थर नाही🚫 IMPLICIT DENYboundary च्या बाहेर✅ ALLOW🚫 IMPLICIT DENYboundary च्या बाहेर⛔ DENYSCP मधील स्पष्ट Deny✅ ALLOWप्रत्यक्ष = identity ∩ SCP ∩ boundary ∩ session — कुंपण कधीच परवानगी वाढवत नाहीकायमार्गे2🧱 boundary म्हणजे छत, देणगी नाहीओळख: admin* on *effective= boundary इतकेचiam:*ec2:Run…boundary-developers: s3:* · logs:* ·cloudwatch:* · ec2:Describe*फक्त boundary काहीच देत नाही:identity Allow नाही → तरीही प्रवेश नाहीdipika: admin, boundary नाही→ iam:CreateUser✅ ALLOWdipika: admin + boundary→ iam:CreateUser🚫 IMPLICIT DENYdipika: admin + boundary→ s3:PutObject✅ ALLOWटीम प्रमुखाला सुरक्षितपणेroles बनवू देतो: प्रत्येक नव्याrole ला ती लावावीच लागते3🌍 SCP — संपूर्ण accounts साठी एक नियम🏛️ organization चे root📁 OU: शाळा 🚧🏫 account111122223333🚧 OU वरील SCP फक्त हे उघडे ठेवते✓ ap-south-1✓ us-east-1✗ sa-east-1✗ eu-west-1iam:* · sts:* · organizations:*यांना सूट आहे (NotAction) — globalkatrina (admin) → ap-south-1 मध्ये ec2:RunInstances✅ ALLOWadmin#Everything परवानगी देतोkatrina (admin) → sa-east-1 मध्ये ec2:RunInstances⛔ DENYscp-two-regions#OnlyMumbaiAndVirginiaSCPs कधीच परवानगी देत नाहीत — FullAWSAccess सुद्धा जोडलेली राहिलीच पाहिजे
⏪ आधी

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 आहे — कुंपणे चालू-बंद करून पहा

संपूर्ण धडा 08 वाचा →

9 🤝 Cross-account आणि resource policies

दोन शाळा, दोन दरवाजे — बोलावणाऱ्याचे 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, जे चिठ्ठी कोणासाठी आहे ते सांगते
1🤝 दोन accounts, दोन दारे — दोन्ही उघडली पाहिजेत🏢 भागीदार account 444455556666role/partner-auditorदुसऱ्या कंपनीचा एक auditor📝 partner-auditor-identity"Sid": "ReadSchoolReports","Effect": "Allow","Action": "s3:GetObject","Resource": "arn:aws:s3:::school-reports/*"🏫 शाळेचे account 111122223333🪣 school-reportsterm1.pdf📝 bucket policy (resource policy)"Sid": "PartnerAuditorReads","Principal": {"AWS": "arn:aws:iam::444455556666: role/partner-auditor"},"Action": "s3:GetObject","Resource": "…school-reports/*"दार 1माझे स्वतःचेखातेदार 2bucket चेमालक🌐 दोन accounts मध्येauditor सही करतोभागीदार-account session नेs3:GetObjectschool-reports/term1.pdf✅ ALLOWidentity policy आणि bucket policy दोन्ही परवानगी देतात2🧪 चार प्रकरणे — python3 iam/demo.py crossaccountpartner-auditor मागतोदार 1 · identityदार 2 · bucketउत्तरकाs3:GetObject — दोन्ही बाजू परवानगी देतातउघडाउघडा✅ ALLOWidentity आणि resource policy दोन्ही परवानगी देतातs3:GetObject — फक्त bucket policyshutउघडा🚫 IMPLICIT DENYदोन्ही लागतात — विचारणाऱ्याची identity policy देत नाहीs3:GetObject — फक्त identity policyउघडाshut🚫 IMPLICIT DENYदोन्ही लागतात — resource policy देत नाहीs3:DeleteObject — दोन्ही चिठ्ठ्या वरीलप्रमाणेshutshut🚫 IMPLICIT DENYदोन्ही लागतात — कोणत्याच चिठ्ठीत DeleteObject नाही3🏠 एकाच account मध्ये: एक दार पुरू शकतेaishwaryaचिठ्ठी नाही🪣bucket policy:"Principal": {"AWS": "arn:…:user/aishwarya"}✅ ALLOWत्याच account मधील user चे नाव घेणारी resource policyएकटीच परवानगी देऊ शकते — धडा 4 मधील तपासणी 34🕵️ गोंधळलेला मध्यस्थ (confused deputy) — आणि ExternalIdएक vendorrobotशाळा: "माझा role वापर"एक अनोळखी: "111122223333 चाrole/… सुद्धा वापर"!trust policy मध्ये भर:"sts:ExternalId": "school-7f3a"(उदाहरण value)शाळेची trust policy एक गुपित मागते जे फक्तशाळेने vendor ला दिले — अनोळखी ते देऊ शकत नाही
⏪ आधी

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) वाचतो — प्रत्येक दार उघडा किंवा बंद करा

संपूर्ण धडा 09 वाचा →

10 🏢 खूप लोक सांभाळणे

प्रत्येक 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 मध्ये कोणती टोपी मिळते ते सांगणारा तक्ता
1🏢 IAM Identity Center — लोक · groups · permission sets · प्रत्येक account मधील roles👤 लोक👥 groups🧾 permission sets🏢 accounts → ते बनवत असलेले rolesaishwaryadipikakatrina👥 teachers-groupaishwaryadipikadirectory मधून👥 it-groupkatrina(उदाहरणादाखल)Teachersread-reportsAdminsadmin🏫 शाळा 111122223333🤝 भागीदार 444455556666AWSReservedSSO_Teachers_…AWSReservedSSO_Admins_…AWSReservedSSO_Admins_…role arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Teachers_…permission set हा एक साचा आहे → Identity Center प्रत्येक नेमलेल्या account मध्ये एक role बनवतो2🎫 aishwarya एकदाच sign in करते — CLI सुद्धा$ aws sso login --profile school-teachersStart URL मध्ये यशस्वीपणे login झाले: https://school.awsapps.com/start$ aws sts get-caller-identity --profile school-teachers"Arn": "arn:aws:sts::111122223333:assumed-role/ AWSReservedSSO_Teachers_1a2b/aishwarya@school.example"# short-lived — no access key on the laptopaishwarya SSO (Teachers) मार्फत → एक report वाचते✅ ALLOWread-reports#ReadReports परवानगी देतोaishwarya SSO (Teachers) मार्फत → EC2 terminate करते🚫 IMPLICIT DENYकोणतीही policy परवानगी देत नाही3🚪 सोडून जाणाऱ्याला एकदाच बंद केले जाते🪪 directory मधील वापरकर्ताdipikaसत्राच्या शेवटी सोडून जातोबंद केलेdirectory मध्ये — एक clickत्याने उघडलेले प्रत्येक दार बंद होते:portal sign-in111122223333 मधील Teachers roleनवी CLI sessions😓 जुनी पद्धत — प्रत्येक account मध्ये IAM users111122223333 मध्ये dipika शोधा, password + keys पुसा444455556666 मध्ये dipika शोधा, password + keys पुसा…आणि पुढच्या account मध्ये dipika शोधा, password + keys पुसा
⏪ आधी

प्रत्येक व्यक्तीचा प्रत्येक 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 निवडा आणि काहीतरी करून पहा

संपूर्ण धडा 10 वाचा →

11 ✂️ कमीत कमी अधिकार (Least privilege)

दिलेले विरुद्ध वापरलेले — कोणी न वापरलेले शोधा, अरुंद policy तयार करा, Access Analyzer ने ती अरुंदच ठेवा.

🧒 सोप्या शब्दांत

शिक्षकांच्या कार्डवर एकदा 'प्रत्येक खोली: ग्रंथालय, lab, स्वयंपाकघर, boiler खोली' लिहिले होते, कारण ते पटकन होते. तीन महिन्यांनी भेट नोंदवही दाखवते की boiler खोलीत कोणीच गेले नाही. म्हणून कार्यालय नोंदवहीत दिसते तेवढेच कार्डवर ठेवते, आणि मग प्रत्येक शिक्षक खरे काम अजूनही करू शकतो का ते तपासते.

📖 नवे शब्दleast privilege — कामाला लागते तेवढेच देणे, जास्त काहीच नाहीlast accessed — प्रत्येक परवानगी खरोखर केव्हा वापरली गेली त्याची नोंदwildcard — 'इथे काहीही' म्हणणारा *, जसे प्रत्येक S3 action साठी s3:*Access Analyzer — न वापरलेला access शोधणारे आणि खऱ्या वापरावरून अरुंद policies बनवणारे AWS tool
1📦 दिलेले विरुद्ध वापरलेले — teachers role, 90 दिवसांचा पुरावादिले s3:*🟩 s3:GetObject🟩 s3:ListBucket🟩 s3:PutObject3 वापरलेदिले ec2:*🟩 ec2:DescribeInstances1 वापरलेदिले dynamodb:*💤कधीच वापरले नाही0 वापरले🧾 data/last-accessed.json"principal": "arn:aws:iam:: 111122223333:role/teachers","days": 90,"actions_used": [ "s3:GetObject", "s3:ListBucket", "s3:PutObject", "ec2:DescribeInstances"]💤 दिले पण कधीच वापरले नाही: dynamodb:*→ काढून टाकाप्रत्येक चौकोन = एक action (एक रेखाटन)2✂️ रुंद चिठ्ठीपासून अरुंद चिठ्ठीपर्यंत📝 teachers-wide.json"Sid": "WhatWeGaveThem","Action": ["s3:*", "ec2:*", "dynamodb:*"],"Resource": "*"✂️📝 अरुंद केलेली (वापरावरून बनवलेली)"Effect": "Allow","Action": ["ec2:DescribeInstances", "s3:GetObject", "s3:ListBucket", "s3:PutObject"],"Resource": "*"मगपायरी 2 · Resource अरुंद करा:s3 actions → फक्त school-reportsआणि school-reports/*ec2:Describe* "*" च राहते(त्याला resource-level ARN नाही)अरुंद policy → s3:GetObject✅ ALLOWidentity policy narrowed#0 परवानगी देतेअरुंद policy → dynamodb:DeleteTable🚫 IMPLICIT DENYकोणतीही policy परवानगी देत नाही — AWS मूळ नियमाने नाकारतोफुटलेली अरुंद चिठ्ठी reports वाचू शकते; फुटलेली रुंद चिठ्ठी प्रत्येक table पुसू शकली असती3🔍 IAM Access Analyzer — तुमच्यासोबत हे करणारे साधन🌍 बाहेरचा प्रवेशschool-reports वाचू शकतेaccount 444455556666 —अपेक्षित (धडा 9)? archive करा💤 न वापरलेला प्रवेशrole teachers: dynamodb:*90 दिवस न वापरलेले —काढा✍️ policy तयार करणेCloudTrail चे 90 दिवस वाचतेआणि अरुंद चिठ्ठीचामसुदा तुमच्या तपासणीसाठी बनवते
⏪ आधी

'लवकर व्हावे' म्हणून 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: काय दिले, काय वापरले, आणि अरुंद केलेली चिठ्ठी

संपूर्ण धडा 11 वाचा →

12 🧾 Audit आणि घटनेला प्रतिसाद

कार्यालयाची नोंदवही — 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 — काही चुकले तर क्रमाने पाळायच्या लिखित पायऱ्या
1📋 credential report — auditor सारखे वाचा (आज = 2026-09-27)usermfa_activepassword_last_usedkey_1_activekey_1_rotatedkey_1_last_usedनिष्कर्ष<root_account>true2026-01-04falseN/AN/A✅ ठीकaishwaryatrue2026-09-26falseN/AN/A✅ ठीकkatrinafalse2026-09-20true2025-11-022026-09-25⚠️ MFA शिवाय password · key 329 दिवस जुनीdipikafalse2026-06-01true2024-03-102024-04-02⚠️ MFA नाही · key 931 दिवस जुनी · 90 दिवसांपेक्षा जास्त न वापरलेली → पुसाci-robotfalseN/Atrue2026-08-302026-09-27✅ ठीक (एक robot: password नाही)iam/demo.py audit मधील नियम: MFA शिवाय password · 90 दिवसांपेक्षा जुनी key · 90 दिवसांपेक्षा जास्त न वापरलेली key2🕑 CloudTrail — katrina ची key, रात्री 02:03, नव्या IP वरून🌙 रात्र 22:00–06:0026 Sep 06:0012:0018:0027 Sep 00:0006:0012:00katrina · GetObject, ListBuckets203.0.113.40 · ap-south-1🚨 36 सेकंदांत 3 calls198.51.100.77 वरूनaishwarya · GetObject203.0.113.12eventTimeusereventNameawsRegionsourceIPerrorCode2026-09-26T09:12:04ZkatrinaGetObjectap-south-1203.0.113.402026-09-26T09:40:11ZkatrinaListBucketsap-south-1203.0.113.40🚨2026-09-27T02:03:55ZkatrinaGetCallerIdentityus-east-1198.51.100.77🚨2026-09-27T02:04:20ZkatrinaRunInstancessa-east-1198.51.100.77AccessDenied🚨2026-09-27T02:04:31ZkatrinaCreateUserus-east-1198.51.100.77AccessDenied2026-09-27T08:15:00ZaishwaryaGetObjectap-south-1203.0.113.12हे विचित्र का आहे· नवा IP: 198.51.100.77· नवे regions: us-east-1,   sa-east-1· 02:03 — katrina झोपलेली असते· GetCallerIdentity ="ही key कोणाची?"· दोनदा AccessDenied: तिच्याचिठ्ठ्या फक्त reports वाचतात3🚒 runbook — पाच पायऱ्या, याच क्रमाने1key निष्क्रिय करा$ aws iam update-access-key --user-name katrina --access-key-id AKIAEXAMPLEKATRINA01 --status Inactive→ key चालणे थांबते2sessions रद्द करा# inline Deny on katrina:Deny * जेव्हा aws:TokenIssueTime02:10Z च्या आधी असेल→ जुनी sessions सुद्धा संपतात3त्याने काय बनवले ते शोधा$ aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId, AttributeValue= AKIAEXAMPLEKATRINA01→ मागे काहीच राहत नाही4rotate करा — किंवा काढून टाकानवी key फक्तखरोखर गरज असेल तर —अधिक चांगले: katrinaSSO ने sign in करते (L10)→ दीर्घकाळ टिकणारी key नाही5ती कशी फुटली ते शोधाgit इतिहास · laptopCI logs · चिकटवलेलाscreenshot → कारणदुरुस्त करा→ पुन्हा घडत नाही
⏪ आधी

जुन्या 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 चालवा

संपूर्ण धडा 12 वाचा →