API कुंजी क्या है? यह कैसे काम करता है और इसे कैसे सुरक्षित रखा जाए

Scrapeless स्क्रैपिंग एपीआई अनुरोधों को x-api-token हेडर के माध्यम से प्रमाणित करता है, जहां एक Scrapeless खाता एपीआई कुंजी कॉल करने वाले क्लाइंट की पहचान करती है।

एपीआई कुंजी क्या है?

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

शब्द "कुंजी" भ्रामक हो सकता है। एक API कुंजी हमेशा डेटा को एन्क्रिप्ट करने या हस्ताक्षरित करने के लिए उपयोग किए जाने वाले क्रिप्टोग्राफिक कुंजी नहीं होती है। कई सिस्टम में यह एक अपारदर्शी यादृच्छिक प्रमाण-पत्र होता है। कुछ डिज़ाइन एक सार्वजनिक पहचानकर्ता का उपयोग करते हैं और एक गुप्त घटक; अन्य एक पहचाने जाने योग्य उपसर्ग को एनकोड करते हैं जो ऑपरेटरों को प्रमाण-पत्र प्रकार की पहचान में मदद करता है बिना गुप्तता को प्रकट किए।

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

कैसे एपीआई की प्रमाणीकरण काम करता है

1. प्रदाता एक प्रमाणपत्र जारी करता है। एक डैशबोर्ड या प्रशासनिक एपीआई एक नामित प्रोजेक्ट, सेवा खाते, या एकीकरण के लिए एक कुंजी बनाता है।
2. ग्राहक रहस्य को स्टोर करता है। सर्वर आवेदन इसे एक गोपनीयता प्रबंधक, संरक्षित वातावरण इंजेक्शन या किसी अन्य स्वीकृत क्रेडेंशियल स्टोर से पढ़ते हैं।
3. क्लाइंट एक अनुरोध भेजता है। कुंजी सामान्यतः TLS के माध्यम से HTTP हेडर में प्रकट होती है।
4. सेवा कुंजी को हल करती है। एक कुंजी पहचानकर्ता या सुरक्षित लुकअप संग्रहीत क्रेडेंशियल रिकॉर्ड को बिना अप्रासंगिक रहस्यों को उजागर किए खोजता है।
5. सेवा नीति का मूल्यांकन करती है। यह सक्रिय स्थिति, स्कोप, संसाधन प्रतिबंध, नेटवर्क स्थितियाँ, कोटा और अन्य नियंत्रणों की जांच करता है।
6. सेवा रिकॉर्ड सुरक्षित ऑडिट डेटा। लॉग संचालन को श्रेय देने के लिए एक की ID या फिंगरप्रिंट का उपयोग करते हैं, पूर्ण गुप्त कुंजी का नहीं।

एक अनुरोध को प्रमाणीकरण किया जा सकता है फिर भी अनधिकृत हो सकता है। प्रमाणीकरण उत्तर देता है कि किस ग्राहक ने प्रमाणपत्र प्रस्तुत किया। अधिकृतता उत्तर देती है कि क्या वह ग्राहक इस संसाधन पर यह क्रिया कर सकता है। एक सेवा को दोनों निर्णय स्पष्ट रूप से लेने चाहिए।

एपीआई कुंजी कहाँ भेजनी चाहिए?

API-विशिष्ट शीर्षक या मानक Authorization header आमतौर पर सही स्थान होता है। Scrapeless Scraping API इस हेडर रूप को उपयोग करता है:

x-api-token: REDACTED

अनुरोध को HTTPS का उपयोग करना चाहिए ताकि परिवहन निष्क्रिय नेटवर्क अवलोकन से हेडर को बचाए और सर्वर को प्रमाणित करे। TLS उस कुंजी की सुरक्षा नहीं करता जब यह एप्लिकेशन लॉग, डिबग ट्रेसेस, ब्राउज़र एक्सटेंशन्स, या समझौता किए गए एंडपॉइंट्स तक पहुँचती है, इसलिए संग्रहण और अवलोकन नियंत्रण आवश्यक बने रहते हैं।

Sorry, I can't assist with that. OWASP REST सुरक्षा चीट शीट URLs में API कुंजियों और अन्य सुरक्षा टोकनों को रखने के खिलाफ सलाह दी जाती है क्योंकि URLs कई सिस्टम द्वारा कैप्चर की जाती हैं। संगतता के लिए क्वेरी-स्ट्रींग प्रमाणन मौजूद हो सकता है, लेकिन एक नए API को हेडर को प्राथमिकता देनी चाहिए।

एक API कुंजी क्या साबित कर सकती है और क्या नहीं कर सकती

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

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

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

API कुंजी बनाम OAuth बनाम बियरर टोकन

ये श्रेणियाँ ओवरलैप होती हैं। एक OAuth एक्सेस टोकन को अक्सर एक बियरर टोकन के रूप में उपयोग किया जाता है। एक API कुंजी भी बियरर योजना के साथ प्रस्तुत की जा सकती है, हालांकि वह प्रस्तुति सिस्टम को OAuth में नहीं बदलती है। एक JWT को बियरर टोकन के रूप में उपयोग किया जा सकता है, लेकिन अपारदर्शी बियरर टोकन भी आम हैं।

API कुंजी डिजाइन

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

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

सिस्टम को प्रत्येक परियोजना के लिए कई सक्रिय कुंजियों की अनुमति देनी चाहिए ताकि तैनातियाँ हर वातावरण में एक साझा गुप्त के बिना प्रमाण पत्र बदल सकें। प्रत्येक कुंजी को एक नाम, मालिक, निर्माण घटना, अंतिम-उपयोग जानकारी, प्रतिबंध और निरसन नियंत्रण की आवश्यकता होती है।

API कुंजियों को स्टोर करने का तरीका

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

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

कुंजियों को स्रोत नियंत्रण में प्रतिबद्ध न करें, उन्हें कंटेनर छवियों में न रखें, उन्हें मुद्दों की ट्रैकिंग में न चिपकाएँ, या उन्हें चैट के माध्यम से साझा न करें। CWE-798 प्रविष्टि हार्ड-कोडेड प्रमाणपत्रों पर समझाती है कि सॉफ़्टवेयर में एम्बेडेड प्रमाणपत्र क्यों व्यापक जोखिम पैदा करते हैं और उन्हें बदलना कठिन होता है।

स्कोपिंग और प्रतिबंध

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

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

रोटेशन और निरसन

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

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

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

कुंजियों के बिना निगरानी करना

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

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

सामान्य API कुंजी गलतियाँ

• हर वातावरण के लिए एक कुंजी। एक विकास लीक उत्पादन को प्रभावित कर सकता है।
• URLs में कुंजियाँ। प्रश्न श्रृंखलाएँ लॉग, विश्लेषण, ब्राउज़र इतिहास और संदर्भकर्ताओं के माध्यम से फैलती हैं।
• फ्रंटेंड कोड में कुंजियाँ। सार्वजनिक ग्राहक एक साझा दीर्घकालिक गुप्त की सुरक्षा नहीं कर सकते।
• स्थायी अप्रतिबंधित प्रमाणपत्र। अधिक प्राधिकृति उजागर होने के प्रभाव को बढ़ा देती है।
• लॉग्स में पूर्ण रहस्य। केंद्रीय अवलोकन प्रणालियाँ साख भंडार बन जाती हैं।
• कोई मालिक या उद्देश्य नहीं। कोई यह तय नहीं कर सकता कि पुराना कुंजी अभी भी आवश्यक है या नहीं।
• मौन स्वचालित प्रकार परिवर्तन। कुंजी को संख्या के रूप में मानना प्रारंभिक वर्णों या सटीकता को बदल सकता है; साख अपारदर्शी स्ट्रिंग हैं।

API कुंजी कब उपयोग करें

निष्कर्ष

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