नियोजित काम की मानवी लॉगिन: API ने कोणती ओळख पाहावी?

नियोजित काम आणि लॉगिन सूचनेसमोर उभी असलेली व्यक्ती एकाच API ला वेगवेगळ्या क्रेडेन्शियल्ससह, वेगळ्या आयुष्यासह आणि वेगळ्या मालकांसह कॉल करतात। कामाला नेटवर्क मार्ग, अनुप्रयोग ओळख आणि परवानग्यांचा संच आवश्यक आहे; व्यक्तीला लॉगिन, दुसरा घटक आणि सत्र आवश्यक आहे। दोन्ही मिसळल्यास व्यक्तीचा पासवर्ड बदलला की तुटणारे स्वयंचलन, किंवा cron काम जिवंत ठेवण्यासाठी तितकेच कमकुवत केलेले बहु-घटक धोरण तयार होते।

एकासारखे दिसणारे तीन दरवाजे

स्रोत-पत्ता नियम विचारतो की विनंती कुठून आली। प्रमाणीकरण विचारते की कोण कॉल करत आहे आणि कोणते पुरावे सादर केले। अधिकृतता विचारते की हा प्रिन्सिपल ही क्रिया करू शकतो का। VPN तीनपैकी फक्त पहिला बदलतो, आणि तो कामासाठीच नव्हे तर होस्टवरील प्रत्येक प्रक्रियेसाठी बदलतो, म्हणून घटना नोंदीत तीन निरीक्षणे वेगळी ठेवा।

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

परस्परसंवादी मार्ग स्वयंचलनासाठी वाईट टेम्पलेट आहे

व्यक्तीचे लॉगिन स्क्रिप्टमध्ये लिहिणे आकर्षक आहे कारण ते एकदा चालते। स्क्रिप्ट पासवर्ड, कदाचित एक-वेळ-पासवर्डची बीजे साठवते आणि नंतर माणूस आवश्यक असलेल्या पद्धतीने तयार केलेल्या आव्हानावर अवलंबून राहते। OAuth साठीची सध्याची सर्वोत्तम सुरक्षा पद्धत, RFC 9700, resource-owner-password-credentials अनुदान प्रतिबंधित करते आणि ते दोन-घटक व बहु-टप्पा प्रमाणीकरणाशी का वाईट जुळते हे स्पष्ट करते।

समर्थित पर्याय सहसा गोपनीय-क्लायंट प्रवाह असतो, ज्यात अधिकृतता सर्व्हर अनुप्रयोगाचे प्रमाणीकरण करतो आणि टोकन देते। RFC 6749 च्या कलम 4.4 मधील client-credentials अनुदान हे त्याचे एक उदाहरण आहे। त्याचे अस्तित्व म्हणजे प्रत्येक API ते स्वीकारते किंवा वापरकर्त्याने प्रत्यायोजित केलेले काम त्याने बदलता येते असा अर्थ नाही, कारण ते सेवा मालकासाठीचे प्रश्न आहेत। कोड लिहिण्यापूर्वी सेवा कोणते देखरेख-मुक्त मॉडेल समर्थते विचारा।

VPN अजूनही कुठे योग्य आहे

VPN खाजगी API ला आवश्यक असलेला नेटवर्क मार्ग देऊ शकतो, आणि ती वैध भूमिका आहे। तो कामाचे अनुप्रयोगासमोर प्रमाणीकरण करत नाही, आणि काम काय करू शकते याची व्याप्ती ठरवत नाही। सामायिक एग्रेस पत्ता कामाची नव्हे तर होस्टची ओळख करतो, म्हणून त्या पत्त्यासाठीच्या अनुमत-यादीतील नोंद तिथे चालणाऱ्या प्रत्येक प्रक्रियेला प्रवेश देते।

काम सामायिक रनरवर चालत असेल, तर हा फरक कमी नव्हे तर जास्त महत्त्वाचा आहे। त्याच होस्टवरील दुसरा कार्यप्रवाह मार्ग आणि पत्ता वारसा घेतो, आणि API दोन्ही वेगळे करू शकत नाही। ही सामायिक पासवर्डसारखीच कमकुवतता आहे, एक थर खाली सरकवलेली। बंधन तिथे ठेवा जिथे अनुप्रयोग ते लागू करू शकतो, आणि अनुमत-यादी अधिक संकुचित करता येत नसेल तर रनर वेगळा ठेवा।

दोन्ही रचनांची प्रामाणिकपणे तुलना करा

मानवी लॉगिन तुम्हाला खरा माणूस, खरा दुसरा घटक आणि लेखापरीक्षणयोग्य सत्र देते, आणि ते देखरेखीशिवाय चालू शकत नाही। अनुप्रयोग ओळख तुम्हाला देखरेख-मुक्त अंमलबजावणी, पुनर्विलोकनयोग्य व्याप्ती आणि फिरवता येणारे क्रेडेन्शियल देते, आणि ती काहीही प्रत्यायोजित न केलेल्या वापरकर्त्याच्या वतीने कार्य करू शकत नाही। दोन्हीपैकी कोणतेही दुसऱ्याची कमकुवत आवृत्ती नाही; ते वेगळ्या प्रश्नांची उत्तरे देतात। काम कोणत्याही व्यक्तीशिवाय चालावे का आणि क्रिया विशिष्ट वापरकर्त्याला मानावी का, हे विचारून निवडा।

दोन्ही उत्तरे होय असतील, तर रचनेला उधार घेतलेला पासवर्ड नव्हे तर प्रत्यायोजन मॉडेल आवश्यक आहे। तो निर्णय पुढील देखभालकर्त्याला सापडेल तिथे लिहा।

हस्तांतरणापूर्वी काय पडताळावे

खऱ्या वर्करकडून एक परवानगी असलेली क्रिया आणि एक अनिवार्य नकार चालवा, आणि दोन्ही निकाल ठेवा। नंतर कालबाह्य क्रेडेन्शियल आणि नेटवर्क मार्ग उपलब्ध नसताना होणारे वर्तन तपासा, कारण रात्री कोणालातरी जागवणाऱ्या या दोनच अपयशी आहेत।

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

प्रिन्सिपल, व्याप्ती, फिरवणीचा मालक आणि अंमलबजावणी वातावरण त्या निकालाच्या शेजारी नोंदवा। तीच नोंद पुढील फिरवणीला घटना नव्हे तर नित्यक्रम बनवते। लेखापरीक्षक मागतो तो भागही तोच आहे।