प्रॉम्प्ट
ग्राहक API कुंजियों को वर्षों तक सक्रिय छोड़ देते हैं। लक्षित उपयोगकर्ताओं, MVP स्कोप, डुअल-की माइग्रेशन, ऑडिटेबिलिटी और सफलता के पैमानों सहित एक क्रेडेंशियल-रोटेशन कंसोल का मूल्यांकन करें।
परिदृश्य और सीमाएं
प्लेटफ़ॉर्म में व्यक्तिगत कुंजियाँ, टीम कुंजियाँ और सर्विस टोकन हैं। ग्राहक CI, फ़ंक्शंस और स्थानीय परिवेशों में क्रेडेंशियल रखते हैं; कुछ सिस्टम दो कुंजियाँ नहीं रख सकते हैं और कुछ व्यवस्थापक सीक्रेट मान नहीं पढ़ सकते हैं। रोटेशन को रोकने (pause), रोलबैक करने योग्य होना चाहिए और इसे कभी भी पूरा सीक्रेट प्रदर्शित नहीं करना चाहिए।
यह क्या परीक्षण करता है
यह परीक्षण एक सुरक्षा क्षमता को अपनाने योग्य वर्कफ़्लो में बदलने की क्षमता को परखता है। Stripe कुंजी निर्माण, समाप्ति और रोटेशन को जीवनचक्र क्षमताओं के रूप में मानता है; Cloudflare एक सर्विस-टोकन रोटेशन एक्शन को उजागर करता है; GitHub पुश सुरक्षा दर्शाती है कि रोकथाम और बाईपास प्रबंधन के लिए स्पष्ट जिम्मेदारी सीमाओं की आवश्यकता होती है।
संदर्भ दृष्टिकोण
क्रेडेंशियल प्रकार और परिनियोजन (डिप्लॉयमेंट) मॉडल के अनुसार विभाजित करें। एक MVP समाप्ति अनुस्मारक (expiry reminders), स्वामी और स्कोप, रोटेशन पूर्वावलोकन, नई कुंजी निर्माण, संक्षिप्त ओवरलैप, नई कुंजी सत्यापन, पुरानी कुंजी निरस्तीकरण (revocation), और ऑडिट इवेंट प्रदान करता है। डिफ़ॉल्ट रूप से केवल उपसर्ग (prefixes), निर्माण समय और अंतिम उपयोग दिखाएं। सिंगल-की सिस्टम के लिए, स्वचालित अमान्यकरण के बजाय निरस्तीकरण विराम (revocation pause), माइग्रेशन चेकलिस्ट और मानव पुष्टि की पेशकश करें।
महत्वपूर्ण विवरण
इडमपोटेंट (idempotent) संचालन और स्थितियों का उपयोग करें: पूर्वावलोकन (preview), निर्माण (create), सत्यापन (verify), सक्रियण (activate), निरस्तीकरण (revoke)। न्यूनतम ओवरलैप, अप्रयुक्त पुरानी कुंजी के अनुस्मारक और विफलता रोलबैक को परिभाषित करें। स्वामियों, व्यवस्थापकों और सुरक्षा टीमों को सूचित करें। पूर्णता दर, समाप्त हो चुके क्रेडेंशियल, रोटेशन के कारण होने वाली विफलताएं, माइग्रेशन समय और निरस्तीकरण के बाद अवशिष्ट उपयोग को मापें।
सामान्य गलतियाँ
प्रत्येक कुंजी को एक ही तिथि पर रोटेट करने के लिए बाध्य करना; पूर्ण सीक्रेट प्रदर्शित करना; अंतिम उपयोग के समय को पूर्णतः सटीक मानना; माइग्रेशन के बिना केवल अनुस्मारक देना; और प्रत्यायोजित अनुमतियों, सर्विस खातों या क्षेत्रीय कैश को अनदेखा करना।
मूल्यांकन रूब्रिक
सशक्त उत्तर विफलता और पूर्णता दरों का उपयोग करके जोखिम स्तरों, MVP सीमाओं, डुअल-की और सिंगल-की पाथ, अनुमति और ऑडिट डिज़ाइन, और मूल्य मेट्रिक्स को परिभाषित करते हैं। केवल "एक रोटेट बटन जोड़ें" कहना अपर्याप्त है।
अनुवर्ती प्रश्न
क्या आप ग्राहक के CI सीक्रेट को स्वचालित रूप से बदलने का वादा करेंगे?
एकीकरण (इंटीग्रेशन) स्कोप और प्राधिकरण की पुष्टि करें। संक्षिप्त डुअल-की ओवरलैप, सत्यापन और रोलबैक को प्राथमिकता दें। यदि राइट (write) की सफलता की पुष्टि नहीं की जा सकती है, तो पुरानी कुंजी को निरस्त न करें; मानव पुष्टि को एक स्पष्ट स्थिति के रूप में प्रस्तुत करें।
लीक होने के संदेह वाली कुंजी को आप कैसे संभालते हैं?
आपातकालीन निरस्तीकरण को नियोजित रोटेशन से अलग रखें। ब्लास्ट रेडियस, अंतिम उपयोग और प्रतिस्थापन निर्माण दिखाएं; निरस्तीकरण से पहले अपरिवर्तनीय प्रभाव के बारे में चेतावनी दें और ऑडिट व सूचनाओं में निर्णय को रिकॉर्ड करें।
आप कंसोल को सीक्रेट-लीक का ज़रिया (leak surface) बनने से कैसे रोकते हैं?
न्यूनतम विशेषाधिकार (least privilege), वन-टाइम डिस्प्ले, कम समय तक चलने वाले ऑपरेशन टोकन, रिडक्शन (redaction), और पूर्ण एक्सेस ऑडिट का उपयोग करें। सीक्रेट मानों को नियंत्रित स्टोरेज में रखें; UI केवल पहचानकर्ताओं और स्थितियों को संभालता है।