बैकएंड इंटरव्यू: आप सुरक्षित API Key ऑथेंटिकेशन कैसे डिज़ाइन करते हैं?

प्रॉम्प्ट और लागू होने वाले परिदृश्य

एक मल्टी-टेनेंट B2B प्लेटफ़ॉर्म सर्वर-टू-सर्वर APIs एक्सपोज़ करता है। प्रत्येक ग्राहक विभिन्न इंटीग्रेशन के लिए कई कीज़ बना सकता है। सिस्टम को अलग-अलग लाइव और टेस्ट वातावरण, स्कोप्ड अनुमतियों, प्रति-की (per-key) और प्रति-टेनेंट (per-tenant) कोटा, वैकल्पिक समाप्ति, ज़ीरो-डाउनटाइम रोटेशन, और सेफ़्टी कॉम्प्रोमाइज़ होने के बाद त्वरित निरस्तीकरण की आवश्यकता है।

जारी करने (issuance), स्टोरेज, सत्यापन (verification), ऑथराइज़ेशन, रोटेशन, निरस्तीकरण, और ऑडिट पाथ डिज़ाइन करें। यह भी बताएं कि किन स्थितियों में API keys गलत क्रेडेंशियल हैं। क्लाइंट एक विश्वसनीय सर्वर है जो सीक्रेट को सुरक्षित रखने में सक्षम है; ब्राउज़र और मोबाइल एप्लिकेशन इस क्रेडेंशियल मॉडल के दायरे से बाहर हैं।

इस डिज़ाइन को पाँच इनवेरिएंट्स (invariants) को बनाए रखना चाहिए:

1. पूरा सीक्रेट केवल एक बार दिखाया जाता है और इसे कभी भी प्लेनटेक्स्ट में स्टोर या लॉग नहीं किया जाता है।
2. एक वैध की किसी मशीन प्रिंसिपल की पहचान करती है, लेकिन स्वचालित रूप से हर क्रिया को ऑथराइज़ नहीं करती है।
3. एक की केवल एक ही टेनेंट और वातावरण से संबंधित होती है।
4. निरस्तीकरण एक परिभाषित, परीक्षण योग्य प्रोपेगेशन लक्ष्य के भीतर प्रभावी होता है।
5. रोटेशन पुरानी और नई कीज़ को इस तरह ओवरलैप कर सकता है जिससे यह छिपा न रहे कि किस क्रेडेंशियल ने अनुरोध किया था।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत यह है कि क्या उम्मीदवार ऑथेंटिकेशन को ऑथराइज़ेशन से अलग करता है। किसी सीक्रेट को सत्यापित करने से यह स्थापित होता है कि किस API-key प्रिंसिपल ने अनुरोध भेजा है। सेवा को फिर भी स्कोप्स, एंडपॉइंट नीति, संसाधन स्वामित्व और टेनेंट आइसोलेशन को लागू करना होगा।

दूसरा संकेत सीक्रेट हैंडलिंग है। एक मजबूत उत्तर क्रिप्टोग्राफ़िक रूप से सुरक्षित रैंडम जनरेटर के साथ एक अपारदर्शी (opaque) उच्च-एंट्रॉपी सीक्रेट उत्पन्न करता है, इसे एक बार प्रदर्शित करता है, केवल एक सत्यापनकर्ता (verifier) को स्टोर करता है, इसे हर जगह रिडैक्ट (redact) करता है, और किसी भी सर्वर-साइड पेपर (pepper) को एक समर्पित सीक्रेट मैनेजर में रखता है।

तीसरा संकेत लाइफ़साइकल डिज़ाइन है। कीज़ को नाम, वातावरण, स्थिति, समाप्ति, स्कोप्स, एट्रिब्यूशन, रोटेशन और निरस्तीकरण की आवश्यकता होती है। किसी की को केवल एक स्थायी डेटाबेस स्ट्रिंग के रूप में मानना ऑपरेटरों को असुरक्षित शेयरिंग और व्यवधानकारी प्रतिस्थापन की ओर ले जाता है।

चौथा संकेत परिचालन संबंधी तर्क (operational reasoning) है। कैश, रेट लिमिट्स, लॉग्स, इंसिडेंट रिस्पॉन्स और उपलब्धता—ये सभी सुरक्षा सीमा को प्रभावित करते हैं। "तत्काल निरस्तीकरण" सही नहीं है यदि कोई एज कैश दस मिनट के लिए निरस्त की गई की को स्वीकार करता है।

अंत में, उम्मीदवार को अविश्वसनीय क्लाइंट्स और अत्यधिक संवेदनशील ऑपरेशनों के लिए API keys को अस्वीकार करना चाहिए। फ्रंटएंड कोड में कॉपी किया गया एक स्थिर बियरर (bearer) सीक्रेट यूज़र्स और हमलावरों द्वारा पुनर्प्राप्त किया जा सकता है। उच्च-मूल्य या यूज़र-प्रत्यायोजित (user-delegated) वर्कफ़्लोज़ के लिए अल्पकालिक वर्कलोड क्रेडेंशियल्स, OAuth, म्यूचुअल TLS, अनुरोध हस्ताक्षर (request signing), या स्टेप-अप नियंत्रणों की आवश्यकता हो सकती है।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• क्रेडेंशियल किसके पास है? एक बैकएंड सेवा एक सीक्रेट की रक्षा कर सकती है; कोई ब्राउज़र, मोबाइल ऐप, डेस्कटॉप बाइनरी या सार्वजनिक रिपॉजिटरी गोपनीयता की गारंटी नहीं दे सकती।
• एक की किसका प्रतिनिधित्व करती है? परिभाषित करें कि क्या यह किसी टेनेंट इंटीग्रेशन, किसी आंतरिक वर्कलोड, या किसी मानव का प्रतिनिधित्व करती है। यह डिज़ाइन टेनेंट के स्वामित्व वाले मशीन प्रिंसिपल का उपयोग करता है, एंड-यूज़र सत्र का नहीं।
• ऑपरेशन्स कितने संवेदनशील हैं? केवल-पढ़ने योग्य (read-only) एनालिटिक्स और धन के लेन-देन (money movement) समान नियंत्रणों के हकदार नहीं हैं।
• निरस्तीकरण और उपलब्धता के लक्ष्य क्या हैं? एक मापने योग्य प्रोपेगेशन लक्ष्य चुनें और तय करें कि यदि प्राथमिक की-स्टोर अनुपलब्ध है तो ऑथेंटिकेशन कैसा व्यवहार करेगा।
• वातावरण कैसे अलग (isolated) किए जाते हैं? टेस्ट और लाइव कीज़ को अलग-अलग प्रीफ़िक्स, डेटा सीमाओं, अनुमतियों और कोटा की आवश्यकता होती है।
• अनुमतियाँ कितनी बारीक (granular) हैं? मोटे स्कोप्स (coarse scopes) के साथ-साथ संसाधन-स्तरीय ऑथराइज़ेशन स्थापित करें; जब तक कि उत्पाद को इसकी आवश्यकता न हो, एक असीमित कस्टम नीति भाषा से बचें।
• एक टेनेंट कितनी कीज़ बना सकता है? एक सीमा कीज़ के अनियंत्रित फैलाव (sprawl) को रोकती है और ग्राहकों को असीमित क्रेडेंशियल्स बनाकर प्रति-की कोटा को बायपास करने से रोकती है।
• कौन से ऑडिट और अनुपालन नियम लागू होते हैं? डेटा प्रतिधारण (retention), निर्माता एट्रिब्यूशन, अंतिम उपयोग का डेटा, अनुमोदन और आपातकालीन एक्सेस को विनियमित किया जा सकता है।

30-सेकंड उत्तर रूपरेखा

"मैं एक खोजने योग्य सार्वजनिक ID और एक अपारदर्शी यादृच्छिक सीक्रेट के साथ एक की जारी करूँगा, जैसे ak_live_7F3KQ2.m8…Vw। पूरा मान केवल एक बार लौटाया जाता है। डेटाबेस सार्वजनिक ID, टेनेंट, वातावरण, स्कोप्स, स्थिति, समाप्ति और एक कीड वेरिफ़ायर (keyed verifier) को स्टोर करता है, प्लेनटेक्स्ट सीक्रेट को कभी नहीं।

प्रत्येक TLS अनुरोध पर, गेटवे हेडर से की निकालता है, सार्वजनिक ID द्वारा पंक्ति ढूंढता है, वेरिफ़ायर की फिर से गणना करता है, निरंतर समय (constant time) में इसकी तुलना करता है, और स्थिति व समाप्ति की जांच करता है। फिर यह एक मशीन-प्रिंसिपल संदर्भ बनाता है। एंडपॉइंट स्कोप्स और टेनेंट स्वामित्व की अलग से जांच की जाती है। रेट लिमिट्स की और टेनेंट दोनों पर लागू होती हैं, और ऑडिट लॉग में केवल सार्वजनिक ID होती है।

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

चरण-दर-चरण गहन विश्लेषण

चरण 1: पहचान और की रिकॉर्ड्स का मॉडल बनाएं

प्रत्येक की को एक विशिष्ट मशीन प्रिंसिपल बनाएं। प्रत्येक इंटीग्रेशन में एक ही टेनेंट-व्यापी सीक्रेट साझा न करें। एक व्यावहारिक रिकॉर्ड है:

ApiKey(
  key_id, tenant_id, environment, name, verifier,
  verifier_version, scopes, status, expires_at,
  created_at, created_by, last_used_at
)

key_id सार्वजनिक और खोजने योग्य है। name एक ऑपरेटर को "बिलिंग निर्यात" को "वेयरहाउस सिंक" से अलग करने में मदद करता है। status कम से कम सक्रिय और निरस्त स्थितियों का समर्थन करता है; समाप्ति का मूल्यांकन स्वतंत्र रूप से किया जाता है। created_by और अनुमानित last_used_at एट्रिब्यूशन में सुधार करते हैं। हर अनुरोध पर last_used_at को सिंक्रोनस रूप से अपडेट न करें: यह एक राइट हॉट स्पॉट (write hot spot) बनाता है। जब मिनट-स्तरीय सटीकता पर्याप्त हो तो इसे एसिंक्रोनस रूप से एग्रीगेट या सैंपल करें।

स्कोप्स मोटे क्षमताओं का वर्णन करते हैं जैसे कि invoices:read। वे संसाधन ऑथराइज़ेशन का स्थान नहीं लेते हैं। की को स्वीकार करने के बाद, चालान 123 के लिए एक अनुरोध को अभी भी ऑथेंटिकेटेड tenant_id द्वारा बाधित क्वेरी की आवश्यकता होती है। कॉलर द्वारा आपूर्ति किए गए टेनेंट को कभी भी अथॉरिटी के रूप में स्वीकार न करें।

चरण 2: एक बार उत्पन्न करें, एक बार प्रकट करें, एक वेरिफ़ायर स्टोर करें

क्रिप्टोग्राफ़िक रूप से सुरक्षित रैंडम जनरेटर के साथ 32-बाइट का रैंडम सीक्रेट उत्पन्न करें। यह एक ठोस डिज़ाइन विकल्प है, सार्वभौमिक प्रोटोकॉल आवश्यकता नहीं। इसे एक ट्रांसपोर्ट-सुरक्षित वर्णमाला में एन्कोड करें और इसे एक पहचानने योग्य प्रीफ़िक्स और सार्वजनिक ID के साथ संयोजित करें:

ak_live_7F3KQ2.m8...opaque-secret...Vw

प्रीफ़िक्स सपोर्ट टूल्स को सीक्रेट को उजागर किए बिना क्रेडेंशियल प्रकार और वातावरण की पहचान करने की अनुमति देता है। पूरी की केवल सफल निर्माण प्रतिक्रिया में लौटाएं। UI को यह बताना होगा कि इसे पुनर्प्राप्त नहीं किया जा सकता है; इसे खोने का मतलब है एक प्रतिस्थापन बनाना।

वेरिफ़ायर के रूप में HMAC-SHA-256(server_pepper, complete_secret) को स्टोर करें। पेपर डेटाबेस से अलग, एक सीक्रेट मैनेजर में रहता है। पर्याप्त रूप से रैंडम टोकन के लिए एक सादा SHA-256 डाइजेस्ट व्यावहारिक है; कीड वेरिफ़ायर तब डिफेंस-इन-डेप्थ जोड़ता है यदि केवल डेटाबेस उजागर होता है। वेरिफ़ायर को वर्शन दें ताकि सेवा एल्गोरिदम या पेपर्स को माइग्रेट कर सके। एक पेपर माइग्रेशन को सीमित दोहरे सत्यापन या एक सुविचारित की-रीइश्यू योजना का समर्थन करना चाहिए; प्रत्येक ग्राहक की को चुपचाप अमान्य करना अस्वीकार्य है।

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

चरण 3: अधिकार को व्यापक किए बिना अनुरोध को ऑथेंटिकेट करें

TLS की आवश्यकता रखें और की को एक ऑथराइज़ेशन या समर्पित हेडर में स्वीकार करें, URL क्वेरी स्ट्रिंग में कभी नहीं। URLs आमतौर पर इतिहास, एनालिटिक्स, प्रॉक्सी लॉग और रेफ़रर डेटा तक पहुँचते हैं। प्रारूप को विभाजित और मान्य करें, अनुक्रमित लुकअप (indexed lookup) के लिए सार्वजनिक ID का उपयोग करें, और महंगे काम से पहले विकृत इनपुट को अस्वीकार करें।

किसी संभावित पंक्ति के लिए, वेरिफ़ायर की फिर से गणना करें और एक निरंतर समय (constant-time) तुलना का उपयोग करें। फिर वातावरण, सक्रिय स्थिति और समाप्ति की जांच करें। अज्ञात, विकृत, समाप्त और निरस्त कीज़ के लिए समान जेनेरिक बाहरी त्रुटि लौटाएं ताकि एंडपॉइंट एक की-एन्यूमरेशन ऑरेकल (key-enumeration oracle) न बने। आंतरिक रूप से, सीक्रेट के बिना एक सुरक्षित कारण कोड रिकॉर्ड करें।

सफल सत्यापन एक ऐसा संदर्भ बनाता है जिसमें key_id, tenant_id, वातावरण और स्कोप्स शामिल होते हैं। रूट नीति आवश्यक स्कोप्स की जांच करती है; डेटा लेयर उस टेनेंट और संसाधन तक पहुंच को सीमित करती है। प्रशासनिक या उच्च-मूल्य वाले एंडपॉइंट्स API-key प्रिंसिपल्स को पूरी तरह से अस्वीकार कर सकते हैं या अतिरिक्त नियंत्रण की मांग कर सकते हैं।

चरण 4: स्तरित कोटा और निगरानी के साथ दुरुपयोग को सीमित करें

रेट लिमिटिंग पहचान साबित नहीं करती है, लेकिन यह चोरी या बग-युक्त क्रेडेंशियल के नुकसान को सीमित करती है। प्रति की एक बर्स्ट (burst) और निरंतर (sustained) सीमा लागू करें, साथ ही एक समग्र टेनेंट सीमा भी लागू करें। टेनेंट लेयर किसी ग्राहक को कई कीज़ बनाकर क्षमता को बढ़ाने से रोकती है। महंगे एंडपॉइंट्स को अलग लागत-भारित बजट और समवर्ती सीमाओं (concurrency limits) की आवश्यकता हो सकती है।

सार्वजनिक की ID, टेनेंट, रूट, निर्णय, विलंबता (latency), नीति द्वारा अनुमत स्रोत नेटवर्क मेटाडेटा और अनुरोध सहसंबंध ID (request correlation ID) को लॉग करें। पूरी की, वेरिफ़ायर या पुन: प्रयोज्य ऑथराइज़ेशन हेडर को कभी भी लॉग न करें। असामान्य भूगोल या नेटवर्क परिवर्तन, अचानक विफलता स्पाइक्स, स्कोप-अस्वीकृति स्पाइक्स, निष्क्रिय कीज़ का सक्रिय होना, और रोटेशन नोटिस के बाद ट्रैफ़िक पर अलर्ट करें। ये जांच के संकेत हैं, कॉम्प्रोमाइज़ का स्वचालित प्रमाण नहीं।

की-प्रबंधन एंडपॉइंट्स को सामान्य डेटा एंडपॉइंट्स की तुलना में अधिक भारी रूप से प्रतिबंधित करें। वे मजबूत मानव ऑथेंटिकेशन, कुकी-आधारित कंसोल के लिए CSRF सुरक्षा, स्पष्ट ऑथराइज़ेशन, ऑडिट इवेंट्स, निर्माण सीमाओं और संभवतः पुनः ऑथेंटिकेशन या अनुमोदन के हकदार हैं।

चरण 5: तीव्र निरस्तीकरण के साथ कैशिंग का मिलान करें

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

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

जोखिम के अनुसार विफलता व्यवहार चुनें। संवेदनशील राइट्स के लिए, पर्याप्त रूप से ताज़ा की-स्थिति प्राप्त करने में विफलता पर क्लोज़्ड फ़ेल (fail closed) होना चाहिए। चयनित कम जोखिम वाले रीड्स के लिए, थोड़ी पुरानी पहले से वैध कैश प्रविष्टि एक स्पष्ट उपलब्धता ट्रेडऑफ़ हो सकती है, लेकिन यह सख्त तत्काल निरस्तीकरण का उल्लंघन करती है और इसे डिफ़ॉल्ट के रूप में शामिल नहीं किया जाना चाहिए।

चरण 6: रोटेशन और निरस्तीकरण को अलग वर्कफ़्लो के रूप में संभालें

नियमित रोटेशन को ओवरलैप की आवश्यकता होती है:

1. पुरानी की से अधिक विशेषाधिकार के बिना एक नई की बनाएं।
2. इसे ग्राहक के सीक्रेट-प्रबंधन पाथ के माध्यम से वितरित करें।
3. नई की को डिप्लॉय करें और कैनरी परीक्षण करें।
4. पुरानी की के शांत होने तक सार्वजनिक की ID द्वारा अनुरोधों का निरीक्षण करें।
5. पुरानी की को निरस्त करें और सत्यापित करें कि कोई भी ट्रैफ़िक अभी भी उस पर निर्भर नहीं है।

पुरानी सीक्रेट को सीधे म्यूटेट (in-place mutate) न करें; दो अलग-अलग IDs माइग्रेशन के दौरान एट्रिब्यूशन और रोलबैक को सुरक्षित रखते हैं। समाप्ति एक अधिकतम लाइफ़टाइम लागू कर सकती है, लेकिन एडॉप्शन टेलीमेट्री के बिना जबरन समाप्ति से बचा जा सकने वाला आउटेज हो सकता है।

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

चरण 7: जानें कि कब API keys अपर्याप्त हैं

API keys बियरर क्रेडेंशियल हैं: उनका उपयोग करने के लिए उनका पास होना ही पर्याप्त है। वे यह साबित नहीं करते हैं कि कॉलर अभी भी अपेक्षित वर्कलोड पर चल रहा है, एंड-यूज़र सहमति प्रदान नहीं करते हैं, या अपने दम पर रीप्ले को रोकते हैं। किसी सीक्रेट की को ब्राउज़र JavaScript, मोबाइल बाइनरी, सैंपल कोड, कंटेनर इमेज या रिपॉजिटरी में कभी भी एम्बेड न करें।

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

चरण 8: सुरक्षा, लाइफ़साइकल और विफलता मोड का परीक्षण करें

एक प्रतिकूल मैट्रिक्स (adversarial matrix) बनाएं जिसमें शामिल हो:

1. विकृत प्रीफ़िक्स, अज्ञात IDs, गलत सीक्रेट्स और निरंतर-समय वेरिफ़ायर हैंडलिंग;
2. समाप्त, निरस्त, टेस्ट-इन-लाइव, और अपर्याप्त-स्कोप कीज़;
3. अन्यथा वैध ऑथेंटिकेशन के बाद क्रॉस-टेनेंट ऑब्जेक्ट एक्सेस;
4. प्रॉक्सी, एप्लिकेशन, ट्रेस, एरर और ऑडिट आउटपुट में सीक्रेट रिडक्शन;
5. रोटेशन ओवरलैप, पुरानी की उपयोग टेलीमेट्री, समाप्ति, और आपातकालीन निरस्तीकरण;
6. पुरानी कैश प्रविष्टियां, छूटे हुए अमान्यीकरण, गेटवे पुनरारंभ, और की-स्टोर आउटेज;
7. प्रति-की और प्रति-टेनेंट कोटा प्रवर्तन, जिसमें एक टेनेंट से कई कीज़ शामिल हैं;
8. समवर्ती निर्माण, इन-फ़्लाइट अनुरोध के दौरान निरस्तीकरण, और डुप्लिकेट प्रबंधन कॉल।

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

मजबूत नमूना उत्तर

"मैं प्रत्येक API key को एक टेनेंट और एक वातावरण के स्वामित्व वाले नामित मशीन प्रिंसिपल के रूप में मानूँगा। जारी किए गए मान में एक सार्वजनिक लुकअप ID और एक अपारदर्शी यादृच्छिक सीक्रेट होता है। मैं इसे TLS पर एक बार लौटाता हूँ, एक कीड वेरिफ़ायर और लाइफ़साइकल मेटाडेटा स्टोर करता हूँ, और प्रत्येक लॉगिंग और ट्रेसिंग लेयर से पूर्ण मान को रिडैक्ट करता हूँ।

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

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

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

सामान्य गलतियाँ

• प्लेनटेक्स्ट की को स्टोर करना ताकि इसे फिर से दिखाया जा सके। रिकवरी की सुविधा डेटाबेस रीड को क्रेडेंशियल प्रकटीकरण में बदल देती है। केवल एक बार दिखाएं और प्रतिस्थापन का समर्थन करें।
• लाइफ़साइकल मेटाडेटा के बिना केवल एक वैश्विक हैश का उपयोग करना। अकेले सत्यापन से टेनेंट, वातावरण, स्कोप, समाप्ति, एट्रिब्यूशन या निरस्तीकरण के सवालों का जवाब नहीं मिल सकता है।
• क्वेरी स्ट्रिंग्स में कीज़ डालना। URLs नियमित रूप से कॉपी और रिकॉर्ड किए जाते हैं। TLS पर हेडर का उपयोग करें।
• स्कोप्स को टेनेंट ऑथराइज़ेशन के रूप में मानना। invoices:read यह साबित नहीं करता है कि चालान 123 ऑथेंटिकेटेड टेनेंट का है।
• प्रत्येक इंटीग्रेशन को एक साझा टेनेंट की देना। ऐसे में लीक होने पर ब्लास्ट रेडियस बड़ा होता है और एट्रिब्यूशन अस्पष्ट हो जाता है।
• केवल प्रति की रेट-लिमिट करना। एक टेनेंट कई कीज़ बना या रोटेट कर सकता है और अपने अनुमत ट्रैफ़िक को बढ़ा सकता है।
• मिनटों के लिए कैशिंग करते हुए तत्काल निरस्तीकरण का दावा करना। एक प्रोपेगेशन लक्ष्य बताएं, सक्रिय रूप से अमान्य करें, और कैश विफलता का परीक्षण करें।
• सीक्रेट को अधिलेखित (overwriting) करके रोटेट करना। यह ओवरलैप, एट्रिब्यूशन, कैनरीइंग और एक स्पष्ट रोलबैक पाथ को हटा देता है।
• पब्लिक क्लाइंट में स्थिर सीक्रेट का उपयोग करना। अस्पष्टता (obfuscation) एक गोपनीय स्टोरेज सीमा नहीं बना सकती है।
• ऑथेंटिकेशन को डिबग करने के लिए क्रेडेंशियल को लॉग करना। एक सार्वजनिक ID और सुरक्षित कारण कोड लॉग करें; पुन: प्रयोज्य सीक्रेट को कभी भी लॉग न करें।

फॉलो-अप प्रश्न और उत्तर

पूरी की को हैश करने और हर पंक्ति को स्कैन करने के बजाय सार्वजनिक ID और सीक्रेट का उपयोग क्यों करें?

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

क्या API-key वेरिफ़ायर के लिए एक तेज़ हैश सुरक्षित है?

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

आप सर्वर-साइड पेपर को कैसे रोटेट करते हैं?

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

क्या last_used_at सटीक होना चाहिए?

आमतौर पर नहीं। हर अनुरोध पर एक पंक्ति को अपडेट करने से राइट लोड और कंटेंशन बढ़ता है। एक सैंपल या एग्रीगेट किया गया उपयोग इवेंट भेजें और समय-समय पर अपडेट करें। सुरक्षा ऑडिट इवेंट्स अनुरोध लेयर पर केवल-संलग्न (append-only) रह सकते हैं, जबकि प्रबंधन UI last_used_at को अनुमानित के रूप में लेबल करता है।

आप इन-फ़्लाइट अनुरोध के साथ होने वाले निरस्तीकरण रेस को कैसे संभालते हैं?

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

क्या कीज़ स्वचालित रूप से समाप्त होनी चाहिए?

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

क्या IP अनुमति सूची (allowlisting) की-चोरी को हल करेगी?

स्थिर इग्रेस (egress) पतों वाले ग्राहकों के लिए यह एक वैकल्पिक अतिरिक्त प्रतिबंध है। यह सीक्रेट सत्यापन की जगह नहीं लेता है, और नेटवर्क बदलने या प्रॉक्सी साझा होने पर यह आउटेज या गलत विश्वास पैदा कर सकता है। इसे पहचान के मूल के रूप में नहीं, बल्कि एक सिग्नल या नीति लेयर के रूप में मानें।

क्रिएट-की रिस्पॉन्स में क्या होना चाहिए?

पूरी की को एक बार लौटाएं, उसकी सार्वजनिक ID या प्रीफ़िक्स, नाम, वातावरण, स्कोप्स, समाप्ति और निर्माण मेटाडेटा। प्रतिक्रिया को गैर-कैश योग्य के रूप में चिह्नित करें और वेरिफ़ायर या पेपर को कभी न लौटाएं। बाद के सूची APIs केवल सार्वजनिक पहचानकर्ता और मेटाडेटा लौटाते हैं।