GCP - Basic Information
Last updated
Last updated
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Google Cloud एक संसाधन पदानुक्रम का उपयोग करता है जो अवधारणात्मक रूप से पारंपरिक फ़ाइल सिस्टम के समान है। यह नीतियों और अनुमतियों के लिए विशिष्ट अटैचमेंट बिंदुओं के साथ एक तार्किक माता/पिता कार्यप्रवाह प्रदान करता है।
उच्च स्तर पर, यह इस तरह दिखता है:
A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.
यह संभव है कि कोई प्रोजेक्ट बिना किसी संगठन के को एक संगठन में roles/resourcemanager.projectCreator और roles/resourcemanager.projectMover अनुमतियों के साथ माइग्रेट किया जाए। यदि प्रोजेक्ट किसी अन्य संगठन के अंदर है, तो इसे पहले संगठन से बाहर ले जाने के लिए GCP समर्थन से संपर्क करना आवश्यक है। अधिक जानकारी के लिए यहाँ देखें.
आपके संगठन के क्लाउड संसाधनों पर नियंत्रण केंद्रीकृत करने की अनुमति देता है:
आपके संगठन के संसाधनों के उपयोग पर प्रतिबंधों को कॉन्फ़िगर करने के लिए नियंत्रण को केंद्रीकृत करें।
आपके विकास टीमों के लिए अनुपालन सीमाओं के भीतर रहने के लिए गार्डरेल परिभाषित और स्थापित करें।
प्रोजेक्ट मालिकों और उनकी टीमों को बिना अनुपालन तोड़ने की चिंता किए तेजी से आगे बढ़ने में मदद करें।
ये नीतियाँ पूर्ण संगठन, फ़ोल्डर(ओं) या प्रोजेक्ट(ओं) को प्रभावित करने के लिए बनाई जा सकती हैं। लक्षित संसाधन पदानुक्रम नोड के वंशज संगठन नीति को विरासत में लेते हैं।
संगठन नीति को परिभाषित करने के लिए, आप एक प्रतिबंध चुनते हैं, जो या तो एक Google Cloud सेवा या Google Cloud सेवाओं के समूह के खिलाफ एक विशेष प्रकार का प्रतिबंध है। आप अपनी इच्छित प्रतिबंधों के साथ उस प्रतिबंध को कॉन्फ़िगर करते हैं।
डोमेन के आधार पर संसाधन साझा करने की सीमा निर्धारित करें।
पहचान और पहुंच प्रबंधन सेवा खातों के उपयोग को सीमित करें।
नए बनाए गए संसाधनों के भौतिक स्थान को प्रतिबंधित करें।
सेवा खाता निर्माण को निष्क्रिय करें।
आपके संगठन के संसाधनों पर बारीक नियंत्रण देने वाले कई और प्रतिबंध हैं। अधिक जानकारी के लिए, देखें सभी संगठन नीति सेवा प्रतिबंधों की सूची.
ये AWS में IAM नीतियों के समान हैं क्योंकि प्रत्येक भूमिका में अनुमतियों का एक सेट होता है।
हालांकि, AWS की तुलना में, भूमिकाओं का कोई केंद्रीकृत रिपॉजिटरी नहीं है। इसके बजाय, संसाधन X को Y प्रिंसिपल को एक्सेस भूमिकाएँ देते हैं, और यह जानने का एकमात्र तरीका है कि किसी संसाधन को किसने एक्सेस दिया है, उस संसाधन पर get-iam-policy विधि का उपयोग करना।
यह एक समस्या हो सकती है क्योंकि इसका मतलब है कि यह जानने का एकमात्र तरीका है कि किस प्रिंसिपल के पास कौन सी अनुमतियाँ हैं, यह पूछना है कि प्रत्येक संसाधन किसे अनुमतियाँ दे रहा है, और एक उपयोगकर्ता को सभी संसाधनों से अनुमतियाँ प्राप्त करने की अनुमति नहीं हो सकती है।
IAM में तीन प्रकार की भूमिकाएँ हैं:
बुनियादी/प्राथमिक भूमिकाएँ, जिसमें स्वामी, संपादक, और दर्शक भूमिकाएँ शामिल हैं जो IAM के परिचय से पहले मौजूद थीं।
पूर्वनिर्धारित भूमिकाएँ, जो एक विशिष्ट सेवा के लिए बारीक पहुंच प्रदान करती हैं और Google Cloud द्वारा प्रबंधित होती हैं। बहुत सारी पूर्वनिर्धारित भूमिकाएँ हैं, आप यहाँ सभी को उनके पास मौजूद विशेषाधिकारों के साथ देख सकते हैं यहाँ।
कस्टम भूमिकाएँ, जो उपयोगकर्ता द्वारा निर्दिष्ट अनुमतियों की सूची के अनुसार बारीक पहुंच प्रदान करती हैं।
GCP में हजारों अनुमतियाँ हैं। यह जांचने के लिए कि क्या किसी भूमिका में अनुमतियाँ हैं, आप यहाँ अनुमति खोज सकते हैं और देख सकते हैं कि कौन सी भूमिकाएँ इसे रखती हैं।
आप यहाँ पूर्वनिर्धारित भूमिकाएँ खोज सकते हैं जो प्रत्येक उत्पाद द्वारा प्रदान की जाती हैं। ध्यान दें कि कुछ भूमिकाएँ उपयोगकर्ताओं को संलग्न नहीं की जा सकती हैं और केवल SAs को क्योंकि उनमें कुछ अनुमतियाँ होती हैं। इसके अलावा, ध्यान दें कि अनुमतियाँ केवल तभी प्रभावी होंगी जब वे संबंधित सेवा से जुड़ी हों।
या जांचें कि क्या कस्टम भूमिका एक विशिष्ट अनुमति का उपयोग कर सकती है यहाँ.
GCP - IAM, Principals & Org Policies EnumGCP कंसोल में कोई उपयोगकर्ता या समूह प्रबंधन नहीं है, यह Google Workspace में किया जाता है। हालाँकि, आप Google Workspace में एक अलग पहचान प्रदाता को समन्वयित कर सकते हैं।
आप कार्यक्षेत्र उपयोगकर्ताओं और समूहों तक पहुँच सकते हैं https://admin.google.com।
MFA को कार्यक्षेत्र उपयोगकर्ताओं पर लागू किया जा सकता है, हालाँकि, एक हमलावर एक टोकन का उपयोग करके GCP के माध्यम से CLI तक पहुँच सकता है जो MFA द्वारा सुरक्षित नहीं होगा (यह MFA द्वारा केवल तब सुरक्षित होगा जब उपयोगकर्ता इसे उत्पन्न करने के लिए लॉगिन करता है: gcloud auth login)।
जब एक संगठन बनाया जाता है, तो कई समूहों का निर्माण करना अत्यधिक अनुशंसित है। यदि आप इनमें से किसी का प्रबंधन करते हैं, तो आप संगठन के सभी या महत्वपूर्ण भाग को समझौता कर सकते हैं:
Group
Function
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
(अब डिफ़ॉल्ट रूप से नहीं)
सीक्रेट मैनेजर में रहस्यों का प्रबंधन करना।
मजबूत पासवर्ड लागू करें
8 से 100 वर्णों के बीच
पुन: उपयोग नहीं
समाप्ति नहीं
यदि लोग तीसरे पक्ष के प्रदाता के माध्यम से कार्यक्षेत्र तक पहुँच रहे हैं, तो ये आवश्यकताएँ लागू नहीं होती हैं।
ये प्रिंसिपल हैं जिन्हें संसाधनों के साथ जुड़ा जा सकता है और GCP के साथ आसानी से बातचीत करने के लिए पहुँच प्राप्त होती है। उदाहरण के लिए, एक सेवा खाते के auth token तक पहुँच प्राप्त करना संभव है जो एक VM में मेटाडेटा में जुड़ा होता है।
यह IAM और एक्सेस स्कोप दोनों का उपयोग करते समय कुछ संघर्षों का सामना करना संभव है। उदाहरण के लिए, आपके सेवा खाते में compute.instanceAdmin की IAM भूमिका हो सकती है लेकिन जिस उदाहरण में आप घुसपैठ कर चुके हैं, उसे https://www.googleapis.com/auth/compute.readonly के स्कोप प्रतिबंध के साथ कमजोर किया गया है। यह आपको उस OAuth टोकन का उपयोग करके कोई परिवर्तन करने से रोक देगा जो स्वचालित रूप से आपके उदाहरण को सौंपा गया है।
यह AWS से IAM भूमिकाओं के समान है। लेकिन AWS की तरह नहीं, कोई भी सेवा खाता किसी भी सेवा से जुड़ा हो सकता है (यह नीति के माध्यम से अनुमति देने की आवश्यकता नहीं है)।
आप पाएंगे कि कई सेवा खाते वास्तव में GCP द्वारा स्वचालित रूप से उत्पन्न होते हैं जब आप किसी सेवा का उपयोग करना शुरू करते हैं, जैसे:
हालांकि, कस्टम सेवा खातों को बनाना और संसाधनों से जोड़ना भी संभव है, जो इस तरह दिखेंगे:
GCP तक पहुँचने के 2 मुख्य तरीके हैं जैसे कि सेवा खाता:
OAuth टोकन के माध्यम से: ये टोकन हैं जो आपको मेटाडेटा एंडपॉइंट्स या HTTP अनुरोधों को चुराने से मिलेंगे और इन्हें एक्सेस स्कोप द्वारा सीमित किया गया है।
कुंजी: ये सार्वजनिक और निजी कुंजी जोड़े हैं जो आपको सेवा खाते के रूप में अनुरोधों पर हस्ताक्षर करने की अनुमति देंगे और यहां तक कि सेवा खाते के रूप में कार्य करने के लिए OAuth टोकन उत्पन्न करेंगे। ये कुंजी खतरनाक हैं क्योंकि इन्हें सीमित और नियंत्रित करना अधिक जटिल है, इसलिए GCP अनुशंसा करता है कि इन्हें उत्पन्न न किया जाए।
ध्यान दें कि हर बार जब एक SA बनाया जाता है, GCP सेवा खाते के लिए एक कुंजी उत्पन्न करता है जिसे उपयोगकर्ता एक्सेस नहीं कर सकता (और यह वेब एप्लिकेशन में सूचीबद्ध नहीं होगा)। इस थ्रेड के अनुसार, यह कुंजी GCP द्वारा आंतरिक रूप से उपयोग की जाती है ताकि मेटाडेटा एंडपॉइंट्स को एक्सेसिबल OAuth टोकन उत्पन्न करने की अनुमति मिल सके।
एक्सेस स्कोप उत्पन्न OAuth टोकन से जुड़े होते हैं ताकि GCP API एंडपॉइंट्स तक पहुँच सके। ये OAuth टोकन के अनुमतियों को सीमित करते हैं। इसका मतलब है कि यदि एक टोकन किसी संसाधन के मालिक का है लेकिन उस संसाधन तक पहुँचने के लिए टोकन स्कोप में नहीं है, तो टोकन उन विशेषाधिकारों का (दुरुपयोग) करने के लिए उपयोग नहीं किया जा सकता।
गूगल वास्तव में अनुशंसा करता है कि एक्सेस स्कोप का उपयोग नहीं किया जाए और पूरी तरह से IAM पर भरोसा किया जाए। वेब प्रबंधन पोर्टल वास्तव में इसे लागू करता है, लेकिन कस्टम सेवा खातों का उपयोग करके प्रोग्रामेटिक रूप से उदाहरणों पर अभी भी एक्सेस स्कोप लागू किए जा सकते हैं।
आप देख सकते हैं कि स्कोप किसे सौंपे गए हैं पूछताछ करके:
पिछले scopes वे हैं जो default द्वारा gcloud का उपयोग करके डेटा तक पहुँचने के लिए उत्पन्न होते हैं। इसका कारण यह है कि जब आप gcloud का उपयोग करते हैं, तो आप पहले एक OAuth टोकन बनाते हैं, और फिर इसका उपयोग एंडपॉइंट्स से संपर्क करने के लिए करते हैं।
उनमें से सबसे महत्वपूर्ण स्कोप cloud-platform है, जिसका मूल रूप से मतलब है कि GCP में किसी भी सेवा तक पहुँचने की संभावना है।
आप यहाँ सभी संभावित स्कोप की एक सूची पाकर सकते हैं।
यदि आपके पास gcloud ब्राउज़र क्रेडेंशियल्स हैं, तो यह अन्य स्कोप के साथ एक टोकन प्राप्त करना संभव है, कुछ ऐसा करते हुए:
जैसा कि terraform द्वारा https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam में परिभाषित किया गया है, GCP के साथ terraform का उपयोग करते समय संसाधन पर एक प्रिंसिपल को पहुँच देने के विभिन्न तरीके हैं:
सदस्यताएँ: आप प्रिंसिपल को भूमिकाओं के सदस्यों के रूप में सेट करते हैं भूमिका या प्रिंसिपल पर कोई प्रतिबंध नहीं। आप एक उपयोगकर्ता को एक भूमिका का सदस्य बना सकते हैं और फिर एक समूह को उसी भूमिका का सदस्य बना सकते हैं और उन प्रिंसिपल (उपयोगकर्ता और समूह) को अन्य भूमिकाओं का सदस्य भी बना सकते हैं।
बाइंडिंग: कई प्रिंसिपल को एक भूमिका से बाइंड किया जा सकता है। वे प्रिंसिपल अभी भी अन्य भूमिकाओं के बाइंड या सदस्य हो सकते हैं। हालाँकि, यदि एक प्रिंसिपल जो भूमिका से बाइंड नहीं है, को बाइंड की गई भूमिका का सदस्य बनाया जाता है, तो अगली बार जब बाइंडिंग लागू की जाती है, तो सदस्यता गायब हो जाएगी।
नीतियाँ: एक नीति अधिकारिता है, यह भूमिकाओं और प्रिंसिपलों को इंगित करती है और फिर, वे प्रिंसिपल अधिक भूमिकाएँ नहीं रख सकते और उन भूमिकाओं में अधिक प्रिंसिपल नहीं हो सकते जब तक कि उस नीति में संशोधन नहीं किया जाता (यहाँ तक कि अन्य नीतियों, बाइंडिंग या सदस्यताओं में भी नहीं)। इसलिए, जब किसी नीति में एक भूमिका या प्रिंसिपल निर्दिष्ट किया जाता है, तो उसकी सभी विशेषताएँ उस नीति द्वारा सीमित होती हैं। स्पष्ट रूप से, यदि प्रिंसिपल को नीति को संशोधित करने या विशेषाधिकार वृद्धि अनुमतियों (जैसे एक नया प्रिंसिपल बनाना और उसे एक नई भूमिका से बाइंड करना) का विकल्प दिया जाता है, तो इसे बायपास किया जा सकता है।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
