GCP - मूल जानकारी

Reading time: 18 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

संसाधन पदानुक्रम

Google Cloud एक संसाधन पदानुक्रम का उपयोग करता है जो अवधारणात्मक रूप से पारंपरिक फ़ाइल सिस्टम के समान है। यह नीतियों और अनुमतियों के लिए विशिष्ट संलग्न बिंदुओं के साथ एक तार्किक माता/पिता कार्यप्रवाह प्रदान करता है।

उच्च स्तर पर, यह इस तरह दिखता है:

Organization
--> Folders
--> Projects
--> Resources

A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.

https://cloud.google.com/static/resource-manager/img/cloud-hierarchy.svg

Projects Migration

यह संभव है कि किसी संगठन के बिना एक प्रोजेक्ट को एक संगठन में माइग्रेट करें जिसमें अनुमतियाँ roles/resourcemanager.projectCreator और roles/resourcemanager.projectMover हों। यदि प्रोजेक्ट किसी अन्य संगठन के अंदर है, तो इसे पहले संगठन से बाहर ले जाने के लिए GCP समर्थन से संपर्क करना आवश्यक है। अधिक जानकारी के लिए यहाँ देखें।

Organization Policies

आपके संगठन के क्लाउड संसाधनों पर नियंत्रण केंद्रीकृत करने की अनुमति देता है:

  • संरक्षणों को कॉन्फ़िगर करने के लिए नियंत्रण को केंद्रीकृत करें कि आपके संगठन के संसाधनों का उपयोग कैसे किया जा सकता है।
  • आपके विकास टीमों के लिए अनुपालन सीमाओं के भीतर रहने के लिए गार्डरेल को परिभाषित और स्थापित करें।
  • प्रोजेक्ट मालिकों और उनकी टीमों को बिना अनुपालन तोड़ने की चिंता किए तेजी से आगे बढ़ने में मदद करें।

ये नीतियाँ पूर्ण संगठन, फ़ोल्डर(ओं) या प्रोजेक्ट(ओं) को प्रभावित करने के लिए बनाई जा सकती हैं। लक्षित संसाधन पदानुक्रम नोड के वंशज संगठन नीति को विरासत में लेते हैं।

एक संगठन नीति को परिभाषित करने के लिए, आप एक प्रतिबंध चुनते हैं, जो या तो एक Google Cloud सेवा या Google Cloud सेवाओं के समूह के खिलाफ एक विशेष प्रकार की प्रतिबंध है। आप अपनी इच्छित प्रतिबंधों के साथ उस प्रतिबंध को कॉन्फ़िगर करते हैं।

https://cloud.google.com/resource-manager/img/org-policy-concepts.svg

Common use cases

  • डोमेन के आधार पर संसाधन साझा करने की सीमा।
  • पहचान और पहुंच प्रबंधन सेवा खातों के उपयोग को सीमित करें।
  • नए बनाए गए संसाधनों के भौतिक स्थान को प्रतिबंधित करें।
  • सेवा खाता निर्माण को निष्क्रिय करें।

आपके संगठन के संसाधनों पर बारीक नियंत्रण देने वाले कई और प्रतिबंध हैं। अधिक जानकारी के लिए, सभी संगठन नीति सेवा प्रतिबंधों की सूची** देखें।**

Default Organization Policies

ये नीतियाँ हैं जो Google आपके GCP संगठन को सेट करते समय डिफ़ॉल्ट रूप से जोड़ेगा:

Access Management Policies

  • Domain restricted contacts: आपके निर्दिष्ट डोमेन के बाहर आवश्यक संपर्कों में उपयोगकर्ताओं को जोड़ने से रोकता है। यह आवश्यक संपर्कों को केवल आपके चयनित डोमेन में प्रबंधित उपयोगकर्ता पहचान को प्लेटफ़ॉर्म सूचनाएँ प्राप्त करने की अनुमति देता है।
  • Domain restricted sharing: आपके निर्दिष्ट डोमेन के बाहर IAM नीतियों में उपयोगकर्ताओं को जोड़ने से रोकता है। यह IAM नीतियों को केवल आपके चयनित डोमेन में प्रबंधित उपयोगकर्ता पहचान को इस संगठन के अंदर संसाधनों तक पहुँचने की अनुमति देता है।
  • Public access prevention: क्लाउड स्टोरेज बकेट को सार्वजनिक रूप से उजागर होने से रोकता है। यह सुनिश्चित करता है कि एक डेवलपर क्लाउड स्टोरेज बकेट को बिना प्रमाणीकरण के इंटरनेट एक्सेस के लिए कॉन्फ़िगर नहीं कर सकता।
  • Uniform bucket level access: क्लाउड स्टोरेज बकेट में ऑब्जेक्ट-स्तरीय एक्सेस नियंत्रण सूचियों (ACLs) को रोकता है। यह आपके एक्सेस प्रबंधन को सरल बनाता है सभी ऑब्जेक्ट्स पर IAM नीतियों को लगातार लागू करके।
  • Require OS login: नए प्रोजेक्ट में बनाए गए VMs में OS लॉगिन सक्षम होगा। यह आपको IAM का उपयोग करके अपने उदाहरणों तक SSH एक्सेस प्रबंधित करने की अनुमति देता है बिना व्यक्तिगत SSH कुंजी बनाने और प्रबंधित किए।

Additional security policies for service accounts

  • Disable automatic IAM grants: डिफ़ॉल्ट ऐप इंजन और कंप्यूट इंजन सेवा खातों को प्रोजेक्ट पर निर्माण के समय स्वचालित रूप से संपादक IAM भूमिका दिए जाने से रोकता है। यह सुनिश्चित करता है कि सेवा खातों को निर्माण के समय अत्यधिक अनुमति वाले IAM भूमिकाएँ नहीं मिलेंगी।
  • Disable service account key creation: सार्वजनिक सेवा खाता कुंजी के निर्माण को रोकता है। यह स्थायी क्रेडेंशियल्स को उजागर करने के जोखिम को कम करने में मदद करता है।
  • Disable service account key upload: सार्वजनिक सेवा खाता कुंजी के अपलोड को रोकता है। यह लीक या पुन: उपयोग की गई कुंजी सामग्री के जोखिम को कम करने में मदद करता है।

Secure VPC network configuration policies

  • Define allowed external IPs for VM instances: सार्वजनिक IP के साथ Compute उदाहरणों के निर्माण को रोकता है, जो उन्हें इंटरनेट ट्रैफ़िक के लिए उजागर कर सकता है।
  • Disable VM nested virtualization: Compute Engine VMs पर नेस्टेड VMs के निर्माण को रोकता है। यह बिना निगरानी वाले नेस्टेड VMs के सुरक्षा जोखिम को कम करता है।
  • Disable VM serial port: Compute Engine VMs पर सीरियल पोर्ट एक्सेस को रोकता है। यह Compute Engine API का उपयोग करके सर्वर के सीरियल पोर्ट में इनपुट को रोकता है।
  • Restrict authorized networks on Cloud SQL instances: सार्वजनिक या गैर-आंतरिक नेटवर्क रेंज को आपके Cloud SQL डेटाबेस तक पहुँचने से रोकता है।
  • Restrict Protocol Forwarding Based on type of IP Address: बाहरी IP पते के लिए VM प्रोटोकॉल फॉरवर्डिंग को रोकता है।
  • Restrict Public IP access on Cloud SQL instances: सार्वजनिक IP के साथ Cloud SQL उदाहरणों के निर्माण को रोकता है, जो उन्हें इंटरनेट ट्रैफ़िक के लिए उजागर कर सकता है।
  • Restrict shared VPC project lien removal: साझा VPC होस्ट प्रोजेक्ट के आकस्मिक हटाने को रोकता है।
  • Sets the internal DNS setting for new projects to Zonal DNS Only: एक विरासत DNS सेटिंग के उपयोग को रोकता है जिसने सेवा उपलब्धता को कम कर दिया है।
  • Skip default network creation: डिफ़ॉल्ट VPC नेटवर्क और संबंधित संसाधनों के स्वचालित निर्माण को रोकता है। यह अत्यधिक अनुमति वाले डिफ़ॉल्ट फ़ायरवॉल नियमों से बचाता है।
  • Disable VPC External IPv6 usage: बाहरी IPv6 उप-नेट के निर्माण को रोकता है, जो अनधिकृत इंटरनेट एक्सेस के लिए उजागर हो सकता है।

IAM Roles

ये AWS में IAM नीतियों के समान हैं क्योंकि प्रत्येक भूमिका में अनुमतियों का एक सेट होता है।

हालांकि, AWS की तुलना में, भूमिकाओं का कोई केंद्रीकृत रिपॉजिटरी नहीं है। इसके बजाय, संसाधन X को Y प्रिंसिपल को एक्सेस भूमिकाएँ देते हैं, और यह जानने का एकमात्र तरीका है कि किसी संसाधन को किसने एक्सेस दिया है, उस संसाधन पर get-iam-policy विधि का उपयोग करना।
यह एक समस्या हो सकती है क्योंकि इसका मतलब है कि यह जानने का एकमात्र तरीका है कि किस प्रिंसिपल के पास कौन सी अनुमतियाँ हैं, यह पूछना है कि प्रत्येक संसाधन किसे अनुमतियाँ दे रहा है, और एक उपयोगकर्ता को सभी संसाधनों से अनुमतियाँ प्राप्त करने की अनुमति नहीं हो सकती है।

IAM में तीन प्रकार की भूमिकाएँ हैं:

  • Basic/Primitive roles, जिसमें Owner, Editor, और Viewer भूमिकाएँ शामिल हैं जो IAM के परिचय से पहले मौजूद थीं।
  • Predefined roles, जो एक विशिष्ट सेवा के लिए बारीक एक्सेस प्रदान करते हैं और Google Cloud द्वारा प्रबंधित होते हैं। कई पूर्वनिर्धारित भूमिकाएँ हैं, आप उन सभी को उनके पास मौजूद विशेषाधिकारों के साथ यहाँ देख सकते हैं।
  • Custom roles, जो उपयोगकर्ता द्वारा निर्दिष्ट अनुमतियों की सूची के अनुसार बारीक एक्सेस प्रदान करते हैं।

GCP में हजारों अनुमतियाँ हैं। यह जांचने के लिए कि क्या किसी भूमिका में अनुमतियाँ हैं, आप यहाँ अनुमति खोज सकते हैं और देख सकते हैं कि कौन सी भूमिकाएँ इसे रखती हैं।

आप यहाँ पूर्वनिर्धारित भूमिकाएँ भी खोज सकते हैं जो प्रत्येक उत्पाद द्वारा पेश की जाती हैं। ध्यान दें कि कुछ भूमिकाएँ उपयोगकर्ताओं को संलग्न नहीं की जा सकती हैं और केवल SAs को क्योंकि उनमें कुछ अनुमतियाँ होती हैं।
इसके अलावा, ध्यान दें कि अनुमतियाँ केवल तभी प्रभावी होंगी यदि वे संबंधित सेवा से जुड़ी हों।

या जांचें कि क्या एक कस्टम भूमिका एक विशिष्ट अनुमति का उपयोग कर सकती है यहाँ।

GCP - IAM, Principals & Org Policies Enum

Users

GCP कंसोल में कोई उपयोगकर्ता या समूह प्रबंधन नहीं है, यह Google Workspace में किया जाता है। हालाँकि, आप Google Workspace में एक अलग पहचान प्रदाता को समन्वयित कर सकते हैं।

आप कार्यक्षेत्रों के उपयोगकर्ताओं और समूहों तक पहुँच सकते हैं https://admin.google.com।

MFA को कार्यक्षेत्र उपयोगकर्ताओं पर लागू किया जा सकता है, हालाँकि, एक हमलावर एक टोकन का उपयोग करके GCP के माध्यम से CLI तक पहुँच सकता है जो MFA द्वारा सुरक्षित नहीं होगा (यह MFA द्वारा केवल तब सुरक्षित होगा जब उपयोगकर्ता इसे उत्पन्न करने के लिए लॉगिन करता है: gcloud auth login)।

Groups

जब एक संगठन बनाया जाता है, तो कई समूहों का निर्माण करना अत्यधिक अनुशंसित है। यदि आप इनमें से किसी का प्रबंधन करते हैं, तो आप संगठन के सभी या महत्वपूर्ण भाग को समझौता कर सकते हैं:

GroupFunction
gcp-organization-admins
(चेकलिस्ट के लिए समूह या व्यक्तिगत खाते आवश्यक)		संगठन से संबंधित किसी भी संसाधन का प्रशासन करना। इस भूमिका को सावधानी से असाइन करें; संगठन के प्रशासकों को आपके सभी Google Cloud संसाधनों तक पहुँच होती है। वैकल्पिक रूप से, क्योंकि यह कार्य अत्यधिक विशेषाधिकार प्राप्त है, समूह बनाने के बजाय व्यक्तिगत खातों का उपयोग करने पर विचार करें।
gcp-network-admins
(चेकलिस्ट के लिए आवश्यक)		नेटवर्क, उप-नेट, फ़ायरवॉल नियम और नेटवर्क उपकरण जैसे क्लाउड राउटर, क्लाउड VPN, और क्लाउड लोड बैलेंसर बनाना।
gcp-billing-admins
(चेकलिस्ट के लिए आवश्यक)		बिलिंग खातों को सेट करना और उनके उपयोग की निगरानी करना।
gcp-developers
(चेकलिस्ट के लिए आवश्यक)		ऐप्लिकेशन को डिज़ाइन, कोडिंग और परीक्षण करना।
gcp-security-admins
संगठन के लिए सुरक्षा नीतियों की स्थापना और प्रबंधन करना, जिसमें पहुँच प्रबंधन और संगठन प्रतिबंध नीतियाँ शामिल हैं। Google Cloud सुरक्षा बुनियादी ढाँचे की योजना बनाने के लिए अधिक जानकारी के लिए Google Cloud सुरक्षा बुनियादी सिद्धांत गाइड देखें।
gcp-devopsनिरंतर एकीकरण और वितरण, निगरानी, और प्रणाली प्रावधान का समर्थन करने वाले एंड-टू-एंड पाइपलाइनों का निर्माण या प्रबंधन करना।
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer
(अब डिफ़ॉल्ट रूप से नहीं)		प्रोजेक्ट पर खर्च की निगरानी करना। सामान्य सदस्य वित्त टीम का हिस्सा होते हैं।
gcp-platform-viewer
(अब डिफ़ॉल्ट रूप से नहीं)		Google Cloud संगठन में संसाधन जानकारी की समीक्षा करना।
gcp-security-reviewer
(अब डिफ़ॉल्ट रूप से नहीं)		क्लाउड सुरक्षा की समीक्षा करना।
gcp-network-viewer
(अब डिफ़ॉल्ट रूप से नहीं)		नेटवर्क कॉन्फ़िगरेशन की समीक्षा करना।
grp-gcp-audit-viewer
(अब डिफ़ॉल्ट रूप से नहीं)		ऑडिट लॉग देखने के लिए।
gcp-scc-admin
(अब डिफ़ॉल्ट रूप से नहीं)		सुरक्षा कमांड सेंटर का प्रशासन करना।
gcp-secrets-admin
(अब डिफ़ॉल्ट रूप से नहीं)		सीक्रेट मैनेजर में रहस्यों का प्रबंधन करना।

Default Password Policy

  • मजबूत पासवर्ड लागू करें
  • 8 से 100 वर्णों के बीच
  • पुन: उपयोग नहीं
  • समाप्ति नहीं
  • यदि लोग तीसरे पक्ष के प्रदाता के माध्यम से कार्यक्षेत्र तक पहुँच रहे हैं, तो ये आवश्यकताएँ लागू नहीं होती हैं।

Service accounts

ये प्रिंसिपल हैं जिन्हें संसाधनों के साथ जुड़ा जा सकता है और GCP के साथ आसानी से बातचीत करने के लिए पहुँच प्राप्त होती है। उदाहरण के लिए, एक सेवा खाते के auth token तक पहुँच प्राप्त करना संभव है जो एक VM में मेटाडेटा में जुड़ा होता है।
यह IAM और एक्सेस स्कोप दोनों का उपयोग करते समय कुछ संघर्षों का सामना करना संभव है। उदाहरण के लिए, आपके सेवा खाते में compute.instanceAdmin की IAM भूमिका हो सकती है लेकिन जिस उदाहरण में आप घुसे हैं, उसे https://www.googleapis.com/auth/compute.readonly के स्कोप सीमा के साथ कमजोर किया गया है। यह आपको आपके उदाहरण के लिए स्वचालित रूप से असाइन किए गए OAuth टोकन का उपयोग करके कोई परिवर्तन करने से रोक देगा।

यह AWS के IAM भूमिकाओं के समान है। लेकिन AWS की तरह नहीं, कोई भी सेवा खाता किसी भी सेवा से जुड़ा हो सकता है (यह नीति के माध्यम से अनुमति देने की आवश्यकता नहीं है)।

आप पाएंगे कि कई सेवा खाते वास्तव में GCP द्वारा स्वचालित रूप से उत्पन्न होते हैं जब आप किसी सेवा का उपयोग करना शुरू करते हैं, जैसे:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

हालांकि, कस्टम सेवा खातों को बनाना और संसाधनों से जोड़ना भी संभव है, जो इस तरह दिखेंगे:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Keys & Tokens

GCP तक पहुँचने के 2 मुख्य तरीके हैं जैसे कि सेवा खाता:

  • OAuth टोकन के माध्यम से: ये टोकन हैं जो आपको मेटाडेटा एंडपॉइंट्स या http अनुरोधों को चुराने से मिलेंगे और ये एक्सेस स्कोप द्वारा सीमित होते हैं।
  • कुंजी: ये सार्वजनिक और निजी कुंजी जोड़े हैं जो आपको सेवा खाते के रूप में अनुरोधों पर हस्ताक्षर करने की अनुमति देंगे और यहां तक कि सेवा खाते के रूप में कार्य करने के लिए OAuth टोकन उत्पन्न करेंगे। ये कुंजी खतरनाक हैं क्योंकि इन्हें सीमित और नियंत्रित करना अधिक जटिल है, इसलिए GCP अनुशंसा करता है कि इन्हें उत्पन्न न किया जाए।
  • ध्यान दें कि हर बार जब एक SA बनाया जाता है, GCP सेवा खाते के लिए एक कुंजी उत्पन्न करता है जिसे उपयोगकर्ता एक्सेस नहीं कर सकता (और यह वेब एप्लिकेशन में सूचीबद्ध नहीं होगा)। इस थ्रेड के अनुसार, यह कुंजी GCP द्वारा आंतरिक रूप से उपयोग की जाती है ताकि मेटाडेटा एंडपॉइंट्स को एक्सेसिबल OAuth टोकन उत्पन्न करने की अनुमति मिल सके।

Access scopes

एक्सेस स्कोप उत्पन्न OAuth टोकन से जुड़े होते हैं ताकि GCP API एंडपॉइंट्स तक पहुँच प्राप्त हो सके। ये OAuth टोकन की अनुमतियों को प्रतिबंधित करते हैं।
इसका मतलब है कि यदि एक टोकन किसी संसाधन के मालिक का है लेकिन उस संसाधन तक पहुँचने के लिए टोकन स्कोप में नहीं है, तो टोकन उन विशेषाधिकारों का (दुरुपयोग) करने के लिए उपयोग नहीं किया जा सकता।

गूगल वास्तव में सिफारिश करता है कि एक्सेस स्कोप का उपयोग न किया जाए और पूरी तरह से IAM पर निर्भर रहें। वेब प्रबंधन पोर्टल वास्तव में इसे लागू करता है, लेकिन कस्टम सेवा खातों का उपयोग करके प्रोग्रामेटिक रूप से उदाहरणों पर अभी भी एक्सेस स्कोप लागू किए जा सकते हैं।

आप देख सकते हैं कि स्कोप असाइन किए गए हैं क्वेरी करके:

bash
curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

पिछले scopes वे हैं जो default द्वारा gcloud का उपयोग करके डेटा तक पहुँचने के लिए उत्पन्न होते हैं। इसका कारण यह है कि जब आप gcloud का उपयोग करते हैं, तो आप पहले एक OAuth टोकन बनाते हैं, और फिर इसका उपयोग एंडपॉइंट्स से संपर्क करने के लिए करते हैं।

उनमें से सबसे महत्वपूर्ण स्कोप cloud-platform है, जिसका मूल रूप से मतलब है कि GCP में किसी भी सेवा तक पहुँचने की संभावना है।

आप यहाँ सभी संभावित स्कोप की एक सूची पैदा कर सकते हैं।

यदि आपके पास gcloud ब्राउज़र क्रेडेंशियल्स हैं, तो यह अन्य स्कोप के साथ एक टोकन प्राप्त करना संभव है, ऐसा कुछ करते हुए:

bash
# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM नीतियाँ, बाइंडिंग और सदस्यताएँ

जैसा कि terraform द्वारा परिभाषित किया गया है https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam GCP के साथ terraform का उपयोग करते समय संसाधन पर एक प्रिंसिपल को पहुँच देने के विभिन्न तरीके हैं:

  • सदस्यताएँ: आप प्रिंसिपल को भूमिकाओं के सदस्यों के रूप में सेट करते हैं भूमिका या प्रिंसिपल पर कोई प्रतिबंध नहीं। आप एक उपयोगकर्ता को एक भूमिका का सदस्य बना सकते हैं और फिर उसी भूमिका का सदस्य बनाने के लिए एक समूह को भी रख सकते हैं और उन प्रिंसिपलों (उपयोगकर्ता और समूह) को अन्य भूमिकाओं का सदस्य भी बना सकते हैं।
  • बाइंडिंग: कई प्रिंसिपल को एक भूमिका से बाइंड किया जा सकता है। वे प्रिंसिपल अभी भी अन्य भूमिकाओं के बाइंड या सदस्य हो सकते हैं। हालाँकि, यदि एक प्रिंसिपल जो भूमिका से बाइंड नहीं है, को बाइंड की गई भूमिका का सदस्य बनाया जाता है, तो अगली बार जब बाइंडिंग लागू की जाती है, तो सदस्यता गायब हो जाएगी।
  • नीतियाँ: एक नीति अधिकारिता है, यह भूमिकाओं और प्रिंसिपलों को इंगित करती है और फिर, वे प्रिंसिपल अधिक भूमिकाएँ नहीं रख सकते और उन भूमिकाओं में अधिक प्रिंसिपल नहीं हो सकते जब तक कि उस नीति में संशोधन नहीं किया जाता (न ही अन्य नीतियों, बाइंडिंग या सदस्यताओं में)। इसलिए, जब किसी नीति में एक भूमिका या प्रिंसिपल निर्दिष्ट किया जाता है, तो उसकी सभी विशेषताएँ उस नीति द्वारा सीमित होती हैं। स्पष्ट रूप से, यदि प्रिंसिपल को नीति को संशोधित करने या विशेषाधिकार वृद्धि की अनुमति दी जाती है (जैसे एक नया प्रिंसिपल बनाना और उसे एक नई भूमिका से बाइंड करना), तो इसे बायपास किया जा सकता है।

संदर्भ

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें