Proxmox Hardening – Deo 3: Enkripcija skladišta i Proxmox Backup Server

Prethodna dva dela serije pokrila su host bezbednost i mrežnu segmentaciju. Ovaj, poslednji deo serije bavi se onim što na kraju najviše određuje ishod ozbiljnog incidenta — zaštitom podataka na disku i backup infrastrukturom, sa fokusom na Proxmox Backup Server (PBS), namensko, integrisano rešenje za backup cele Proxmox infrastrukture. Isti princip koji smo naglasili kroz MSSQL, Hyper-V i VMware serije na ovom blogu važi i ovde, sa dodatnom težinom: backup server u virtuelizovanom okruženju čuva istoriju svega što hipervizor pokreće, što ga čini metom prvog reda za svaki ozbiljniji, ciljani napad.

Zašto je backup server meta pre same produkcije

Vredi ponoviti princip iz ranijih serija, jer je ovde posebno konkretan: profesionalne ransomware grupe rutinski prioritizuju napad na backup infrastrukturu pre nego što aktiviraju enkripciju na produkcionim sistemima, upravo zato što znaju da je backup jedini realan put oporavka žrtve bez plaćanja otkupnine. Ako backup server deli mrežu, kredencijale ili fizičku infrastrukturu sa onim što štiti, napadač koji kompromituje jedno automatski dobija i drugo, i cela svrha postojanja backup-a nestaje u istom trenutku kad i produkcija.

PBS mrežna izloženost — jedan port, ozbiljna pažnja

Proxmox Backup Server koristi jedan jedini port (8007, HTTPS) i za web interfejs i za sam backup API. Podrazumevana instalacija ovaj port izlaže na svim mrežnim interfejsima, sa samopotpisanim (self-signed) TLS sertifikatom i bez ugrađenog ograničenja brzine pokušaja prijave — isti obrazac "funkcionalno, ali ne i hardenovano po difoltu" koji smo opisali za sam Proxmox VE u prvom delu serije.

Šta treba uraditi

• Ograničiti pristup portu 8007 isključivo na poznate izvore — sam Proxmox VE host/klaster koji šalje backup podatke, i uzak krug administratora koji upravljaju PBS-om — kroz firewall pravila, po istom "default deny, eksplicitno dozvoli" principu koji se provlači kroz svaku seriju na ovom blogu
• Uvesti fail2ban ili sličan mehanizam za ograničavanje pokušaja prijave, budući da PBS nema ugrađeno rate limiting za autentifikaciju — isti princip opisan za SSH u seriji o hardeningu Linux servera, ovde primenjen na PBS web/API pristup
• Zameniti podrazumevani, samopotpisani TLS sertifikat validnim sertifikatom (interne CA ili javno poverljive, u zavisnosti od okruženja), posebno ako PBS interfejs ikad pristupaju alati koji striktno proveravaju validnost sertifikata
• Koristiti API tokene za automatizovan pristup (backup zadaci, integracije) umesto deljenja punih korisničkih kredencijala — API tokeni se mogu obimom (scope) ograničiti na tačno određen datastore i ulogu, i nezavisno opozvati bez uticaja na ostatak sistema

Least privilege za backup naloge — Backup rola, ne Admin

Ovo je princip koji se ponavlja kroz svaku seriju o backup-u na ovom blogu, ovde sa konkretnom, PBS-specifičnom primenom. Nalog ili API token koji Proxmox VE host koristi da šalje backup podatke ka PBS-u treba da ima isključivo Backup ulogu (mogućnost pisanja novih backup podataka), ne Admin ili Prune ulogu. Razlog je direktan: ako je taj nalog kompromitovan (npr. preko kompromitovanog PVE hosta koji šalje backup), napadač sa punim administratorskim pravima na PBS-u može obrisati postojeće backup indekse ili pokrenuti agresivno čišćenje (prune) starih verzija — što posle sledećeg ciklusa garbage collection-a znači trajan, nepovratan gubitak istorijskih backup-a. Nalog ograničen isključivo na Backup ulogu ne može ovo da uradi, čak i ako je u potpunosti kompromitovan.

Šta treba uraditi

• Kreirati poseban PBS nalog ili API token za svaki Proxmox VE host/klaster koji šalje backup podatke, sa dozvolom ograničenom isključivo na Backup ulogu nad tačno određenim datastore-om
• Nikad ne koristiti Admin nalog za rutinske, automatizovane backup zadatke — Admin pristup rezervisati za ljude koji ručno upravljaju PBS konfiguracijom, ne za sistemske procese
• Redovno (bar kvartalno) proveravati ACL listu na PBS-u — po difoltu, PBS ACL sistem je "default deny", ali vremenom se dozvole akumuliraju i zaslužuju istu periodičnu reviziju opisanu kroz svaku prethodnu seriju na ovom blogu
• Za operatore koji zaista trebaju šire pravo brisanja ili prune operacija, dodeliti to pravo usko, imenovanim nalozima sa punom autentifikacijom (uključujući 2FA opisan u prvom delu serije), ne generičkim, deljenim servisnim nalozima

Klijentska enkripcija — PBS koji nikad ne vidi vaše podatke

Ovo je tehnički najvažniji, i vredan detaljnog objašnjenja mehanizam u celoj PBS ponudi. Za razliku od enkripcije "na odredištu" (gde server prima podatke u čitljivom obliku i sam ih enkriptuje pre upisa na disk), PBS podržava klijentsku enkripciju — podaci se enkriptuju direktno na Proxmox VE hostu, na nivou pojedinačnih delova podataka (chunk-ova), koristeći AES-256-GCM algoritam, pre nego što ijedan bajt uopšte napusti taj host preko mreže. PBS server prima i skladišti isključivo šifrovan sadržaj (ciphertext) — nema tehničku mogućnost da ga dekriptuje, čak ni sa punim administratorskim pristupom samom PBS sistemu.

Praktična posledica ovog dizajna je značajna: ako je sam PBS server kompromitovan — bilo kroz ranjivost, kroz kompromitovan administratorski nalog, ili kroz fizičku krađu skladišta — napadač dobija gomilu enkriptovanih chunk-ova bez ikakve praktične mogućnosti da izvuče iz njih stvaran sadržaj, sve dok ne poseduje i sam ključ za enkripciju, koji se čuva odvojeno, na Proxmox VE strani, ne na PBS-u.

Šta treba uraditi

• Uključiti klijentsku enkripciju za sve backup zadatke koji sadrže osetljive podatke — ovo pomera tačku poverenja sa "verujemo da je PBS server bezbedan" na "čak i ako PBS server bude kompromitovan, podaci ostaju zaštićeni"
• Razumeti gde se ključ fizički čuva — na Proxmox VE strani, u putanji /etc/pve/priv/storage/, i nikad na samom PBS serveru — što znači da backup PBS servera samog ne uključuje automatski i ključeve potrebne za dekriptovanje tih backup-a
• Napraviti bezbednu, odvojenu kopiju enkripcionog ključa odmah po njegovom kreiranju, i čuvati je potpuno nezavisno od i PVE i PBS infrastrukture — isti princip odvojenog čuvanja ključa opisan za TDE sertifikat u MSSQL seriji i za etcd enkripcioni ključ u Kubernetes seriji
• Za organizacije sa više administratora, razmotriti master key mehanizam koji PBS nudi za enterprise key escrow — ovo omogućava kontrolisan, dokumentovan pristup ključu za ovlašćeno osoblje, umesto da ključ zavisi od jedne osobe ili jedne, nedokumentovane lokacije

Napomena o riziku, i ovo zaslužuje najveći mogući naglasak u celom ovom tekstu: gubitak enkripcionog ključa znači trajan, nepovratan gubitak mogućnosti dekriptovanja svih backup-a zaštićenih tim ključem — PBS dokumentacija je eksplicitna da za ovo ne postoji mehanizam oporavka. Ovo nije scenario "kontaktirajte podršku i vratiće vam pristup" — izgubljen ključ znači da backup podaci postoje na disku, ali su trajno, kriptografski nedostupni, čak i legitimnom vlasniku. Testirati proceduru čuvanja i preuzimanja ključa pre nego što se klijentska enkripcija stvarno osloni kao produkciona mera, i tretirati zaštitu tog ključa sa istim, ako ne i većim, nivoom pažnje kao i sam backup koji štiti.

Nepromenljivost (immutability) — zaštita od brisanja, ne samo od čitanja

Enkripcija štiti poverljivost — sprečava neovlašćeno čitanje. Ne štiti, sama po sebi, od brisanja ili uništavanja postojećih backup-a od strane nekoga ko ima pristup za pisanje/brisanje na PBS-u (uključujući, u najgorem slučaju, samog napadača sa ukradenim administratorskim kredencijalima). Za ovo je potreban odvojen mehanizam — nepromenljivost.

PBS-ova osnovna arhitektura već pruža deo ove zaštite besplatno, kao posledicu dizajna, ne kao posebno uključenu funkciju: backup operacije na nivou pojedinačnih delova podataka (chunk-ova) su append-only — nova verzija backup-a dodaje nove chunk-ove i kreira nov manifest, nikad ne menja postojeće chunk-ove. Jedina operacija koja stvarno uklanja stare chunk-ove je prune (čišćenje starih verzija) praćeno garbage collection ciklusom — što znači da je kontrola nad tim ko sme da pokrene prune operaciju (opisana ranije u tekstu kroz Backup vs. Admin/Prune ulogu) sama po sebi značajna zaštita.

Šta treba uraditi

• Koristiti protected snapshots funkciju (dostupnu u novijim PBS verzijama) za označavanje pojedinačnih backup verzija kao nepromenljivih do određenog datuma — jednom postavljena zaštita ne može biti uklonjena standardnim API nalogom, samo administratorskim pristupom kroz pveum, što znači da čak i kompromitovan backup nalog (ograničen na Backup ulogu, opisano ranije) ne može ukloniti tu zaštitu
• Za najviši nivo garancije, razmotriti bar jednu kopiju na fizički nepromenljivom mediju — LTO traka koja fizički nije montirana van perioda sinhronizacije, ili immutable object storage (S3 Object Lock) sa uključenim verzionisanjem — ransomware ne može prepisati medij koji nije aktivno montiran ili koji tehnički odbija izmene
• Sprovoditi 3-2-1(-1-0) princip u celini — najmanje tri kopije podataka, na dva različita tipa medija, sa jednom kopijom van glavne lokacije, idealno uz jednu nepromenljivu ili offline kopiju, i sa "0" kao ciljem broja grešaka u redovnim verify zadacima
• Pokretati redovne verify zadatke koji ponovo izračunavaju heš vrednosti chunk-ova i upoređuju ih sa manifestom — ovo otkriva tihu korupciju podataka pre nego što restauracija postane hitno potrebna, isti princip proaktivne provere integriteta opisan kroz svaku seriju o backup-u na ovom blogu
• Sprovoditi kvartalne, stvarne restauracije nasumično izabranog VM-a kao proveru da ceo lanac (backup, enkripcija, ključ, restauracija) zaista radi od početka do kraja, ne samo da pojedinačni koraci deluju ispravno izolovano

Enkripcija na nivou skladišta — dodatan, komplementaran sloj

Nezavisno od PBS klijentske enkripcije, sam disk skladišta na PVE ili PBS strani može biti dodatno zaštićen enkripcijom na nivou fajl sistema — LUKS2 za standardne blok uređaje, ili nativna ZFS enkripcija na nivou dataset-a za okruženja koja koriste ZFS (čest izbor u Proxmox svetu zbog ugrađenih checksuma i snapshot mogućnosti). Ovo štiti od scenarija fizičke krađe diska ili neovlašćenog pristupa storage infrastrukturi, nezavisno od toga da li je klijentska enkripcija na PBS nivou uključena.

Šta treba uraditi

• Za ZFS skladišta, uključiti nativnu enkripciju na nivou dataset-a za osetljiva radna opterećenja, što omogućava pojedinačne ključeve po dataset-u i fleksibilnije procedure otključavanja u odnosu na enkripciju celog diska
• Za standardne konfiguracije, razmotriti LUKS2 enkripciju blok uređaja postavljenu pre same instalacije Proxmox-a — kao i kod UEFI Secure Boot-a opisanog za ESXi u VMware seriji, ovo je odluka koju je znatno lakše doneti unapred nego naknadno primeniti na već aktivnu instalaciju
• Čuvati recovery ključeve za LUKS2 ili ZFS enkripciju odvojeno od same infrastrukture, u offline password manageru ili hardverskom sigurnosnom modulu (HSM), po istom principu odvojenog čuvanja ključeva koji se ponavlja kroz ceo ovaj deo teksta

Ovim se zaokružuje serija o hardeningu Proxmox infrastrukture — host bezbednost, mrežna segmentacija, i zaštita podataka kroz enkripciju i disciplinovan, testiran backup. Isti obrazac koji povezuje ovu seriju sa Hyper-V i VMware serijama ranije na ovom blogu ostaje nepromenjen: bezbednost hipervizora i backup infrastrukture koja ga štiti postavlja gornju granicu za sve što se gradi iznad njih, bez obzira na to koliko je pažljivo hardenovan sadržaj pojedinačnih VM-ova.