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

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

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

परिचय

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

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

एपीआई नेटवर्क की संख्या तेज़ी से बढ़ रही है. साथ ही, एपीआई का गलत इस्तेमाल और उसका दुरुपयोग भी बढ़ रहा है. इससे, हमलावर डेटा को चुरा लेते हैं. इसलिए, आज एपीआई नेटवर्क, हमले के सबसे सामान्य तरीकों में से एक बन गया है. 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 आरएफ़सी, पुष्टि करने और अनुमति देने के लिए, कई तरह के फ़्लो उपलब्ध कराते हैं. साथ ही, इन फ़्लो में शामिल लोगों की जानकारी भी देते हैं. यह एक जटिल विषय है. इसलिए, यह कोई आश्चर्य की बात नहीं है कि पुष्टि करने की गड़बड़ी, OWASP एपीआई के लिए सबसे ज़्यादा खतरों में से एक है. पहचान के मानकों को सही तरीके से लागू करने के बारे में पूरी जानकारी देना, इस दस्तावेज़ का मकसद नहीं है. हालांकि, Apigee के पास OAuth फ़्लो को बेहतर तरीके से समझने के लिए कई अन्य संसाधन हैं. जैसे, यह ई-बुक और वेबकास्ट. साथ ही, लागू करने का उदाहरण.

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

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

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

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

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

मैनेज करना

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

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

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

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

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

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

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

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

सुरक्षा से जुड़ी रिपोर्टिंग

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

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

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

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

Apigee Sense

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

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

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

बेहतर एपीआई ऑपरेशंस

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

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

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

  • ट्रैफ़िक से जुड़ी कुल सूचनाएं. किसी समयसीमा के दौरान, ट्रैफ़िक में तय प्रतिशत का बदलाव होने पर सूचना भेजता है. उदाहरण के लिए, एक घंटे के लिए ट्रैफ़िक में 5% या उससे ज़्यादा की बढ़ोतरी होने पर या एक हफ़्ते के लिए 10% या उससे ज़्यादा की गिरावट होने पर, सूचना भेजी जा सकती है
  • गड़बड़ी की सूचनाएं. Edge, ट्रैफ़िक और परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाता है. इसके लिए, आपको पहले से इन समस्याओं का पता लगाने की ज़रूरत नहीं होती. इसके बाद, इन गड़बड़ियों के लिए सूचना दी जा सकती है
  • टीएलएस की समयसीमा खत्म होने की चेतावनियां. TLS सर्टिफ़िकेट की समयसीमा खत्म होने पर सूचना भेजता है

API3:2019 डेटा को बिना अनुमति के सार्वजनिक करना

खतरे के बारे में जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कस्टम कोड की मदद से कॉन्टेंट को फिर से लिखना

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

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

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

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

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

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

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

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

API4:2019 संसाधनों की कमी और अनुरोध की दर सीमित करना

खतरे के बारे में जानकारी

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

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

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

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

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

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

Spike Arrest

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

कोटा

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

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

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

Apigee Sense की मदद से बॉट की पहचान करना

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

बेहतर एपीआई ऑपरेशंस की मदद से खतरे का पता लगाना मॉनिटरिंग

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

API5:2019 फ़ंक्शन लेवल के लिए अनुमति का गलत इस्तेमाल

खतरे के बारे में जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

शर्तों के हिसाब से फ़्लो की मदद से पुष्टि का अनुरोध करना

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

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

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

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

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

API6:2019 एक साथ कई एलिमेंट असाइन करना

खतरे के बारे में जानकारी

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

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

आम तौर पर, इस तरह के खतरे को दो वजहों से अनुमति दी जाती है:

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

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

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

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

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

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

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

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

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

खतरे के बारे में जानकारी

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

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

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

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

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

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

एपीआई की सुरक्षा से जुड़ी रिपोर्टिंग

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

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

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

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

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

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

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

Apigee Sense

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

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

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

API8:2019 इंजेक्शन

खतरे के बारे में जानकारी

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

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

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

रेगुलर एक्सप्रेशन की मदद से सुरक्षा से जुड़ी नीति

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

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

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

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

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

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

एपीआई की सुरक्षा से जुड़ी रिपोर्टिंग

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

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

API9:2019 ऐसेट का गलत तरीके से मैनेज किया जाना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

फ़्लो हुक

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

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

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

सुरक्षा से जुड़ी रिपोर्टिंग

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

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

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

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

उपयोगकर्ता की गतिविधि: प्लैटफ़ॉर्म के उपयोगकर्ताओं की संवेदनशील कार्रवाइयों को ट्रैक करें. संदिग्ध गतिविधि पर ड्रिल-डाउन करके, संदिग्ध गतिविधि का विश्लेषण करें.

API10:2019 लॉगिंग और मॉनिटरिंग की सुविधा का सही तरीके से इस्तेमाल न करना

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

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

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

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

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

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

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

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

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

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