मैं किसी कंपनी के भीतर आंतरिक एपीआई कुंजी साझा करने को कैसे हतोत्साहित कर सकता हूं?


37

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

हम यह जानने के लिए उत्सुक हैं कि कौन से अनुप्रयोग कौन से अनुरोध भेज रहे हैं, ताकि हम उपयोग के पैटर्न और डेवलपर्स को जिम्मेदार पहचान सकें। (संदेह से बचने के लिए, उपयोगकर्ता प्रमाणीकरण को अलग से संभाला जाता है।)

हमारे समाधान के लिए एपीआई कुंजियों की आवश्यकता है, प्रति आवेदन एक - तो हमारे पास विकास टीम के लिए संपर्क विवरण है।

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

हम डेवलपर्स को आंतरिक रूप से एपीआई कुंजी साझा नहीं करने के लिए कैसे प्रोत्साहित कर सकते हैं?


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

3
यदि आप नहीं चाहते हैं कि लोग सहकर्मियों को कुंजियाँ साझा करें, तो एक विन्यास फाइल को शामिल करना आसान बना दें जिसे संस्करण प्रणाली द्वारा अनदेखा किया गया है (ताकि कुंजी कभी भी कमिट न हो) और नई कुंजी बनाने में भी आसानी हो। कोई भी एक गुप्त कुंजी साझा करने से परेशान नहीं होगा यदि कोई अन्य डेवलपर आसानी से खुद से एक नई कुंजी बना सकता है। व्यक्तिगत कुंजी साझा करने में समस्या आमतौर पर इस तथ्य के कारण होती है कि नई कुंजी प्राप्त करने में समय लगता है।
सुल्तान

क्या आपने आवेदन शुरू होने पर पंजीकरण की आवश्यकता पर विचार किया है? यह एक स्पलैश स्क्रीन दिखा सकता है जो उपयोगकर्ता के संपर्क विवरण (या जो कुछ भी जानकारी आपको चाहिए) के लिए पूछ रही है और फिर मौके पर एपीआई कुंजी जारी करें।
जॉन वू

"हम डेवलपर्स को आंतरिक रूप से एपीआई कुंजी साझा नहीं करने के लिए कैसे प्रोत्साहित कर सकते हैं?" बस कहा जाता है, हर कुंजी को उन कंप्यूटरों में नेटवर्क कार्ड के मैक पते से जोड़ दें जो उन्हें चलाते हैं। नेटवर्किंग प्रोटोकॉल एक ही मैक पते को एक ही नेटवर्क में उपयोग करने से रोकता है, जिससे लोग बार-बार एक ही कुंजी का उपयोग करने से बचते हैं। मैंने इसे एक उत्तर में बनाया है, लेकिन मेरे पास इसके लिए वर्तमान में प्रतिनिधि नहीं है।
ब्लर

जिज्ञासावश, मुझे फिलहाल इस पृष्ठ पर कहीं भी "रोटेशन" (जैसा कि कुंजी रोटेशन - क्रेडेंशियल एक्सप्रेशन / रोटेशन) शब्द दिखाई नहीं देता है । एक बार जब कोई व्यक्ति एक कुंजी प्राप्त करता है, तो क्या यह एक परिमित जीवनकाल होता है जिसके बाद इसे उपयोग से बाहर घुमाया जाना चाहिए और एक नए द्वारा प्रतिस्थापित किया जाना चाहिए? यदि नहीं, तो क्यों नहीं?
माइकल - साइक्लबोट

जवाबों:


76

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

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

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


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

3
पुन: पूर्व-खाली करना, आप बिल्कुल सही हैं, हमें आक्रामक रूप से इच्छुक पार्टियों को चाबियां बनाना और भेजना चाहिए। मैंने जो उल्लेख नहीं किया, वह यह है कि इनमें से कुछ ऐप एक सामान्य ढांचे / इंटरफ़ेस का उपयोग करते हैं, और हम शायद उस परत पर अद्वितीय कुंजियों को स्वचालित रूप से इंजेक्ट या लागू कर सकते हैं, लेकिन यह सभी ऐप्स पर लागू नहीं होता है।
ओली

1
@ ईवन यदि आप दी गई कुंजी तक पहुंच को निष्क्रिय कर देते हैं तो सभी उपयोगकर्ता आपके पास चले जाएंगे - उन्हें पीछा करने की कोई आवश्यकता नहीं है। और फिर आप उन्हें अद्वितीय कुंजी दे सकते हैं :)
अलेक्सी लेवेनकोव

15
पूर्व-खाली करने के लिए यह फ़ॉर्म लेना चाहिए: कुंजी के बिना एपीआई तक पहुंच पृष्ठ के लिंक के साथ एक त्रुटि संदेश पैदा करता है जहां आप कुंजी के लिए आवेदन करते हैं। प्रलेखन पढ़ने के लिए किसी से अपेक्षा न करें। जब कोई उनके बारे में नहीं जानता है तो प्रोत्साहन काम नहीं करता है।
कैंडिड_ऑरेंज

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

20

पहले से ही अच्छे जवाब, मैंने सिर्फ एक अलग दृष्टिकोण के बारे में सोचा जो आपके लिए काम कर सकता है या नहीं।

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


यदि एप्लिकेशन के स्वामित्व में परिवर्तन होने से जीवन कुछ कठिन हो जाता है - उदाहरण के लिए, हम बस अपने अंत में संग्रहीत API कुंजी विवरण को अपडेट कर सकते हैं, लेकिन यदि हम मुफ्त फॉर्म टेक्स्ट को स्वीकार करते हैं जिसके लिए कोड परिवर्तन करने के लिए एप्लिकेशन की आवश्यकता होती है।
ओली

1
@ यदि किसी एप्लिकेशन का स्वामित्व बदल गया है और (नया) डेवलपर एप्लिकेशन की पहचान को अपडेट करने के लिए उपयुक्त होगा (जो कि इसके कारण है क्योंकि कोई और इसे बनाए रख रहा है), तो समस्या क्या होगी? आप पूर्व स्वामित्व परिवर्तन और स्वामित्व परिवर्तन के बाद अंतर कर सकते हैं, बस उन्हें दो अलग-अलग अनुप्रयोगों के रूप में मानते हैं। मैं किसी भी नए मालिक से उम्मीद नहीं करूंगा कि वह जल्द से जल्द हेडर में नाम को नोटिस करे।
मार्टिन माट

3
मैं यह करता हूं। ग्राहक के पास एक निर्माण पैरामीटर है, जो ऐप का नाम है और / या प्रतिबिंब का उपयोग करके अन्य सामानों को खींचने के लिए, जैसे मशीन को चलाने वाला, इसका संस्करण आदि। महत्वपूर्ण बात यह है कि आप रिपोर्ट करने में सक्षम हों जब लोग आपके एपीआई का पालन नहीं कर रहे हों। नीति
इवान

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

@ कालेब अगर चीजों को इस तरह केंद्रीकृत किया जाता तो ओपी को शायद यह समस्या नहीं होती। जो मैं समझता हूं कि फ्रंट एंड एप्लिकेशन डेवलपर्स ओपी के लिए बहुत कम हैं, सॉफ्टवेयर विकास के निजी तरीकों के साथ।
मार्टिन मैत

16

संक्षेप में:

पहला: सुविधा और लाभ; यदि आवश्यक हो: घर्षण और पुलिस।

कुछ और शब्द

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

लाभ : अपनी एपीआई कुंजी का उपयोग टीम या उत्पाद के मालिक के लिए एक लाभ हो। उदाहरण के लिए, उस कुंजी के आधार पर ऐप के उपयोग के बारे में कुछ प्रतिक्रिया दें।

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

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

टिप्पणी : आपको अपनी एपीआई कुंजी नीति पर बहुत स्पष्ट होने की आवश्यकता हो सकती है: क्या एक नए प्रमुख संस्करण को अपनी एपीआई कुंजी की आवश्यकता होगी? एक कांटा के साथ क्या है, या यदि कोई एप्लिकेशन विभाजित है? क्या होगा अगर एक अन्य टीम प्रभारी है, आदि ...


6

आमतौर पर डेवलपर्स को "सही काम करने" के लिए सबसे आसान तरीका है, उनके लिए ऐसा करना आसान है।

उस अंत तक मैं एक एपीआई कुंजी जारी करने वाले वेब पेज / साइट बनाने का सुझाव दूंगा। अपने सरलतम रूप में यह सिर्फ एक लॉगिन हो सकता है (आदर्श रूप से आपके कॉरपोरेट AD / LDAP से जुड़ा हुआ) और वह पृष्ठ जो केवल आवेदन नाम पूछता है और कुंजी जारी करता है।

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

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


1

सक्रिय होना।

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

एपीआई कुंजियों का उपयोग किया गया है, और जो नहीं है का ट्रैक रखें। यदि बॉब ने परियोजना में टिकट जमा किए हैं, लेकिन वह अपनी API कुंजियों का उपयोग नहीं कर रहा है, तो संभवतः वह किसी और का उधार ले रहा है।

प्रबंधन का सहयोग लें। कोई बात नहीं है कि कोई फर्क नहीं पड़ता कि कोई नियम बनाने जा रहा है एक Nosy नैन्सी मत बनो। वस्तुतः प्रबंधन को आश्वस्त करता है कि यह महत्वपूर्ण है, और फिर वे समूह को समझाने के लिए हैं कि यह महत्वपूर्ण है। हर किसी को समझाने पर काम मत करो।

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


1

हम डेवलपर्स को आंतरिक रूप से एपीआई कुंजी साझा नहीं करने के लिए कैसे प्रोत्साहित कर सकते हैं?

  • स्वयं-सेवा अनुप्रयोग पंजीकरण के परिणामस्वरूप कुंजियाँ बनाएँ
  • कुंजी सक्रिय होने से पहले संपर्क के एक बिंदु की आवश्यकता होती है।
  • और उन्हें साझा न करने के लिए कहें। (सेवा की शर्तें बनाएं और / या उन्हें बताएं कि उनके लिए साझा न करना बेहतर क्यों है ।)

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

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


0

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

यह आपको बताएगा कि क्या यह उत्पादन, क्यूए या देव में कुछ था, और शुरू की गई समस्याओं को किस संस्करण / निर्माण पर।


0

पहली और सबसे अच्छी बात यह है कि आप कुंजियों को प्रारूपित करना चाहते हैं ताकि वे आसानी से पढ़ने योग्य रूप में एप्लिकेशन का नाम शामिल करें, और यदि आप इसे बदलते हैं तो काम न करें।

यदि यह स्पष्ट है कि टीमें गलत कुंजी का उपयोग कर रही हैं, तो वे प्रयास करेंगे कि नहीं।

फिर, समय-समय पर चाबियाँ समाप्त हो जाती हैं। आपको इसे वैसे भी करना चाहिए , और जब कोई समाप्ति समाप्त होने वाली होती है, तो आप उस टीम को एक नया भेज सकते हैं जो इसका मालिक है। एक कुंजी का उपयोग करने वाली टीम को यह सुनिश्चित करने के लिए प्रेरित किया जाएगा कि वे वह टीम है जो इसका मालिक है, ताकि जब वह समाप्त हो जाए तो उन्हें नया मिल जाए।


1
व्यवहार में हालांकि एक्सपायरिंग कीज़ को अपनाने वाले आवेदन के लिए बहुत अधिक बाधा हो सकती है - मैं प्रबंधकों को "फ़गगेटबाउट" कहकर देख सकता हूं क्योंकि यह अभी बाद में परेशान करने वाला है।
दाविदबक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.