VPS पर फुल-डिस्क एन्क्रिप्शन

फुल-डिस्क एन्क्रिप्शन ठीक एक सवाल का जवाब देता है: जब हमलावर के पास आपका स्टोरेज हो और मशीन बंद हो, तो उसे क्या मिलता है? आपके बाकी सभी सवालों — होस्ट क्या देख सकता है, अगर चल रहा सर्वर ज़ब्त हो जाए तो क्या होता है, क्या आपके बैकअप सुरक्षित हैं — का जवाब अलग है, और इन सबको एक मान लेना ही वह तरीका है जिससे लोग ऐसे एन्क्रिप्शन के साथ रह जाते हैं जो कुछ भी सुरक्षित नहीं करता।

यह फ़र्क साफ़ शब्दों में कहने लायक है, क्योंकि इस उद्योग के हर प्राइवेसी-होस्टिंग पेज पर "LUKS-एन्क्रिप्टेड" लिखा मिलता है, हमारा पेज भी शामिल है। यह एक असली नियंत्रण है, इसे चलाने में लगभग कुछ खर्च नहीं होता, और यह होस्टिंग में सबसे ज़्यादा बढ़ा-चढ़ाकर बताया जाने वाला नियंत्रण भी है। यह गाइड कवर करती है: किराये के सर्वर पर रेस्ट में एन्क्रिप्शन असल में क्या रोकता है, तैनात करने लायक तीन तरीके और हर एक के कमांड, छोटे VPS पर असल में मायने रखने वाली दो सेटिंग्स, और वे चंद गलतियाँ जो पूरी कवायद को दिखावे में बदल देती हैं।

रेस्ट में एन्क्रिप्शन असल में किससे बचाता है

रेस्ट में एन्क्रिप्शन का मतलब है कि जब भी वॉल्यूम बंद हो, स्टोरेज मीडियम पर मौजूद बाइट्स सिफरटेक्स्ट हों। यह एक सीमित दावा है, और इसकी क़ीमत एक ही चर पर निर्भर करती है: जिस पल हमलावर पहुंचता है, उस वक़्त कुंजी कहाँ है।

इसे निराशा की तरह नहीं, परिभाषा की तरह पढ़ें। डिस्क-निकाले जाने वाले एक्सपोज़र को हटाना एक घंटे के काम के लायक ठीक इसलिए है क्योंकि यह वह वर्ग है जिसके ख़िलाफ़ आपके पास कोई और बचाव नहीं है, और यह वही है जो बिना किसी के आपको निशाना बनाए होता है: हार्डवेयर ख़राब होकर लौटाया जाता है, ऐरे रिटायर होते हैं, वॉल्यूम अगले टेनेंट को फिर से जारी किए जाते हैं। एन्क्रिप्शन इन सबको एक मामूली बात बना देता है।

VPS लैपटॉप क्यों नहीं है

लैपटॉप पर डिज़ाइन ख़ुद-ब-ख़ुद साफ़ है। आप बूट के समय पासफ़्रेज़ टाइप करते हैं, मशीन जागी रहने तक कुंजी सिर्फ़ RAM में रहती है, और बंद करते ही कहानी ख़त्म हो जाती है। सर्वर के कंसोल पर कोई नहीं होता। हर बूट पर कुंजी कुछ-न-कुछ मुहैया कराना ही होगा, और "कुछ" के हर उम्मीदवार में उपलब्धता को सुरक्षा के बदले में जोखिम में डाला जाता है:

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

ज़्यादातर गाइड जो दूसरा फ़र्क छोड़ देते हैं, वह यह है। VPS पर /boot और initramfs प्लेनटेक्स्ट होते हैं, वे उस स्टोरेज पर रहते हैं जिसे आख़िरकार प्रदाता नियंत्रित करता है, और कोई बूट चेन नहीं है जिसे आप सत्यापित कर सकें — न आपका अपना TPM, न मेज़र्ड बूट, सत्यापित करने के लिए कुछ नहीं। जो होस्ट आपका पासफ़्रेज़ चाहता हो, वह initramfs बदल सकता है और अगली बार जब आप अनलॉक करें तब उसे इकट्ठा कर सकता है। यह इस बात का विवरण नहीं है कि हम क्या करते हैं; यह इस बात का विवरण है कि आर्किटेक्चर क्या अनुमति देता है, और किराये की मशीन के बारे में सोचने का यही एकमात्र ईमानदार तरीका है। हमारी VPS बनाम डेडिकेटेड तुलना हार्डवेयर की तरफ़ से इसी ट्रस्ट बाउंड्री पर चलती है, और ऑफ़शोर गुमनामी पर हमारा ईमानदार जवाब इसी अनुशासन को इसके इर्द-गिर्द की मार्केटिंग पर लागू करता है।

तैनात करने लायक तीन तरीके

कोई एक सही सेटअप नहीं होता — बस वह होता है जिसका फ़ेल होने का तरीक़ा आप झेल सकते हैं। ये तीन तरीक़े लगभग हर असली मामले को कवर करते हैं।

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

चल रहे VPS पर डेटा वॉल्यूम को एन्क्रिप्ट करना

पहले इसी तरीक़े की तरफ़ जाएं। कुछ भी दोबारा इंस्टॉल नहीं होता, बूट प्रोसेस में कुछ नहीं बदलता, और अगर आपसे कोई ग़लती हो जाए तो सबसे बुरा नतीजा बस एक कंटेनर फ़ाइल है जिसे आप फेंक देंगे। लाइव Debian या Ubuntu सर्वर पर पंद्रह मिनट।

• टूलिंग इंस्टॉल करें। apt install cryptsetup। अगर आपके प्लान में दूसरा ब्लॉक डिवाइस मिला है, तो उसे सीधे इस्तेमाल करें और अगला स्टेप छोड़ दें।
• एक कंटेनर बनाएं। सिंगल-डिस्क VPS पर व्यावहारिक रास्ता एक फ़ाइल है: fallocate -l 40G /var/lib/vault.img। यह डिस्क की तरह बर्ताव करती है और बाद में बड़ी की जा सकती है।
• इसे LUKS2 के रूप में फ़ॉर्मैट करें। cryptsetup luksFormat --type luks2 /var/lib/vault.img। सिफर के लिए डिफ़ॉल्ट रहने दें; नीचे वाला सेक्शन उस एक पैरामीटर को कवर करता है जिसे छोटे सर्वर पर छूना लायक है।
• इसे खोलें और फ़ाइल सिस्टम बिछाएं। cryptsetup open /var/lib/vault.img vault आपको /dev/mapper/vault देता है; फिर mkfs.ext4 /dev/mapper/vault और mount /dev/mapper/vault /srv/vault।
• जो डेटा मायने रखता है उसे ले जाएं, फिर सेवाओं को उस तरफ़ इशारा करें। सिम्लिंक की बजाय आमतौर पर एक बाइंड माउंट, या सेवा रोककर किया गया rsync, ज़्यादा साफ़-सुथरा रहता है — डेटाबेस को ख़ासकर इधर-उधर पीछा किए जाना पसंद नहीं।
• LUKS हेडर का बैकअप लें। cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, फिर उस फ़ाइल को सर्वर से बाहर ले जाएं। कंटेनर की शुरुआत में कुछ ख़राब किलोबाइट्स उसके पीछे मौजूद हर बाइट को हमेशा के लिए तबाह कर देते हैं, और यही एकमात्र बीमा है जो मौजूद है।
• इसे बंद करें और साबित करें कि आप वापस अंदर आ सकते हैं। umount /srv/vault && cryptsetup close vault, फिर याददाश्त से नहीं बल्कि अपने नोट्स से इसे दोबारा खोलें। अंदर कुछ भी क़ीमती होने से पहले यह कर लें।

रीबूट के बाद वॉल्ट तब तक बंद रहता है जब तक आप लॉग इन करके इसे खोल न दें। यह कोई सीमा नहीं है जिसके इर्द-गिर्द इंजीनियरिंग करनी हो — यही तो पूरी बात है। जो वॉल्यूम ख़ुद खुल जाए, वह ऐसा वॉल्यूम है जिसकी कुंजी मशीन पर ही है।

SSH पर रिमोट अनलॉक वाला फुल-रूट एन्क्रिप्शन

जब ज़रूरत यह हो कि बंद हालत में हुई ज़ब्ती के बाद कुछ भी पढ़ने लायक न बचे — लॉग, शेल हिस्ट्री, पैकेज लिस्ट, आप क्या चलाते हैं इसकी शक्ल — तो रूट फ़ाइल सिस्टम को भी कंटेनर के अंदर होना पड़ता है। इसके बाद समस्या यह बन जाती है कि ऐसी मशीन में पासफ़्रेज़ कैसे पहुंचाई जाए जो अभी बूट ही नहीं हुई, और इसका जवाब है initramfs में रहने वाला एक छोटा-सा SSH सर्वर।

• शुरुआत से ही एन्क्रिप्टेड इंस्टॉल करें। कस्टम ISO अपलोड के ज़रिए डिस्ट्रिब्यूशन इंस्टॉलर बूट करें और एन्क्रिप्टेड LVM के साथ गाइडेड पार्टीशनिंग चुनें। चल रहे रूट फ़ाइल सिस्टम को उसकी जगह पर ही बदलना संभव है, पर जोखिम लेने लायक नहीं।
• प्री-बूट SSH सर्वर जोड़ें। apt install dropbear-initramfs, फिर अपनी पब्लिक कुंजी /etc/dropbear/initramfs/authorized_keys में डालें। यह आपके सामान्य SSH से अलग कुंजी सेट है — एक समर्पित कुंजी इस्तेमाल करें।
• इसे लॉक कर दें। /etc/dropbear/initramfs/dropbear.conf में, DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s" सेट करें: कोई पासवर्ड लॉगिन नहीं, कोई पोर्ट फ़ॉरवर्डिंग नहीं, अपना ख़ुद का पोर्ट, और एक आइडल टाइमआउट ताकि कोई अटका हुआ सेशन बूट को खुला न रोक सके।
• initramfs को नेटवर्क दें। एक स्टैटिक ip= पैरामीटर GRUB_CMDLINE_LINUX में जोड़ें, जो /etc/default/grub में है — फ़ॉर्म है ip=address::gateway:netmask::interface:off। इस स्टेज पर DHCP पर भरोसा करना ही वह तरीक़ा है जिससे लोग लॉक-आउट हो जाते हैं।
• दोबारा बनाएं और रीबूट करें। update-initramfs -u && update-grub, फिर रीबूट करें और ssh -p 2222 root@your-server से कनेक्ट करके cryptroot-unlock चलाएं। आपका क्लाइंट एक अनजान होस्ट-की की चेतावनी देगा: initramfs की अपनी अलग की है, जो अपेक्षित है और एक अलग known_hosts एंट्री में पिन करने लायक है।
• भरोसा करने से पहले फ़ेल्योर पाथ टेस्ट करें। एक कर्नेल अपडेट इंस्टॉल करें, रीबूट करें, फिर से अनलॉक करें। कर्नेल अपग्रेड initramfs को दोबारा बनाते हैं, और यही वह पल है जब कोई ग़लत कॉन्फ़िगरेशन सामने आता है।

दो सेटिंग्स जो मायने रखती हैं, और छोटे-VPS का जाल

LUKS2 डिफ़ॉल्ट रूप से 512-बिट कुंजी के साथ AES-XTS और Argon2id की-डेरिवेशन इस्तेमाल करता है। दोनों सही हैं। सिफर को हाथ से ट्यून करना एक साथ धीमा और कमज़ोर होने का तरीक़ा है, और इंटरनेट पर ऐसी ही नक़ल की गई कमांड लाइनों की भरमार है। फिर भी, दो चीज़ें आपका ध्यान चाहती हैं।

परफ़ॉर्मेंस तब तक कोई मुद्दा नहीं, जब तक बन नहीं जाती

grep -m1 -o aes /proc/cpuinfo से हार्डवेयर एक्सेलेरेशन चेक करें और cryptsetup benchmark से नापें। AES-NI वाले किसी भी CPU पर — यानी हमारे चलाए हर नोड पर — AES-XTS हर कोर पर हर सेकंड कई गीगाबाइट चलता है, जो सिंगल वर्चुअल डिस्क की डिलीवरी से कहीं ज़्यादा है, इसलिए दिखने वाली क़ीमत भारी I/O के तहत CPU का बस कुछ प्रतिशत और लेटेंसी में मामूली बढ़ोतरी है। AES-NI के बिना तस्वीर पलट जाती है और एन्क्रिप्शन ही बॉटलनेक बन जाता है; यही अकेला मामला है जहाँ कोई वैकल्पिक सिफर कार्गो कल्ट नहीं, बल्कि एक असली फ़ैसला है।

Argon2id की मेमोरी ही असली काटती है

Argon2id जान-बूझकर मेमोरी का भूखा है, और cryptsetup फ़ॉर्मैट के समय इसे उस मशीन की RAM के हिसाब से कैलिब्रेट करता है जिस पर आप फ़ॉर्मैट कर रहे हैं। किसी 32 GB वर्कस्टेशन पर वॉल्यूम फ़ॉर्मैट करें, उसे 1 GB के VPS पर ले जाएं, और अनलॉक करना पूरी तरह फ़ेल हो सकता है क्योंकि की-डेरिवेशन जितनी मेमोरी मांगती है वह वहाँ है ही नहीं — और initramfs के अंदर हालत और बुरी होती है, जहाँ चल रहे सिस्टम से कहीं कम मेमोरी उपलब्ध होती है। छोटे इंस्टेंस पर इसे पिन करें: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb इसे 256 MB पर सीमित कर देता है। कम मेमोरी का मतलब है ऑफ़लाइन ब्रूट फ़ोर्स के प्रतिरोध में असली कमी, तो इसकी भरपाई एक लंबे पासफ़्रेज़ से करें।

एक वैकल्पिक फ़्लैग कॉपी-पेस्ट की बजाय सोच-समझकर तय करने लायक है: --allow-discards TRIM को नीचे मौजूद डिवाइस तक पहुंचाता है, जो SSD के घिसाव और स्थिर-अवस्था परफ़ॉर्मेंस के लिए अच्छा है, और यह भी ज़ाहिर करता है कि वॉल्यूम का कितना हिस्सा इस्तेमाल में है और लगभग कहाँ। यह डिफ़ॉल्ट रूप से बंद है। यह जानते हुए इसे चालू करें कि यह क्या ज़ाहिर करता है।

स्वैप, लॉग, स्नैपशॉट — वे हिस्से जो लोग भूल जाते हैं

चारों तरफ़ प्लेनटेक्स्ट लीक कर रहा एक एन्क्रिप्टेड वॉल्ट सबसे आम विफलता है, और जब तक कोई देखे न, यह अदृश्य रहती है।

• स्वैप। मेमोरी में मौजूद कुछ भी डिस्क पर पेज हो सकता है, यहाँ तक कि वह सामग्री भी जिसे आपने ध्यान से वॉल्ट में रखा। या तो स्वैप बंद करें, या हर बूट पर इसे एक रैंडम कुंजी दें, /etc/crypttab की ऐसी लाइन से: swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256।
• वह सब कुछ जो वहाँ लिखता है जहाँ आपने नहीं देखा। /var/log, /tmp, डेटाबेस डेटा डायरेक्टरी, /var/lib/docker, शेल हिस्ट्री, systemd जर्नल। /srv/vault को एन्क्रिप्ट करना, जबकि PostgreSQL /var/lib/postgresql पर लिखता रहे, बिल्कुल कुछ हासिल नहीं करता। एन्क्रिप्ट करने से पहले गिनती कर लें।
• स्नैपशॉट। एन्क्रिप्टेड वॉल्यूम का ब्लॉक-स्तरीय स्नैपशॉट सिफरटेक्स्ट है इसलिए ठीक है। मेमोरी स्टेट कैप्चर करने वाला स्नैपशॉट पूरी तरह अलग चीज़ है और इसमें कुंजी हो सकती है। इस्तेमाल करने से पहले जान लें कि आपके प्रदाता का पैनल कौन-सा प्रकार लेता है।
• बैकअप। इसे हल करने के लिए गंतव्य ग़लत जगह है। restic और BorgBackup जैसे टूल स्रोत पर ही ऐसी कुंजी से एन्क्रिप्ट करते हैं जिसे लक्ष्य कभी नहीं देखता, यही वजह है कि बैकअप सर्वर भरोसेमंद मशीन की बजाय किसी दूसरे क्षेत्राधिकार में एक साधारण मशीन हो सकता है।
• वह प्लेनटेक्स्ट जो आप पहले ही कहीं भेज चुके हैं। रेस्ट में एन्क्रिप्शन पूर्वव्यापी नहीं है। जो कुछ भी पहले ही कॉपी, मेल या सिंक किया जा चुका है, वह अब आपके खींचे जा रहे दायरे से बाहर है।

कुंजी कहाँ रहती है, यही पूरा डिज़ाइन है

ऊपर बताया हर तरीक़ा असल में कुंजी की हिफ़ाज़त के बारे में एक बयान है। चार विकल्प मौजूद हैं और वे एक-दूसरे के बराबर नहीं हैं:

• आपके दिमाग़ में, हर बूट पर टाइप की गई। अधिकतम सुरक्षा, अधिकतम परिचालन घर्षण। मशीन को आपके बिना सचमुच नहीं पढ़ा जा सकता।
• एन्क्रिप्टेड मशीन पर एक फ़ाइल में। यह सिर्फ़ भोली-भाली डिस्क रीसेल से बचाता है, और कुछ नहीं। अगर वह फ़ाइल प्लेनटेक्स्ट /boot पर रखी है, तो यह बिल्कुल कुछ नहीं बचाती — सेल्फ़-होस्टेड एन्क्रिप्शन में यह सबसे आम अकेली ग़लती है।
• आपके नियंत्रण वाली मशीन पर, नेटवर्क पर लाई गई। Tang सर्वर से बंधा Clevis: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'। जब तक सर्वर घर तक पहुंच सके, यह बिना किसी के बूट होता है और कहीं और अनलॉक होने से इनकार करता है। हेडलेस फ़्लीट के लिए बेहतरीन, और यह Tang होस्ट को वह चीज़ बना देता है जिसकी हिफ़ाज़त ज़रूर होनी चाहिए।
• TPM में। आपके मालिकाना हार्डवेयर पर सार्थक। VPS पर वर्चुअल TPM उसी हाइपरवाइज़र से मिलता है जिसे आप बाहर रखने की कोशिश कर रहे हैं, इसलिए यह भरोसे की नहीं, सुविधा की समस्या हल करता है।

एक टेस्ट ज़्यादातर डिज़ाइन तय कर देता है: अगर मशीन आपके बिना लॉगिन प्रॉम्प्ट तक पहुंच सकती है, तो कुंजी मशीन पर ही है। यह पूरी तरह एक जायज़ समझौता हो सकता है — बहुत सारे वर्कलोड किसी दृढ़ हमलावर के प्रतिरोध से ज़्यादा बिना निगरानी वाला रीबूट चाहते हैं। यह चुनाव सोच-समझकर करें, और नतीजे को वह मत बताइए जो यह नहीं है।

आपका होस्ट क्या देख सकता है, और कहाँ से क्षेत्राधिकार संभाल लेता है

VPS पर आपके नीचे एक हाइपरवाइज़र बैठा होता है। हम गेस्ट मेमोरी नहीं पढ़ते, और हम कोई ट्रैफ़िक, कनेक्शन या DNS लॉग और कोई कंसोल ट्रेल नहीं रखते — लेकिन ये नीतियाँ हैं, और ईमानदार बात यह है कि VPS आपसे इन पर भरोसा करने को कहता है। बेयर मेटल पर आपके और सिलिकॉन के बीच कोई हाइपरवाइज़र नहीं होता: इंस्टॉल के समय ऐसे पासफ़्रेज़ के साथ सेट किया गया फुल-डिस्क एन्क्रिप्शन जो हमें कभी नहीं मिलता, हमारी तरफ़ से भरोसा दिलाना नहीं बल्कि मशीन का भौतिक गुण है। यही फ़र्क है, न कि सिफर की पसंद, जिसके बीच आप असल में चुनाव कर रहे हैं।

यही वजह है कि एन्क्रिप्शन और क्षेत्राधिकार एक ही जवाब के दो हिस्से हैं। एन्क्रिप्शन तय करता है कि आपकी डिस्क की कॉपी की क़ीमत क्या है; क्षेत्राधिकार तय करता है कि मशीन को पेश करने के लिए किसके पास मजबूर करने की ताक़त है, किस प्रक्रिया से और कितनी जल्दी। हम सात जगह चलते हैं — आइसलैंड, स्विट्ज़रलैंड, पनामा, रोमानिया, मोल्दोवा, नीदरलैंड्स और रूस — और इनके बीच चुनने की वजहें हमारी क्षेत्राधिकार गाइड में हैं, या संक्षेप में क्षेत्राधिकार सिलेक्टर और लोकेशन पेज के ज़रिए।

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

नौ ग़लतियाँ जो एन्क्रिप्शन को दिखावा बना देती हैं

• उसी डिस्क पर मौजूद की-फ़ाइल से ऑटो-अनलॉक करना। ज़्यादातर "एन्क्रिप्टेड" सर्वर यही करते हैं, और यह ताले में ही चाबी छोड़ देने जैसा है।
• ऐसा वॉल्यूम एन्क्रिप्ट करना जहाँ संवेदनशील डेटा कभी पहुंचता ही नहीं। वॉल्ट ख़ाली है और डेटाबेस उसमें है ही नहीं।
• LUKS हेडर का बैकअप कभी न लेना। कंटेनर के आगे का एक ख़राब सेक्टर, और उसके पीछे मौजूद हर बाइट हमेशा के लिए चली जाती है।
• अनलॉक पाथ को कभी टेस्ट न करना। फिर एक कर्नेल अपग्रेड initramfs को दोबारा बना देता है और अगला रीबूट एक रेस्क्यू ऑपरेशन बन जाता है।
• बड़ी मशीन पर फ़ॉर्मैट करना और छोटी मशीन पर अनलॉक करना। Argon2id उतनी मेमोरी मांगता है जो VPS दे नहीं सकता, और वॉल्यूम खुलेगा नहीं।
• लॉगिन पासवर्ड जैसा पासफ़्रेज़ चुनना। की-डेरिवेशन फ़ंक्शन के अलावा कुछ भी ऑफ़लाइन हमले की रफ़्तार सीमित नहीं करता। समय ख़रीदने वाली चीज़ लंबाई है।
• प्लेनटेक्स्ट को एन्क्रिप्शन में माइग्रेट करके यह मान लेना कि ओरिजिनल मिट गया। वर्चुअलाइज़्ड स्टोरेज पर, ओवरराइट करना भरोसे के साथ मिटाता नहीं है।
• बॉक्स को एडमिनिस्टर करने वाले उसी चैनल से पासफ़्रेज़ भेजना। Server OpSec इससे बनने वाली कोरिलेशन समस्या को कवर करता है।
• अपने प्रदाता के एन्क्रिप्शन को अपने ख़ुद के एन्क्रिप्शन से गड्डमड्ड करना। "सारा इन्फ्रास्ट्रक्चर रेस्ट में एन्क्रिप्टेड है" — हमारा भी शामिल है — यह इन्फ्रास्ट्रक्चर को सुरक्षित करता है। सिर्फ़ वह कुंजी जो आप ख़ुद रखते हैं, आपको इन्फ्रास्ट्रक्चर से सुरक्षित करती है।

तो क्या VPS पर यह करना लायक है?

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

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