SaaS secrets management: lifecycle, storage और rotation checklist
व्यावहारिक secrets inventory के साथ SaaS credentials की creation, least-privilege access, monitoring, rotation, revocation और recovery संभालें।
इस मार्गदर्शिका में
SaaS product के लिए secrets management क्या है?
Secret संवेदनशील authentication सामग्री है, जैसे database password, API token, signing key, certificate या cloud credential। Secrets management development और production में इन्हें बनाने, रखने, access देने, monitor करने, rotate और revoke करने की प्रक्रिया है। केवल vault लगा देना पर्याप्त नहीं: access policy, application design, deployment workflow और incident response तय करते हैं कि secret उजागर होगा या समय पर रोका जा सकेगा।
हर secret और उसके purpose की inventory रखें
Secret का प्रकार, उपयोग करने वाली service और environment, owner, permissions, expiry या rotation तरीका, dependent systems और emergency contact दर्ज करें। Development, staging और production credentials अलग रखें ताकि test environment customer systems तक रास्ता न बने। Inventory को protected system में रखें; उसमें secret का असली value कभी न लिखें।
Managed secret store लें और हर workload की पहुँच सीमित करें
Source code, tickets, shared documents या container images की बजाय maintained secrets manager या platform vault में secrets रखें। हर service identity को केवल जरूरी secret और operations की permission दें। Secret administration को सामान्य engineering access से अलग करें और देखें कि production secret कौन पढ़, बदल या access दे सकता है।
जहाँ संभव हो short-lived या dynamic credentials जारी करें
Workload identity काम शुरू होने पर सीमित credential माँग सकती है, जिसे task पूरा होने पर expire किया जा सकता है। इससे credential reuse कम हो सकता है, लेकिन identity और provider configuration मजबूत होने चाहिए। Static secret जरूरी हो तो उसका scope सीमित रखें, owner और expiry तय करें और replacement प्रक्रिया test योग्य बनाएँ।
| Secret / purpose | Service और environment | Owner / access | Rotation या expiry | Revocation test |
|---|---|---|---|---|
SaaS team secrets को सुरक्षित रूप से rotate, revoke और recover कैसे करे?
Rotation को tested change बनाएँ, केवल calendar reminder नहीं
Credential का उपयोग करने वाली हर service map करें और पता करें कि provider पुराने और नए value को कुछ समय साथ चलाने देता है या नहीं। सुरक्षित क्रम आमतौर पर नया credential बनाना, consumer को देना, वास्तविक connection जाँचना, traffic बदलना और फिर पुराना बंद करना है। Stored data की encryption keys के लिए अलग key-management योजना लें, क्योंकि rotation में data दोबारा wrap या encrypt करना पड़ सकता है।
Exposure पर असली credential revoke करें
Repository, log, ticket या build output में token दिखे तो मानें कि उसकी copy बन चुकी हो सकती है। Issuer पर उसे disable या rotate करें, permissions और usage history देखें, dependent services पहचानें और जाँचें कि उसका उपयोग हुआ या नहीं। दिखती copy हटाने या repository history बदलने से credential सुरक्षित नहीं हो जाता; containment के बाद exposure साफ करें और incident evidence बचाएँ।
Recovery और break-glass access सुरक्षित रखें
Secrets service restore करने, emergency access मंजूर करने और emergency credentials सुरक्षित रखने तथा test करने का तरीका लिखें। मजबूत authentication और सीमित permissions रखें, हर break-glass use पर alert करें और बाद में review करें। Vault खोना या identity provider अनुपलब्ध होना production रोक सकता है, इसलिए backups भी test करें।
Code और build से secrets leak होने से कैसे रोकें?
Changes और repositories scan करें, फिर उजागर credential rotate करें
संभावित credentials पकड़ने के लिए pre-commit checks और repository scanning रखें; build logs, release artifacts और container images भी scan करें। Scanning खोज में मदद करती है, पर हर secret मिल जाने का प्रमाण नहीं है। Finding आए तो credential revoke या rotate करें, उसका scope देखें और incident triage करें; केवल alert दबाना या file हटाना पर्याप्त नहीं।
Workflow logs और untrusted pull requests से secrets दूर रखें
Debugging के लिए credentials print न करें और untrusted text को ऐसे shell command में न जोड़ें जो privileged workflow में चले। Forks या दूसरे untrusted pull requests के code को deployment secrets न दें। Masking उपयोगी है, लेकिन encoded या बदले हुए value के लिए guaranteed redaction न मानें।
Machine secrets और लोगों के passwords को अलग समझें
Workload credentials के owner, scope, lifecycle और revocation तय हों। Human passwords के लिए अलग authentication guidance है: compromise का प्रमाण या उचित जोखिम कारण न हो तो मनमाने समय पर password बदलना अनिवार्य न करें। MFA या passkeys, सुरक्षित account recovery और अपने service में रखे passwords के लिए password-hashing function इस्तेमाल करें।
SaaS secrets management के सवाल
क्या CI provider में secret रखना हमेशा असुरक्षित है?
जरूरी नहीं। Protected CI secret store ठीक हो सकता है यदि access सीमित हो, workflows review हों, untrusted code secret न पढ़ सके, output नियंत्रित हो और credential सीमित तथा revoke करने योग्य हो। Cloud deployment में workload identity और short-lived credentials, लंबे समय तक चलने वाली cloud key से बचा सकते हैं।
क्या हर secret को हर 30 या 90 दिन में rotate करना चाहिए?
हर credential के लिए एक सार्वभौमिक अवधि नहीं है। Credential के प्रकार, exposure, privilege, provider क्षमता और operational risk के आधार पर rotation तय करें। जहाँ संभव हो छोटा lifetime रखें और exposure का संदेह या पुष्टि होते ही rotate करें। Rotation schedule तभी उपयोगी है जब consumers और rollback रास्ते test किए गए हों।
क्या secret scanning leaked credential को ठीक कर देती है?
नहीं। यह संभावित exposure का alert देती है। Issuer पर credential revoke या rotate करें, access और audit records देखें, unauthorized use जाँचें और exposed copies साफ करें। Repository history या logs की दूसरी copies कहीं रह सकती हैं।
क्या troubleshooting के लिए developer हर production secret पढ़ सके?
स्थायी और व्यापक access से account compromise तथा गलती से disclosure का असर बढ़ता है। हर service के लिए अलग access, अपवाद में सीमित अवधि की मंजूरी, audited secret operations और value उजागर किए बिना सुरक्षित metadata या logs से troubleshooting को प्राथमिकता दें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .