निजी रूप से प्राप्त सर्वर को अलग रखना
दूरस्थ पहुँच, परियोजना identities, metadata, नवीनीकरण और एन्क्रिप्टेड बैकअप के लिए टिकाऊ आदतें बनाएँ।
एक नज़र में
निजी रूप से अर्जित सर्वर को अलग रखने के लिए निरंतर देखभाल आवश्यक है: समर्पित क्रेडेंशियल, सुसंगत प्रशासन पथ, सॉफ़्टवेयर अपडेट, अनुप्रयोग कॉन्फ़िगरेशन और परीक्षित बैकअप। व्यक्तिगत खाते, डोमेन रिकॉर्ड या टोकन सावधानीपूर्वक खरीद के बाद लिंक बना सकते हैं। संचालन, नवीनीकरण और पुनर्प्राप्ति के दौरान उन विकल्पों की समीक्षा करें।
गोपनीयता योजना को पहले दिन से आगे टिकाऊ बनाएँ
सावधानीपूर्वक सर्वर खरीद केवल शुरुआत है। बाद के लॉगिन, सॉफ़्टवेयर कॉन्फ़िगरेशन, भुगतान और बैकअप ऐसे पहचानकर्ता लिंक बना सकते हैं जो साइनअप में अनुपस्थित थे। गोपनीयता को एक संचालन अभ्यास मानें जो मशीन के साथ उसके पूरे जीवनकाल तक चलता है।
यह मार्गदर्शिका मानती है कि आपने ऑर्डर की identity और भुगतान आवश्यकताओं पर पहले ही विचार कर लिया है। यदि आवश्यक हो तो पहले उस चरण की समीक्षा करें। फिर परिभाषित करें कि क्या अलग रहना चाहिए: आपकी सार्वजनिक identity, कोई अन्य परियोजना, घरेलू नेटवर्क या विशेष खाते। योजना को वास्तविक चिंता का समाधान करना चाहिए और नियमित रखरखाव के दौरान व्यावहारिक बने रहना चाहिए।
दोहराने योग्य प्रबंधन मार्ग का उपयोग करें
एक संरक्षित एक्सेस पथ चुनें और इसे अपने SSH कॉन्फ़िगरेशन में डिफ़ॉल्ट बनाएँ। एक Tor SOCKS मार्ग या क्लाइंट-अधिकृत ओनियन एंडपॉइंट गंतव्य तक सीधे घरेलू IP को उजागर करने से बच सकता है। DNS व्यवहार और होस्ट प्रमाणीकरण की जाँच करें, और सार्वजनिक SSH को प्रतिबंधित करने से पहले एक रिकवरी विधि तैयार करें।
एक समर्पित प्रशासनिक खाता और SSH कुंजी का उपयोग करें। कुंजी प्रमाणीकरण का परीक्षण करने के बाद, पासवर्ड और अत्यधिक दूरस्थ विशेषाधिकार अक्षम करें। लंबे कार्यों को एक स्थायी टर्मिनल सत्र के भीतर रखें। एक वर्कफ़्लो जो आउटेज के दौरान विश्वसनीय होता है, जल्दबाजी में मरम्मत के लिए बायपास होने की संभावना कम होती है।
तैनाती से पहले पहचान करने वाले डेटा की समीक्षा करें
फ़ाइलें और एप्लिकेशन सेटिंग्स होस्टिंग खाते से अधिक उजागर कर सकती हैं। Git लेखक मेटाडेटा, प्रमाणपत्र संपर्क पते, व्यक्तिगत API क्रेडेंशियल, कॉपी की गई SSH कुंजियाँ और दस्तावेज़ गुण सभी किसी प्रोजेक्ट को किसी व्यक्ति से जोड़ सकते हैं। छवियाँ EXIF स्थान जानकारी या पहचान करने वाले फ़ाइल नाम बनाए रख सकती हैं।
उस डेटा की समीक्षा करें जिसकी आपको वास्तव में आवश्यकता है, फिर बाकी को न्यूनतम करें। संवेदनशील संग्रहीत सामग्री को एन्क्रिप्ट करें और सेवाओं के लिए TLS का उपयोग करें, यह याद रखते हुए कि भौतिक होस्ट को नियंत्रित करने वाला VPS प्रशासक अभी भी चल रही मेमोरी तक पहुँच सकता है। यह मानने से बचें कि स्टोरेज एन्क्रिप्शन या निजी साइनअप हर संभावित अवलोकन की रक्षा करता है।
- प्रोजेक्ट-विशिष्ट SSH कुंजियाँ और पासवर्ड जनरेट करें।
- Git लेखक और प्रमाणपत्र संपर्क सेटिंग्स की जाँच करें।
- अनावश्यक दस्तावेज़ और छवि मेटाडेटा हटाएँ।
- व्यक्तिगत ब्राउज़र सत्र और खाता निर्यात सर्वर से दूर रखें।
- एप्लिकेशन टेलीमेट्री और तृतीय-पक्ष एकीकरण का निरीक्षण करें।
पहुँच खोए बिना विभाजन करें
जहाँ अलगाव मायने रखता है वहाँ अलग प्रोजेक्ट क्रेडेंशियल, मेलबॉक्स और खाता नाम का उपयोग करें। किसी प्रोजेक्ट मेलबॉक्स को व्यक्तिगत रिकवरी नंबर, फ़ॉरवर्डिंग पता या पुनः उपयोग किए गए हैंडल से न जोड़ें। एक समर्पित ब्राउज़र प्रोफ़ाइल, उपयोगकर्ता खाता या वर्चुअल मशीन सत्रों के आकस्मिक मिश्रण को कम कर सकती है।
विभाजन के लिए उपयोगी रिकवरी भी चाहिए। क्रेडेंशियल को एक एन्क्रिप्टेड मैनेजर में एक जानबूझकर बनाई गई बैकअप रणनीति के साथ संग्रहीत करें, और दस्तावेज़ित करें कि कौन सी पहचान किस सेवा की मालिक है। अलग-अलग जोखिम वाली गतिविधियों को अलग करें, बजाय इतनी सारी पहचानें बनाने के कि आप अनिवार्य रूप से उनका पुनः उपयोग करें या ट्रैक खो दें।
नवीनीकरण को एक और संवेदनशील कार्रवाई मानें
नवीनीकरण मूल खरीद की भुगतान और खाता सतहों को दोहराते हैं। वही प्रोजेक्ट मेलबॉक्स और संरक्षित सत्र रखें, और सुविधा के लिए किसी पहचान वाले खाते पर स्विच करने के बजाय चुने गए वॉलेट के माध्यम से भुगतान करें। जल्दबाजी में रिकवरी या अप्रत्याशित आउटेज से बचने के लिए तारीखों की जल्दी जाँच करें।
फंडिंग रिकॉर्ड और समय पर ध्यान देना चाहिए, लेकिन फंड को अनाम बनाने के लिए किसी मनमानी प्रतीक्षा अवधि पर भरोसा न करें। यदि प्रीपेमेंट उपलब्ध है, तो प्रदाता को प्रतिबद्ध अतिरिक्त फंड के मुकाबले कम भुगतान इंटरैक्शन तौलें। प्रत्येक इनवॉइस संदर्भ को निजी तौर पर सहेजें, बिना अनावश्यक पहचान करने वाले नोट जोड़े।
सेवा और उसकी पहचान का जानबूझकर बैकअप लें
चुनें कि डिस्क विफलता में क्या बचना चाहिए: एप्लिकेशन डेटाबेस, अटैचमेंट, कॉन्फ़िगरेशन, सेवा कुंजियाँ और उन्हें पुनर्स्थापित करने के निर्देश। सुसंगत डेटाबेस बैकअप बनाएँ, संग्रह को मशीन से बाहर भेजने से पहले एन्क्रिप्ट करें और एन्क्रिप्शन रिकवरी सामग्री की एक अलग प्रति रखें।
बैकअप गंतव्य और स्थानांतरण मार्ग अपने स्वयं के खाता लिंक बना सकते हैं। उन्हें अपने खतरे के मॉडल के अनुसार चुनें, बजाय स्वचालित रूप से व्यक्तिगत क्लाउड स्टोरेज का उपयोग करने के। एक पृथक वातावरण में पुनर्स्थापन का परीक्षण करें और सुनिश्चित करें कि यह अप्रत्याशित रूप से पहचान वाले खातों से संपर्क न करे या मूल सेवा को प्रकाशित न करे।
छोटे क्रॉसओवर पर नज़र रखें
सामान्य लिंक साधारण सुविधा से आते हैं: किसी सार्वजनिक हैंडल का पुनः उपयोग, एक बार सीधे जुड़ना, व्यक्तिगत कॉन्फ़िगरेशन फ़ाइल की प्रतिलिपि बनाना या पहचान वाले खाते के माध्यम से किसी प्रोजेक्ट पर चर्चा करना। तकनीकी पहचानकर्ता भिन्न होने पर भी व्यवहार और सामग्री संबंधों को प्रकट कर सकते हैं।
सॉफ़्टवेयर जोड़ने या डिवाइस बदलने के बाद समय-समय पर अपने सेटअप की समीक्षा करें। पूछें कि क्या प्रबंधन मार्ग, DNS, क्रेडेंशियल, लॉग और बैकअप गंतव्य अभी भी योजना से मेल खाते हैं। होस्टिंग प्रदाता अपना संग्रह न्यूनतम कर सकता है, लेकिन आपके एप्लिकेशन के माध्यम से आपके द्वारा प्रकाशित जानकारी को रोक नहीं सकता।
- क्लाइंट परिवर्तनों के बाद स्रोत पते और दूरस्थ DNS की जाँच करें।
- एकीकरण स्थापित करने से पहले नए क्रेडेंशियल और बाहरी खातों की समीक्षा करें।
- सहायता संदेशों को आवश्यक सेवा विवरण तक सीमित रखें।
- कॉन्फ़िगरेशन में व्यक्तिगत नाम, होस्टनाम और ईमेल पते खोजें।
- समय-समय पर बैकअप पुनर्स्थापन और खाता रिकवरी का पुनः परीक्षण करें।
ऐसी दिनचर्याएँ बनाएँ जिन्हें आप बनाए रख सकें
निजी अधोसंरचना के लिए अभी भी पैच, संसाधन निगरानी और समझदार दुरुपयोग रोकथाम की आवश्यकता होती है। उपयोगी डायग्नोस्टिक्स को आँख मूंदकर न त्यागें: सेवा के अनुकूल एक दायरा और छोटी अवधारण अवधि चुनें, फिर शेष परिचालन डेटा की रक्षा करें।
टिकाऊ परिणाम कम अनावश्यक लिंक वाला एक प्रबंधनीय सर्वर है, अदृश्यता की गारंटी नहीं। रखरखाव और रिकवरी को प्रारंभिक ऑर्डर की तरह ही सावधानी से तैयार करें, और प्रोजेक्ट के बढ़ने पर अलगाव बनाए रखें।