सर्वर रहित कंप्यूटिंग ने मूल रूप से बदल दिया है कि कैसे विकास टीमों ने अनुप्रयोगों का निर्माण और तैनाती की है, बुनियादी ढांचे की परत को अमूर्त किया ताकि इंजीनियर व्यवसाय तर्क और बाजार की गति पर ध्यान केंद्रित कर सकें। हालांकि, यह प्रतिमान बदलाव एक नई हमला सतह भी पेश करता है, जिसमें APIs ने सर्वर रहित APIs, AWS Lambda, Azure Functions, या Google क्लाउड फंक्शन जैसे क्लाउड फंक्शन्स के बीच प्राथमिक इंटरफेस के रूप में कार्य किया है। इन समापन बिंदुओं को सुरक्षित करना अब एक बाद में नहीं है- यह उत्पादन-ग्रेड अनुप्रयोगों के लिए एक महत्वपूर्ण आवश्यकता है। यह लेख सर्वर रहित APIs की रक्षा के लिए सिद्ध सर्वोत्तम प्रथाओं पर विस्तार करता है, प्रमाणीकरण, सुरक्षित संचार, दर सीमित करना, इनपुट सत्यापन, और सहायक सुरक्षा नियंत्रण आपको आज लागू करने की आवश्यकता है।

सर्वर रहित सुरक्षा मॉडल को समझना

पारंपरिक बुनियादी ढांचे में, सुरक्षा नेटवर्क परिधि पर निर्भर करती है: फायरवॉल, वीपीएन और कठोर सर्वर। सर्वर रहित उस मॉडल को उलट देता है। कठोर होने के लिए कोई लगातार सर्वर नहीं है; इसके बजाय, प्रत्येक फ़ंक्शन चालान एफ़िमरल है, और क्लाउड प्रदाता रनटाइम वातावरण का प्रबंधन करता है। साझा जिम्मेदारी मॉडल का मतलब है कि आप अपने कोड, डेटा और पहचान को सुरक्षित रखते हैं- जबकि प्रदाता अंतर्निहित होस्ट को सुरक्षित करता है। एपीआई नई परिधि बन जाते हैं। प्रत्येक अनुरोध को संभावित रूप से दुर्भावनापूर्ण रूप से इलाज किया जाना चाहिए, और प्रत्येक कार्य को अपने स्वयं के संदर्भ को मान्य करना चाहिए। इस पहचान-पहला दृष्टिकोण को घटना-संचालित वास्तुकला के साथ प्रमाणीकरण, प्राधिकरण और डेटा अखंडता की गहरी समझ की आवश्यकता है।

कोर थ्रेट्स सर्वर रहित एपीआई

रक्षा में डाइविंग से पहले, सर्वर रहित समापन बिंदुओं को लक्षित करने वाले सबसे आम हमला वेक्टरों को पहचानने के लिए यह महत्वपूर्ण है:

  • ]इंजेक्शन हमलों - SQL, NoSQL, OS कमांड, या LDAP इंजेक्शन बिना किसी प्रकार के इनपुट के कार्यों के लिए पारित किया गया।
  • Broken प्रमाणीकरण - कमजोर या लापता टोकन सत्यापन, गरीब कुंजी प्रबंधन, या अनुचित रूप से दायर एक्सेस टोकन।
  • ]Excessive data exchange – एपीआई पूर्ण वस्तु पेलोड लौटाने पर केवल आंशिक डेटा की आवश्यकता होती है, संवेदनशील क्षेत्रों को लीक कर देता है।
  • Denial of service (DoS) – बर्स्ट हमलों कि निकास समारोह concurrency सीमा या ट्रिगर महंगा ठंड शुरू होता है।
  • Misconfiguration – अत्यधिक permisssive IAM भूमिकाओं, सार्वजनिक बाल्टी, या अक्षम लॉगिंग अपने बुनियादी ढांचे को उजागर.

इन खतरों में से प्रत्येक को जानबूझकर डिजाइन और टूलिंग के साथ अपने तैनाती पाइपलाइन में एकीकृत किया जा सकता है।

अपने अंतिम बिंदुओं की रक्षा के लिए सर्वश्रेष्ठ अभ्यास

1. मजबूत प्रमाणीकरण और प्राधिकरण लागू करना

प्रत्येक API अनुरोध को सर्वर रहित फ़ंक्शन को प्रमाणित और अधिकृत किया जाना चाहिए। OAuth 2.0 के साथ उद्योग मानक प्रोटोकॉल का उपयोग करें OpenID कनेक्ट ] या जारी JSON Web Tokens (JWT)]]]]. प्रत्येक कार्य के अंदर टोकनों को मान्य करें (या API गेटवे लेखक के माध्यम से) यह सुनिश्चित करने के लिए कि वे समाप्त नहीं हुए हैं या उन्हें छेड़छाड़ नहीं की गई है। आंतरिक सेवाओं के लिए, API कुंजी का उपयोग पर्यावरण चर या एक गुप्त प्रबंधक में सुरक्षित रूप से संग्रहीत किया जाता है।

] के साथ बुनियादी प्रमाणीकरण से परे जाना role आधारित अभिगम नियंत्रण (RBAC) या यहां तक कि attribute-based access Control (ABAC) ]]]]]]. उदाहरण के लिए, एक AWS Lambda फंक्शन प्रोसेसिंग यूजर डॉक्यूमेंट्स को डेटा लौटने से पहले कॉलर की भूमिका और संसाधन स्वामित्व की पुष्टि करने का दावा करना चाहिए। AWS Cognito, Auth0 और फायरबेस प्रमाणीकरण जैसी सेवाएं प्रबंधित पहचान परतें प्रदान करती हैं जो सीधे सर्वर रहित ढांचे के साथ एकीकृत होती हैं।

2. सुरक्षित संचार को लागू करना

सभी एपीआई यातायात को पारगमन में एन्क्रिप्ट किया जाना चाहिए। क्लाइंट अनुप्रयोगों पर HTTPS (TLS 1.2 या 1.3) का उपयोग करें। HTTP अनुरोधों को अस्वीकार करने के लिए अपने एपीआई गेटवे या लोड बैलेंसर को कॉन्फ़िगर करें। अतिरिक्त सुरक्षा के लिए, ]] को लागू करें।

यदि आपके कार्य एक दूसरे के साथ संवाद करते हैं (जैसे, घटना बसों या कतारों के माध्यम से), तो उस यातायात को भी एन्क्रिप्ट करें। अधिकांश क्लाउड प्रदाता अंतर-सेवा संदेश के लिए डिफ़ॉल्ट रूप से एन्क्रिप्शन सक्षम करते हैं, लेकिन सत्यापित करते हैं कि आपका उत्पाद विन्यास इस पर लॉक करते हैं।

3. लागू दर सीमा और थ्रॉटलिंग

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

प्रमाणीकरण स्थिति के आधार पर अलग-अलग सीमाएं। अनाम उपयोगकर्ताओं को 10 अनुरोध / मिनट थ्रॉटल मिल सकता है, जबकि प्रमाणित उपयोगकर्ताओं को उच्च सीमा प्राप्त होती है। उपयोग करने पर विचार करें API कुंजी के साथ उपयोग करने की योजना AWS API गेटवे में या ] की दर को सीमित करने के लिए नियम ]]] को लागू करें, concurrency सीमाएं ]]]] अपने सर्वर रहित कार्यों पर खुद को खाते के स्तर के संसाधनों से एक DoS हमले को रोकने के लिए।

थ्रॉटल घटनाओं पर लॉग इन और चेतावनी देना ताकि आप वैध ट्रैफिक स्पाइक्स और दुर्भावनापूर्ण प्रयासों के बीच अंतर कर सकें।

4. सभी इनपुट को मान्य और संयोजित करें

कभी भी क्लाइंट या अपस्ट्रीम सेवा से आने वाले डेटा पर भरोसा नहीं करता है। प्रत्येक कार्य के प्रारंभ में एक स्कीमा सत्यापन पुस्तकालय (जैसे, जोई, प्याडैन्टिक या जेएसओएन स्कीमा) का उपयोग करें। किसी भी इनपुट को अस्वीकार करें जो अपेक्षित आकार से मेल नहीं खाता है। SQL या NoSQL क्वेरीज़ के लिए, हमेशा पैरामीटरीकृत बयान या एक ORM का उपयोग करें जो स्वचालित रूप से इनपुट से भाग लेता है। स्पष्ट रूप से श्वेतसूची ने स्ट्रिंग क्षेत्रों के लिए पात्रों की अनुमति दी, और कभी भी उपयोगकर्ता इनपुट को कोड के रूप में मूल्यांकन नहीं किया (no )।

इसके अतिरिक्त, सामग्री-प्रकार सत्यापन को लागू करें। यदि आपका समापन बिंदु JSON की उम्मीद करता है, तो ] या बिना समर्थित MIME प्रकार के अनुरोधों को अस्वीकार करें। फ़ाइल अपलोड के लिए, MIME टाइप, फाइल साइज और मैलवेयर के लिए AWS गार्डड्यूटी या तीसरे पक्ष के वायरस स्कैनर जैसी समर्पित सेवाओं का उपयोग करके मान्य करें।

अतिरिक्त सुरक्षा उपाय

वेब अनुप्रयोग फायरवॉल (WAF)

अपने एपीआई गेटवे के सामने एक WAF को स्वचालित रूप से SQL इंजेक्शन, क्रॉस-साइट स्क्रिप्टिंग (XSS) और IP प्रतिष्ठा खतरों जैसे आम हमले पैटर्न को फ़िल्टर करने के लिए तैनात करें। क्लाउड प्रदाता WAFs (AWS WAF, Azure WAF, क्लाउड आर्मर) को प्रबंधित करते हैं जो उनके लोड बैलेंसर और CDN सेवाओं के साथ एकीकृत होते हैं। अपने आवेदन के विशिष्ट समापन बिंदुओं के लिए कस्टम नियम सेट को कॉन्फ़िगर करें, जैसे कि विकृत JWTs या संदिग्ध क्वेरी मापदंडों के साथ अनुरोधों को अवरुद्ध करना।

व्यापक निगरानी और लॉगिंग

सुरक्षा के लिए दृश्यता गैर-परक्राम्य है। सभी एपीआई अनुरोधों और कार्य चालानों के लिए विस्तृत लॉग सक्षम करें। AWS CloudTrail, Azure Monitor, या Google क्लाउड लॉगिंग जैसी सेवाओं का उपयोग करने के लिए किया जाता है, जो किस चीज़ तक पहुंचता है, कब और कहाँ से। एक SIEM टूल (जैसे, स्प्लंक, ELK स्टैक, Datadog) में लॉग्स को केंद्रीकृत करें और इसके लिए अलर्ट सेट करें:

  • दोहराया 401/403 प्रतिक्रियाओं (संभव ब्रूट बल)
  • फंक्शन निष्पादन समय या त्रुटि दर में अचानक स्पाइक
  • असामान्य भौगोलिक या आईपी रेंज से पहुंच
  • कार्य चालान जो एपीआई गेटवे (डायरेक्ट URL चालान) को बायपास करते हैं

पूरी तरह से हमला श्रृंखला का पता लगाने के लिए परतों-gateway, समारोह और डेटा स्टोर में कोर्रेलेट लॉग।

निर्भरता और पैच प्रबंधन

सर्वर रहित कार्य तीसरे पक्ष के पुस्तकालयों पर निर्भर हैं। एक एकल असुरक्षित निर्भरता आपके पूरे अनुप्रयोग को समझौता कर सकती है। सॉफ्टवेयर संरचना विश्लेषण (SCA) टूल्स (जैसे, Snyk, Trivy, निर्भरता) का उपयोग करके अपने CI/CD पाइपलाइन में ज्ञात भेद्यता के लिए स्कैन करने के लिए। पिन विशिष्ट संस्करणों के लिए निर्भरता [FLT: 3] का उपयोग करने के बजाय AWS Lambda परतें या Azure Functions एक्सटेंशन ]]]]

नियमित रूप से समीक्षा और अद्यतन समारोह रनटाइम्स और बेस छवियों (कंटेनर आधारित सर्वर रहित के लिए)। ब्रेकिंग परिवर्तनों से बचने के लिए परीक्षण के साथ स्वचालित निर्भरता अद्यतन सेट करें। बिना किसी निर्धारित निर्भरता के साथ विरासत कार्यों के लिए, उन्हें अलग करें और अतिरिक्त क्षतिपूर्ति नियंत्रण जैसे WAF या सख्त इनपुट सत्यापन लागू करें।

नेटवर्क सुरक्षा और अलगाव

जबकि सर्वर रहित कार्य बहु-कार्यात्मक क्लाउड वातावरण में चल रहे हैं, आप नेटवर्क-स्तर नियंत्रण जोड़ सकते हैं। ऐसे कार्य जो संवेदनशील डेटा (जैसे भुगतान की जानकारी, स्वास्थ्य रिकॉर्ड) को ]VPC के अंदर संसाधित करते हैं, जिनमें कोई सार्वजनिक इंटरनेट एक्सेस नहीं है। API गेटवे को संलग्न करें जो प्रॉक्सी एक निजी लोड बैलेंसर के लिए अनुरोध करता है या AWS PrivateLink] या ]Azure Private Endpoint सुरक्षित सेवा-सेवा-सेवा संचार के लिए।

IP whitelisting का प्रयोग प्रशासनिक समापन बिंदुओं या आंतरिक टूलींग के लिए किया जाता है। केवल आवश्यक बंदरगाहों और स्रोत IPs के लिए भीतर की यातायात को प्रतिबंधित करने के लिए सुरक्षा समूहों और नेटवर्क ACL को कॉन्फ़िगर करें। उन कार्यों के लिए जिन्हें इंटरनेट एक्सेस की आवश्यकता होती है (उदाहरण के लिए, तीसरे पक्ष के API को बुलाना), एक नियंत्रित सबनेट में NAT गेटवे के माध्यम से यातायात मार्ग।

एक CI/CD पाइपलाइन में सुरक्षा को लागू करना

सुरक्षा को विकास में शीघ्र स्वचालित और एकीकृत होना चाहिए। अपने सीआई/सीडी पाइपलाइन में सुरक्षा द्वार का परिचय दें जो तैनाती से पहले निम्नलिखित को लागू करता है:

  • स्थैतिक अनुप्रयोग सुरक्षा परीक्षण (SAST) पर असुरक्षित पैटर्न का पता लगाने के लिए कार्य कोड पर।
  • गंभीर कमजोरियों पर विफलता के साथ निर्भरता स्कैनिंग।
  • बुनियादी ढांचा-as-code (IaC) स्कैनिंग (जैसे, , ]]) गलत विन्यास IAM भूमिकाओं, एन्क्रिप्शन की कमी, या सार्वजनिक जोखिम के लिए।
  • इकाई और एकीकरण परीक्षण जो प्रमाणीकरण, प्राधिकरण और इनपुट सत्यापन लॉजिक को मान्य करते हैं।

उत्पादन में विलय करने से पहले वास्तविक सर्वर रहित समापन बिंदुओं के खिलाफ सुरक्षा परीक्षण चलाने के लिए ephemeral वातावरण (स्टेजिंग या पूर्वावलोकन तैनाती) का उपयोग करें। ] Postman] या ]]]]]] जैसे API सुरक्षा परीक्षण उपकरण का उपयोग करने पर विचार करें।

निष्कर्ष

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