प्रत्येक एकीकरण को अपनी अलग कुंजी दें।

बनाने से पहले दायरे तय करें

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

सावधानी से प्रकट करें और निजी तौर पर संग्रहीत करें

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

निरसन को व्यावहारिक बनाएं

प्रत्येक एकीकरण के लिए अलग क्रेडेंशियल जारी करें ताकि सब कुछ रोके बिना एक को रद्द किया जा सके। जानबूझकर रोटेट करें और सत्यापित करें कि पुरानी कुंजी अब काम नहीं करती। सीमित ऑडिट रिकॉर्ड के साथ अप्रत्याशित उपयोग की जाँच करें।

सीमाओं का परीक्षण करें

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

उम्मीदवार कुंजी नीति

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

अनुरोध उजागर किए बिना ऑडिट करें

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

प्रत्येक ऑटोमेशन को अपना अलग क्रेडेंशियल दें

बैकअप चेकर, परिनियोजन वर्कर और बिलिंग एकीकरण को समान पूर्ण-पहुँच कुंजी साझा नहीं करनी चाहिए। कुंजी को उसके कार्य के अनुसार नाम दें, न्यूनतम दायरा दें और दर्ज करें कि इसका स्वामी कौन है। इच्छित समूह read, servers, billing और full हैं; जब API उपलब्ध हो तो उनका सटीक संचालन मैपिंग परीक्षण किया जाना चाहिए।

निर्माण, संग्रहण और रोटेशन

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

पहुँच रद्द करें, साक्ष्य नहीं

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

थोड़ी और स्पष्टता।