SaaS production database सुरक्षा checklist
Production database के लिए private network, सीमित roles, TLS, encryption, secrets rotation, patching, audit logs और tested restore की व्यावहारिक checklist।
इस मार्गदर्शिका में
Production database security checklist में क्या होना चाहिए?
Production database की सुरक्षा जाँचती है कि कौन जुड़ सकता है, हर identity क्या कर सकती है, data रास्ते में और storage में कैसे सुरक्षित है, तथा misuse या failure को team पहचान और recover कर सकती है या नहीं। शुरुआत private network path और least-privilege roles से करें; फिर encryption, managed credentials, updates, audit records और tested backups जोड़ें। सही controls database engine, hosting model और customer data पर निर्भर करते हैं।
Data और हर connection path का नक्शा बनाएँ
Production databases, replicas, analytics copies, exports और backups की सूची बनाएँ। हर copy के लिए data owner, sensitivity, application services, human operators, migration jobs और external processors दर्ज करें। पुराने test endpoints हटाएँ और किसी भी public connection की आवश्यकता का कारण लिखें।
Default रूप से database को public internet से दूर रखें
Private subnet या provider की private connectivity को प्राथमिकता दें। Inbound traffic केवल पहचाने हुए application या administration paths, संकीर्ण source ranges और आवश्यक ports तक सीमित रखें। यदि public access स्वीकृत अपवाद है, तो उसका owner, अतिरिक्त controls, expiry date और monitoring दर्ज करें; firewall rule अकेले user की पहचान नहीं करता।
हर environment के लिए review योग्य baseline रखें
Database engine और supported version, network boundary, identity roles, encryption, backup schedule, log destination और recovery owner दर्ज करें। Deployments और provider changes के बाद production की इस baseline से तुलना करें। Checklist में evidence और reviewer का नाम हो, केवल ‘control enabled है’ ऐसा checkbox नहीं।
| Database और data | स्वीकृत identities और paths | Encryption और secrets | Backup और restore evidence | Owner और अगली समीक्षा |
|---|---|---|---|---|
| मुख्य customer database | ||||
| Read replica या analytics copy | ||||
| Backup और export location |
SaaS team database access और encryption कैसे नियंत्रित करे?
अलग कामों के लिए अलग database identities रखें
Application, schema migration, reporting, support और emergency administration के लिए अलग roles बनाएँ। केवल ज़रूरी schemas, tables और operations दें; सामान्य application traffic में database owner या superuser का उपयोग न करें। Default privileges और निष्क्रिय accounts की समीक्षा करें। PostgreSQL में password authentication हो तो समर्थित SCRAM method चुनें।
Network पार करने वाले connections में verified TLS अनिवार्य करें
Database provider की supported TLS configuration अपनाएँ और client से server certificate तथा hostname verify करवाएँ। Certificate validation के बिना encryption client को नकली endpoint पहचानने नहीं देती। Production बदलने से पहले renewal और connection behavior जाँचें; PostgreSQL के दस्तावेज़ server TLS और client verification के विकल्प समझाते हैं।
At-rest encryption को सुरक्षा की एक परत समझें
Platform की supported storage encryption सक्षम करें और keys को access controls तथा recovery procedures से सुरक्षित रखें। At-rest encryption compromised application role को उसके अनुमत queries पढ़ने से नहीं रोकती। Access reviews, backups और secure exports फिर भी ज़रूरी हैं। दर्ज करें कि संबंधित keys कौन इस्तेमाल या administer कर सकता है।
Production database को सुरक्षित रूप से maintain और recover कैसे करें?
Credentials को code से बाहर रखें और rotation को test करें
Database credentials को स्वीकृत secrets manager या managed identity में रखें। Retrieval सीमित करें और secrets को source code, chat, command history या verbose logs में न डालें। Rotation में application और database को समन्वित तरीके से update करें, नए connections जाँचें और transition के बाद पुराना credential revoke करें। Platform support करे तो short-lived identity चुनें।
Rollback plan के साथ database और extensions patch करें
Database, extensions, drivers और managed service के supported versions तथा security advisories track करें। Representative workload और backups के साथ upgrade test करें, compatibility जाँचें और नियंत्रित deployment करें। Upgrade विफल होने पर service लौटाने का तरीका तय करें; updates को अनिश्चित समय तक टालने से ज्ञात कमजोरियाँ बनी रहती हैं।
Audit signals सुरक्षित रखें और backup restore साबित करें
Authentication failures, privilege changes, संवेदनशील administrative actions और ज़रूरी data access को documented purpose और retention अवधि के अनुसार record करें। Logs बदलने या मिटाने का access सीमित रखें और अनावश्यक personal data न जुटाएँ। Controlled environment में restore करके integrity और application workflows जाँचें, समय दर्ज करें; backup job सफल होना अपने-आप recovery का प्रमाण नहीं है।
Production database security FAQs
क्या production database का public IP हो सकता है?
Private network path सुरक्षित default है। कुछ architecture में स्वीकृत public endpoint हो सकता है, पर उसके लिए संकीर्ण network rules, मजबूत verified authentication, TLS, monitoring और स्पष्ट owner चाहिए। आवश्यकता खत्म होने पर अपवाद की फिर समीक्षा करें और public reachability हटाएँ।
क्या database encryption अकेले customer data को सुरक्षित कर देता है?
नहीं। Encryption storage या network की कुछ परतों को सुरक्षित करती है, जबकि permissions तय करती हैं कि कौन data पढ़ या बदल सकता है। Credentials, application authorization, key access, logging, backups और incident response भी आवश्यक हैं।
क्या application को database administrator के रूप में connect करना चाहिए?
आमतौर पर नहीं। Application को केवल आवश्यक operations वाला अलग role दें और owner या administrative privileges को नियंत्रित maintenance के लिए रखें। Migrations को अलग test करें, क्योंकि schema बदलावों को runtime application से अधिक permissions चाहिए हो सकती हैं।
Database restore कितनी बार test करना चाहिए?
Recovery objectives, data की criticality और system बदलावों के आधार पर cadence तय करें। Representative restore नियमित रूप से और backup, key, database version या recovery instructions में बड़े बदलाव के बाद test करें। दर्ज करें कि restored service अपेक्षित recovery point और recovery time पर खरी उतरती है या नहीं।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .