VPN prisijungia, klientas atidaro sesiją, ir visi mano, kad duomenų bazės ryšys apsaugotas. Ką tik buvo sumaišyti trys skirtingi dalykai. Ar klausytuvas apskritai pasiekiamas, ar serveris priėmė vartotoją ir ar Firebird susitarė dėl laidų šifravimo yra atskiri mechanizmai su atskirais įrodymais. Tunelis atsako tik į pirmąjį, ir tik tiems šaltiniams, kuriuos leidote.

Dvi ribos, ir jos nesikerta

VPN riba saugo paketus tarp kliento ir tinklų sietuvo. Firebird laidų šifravimas saugo duomenų bazės protokolą tarp kliento bibliotekos ir serverio proceso. Abu gali egzistuoti, ir nė vienas nepakeičia kito.

Jei tunelis baigiasi prieš duomenų bazės mazgą, už jo esantis srautas saugomas tik tuo, dėl ko susitarė duomenų bazės sesija. Būtent šioje spragoje apžvalga paprastai randa netikėtumą. Tunelio schema baigiasi prie tinklų sietuvo, o užklausą nešantis ryšys tęsiasi toliau. Kiekvienas, kuris tą schemą perskaitys vėliau, paveldi šią prielaidą.

Pirmoji riba: kas gali atidaryti klausytuvą

Nustatykite tikrąjį serverio adresą ir sukonfigūruotą prievadą, kuris yra 3050, jei nebuvo pakeistas, tada mazgo ir tinklo užkardose leiskite tik patvirtintus VPN šaltinius. Atsižvelkite į bet kokį adresų vertimą VPN sietuve ir, jei sietuvas atskiras, suteikite duomenų bazės mazgui grįžimo maršrutą į klientų telkinį.

Tada įrodykite neigiamą atvejį. Išorinis kelias, kuris turėtų būti atmestas, turi likti atmestas, nes tunelio atidarymas savaime neriboja Firebird klausytuvo.

Antroji riba: dėl ko susitaria Firebird

Firebird 3 pristatė laidų šifravimo sistemą su serverio politika, kuri gali būti išjungta, įjungta arba privaloma. Politika nustato apatinę ribą. Faktinė sesija vis dar priklauso nuo kliento bibliotekos, kurią įkelia programa, ir papildinių, kuriuos palaiko abi pusės.

Firebird 3 leidimo pastabose Arc4 nurodytas kaip numatytasis tos versijos laidų šifravimo papildinys. Arc4 yra istorinis numatytasis variantas, o ne šiuolaikinio šifro rekomendacija, ir tai nėra tas pats, kas išorinė VPN apsauga.

Autentifikavimas yra trečiasis kintamasis tose pačiose derybose. Serveris priima autentifikavimo papildinių rinkinį, kliento biblioteka siūlo jo poaibį, ir abu turi sutapti.

Legacy_Auth spąstai

Norint palaikyti Legacy_Auth, reikia sušvelninti numatytąją serverio privalomojo šifravimo politiką. Tai dokumentuota suderinamumo kaina, ir todėl politikos sumažinimas, norint nutildyti ryšio klaidą, yra saugumo pakeitimas, o ne taisymas.

Jei klientas po serverio naujinimo staiga ima nepavykti, palyginkite papildinių sąrašus prieš ką nors silpnindami. Nepavykimas paprastai yra derybų neatitikimas, o atsakymas yra abiejose pusėse palaikomas papildinys.

Patikrinkite svarbų ryšį

Kuriant su konteksto kintamuoju, ši užklausa praneša dabartinio ryšio šifravimo būseną:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

Vykdykite ją per pačios programos ryšį, o ne per administratoriaus sesiją tame pačiame serveryje. Užšifruotas administratoriaus ryšys nieko nesako apie kitos kliento bibliotekos sesiją, o senesnis kūrinys, nepalaikantis kintamojo, nėra įrodymas, kad šifravimas išjungtas.

Užrašykite kartu kliento bibliotekos versiją, serverio kūrinį ir rezultatą, nes nė vienas jų atskirai neperskaitomas.

Teisės ir naujinimo kelias

Šaltinių ribojimas ir transporto šifravimas nepakeičia autentifikavimo ar mažiausių privilegijų teisių. Patikrinkite įprasto duomenų bazės vartotojo teises objektams, kuriuos jis iš tikrųjų liečia.

Galiausiai ilgalaikį diegimą traktuokite kaip priežiūros klausimą. Tunelis nepadaro pasenusios kliento bibliotekos saugios neribotam laikui, o palaikomas naujinimo kelias pigesnis nei sužinoti, kad reikalingas papildinys buvo pašalintas.

Susiję straipsniai