OWASP मुख्य 10 API खतरे

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. info

इस दस्तावेज़ में, OWASP की ओर से पहचानी गई सुरक्षा से जुड़ी कमियों को ठीक करने के लिए, Apigee में इस्तेमाल किए जा सकने वाले अलग-अलग तरीकों के बारे में बताया गया है. Apigee के लिए दस्तावेज़ में बताए गए अन्य तरीकों के बारे में जानने के लिए, Google Cloud पर OWASP Top 10 2021 के जोखिमों को कम करने के विकल्प लेख पढ़ें.

परिचय

OWASP एक ओपन कम्यूनिटी है. यह संगठनों को भरोसेमंद ऐप्लिकेशन और एपीआई डेवलप करने, खरीदने, और उन्हें बनाए रखने में मदद करती है. OWASP API Security project के ज़रिए, OWASP वेब ऐप्लिकेशन और REST API के लिए सुरक्षा से जुड़े सबसे अहम जोखिमों को पब्लिश करता है. साथ ही, इन जोखिमों को दूर करने के लिए सुझाव देता है.

इस दस्तावेज़ में, एपीआई पर होने वाले सामान्य हमलों से बचने के तरीकों के बारे में बताया गया है. इन हमलों की पहचान, OWASP ने 2019 में एपीआई की सुरक्षा से जुड़े सबसे बड़े दस खतरों के तौर पर की थी. हाल ही की सूची में, सबसे ज़्यादा खतरे वाली समस्याओं के बारे में बताया गया है. ये समस्याएं, पुष्टि करने और अनुमति देने वाले कंट्रोल को सही तरीके से लागू न करने की वजह से होती हैं. जैसे, क्लाइंट ऐप्लिकेशन में एपीआई अनुरोध से मिले डेटा को फ़िल्टर करने पर भरोसा करना. इसके अलावा, ऐक्सेस कंट्रोल लागू करने के लिए, क्लाइंट ऐप्लिकेशन का इस्तेमाल करने पर भरोसा करना.

एपीआई के इकोसिस्टम में तेज़ी से बढ़ोतरी हो रही है. इसलिए, एपीआई का गलत इस्तेमाल और दुरुपयोग करने के मामले भी बढ़ रहे हैं. इससे हमलावर, डेटा को चुरा रहे हैं. अफ़सोस की बात है कि आज यह हमला करने का सबसे सामान्य तरीका बन गया है. Apigee के लिए सुरक्षा अब भी एक अहम प्राथमिकता है. इसमें कई नई सुविधाएं शामिल हैं. जैसे, ऐडवांस एपीआई ऑपरेशंस. इसमें गड़बड़ी की पहचान करने वाली सुविधाएं शामिल हैं. हालांकि, Apigee की सुरक्षा सुविधाओं को सही तरीके से डिज़ाइन और लागू करना ज़रूरी है. इससे आपके एपीआई पर होने वाले हमलों को कम किया जा सकता है.

उपयोगकर्ता के ऐप्लिकेशन को अविश्वसनीय या “सार्वजनिक” माना जाना चाहिए, क्योंकि आपके पास उस प्लैटफ़ॉर्म का कंट्रोल नहीं होता जिस पर ऐप्लिकेशन चल रहा है. मान लें कि किसी भी सार्वजनिक ऐप्लिकेशन से समझौता किया जा सकता है. इसलिए, इन पर भरोसा नहीं किया जा सकता कि ये ऐक्सेस कंट्रोल (API1, API5) लागू करेंगे, जवाब के डेटा को फ़िल्टर करेंगे (API6) या क्लाइंट के सीक्रेट (API2), जैसे कि एपीआई कुंजियां या ऐक्सेस टोकन को सुरक्षित तरीके से सेव करेंगे. साल 2019 के OWASP टॉप 10 की जांच करने के बाद, कुछ सुझाव मिले हैं:

  • तय करें कि आपके एपीआई का इस्तेमाल किस तरह के क्लाइंट ऐप्लिकेशन (एसपीए, मोबाइल या ब्राउज़र पर आधारित) करेंगे. इसके बाद, पुष्टि करने, अनुमति देने, और सुरक्षा के सही पैटर्न डिज़ाइन करें.
  • हमेशा “सार्वजनिक क्लाइंट” OAuth या OpenID Connect फ़्लो का इस्तेमाल करें. हमारा सुझाव है कि आप PKCE का इस्तेमाल करें
  • अपने ऐप्लिकेशन के कारोबारी नियमों के बारे में सोचें. सबसे पहले, OpenAPI स्पेसिफ़िकेशन तय करें. इसके बाद, Apigee में बैकएंड से मिले सभी जवाबों के डेटा को फ़िल्टर करने के लिए, एपीआई प्रॉक्सी डिज़ाइन करें. यह काम करने के लिए, कभी भी डाउनस्ट्रीम ऐप्लिकेशन के कोड लॉजिक पर भरोसा न करें!
  • उपयोगकर्ता की निजी पहचान से जुड़ी जानकारी (पीआईआई) वाले सभी डेटा अनुरोधों को फ़िल्टर करें, ताकि सिर्फ़ आपके बैकएंड से मिले उस डेटा को अनुमति दी जा सके जो अनुरोध करने वाले उपयोगकर्ता से जुड़ा है.

API1:2019 ब्रोकन ऑब्जेक्ट लेवल ऑथराइज़ेशन

खतरे की जानकारी

किसी ऑब्जेक्ट के ऐक्सेस के अनुरोध की पुष्टि करने के लिए, अनुमति की पुष्टि करने की प्रोसेस सही तरीके से न होने पर, हमलावर ऐक्सेस टोकन का फिर से इस्तेमाल करके, बिना अनुमति के कार्रवाई कर सकता है. यह खतरा, पुष्टि करने की प्रोसेस के गलत कॉन्फ़िगरेशन की वजह से होता है. Apigee, VerifyApiKey, OAuth, और JSON वेब टोकन (JWT) नीतियां उपलब्ध कराता है. ये नीतियां, इस जोखिम की आशंका से बचाने में मदद करती हैं. हालांकि, यह ज़रूरी है कि इन नीतियों को सही तरीके से कॉन्फ़िगर किया जाए, ताकि इस खतरे को रोका जा सके.

इस खतरे को रोकने के लिए, यह ज़रूरी है कि ऐप्लिकेशन डेवलपमेंट और सुरक्षा टीमें साथ मिलकर काम करें. अनुमति देना एक जटिल विषय है. साथ ही, बेहतर तरीके से अनुमति देने के लिए, ऐप्लिकेशन के कारोबारी नियमों को समझना ज़रूरी है.

Apigee को लागू करने के नज़रिए से, इन दो मुख्य पहलुओं पर ध्यान देना ज़रूरी है:

  • ऐक्सेस टोकन की पुष्टि करना
  • ऐक्सेस कंट्रोल लागू करना

ऐक्सेस टोकन की पुष्टि

यह पुष्टि करना ज़रूरी है कि अनुरोध करने वाले क्लाइंट से मिले टोकन में कोई बदलाव नहीं किया गया है. इसके लिए, सही OAuth या OpenID Connect फ़्लो के साथ-साथ क्रेडेंशियल की पुष्टि करने या हस्ताक्षर करने के सही तरीके का इस्तेमाल करें. Apigee, आम तौर पर इस्तेमाल किए जाने वाले सभी OAuth फ़्लो के साथ काम करता है.

Apigee के ऐक्सेस टोकन की पुष्टि करने वाली नीतियों में ये शामिल हैं:

ऐक्सेस कंट्रोल लागू करना

ऐक्सेस टोकन की वैधता की पुष्टि हो जाने के बाद, ऐक्सेस कंट्रोल लागू करने से जुड़ी नीतियों को लागू करना ज़रूरी है. इससे, आने वाले हर एपीआई अनुरोध का आकलन, अनुमति वाले टोकन के ऐक्सेस एनटाइटलमेंट के हिसाब से किया जा सकता है.

Apigee, अनुमति देने से जुड़ी नीतियों की पुष्टि करने और उन्हें लागू करने के लिए दो मुख्य तरीके उपलब्ध कराता है:

  • इंटरनल: शर्तों के हिसाब से फ़्लो का इस्तेमाल करके, ऐक्सेस के अनुरोधों का आकलन करना. इसके लिए, ऑथराइज़ेशन टोकन से फ़्लो वैरिएबल के तौर पर निकाले गए दावों का इस्तेमाल किया जाता है
  • सौंपा गया: तीसरे पक्ष के ऐक्सेस मैनेजमेंट समाधान के लिए, सेवा कॉलआउट का इस्तेमाल करना

अगर ऐक्सेस कंट्रोल मॉडल काफ़ी आसान है, तो इंटरनल अप्रोच (ऊपर दिए गए डायग्राम में दिखाया गया है) का इस्तेमाल करने का सुझाव दिया जाता है. उदाहरण के लिए, अगर किसी ऐक्सेस टोकन से निकाले गए दावों का इस्तेमाल, एपीआई ऑब्जेक्ट के अनुरोध का सीधे तौर पर आकलन और पुष्टि करने के लिए किया जा सकता है.

OAuth या JWT नीतियों के लिए उपलब्ध फ़्लो वैरिएबल का इस्तेमाल करके, शर्तों वाले फ़्लो स्टेटमेंट का इस्तेमाल करके ऐक्सेस के अनुरोधों का आकलन करें.

डेलिगेट किए गए तरीके (ऊपर दिए गए डायग्राम में दिखाया गया है) का इस्तेमाल तब करने का सुझाव दिया जाता है, जब ऐक्सेस टोकन से निकाले गए दावों का इस्तेमाल, बैकएंड ऑब्जेक्ट के लिए एपीआई अनुरोध को सीधे तौर पर अनुमति देने के लिए नहीं किया जा सकता. इसके अलावा, इसका इस्तेमाल OAuth फ़्लो के ज़्यादा जटिल टाइप के लिए भी किया जा सकता है. इसके लिए, ऐक्सेस टोकन पाने के लिए ऑथराइज़ेशन सर्वर को अलग से कॉल करना पड़ता है.

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

API2:2019 उपयोगकर्ता की पुष्टि करने की प्रोसेस में गड़बड़ी

खतरे की जानकारी

उपयोगकर्ता की पुष्टि करने से जुड़ी नीतियों को सही तरीके से लागू न करने पर, हमलावर असली उपयोगकर्ताओं के नाम पर काम कर सकते हैं. ऐसा वे पुष्टि करने की प्रोसेस में मौजूद कमियों का फ़ायदा उठाकर करते हैं. पुष्टि करने के तरीकों को लागू करते समय, पुष्टि करने के कुछ सिद्धांतों को ध्यान में रखना चाहिए. इनमें ये शामिल हैं:

  • हमेशा उपयोगकर्ता एजेंट (ऐप्लिकेशन) और अनुरोध करने वाले उपयोगकर्ता, दोनों की पुष्टि करें
  • डेलिगेट किए गए पुष्टि करने और अनुमति देने के पैटर्न का इस्तेमाल करें. साथ ही, एपीआई अनुरोध में सीधे तौर पर पासवर्ड न डालें
  • हमेशा ऐक्सेस क्रेडेंशियल के हस्ताक्षर की पुष्टि करें. साथ ही, यह पक्का करें कि इस्तेमाल किए गए सभी ऐक्सेस क्रेडेंशियल की समयसीमा तय की गई हो
  • कोटा सेट करके और Apigee Sense का इस्तेमाल करके, ब्रूट फ़ोर्स हमलों को रोकें. साथ ही, बॉट की मदद से किए जाने वाले ब्रूट फ़ोर्स हमलों का पता लगाएं और उनका जवाब दें

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

यहां कुछ मुख्य बातों का ध्यान रखना ज़रूरी है. इन दोनों के बारे में अगले सेक्शन में बताया जाएगा:

  • सुरक्षा डिज़ाइन: पुष्टि करने के पैटर्न लागू करने के लिए, Apigee की सुविधाओं का पूरा इस्तेमाल करना
  • गवर्नेंस: यह पक्का करना कि डिज़ाइन किए गए पुष्टि करने के पैटर्न का सही तरीके से इस्तेमाल किया जा रहा हो. साथ ही, पब्लिश किए गए सभी एपीआई प्रॉडक्ट में इनका लगातार इस्तेमाल किया जा रहा हो
  • ऑपरेशनल सिक्योरिटी: संदिग्ध या असामान्य गतिविधियों का पता लगाना. साथ ही, पुष्टि की गई एपीआई प्रॉक्सी को बाईपास करने या उन पर ब्रूट फ़ोर्स अटैक करने की कोशिशों का पता लगाना

सुरक्षा डिज़ाइन

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

OpenID Connect और OAuth RFC, पुष्टि करने और अनुमति देने के लिए कई तरह के फ़्लो उपलब्ध कराते हैं. साथ ही, इन फ़्लो में शामिल लोगों के बारे में भी जानकारी देते हैं. यह एक मुश्किल विषय है. इसलिए, इसमें कोई हैरानी की बात नहीं है कि पुष्टि करने की प्रोसेस में गड़बड़ी, OWASP API के लिए सबसे ज़्यादा खतरनाक है. इस दस्तावेज़ में, पहचान के मानकों को सही तरीके से लागू करने के बारे में पूरी जानकारी नहीं दी गई है. हालांकि, Apigee के पास OAuth फ़्लो को बेहतर तरीके से समझने के लिए कई अतिरिक्त संसाधन हैं. जैसे, यह ई-बुक और वेबकास्ट, और लागू करने का उदाहरण.

पुष्टि करने से जुड़ी नीतियां

Apigee की ऐसी नीतियां जो पहचान और पुष्टि से जुड़ी समस्याओं को हल करने में मदद करती हैं:

ट्रैफ़िक मैनेजमेंट

Apigee की ट्रैफ़िक मैनेजमेंट से जुड़ी ये सुविधाएं, ब्रूट फ़ोर्स अटैक से बचाने में मदद करती हैं:

  • एपीआई प्रॉक्सी पर रोलिंग ऐवरेज रेट लिमिट सेट करने के लिए, स्पाइक अरेस्ट नीति
  • कोटा नीतियां, ऐप्लिकेशन की कुंजियों, डेवलपर या एपीआई प्रॉडक्ट के कोटा के आधार पर, एपीआई प्रॉक्सी के लिए दर की सीमाएं सेट करने के लिए
  • कैशिंग की नीतियां, तय की गई समयसीमा के आधार पर सेव किए गए ऐक्सेस टोकन को कैश करने के लिए. साथ ही, कैश किए गए क्रेडेंशियल को अमान्य करने की सुविधा (उदाहरण के लिए, ऐसी स्थिति में जहां मान्य ऐक्सेस टोकन से समझौता किया गया हो)

मैनेज करना

सुरक्षा एक लगातार चलने वाली प्रोसेस है. यह “सेट करो और भूल जाओ” वाला प्रोजेक्ट नहीं है. सुरक्षा से जुड़े उल्लंघनों की सबसे बड़ी वजहों में से एक, गलत कॉन्फ़िगरेशन है. पुष्टि करने के फ़्लो, पहचान के इंटिग्रेशन के पैटर्न, और पुष्टि से जुड़े ट्रैफ़िक मैनेजमेंट की नीतियां तय करने के बाद, यह बहुत ज़रूरी है कि उन्हें सही तरीके से और लगातार लागू किया जाए.

Apigee, एपीआई को सही तरीके से लागू करने और कॉन्फ़िगरेशन से जुड़ी गड़बड़ियों को रोकने के लिए कई सुविधाएं और टूल उपलब्ध कराता है.

भूमिका के हिसाब से ऐक्सेस कंट्रोल (आरबीएसी)

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

Apigee, भूमिका के आधार पर ऐक्सेस मैनेज करने की सुविधाएं देता है. इसके लिए, यह आपको उपयोगकर्ताओं को पहले से तय की गई भूमिकाएं असाइन करने की सुविधा देता है. इसके अलावा, यह आपको अपनी एपीआई टीमों के हिसाब से कस्टम भूमिकाएं बनाने की सुविधा भी देता है. भूमिका असाइनमेंट को सही तरीके से तय करना और मैनेज करना ज़रूरी है. इससे, आपको अपने एपीआई प्रोग्राम को सुरक्षित तरीके से बढ़ाने में मदद मिलती है. अपनी मौजूदा कॉर्पोरेट डायरेक्ट्री के साथ इंटिग्रेट करने के लिए, फ़ेडरेशन का इस्तेमाल भी किया जा सकता है. इससे Apigee में एडमिन के क्रेडेंशियल के दूसरे सेट को मैनेज करने की ज़रूरत कम हो जाती है.

शेयर किए गए फ़्लो

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

डायग्राम: शेयर किए गए फ़्लो, नीतियों और शर्तों के लॉजिक के ऐसे बंडल होते हैं जिन्हें फिर से इस्तेमाल किया जा सकता है. इनकी मदद से, कंपोज़िट पैटर्न को बनाए रखा जा सकता है.

ऑपरेशनल सिक्योरिटी

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

Apigee Sense

Apigee Sense आपके एपीआई को अनचाहे अनुरोध ट्रैफ़िक से बचाता है. इसमें हैकर के हमलों से भी सुरक्षा मिलती है. Apigee Sense, एपीआई अनुरोध के ट्रैफ़िक का विश्लेषण करता है. इससे ऐसे पैटर्न की पहचान की जाती है जो अनचाहे अनुरोधों को दिखा सकते हैं. इस विश्लेषण का इस्तेमाल करके, ऐसे क्लाइंट की पहचान की जा सकती है जो अनचाहे अनुरोध करते हैं. इसके बाद, उन अनुरोधों को अनुमति देने, ब्लॉक करने या फ़्लैग करने के लिए कार्रवाई की जा सकती है. Sense की आने वाली सुविधाओं में, संदिग्ध ट्रैफ़िक पर ReCAPTCHA की पुष्टि करने की सुविधा अपने-आप चालू होने की सुविधा शामिल होगी.

Apigee Sense की मदद से, अपने एपीआई को अनुरोध के ऐसे पैटर्न से सुरक्षित रखा जा सकता है जिनमें ये शामिल हैं:

  • अपने-आप होने वाली ऐसी गतिविधि जो इंसानों की गतिविधि से मिलती-जुलती हो
  • एक ही आईपी पते से बार-बार कोशिश करना
  • गड़बड़ी की दरें असामान्य हैं
  • क्लाइंट के संदिग्ध अनुरोध
  • डेटा क्रॉल करना
  • कुंजी इकट्ठा करना और पुष्टि करने के लिए ब्रूट फ़ोर्स अटैक
  • गतिविधि में अचानक होने वाली बढ़ोतरी
  • भौगोलिक पैटर्न

Advanced API Ops

Sense को खास तौर पर, बॉट जैसी गतिविधियों का पता लगाने और उनसे निपटने के लिए डिज़ाइन किया गया है. वहीं, Advanced API Ops में अनियमितता का पता लगाने और बेहतर सूचना की परिभाषा, दोनों शामिल हैं.

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

एडवांस एपीआई ऑप्स, एपीआई मॉनिटरिंग की मौजूदा सूचना प्रणाली पर आधारित है. इसमें सूचना के ये बेहतर टाइप जोड़े गए हैं:

  • गड़बड़ी की सूचनाएं. Edge, ट्रैफ़िक और परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाता है. इसके लिए, आपको पहले से यह तय करने की ज़रूरत नहीं होती कि कौनसी समस्याएं हैं. इसके बाद, इन अनियमितताओं के लिए सूचना दी जा सकती है
  • टीएलएस की समयसीमा खत्म होने की सूचनाएं. यह कुकी, टीएलएस सर्टिफ़िकेट की समयसीमा खत्म होने से पहले सूचना दिखाती है

API3:2019 ज़रूरत से ज़्यादा डेटा का ऐक्सेस

खतरे की जानकारी

पब्लिश किया गया एपीआई, ज़रूरत से ज़्यादा डेटा दिखा सकता है. इसके लिए, क्लाइंट ऐप्लिकेशन पर ज़रूरी फ़िल्टरिंग करने की ज़िम्मेदारी होती है. अगर कोई हमलावर सीधे तौर पर एपीआई से क्वेरी करता है, तो वह संवेदनशील डेटा को ऐक्सेस कर सकता है.

एपीआई डिज़ाइन के लिए Apigee के “आउटसाइड-इन” डिज़ाइन के सिद्धांतों में से एक सिद्धांत, डेटा पार्सिमोनी है. अपने यूज़र एक्सपीरियंस (यूएक्स) डिज़ाइनर और डेवलपर के साथ मिलकर काम करें. साथ ही, सिर्फ़ ऐसे एपीआई के ज़रिए डेटा दिखाएं जिनकी ज़रूरत आपके ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) में हो. बैकएंड सिस्टम को सार्वजनिक इस्तेमाल के पैटर्न के लिए नहीं बनाया गया था. इसलिए, Apigee के साथ एपीआई फ़र्स्ट डिज़ाइन का पहला काम यह है कि आपके ग्राहकों और डेवलपर के लिए बेहतरीन एपीआई प्रॉडक्ट उपलब्ध कराने के लिए, कम से कम ज़रूरी डेटा को दिखाया जाए.

Apigee के डिज़ाइन सिद्धांतों में से एक, फिर से इस्तेमाल करने की सुविधा है. सुरक्षा से जुड़ी समस्याओं के अलावा, एपीआई से मिले डेटा को फ़िल्टर करने के लिए किसी ऐप्लिकेशन पर भरोसा करने से, आपको उस फ़िल्टरिंग लॉजिक को हर उस प्लैटफ़ॉर्म पर पोर्ट करना होगा जिसके लिए आपने कोई ऐप्लिकेशन बनाया है.

सुरक्षा के लिहाज़ से, यह खतरा किसी ऐप्लिकेशन को अनुमति लागू करने का अधिकार सौंपने की वजह से होता है. हालांकि, ऐसा अक्सर किसी ऐसे प्लैटफ़ॉर्म या ओएस पर होता है जिसे कंट्रोल करने का अधिकार आपके पास नहीं होता. हम API1 और API2 में पहले ही यह देख चुके हैं कि डेटा को बिना अनुमति के ऐक्सेस किए जाने से रोकने के लिए, पुष्टि करने और अनुमति देने की प्रोसेस को सही तरीके से लागू करना कितना ज़रूरी है.

अगले सेक्शन में, इन कामों के बारे में बताया गया है:

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

जवाबों और अनुरोधों को फिर से लिखना

आम तौर पर, बैकएंड सिस्टम को सार्वजनिक ऐप्लिकेशन या ऐसे सार्वजनिक नेटवर्क पर इस्तेमाल करने के लिए डिज़ाइन नहीं किया जाता जिन पर भरोसा नहीं किया जा सकता. Apigee Edge को इस तरह से डिज़ाइन किया गया है कि इसकी मदद से, सार्वजनिक एपीआई प्रॉडक्ट को डिप्लॉय किया जा सके. साथ ही, यह आपके बैकएंड को ज़्यादा डेटा एक्सपोज़र से बचाता है.

इसके लिए, Apigee तीन मुख्य नीतियों का इस्तेमाल करता है:

  • मैसेज असाइन करें
  • कोड कॉलआउट
  • गड़बड़ी ठीक करना

मैसेज से जुड़ी नीति असाइन करना

Assign Message नीति, एपीआई प्रॉक्सी फ़्लो के दौरान अनुरोध और जवाब के मैसेज में बदलाव करती है या नए मैसेज बनाती है. इस नीति के तहत, आपको इन मैसेज पर ये कार्रवाइयां करने की अनुमति मिलती है:

  • किसी मैसेज में नए फ़ॉर्म पैरामीटर, हेडर या क्वेरी पैरामीटर जोड़ें
  • कॉपी करें एक मैसेज से दूसरी प्रॉपर्टी में मौजूदा प्रॉपर्टी
  • किसी मैसेज से हेडर, क्वेरी पैरामीटर, फ़ॉर्म पैरामीटर, और/या मैसेज पेलोड हटाएं
  • सेट करें किसी मैसेज में मौजूद प्रॉपर्टी की वैल्यू

Assign Message नीति का इस्तेमाल करके, आम तौर पर अनुरोध या जवाब की प्रॉपर्टी जोड़ी, बदली या हटाई जाती हैं. हालांकि, Assign Message का इस्तेमाल करके, कस्टम अनुरोध या जवाब का मैसेज भी बनाया जा सकता है. साथ ही, इसे किसी अन्य टारगेट को भेजा जा सकता है. इसके बारे में कस्टम अनुरोध के मैसेज बनाना लेख में बताया गया है.

कस्टम कोड की मदद से, मुश्किल टेक्स्ट को फिर से लिखना

डेटा को मैनेज करने और फिर से लिखने के ऐसे जटिल नियमों के लिए, JavaScript, Java या Python जैसी प्रोसीजरल भाषाओं का इस्तेमाल किया जा सकता है जिन्हें असाइन मैसेज नीति के तहत लागू नहीं किया जा सकता. एपीआई प्रॉक्सी में कस्टम कोड जोड़ा जा सकता है. इसके बाद, प्रॉक्सी फ़्लो में जोड़ी गई नीतियों से इसे कॉल किया जा सकता है. प्रोसीजरल कोड की सुविधा, फ़्लो वैरिएबल, गड़बड़ियों, और अनुरोध और जवाब के मुख्य हिस्से को आसानी से मैनेज करने के लिए डिज़ाइन की गई है.

प्रोसीजरल कोड की मदद से, ये काम किए जा सकते हैं:

  • जटिल बॉडी वैल्यू बनाना या उनमें बदलाव करना. जैसे, अनुरोध और जवाब की वैल्यू.
  • यूआरएल फिर से लिखें, जैसे कि टारगेट एंडपॉइंट यूआरएल को मास्क करना.

Apigee Edge में, इस्तेमाल की जा सकने वाली भाषाओं के लिए अलग-अलग नीतियां शामिल हैं: JavaScript नीति, Java Callout नीति, और Python Script नीति.

गड़बड़ी ठीक करना

Apigee, Raise Fault टाइप की नीति का इस्तेमाल करके, आपको कस्टम अपवाद हैंडलिंग करने की सुविधा देता है. 'गड़बड़ी की जानकारी दें' नीति, 'मैसेज असाइन करें' नीति का एक रूप है. इसकी मदद से, गड़बड़ी की स्थिति में कस्टम गड़बड़ी का जवाब जनरेट किया जा सकता है.

शेयर किए गए फ़्लो

शेयर किए गए फ़्लो का इस्तेमाल, गड़बड़ी के मैसेज को स्टैंडर्ड बनाने के लिए किया जा सकता है. उदाहरण के लिए, कॉन्फ़िगर की गई उन नीतियों का इस्तेमाल किया जा सकता है जो बैकएंड से किसी खास एचटीटीपी गड़बड़ी कोड का पता लगाती हैं. इन नीतियों का इस्तेमाल, गड़बड़ी के रिस्पॉन्स को फिर से लिखने के लिए किया जा सकता है, ताकि गड़बड़ी का सामान्य मैसेज दिखाया जा सके.

API4:2019 संसाधनों की कमी और अनुरोध संख्या सीमित करने की सुविधा

खतरे की जानकारी

अनुरोध संख्या सीमित करने वाली नीतियों को लागू न करने पर, हमलावर डिनायल ऑफ़ सर्विस अटैक के ज़रिए बैकएंड पर बहुत ज़्यादा लोड डाल सकते हैं.

इस खतरे को इन Apigee सुविधाओं का इस्तेमाल करके आसानी से ठीक किया जा सकता है:

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

कोटा और स्पाइक अरेस्ट नीतियों की मदद से, अनुरोध संख्या सीमित करना

Apigee, अनुरोध संख्या सीमित करने के लिए दो नीतियां उपलब्ध कराता है:

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

स्पाइक अरेस्ट

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

कोटा

Quota नीति की मदद से, अनुरोध के उन मैसेज की संख्या को कॉन्फ़िगर किया जा सकता है जिन्हें एपीआई प्रॉक्सी, तय समयावधि में अनुमति देती है. जैसे, एक मिनट, एक घंटा, एक दिन, एक हफ़्ता या एक महीना. एपीआई प्रॉक्सी को ऐक्सेस करने वाले सभी ऐप्लिकेशन के लिए, एक ही कोटा सेट किया जा सकता है. इसके अलावा, कोटा को इन आधारों पर भी सेट किया जा सकता है:

  • वह प्रॉडक्ट जिसमें एपीआई प्रॉक्सी शामिल है
  • एपीआई का अनुरोध करने वाला ऐप्लिकेशन
  • ऐप्लिकेशन डेवलपर
  • अन्य कई मानदंड

यह नीति, स्पाइक अरेस्ट की तुलना में ज़्यादा बारीकी से काम करती है. आम तौर पर, इसका इस्तेमाल स्पाइक अरेस्ट के साथ-साथ किया जाना चाहिए.

Apigee Sense की मदद से बॉट का पता लगाना

Apigee Sense की मदद से, कुछ क्लाइंट, आईपी रेंज या ऑटोनॉमस सिस्टम संगठनों से मिले अनुरोधों को साफ़ तौर पर अनुमति दी जा सकती है, ब्लॉक किया जा सकता है या फ़्लैग किया जा सकता है. ऐसा उन क्लाइंट या जगहों के आधार पर किया जाता है जो नुकसान पहुंचाने वाली या संदिग्ध गतिविधि करते हैं. Apigee Edge, इन कार्रवाइयों को अनुरोधों पर लागू करता है. इसके बाद, आपकी एपीआई प्रॉक्सी उन्हें प्रोसेस करती हैं. उदाहरण के लिए, “ब्रूट गेसर” (बार-बार अनुमान लगाने वाला) व्यवहार दिखाने वाले किसी आईपी पते की रेंज या क्लाइंट का पता लगाया जा सकता है. इसके बाद, उसे ब्लॉक किया जा सकता है या फ़्लैग किया जा सकता है.

एडवांस एपीआई ऑपरेशंस मॉनिटरिंग की मदद से, खतरों का पता लगाना

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

API5:2019 फ़ंक्शन लेवल पर अनुमति देने की सुविधा ठीक से काम नहीं कर रही है

खतरे की जानकारी

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

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

इस खतरे की आशंका को कम करने के लिए, कॉन्सेप्ट से जुड़े एलिमेंट को आम तौर पर इन हिस्सों में बांटा जाता है:

  • किसकी सुरक्षा की जा रही है? अपने एपीआई प्रॉडक्ट की रणनीति के बारे में सोचें. साथ ही, Apigee API प्रॉक्सी, प्रॉडक्ट, और ऐप्लिकेशन की सुविधाओं के ज़रिए दिखाए जा रहे पाथ और संसाधनों को डिज़ाइन करने के लिए, RESTful के सबसे सही तरीकों का इस्तेमाल करते समय, फ़ंक्शन को लॉजिकल तरीके से सेगमेंट में बांटें.
  • आपके एपीआई संसाधनों को कौन ऐक्सेस कर रहा है? हाई लेवल के पर्सोना तय करें. साथ ही, Apigee की कुछ पुष्टि करने और अनुमति देने की सुविधाओं का इस्तेमाल करके, डिफ़ॉल्ट रूप से “कम से कम विशेषाधिकार” वाले ऐक्सेस एनटाइटलमेंट लागू करें. इन सुविधाओं के बारे में API1 और API2 में बताया गया है.
  • ऐक्सेस से जुड़ी आपकी नीतियां कैसे लागू की जा रही हैं? सभी एपीआई अनुरोधों के यूआरएल पाथ और वर्ब की पुष्टि करने के लिए, शर्तों के साथ काम करने वाले फ़्लो और गड़बड़ियों का इस्तेमाल करें.

आंकड़ा: इस डायग्राम में दिखाया गया है कि Apigee में फ़ंक्शन-लेवल ऑथराइज़ेशन कैसे लागू किया जाएगा. इसमें, ऐक्सेस टोकन में दिए गए स्कोप का इस्तेमाल एनटाइटलमेंट के तौर पर किया जाएगा.

एपीआई प्रॉक्सी, प्रॉडक्ट, और ऐप्लिकेशन के साथ लॉजिकल सेगमेंटेशन

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

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

आंकड़ा: एपीआई प्रॉडक्ट में बंडल किए गए एपीआई संसाधन, एक या उससे ज़्यादा एपीआई से मिल सकते हैं. इसलिए, खपत के टियर और अनुमति की सीमाएं बनाने के लिए, संसाधनों को मिक्स और मैच किया जा सकता है.

OAuth के स्कोप और JWT के दावों की मदद से, फ़ंक्शन-लेवल का ऐक्सेस कंट्रोल

ऊपर बताए गए ऑथराइज़ेशन के तरीके, API1:2019 ब्रोकन ऑब्जेक्ट ऑथराइज़ेशन के लिए ऑब्जेक्ट-लेवल पर बेहतर ऐक्सेस कंट्रोल को लागू करते हैं. हालांकि, फ़ंक्शन लेवल पर सामान्य ऐक्सेस कंट्रोल को लागू करना भी उतना ही ज़रूरी है. क्या अनुरोध करने वाले उपयोगकर्ता को इस यूआरएल पाथ का अनुरोध करने की अनुमति है? इस तरह की नीति को अक्सर हर उपयोगकर्ता के हिसाब से तय किया जाता है. जैसे, ग्राहक, कर्मचारी, एडमिन, इंटरनल या तीसरे पक्ष का डेवलपर.

गलत कॉन्फ़िगरेशन के जोखिम को कम करने के लिए, हमारा सुझाव है कि आप अपनी सुरक्षा टीम के साथ मिलकर काम करें. इससे यह पक्का किया जा सकेगा कि अनुरोध करने वाले उपयोगकर्ता के बारे में दावे, ऐक्सेस टोकन में शामिल हों. ऐसा OAuth स्कोप या JWT दावों का इस्तेमाल करके किया जा सकता है.

कंडिशनल फ़्लो के साथ पुष्टि करने का अनुरोध करना

बुनियादी तौर पर, REST API कॉल में ये शामिल होते हैं:

  • एंडपॉइंट
  • कोई संसाधन
  • ऐक्शन वर्ब
  • अनुरोध के लिए कोई भी अतिरिक्त एट्रिब्यूट, जैसे कि क्वेरी पैरामीटर

इस थ्रेट में बताए गए अटैक की वजह आम तौर पर, एपीआई अनुरोध को सही तरीके से फ़िल्टर न करना होता है. इससे हमलावर को बिना अनुमति के कार्रवाइयाँ करने या सुरक्षित संसाधन को ऐक्सेस करने की अनुमति मिल जाती है. ऐक्सेस टोकन या दावों के आधार पर अनुरोधों को फ़िल्टर करने की अनुमति देने वाले शर्त के हिसाब से तय किए गए लॉजिक के अलावा, Apigee अनुरोध के आधार पर फ़िल्टर करने के लॉजिक को लागू करने की अनुमति देता है.

एपीआई प्रॉडक्ट के कारोबारी नियम को समझने और उसे तय करने के बाद, यह तय करें कि आपके एपीआई को किन फ़ंक्शन की अनुमति है. इसके बाद, इन Apigee प्रॉडक्ट सुविधाओं का इस्तेमाल करके, ऐसे अनुरोधों को सीमित करें जो इस दायरे से बाहर हैं:

  • प्रॉक्सी फ़्लो कॉन्फ़िगरेशन के किसी भी चरण में, संसाधन पाथ या क्रियाओं को सीमित करने के लिए, शर्त के हिसाब से लॉजिक और Raise Fault नीतियां
  • JSON और XML कॉन्टेंट पर आधारित हमलों से सुरक्षा देने वाली नीतियां. ये नीतियां, गलत तरीके से बनाए गए JSON या XML के अनुरोध पेलोड का इस्तेमाल करके किए जाने वाले हमलों से सुरक्षा देती हैं

API6:2019 मास असाइनमेंट

खतरे की जानकारी

एपीआई के ज़रिए क्लाइंट ऐप्लिकेशन को बिना फ़िल्टर किया गया डेटा उपलब्ध कराया जाता है. इससे हमलावर, अनुरोधों के ज़रिए ऑब्जेक्ट की प्रॉपर्टी का अनुमान लगा सकते हैं. इसके अलावा, वे एंडपॉइंट के नाम रखने के नियमों का इस्तेमाल करके यह पता लगा सकते हैं कि बैकएंड में सेव किए गए डेटा ऑब्जेक्ट की प्रॉपर्टी में अनधिकृत बदलाव कहां करना है या उन्हें कहां ऐक्सेस करना है.

यह खतरा तब होता है, जब बिना फ़िल्टर किया गया डेटा (आम तौर पर JSON या XML में) किसी क्लाइंट को भेजा जाता है. इससे हमलावर को आपके बैकएंड सिस्टम की लागू करने से जुड़ी जानकारी का अनुमान लगाने की अनुमति मिल जाती है. साथ ही, गोपनीय डेटा एलिमेंट के प्रॉपर्टी नामों का भी अनुमान लगाया जा सकता है. इस तरह के हमले के नतीजे के तौर पर, हैकर को गलत डेटा को पढ़ने या उसमें बदलाव करने की अनुमति मिल सकती है. इसके अलावा, सबसे खराब स्थिति में, रिमोट कोड प्रोग्राम चलाने से जुड़ी कमज़ोरियों को भी चालू किया जा सकता है.

आम तौर पर, इस तरह के खतरे को अनुमति देने में दो पहलू शामिल होते हैं:

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

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

OpenAPI स्पेसिफ़िकेशन फ़िल्टर करने की नीति

OASValidation (OpenAPI स्पेसिफ़िकेशन की पुष्टि करना) नीति की मदद से, OpenAPI 3.0 स्पेसिफ़िकेशन (JSON या YAML) के हिसाब से, आने वाले अनुरोध या जवाब वाले मैसेज की पुष्टि की जा सकती है. इस नीति की मदद से, ये काम किए जा सकते हैं:

  1. OpenAPI स्पेसिफ़िकेशन (ओएएस) बनाकर, अपना एपीआई डिज़ाइन करना
  2. Apigee की मदद से, अपने बैकएंड से एपीआई प्रॉडक्ट को सुरक्षित तरीके से उपलब्ध कराने के लिए, ज़रूरी मीडिएशन, सुरक्षा, और कैश मेमोरी का लॉजिक लागू करें
  3. अपने ओएएस स्पेसिफ़िकेशन में तय किए गए डेटा स्कीमा के हिसाब से, आने वाले अनुरोधों की पुष्टि करें. इसमें ये शामिल हैं: basepath, verb, request message policy, और parameters

SOAP मैसेज की पुष्टि करने से जुड़ी नीति

SOAP मैसेज की पुष्टि करने से जुड़ी नीति की मदद से, एक्सएमएल पर आधारित अनुरोधों की पुष्टि की जा सकती है. इसके लिए, एक्सएसडी स्कीमा के ख़िलाफ़ एक्सएमएल मैसेज की पुष्टि की जाती है या डब्ल्यूएसडीएल परिभाषा के ख़िलाफ़ SOAP मैसेज की पुष्टि की जाती है. इसके अलावा, मैसेज की पुष्टि करने की नीति का इस्तेमाल करके यह पुष्टि की जा सकती है कि JSON या XML मैसेज पेलोड सही फ़ॉर्मैट में है. इसमें, XML या JSON मैसेज में मौजूद इन चीज़ों की पुष्टि करना शामिल है:

  • सिर्फ़ एक रूट एलिमेंट मौजूद है
  • कॉन्टेंट में कोई भी अवैध वर्ण मौजूद नहीं है
  • ऑब्जेक्ट और टैग सही तरीके से नेस्ट किए गए हों
  • शुरुआती और आखिरी टैग मैच करते हों

API7:2019 सिक्योरिटी मिसकॉन्फ़िगरेशन

खतरे की जानकारी

सुरक्षा से जुड़ी गलत सेटिंग की वजह से, ये समस्याएं हो सकती हैं: डिफ़ॉल्ट कॉन्फ़िगरेशन का असुरक्षित होना, अधूरे या ऐड-हॉक कॉन्फ़िगरेशन, ओपन क्लाउड स्टोरेज, गलत तरीके से कॉन्फ़िगर किए गए एचटीटीपी हेडर, गैर-ज़रूरी एचटीटीपी तरीके, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) की अनुमति देना, और संवेदनशील जानकारी वाले ज़्यादा शब्दों वाले गड़बड़ी के मैसेज. हमलावर अक्सर बिना पैच वाली कमियों, सामान्य एंडपॉइंट या बिना सुरक्षा वाली फ़ाइलों और डायरेक्ट्री का पता लगाने की कोशिश करते हैं. ऐसा वे उस सिस्टम का अनधिकृत ऐक्सेस पाने या उसके बारे में जानकारी हासिल करने के लिए करते हैं जिस पर उन्हें हमला करना है. सुरक्षा से जुड़ी गलत कॉन्फ़िगरेशन की वजह से, न सिर्फ़ लोगों का संवेदनशील डेटा सार्वजनिक हो सकता है, बल्कि सिस्टम की ऐसी जानकारी भी सार्वजनिक हो सकती है जिससे सर्वर को पूरी तरह से हैक किया जा सकता है. इसके अलावा, सुरक्षा से जुड़ी गलत कॉन्फ़िगरेशन की वजह से होने वाली कमियों के कुछ अन्य उदाहरणों में ये शामिल हो सकते हैं:

  • TLS को गलत तरीके से कॉन्फ़िगर किया गया है
  • स्टैक ट्रेस के साथ गड़बड़ी के मैसेज
  • ऐसे सिस्टम जिनमें पैच नहीं किया गया है
  • स्टोरेज या सर्वर मैनेजमेंट पैनल का ऐक्सेस

सुरक्षा से जुड़ी गलत कॉन्फ़िगरेशन की समस्याओं को हल करने और उन्हें कम करने के लिए, संगठन कई कदम उठा सकते हैं. इनमें ये शामिल हैं:

  1. सुरक्षा को बेहतर बनाने और पैच करने की प्रोसेस को सेट अप करना और उन्हें स्टैंडर्ड बनाना
  2. एपीआई के पूरे सिस्टम के लिए गवर्नेंस तैयार करना
  3. एडमिन ऐक्सेस को सीमित करना और ऑडिटिंग और सूचना पाने की सुविधा चालू करना

शेयर किए गए फ़्लो और फ़्लो हुक

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

एपीआई मॉनिटरिंग

Apigee, एपीआई मॉनिटरिंग के लिए एक बेहतरीन प्लैटफ़ॉर्म उपलब्ध कराता है. एपीआई मॉनिटरिंग की मदद से, संगठन एपीआई ट्रैफ़िक और परफ़ॉर्मेंस से जुड़ी समस्याओं का पहले से ही पता लगा सकते हैं. Apigee API Monitoring, Apigee Edge for Public Cloud के साथ मिलकर काम करता है. इससे एपीआई की परफ़ॉर्मेंस के बारे में रीयल-टाइम में अहम जानकारी मिलती है. साथ ही, समस्याओं का तुरंत पता लगाने और कारोबार को जारी रखने के लिए ज़रूरी कार्रवाइयां करने में मदद मिलती है.

आंकड़ा: Apigee API Monitoring, समस्याओं को मॉनिटर करने, उनकी जांच करने, और उन पर कार्रवाई करने के लिए कई तरह के टूल उपलब्ध कराता है. यह Google Cloud Platform की बेहतरीन इंटेलिजेंस सुविधाओं का इस्तेमाल करता है.

Apigee Sense

Apigee Sense, एपीआई को अनचाहे अनुरोध ट्रैफ़िक से बचाता है. इसमें नुक़सान पहुँचाने वाले क्लाइंट के हमले भी शामिल हैं. Apigee Sense, एपीआई अनुरोध के ट्रैफ़िक का विश्लेषण करता है. इससे ऐसे पैटर्न की पहचान की जाती है जो अनचाहे अनुरोधों को दिखा सकते हैं.

इस विश्लेषण का इस्तेमाल करके, संगठन उन क्लाइंट की पहचान कर सकते हैं जो अनचाहे अनुरोध करते हैं. इसके बाद, वे उन अनुरोधों को अनुमति देने, ब्लॉक करने या फ़्लैग करने के लिए कार्रवाई कर सकते हैं. Apigee Sense की मदद से, एपीआई को अनुरोध के ऐसे पैटर्न से सुरक्षित रखा जा सकता है जिनमें ये शामिल हैं:

  • अपने-आप होने वाली ऐसी गतिविधि जो इंसानों की गतिविधि से मिलती-जुलती हो
  • एक ही आईपी पते से बार-बार कोशिश करना
  • गड़बड़ी की दरें असामान्य हैं
  • क्लाइंट के संदिग्ध अनुरोध
  • डेटा क्रॉल करना
  • कीवर्ड इकट्ठा करना
  • गतिविधि में अचानक होने वाली बढ़ोतरी
  • भौगोलिक पैटर्न

API8:2019 इंजेक्शन

खतरे की जानकारी

एपीआई अनुरोधों में गैर-भरोसेमंद डेटा, जैसे कि SQL, NoSQL, XML पार्सर, ORM, LDAP, ओएस कमांड, और JavaScript को इंजेक्ट करने से, अनचाहे निर्देशों का इस्तेमाल हो सकता है या डेटा को बिना अनुमति के ऐक्सेस किया जा सकता है. हमलावर, एपीआई में किसी भी उपलब्ध इंजेक्शन वेक्टर के ज़रिए नुकसान पहुंचाने वाला डेटा भेजेंगे. जैसे, डायरेक्ट इनपुट, पैरामीटर, इंटिग्रेटेड सेवाएं वगैरह. वे उम्मीद करेंगे कि यह डेटा इंटरप्रेटर को भेजा जाए. हमलावर, सोर्स कोड की समीक्षा करते समय इन कमियों का आसानी से पता लगा सकते हैं. इसके लिए, वे सुरक्षा से जुड़ी कमियों का पता लगाने वाले स्कैनर और फ़ज़र का इस्तेमाल करते हैं. इंजेक्शन के सफल होने पर, जानकारी ज़ाहिर हो सकती है. इससे निजता और डेटा के नुकसान पर असर पड़ता है. कुछ मामलों में, इससे DoS भी हो सकता है.

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

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

रेगुलर एक्सप्रेशन प्रोटेक्शन नीति

RegularExpressionProtection नीति, मैसेज से जानकारी निकालती है. जैसे, यूआरआई पाथ, क्वेरी पैरामीटर, हेडर, फ़ॉर्म पैरामीटर, वैरिएबल, एक्सएमएल पेलोड या JSON पेलोड. इसके बाद, यह नीति पहले से तय किए गए रेगुलर एक्सप्रेशन के हिसाब से उस कॉन्टेंट का आकलन करती है. अगर तय किए गए कोई भी रेगुलर एक्सप्रेशन सही पाए जाते हैं, तो मैसेज को खतरा माना जाता है और उसे अस्वीकार कर दिया जाता है. रेगुलर एक्सप्रेशन या छोटे तौर पर regex, स्ट्रिंग का एक सेट होता है. यह स्ट्रिंग में पैटर्न तय करता है. रेगुलर एक्सप्रेशन की मदद से, कॉन्टेंट का प्रोग्राम के हिसाब से आकलन किया जा सकता है, ताकि पैटर्न का पता लगाया जा सके. रेगुलर एक्सप्रेशन का इस्तेमाल किया जा सकता है. उदाहरण के लिए, किसी ईमेल पते का आकलन करने के लिए, ताकि यह पक्का किया जा सके कि वह सही तरीके से बनाया गया है.

RegularExpressionProtection का सबसे ज़्यादा इस्तेमाल, JSON और XML पेलोड में मौजूद नुकसान पहुंचाने वाले कॉन्टेंट का आकलन करने के लिए किया जाता है.

कोई भी रेगुलर एक्सप्रेशन, कॉन्टेंट पर आधारित सभी हमलों को नहीं रोक सकता. इसलिए, सुरक्षा की कई लेयर बनाने के लिए, कई तरीकों को एक साथ इस्तेमाल करना चाहिए. इस सेक्शन में, कॉन्टेंट को ऐक्सेस करने से रोकने के लिए कुछ सुझाए गए पैटर्न के बारे में बताया गया है.

Apigee प्लैटफ़ॉर्म पर, इनपुट की पुष्टि करने के कई अन्य तरीके उपलब्ध हैं:

कॉन्टेंट टाइप की पुष्टि करना

कॉन्टेंट टाइप का मतलब, किसी फ़ाइल के उस कॉन्टेंट से है जिसे एचटीटीपी के ज़रिए ट्रांसफ़र किया जाता है. इसे दो हिस्सों वाले स्ट्रक्चर के हिसाब से कैटगरी में बांटा जाता है. Apigee का सुझाव है कि अनुरोध और जवाब के लिए, कॉन्टेंट टाइप की पुष्टि करें. इसके लिए, यहां बताया गया तरीका अपनाएं.

API9:2019 ऐसेट को सही तरीके से मैनेज न करना

खतरे की जानकारी

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

इस खतरे से निपटने के लिए, Apigee की बेहतर सुविधाओं का इस्तेमाल किया जा सकता है. इनकी मदद से, एपीआई के पूरे लाइफ़साइकल को मैनेज किया जा सकता है. इससे आपको एक ऐसा गवर्नेंस मॉडल बनाने में मदद मिलती है जिससे टीमें आपस में मिलकर काम कर सकती हैं. साथ ही, सुरक्षा से जुड़े स्टेकहोल्डर और एपीआई डेवलपर के बीच ज़िम्मेदारियों को अलग-अलग बांटा जा सकता है. इनकी मदद से, सीमाएं और कंट्रोल कॉन्फ़िगर और बनाए रखे जा सकते हैं:

संगठन, एनवायरमेंट, और वर्शन: वर्चुअल और फ़िज़िकल गार्डरेल, जो रनटाइम कॉन्टेक्स्ट के ज़रिए आइसोलेशन और सुरक्षित प्रमोशन प्रोसेस की गारंटी देते हैं.

भूमिका के आधार पर ऐक्सेस कंट्रोल: आपकी एपीआई टीमों के सिर्फ़ ज़रूरी लोगों के पास, कॉन्फ़िगरेशन में बदलाव करने और प्रमोशन की प्रोसेस को मैनेज करने की अनुमतियां होंगी.

एपीआई के दस्तावेज़ों के लिए ऑडियंस मैनेजमेंट: डेवलपर पोर्टल में एपीआई पब्लिश होने के बाद, टारगेट ऑडियंस को मैनेज करके दस्तावेज़ों को सीमित तौर पर दिखाया जा सकता है.

फ़्लो हुक: ग्लोबल नीतियां और पैटर्न लागू किए जा सकते हैं. इन्हें खास अधिकारों वाले गार्डरेल के तौर पर मैनेज किया जा सकता है. इनमें एपीआई डेवलपर बदलाव नहीं कर सकते.

संगठन और एनवायरमेंट

Apigee में कॉन्फ़िगरेशन आर्टफ़ैक्ट, उपयोगकर्ताओं, और सुविधाओं को किसी खास संगठन और/या एनवायरमेंट के हिसाब से तय किया जा सकता है. इसका मतलब है कि प्लैटफ़ॉर्म में पहले से ही ऐसे गार्डरेल मौजूद हैं जिन्हें एपीआई और उनके साथ काम करने वाले कॉन्फ़िगरेशन के आस-पास रखा जा सकता है.

संगठन: संगठन, Apigee में टॉप-लेवल का किरायेदार होता है. इससे आपको ट्रैफ़िक, कॉन्फ़िगरेशन, और उपयोगकर्ताओं को पूरी तरह से अलग करने की सुविधा मिलती है. गवर्नेंस के सबसे सही तरीके के तौर पर, आपको प्रोडक्शन और नॉन-प्रोडक्शन के लिए अलग-अलग संगठन बनाने चाहिए. इस तरीके से, प्रोडक्शन डेटा, उपयोगकर्ताओं, और ट्रैफ़िक को लोअर एनवायरमेंट के साथ मिक्स होने से रोका जा सकता है.

एनवायरमेंट: Apigee में मौजूद एपीआई को डिप्लॉयमेंट की कई स्थितियों के ज़रिए प्रमोट किया जा सकता है. हर स्थिति, एक्ज़ीक्यूशन कॉन्टेक्स्ट से जुड़ी होती है. प्रमोशन की प्रोसेस के दौरान, एनवायरमेंट कॉन्टेक्स्ट को साथ नहीं ले जाया जाता. इसलिए, बिना अनुमति वाले उपयोगकर्ताओं को संवेदनशील कॉन्फ़िगरेशन नहीं दिखता.

बदलाव: बदलाव की मदद से, एपीआई और अलग-अलग सुविधाओं को अलग-अलग एनवायरमेंट में आसानी से प्रमोट किया जा सकता है.

रोल के हिसाब से ऐक्सेस कंट्रोल

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

एपीआई के दस्तावेज़ के लिए ऑडियंस मैनेजमेंट

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

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

फ़्लो हुक

एपीआई के प्रमोशन और रिलीज़ की प्रोसेस में, सुरक्षा से जुड़े नियमों का पालन करने और सर्टिफ़िकेट पाने की प्रोसेस हमेशा शामिल होनी चाहिए. एपीआई टीमों को सही टूल का इस्तेमाल करके, ऐसे दिशा-निर्देश बनाने चाहिए जो ज़िम्मेदारियों को अलग-अलग करने की गारंटी देते हों. साथ ही, रिलीज़ साइकल को तेज़ी से पूरा करने में मदद करते हों.

Apigee की मदद से, सुरक्षा से जुड़ी नीतियों को लागू करके, सुरक्षा से जुड़ी गवर्नेंस की ज़िम्मेदारियों को पूरा किया जा सकता है. इसके लिए, फ़्लो हुक का इस्तेमाल किया जाता है. इन ग्लोबल नीतियों को, खास अधिकारों वाले गार्डरेल के तौर पर मैनेज किया जा सकता है. इनमें एपीआई डेवलपर बदलाव नहीं कर सकते. इसलिए, ज़िम्मेदारियों को अलग-अलग रखने की गारंटी दी जाती है. साथ ही, डिफ़ॉल्ट सुरक्षा लागू करके तेज़ी से काम करने को बढ़ावा दिया जाता है. इसके अलावा, किसी दिए गए एक्ज़ीक्यूशन एनवायरमेंट में डिप्लॉय किए गए सभी एपीआई के लिए, सुरक्षा से जुड़े नियमों का पालन करने की सुविधा भी दी जाती है.

आंकड़ा: Apigee में, फ़्लो हुक और शेयर किए गए फ़्लो के ज़रिए, खास अधिकारों वाले गार्डरेल कॉन्फ़िगर किए जा सकते हैं. सुरक्षा से जुड़े स्टेकहोल्डर की यह ज़िम्मेदारी है कि वे सुरक्षा से जुड़ी ग्लोबल नीतियों को बनाए रखें. इन सुविधाओं से, ज़िम्मेदारियों को अलग-अलग करने की गारंटी मिलती है. साथ ही, इनसे डेवलपमेंट के जीवन चक्र को बेहतर बनाने में मदद मिलती है.

API10:2019 Insufficient logging & monitoring

खतरे की जानकारी

लॉगिंग, मॉनिटरिंग, और सूचनाएं पाने की सुविधा न होने पर, चालू हमलों का पता नहीं चल पाता. इसलिए, अहम इवेंट के बारे में अहम जानकारी पाने के लिए एक रणनीति की ज़रूरत होती है. इससे आपके कारोबार पर असर पड़ता है.

एपीआई के लिए इवेंट और लॉगिंग मैनेजमेंट की रणनीतियों में, इन सबसे सही तरीकों को ध्यान में रखना चाहिए:

  • लॉग मैनेज करने की नीति: लॉग की वर्बोसिटी, लॉग लेवल, लॉग इंटिग्रिटी, सेंट्रलाइज़्ड रिपॉज़िटरी वगैरह को स्टैंडर्ड बनाने और कंट्रोल करने के लिए, नियमों को लागू करें और उनका दस्तावेज़ बनाएं
  • इवेंट मैनेजमेंट से जुड़ी नीति: यह पक्का करना कि हर इवेंट को उसके सोर्स से ट्रैक किया जा सके. साथ ही, इवेंट को गंभीरता और कारोबार पर पड़ने वाले असर के हिसाब से कैटगरी में बांटा जा सकता है
  • रिपोर्ट और ऑडिट: सुरक्षा और संचालन से जुड़े स्टेकहोल्डर के पास, रीयल टाइम में लॉग और इवेंट को ऐक्सेस करने और उन पर कार्रवाई करने की सुविधा होनी चाहिए. इसके अलावा, स्टेकहोल्डर, रीइन्फ़ोर्समेंट साइकल को पूरा कर सकते हैं. इससे, पुराने डेटा के आधार पर पहचान करने के पैटर्न में बदलाव किया जा सकता है

Apigee, इवेंट और लॉगिंग मैनेजमेंट की पूरी रणनीति बनाने के लिए ज़रूरी टूल उपलब्ध कराता है. इन टूल में ये शामिल हैं:

मैसेज लॉगिंग की नीति: अपने एपीआई ट्रैफ़िक के ट्रैफ़िक की जानकारी या मेटाडेटा के आधार पर लॉग स्ट्रीम बनाएं. आपके पास शर्तों के हिसाब से लॉजिक और मैसेज टेंप्लेट का इस्तेमाल करके, स्ट्रीम की वर्बोसिटी तय करने का विकल्प होता है.

Google की Cloud Operation Suite: Google के मॉनिटरिंग और लॉगिंग टूल के साथ इंटिग्रेशन का फ़ायदा पाएं. ये टूल बड़े पैमाने पर इस्तेमाल किए जा सकते हैं.

सेवा से जुड़े कॉलआउट की नीति: इसमें लॉग स्ट्रीम के लिए सहायता जोड़ी गई है. इसके लिए, इवेंट भेजने के लिए एचटीटीपी एंडपॉइंट की ज़रूरत होती है.

Analytics: आउट ऑफ़ बॉक्स और/या पसंद के मुताबिक बनाई गई रिपोर्ट के ज़रिए, पुराने ट्रैफ़िक के मेटाडेटा को ऐक्सेस और उसका विश्लेषण करें. ट्रेंड के आधार पर सूचनाएं बनाना और उन्हें मैनेज करना. साथ ही, ट्रैफ़िक की अनियमितताओं को समझना.

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