SaaS API key security: credentials बनाएँ, rotate करें और revoke करें
Scoped permissions, सुरक्षित storage, planned rotation और तेज revocation से customer API keys की रक्षा करें।
इस मार्गदर्शिका में
SaaS product API keys कैसे जारी करे?
API key एक credential है: जिसे यह मिल जाए वह उसकी permissions से काम कर सकता है। इसे password या दूसरे secret की तरह संभालें और key-generation screen जारी करने से पहले पूरा lifecycle तय करें। OWASP central secret management, least privilege, auditing और credential के इस्तेमाल तथा exposure के अनुरूप rotation प्रक्रिया सुझाता है।
मजबूत random secret बनाएँ और केवल एक बार दिखाएँ
Cryptographically secure random source से पर्याप्त entropy वाली key बनाएँ, ताकि अनुमान लगाना कठिन हो। Secret केवल creation पर दिखाएँ, साफ बताएँ कि बाद में इसे retrieve नहीं किया जा सकेगा, और ऐसा copy action दें जो analytics या logs में key न भेजे। Secret बताए बिना पहचान के लिए non-secret prefix या ID रखें।
Key की permissions, tenant और environment सीमित रखें
हर key को केवल जरूरी API operations दें और उसे issuing tenant तक सीमित रखें। Test और production credentials अलग रखें। एक साझा company-wide key के बजाय हर integration के लिए अलग key पर विचार करें। Network restriction या expiry उपयोगी हो तो उनका प्रभाव साफ बताएँ और वैध jobs पर test करें।
उपयोग के अनुसार verifier या encrypted secret रखें
अगर service को केवल प्रस्तुत customer key verify करनी है, तो one-way verifier रखें और सुरक्षित comparison करें; बिना जरूरत वापस पढ़े जा सकने वाली copy न रखें। अगर service को बाद में किसी दूसरे provider को credential भेजना है, तो managed secret store में encrypt करें और decryption access सीमित रखें। Secrets को source control, browser storage, URL और support ticket से बाहर रखें।
| Key ID / owner | Tenant और environment | Scopes और purpose | Created / expiry / last used | Rotation और revocation owner |
|---|---|---|---|---|
API key को सुरक्षित तरीके से कैसे rotate करें?
मौजूदा key बंद करने से पहले replacement तैयार करें
नई scoped credential बनाएँ और सुरक्षित तरीके से customer तक पहुँचाएँ। Integration बदलने के लिए सीमित overlap window जरूरी हो तो दोनों keys के उपयोग को अलग track करें और पुरानी key बंद करने की आखिरी तारीख दिखाएँ। दोनों को अनिश्चित समय तक active न रखें।
Revocation को तेज और स्पष्ट बनाएँ
सही permission वाला user compromised या retired key को customer account मिटाए बिना बंद कर सके। तय करें कि बदलाव caches, workers और अलग-अलग regions में कितनी जल्दी लागू होगा। फिर test करें कि कोई hidden copy या लंबे समय तक चलने वाला session key को इस्तेमाल योग्य न रखे।
Rotation का समय risk और exposure देखकर तय करें
Policy बनाते समय key की privilege, environment, lifetime, storage path, vendor guidance और incident history पर विचार करें। Exposure की आशंका पर तुरंत revoke करें—सिर्फ तय schedule का इंतजार न करें। Integration सुरक्षित रूप से support करे तो rotation automate करें और planned change के समय failures monitor करें।
Leaked API key पहचानकर प्रतिक्रिया कैसे दें?
Key value को telemetry से बाहर रखें
Logging, tracing या error reporting से पहले authorization headers और request bodies redact करें। मंजूर secret-scanning tools से build output, repositories, tickets और shared documents में accidental exposure खोजें। Logs में पूरी key की जगह ID या सुरक्षित fingerprint रखें।
पहले revoke करें, फिर गतिविधि की जाँच करें
Exposure की पुष्टि होते ही key disable करें, trusted route से owner को सूचित करें और integration तैयार होने के बाद replacement दें। हाल की activity, tenant scope, data access और downstream actions review करें। Incident process के अनुसार जरूरी audit evidence बचाएँ, लेकिन report में secret की copy न रखें।
Customer को key management की साफ जानकारी दें
स्थिर key name या prefix, scopes, environment, creation time, last-used time और status दिखाएँ। Revocation से पहले बताएँ कि known jobs रुक सकते हैं, लेकिन emergency revoke उपलब्ध रखें। Creation, scope change और revocation को audit events के रूप में दर्ज करें, जिन्हें authorized workspace admins देख सकें।
SaaS API key security से जुड़े सवाल
क्या customer API key plain text में रखनी चाहिए?
नहीं, जब तक बाद में उसे retrieve करने की कोई सीमित और उचित जरूरत न हो; ऐसी स्थिति में encryption तथा सख्त secret management अपनाएँ। Service को केवल भेजी गई key verify करनी हो तो सामान्यतः one-way verifier अधिक सुरक्षित है। Secret को logs या source code में कभी न रखें।
API keys कितनी बार rotate करनी चाहिए?
Privilege, exposure और key के इस्तेमाल को देखकर policy तय करें। Compromise की आशंका पर तुरंत revoke करें। Scheduled rotation में पुरानी और replacement key को सीमित migration window तक साथ रखें, फिर जाँचें कि पुरानी key अब स्वीकार नहीं हो रही।
क्या पूरी team एक API key साझा कर सकती है?
जहाँ per-user या per-integration credentials संभव हों वहाँ broad shared key से बचें। अलग keys से activity पहचानना, scope सीमित करना और revoke करना आसान होता है; एक integration हटाने पर दूसरे workflows की हर key बदलनी नहीं पड़ती।
Public repository में key दिख जाए तो क्या करें?
Product में उसे तुरंत revoke करें, replacement बनाएँ, integration को सुरक्षित रूप से update करें और exposure के समय की activity जाँचें। दिखने वाला text हटाने से पुरानी key सुरक्षित नहीं हो जाती; उसकी copy पहले बन चुकी हो सकती है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .