निजी होस्टिंग एक यथार्थवादी खतरा मॉडल से शुरू होती है।

पहचान को गोपनीयता से अलग रखें

नो-KYC खाता नियमित दस्तावेज़ संग्रह को कम करता है। यह सार्वजनिक DNS, खुले पोर्ट, सॉफ़्टवेयर फ़िंगरप्रिंट, ब्लॉकचेन लेनदेन या आपके द्वारा प्रकाशित जानकारी को नहीं छिपाता। एन्क्रिप्शन विशिष्ट डेटा पथों की रक्षा करता है; यह हर गतिविधि को अनाम नहीं बनाता।

पर्यवेक्षकों का मानचित्रण करें

होस्ट, भुगतान नेटवर्क, एक्सचेंज, डोमेन रजिस्ट्रार, DNS ऑपरेटर, अपस्ट्रीम कनेक्टिविटी और बाहरी API पर विचार करें। वे अलग-अलग जानकारी देखते हैं। लिख लें कि प्रत्येक पक्ष को क्या चाहिए और बिना कारण हर जगह एक ही व्यक्तिगत पहचानकर्ता भेजने से बचें।

एक व्यावहारिक आधारभूत स्थिति अपनाएँ

समर्थित सॉफ़्टवेयर चुनें, लॉगिन सुरक्षित करें, रहस्यों को अलग रखें और बैकअप रखें। एक समझौता किया गया एप्लिकेशन अपूर्ण मार्केटिंग लेबल की तुलना में अधिक प्रत्यक्ष गोपनीयता विफलता है। आपके द्वारा उजागर की गई सेवाओं की निगरानी करें और जिन्हें अब उपयोग नहीं करते उन्हें हटा दें।

वादों को प्रमाण के विरुद्ध जाँचें

ऑपरेटर की पहचान, प्रतिधारण नीति, स्वीकार्य-उपयोग की शर्तें और कानूनी प्रबंधन पढ़ें। परिभाषित बैकअप नीति और सत्यापित अवसंरचना विवरण माँगें। कोई भी प्रदाता कानूनी प्रक्रिया से सार्वभौमिक छूट का वादा नहीं कर सकता।

तीन परतों का स्वतंत्र रूप से आकलन करें

प्रदाता खाता एकत्रित पहचान और सेवा रिकॉर्ड से संबंधित है। भुगतान परत वॉलेट इतिहास, मध्यस्थों और चालान डेटा से संबंधित है। वर्कलोड परत अनुप्रयोगों, सार्वजनिक पहचानकर्ताओं और पहुँच नियंत्रणों से संबंधित है। एक परत में सुधार अपने आप अन्य परतों की कमज़ोरी को ठीक नहीं करता।

गोपनीयता दावों के पीछे के साक्ष्य पढ़ें

पारदर्शिता रिपोर्टों में तिथियाँ और गणना विधि आवश्यक है। वारंट कैनरी में सटीक शब्दावली और सत्यापित प्रकाशन प्रक्रिया आवश्यक है, और यह किसी अनुपस्थित कानूनी माँग का निर्णायक प्रमाण नहीं है। क्षेत्राधिकार के दावों के लिए वास्तविक कानूनी ऑपरेटर आवश्यक है। सबसे अधिक भार उन प्रथाओं पर रखें जिन्हें आप निरीक्षित कर सकते हैं: न्यूनीकरण, प्रतिधारण, पहुँच और पुनर्प्राप्ति।

गोपनीयता वरीयता को स्वीकृति मानदंड में बदलें

होस्ट की तुलना करने से पहले, प्रत्येक पर्यवेक्षक के लिए एक संक्षिप्त आवश्यकता लिखें। आवश्यकता जाँचने योग्य होनी चाहिए: कौन-से साइनअप फ़ील्ड अनिवार्य हैं, कौन-सा भुगतान एसेट और नेटवर्क समर्थित है, कौन-से एप्लिकेशन लॉग रखे जाते हैं, और कौन-सा ऑपरेटर आपके साथ अनुबंध करता है। तय करें कि कौन-से अनुत्तरित प्रश्न परिनियोजन को रोकेंगे। किसी ब्रांड का शुभंकर, राष्ट्रीय ध्वज या भुगतान लोगो इन उत्तरों का विकल्प नहीं हो सकता।

• साइनअप: वास्तविक आवश्यक फ़ील्ड और रिकवरी प्रवाह की जाँच करें; वैकल्पिक प्रोफ़ाइल फ़ील्ड को बिलिंग पूर्वापेक्षा से अलग पहचानें।
• भुगतान: अंतिम चालान, शुल्क और धनवापसी नियम पढ़ें। जाँचें कि क्या किसी मध्यस्थ की अपनी पहचान आवश्यकताएँ हैं।
• नेटवर्क: सार्वजनिक A/AAAA रिकॉर्ड, लिसनिंग सेवाओं और तृतीय-पक्ष API कनेक्शनों की सूची बनाएँ। दर्ज करें कि क्या अवलोकनीय रहता है।
• क्षेत्राधिकार: प्राथमिक डेटा, बैकअप, सहायता पहुँच और अनुबंध करने वाली इकाई की पहचान करें। अपनी समीक्षा में उपयोग की गई नीति संस्करण रखें।

आधिकारिक दस्तावेज़: EDPB: नियंत्रक और प्रोसेसर की जिम्मेदारियाँ

पूरा स्टैक स्थानांतरित करने से पहले एक सेवा का परीक्षण करें

पहुँच, रीबूट व्यवहार, सहायता निर्देश और एक स्वतंत्र पुनर्स्थापना का परीक्षण करने के लिए एक छोटा, गैर-संवेदनशील परिनियोजन उपयोग करें। देखा गया परिणाम और तिथि दर्ज करें। एक सफल इंस्टॉलेशन को सामान्य अपटाइम या गोपनीयता दावे में न बदलें। यदि कोई एप्लिकेशन अप्रत्याशित रूप से अपना मूल पता उजागर करता है, तो होस्टिंग प्रदाता बदलने से पहले DNS, प्रमाणपत्र नाम और सीधे नेटवर्क श्रोताओं की जाँच करें।

• एक संक्षिप्त प्रमाण रिकॉर्ड रखें: दावा, स्रोत, जाँच की तारीख, वास्तविक परीक्षण और अनसुलझी सीमा।
• कुल की तुलना करने से पहले पारदर्शिता रिपोर्ट की समय अवधि और परिभाषाएँ पढ़ें। अनुपस्थित या बदला हुआ वारंट कैनरी संदर्भ की मांग करता है, स्वतः निष्कर्ष का नहीं।
• CDN, भुगतान प्रोसेसर, मॉनिटरिंग टूल या बाहरी मॉडल API जोड़ते समय समीक्षा को फिर से देखें; डेटा पथ बदल गया है।

आधिकारिक दस्तावेज़: लेट्स एन्क्रिप्ट: प्रमाणपत्र पारदर्शिता