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

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

👤 IAM users विरुद्ध roles विरुद्ध Identity Center — धडे 02, 05, 10

⏮️ roles आणि single sign-on आधी

प्रत्येक व्यक्तीला आणि प्रत्येक script ला password आणि दीर्घकाळ टिकणारी access key असलेला IAM user मिळे; keys laptops, repos आणि screenshots मध्ये पोहोचत, आणि कोणत्या अजून वापरात आहेत ते कोणालाच माहीत नसे.

✅ फायदे

  • roles अल्पायुषी credentials देतात — फुटण्यासारखे कायमचे काहीच नाही
  • Identity Center लोकांना अनेक accounts साठी एकच login देते
  • IAM users अजूनही क्वचित break-glass प्रसंगांसाठी चालतात

❌ तोटे

  • roles ना trust policy लागते — बरोबर करायची आणखी एक गोष्ट
  • Identity Center ही संपूर्ण organization ची मांडणी आहे
  • जुनी साधने फक्त access keys समजू शकतात

👍 वापरा जेव्हा

  • लोक: Identity Center · AWS वरील programs: roles · CI: OIDC roles
  • break-glass: MFA सह कुलुपात ठेवलेला एकच user

👎 दोनदा विचार करा जेव्हा

  • प्रत्येक developer साठी एक IAM user आणि त्याच्या laptop वर access key
  • अनेक लोकांमध्ये एकच user वाटून घेणे

📝 AWS-managed विरुद्ध customer-managed विरुद्ध inline policies — धडा 03

⏮️ पुन्हा वापरता येणाऱ्या policies आधी

तोच JSON अनेक users मध्ये चिकटवला जाई; एक चूक दुरुस्त करायची म्हणजे प्रत्येक प्रत शोधणे.

✅ फायदे

  • customer-managed: एक तपासलेली policy, अनेकदा जोडलेली, versions सह
  • AWS-managed: नेहमीच्या कामांसाठी झटपट सुरुवात
  • inline: तिच्या user किंवा role सोबत संपते — काटेकोर एकास-एक

❌ तोटे

  • AWS-managed policies व्यापक असतात आणि AWS बदलल्यावर बदलतात
  • मोठ्या प्रमाणावर inline policies चे audit कठीण असते

👍 वापरा जेव्हा

  • तुमच्या मालकीच्या प्रत्येक गोष्टीसाठी customer-managed
  • inline फक्त एका घट्ट, एकदाच्या जोडणीसाठी

👎 दोनदा विचार करा जेव्हा

  • default म्हणून AdministratorAccess
  • तीच inline policy वीस roles मध्ये copy केलेली

⚖️ Explicit deny विरुद्ध implicit deny — धडा 04

⏮️ नियम स्पष्ट होण्याआधी

टीम्स समजत की 'उल्लेख नाही' म्हणजे 'परवानगी आहे', किंवा मोठ्या Allow ने 'un-deny' करण्याचा प्रयत्न करत.

✅ फायदे

  • implicit deny: मुळातच सुरक्षित — कोणी हो म्हणेपर्यंत काहीच चालत नाही
  • explicit Deny: कोणताही Allow डावलू शकत नाही असा पक्का थांबा — कुंपणांसाठी उत्तम

❌ तोटे

  • व्यापक explicit Deny admins ना सुद्धा बाहेर ठेवू शकतो
  • 'नकार का?' शोधायला संपूर्ण मूल्यमापन क्रम लागतो

👍 वापरा जेव्हा

  • 'कधीच नाही' साठी explicit Deny: audit logs पुसणे, मंजूर regions सोडणे
  • बाकी सगळ्यासाठी implicit deny वर अवलंबून रहा

👎 दोनदा विचार करा जेव्हा

  • जिथे अरुंद Allow पुरेल तिथे Deny वापरणे
  • तपासल्याशिवाय NotAction + Deny — त्यात आश्चर्ये लपतात

🏷️ RBAC विरुद्ध ABAC — धडा 07

⏮️ policies मध्ये tags आधी

प्रत्येक टीम, प्रत्येक project, प्रत्येक environment साठी नवी policy — शेकडो जवळजवळ सारख्या प्रती.

✅ फायदे

  • ABAC: एक policy, tags ठरवतात — नवी टीम म्हणजे नवा tag
  • RBAC: सोपे आणि स्पष्ट, वाचायला सोपे

❌ तोटे

  • ABAC tagging च्या शिस्तीवर अवलंबून — चुकीचा tag म्हणजे चुकीची परवानगी
  • प्रत्येक action प्रत्येक condition key ला साथ देत नाही

👍 वापरा जेव्हा

  • अनेक सारख्या टीम्स किंवा projects साठी ABAC
  • मोजक्या स्पष्ट roles साठी RBAC

👎 दोनदा विचार करा जेव्हा

  • tags कोण बदलू शकतो याचे संरक्षण न करता ABAC
  • tests शिवाय एकाच policy मध्ये दोन्ही शैली मिसळणे

🚧 Permission boundaries विरुद्ध SCPs — धडा 08

⏮️ कुंपणांआधी

Admins स्वतःपेक्षा जास्त ताकदीचा user बनवू शकत, आणि एका account ची चूक कोणत्याही region मध्ये पैसे खर्च करू शकत असे.

✅ फायदे

  • boundary: एका user किंवा role वर छत — IAM चे सुरक्षित सोपवणे
  • SCP: organization कडून संपूर्ण account वर छत — region आणि service नियम

❌ तोटे

  • दोन्हीपैकी कोणीच काही देत नाही — लोक विसरतात आणि काहीच का चालत नाही असा विचार करतात
  • SCPs management account वर परिणाम करत नाहीत

👍 वापरा जेव्हा

  • developers roles बनवू शकत असतील तेव्हा boundary
  • संपूर्ण organization च्या 'कधीच नाही' साठी SCP

👎 दोनदा विचार करा जेव्हा

  • SCPs लाच एकमेव परवानग्या म्हणून वापरणे
  • कोणीच नोंद न केलेली boundary

🤝 Resource policies विरुद्ध role assume करणे — धडा 09

⏮️ दोन्हीपैकी काहीही येण्याआधी

टीम्स passwords वाटून घेत किंवा accounts मध्ये data हाताने copy करत.

✅ फायदे

  • resource policy: भागीदार स्वतःची ओळख ठेवतो; S3, KMS, SQS साठी सोपे
  • assume role: एक दार, प्रत्येक session चे audit शक्य, कोणत्याही service साठी चालते

❌ तोटे

  • resource policies फक्त काही services साठीच असतात
  • assume-role साठी भागीदाराला roles बदलावे लागतात; confused-deputy साठी ExternalId लागतो

👍 वापरा जेव्हा

  • एका bucket चा वाचन प्रवेश: resource policy
  • दुसऱ्या account मध्ये व्यापक काम: trust policy सह role

👎 दोनदा विचार करा जेव्हा

  • अटींशिवाय Principal: *
  • तिसऱ्या पक्षांसाठी ExternalId शिवाय संपूर्ण account root वर विश्वास ठेवणे

🤖 साठवलेल्या access keys विरुद्ध OIDC federation — धडा 06

⏮️ OIDC च्या आधी

CI systems AWS access key secret म्हणून साठवत; ती logs आणि forks मध्ये फुटे आणि कधीच expire होत नसे.

✅ फायदे

  • कुठेही दीर्घकाळ टिकणारे secret नाही; credentials सुमारे एका तासात expire होतात
  • trust policy नेमका repo आणि branch पक्का करते

❌ तोटे

  • trust policy च्या अटी अचूकच हव्यात — ढिला sub forks ना आत येऊ देतो
  • प्रत्येक account मध्ये एकदा identity provider मांडावा लागतो

👍 वापरा जेव्हा

  • GitHub Actions, GitLab, Kubernetes service accounts
  • OIDC tokens बनवू शकणारी कोणतीही CI

👎 दोनदा विचार करा जेव्हा

  • फक्त aud तपासणारी trust policy
  • 'फक्त आत्तापुरती' CI मध्ये access key