प्रॉम्प्ट और संदर्भ
मल्टी-टेनेंट प्लेटफ़ॉर्म की एक रीड-ओनली API key सार्वजनिक रिपॉजिटरी में कमिट हो जाती है। यह संभव है कि की (key) कॉपी कर ली गई हो, और कॉलर 200 ऐसी सेवाओं में फैले हुए हैं जिन्हें तुरंत बंद नहीं किया जा सकता। हर स्वस्थ टेनेंट को ऑफ़लाइन किए बिना अटैक विंडो को कम से कम करने के लिए डिटेक्शन, अलर्टिंग, रेवोकेशन, प्रभाव विश्लेषण, रोटेशन और सत्यापन डिज़ाइन करें।
यह बैकएंड, सुरक्षा-इंजीनियरिंग (security-engineering) और प्लेटफ़ॉर्म-इंजीनियरिंग भूमिकाओं के लिए एक लाइफ़साइकिल और इंसिडेंट-हैंडलिंग प्रश्न है। रीड-ओनली स्कोप, 200 कॉलर्स और सब कुछ तुरंत बंद करने में असमर्थता इंटरव्यू के अनुमान हैं, न कि उद्योग के बेंचमार्क। एक्सपोज़र को एक अवलोकनीय (observable) सुरक्षा घटना मानने, डिटेक्शन को पहले चरण में लाने, रेवोकेशन को प्रोपेगेट करने, प्रभाव को सीमित करने और रिकवरी को ऑर्केस्ट्रेट करने पर ध्यान केंद्रित करें। आपको एक संपूर्ण क्रिप्टोग्राफ़िक की-मैनेजमेंट प्लेटफ़ॉर्म डिज़ाइन करने की आवश्यकता नहीं है।
इंटरव्यूअर क्या जांच रहा है
पहला, क्या आप "टेक्स्ट एक की जैसा दिखता है" और "क्रेडेंशियल मान्य (valid) है" के बीच अंतर कर सकते हैं? एक regex या प्रोवाइडर फ़िंगरप्रिंट एक उम्मीदवार (candidate) बनाता है; एक प्रतिबंधित सत्यापन पथ (validation path), स्थिति लुकअप या आंतरिक मेटाडेटा को सीक्रेट को प्रिंट किए बिना इसकी पुष्टि करनी चाहिए।
दूसरा, क्या आप रोकथाम, डिटेक्शन और रिस्पॉन्स को आपस में जोड़ सकते हैं? Pre-commit या पुश प्रोटेक्शन रिपॉजिटरी में प्रविष्टि को कम करता है, ऐतिहासिक और सार्वजनिक-रिपॉजिटरी स्कैन छूटे हुए मामलों को पकड़ते हैं, की-सर्विस रीवोक करती है, रिक्वेस्ट लॉग प्रभाव विश्लेषण में सहायता करते हैं और डिप्लॉयमेंट सिस्टम कॉलर्स को रोटेट करते हैं।
तीसरा, क्या आप रेवोकेशन सेमेंटिक्स को परिभाषित कर सकते हैं? डेटाबेस स्थिति बदलने से एज कैश तुरंत रिजेक्ट नहीं करने लगता, और न ही यह किसी हमलावर द्वारा पहले से कॉपी किए गए स्टैटिक क्रेडेंशियल को अमान्य करता है। एक सशक्त उत्तर एक प्रोपेगेशन लक्ष्य, कैश नीति और डाउनस्ट्रीम रोटेशन क्रम को निर्दिष्ट करता है।
अंत में, क्या आप सुरक्षा बनाम निरंतरता का एक सीमित विकल्प चुन सकते हैं: पूरे टेनेंट के बजाय केवल की को रीवोक करना, नियमित रोटेशन के लिए एक छोटी डुअल-की विंडो की अनुमति देना लेकिन एक्सपोज़र के बाद डिफ़ॉल्ट रूप से नहीं, और हर कदम को ऑडिट योग्य, पुनः प्रयास योग्य (retryable) और प्रतिवर्ती (reversible) बनाना?
पहले स्पष्ट करने योग्य प्रश्न
- यह कौन सा क्रेडेंशियल है: रीड-ओनली API key, राइट key, क्लाउड क्रेडेंशियल या यूज़र टोकन? स्कोप के आधार पर ब्लास्ट रेडियस और प्राथमिकताएं बदलती हैं।
- यह कहां एक्सपोज़ हुआ था: सार्वजनिक रिपॉजिटरी, निजी रिपॉजिटरी, लॉग, चैट या कोई आर्टिफ़ैक्ट? क्या इतिहास मिरर किया गया है या अभी भी सुलभ है?
- जोखिम भरी व्यावसायिक कॉल किए बिना वैधता की पुष्टि कैसे की जा सकती है?
- क्या रेवोकेशन का अर्थ सेकंडों के भीतर नए अनुरोधों को अस्वीकार करना है, या डाउनस्ट्रीम सिस्टम में पुराने क्रेडेंशियल को भी अमान्य करना है?
- क्या 200 सेवाएं डिप्लॉयमेंट, कॉन्फ़िगरेशन, साइडकार या सीक्रेट्स-मैनेजर पाथ साझा करती हैं? कौन सी स्वचालित रूप से अपडेट नहीं हो सकती हैं?
- क्या टेनेंट एक छोटी डुअल-की विंडो सहन कर सकता है? किन राइट्स को तुरंत रोकना होगा, और कौन से रीड्स सुरक्षित रूप से डिग्रेड हो सकते हैं?
- कौन से साक्ष्य सुरक्षित रखे जाने चाहिए, और कौन अपवाद या ब्रेक-ग्लास कार्रवाई को मंज़ूरी दे सकता है?
30-सेकंड का उत्तर
"मैं उम्मीदवार को संभावित रूप से एक्सपोज़ मानूंगा और स्कैनर से सीक्रेट को कभी प्रदर्शित नहीं करूंगा। मैं क्रेडेंशियल, स्कोप, टेनेंट और अंतिम उपयोग की पहचान करूंगा, उच्च जोखिम वाले एक्सेस को तुरंत रीवोक या सीमित करूंगा, और हर गेटवे को एक मापने योग्य प्रोपेगेशन लक्ष्य को पूरा करने के लिए बाध्य करूंगा। फिर मैं समय सीमा, रूट्स और संदिग्ध स्रोतों को सीमित करने के लिए रिक्वेस्ट लॉग का उपयोग करूंगा; सीक्रेट्स मैनेजर के माध्यम से एक प्रतिस्थापन बनाऊंगा; इसे बैचों में रोल आउट करूंगा; और उपयोग का निरीक्षण करने के बाद पुरानी की को रिटायर कर दूंगा। पुश ब्लॉकिंग, ऐतिहासिक स्कैन, रिक्वेस्ट ऑडिटिंग और रोटेशन अभ्यास एक स्थायी लूप बनाते हैं। केवल एक सिद्ध रूप से अमान्य फ़ॉल्स पॉज़िटिव ही ऑडिट किए गए अपवाद पथ में जाना चाहिए।"
चरण-दर-चरण उत्तर
चरण 1: इंसिडेंट की स्थितियां और साक्ष्य सीमा स्थापित करें
detected → triaged → contained → rotated → verified → closed का मॉडल बनाएं। प्रत्येक ट्रांज़िशन एक इंसिडेंट ID, सार्वजनिक क्रेडेंशियल पहचानकर्ता, टेनेंट, स्रोत, स्कोप, समय और ओनर को रिकॉर्ड करता है। स्कैनर हैश, फ़िंगरप्रिंट और लोकेशन स्टोर करता है, पूरा सीक्रेट कभी नहीं; विश्लेषक एक अनुमति-प्राप्त आंतरिक वैलिडेशन पाथ का उपयोग करते हैं।
उम्मीदवार pre-commit स्कैनिंग, रिपॉजिटरी इतिहास, सार्वजनिक-रिपॉजिटरी इवेंट्स, CI लॉग, आर्टिफ़ैक्ट स्कैन या प्रोवाइडर सूचनाओं से आ सकते हैं। GitHub पुश प्रोटेक्शन पहचाने गए सीक्रेट्स वाले पुश को ब्लॉक करता है और बाईपास के लिए अलर्ट बनाता है। यह इतिहास में नई प्रविष्टियों को कम करता है लेकिन ऐतिहासिक स्कैनिंग या रनटाइम मॉनिटरिंग की जगह नहीं लेता है।
चरण 2: वैधता की पुष्टि करें और ब्लास्ट रेडियस की गणना करें
स्थानीय फ़िल्टरिंग के लिए प्रीफ़िक्स, लंबाई, चेकसम या प्रोवाइडर नियमों का उपयोग करें, फिर एक ऐसे वैलिडेशन एंडपॉइंट को कॉल करें जो सीक्रेट को उजागर न करे। रिस्पॉन्स valid, invalid, revoked, या unknown और सुरक्षित मेटाडेटा होना चाहिए। किसी स्कैनर को प्रोडक्शन राइट विशेषाधिकारों का उपयोग न करने दें; यदि वैलिडेशन आवश्यक है, तो रीड-ओनली, कम लागत वाले, पृथक (isolated) टेनेंट और ऑडिट मार्कर का उपयोग करें।
पुष्टि के बाद, स्कोप, टेनेंट, निर्माता, परिवेश, समाप्ति, अंतिम उपयोग और 200 सेवाओं के लिए निर्भरता सूची पढ़ें। खोज और रेवोकेशन के बीच के रिक्वेस्ट लॉग को क्वेरी करें। अज्ञात नेटवर्क, असामान्य क्षेत्रों, अप्रत्याशित रूट्स, अस्वीकृति स्पाइक्स और उच्च-मूल्य संसाधन रीड्स से सामान्य स्रोतों को अलग करें। लॉग में केवल सार्वजनिक की ID, टेनेंट और कोरिलेशन ID होती है, Authorization हेडर या सीक्रेट कभी नहीं।
चरण 3: पहले नियंत्रण करें, फिर माइग्रेशन की योजना बनाएं
उच्च-विशेषाधिकार, राइट या वित्तीय लेन-देन वाली कीज़ को पहले रीवोक करें। जब कोई दुरुपयोग न दिख रहा हो, तब भी रीड-ओनली की को एक्सपोज़्ड मानें। आधिकारिक रेवोकेशन स्थिति लिखें, इनवैलिडेशन इवेंट्स प्रकाशित करें, और खोए हुए इवेंट्स के लिए फ़ॉलबैक के रूप में एक छोटे गेटवे TTL का उपयोग करें। "सभी गेटवे पांच सेकंड के भीतर नए अनुरोधों को अस्वीकार करते हैं" जैसा लक्ष्य निर्धारित करें, फिर संदेश हानि, नोड पुनरारंभ और विभाजन का परीक्षण करें।
200 सेवाओं की सुविधा के लिए किसी एक्सपोज़्ड की को लंबी छूट अवधि (grace period) न दें। एक गैर-एक्सपोज़्ड नियमित रोटेशन डुअल-की विंडो का उपयोग कर सकता है; संदिग्ध लीक को पहले रीवोक किया जाता है। यदि आवश्यक हो, तो कम जोखिम वाला रीड एंडपॉइंट थोड़े समय के लिए सुरक्षित डिग्रेटेड परिणाम दे सकता है। डिग्रेडेशन से अधिक डेटा का खुलासा नहीं होना चाहिए या यह एक सफल राइट जैसा नहीं दिखना चाहिए।
चरण 4: एक ऑडिट योग्य बैच रोटेशन को ऑर्केस्ट्रेट करें
प्रति कॉलर एक स्वतंत्र प्रतिस्थापन उत्पन्न करें, जिसके पास पुरानी की से अधिक विशेषाधिकार न हों; अल्पकालिक (short-lived) या वर्कलोड पहचान (workload identity) को प्राथमिकता दें। इसे एक साझा सीक्रेट्स मैनेजर या डिप्लॉयमेंट कॉन्फ़िगरेशन के माध्यम से बैचों में डिलीवर करें: पहले एक छोटा कैनरी, फिर सेवा समूह। प्रत्येक सेवा prepared → deployed → observed → old-revoked जैसी एक इडेम्पोटेंट स्टेट मशीन का पालन करती है; पुनः प्रयासों (retries) से असीमित कीज़ नहीं बननी चाहिए या पुरानी की को फिर से सक्रिय नहीं किया जाना चाहिए।
Stripe एक्सपोज़र के तुरंत बाद रोटेट करने की सलाह देता है, भले ही आप यह साबित न कर सकें कि किसी ने की देखी थी। प्रतिबंधित कीज़ और स्रोत-IP नियंत्रण ब्लास्ट रेडियस को कम करते हैं। OWASP निर्माण, उपयोग, रोटेशन, विलोपन, उद्देश्य और स्वामित्व मेटाडेटा रिकॉर्ड करने और जहां संभव हो अल्पकालिक या डायनेमिक क्रेडेंशियल्स का उपयोग करने की भी अनुशंसा करता है।
चरण 5: केवल डिप्लॉयमेंट नहीं, बल्कि समाप्ति (closure) का सत्यापन करें
चार जांचें चलाएं: प्रत्येक गेटवे लगातार पुरानी की को अस्वीकार करता है; नई की केवल अनुमत टेनेंट और रूट्स तक पहुंच सकती है; लॉग में कोई पुरानी की ID या संदिग्ध स्रोत नहीं है; और सभी 200 सेवाओं के लिए स्वास्थ्य, व्यावसायिक मेट्रिक्स और त्रुटि बजट (error budgets) पुनर्प्राप्त होते हैं। जो सेवाएं स्वचालित रूप से अपडेट नहीं हो सकती हैं, उनके लिए "नया कॉन्फ़िगरेशन भेजा गया" को पूर्णता मानने के बजाय एक ओनर, समय सीमा और अस्थायी पृथक्करण नीति निर्दिष्ट करें।
समाप्त करने से पहले, एक अपरिवर्तनीय साक्ष्य सारांश, समयरेखा, अनुमति परिवर्तन, अनुमोदन और प्रतिनिधि संदिग्ध अनुरोधों को सुरक्षित रखें। नीति के अनुसार सीक्रेट सामग्री को नष्ट करें। समीक्षा में यह स्पष्ट होना चाहिए कि डिटेक्शन पहले क्यों नहीं हुआ, कॉलर्स ने एक की क्यों साझा की, किन लॉग्स में की ID का अभाव था, और क्या रेवोकेशन अपने लक्ष्य पर खरा उतरा। उत्तरों को परीक्षण योग्य कार्रवाइयों में बदलें।
मॉडल उच्च-गुणवत्ता वाला उत्तर
"मैं रीड-ओनली की को एक्सपोज़्ड मानूंगा। स्कैनर इसे कभी प्रदर्शित नहीं करेगा; यह एक फ़िंगरप्रिंट और रिपॉजिटरी लोकेशन स्टोर करता है, और एक प्रतिबंधित वैलिडेशन एंडपॉइंट की ID, टेनेंट, स्कोप और स्थिति की पुष्टि करता है। मैं उच्च जोखिम वाले क्रेडेंशियल्स को तुरंत रीवोक करूंगा, आधिकारिक स्थिति लिखूंगा, इनवैलिडेशन इवेंट्स प्रकाशित करूंगा, और आवश्यकता होगी कि प्रत्येक गेटवे पांच सेकंड के भीतर नए अनुरोधों को अस्वीकार करे, जिसका परीक्षण संदेश हानि, कैश व्यवहार और नोड रीस्टार्ट के तहत किया जाएगा।
मैं 200 कॉलर्स, रूट्स, स्रोत नेटवर्क और संदिग्ध रीड्स की पहचान करने के लिए खोज और रेवोकेशन के बीच रिक्वेस्ट लॉग को क्वेरी करूंगा। लॉग में केवल सार्वजनिक की ID होगी, Authorization हेडर नहीं। मैं प्रति सेवा एक स्वतंत्र न्यूनतम-विशेषाधिकार प्राप्त की उत्पन्न करूंगा, इसे सीक्रेट्स मैनेजर के माध्यम से कैनरी और बैचों में डिलीवर करूंगा, और पुरानी तथा नई की के ट्रैफ़िक का निरीक्षण करूंगा। किसी एक्सपोज़र को लंबी छूट अवधि नहीं मिलती है; डुअल कीज़ नियमित रोटेशन के लिए होती हैं।
सत्यापन का अर्थ केवल सफल डिप्लॉयमेंट से कहीं अधिक है: प्रत्येक गेटवे पुरानी की को अस्वीकार करता है, नई की टेनेंट और रूट प्राधिकरण को लागू करती है, पुरानी-की ट्रैफ़िक शून्य तक पहुंच जाता है, और सेवा त्रुटियां बजट में वापस आ जाती हैं। मैं इंसिडेंट टाइमलाइन और सुरक्षित साक्ष्य को सुरक्षित रखूंगा, सीक्रेट सामग्री को नष्ट करूंगा, और pre-commit ब्लॉकिंग, ऐतिहासिक स्कैन, रनटाइम विसंगति अलर्ट, स्वतंत्र कीज़ और रोटेशन अभ्यास जोड़ूंगा। यह पूरे टेनेंट या हर सेवा को ऑफ़लाइन किए बिना अटैक विंडो को छोटा करता है।"
सामान्य विफलता मोड
- मिलान के बाद पूरी की को लॉग करना → दूसरा लीक बनाता है → केवल फ़िंगरप्रिंट, की IDs और लोकेशन रखें।
- Regex को एक्सपोज़र तय करने देना → फ़ॉल्स पॉज़िटिव और अज्ञात प्रारूप रिस्पॉन्स को गलत दिशा में ले जाते हैं → प्रतिबंधित वैलिडेशन और प्रोवाइडर मेटाडेटा के माध्यम से पुष्टि करें।
- रीवोक करने से पहले दुरुपयोग की प्रतीक्षा करना → हो सकता है कि स्टैटिक की पहले ही कॉपी की जा चुकी हो → एक्सपोज़र को संभावित समझौते के रूप में समझें, पहले नियंत्रण करें।
- डेटाबेस पंक्ति को हटाना और रुक जाना → गेटवे कैश और डाउनस्ट्रीम सिस्टम अभी भी की को स्वीकार कर सकते हैं → प्रोपेगेशन को मापें, कैश को अमान्य करें, और डाउनस्ट्रीम रोटेशन को सत्यापित करें।
- पूरे टेनेंट को प्रतिबंधित करना → ब्लास्ट रेडियस फैलता है और रिकवरी कठिन हो जाती है → की, स्कोप, रूट और समय सीमा द्वारा सीमित करें।
- एक्सपोज़्ड की को लंबी डुअल-की विंडो देना → हमलावर एक्सेस बनाए रखता है → डुअल कीज़ को गैर-एक्सपोज़्ड नियमित रोटेशन के लिए आरक्षित रखें।
- सभी सेवाओं को एक साथ स्विच करना → एक खराब कॉन्फ़िगरेशन पूरे फ़्लीट में रुकावट का कारण बनता है → कैनरी, बैच, इडेम्पोटेंट स्थिति और रोलबैक का उपयोग करें।
- डिलीवरी को ही पूर्णता मानना → हो सकता है कि कोई सेवा रीलोड न हो और फिर भी पुरानी की का उपयोग करे → पुरानी-की अस्वीकृति, नई-की प्राधिकरण और व्यावसायिक मेट्रिक्स का परीक्षण करें।
फ़ॉलो-अप प्रश्न
फ़ॉलो-अप 1: स्कैनर यह साबित नहीं कर सकता कि कोई उम्मीदवार मान्य है। अब क्या करें?
वैध विंडो को छोटा करने के लिए इसे संभावित रूप से एक्सपोज़्ड मानें। गैर-सीक्रेट-रिटर्निंग वैलिडेशन एंडपॉइंट, रिपॉजिटरी संदर्भ और आंतरिक की मेटाडेटा के साथ साक्ष्य जोड़ें। यदि फ़ॉल्स-पॉज़िटिव लागत अधिक है, तो एक अधिकृत सुरक्षा समीक्षक कारण सहित समयबद्ध अपवाद को मंज़ूरी दे सकता है; स्कैनर को स्वयं स्वीकृति नहीं देनी चाहिए।
फ़ॉलो-अप 2: एक लीगेसी सिस्टम नई की को हॉट-रीलोड नहीं कर सकता। आप कैसे रोटेट करेंगे?
एक नया डिप्लॉयमेंट या संक्षिप्त डुअल प्रोसेस तैयार करें, नई की को मान्य करें, ट्रैफ़िक को शिफ़्ट करें, फिर पुरानी की को रीवोक करें। यदि यह असंभव है, तो सेवा की अनुमतियों और इग्रेस को अलग करें, एक छोटी समय सीमा निर्धारित करें, और मैन्युअल चरण का ऑडिट करें। लीगेसी बाधाएं एक्सपोज़्ड की को अनिश्चित काल तक मान्य छोड़ने को सही नहीं ठहराती हैं।
फ़ॉलो-अप 3: रेवोकेशन में पांच सेकंड से अधिक समय लगता है। सेवा जारी रखें या सब कुछ बंद कर दें?
स्कोप और व्यावसायिक जोखिम के आधार पर स्तरित (tier) करें। स्थिति बासी होने पर राइट्स, भुगतान और उच्च-मूल्य वाले रूट्स फ़ेल क्लोज़्ड (fail closed) होते हैं; कम जोखिम वाले रीड्स स्पष्ट रूप से लेबल किए गए संक्षिप्त डिग्रेडेशन का उपयोग कर सकते हैं। अलगाव और थ्रॉटलिंग बढ़ाएं, इनवैलिडेशन या कैश पाथ की मरम्मत करें, फिर तय करें कि क्या व्यापक ब्लॉक आवश्यक है।
फ़ॉलो-अप 4: हमलावर ने पुरानी की से पहले ही डेटा पढ़ लिया है। आगे क्या करें?
साक्ष्य सुरक्षित रखें, समय, टेनेंट, रूट्स और डेटा को सीमित करें, प्रभावित पक्षों को सूचित करें, और ब्रीच-रिपोर्टिंग कर्तव्यों का आकलन करें। रेवोकेशन और रोटेशन आगे के उपयोग को रोकते हैं; द्वितीयक एक्सपोज़र के लिए एक्सपोर्ट, कैश, एसिंक्रोनस जॉब्स और डाउनस्ट्रीम प्रतियों की समीक्षा करें।