API Gateway Policies क्या हैं?

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

API गेटवे नीतियां क्या हैं

API गेटवे आमतौर पर सभी अपस्ट्रीम सेवाओं के सामने स्थित होता है। जब कोई उपयोगकर्ता किसी सेवा के लिए अनुरोध भेजता है, तो अनुरोध पहले API गेटवे पर जाएगा, और API गेटवे आमतौर पर कई चीजों की जांच करेगा:

1. जांच करेगा कि अनुरोध कानूनी है या नहीं। क्या यह उन उपयोगकर्ताओं की सूची से है जिन्हें पहुंच से प्रतिबंधित किया गया है?
2. जांच करेगा कि अनुरोध प्रमाणित है और पहुंचा गया सामग्री अधिकृत है।
3. जांच करेगा कि अनुरोध विशिष्ट प्रतिबंध नियमों को ट्रिगर करता है, जैसे दर सीमा।
4. जांच करेगा कि किस अपस्ट्रीम सेवा को फॉरवर्ड किया जाए।

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

API गेटवे Apache APISIX को उदाहरण के रूप में लेते हुए, APISIX की दो प्रकार की कॉन्फ़िगरेशन जानकारी होती है: गेटवे स्टार्टअप के लिए कॉन्फ़िगरेशन फ़ाइल, जैसे config.yaml, यह फ़ाइल गेटवे को सामान्य रूप से शुरू करने के लिए आवश्यक कुछ कॉन्फ़िगरेशन निर्धारित करती है। इसके अलावा, प्रशासक रनटाइम में Admin API के माध्यम से विभिन्न नियम और कॉन्फ़िगरेशन बना सकते हैं, जैसे Route, Consumer, Plugin, आदि। API गेटवे की नीतियां प्रशासक द्वारा Admin API के माध्यम से गतिशील रूप से बनाए गए विभिन्न नियम और कॉन्फ़िगरेशन होते हैं।

यह लेख चार API गेटवे, प्रमाणीकरण और अधिकार, सुरक्षा, ट्रैफिक प्रसंस्करण, और ऑब्जर्वेबिलिटी के परिदृश्यों पर विस्तार से चर्चा करेगा, और प्रत्येक परिदृश्य के तहत API गेटवे नीतियां कैसे काम करती हैं।

प्रमाणीकरण और अधिकार नीति

प्रमाणीकरण API कॉलर की पहचान की पुष्टि कर सकता है, और अधिकार कॉलर को केवल अधिकार के दायरे में संसाधनों तक पहुंचने की अनुमति देता है।

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

बेसिक ऑथ

बेसिक एक्सेस प्रमाणीकरण नीति सबसे सरल पहुंच नियंत्रण तकनीक है। आमतौर पर, उपयोगकर्ता का HTTP प्रॉक्सी अनुरोध भेजते समय प्रमाणीकरण के लिए एक अनुरोध हेडर ले जाता है, जो आमतौर पर होता है: Authorization: Basic <credentials>, और credentials में उपयोगकर्ता प्रमाणीकरण के लिए आवश्यक उपयोगकर्ता ID और पासवर्ड शामिल होते हैं, जो : द्वारा अलग किए जाते हैं। इस विधि को लॉगिन पृष्ठ और कुकीज़ जैसे जटिल सेटिंग्स की आवश्यकता नहीं होती है। यह अनुरोध हेडर में सरल क्रेडेंशियल जानकारी के आधार पर प्रमाणित होता है, आमतौर पर एक उपयोगकर्ता नाम और पासवर्ड, जो कॉन्फ़िगर और उपयोग करने में सरल है।

बेसिक प्रमाणीकरण के साथ एक cURL अनुरोध का उदाहरण निम्नलिखित है, username और password के साथ:

curl -i -u 'username:password' http://127.0.0.1:8080/hello

यह ध्यान दिया जाना चाहिए कि credentials में जानकारी ट्रांसमिशन के दौरान एन्क्रिप्ट नहीं की जाएगी। यह केवल base64 एन्कोडेड होता है, इसलिए आमतौर पर इसे HTTPS के साथ उपयोग करने की आवश्यकता होती है ताकि पासवर्ड की सुरक्षा सुनिश्चित हो सके।

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

की ऑथ

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

APISIX के key-auth प्लगइन को उदाहरण के रूप में लेते हुए। प्लगइन को Admin API के माध्यम से एक अद्वितीय कुंजी मान के साथ एक Consumer बनाने की आवश्यकता होती है:

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack-key"
        }
    }
}'

यह अनुरोध jack नामक एक Consumer बनाता है जिसमें कुंजी मान jack-key होता है।

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

curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'

एक बार APISIX को यह अनुरोध प्राप्त होता है, APISIX कुंजी को पार्स करेगा और सभी कॉन्फ़िगर की गई कुंजियों से Consumer jack को मिलाएगा। इसलिए गेटवे को पता चलेगा कि अनुरोध jack द्वारा भेजा गया है। यदि कोई मिलान कुंजी नहीं मिलती है, तो इसे अवैध अनुरोध माना जा सकता है।

JSON वेब टोकन

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

API गेटवे में, JWT प्रमाणीकरण को JWT नीति के माध्यम से गेटवे में जोड़ा जा सकता है। इसलिए, हम प्रमाणीकरण तर्क को व्यावसायिक कोड से अलग कर सकते हैं, और डेवलपर्स व्यावसायिक तर्क को लागू करने पर अधिक ध्यान केंद्रित कर सकते हैं। APISIX के jwt-auth प्लगइन को उदाहरण के रूप में लेते हुए। प्लगइन को Consumer में सक्षम और कॉन्फ़िगर करने की आवश्यकता होती है जिसमें इसकी अद्वितीय कुंजी, एन्क्रिप्शन के लिए सार्वजनिक और निजी कुंजी, एन्क्रिप्शन एल्गोरिथ्म, टोकन समाप्ति समय, आदि शामिल होते हैं। साथ ही, आपको रूट में इस प्लगइन को सक्षम करने और गेटवे को टोकन के स्थान और फ़ील्ड को पढ़ने के लिए कॉन्फ़िगर करने की आवश्यकता होती है, जैसे हेडर, क्वेरी, कुकी, आदि। यह प्लगइन API गेटवे में टोकन जारी करने के लिए एक API जोड़ेगा। अनुरोध भेजने से पहले, टोकन जारी करने वाले API को अनुरोध करने की आवश्यकता होती है। अनुरोध भेजते समय, कॉन्फ़िगरेशन जानकारी के अनुसार टोकन को निर्दिष्ट स्थान पर ले जाने की आवश्यकता होती है। अनुरोध गेटवे तक पहुंचने के बाद, गेटवे कॉन्फ़िगरेशन जानकारी के अनुसार अनुरोध के निर्दिष्ट स्थान से टोकन को पढ़ेगा और टोकन की वैधता की जांच करेगा। सत्यापन पर अनुरोध को अपस्ट्रीम सेवा को फॉरवर्ड किया जा सकता है।

पिछले दो रणनीतियों की तुलना में, JWT नीति में समाप्ति समय का विकल्प शामिल होता है। जारी किया गया टोकन समय के साथ समाप्त हो सकता है, लेकिन बेसिक ऑथ और की ऑथ की वैधता स्थायी होती है जब तक कि सर्वर पासवर्ड या कुंजी को नहीं बदलता है। इसके अलावा, JWT नीति को कई सेवाओं के बीच साझा किया जा सकता है, जो सिंगल साइन-ऑन (SSO) परिदृश्यों के लिए फायदेमंद है।

ओपनआईडी कनेक्ट

ओपनआईडी कनेक्ट OAuth2.0 प्रोटोकॉल पर आधारित एक प्रमाणीकरण और अधिकार विधि है, जो एक अपेक्षाकृत पूर्ण एप्लिकेशन समाधान प्रदान करता है। API गेटवे में ओपनआईडी कनेक्ट नीति अपस्ट्रीम सेवा को पहचान प्रदाता (IdP) से उपयोगकर्ता जानकारी प्राप्त करने की अनुमति देगी, जिससे API सुरक्षा सुनिश्चित होगी। सामान्य IdP हैं Keycloak, Ory Hydra, Okta, Auth0, आदि। Apache APISIX को उदाहरण के रूप में लेते हुए, गेटवे में ओपनआईडी कनेक्ट नीति का कार्यप्रवाह निम्नलिखित है:

1. क्लाइंट गेटवे को अनुरोध भेजता है
2. अनुरोध प्राप्त करने के बाद, गेटवे IdP को प्रमाणीकरण अनुरोध भेजता है
3. उपयोगकर्ता को IdP द्वारा प्रदान किए गए पृष्ठ पर लॉगिन प्रमाणीकरण पूरा करने के लिए रीडायरेक्ट किया जाएगा
4. IdP प्रमाणीकरण कोड के साथ गेटवे पर रीडायरेक्ट करता है
5. गेटवे कोड के माध्यम से IdP से एक्सेस टोकन अनुरोध करता है ताकि उपयोगकर्ता जानकारी प्राप्त हो सके
6. गेटवे अनुरोध को अपस्ट्रीम फॉरवर्ड करते समय उपयोगकर्ता जानकारी ले जा सकता है

यह प्रक्रिया प्रमाणीकरण और अधिकार को व्यवसाय से अलग करती है, जिससे आर्किटेक्चर अधिक सूक्ष्म हो जाता है।

APISIX प्रमाणीकरण और अधिकार विधियों के बारे में अधिक जानकारी के लिए, कृपया API गेटवे प्रमाणीकरण देखें।

सुरक्षा नीति

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

निम्नलिखित कुछ महत्वपूर्ण API गेटवे सुरक्षा नीतियां हैं:

IP पहुंच प्रतिबंध

IP प्रतिबंध नीति कुछ विशिष्ट IPs या CIDR को एक allowlist या denylist में सेट करके विशिष्ट क्लाइंट्स को API तक पहुंच को प्रतिबंधित करती है ताकि संवेदनशील डेटा के दुर्भावनापूर्ण पहुंच को रोका जा सके। इस नीति को सही ढंग से कॉन्फ़िगर करने से API की सुरक्षा में काफी सुधार होगा और उच्च API सुरक्षा प्रशासन सक्षम होगा।

URI ब्लॉकर

URI ब्लॉकिंग नीति कुछ URI नियमों को सेट करके संभावित खतरनाक API अनुरोधों को अवरुद्ध करती है। उदाहरण के लिए, कुछ सुरक्षा हमले URI पथ को सूंघकर संभावित कमजोरियों का पता लगाते हैं और फिर हमला करते हैं। Apache APISIX uri-blocker प्लगइन प्रदान करता है जो खतरनाक API अनुरोधों को अवरुद्ध करता है। कोई uri-blocker प्लगइन के माध्यम से नियमित अभिव्यक्तियों को भी सेट कर सकता है। यदि अनुरोध नियम से मेल खाता है, तो API गेटवे अनुरोध को अवरुद्ध कर देगा। उदाहरण के लिए, यदि हम root.exe, admin कॉन्फ़िगर करते हैं, तो यह प्लगइन */root.exe और */admin अनुरोधों को अवरुद्ध कर सकता है ताकि API सुरक्षा को और बढ़ाया जा सके।

CORS

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

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

CSRF

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

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

ट्रैफिक प्रसंस्करण नीति

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

दर सीमा

सीमित संसाधनों के मामले में, API द्वारा प्रदान की जाने वाली सेवा क्षमता की एक सीमा होती है। यदि कॉल इस सीमा से अधिक हो जाता है, तो अपस्ट्रीम सेवा क्रैश हो सकती है और कुछ चेन रिएक्शन का कारण बन सकती है। दर सीमा ऐसे मामलों से बचा सकती है और DDOS (डिनायल-ऑफ-सर्विस अटैक) से API को बचा सकती है।

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

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

सर्किट ब्रेकिंग

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

इस नीति में, यह भी सेट करना आवश्य