---
title: "GCP सुरक्षा सुदृढ़ीकरण चेकलिस्ट | Snow Tree"
url: "https://www.snow-tree.com/hi/gcp-security-hardening/"
---

सुरक्षित GCP अवसंरचना

# छोटी और मध्यम आकार की टीमों के लिए GCP सुरक्षा सुदृढ़ीकरण चेकलिस्ट

उन टीमों के लिए एक व्यावहारिक आधार, जो बिना समर्पित सुरक्षा विभाग के Google Cloud पर उत्पादन वर्कलोड चलाती हैं। वहाँ से शुरू करें जहाँ किसी गंभीर घटना के सबसे संभावित रास्तों को कम करना सबसे आसान है।

## इस पेज पर

1. [GCP में खतरे के आम रास्ते](https://www.snow-tree.com/hi/#threat-paths)
2. [पहचान और पहुँच](https://www.snow-tree.com/hi/#identity)
3. [नेटवर्क और एज](https://www.snow-tree.com/hi/#network)
4. [डेटा और सीक्रेट](https://www.snow-tree.com/hi/#data)
5. [GKE सुदृढ़ीकरण](https://www.snow-tree.com/hi/#gke)
6. [पता लगाना और पुनर्प्राप्ति](https://www.snow-tree.com/hi/#detection)
7. [30, 60 और 90 दिनों की प्राथमिकता-आधारित चेकलिस्ट](https://www.snow-tree.com/hi/#checklist)
8. [आधिकारिक संदर्भ](https://www.snow-tree.com/hi/#references)

## GCP में खतरे के आम रास्ते

ज़्यादातर क्लाउड घटनाएँ स्वामित्व या कॉन्फ़िगरेशन में किसी छोटी-सी कमी से शुरू होती हैं। किसी हमलावर से पहले आप इन रास्तों को खोजें।

- ज़रूरत से ज़्यादा अनुमतियों वाला उपयोगकर्ता, सेवा खाता या वर्कलोड पहचान एक चुराए गए क्रेडेंशियल को कई प्रोजेक्ट में व्यापक पहुँच में बदल सकती है।
- खुला छोड़ा गया प्रबंधन एंडपॉइंट, डिबग पोर्ट या ढीला फ़ायरवॉल नियम सामान्य ऐप्लिकेशन ट्रैफ़िक के लिए बनाए गए हर नियंत्रण को बायपास कर सकता है।
- सार्वजनिक स्टोरेज बकेट या ज़रूरत से ज़्यादा व्यापक हस्ताक्षरित URL, ऐप्लिकेशन में किसी दिखाई देने वाली सेंध के बिना ही ग्राहक डेटा उजागर कर सकता है।
- जब पुरानी इमेज, भुला दिए गए नेमस्पेस, अप्रयुक्त सेवा खाते और बिना मालिक वाले संसाधन अब भी परिनियोजित किए जा सकते हैं, तो पुराने वर्कलोड लंबे समय तक बना रहने वाला जोखिम पैदा करते हैं।
- ऑडिट साक्ष्य न होने या उनके कम समय तक रखे जाने से यह पहचानना मुश्किल हो जाता है कि नीति किसने बदली, पहुँच कब शुरू हुई और किस डेटा तक पहुँचा गया।
- बिना परखा गया बैकअप सिर्फ़ एक उम्मीद है। रीस्टोर की विफलताएँ, अधूरा प्रतिधारण और पहुँच से बाहर एन्क्रिप्शन कुंजियाँ किसी सुरक्षा घटना को स्थायी नुकसान में बदल सकती हैं।

## पहचान और पहुँच

पहचान को प्राथमिक कंट्रोल प्लेन मानें। हर व्यक्ति, ऑटोमेशन प्रक्रिया और वर्कलोड की सीमित उद्देश्य वाली एक अलग पहचान होनी चाहिए।

### संसाधन सीमा स्पष्ट करें

सुरक्षा सीमाओं के लिए संगठन और फ़ोल्डर का उपयोग करें, और विकास, स्टेजिंग और उत्पादन को अलग-अलग प्रोजेक्ट या अधिक मज़बूत भरोसे की सीमाओं में बाँटें। संगठन नीतियाँ व्यावहारिक रूप से संभव सबसे ऊँचे स्तर पर लागू करें, सेवाओं के उपयोग को सीमित करें, और असंबंधित उत्पादों के बीच उत्पादन प्रोजेक्ट साझा करने से बचें।

### सबसे सीमित दायरे में न्यूनतम भूमिका दें

व्यापक प्रिमिटिव भूमिकाओं के बजाय पहले से तय या कस्टम भूमिकाओं को प्राथमिकता दें, उन्हें समूहों और वर्कलोड पहचानों को दें, और जहाँ संसाधन का नाम या टैग पहुँच को सीमित कर सके, वहाँ IAM शर्तों का उपयोग करें। अप्रयुक्त अनुमतियों की समीक्षा करें और उत्पादन तक उस स्थायी पहुँच को हटाएँ जो केवल ब्रेक-ग्लास प्रक्रिया के लिए होनी चाहिए।

### लंबे समय तक मान्य रहने वाले क्रेडेंशियल हटाएँ

Workload Identity Federation for GKE का उपयोग करें, ताकि पॉड को निर्यात की गई सेवा-खाता कुंजियों के बिना अल्पकालिक क्रेडेंशियल मिलें। जहाँ संभव हो, संगठन नीति से कुंजी बनाने और अपलोड करने को ब्लॉक करें, बची हुई सभी कुंजियों की सूची बनाएँ, और Cloud Audit Logs में उच्च जोखिम वाले IAM बदलावों पर अलर्ट सेट करें।

## नेटवर्क और एज

मानकर चलें कि ऐप्लिकेशन की कोई न कोई खामी आख़िरकार नेटवर्क से पहुँच में आ जाएगी। सीमित करें कि वह खामी किन चीज़ों तक पहुँच सकती है।

### इनकार से प्रारंभ करें और नामित पथ जोड़ें

पॉड ट्रैफ़िक के लिए न्यूनतम विशेषाधिकार वाले VPC फ़ायरवॉल नियमों और Kubernetes NetworkPolicies का उपयोग करें। वातावरणों को अलग-अलग नेटवर्क में बाँटें, हर इनग्रेस पथ का दस्तावेज़ बनाएँ, और ऐसे व्यापक डिबग नियम हटाएँ जो बड़ी IP पता रेंज से प्रबंधन पोर्ट या सभी प्रोटोकॉल की अनुमति देते हैं।

### नोड और कंट्रोल प्लेन को निजी रखें

GKE नोड पर बाहरी IP पते बंद करें। DNS-आधारित निजी कंट्रोल प्लेन एंडपॉइंट को प्राथमिकता दें, और जब IP एंडपॉइंट से बचा न जा सके, तो उसे अधिकृत नेटवर्क से सीमित करें। वर्कलोड को व्यापक इंटरनेट पहुँच देने के बजाय सोच-समझकर तय किया गया ईग्रेस पथ दें।

### केवल सोच-समझकर तय की गई सार्वजनिक सेवाएँ प्रकाशित करें

ऐप्लिकेशन को संयोग से उपलब्ध पॉड या नोड पतों के बजाय समीक्षा किए गए गेटवे या लोड बैलेंसर के माध्यम से उपलब्ध कराएँ। प्रबंधित प्रमाणपत्रों पर TLS टर्मिनेट करें, इनग्रेस होस्ट और पथ सीमित करें, अनुरोध और दर सीमाएँ लागू करें, और प्रशासन इंटरफ़ेस को पहचान-आधारित पहुँच नियंत्रण के पीछे रखें।

## डेटा और सीक्रेट

संग्रहीत, ट्रांज़िट में और उपयोग में मौजूद डेटा को सुरक्षित रखें, फिर साबित करें कि आप उसे पुनर्प्राप्त कर सकते हैं। डेटा की खोज भी नियंत्रण का हिस्सा है।

### आकस्मिक सार्वजनिक पहुंच को रोकें

Cloud Storage पर सार्वजनिक पहुंच रोकथाम और समान बकेट-स्तरीय पहुंच लागू करें। संवेदनशीलता के आधार पर बकेट को वर्गीकृत करें, ऑब्जेक्ट और कुंजी पहुंच को प्रतिबंधित करें, उच्च-मूल्य डेटा के लिए लॉगिंग सक्षम करें, और ग्राहक-प्रबंधित एन्क्रिप्शन कुंजियों का उपयोग करें जहां आपके जोखिम या अनुपालन मॉडल को उनकी आवश्यकता होती है।

### सीक्रेट को इमेज और सोर्स कोड से बाहर रखें

क्रेडेंशियल Secret Manager में संग्रहीत करें और किसी विशिष्ट वर्कलोड पहचान को किसी विशिष्ट सीक्रेट वर्शन तक पहुँच दें। सीक्रेट को सोच-समझकर रोटेट करें, उन्हें Git या कंटेनर इमेज में कॉपी करने से बचें, और सामान्य Kubernetes Secrets को पूरी सुरक्षा सीमा न मानें।

### पुनर्प्राप्ति का परीक्षण करें, न कि केवल बैकअप निर्माण का

पुनर्प्राप्ति बिंदु और पुनर्प्राप्ति समय के लक्ष्य तय करें, प्रतियाँ उत्पादन फ़ेल्योर डोमेन के बाहर रखें, और बैकअप तथा एन्क्रिप्शन कुंजी तक पहुँच को वर्कलोड पहचान से सुरक्षित रखें। तय समय-सारिणी पर किसी अलग-थलग वातावरण में रीस्टोर करें, डेटा सत्यापित करें, और लगा हुआ समय तथा सभी मैन्युअल चरण दर्ज करें।

## GKE सुदृढ़ीकरण

GKE प्रबंधित कंट्रोल प्लेन को सुरक्षित करता है, लेकिन आपके क्लस्टर का कॉन्फ़िगरेशन, नेमस्पेस, एडमिशन नीतियाँ और वर्कलोड नियंत्रित करना आपकी ही ज़िम्मेदारी रहती है।

### नेमस्पेस को अलगाव का अनुबंध बनाएँ

टीमों और वातावरणों को अलग-अलग नेमस्पेस या क्लस्टर में बाँटें, वहाँ सीमित Kubernetes RBAC भूमिकाएँ बाइंड करें, और संसाधन कोटा तथा NetworkPolicies लागू करें। ऐप्लिकेशन डिलीवरी के लिए पूरे क्लस्टर में लिखने की पहुँच देने से बचें, और जब किसी वर्कलोड को अलग पहचान चाहिए, तो उसे उसका अपना सेवा खाता दें।

### केवल उन्हीं इमेज और कॉन्फ़िगरेशन को स्वीकार करें जिन पर आपको भरोसा है

प्रतिबंधित Pod Security मानक या उसके समकक्ष Policy Controller नियम लागू करें। इमेज को अपरिवर्तनीय डाइजेस्ट से परिनियोजित करें, उन्हें कमज़ोरियों के लिए स्कैन करें, जहाँ उत्पत्ति मायने रखती है वहाँ Binary Authorization का उपयोग करें, और अनपेक्षित होस्ट पहुँच, विशेषाधिकार वृद्धि और cluster-admin बाइंडिंग को अस्वीकार करें।

### कंटेनर के अनावश्यक अधिकार हटाएँ

गैर-रूट उपयोगकर्ता के रूप में चलाएँ, Linux कैपेबिलिटीज़ हटाएँ, जहाँ संभव हो केवल-पढ़ने योग्य रूट फ़ाइल सिस्टम का उपयोग करें, और RuntimeDefault seccomp प्रोफ़ाइल लागू करें। ज़रूरत न हो तो सेवा-खाता टोकन माउंट न करें, विशेषाधिकार प्राप्त मोड और होस्ट नेमस्पेस से बचें, नोड सेवा खाते की अनुमतियाँ न्यूनतम रखें, और Shielded Nodes के साथ Container-Optimized OS का उपयोग करें।

## पता लगाना और पुनर्प्राप्ति

नियंत्रण विफल होते हैं। इस भरोसे पर नहीं कि किसी ने गलती नहीं की, बल्कि साक्ष्य और पहले से अभ्यास की गई कार्रवाइयों पर निर्भर रहें।

### आपको जिन साक्ष्यों की आवश्यकता होगी उन्हें एकत्रित करें

Cloud Audit Logs और GKE के सिस्टम व वर्कलोड लॉग एक केंद्रीय गंतव्य में रखें, और उनका प्रतिधारण आपकी जाँच की ज़रूरतों के अनुरूप रखें। संवेदनशील डेटा के लिए डेटा ऐक्सेस ऑडिट लॉग चुनिंदा रूप से सक्षम करें, लॉग तक पहुँच सीमित करें, और IAM, फ़ायरवॉल, स्टोरेज और क्लस्टर कॉन्फ़िगरेशन में होने वाले प्रशासनिक बदलाव दर्ज करें।

### सुरक्षा के लिहाज़ से अहम बदलावों पर अलर्ट करें

इन पर अलर्ट करें: सार्वजनिक स्टोरेज का उजागर होना, व्यापक फ़ायरवॉल या IAM बदलाव, अनपेक्षित सेवा-खाता कुंजियाँ, एडमिशन अस्वीकृतियाँ, कंट्रोल प्लेन का उजागर होना, बार-बार प्रमाणीकरण विफलताएँ, बंद की गई लॉगिंग, विफल बैकअप और समाप्त होने वाले प्रमाणपत्र। हर अलर्ट को उसके मालिक तक भेजें, साथ में उसकी पुष्टि करने या उसे खारिज करने के चरण भी दें।

### प्रतिक्रिया का पूर्वाभ्यास करें

लीक हुए क्रेडेंशियल, सार्वजनिक हो गए डेटा, सेंध लगे वर्कलोड और खोए हुए क्षेत्रों या प्रोजेक्ट के लिए छोटी रनबुक लिखें। उनमें बताएँ कि घटना को सीमित करने की कार्रवाई को कौन अधिकृत कर सकता है, पहुँच कैसे रद्द करें, साक्ष्य कैसे सुरक्षित रखें और सेवा कैसे बहाल करें। रनबुक का परीक्षण उन्हीं लोगों के साथ करें जो उनका उपयोग करेंगे।

## 30, 60 और 90 दिनों की प्राथमिकता-आधारित चेकलिस्ट

यदि आप अधूरी आधार रेखा से शुरुआत कर रहे हैं, तो पहले एक्सपोज़र को कम करने और बाद की समीक्षाओं को दोहराने योग्य बनाने के लिए कार्य को अनुक्रमित करें।

### दिन 1 से 30: स्पष्ट रास्तों को रोकें

प्रोजेक्ट और उनके मालिकों की सूची बनाएँ, अप्रयुक्त और लंबे समय तक मान्य क्रेडेंशियल हटाएँ, ऑडिट लॉगिंग की पुष्टि करें, सार्वजनिक बकेट ब्लॉक करें, सबसे व्यापक फ़ायरवॉल नियमों और IAM अनुमतियों की समीक्षा करें, उत्पादन बैकअप की कमियाँ पहचानें, और बिना मालिक वाले किसी भी सार्वजनिक एंडपॉइंट को ठीक करें। हर निष्कर्ष के लिए एक मालिक और नियत तिथि तय करें।

### दिन 31 से 60: आधार रेखा को दोहराने योग्य बनाएं

नेटवर्क, पहचान और वर्कलोड कॉन्फ़िगरेशन को समीक्षा किए गए इन्फ़्रास्ट्रक्चर ऐज़ कोड और GitOps डिलीवरी में ले जाएँ। Workload Identity, निजी नोड, प्रतिबंधित Pod Security, भरोसेमंद इमेज की जाँच, केंद्रीकृत लॉग और सबसे अहम बदलावों के लिए अलर्ट अपनाएँ।

### दिन 61 से 90: इसे सिद्ध करें और कायम रखें

रीस्टोर परीक्षण और घटना प्रतिक्रिया का एक टेबलटॉप अभ्यास करें, विशेषाधिकार प्राप्त पहुँच और अपवादों की समाप्ति की समीक्षा करें, इमेज और निर्भरताओं को फिर से स्कैन करें, सत्यापित करें कि मालिकों को अलर्ट मिलते हैं, और बची हुई कमियों को मापें। साक्ष्य पुराने पड़ने से पहले इन जाँचों को नियमित समीक्षा चक्र में शामिल करें।

इस चेकलिस्ट को शुरुआती बिंदु के रूप में उपयोग करें। Snow Tree प्रबंधित प्लेटफ़ॉर्म संचालन या केंद्रित परामर्श कार्य के माध्यम से यह आधार लागू कर सकती है।

[प्रबंधित प्लेटफ़ॉर्म](https://www.snow-tree.com/hi/managed-platform/) [परामर्श](https://www.snow-tree.com/hi/consulting/)

## आधिकारिक संदर्भ

जब प्लेटफ़ॉर्म डिफ़ॉल्ट या उत्पाद क्षमताएँ बदलें, तब Google के मौजूदा मार्गदर्शन को प्रामाणिक तकनीकी स्रोत मानें।

- [Google Cloud: अपने GKE क्लस्टर के सुदृढ़ीकरण की सर्वोत्तम प्रथाएँ](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster)
- [Google Cloud: GKE सुरक्षा संबंधी सर्वोत्तम प्रथाएं](https://docs.cloud.google.com/docs/security/gke-security-bps)

प्रबंधित प्लेटफ़ॉर्म

## सॉफ़्टवेयर बनवाने, होस्ट कराने और चलाने की ज़िम्मेदारी Snow Tree को दें।

[परियोजना शुरू करें](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)