VPS'te Tam Disk Şifreleme

Tam disk şifrelemesi tek bir soruyu tam olarak yanıtlar: bir düşman, depolama biriminizi elinde tutarken ve makine kapalıyken eline ne geçer? Sorabileceğiniz diğer her soru — sağlayıcının ne görebildiği, çalışan bir sunucu ele geçirilirse ne olacağı, yedeklerinizin güvende olup olmadığı — farklı bir yanıta sahiptir ve hepsini tek bir soru gibi ele almak, insanların hiçbir şeyi korumayan bir şifrelemeyle sonuçlanmasının nedenidir.

Bu ayrımı açıkça ortaya koymakta fayda var, çünkü "LUKS ile şifrelenmiştir" ifadesi bu sektördeki her gizlilik barındırma sayfasında karşınıza çıkar — bizimkiler dahil. Bu gerçek bir kontroldür, çalıştırma maliyeti neredeyse sıfırdır ve aynı zamanda barındırmada en fazla abartılan kontroldür. Bu rehber, kiralık bir sunucuda bekleme durumundaki şifrelemenin gerçekte neyi durdurduğunu, devreye almaya değer üç düzenlemeyi ve her biri için gereken komutları, küçük bir VPS'te gerçekten önemli olan iki ayarı ve tüm bu işi süse çeviren birkaç hatayı ele alır.

Bekleme durumundaki şifreleme gerçekte neye karşı korur

Bekleme durumunda şifreleme, birim kapalı olduğu sürece depolama ortamındaki baytların şifreli metin olması anlamına gelir. Bu dar kapsamlı bir iddiadır ve değeri tek bir değişkene bağlıdır: düşman geldiği anda anahtarın nerede olduğuna.

Bunu bir hayal kırıklığı değil, bir tanım olarak okuyun. Sökülmüş disk sınıfındaki maruziyeti ortadan kaldırmak tam olarak bir saatlik çalışmaya değer, çünkü bu, başka hiçbir savunmanızın olmadığı ve kimsenin sizi hedef almadan gerçekleştiği tek sınıftır: donanım arızalanır ve iade edilir, diziler emekliye ayrılır, birimler bir sonraki kiracıya yeniden atanır. Şifreleme, bunların hepsini önemsiz bir olaya dönüştürür.

Bir VPS neden bir dizüstü bilgisayar değildir

Bir dizüstü bilgisayarda tasarım kendiliğinden anlaşılır. Açılışta bir parola yazarsınız, anahtar yalnızca makine uyanıkken RAM'de bulunur ve makineyi kapatmak hikayeyi bitirir. Bir sunucunun konsolunda kimse yoktur. Her açılışta anahtarı bir şeyin sağlaması gerekir ve bu "bir şey" için her aday, kullanılabilirliği koruma karşısında feda eder:

• Bir insan yazar. En güçlü düzenleme, çünkü anahtar hiçbir zaman makinenin üzerinde durmaz — ama sunucu siz olmadan yeniden başlatmadan dönemez ve işletim sistemi var olmadan önce içeri girecek bir yola ihtiyacınız vardır.
• Makine kendisi tutar. Kullanışlıdır ve çoğu ev yapımı kurulumda kendi kendini boşa çıkarır: aynı sanal diskteki bir anahtar dosyası, diski elinde tutan herkesin anahtarı da elinde tuttuğu anlamına gelir.
• Başka bir makine teslim eder. Ağa bağlı kilit açma, genellikle bir Tang sunucusuyla birlikte Clevis. Sunucu, yalnızca kontrolünüzdeki bir sunucuya hâlâ ulaşabildiği sürece kendi kilidini açar; bu gerçekten yararlı bir özelliktir — ve güvenin ortadan kaldırılması değil, yeniden konumlandırılmasıdır.

Çoğu rehberin atladığı ikinci bir fark daha var. Bir VPS'te /boot ve initramfs düz metindir, nihayetinde sağlayıcının kontrol ettiği bir depolama üzerinde bulunurlar ve doğrulayabileceğiniz bir önyükleme zinciri yoktur — size ait bir TPM, ölçülü önyükleme (measured boot), tasdik edilecek hiçbir şey yoktur. Parolanızı isteyen bir sağlayıcı, initramfs'i değiştirip bir sonraki kilit açışınızda onu toplayabilir. Bu, yaptığımız herhangi bir şeyin tarifi değildir; kiraladığınız bir bilgisayar hakkında akıl yürütmenin tek dürüst yolu olan, mimarinin neye izin verdiğinin bir tarifidir. VPS'e karşı özel sunucu karşılaştırmamız aynı güven sınırını donanım tarafından ele alır ve offshore anonimliği hakkındaki dürüst yanıtımız aynı disiplini bunun çevresindeki pazarlamaya uygular.

Devreye almaya değer üç düzenleme

Tek bir doğru kurulum yoktur — yaşayabileceğiniz bir arıza moduna sahip olan kurulum vardır. Bu üçü, hemen hemen her gerçek durumu kapsar.

Belirli bir nedeniniz yoksa birinciyle başlayın. Operasyonel riskin küçük bir kısmı karşılığında korumanın büyük bölümünü sağlar ve diğer ikisinde bulunmayan tek özelliğe sahiptir: hiçbir şey sunucunun yeniden çevrimiçi olmasını engelleyemez. Üçüncü düzenleme, parolanın sağlayıcının bir vaadi değil, sağlayıcının ulaşamadığı bir gerçek olduğu tek düzenlemedir; özel sunucularımızın kurulumda, bizim asla görmediğimiz bir parolayla LUKS'u devreye almasının nedeni de budur.

Çalışan bir VPS'te veri birimi şifreleme

İlk başvurulacak düzenleme budur. Hiçbir şey yeniden kurulmaz, önyükleme süreciyle ilgili hiçbir şey değişmez ve bir hata yaparsanız en kötü sonuç, atıp gidebileceğiniz bir kapsayıcı (container) dosyasıdır. Canlı bir Debian veya Ubuntu sunucusunda on beş dakika.

• Aracı kurun. apt install cryptsetup. Planınız size ikinci bir blok cihaz verdiyse, onu doğrudan kullanın ve bir sonraki adımı atlayın.
• Bir kapsayıcı oluşturun. Tek diskli bir VPS'te pratik yol bir dosyadır: fallocate -l 40G /var/lib/vault.img. Bir disk gibi davranır ve daha sonra büyütülebilir.
• LUKS2 olarak biçimlendirin. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Şifreleme algoritması için varsayılanları kullanın; aşağıdaki bölüm, küçük bir sunucuda değiştirmeye değer tek parametreyi ele alır.
• Açın ve bir dosya sistemi yerleştirin. cryptsetup open /var/lib/vault.img vault size /dev/mapper/vault'u verir; ardından mkfs.ext4 /dev/mapper/vault ve mount /dev/mapper/vault /srv/vault.
• Önemli olan veriyi taşıyın, ardından servisleri ona yönlendirin. Bir bind mount, ya da servis durdurulmuşken bir rsync, genellikle sembolik bağlantılardan (symlink) daha temizdir — özellikle veritabanları etrafta takip edilmekten hoşlanmaz.
• LUKS başlığını yedekleyin. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, ardından bu dosyayı sunucudan çıkarın. Kapsayıcının başındaki birkaç bozuk kilobayt, arkasındaki her baytı kalıcı olarak yok eder ve var olan tek sigorta budur.
• Kapatın ve geri girebildiğinizi kanıtlayın. umount /srv/vault && cryptsetup close vault, ardından hafızanızdan değil notlarınızdan tekrar açın. Bunu içeride değerli bir şey olmadan önce yapın.

Yeniden başlatmadan sonra kasa, siz oturum açıp onu açana kadar kapalı kalır. Bu, etrafından dolanılacak bir kısıtlama değildir — bütün mesele budur. Kendi kendine açılan bir birim, anahtarı makinenin üzerinde olan bir birimdir.

SSH üzerinden uzaktan kilit açmalı tam kök şifreleme

Gereksinim, kapalı haldeyken el konulmaya karşı okunabilir hiçbir şeyin hayatta kalmaması ise — günlükler, kabuk geçmişi, paket listeleri, çalıştırdığınız şeyin şekli — kök dosya sisteminin de kapsayıcının içinde olması gerekir. O zaman sorun, henüz önyüklenmemiş bir makineye bir parolayı ulaştırmak haline gelir ve yanıt, initramfs içinde yaşayan minicik bir SSH sunucusudur.

• Baştan şifreli kurun. Dağıtım kurulumcusunu özel ISO yükleme üzerinden önyükleyin ve şifreli LVM ile rehberli bölümlendirmeyi seçin. Çalışan bir kök dosya sistemini yerinde dönüştürmek mümkündür ama riske değmez.
• Önyükleme öncesi SSH sunucusunu ekleyin. apt install dropbear-initramfs, ardından ortak anahtarınızı /etc/dropbear/initramfs/authorized_keys içine koyun. Bu, normal SSH'nizden ayrı bir anahtar kümesidir — özel bir anahtar kullanın.
• Kilitleyin. /etc/dropbear/initramfs/dropbear.conf içinde DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s" ayarını yapın: parola ile giriş yok, port yönlendirme yok, kendine ait bir port ve takılıp kalmış bir oturumun önyüklemeyi açık tutamaması için bir boşta bekleme zaman aşımı.
• initramfs'e bir ağ verin. Statik bir ip= parametresini GRUB_CMDLINE_LINUX'a, /etc/default/grub içinde ekleyin — biçimi şöyledir: ip=address::gateway:netmask::interface:off. Bu aşamada DHCP'ye güvenmek, insanların kilitlenip kalmasının nedenidir.
• Yeniden oluşturun ve yeniden başlatın. update-initramfs -u && update-grub, ardından yeniden başlatın ve ssh -p 2222 root@your-server ile bağlanıp cryptroot-unlock komutunu çalıştırın. İstemciniz bilinmeyen bir ana bilgisayar anahtarı konusunda uyaracaktır: initramfs'in kendine ait bir anahtarı vardır, bu beklenen bir durumdur ve ayrı bir known_hosts girdisinde sabitlemeye değer.
• Ona güvenmeden önce arıza yolunu test edin. Bir çekirdek güncellemesi kurun, yeniden başlatın, tekrar kilidi açın. Çekirdek yükseltmeleri initramfs'i yeniden oluşturur ve bir yanlış yapılandırmanın ortaya çıktığı an tam olarak budur.

Önemli olan iki ayar ve küçük VPS tuzağı

LUKS2 varsayılan olarak 512 bit anahtarlı AES-XTS ve Argon2id anahtar türetmeyi kullanır. İkisi de doğrudur. Şifreleme algoritmasını elle ayarlamak, aynı anda hem daha yavaş hem daha zayıf olmanın bir yoludur ve internet, tam olarak bunu yapan kopyalanmış komut satırlarıyla doludur. Ancak iki şey dikkatinizi hak ediyor.

Performans, ta ki öyle olmayana kadar sorun değildir

grep -m1 -o aes /proc/cpuinfo ile donanım hızlandırmasını kontrol edin ve cryptsetup benchmark ile ölçün. AES-NI'ye sahip herhangi bir CPU'da — ki çalıştırdığımız her düğüm böyledir — AES-XTS çekirdek başına saniyede birkaç gigabayt işler; bu, tek bir sanal diskin sağladığından rahatlıkla daha fazladır, dolayısıyla görünür maliyet, yoğun G/Ç altında CPU'nun birkaç yüzdesi ve küçük bir gecikme artışıdır. AES-NI olmadan tablo tersine döner ve şifreleme darboğaz haline gelir; alternatif bir şifrenin kargo kültü değil gerçek bir karar olduğu tek durum budur.

Argon2id belleği ısıran şeydir

Argon2id kasıtlı olarak bellek açlığı çeker ve cryptsetup biçimlendirme sırasında bunu, biçimlendirme yaptığınız makinenin RAM'ine göre kalibre eder. Bir birimi 32 GB'lık bir iş istasyonunda biçimlendirip 1 GB'lık bir VPS'e taşırsanız, anahtar türetmenin talep ettiği bellek orada olmadığı için kilit açma tamamen başarısız olabilir — bir initramfs içinde daha da kötüsü, çünkü çalışan bir sistemdekinden çok daha azı kullanılabilir. Küçük örneklerde bunu sabitleyin: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb bunu 256 MB'a sınırlar. Daha düşük bir değer, çevrimdışı kaba kuvvete karşı direnişte gerçek bir azalmadır, bu yüzden daha uzun bir parolayla telafi edin.

İsteğe bağlı bir bayrak, kopyala-yapıştır yerine bilinçli bir karar hak ediyor: --allow-discards, TRIM'i altta yatan cihaza geçirir; bu, SSD aşınması ve kararlı durum performansı için iyidir ve aynı zamanda birimin ne kadarının kullanımda olduğunu ve kabaca nerede olduğunu da ortaya çıkarır. Varsayılan olarak kapalıdır. Neyi ele verdiğini bilerek açın.

Swap, günlükler, anlık görüntüler — insanların unuttuğu kısımlar

Etrafına düz metin sızdıran şifreli bir kasa, hepsinin en yaygın arızasıdır ve biri bakana kadar görünmez kalır.

• Swap. Kasaya özenle koyduğunuz malzeme dahil, bellekteki her şey diske sayfalanabilir. Ya swap'ı devre dışı bırakın ya da /etc/crypttab içinde swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256 gibi bir satırla her açılışta ona rastgele bir anahtar verin.
• Bakmadığınız yere yazan her şey. /var/log, /tmp, veritabanı veri dizini, /var/lib/docker, kabuk geçmişi, systemd günlükleri. /srv/vault'u şifrelemek, PostgreSQL /var/lib/postgresql'e yazarken tam olarak hiçbir şey başarmaz. Şifrelemeden önce sayın.
• Anlık görüntüler. Şifreli bir birimin blok düzeyinde anlık görüntüsü şifreli metindir ve bu nedenle sorun değildir. Bellek durumunu yakalayan bir anlık görüntü tamamen farklı bir nesnedir ve anahtarı içerebilir. Sağlayıcınızın panelinin hangi türü aldığını kullanmadan önce öğrenin.
• Yedekler. Bunu çözmek için hedef yanlış yerdir. restic ve BorgBackup gibi araçlar kaynakta, hedefin hiçbir zaman görmediği bir anahtarla şifreler; bir yedekleme sunucusunun güvenilir bir makine yerine başka bir yargı bölgesindeki sıradan bir makine olabilmesinin nedeni de budur.
• Zaten bir yere gönderdiğiniz düz metin. Bekleme durumundaki şifreleme geriye dönük değildir. Başka bir yere zaten kopyalanmış, e-postayla gönderilmiş ya da senkronize edilmiş her şey, şimdi çizdiğiniz sınırın dışında kalır.

Anahtarın nerede yaşadığı, tasarımın tamamıdır

Yukarıdaki her düzenleme aslında anahtar gözetimi hakkında bir beyandır. Dört seçenek vardır ve eşdeğer değildirler:

• Kafanızda, her açılışta yazılır. Azami koruma, azami operasyonel sürtünme. Makine siz olmadan gerçekten okunamaz.
• Şifreli makinedeki bir dosyada. Sadece saf bir disk yeniden satışına karşı korur, başka hiçbir şeye karşı korumaz. O dosya düz metin /boot üzerinde duruyorsa, hiçbir şeye karşı korumaz — kendi kendine barındırılan şifrelemedeki en yaygın tek hata budur.
• Kontrolünüzdeki bir makinede, ağ üzerinden alınır. Bir Tang sunucusuna bağlı Clevis: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. Sunucu, eve ulaşabildiği sürece gözetimsiz açılır ve başka hiçbir yerde kilidini açmayı reddeder. Başsız (headless) filolar için mükemmeldir ve savunulması gereken şeyi Tang sunucusu haline getirir.
• Bir TPM'de. Sahip olduğunuz donanımda anlamlıdır. Bir VPS'te sanal TPM, dışlamaya çalıştığınız hipervizör tarafından sağlanır, dolayısıyla güveni değil kullanışlılığı çözer.

Tek bir test çoğu tasarımı çözer: makine siz olmadan bir oturum açma istemine ulaşabiliyorsa, anahtar makinenin üzerindedir. Bu tamamen makul bir takas olabilir — birçok iş yükü, kararlı bir düşmana direnç göstermektense gözetimsiz yeniden başlatmayı ister. Seçimi bilinçli olarak yapın ve sonucu olmadığı bir şeymiş gibi tanımlamayın.

Sağlayıcınız neyi görebilir ve yargı yetkisi nerede devreye girer

Bir VPS'te altınızda bir hipervizör bulunur. Misafir belleği okumayız ve hiçbir trafik, bağlantı ya da DNS günlüğü ve hiçbir konsol izi tutmayız — ama bunlar birer politikadır ve dürüst çerçeveleme, bir VPS'in sizden bunlara güvenmenizi istediğidir. Bare metal'de sizinle silikon arasında hipervizör yoktur: kurulumda ayarlanan ve bizim asla almadığımız bir parolayla yapılan tam disk şifrelemesi, bizden gelen bir güvenceden ziyade makinenin fiziksel bir özelliğidir. Gerçekten seçtiğiniz şey, şifreleme algoritmasının seçimi değil, bu farktır.

Bu yüzden şifreleme ve yargı yetkisi, tek bir yanıtın iki yarısıdır. Şifreleme, diskinizin bir kopyasının ne değerde olduğuna karar verir; yargı yetkisi ise makinenin hangi süreçle ve ne kadar hızlı üretilmeye zorlanabileceğine kimin karar verebileceğini belirler. Yedi yargı bölgesinde faaliyet gösteriyoruz — İzlanda, İsviçre, Panama, Romanya, Moldova, Hollanda ve Rusya — ve aralarında seçim yapmanın gerekçesi yargı bölgesi rehberimizde, ya da daha kısa bir biçimde yargı bölgesi seçicide ve konumlar sayfasında bulunur.

Şifrelemenin dokunamadığı kısım, donanıma değil size yönelik olduğu için zorunlu ifşadır. Birleşik Krallık, Fransa ve Avustralya, hukuku bir kişiyi bir şifre çözme anahtarını ibraz etmeye zorlayabilen ya da reddetmesi halinde ceza uygulayabilen ülkeler arasındadır. Bu maruziyet, sunucunun değil sizin bulunduğunuz yeri takip eder ve kutu üzerindeki hiçbir yapılandırma bunu değiştirmez. Kimlik belgesi olmadan kayıt olmak, en başta ne kadar kağıt izi bulunduğunu sınırlar — KYC'siz barındırmanın ve şifrelemenin aynı konuşmada buluşmasının pratik ve gösterişsiz nedeni budur — ama bu, adınızı zaten bilen bir mahkemeye karşı bir savunma değildir.

Şifrelemeyi süse çeviren dokuz hata

• Aynı diskteki bir anahtar dosyasından otomatik kilit açma. "Şifreli" sunucuların çoğunluğu ve anahtarı kilidin üzerinde bırakmanın karşılığı.
• Hassas verinin hiç ulaşmadığı bir birimi şifrelemek. Kasa boştur ve veritabanı içinde değildir.
• LUKS başlığını hiç yedeklememek. Kapsayıcının önündeki bir hasarlı sektör ve arkasındaki her bayt sonsuza dek gider.
• Kilit açma yolunu hiç test etmemek. Sonra bir çekirdek yükseltmesi initramfs'i yeniden oluşturur ve bir sonraki yeniden başlatma bir kurtarma operasyonuna dönüşür.
• Büyük bir makinede biçimlendirip küçük birinde kilit açmak. Argon2id, VPS'in sağlayamayacağı bir bellek ister ve birim açılmaz.
• Bir parolayı bir giriş şifresi gibi seçmek. Anahtar türetme işlevi dışında hiçbir şey çevrimdışı bir saldırıyı hız sınırlamaz. Zaman kazandıran şey uzunluktur.
• Düz metni şifrelemeye taşıyıp orijinalin gittiğini varsaymak. Sanallaştırılmış depolamada, üzerine yazmak güvenilir biçimde silmez.
• Parolayı, kutuyu yönetmek için kullanılan aynı kanaldan göndermek. Sunucu OpSec rehberimiz bunun yarattığı korelasyon sorununu ele alır.
• Sağlayıcınızın şifrelemesini kendi şifrelemenizle karıştırmak. "Tüm altyapı bekleme durumunda şifrelidir" — bizimki dahil — altyapıyı korur. Sizi altyapıdan yalnızca elinizde tuttuğunuz bir anahtar korur.

Peki bir VPS'te yapmaya değer mi?

Evet, beklentileri ayarlayarak. Bir saatlik çalışma ve ölçülebilir bir çalıştırma maliyeti olmadan, şifreli bir veri birimi, başka türlü ele alamayacağınız bütün bir maruziyet sınıfını kaldırır ve bunu kalıcı olarak yapar: emekliye ayrılmış donanım, yeniden atanmış depolama, başkasının gözetimindeki kapalı bir makine. İlk saat sıkılaştırma kontrol listesinin hemen ardından, önemli bir şey barındıran her sunucuda bunu yapın.

Yapmadığı şey ise kiralık bir bilgisayarı sizin bilgisayarınıza dönüştürmektir. Tehdit modelinizde sağlayıcının kendisi düşman olarak yer alıyorsa, hiçbir şifreleme algoritması bunu düzeltmez — çözüm, anahtarın IPMI üzerinden yazıldığı ve hiçbir zaman bir hipervizörden geçmediği özel donanımdır, kasıtlı olarak seçilmiş bir yargı bölgesi ve orada bulunması gerekmeyen hiçbir şeyi hiçbir sunucuya koymama disiplinidir. Kontrolü gerçek tehditle eşleştirmek, gizlilik ile gizliliğin görüntüsü arasındaki farktır.