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

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

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

शुरुआती जानकारी

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

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

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

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

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

API1:2019 टूटा हुआ ऑब्जेक्ट लेवल की अनुमति

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

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

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

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

  • ऐक्सेस टोकन इंटिग्रिटी
  • ऐक्सेस कंट्रोल लागू करने का तरीका

ऐक्सेस टोकन इंटिग्रिटी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सिक्योरिटी डिज़ाइन

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

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

पुष्टि करने की नीतियां

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

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

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

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

मैनेज करना

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

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

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

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

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

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

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

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

सुरक्षा रिपोर्टिंग

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

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

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

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

Apigee Sense

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

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

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

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

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

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

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

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

API3:2019 बहुत ज़्यादा डेटा एक्सपोज़र

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

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

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

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

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

अगले सेक्शन में बताया गया है कि ये काम कैसे किए जाते हैं:

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

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

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

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

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

मैसेज की नीति असाइन करें

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

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

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

कस्टम कोड के साथ जटिल रीराइटिंग

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

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

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

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

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

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

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

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

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

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

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

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

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

कोटा और बढ़ोतरी से जुड़ी नीतियों के तहत, दर की सीमा तय की गई है

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

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

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

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

कोटा

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

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

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

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

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

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

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

API5:2019 काम नहीं करने वाले फ़ंक्शन के लेवल की अनुमति

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

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

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

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

  • किस चीज़ की सुरक्षा की जा रही है? अपने एपीआई के लिए प्रॉडक्ट की रणनीति को ध्यान में रखें. साथ ही, Apigee API प्रॉक्सी, प्रॉडक्ट, और ऐप्लिकेशन की सुविधाओं से दिखाए जाने वाले पाथ और संसाधनों को डिज़ाइन करने के लिए, RESTful के सबसे सही तरीकों का इस्तेमाल करते समय, फ़ंक्शन के फ़ंक्शन को लॉजिकल सेगमेंटेशन लागू करें.
  • आपके एपीआई के संसाधनों को कौन ऐक्सेस कर रहा है? हाई लेवल पर्सोना के बारे में बताएं. साथ ही, 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. आपके ओएएस की खास जानकारी में बताए गए डेटा स्कीमा के हिसाब से मिलने वाले अनुरोधों की पुष्टि करें. इसमें basepath, कार्रवाई, अनुरोध से जुड़े मैसेज की नीति, और पैरामीटर शामिल हैं

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

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

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

API7:2019 सुरक्षा का गलत कॉन्फ़िगरेशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Apigee Sense

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

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

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

API8:2019 इंजेक्शन

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

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

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

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

रेगुलर एक्सप्रेशन सुरक्षा की नीति

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

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

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

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

  • JSONThreatProtection नीति, खतरों का पता लगाने के लिए JSON पेलोड की जांच करती है
  • XMLThreatProtection नीति के तहत, खतरों के बारे में जानने के लिए एक्सएमएल पेलोड की जांच की जाती है
  • JavaScript का इस्तेमाल करके, पैरामीटर की पुष्टि की जा सकती है
  • JavaScript का इस्तेमाल करके, हेडर की पुष्टि की जा सकती है

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

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

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

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

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

API9:2019 एसेट का गलत तरीके से मैनेजमेंट

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

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

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

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

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

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

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

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

संगठन और परिवेश

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

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

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

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

रोल पर आधारित ऐक्सेस कंट्रोल

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

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

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

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

फ़्लो हुक

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

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

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

सुरक्षा रिपोर्टिंग

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

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

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

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

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

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

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

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

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

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

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

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

Google का क्लाउड ऑपरेशन सुइट: Google के, निगरानी और लॉग करने वाले टूल के साथ काम करने के लिए, आउट-ऑफ़-बॉक्स इंटिग्रेशन का इस्तेमाल करें.

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

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

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