कोई कॉन्ट्रैक्टर जिसे इंपोर्ट ठीक करना है, कोई क्वेरी तेज़ करनी है या कोई टेबल माइग्रेट करनी है, उसे आमतौर पर इसके लिए डेटाबेस लॉगिन चाहिए होता है। खतरा शायद ही कभी कॉन्ट्रैक्टर से होता है। खतरा लॉगिन से होता है: जल्दबाज़ी में बना, काम से ज़्यादा एक्सेस वाला, ईमेल में पेस्ट किया हुआ, और इनवॉइस चुकाने के छह महीने बाद भी चालू।
इसका हल एक छोटी-सी प्रक्रिया है। तय करें कि सीधी एक्सेस की ज़रूरत है भी या नहीं, ऐसा यूज़र बनाएं जिसका दायरा सीमित हो और जिसकी आखिरी तारीख पहले से तय हो, पासवर्ड कॉपी रखने वाले मैसेज के बजाय वन-टाइम सीक्रेट लिंक से भेजें, नेटवर्क का रास्ता सीमित करें, और काम पूरा होते ही अकाउंट बंद कर दें। यह गाइड हर कदम बताती है, और जहां मदद मिले वहां सटीक कमांड भी देती है।
क्या कॉन्ट्रैक्टर को डेटाबेस की सीधी एक्सेस चाहिए?
अनुरोध से नहीं, काम से शुरू करें। “इंपोर्ट ठीक कर दें” का मतलब एक टेबल पढ़ना भी हो सकता है और आधे स्कीमा पर लिखने की एक्सेस भी। पूछें कि कौन-सा ऑपरेशन, कौन-सा एनवायरनमेंट और कौन-सी टेबल शामिल हैं, फिर उसे देने का कोई सस्ता तरीका ढूंढें।
- staging डेटाबेस, जिसमें हाल की और साफ़ की गई कॉपी हो, ज़्यादातर डायग्नोस्टिक और माइग्रेशन के काम के लिए काफ़ी है, और इसमें ग्राहकों के लाइव रिकॉर्ड सामने नहीं आते।
- ऐप्लिकेशन या एडमिन API अक्सर तब काफ़ी होता है, जब कॉन्ट्रैक्टर को स्कीमा नहीं, डेटा बदलना हो।
- read replica सिर्फ़ पढ़ने वाले विश्लेषण के काम को प्राइमरी को छुए बिना चलने की जगह देती है।
अगर इनमें से कुछ भी काम न आए और प्रोडक्शन की एक्सेस देनी ही पड़े, तो एक लाइन में लिखें कि क्यों। बाद में कोई इस एक्सेस का ऑडिट करे, तो यही नोट उसका कारण बनता है।
ऐसा यूज़र बनाएं जिसका दायरा सीमित हो और एक्सपायरी पहले से तय हो
कभी भी साझा लॉगिन या किसी कर्मचारी की लॉगिन की जानकारी न सौंपें। अलग यूज़र से ही आप देख पाते हैं कि कॉन्ट्रैक्टर ने क्या किया, सीमित कर पाते हैं कि वह कहां तक पहुंच सकता है, और किसी और पर असर डाले बिना उसे हटा पाते हैं। यूज़र बनाते समय ही उसकी एक्सपायरी सेट करें, ताकि आप भूल भी जाएं तो एक्सेस खत्म हो जाए।
PostgreSQL में ऐसा यूज़र, जो सिर्फ़ दो टेबल पढ़ सकता है और एक तय तारीख पर काम करना बंद कर देता है, ऐसा दिखता है:
CREATE ROLE contractor_jo LOGIN PASSWORD 'generated-elsewhere'
VALID UNTIL '2026-11-08 18:00+00';
GRANT CONNECT ON DATABASE app TO contractor_jo;
GRANT USAGE ON SCHEMA public TO contractor_jo;
GRANT SELECT ON orders, order_items TO contractor_jo;
MySQL में CREATE USER ... PASSWORD EXPIRE INTERVAL 14 DAY है, और RDS, Cloud SQL और Supabase जैसी मैनेज्ड सर्विसें यही काम अपने कंसोल से या IAM पर आधारित कम समय वाले टोकन से करने देती हैं। आपका प्लेटफ़ॉर्म जो सपोर्ट करे, वही इस्तेमाल करें, और पासवर्ड खुद टाइप करने के बजाय पासवर्ड मैनेजर से बनाएं।
तय काम पूरा करने के लिए जितनी अनुमतियां सबसे कम ज़रूरी हों, उतनी ही दें। डायग्नोस्टिक काम के लिए इसका मतलब है खास टेबल पर SELECT। माइग्रेशन के लिए इसका मतलब है सिर्फ़ उन ऑब्जेक्ट पर लिखने की एक्सेस जो बदलेंगे, और कुछ नहीं। अस्थायी अकाउंट के लिए owner और superuser रोल कभी सही जवाब नहीं हैं।
कॉन्ट्रैक्टर को अस्थायी डेटाबेस लॉगिन कैसे भेजें
हैंडओवर में सिर्फ़ पासवर्ड ही ऐसा हिस्सा है जिसे गोपनीय रहना है। होस्ट, पोर्ट, डेटाबेस का नाम और यूज़रनेम हमलावर के काम के तो हैं, लेकिन अकेले काफ़ी नहीं, इसलिए ये सामान्य मैसेज में जा सकते हैं। दोनों को अलग रखें।
- प्राप्तकर्ता की पुष्टि करें ऐसे चैनल से जिस पर आपको पहले से भरोसा है, जैसे कॉन्ट्रैक्ट वाला ईमेल थ्रेड या कॉल। मिलते-जुलते पते लॉगिन की जानकारी के गलत इनबॉक्स में पहुंचने का आम ज़रिया हैं।
- सिर्फ़ पासवर्ड वाला वन-टाइम सीक्रेट लिंक बनाएं। LinkPilot में टेक्स्ट स्टोर होने से पहले आपके ब्राउज़र में ही एन्क्रिप्ट होता है, लिंक पहली बार खुलते ही स्टोर की गई कॉपी मिट जाती है, और आप एक घंटे, 24 घंटे या सात दिन की एक्सपायरी चुन सकते हैं। Pro अकाउंट अपनी पसंद की एक्सपायरी सेट कर सकते हैं, पासफ़्रेज़ जोड़ सकते हैं और ऑडिट टाइमलाइन में देख सकते हैं कि लिंक कब खुला।
- लिंक सामान्य थ्रेड में भेजें, साथ में एक लाइन का नोट कि यह किसलिए है और कब एक्सपायर होगा। यूज़रनेम उसी मैसेज में न डालें जिसमें लिंक है।
- कनेक्शन की जानकारी अलग से भेजें: होस्ट, पोर्ट, डेटाबेस, यूज़रनेम, और TLS ज़रूरी है या नहीं। दूसरा ईमेल या टिकट पर कमेंट काफ़ी है, क्योंकि इसमें अकेले कुछ भी गोपनीय नहीं है।
- पासफ़्रेज़ सेट किया हो, तो उसे किसी दूसरे चैनल से भेजें, जैसे टेक्स्ट मैसेज से या कॉल पर।
- कॉन्ट्रैक्टर से कन्फ़र्म करवाएं कि लिंक खुल गया। अगर लिंक बताए कि वह पहले ही देखा जा चुका है और कॉन्ट्रैक्टर ने उसे नहीं खोला, तो पासवर्ड को उजागर मानें और बदल दें।
अगर कॉन्ट्रैक्टर पहले से आपके वॉल्ट में है, तो पासवर्ड मैनेजर का शेयर फ़ीचर भी ठीक विकल्प है। एक बार के काम में वन-टाइम लिंक से भेजें, तो सिर्फ़ एक वैल्यू सौंपने के लिए अकाउंट नहीं बनाना पड़ता। सीक्रेट लिंक बनाम पासवर्ड मैनेजर गाइड बताती है कि कौन-सा कब सही रहता है।
कनेक्शन को सुरक्षित करें
खुले पोर्ट पर सही दायरे वाला यूज़र भी समस्या है। ये तीन उपाय ज़्यादातर कमी दूर कर देते हैं।
- TLS ज़रूरी करें और कॉन्ट्रैक्टर से कहें कि अपने क्लाइंट में
sslmode=requireया उसके बराबर की सेटिंग लगाए। अगर आप ज़ोर न दें, तो कई क्लाइंट चुपचाप सादे टेक्स्ट पर लौट आते हैं। - कनेक्शन का स्रोत सीमित करें IP allowlist, VPN या bastion host से। काम के दौरान कॉन्ट्रैक्टर के पते को allowlist में डालना जल्दी सेट होता है और जल्दी हटता है।
- सिर्फ़ वही शेयर करें जो काम के लिए ज़रूरी है। कॉन्ट्रैक्टर को अंदरूनी नेटवर्क का डायग्राम, सर्वर के दूसरे डेटाबेस या एडमिन कंसोल का URL नहीं चाहिए।
अगर आपका प्लेटफ़ॉर्म स्थायी पासवर्ड की जगह कम समय वाले IAM टोकन देता है, तो आमतौर पर वही बेहतर विकल्प है, और इससे पासवर्ड सौंपने की ज़रूरत ही खत्म हो जाती है।
अकाउंट पर नज़र रखें और उसे बंद करें
काम शुरू होने से पहले नए यूज़र के लिए ऑथेंटिकेशन और क्वेरी लॉगिंग चालू करें, ताकि आप तय हुए काम से असल में हुए काम की तुलना कर सकें। अजीब समय पर लॉगिन या असंबंधित टेबल पर क्वेरी दिखें, तो सवाल पूछें, आरोप न लगाएं।
काम खत्म होने पर, या दायरा बदलने पर, उसी दिन चार काम करें:
- यूज़र को ड्रॉप या डिसेबल करें और पक्का कर लें कि वह अब कनेक्ट नहीं हो सकता।
- नेटवर्क की वह अनुमति हटाएं जो आपने उसके लिए जोड़ी थी।
- लॉगिन के साथ गया हर सीक्रेट बदल दें, जैसे उसी टिकट में मौजूद कोई ऐप्लिकेशन पासवर्ड।
- हैंडओवर दर्ज करें: किसके पास एक्सेस थी, किस चीज़ की, कब से कब तक, और क्यों। रिकॉर्ड रखें, पासवर्ड नहीं।
जिस अस्थायी लॉगिन का दायरा सीमित है, जो एक्सपायर होता है, एक बार भेजा जाता है और समय पर बंद होता है, वह सुरक्षा का कोई अपवाद नहीं है। कॉन्ट्रैक्टर को एक्सेस देने का सही तरीका यही है।