GCP - Basic Information
AWS Hacking सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें और अभ्यास करें:
HackTricks Training GCP Red Team Expert (GRTE)
Resource hierarchy
Google Cloud एक Resource hierarchy का उपयोग करता है जो अवधारणात्मक रूप से पारंपरिक फाइल सिस्टम के समान है। यह नीतियों और अनुमतियों के लिए विशिष्ट अटैचमेंट पॉइंट्स के साथ एक तार्किक parent/child वर्कफ़्लो प्रदान करता है।
उच्च स्तर पर, यह इस प्रकार दिखता है:
एक वर्चुअल मशीन (जिसे Compute Instance कहा जाता है) एक संसाधन है। एक संसाधन एक प्रोजेक्ट में स्थित होता है, संभवतः अन्य Compute Instances, स्टोरेज बकेट्स आदि के साथ।
Projects Migration
यह संभव है कि किसी प्रोजेक्ट को बिना किसी संगठन के एक संगठन में माइग्रेट किया जा सके, जिसमें roles/resourcemanager.projectCreator
और roles/resourcemanager.projectMover
की अनुमतियाँ हों। यदि प्रोजेक्ट किसी अन्य संगठन के अंदर है, तो पहले उन्हें संगठन से बाहर निकालने के लिए GCP समर्थन से संपर्क करना आवश्यक है। अधिक जानकारी के लिए यहाँ देखें।
Organization Policies
आपके संगठन के क्लाउड संसाधनों पर केंद्रीकृत नियंत्रण की अनुमति देता है:
आपके संगठन के संसाधनों का उपयोग कैसे किया जा सकता है, इस पर प्रतिबंधों को कॉन्फ़िगर करने के लिए केंद्रीकृत नियंत्रण।
आपके विकास टीमों को अनुपालन सीमाओं के भीतर रहने के लिए गार्डरेल्स को परिभाषित और स्थापित करें।
प्रोजेक्ट मालिकों और उनकी टीमों को तेजी से आगे बढ़ने में मदद करें बिना अनुपालन तोड़ने की चिंता के।
इन नीतियों को पूरे संगठन, फ़ोल्डर(s) या प्रोजेक्ट(s) को प्रभावित करने के लिए बनाया जा सकता है। लक्षित संसाधन पदानुक्रम नोड के वंशज संगठन नीति को विरासत में प्राप्त करते हैं।
एक संगठन नीति को परिभाषित करने के लिए, आप एक constraint चुनते हैं, जो या तो एक Google Cloud सेवा या Google Cloud सेवाओं के समूह के खिलाफ एक विशेष प्रकार का प्रतिबंध है। आप अपनी इच्छित प्रतिबंधों के साथ उस constraint को कॉन्फ़िगर करते हैं।
सामान्य उपयोग के मामले
डोमेन के आधार पर संसाधन साझा करने को सीमित करें।
Identity and Access Management सेवा खातों के उपयोग को सीमित करें।
नए बनाए गए संसाधनों के भौतिक स्थान को प्रतिबंधित करें।
सेवा खाता निर्माण को अक्षम करें
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F1773225330-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FvYvsXQ9SrLWOiw1tUeAK%252Fuploads%252Fgit-blob-b3d7695b6893be5eb50b87934be4f0e2bcc6736f%252Fimage%2520%28172%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=df9b2a9&sv=1)
कई और constraints हैं जो आपके संगठन के संसाधनों पर सूक्ष्म नियंत्रण प्रदान करते हैं। अधिक जानकारी के लिए, सभी Organization Policy Service constraints की सूची देखें।
Default Organization Policies
IAM Roles
ये AWS में IAM नीतियों की तरह हैं क्योंकि प्रत्येक भूमिका में अनुमतियों का एक सेट होता है।
हालांकि, AWS के विपरीत, यहाँ कोई केंद्रीकृत रिपॉजिटरी नहीं है। इसके बजाय, संसाधन Y प्रिंसिपल्स को X एक्सेस भूमिकाएँ देते हैं, और किसी संसाधन तक किसके पास पहुँच है, यह जानने का एकमात्र तरीका है उस संसाधन पर get-iam-policy
विधि का उपयोग करना।
यह एक समस्या हो सकती है क्योंकि इसका मतलब है कि किस प्रिंसिपल के पास कौन सी अनुमतियाँ हैं, यह जानने का एकमात्र तरीका है कि हर संसाधन से पूछें कि वह किसे अनुमतियाँ दे रहा है, और एक उपयोगकर्ता के पास सभी संसाधनों से अनुमतियाँ प्राप्त करने की अनुमति नहीं हो सकती है।
IAM में तीन प्रकार की भूमिकाएँ हैं:
Basic/Primitive roles, जिनमें Owner, Editor, और Viewer भूमिकाएँ शामिल हैं जो IAM के परिचय से पहले मौजूद थीं।
Predefined roles, जो एक विशिष्ट सेवा के लिए सूक्ष्म पहुँच प्रदान करते हैं और Google Cloud द्वारा प्रबंधित होते हैं। बहुत सारी predefined roles हैं, आप उनके पास मौजूद विशेषाधिकारों के साथ सभी को यहाँ देख सकते हैं।
Custom roles, जो उपयोगकर्ता-निर्दिष्ट अनुमतियों की सूची के अनुसार सूक्ष्म पहुँच प्रदान करते हैं।
GCP में हजारों अनुमतियाँ हैं। यह जांचने के लिए कि क्या किसी भूमिका में कोई अनुमति है, आप यहाँ अनुमति खोज सकते हैं और देख सकते हैं कि किन भूमिकाओं में यह है।
आप यहाँ प्रत्येक उत्पाद द्वारा पेश की गई predefined roles भी खोज सकते हैं। ध्यान दें कि कुछ भूमिकाएँ उपयोगकर्ताओं से जुड़ी नहीं हो सकती हैं और केवल SAs से क्योंकि उनमें कुछ अनुमतियाँ होती हैं। इसके अलावा, ध्यान दें कि अनुमतियाँ केवल तभी प्रभावी होंगी जब वे संबंधित सेवा से जुड़ी हों।
या जांचें कि क्या कोई कस्टम भूमिका यहाँ किसी विशिष्ट अनुमति का उपयोग कर सकती है।
GCP - IAM, Principals & Org Policies EnumUsers
GCP कंसोल में कोई Users या Groups प्रबंधन नहीं है, यह Google Workspace में किया जाता है। हालाँकि आप Google Workspace में एक अलग पहचान प्रदाता को सिंक्रनाइज़ कर सकते हैं।
आप Workspaces उपयोगकर्ताओं और समूहों तक पहुँच सकते हैं https://admin.google.com।
MFA को Workspaces उपयोगकर्ताओं पर मजबूर किया जा सकता है, हालाँकि, एक हमलावर GCP के माध्यम से cli का उपयोग करके एक टोकन का उपयोग कर सकता है जो MFA द्वारा संरक्षित नहीं होगा (यह केवल तब संरक्षित होगा जब उपयोगकर्ता इसे उत्पन्न करने के लिए लॉगिन करता है: gcloud auth login
)।
Groups
जब एक संगठन बनाया जाता है तो कई समूहों को मजबूती से बनाने का सुझाव दिया जाता है। यदि आप इनमें से किसी का प्रबंधन करते हैं तो आपने पूरे या संगठन के एक महत्वपूर्ण हिस्से से समझौता किया हो सकता है:
Group | Function |
| संगठन से संबंधित किसी भी संसाधन का प्रशासन करना। इस भूमिका को कम से कम असाइन करें; org admins को आपके सभी Google Cloud संसाधनों तक पहुँच प्राप्त है। वैकल्पिक रूप से, क्योंकि यह कार्य अत्यधिक विशेषाधिकार प्राप्त है, समूह बनाने के बजाय व्यक्तिगत खातों का उपयोग करने पर विचार करें। |
| नेटवर्क, सबनेट, फ़ायरवॉल नियम, और नेटवर्क उपकरण जैसे Cloud Router, Cloud VPN, और cloud load balancers बनाना। |
| बिलिंग खातों की स्थापना और उनके उपयोग की निगरानी करना। |
| एप्लिकेशन डिज़ाइन करना, कोडिंग करना, और परीक्षण करना। |
| संपूर्ण संगठन के लिए सुरक्षा नीतियों की स्थापना और प्रबंधन करना, जिसमें एक्सेस प्रबंधन और organization constraint policies शामिल हैं। अपने Google Cloud सुरक्षा बुनियादी ढांचे की योजना बनाने के बारे में अधिक जानकारी के लिए Google Cloud सुरक्षा नींव गाइड देखें। |
| निरंतर एकीकरण और वितरण, निगरानी, और सिस्टम प्रावधान का समर्थन करने वाले एंड-टू-एंड पाइपलाइनों का निर्माण या प्रबंधन करना। |
| |
| |
| |
| प्रोजेक्ट्स पर खर्च की निगरानी करना। विशिष्ट सदस्य वित्त टीम का हिस्सा होते हैं। |
| Google Cloud संगठन में संसाधन जानकारी की समीक्षा करना। |
| क्लाउड सुरक्षा की समीक्षा करना। |
| नेटवर्क कॉन्फ़िगरेशन की समीक्षा करना। |
| ऑडिट लॉग्स देखना। |
| Security Command Center का प्रशासन करना। |
| Secret Manager में रहस्यों का प्रबंधन करना। |
Default Password Policy
मजबूत पासवर्ड लागू करें
8 से 100 वर्णों के बीच
पुन: उपयोग नहीं
समाप्ति नहीं
यदि लोग Workspace के माध्यम से किसी तृतीय पक्ष प्रदाता के माध्यम से पहुँच रहे हैं, तो ये आवश्यकताएँ लागू नहीं होती हैं।
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F1773225330-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FvYvsXQ9SrLWOiw1tUeAK%252Fuploads%252Fgit-blob-67281e0416106a097667451f548ff3dd8d4bfebc%252Fimage%2520%2820%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=d325e0ed&sv=1)
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F1773225330-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FvYvsXQ9SrLWOiw1tUeAK%252Fuploads%252Fgit-blob-4ba6ea2ef11e65869fbe82ce2383c74ac7c95918%252Fimage%2520%2822%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=ee42455a&sv=1)
Service accounts
ये वे प्रिंसिपल्स हैं जिन्हें संसाधनों के साथ संलग्न किया जा सकता है और GCP के साथ आसानी से इंटरैक्ट करने के लिए एक्सेस प्राप्त कर सकते हैं। उदाहरण के लिए, एक Service Account संलग्न VM के मेटाडेटा में auth token तक पहुँचना संभव है।
जब IAM और access scopes दोनों का उपयोग करते समय कुछ संघर्ष हो सकते हैं। उदाहरण के लिए, आपके सेवा खाते में compute.instanceAdmin
की IAM भूमिका हो सकती है लेकिन जिस instance को आपने breached किया है उसे https://www.googleapis.com/auth/compute.readonly
के scope प्रतिबंध के साथ crippled किया गया है। यह आपको आपके instance को स्वचालित रूप से असाइन किए गए OAuth token का उपयोग करके कोई भी परिवर्तन करने से रोक देगा।
यह AWS से IAM roles के समान है। लेकिन AWS के विपरीत, कोई भी सेवा खाता किसी भी सेवा से संलग्न किया जा सकता है (इसके लिए इसे नीति के माध्यम से अनुमति देने की आवश्यकता नहीं है)।
कई सेवा खाते जो आप पाएंगे वास्तव में GCP द्वारा स्वचालित रूप से उत्पन्न किए गए हैं जब आप किसी सेवा का उपयोग करना शुरू करते हैं, जैसे:
हालांकि, यह भी संभव है कि संसाधनों के लिए custom service accounts बनाए और संलग्न किए जाएं, जो इस प्रकार दिखेंगे:
Access scopes
Access scope उत्पन्न OAuth tokens को GCP API endpoints तक पहुँचने के लिए संलग्न किए जाते हैं। ये OAuth token की अनुमतियों को प्रतिबंधित करते हैं। इसका मतलब है कि अगर एक token किसी resource के Owner का है लेकिन उस resource तक पहुँचने के लिए token scope में नहीं है, तो token का उपयोग उन विशेषाधिकारों को (ab)use करने के लिए नहीं किया जा सकता।
Google वास्तव में सिफारिश करता है कि access scopes का उपयोग न किया जाए और पूरी तरह से IAM पर निर्भर रहें। वेब प्रबंधन पोर्टल वास्तव में इसे लागू करता है, लेकिन access scopes को कस्टम service accounts का प्रोग्रामेटिक रूप से उपयोग करके instances पर अभी भी लागू किया जा सकता है।
आप देख सकते हैं कि scopes को कैसे असाइन किया गया है querying:
पूर्ववर्ती स्कोप्स वे हैं जो डिफ़ॉल्ट रूप से gcloud
का उपयोग करके डेटा तक पहुंचने के लिए उत्पन्न होते हैं। ऐसा इसलिए है क्योंकि जब आप gcloud
का उपयोग करते हैं, तो आप पहले एक OAuth टोकन बनाते हैं, और फिर इसका उपयोग एंडपॉइंट्स से संपर्क करने के लिए करते हैं।
उनमें से सबसे महत्वपूर्ण स्कोप संभावित रूप से cloud-platform
है, जिसका मूल रूप से मतलब है कि GCP में किसी भी सेवा तक पहुंचना संभव है।
आप यहां सभी संभावित स्कोप्स की सूची पा सकते हैं।
यदि आपके पास gcloud
ब्राउज़र क्रेडेंशियल्स हैं, तो यह अन्य स्कोप्स के साथ एक टोकन प्राप्त करना संभव है, कुछ इस तरह से:
Terraform IAM Policies, Bindings and Memberships
जैसा कि terraform द्वारा https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam में परिभाषित किया गया है, GCP के साथ terraform का उपयोग करते समय किसी संसाधन पर एक प्रमुख को एक्सेस देने के विभिन्न तरीके हैं:
Memberships: आप बिना किसी प्रतिबंध के भूमिकाओं के सदस्यों के रूप में प्रमुखों को सेट करते हैं। आप एक उपयोगकर्ता को एक भूमिका के सदस्य के रूप में रख सकते हैं और फिर एक समूह को उसी भूमिका के सदस्य के रूप में रख सकते हैं और उन प्रमुखों (उपयोगकर्ता और समूह) को अन्य भूमिकाओं के सदस्य के रूप में भी सेट कर सकते हैं।
Bindings: कई प्रमुखों को एक भूमिका से बांधा जा सकता है। वे प्रमुख अभी भी अन्य भूमिकाओं के सदस्य या बंधे हो सकते हैं। हालाँकि, यदि कोई प्रमुख जो भूमिका से बंधा नहीं है, उसे बंधी हुई भूमिका के सदस्य के रूप में सेट किया जाता है, तो अगली बार जब बाइंडिंग लागू की जाती है, तो सदस्यता गायब हो जाएगी।
Policies: एक नीति प्राधिकारी होती है, यह भूमिकाओं और प्रमुखों को इंगित करती है और फिर, वे प्रमुख अधिक भूमिकाएँ नहीं ले सकते और वे भूमिकाएँ अधिक प्रमुख नहीं ले सकतीं जब तक कि उस नीति को संशोधित नहीं किया जाता (यहां तक कि अन्य नीतियों, बाइंडिंग्स या सदस्यताओं में भी नहीं)। इसलिए, जब किसी नीति में कोई भूमिका या प्रमुख निर्दिष्ट होता है तो उसके सभी विशेषाधिकार उस नीति द्वारा सीमित होते हैं। जाहिर है, यदि प्रमुख को नीति को संशोधित करने या विशेषाधिकार वृद्धि अनुमतियों का विकल्प दिया जाता है (जैसे कि एक नया प्रमुख बनाना और उसे एक नई भूमिका से बांधना), तो इसे बायपास किया जा सकता है।
References
AWS Hacking सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें और अभ्यास करें:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated