सुरक्षा सुदृढ़ीकरण और प्रोडक्शन जाँचसूची
शिक्षार्थी प्रमाणीकरण, RBAC, TLS, एन्क्रिप्शन, निगरानी और बैकअप रणनीति को शामिल करने वाली प्रोडक्शन-तत्परता जाँचसूची की समीक्षा करेंगे।
सुरक्षा सुदृढ़ीकरण और प्रोडक्शन जाँचसूची, CoddyKit पर MongoDB Academy का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह MongoDB Academy सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। MongoDB Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
उत्पादन-तत्परता की मानसिकता
उत्पादन-तत्परता कोई सुविधा नहीं है—यह वास्तविक उपयोगकर्ता के आपके सिस्टम का उपयोग शुरू करने से पहले लागू किए जाने वाले अनुशासनों की जाँच-सूची है। ऐसा परिनियोजन जो सभी कार्यात्मक परीक्षणों में सफल हो, लेकिन सुरक्षा सुदृढ़ीकरण, निगरानी और बैकअप सत्यापन छोड़ दे, उत्पादन के लिए तैयार नहीं है। यह अंतिम पाठ MongoDB परिनियोजन के लिए आवश्यक उत्पादन जाँच-सूची को समझाता है, जिसमें प्रमाणीकरण, RBAC, TLS, एन्क्रिप्शन, निगरानी, बैकअप और आपदा पुनर्प्राप्ति शामिल हैं।
जाँच-सूची 1: प्रमाणीकरण सक्षम
सत्यापित करें कि प्रमाणीकरण सक्षम है और बिना प्रमाणीकरण वाले कनेक्शन संभव नहीं हैं। स्वयं-होस्टेड MongoDB पर mongod.conf में security.authorization: enabled की पुष्टि करें। Atlas में प्रमाणीकरण अनिवार्य है और इसे अक्षम नहीं किया जा सकता। बिना क्रेडेंशियल के कनेक्ट करने का प्रयास करके परीक्षण करें—कनेक्शन अस्वीकार होना चाहिए। पुष्टि करें कि उत्पादन एप्लिकेशन खातों में किसी उपयोगकर्ता के पास root या __system भूमिका नहीं है।
// Verify authentication is required
// (attempt to connect without credentials — should fail)
try {
const client = new MongoClient('mongodb://localhost:27017')
await client.connect()
await client.db('admin').command({ ping: 1 })
console.log('AUTH MISSING — unauthenticated connections accepted!')
} catch (e) {
console.log('Good: unauthenticated connections rejected')
}
// List all admin users and their roles
use admin
db.getUsers() // verify no app user has 'root' roleजाँच-सूची 2: न्यूनतम-अधिकार RBAC
प्रत्येक डेटाबेस उपयोगकर्ता का ऑडिट करें। प्रत्येक एप्लिकेशन सेवा के पास केवल वही भूमिकाएँ होनी चाहिए जिनकी उसे आवश्यकता है और केवल उन्हीं डेटाबेस पर जिन तक उसे पहुँच चाहिए। प्रत्येक डेटाबेस के लिए db.getUsers() चलाएँ और जाँचें कि किसी सेवा खाते के पास dbAdminAnyDatabase, readWriteAnyDatabase या root नहीं है। एक उपयोगकर्ता पहुँच मैट्रिक्स बनाएँ, जिसमें दर्ज हो कि कौन-सी सेवा किस उपयोगकर्ता से कनेक्ट होती है, उसके पास कौन-सी भूमिकाएँ हैं और ऐसा क्यों है। यह मैट्रिक्स पहुँच समीक्षाओं के लिए आपके सत्य का एकमात्र स्रोत है।
// Audit access matrix
const accessMatrix = [
{ service: 'api-server', user: 'apiSvc', roles: [{ role: 'readWrite', db: 'ecommerce' }] },
{ service: 'analytics-job', user: 'analyticsSvc', roles: [{ role: 'read', db: 'ecommerce' }] },
{ service: 'backup-agent', user: 'backupAgent', roles: [{ role: 'backup', db: 'admin' }] },
{ service: 'monitoring-exp', user: 'prometheusExp', roles: [{ role: 'clusterMonitor', db: 'admin' }] }
]
// Verify each user's actual roles match the matrix
accessMatrix.forEach(entry => {
const user = db.getSiblingDB('admin').getUser(entry.user)
console.log(entry.service, user ? 'OK' : 'MISSING')
})जाँच-सूची 3: TLS अनिवार्य
पुष्टि करें कि net.tls.mode: requireTLS सक्रिय है और सभी client कनेक्शन एन्क्रिप्टेड हैं। TLS हैंडशेक विफलताओं के लिए MongoDB लॉग जाँचें, जो दर्शाती हैं कि कुछ client अभी भी खुले रूप में कनेक्ट करने का प्रयास कर रहे हैं। Atlas में TLS डिफ़ॉल्ट रूप से सक्षम है और इसे अक्षम नहीं किया जा सकता। स्वयं-होस्टेड परिनियोजन में TLS सक्रिय होने की पुष्टि करने के लिए db.adminCommand({ sslInfo: 1 }) चलाएँ (या db.serverStatus().network जाँचें)। ऐसे किसी परिनियोजन को अस्वीकार करें जिसमें उत्पादन में TLS allowTLS मोड में हो।
// Verify TLS is active on the server
const netStatus = db.adminCommand({ serverStatus: 1 }).network
console.log('TLS connections:', netStatus.serviceExecutorTaskStats)
// Confirm connection string includes TLS
// mongodb+srv:// always uses TLS
// Self-hosted: mongodb://host:27017/?tls=true
// Check mongod.conf programmatically
// grep 'mode: requireTLS' /etc/mongod.confजाँच-सूची 4: नेटवर्क पृथक्करण
MongoDB को सार्वजनिक इंटरनेट से सीधे पहुँच योग्य नहीं होना चाहिए। Atlas में सत्यापित करें कि IP Access List में 0.0.0.0/0 (सभी को अनुमति) शामिल नहीं है। ट्रैफ़िक को निजी रूप से रूट करने के लिए VPC Peering या Private Link का उपयोग करें। स्वयं-होस्टेड परिनियोजन में MongoDB को केवल निजी नेटवर्क इंटरफ़ेस से बाँधें (net.bindIp: 127.0.0.1,10.0.0.5) और फ़ायरवॉल नियम इस तरह कॉन्फ़िगर करें कि पोर्ट 27017 पर केवल एप्लिकेशन सर्वर IP को अनुमति मिले।
# mongod.conf — bind only to localhost and private network interface
net:
bindIp: 127.0.0.1,10.0.0.5 # never 0.0.0.0 in production
port: 27017
# Firewall rule (iptables example — block public access to 27017)
# iptables -A INPUT -p tcp --dport 27017 -s 10.0.0.0/8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 27017 -j DROPजाँच-सूची 5: बैकअप और समय-बिंदु पुनर्प्राप्ति
उत्पादन परिनियोजन में सत्यापित और परीक्षित बैकअप रणनीति होना अनिवार्य है। Atlas में Continuous Cloud Backup सक्षम करें, जो प्रतिधारण अवधि के भीतर किसी भी सेकंड तक समय-बिंदु पुनर्प्राप्ति प्रदान करता है। स्वयं-होस्टेड व्यवस्था में S3 पर दैनिक mongodump स्नैपशॉट कॉन्फ़िगर करें और हर महीने पुनर्स्थापन का परीक्षण करें। मुख्य शब्द है परीक्षित—जिस बैकअप से कभी पुनर्स्थापन नहीं किया गया, उस पर आप भरोसा नहीं कर सकते। हर तिमाही आपदा पुनर्प्राप्ति अभ्यास करें।
# mongodump — daily backup to S3
mongodump \
--uri 'mongodb://backupAgent:pass@host:27017/?authSource=admin' \
--gzip \
--archive=/tmp/backup-$(date +%Y%m%d).gz
# Upload to S3
aws s3 cp /tmp/backup-$(date +%Y%m%d).gz s3://my-mongo-backups/
# Verify backup integrity — test restore to a separate cluster
mongorestore \
--uri 'mongodb://host2:27017' \
--gzip \
--archive=/tmp/backup-$(date +%Y%m%d).gz \
--dropजाँच-सूची 6: निगरानी और अलर्ट
उत्पादन MongoDB परिनियोजन में इनकी निगरानी आवश्यक है: हार्डवेयर (CPU, डिस्क I/O, नेटवर्क); MongoDB-विशिष्ट (कनेक्शन, opcounters, कैश हिट अनुपात, प्रतिकृति विलंब, लॉक प्रतिशत); और एप्लिकेशन-स्तर (क्वेरी विलंबता P99, त्रुटि दर)। Atlas में निगरानी और अलर्ट की अंतर्निहित सुविधा है। स्वयं-होस्टेड परिनियोजन को Prometheus (mongodb_exporter) + Grafana या किसी समकक्ष प्रणाली के साथ एकीकृत करना चाहिए। सीमाएँ पार होने के बाद नहीं, बल्कि उनसे पहले अलर्ट सेट करें।
// Key Atlas alerts to configure (examples)
const alerts = [
{ metric: 'DISK_UTILIZATION', threshold: '80%', severity: 'WARNING' },
{ metric: 'CPU_SYSTEM_NORMALIZED', threshold: '70%', severity: 'WARNING' },
{ metric: 'REPLICATION_LAG', threshold: '10s', severity: 'CRITICAL' },
{ metric: 'CONNECTIONS', threshold: '80%', severity: 'WARNING' },
{ metric: 'CACHE_DIRTY_BYTES', threshold: '20%', severity: 'WARNING' }
]जाँच-सूची 7: क्वेरी प्रदर्शन का आधार-मान
लॉन्च से पहले क्वेरी प्रदर्शन का आधार-मान स्थापित करें: प्रोफ़ाइलर को स्तर 1 पर सक्षम करें, प्रतिनिधि कार्यभार चलाएँ (MongoDB के लोड जनरेटर या k6 जैसे टूल का उपयोग करके), और प्रत्येक महत्वपूर्ण एंडपॉइंट के लिए P95 तथा P99 विलंबता दर्ज करें। इन आधार-मानों को संग्रहित करें। प्रत्येक परिनियोजन के बाद लोड परीक्षण फिर चलाएँ और तुलना करें। P99 में 20% से अधिक की कोई भी गिरावट, परिनियोजन को सभी उपयोगकर्ताओं तक पहुँचाने से पहले जाँच शुरू कर देती है।
// Enable profiler and set slow query threshold
db.setProfilingLevel(1, { slowms: 50 }) // log queries > 50ms
// After load test, query profiler for summary
db.system.profile.aggregate([
{
$group: {
_id: '$ns',
avgMs: { $avg: '$millis' },
maxMs: { $max: '$millis' },
count: { $sum: 1 },
slowOps: { $sum: { $cond: [{ $gt: ['$millis', 100] }, 1, 0] } }
}
},
{ $sort: { avgMs: -1 } }
])जाँच-सूची 8: स्थिर डेटा का एन्क्रिप्शन
PII, भुगतान डेटा या स्वास्थ्य संबंधी जानकारी संभालने वाले एप्लिकेशन के लिए सत्यापित करें कि स्थिर डेटा का एन्क्रिप्शन सक्षम है। Atlas में Security सेटिंग्स के अंतर्गत क्लाउड प्रदाता के KMS-आधारित एन्क्रिप्शन को सक्षम करें। स्वयं-होस्टेड Enterprise परिनियोजन में security.enableEncryption: true की पुष्टि करें और जाँचें कि KMIP कुंजी प्रबंधक कॉन्फ़िगर है। दर्ज करें कि कौन-सी Customer Master Key किस क्लस्टर की सुरक्षा करती है और सुनिश्चित करें कि CMK पर स्वयं कई व्यक्तियों के पहुँच नियंत्रण लागू हों, ताकि पहुँच अवरुद्ध न हो।
// Verify Atlas encryption at rest is enabled via Atlas Admin API
curl -u 'PUBLIC_KEY:PRIVATE_KEY' --digest \
'https://cloud.mongodb.com/api/atlas/v1.0/groups/GROUP_ID/encryptionAtRest'
// Response should show: 'awsKms.enabled': true (or azure/gcp equivalent)
// For self-hosted, check mongod.conf
// grep 'enableEncryption' /etc/mongod.conf
// Expected: enableEncryption: trueजाँच-सूची 9: ऑडिट लॉगिंग
प्रत्येक प्रमाणीकरण, प्राधिकरण विफलता और संवेदनशील डेटा पहुँच घटना दर्ज करने के लिए ऑडिट लॉगिंग सक्षम करें। MongoDB Enterprise और Atlas ऐसी ऑडिट लॉग धाराएँ प्रदान करते हैं जिन्हें आप SIEM (Security Information and Event Management) प्रणाली तक भेज सकते हैं। ऑडिट फ़िल्टर इस तरह कॉन्फ़िगर करें कि इनमें ये दर्ज हों: सभी authenticate कार्रवाइयाँ, सभी createUser/dropUser/updateUser कार्रवाइयाँ और संवेदनशील कलेक्शन (users, payments) पर होने वाले सभी ऑपरेशन। अनुपालन के लिए ऑडिट लॉग कम-से-कम 1 वर्ष तक रखें।
# mongod.conf — enable audit logging (Enterprise)
auditLog:
destination: file
format: JSON
path: /var/log/mongodb/audit.json
filter: '{
atype: {
$in: ["authenticate", "authCheck", "createUser", "dropUser",
"logout", "createCollection", "dropCollection"]
}
}'जाँच-सूची 10: रनबुक और आपदा पुनर्प्राप्ति योजना
संचालन संबंधी प्रक्रियाओं को एक runbook में दर्ज करें: आपातकाल में MongoDB से कैसे कनेक्ट करें, विफल रेप्लिका सेट सदस्य को कैसे पुनः आरंभ करें, मैन्युअल फेलओवर कैसे करें, बैकअप से पुनर्स्थापन कैसे करें और समस्या को आगे किस स्तर तक पहुँचाना है। इन प्रक्रियाओं का अभ्यास स्टेजिंग वातावरण में करें। एक Recovery Time Objective (RTO) निर्धारित करें—डेटाबेस कितनी देर तक बंद रह सकता है—और एक Recovery Point Objective (RPO)—कितना डेटा खोना स्वीकार्य है। Atlas का सतत बैकअप सेकंडों का RPO प्रदान करता है।
// Runbook checklist (document in your team wiki)
const runbook = {
emergencyConnect: 'mongosh mongodb+srv://adminUser:***@cluster.mongodb.net',
checkReplicaStatus: 'rs.status()',
triggerManualFailover: 'rs.stepDown() // on current primary',
viewReplicationLag: 'rs.printSlaveReplicationInfo()',
restoreFromBackup: 'atlas backups restores start --clusterName prod',
contactList: ['dba-oncall@company.com', '+1-800-DBA-HELP'],
rto: '15 minutes',
rpo: '5 seconds (continuous backup)'
}त्वरित जाँच
इस पाठ में MongoDB और NoSQL डेटाबेस की अवधारणाओं की अपनी समझ जाँचें।
पाठ का पुनरावलोकन
इस समापन परियोजना के अंतिम पाठ में आपने उत्पादन-तत्परता जाँच-सूची पूरी की: प्रमाणीकरण, न्यूनतम-अधिकार वाला RBAC, TLS, नेटवर्क पृथक्करण, बैकअप और परीक्षित पुनर्स्थापन, निगरानी, क्वेरी प्रदर्शन की आधाररेखा, स्थिर डेटा का एन्क्रिप्शन, ऑडिट अभिलेखन और लिखित संचालन पुस्तिका। बधाई हो — आपने अब पहले दस्तावेज़ के समावेशन से लेकर शार्डयुक्त क्लस्टर के उत्पादन परिनियोजन तक, MongoDB और NoSQL डेटाबेस का पूरा पाठ्यक्रम पूरा कर लिया है। इन कौशलों का उपयोग करके कुछ शानदार बनाइए!
एआई शिक्षक के साथ JavaScript सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 30
- पाठ
- 120
अक्सर पूछे जाने वाले प्रश्न
क्या “सुरक्षा सुदृढ़ीकरण और प्रोडक्शन जाँचसूची” पाठ निःशुल्क है?
हाँ—“सुरक्षा सुदृढ़ीकरण और प्रोडक्शन जाँचसूची” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और MongoDB Academy पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। MongoDB Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“सुरक्षा सुदृढ़ीकरण और प्रोडक्शन जाँचसूची” में मैं क्या सीखूँगा?
शिक्षार्थी प्रमाणीकरण, RBAC, TLS, एन्क्रिप्शन, निगरानी और बैकअप रणनीति को शामिल करने वाली प्रोडक्शन-तत्परता जाँचसूची की समीक्षा करेंगे। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ MongoDB Academy का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या MongoDB Academy शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर MongoDB Academy शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।
“सुरक्षा सुदृढ़ीकरण और प्रोडक्शन जाँचसूची” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस MongoDB Academy पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर MongoDB Academy पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- आवश्यकताओं का विश्लेषण और स्कीमा डिज़ाइन
- इंडेक्स रणनीति और क्वेरी प्लानर का सत्यापन
- स्केलिंग योजना: रेप्लिका सेट से शार्डेड क्लस्टर तक
- सुरक्षा सुदृढ़ीकरण और प्रोडक्शन जाँचसूची