SaaS team के लिए serverless function security checklist
Per-function identities, protected invocation, validated events, managed secrets, supported runtimes, सीमित retries और उपयोगी logs से SaaS serverless functions सुरक्षित करें।
इस मार्गदर्शिका में
Serverless function security checklist क्या है?
Serverless function security checklist managed cloud platform पर चलने वाले functions के code, identity, event sources, configuration और data paths की रक्षा करती है। हर function का attack surface होता है: HTTP URL public हो सकता है, event producer पर जरूरत से अधिक भरोसा हो सकता है या execution role असंबंधित resources खोल सकता है। हर function की trust boundary अलग बनाएँ और provider के अनुरूप controls अपनाएँ; उदाहरण के लिए यहाँ AWS Lambda docs का उपयोग है।
हर function के triggers, data और callable paths की सूची बनाएँ
HTTP endpoints, queues, storage events, schedules, identity providers और service integrations दर्ज करें जो हर function को invoke कर सकते हैं। Expected caller, event format, data classification, downstream services, owner और failure behavior लिखें। Preview और पुराने function versions भी शामिल करें ताकि भूले हुए endpoints खुले न रहें।
हर function को dedicated execution identity दें
अलग data या duties वाले functions को अलग रखें और हर runtime role को केवल आवश्यक resources तथा actions दें। Deployment permissions को runtime permissions से अलग रखें; एक table पढ़ने वाले function को पूरे account का admin access नहीं चाहिए। AWS Lambda execution roles और least privilege बताता है; दूसरे platforms पर इसका समकक्ष workload identity अपनाएँ।
स्पष्ट निर्णय लें कि HTTP trigger public है या नहीं
Function की authentication setting और resource-based invocation policy दोनों review करें। Route जानबूझकर public हो तो requests validate करें और application में sensitive actions authorize करें; अन्यथा platform authentication माँगें या authenticated gateway के पीछे रखें। AWS Lambda function URL में AuthType NONE हो तो unauthenticated invocation के लिए public resource policy आवश्यक है।
| Function और trigger | Trusted caller और event | Runtime permissions | Secrets और data | Retry, alert और owner |
|---|---|---|---|---|
| Public API handler | ||||
| Queue consumer | ||||
| Scheduled maintenance job |
Serverless configuration और deployment कैसे सुरक्षित करें?
Secret values को managed secret store में रखें
जहाँ उचित हो environment variables को non-secret configuration के लिए इस्तेमाल करें, लेकिन function configuration encrypted है इसलिए long-lived credentials रखना सुरक्षित है—ऐसा न मानें। Managed secrets service या short-lived workload identity चुनें, हर function को केवल जरूरी secret पढ़ने दें और release के साथ rotation test करें। AWS database credentials, API keys और authorization tokens के लिए Lambda environment variables के बजाय Secrets Manager सुझाता है।
Supported runtimes चलाएँ और function dependencies update करें
Runtime support dates, language package vulnerabilities और base-image updates track करें। Managed platform अपने managed runtime के कुछ हिस्से patch कर सकता है, लेकिन function code और dependencies आपकी जिम्मेदारी हैं; container-based functions के लिए image rebuild और redeploy भी करें। Real event shape और rollback plan के साथ upgrade test करें।
Deployment path और configuration changes सुरक्षित रखें
Review करें कि कौन version publish, trigger update, execution role change या environment settings बदल सकता है। Production approval को सामान्य code contribution से अलग रखें और build identity सुरक्षित करें। Dependencies तथा deployment artifacts scan करें और live function configuration किस reviewed change से बनी, उसका इतिहास रखें।
Serverless event handling और operations कैसे harden करें?
हर event payload को untrusted input मानें
Event इस्तेमाल करने से पहले required fields, types, size और allowed values validate करें। Platform policy से authorized producer verify करें; customer द्वारा भेजे tenant ID या event name को permission का प्रमाण न मानें। Customer data पढ़ने या बदलने से पहले HTTP API जैसी object-level authorization जाँचें।
Retries, timeout और duplicate delivery पहले से design करें
Downstream service के अनुसार execution timeout और concurrency limits तय करें। Handler को idempotent बनाएँ ताकि retry या duplicate event से customer को दोबारा charge, notify या update न किया जाए। Asynchronous work के लिए bounded retries और dead-letter behavior लगाएँ तथा repeated failures पर alert करें।
Sensitive payload कॉपी किए बिना investigation योग्य logs रखें
Function version, request या event correlation ID, outcome और उपयोगी security decisions record करें। Full credentials, tokens, uploaded content या personal records logs में न लिखें। Log access सीमित करें और unexpected public invocation, permission changes, error spikes तथा exhausted retries के alarms test करें।
Serverless function security FAQs
क्या serverless functions default से secure होते हैं?
Provider runtime platform के कुछ हिस्से चलाता है, पर invocation permissions, execution identity, code, dependencies, secrets, network access और data handling आपकी team configure करती है। वास्तविक service और deployment mode की shared responsibility जाँचें।
क्या हर function का अलग role होना चाहिए?
अलग permissions या data access वाले functions के लिए अलग roles अच्छा default हैं। Role साझा करने से छोटा deployment आसान हो सकता है, पर compromised function का असर बढ़ता और review कम सटीक होता है। Shared roles संकीर्ण रखें और कारण दर्ज करें।
क्या API keys environment variables में रख सकते हैं?
Long-lived API keys, database passwords या authorization tokens सीधे function environment variables में न रखें। Managed secrets service अपनाएँ, retrieval केवल जरूरी function तक सीमित करें और rotation plan करें। Provider की at-rest encryption access-control या log-exposure जोखिम खत्म नहीं करती।
क्या function URLs की अलग security review चाहिए?
हाँ। Authentication mode, resource-based policy, allowed caller, application authorization और logging verify करें। URL का अनुमान कठिन होना access control नहीं है; public function URL को internet-facing API की तरह सुरक्षित करना चाहिए।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .