Firebird 3:n lankasalaus ja VPN ovat kaksi eri rajaa

VPN yhdistyy, asiakas avaa istunnon ja kaikki olettavat, että tietokantayhteys on suojattu. Juuri sekoitettiin kolme eri asiaa. Onko listener ylipäätään tavoitettavissa, hyväksyikö palvelin käyttäjän ja neuvotteliko Firebird lankasalauksesta, ovat erillisiä mekanismeja erillisine todisteineen. Tunneli vastaa vain ensimmäiseen, ja vain niille lähteille, jotka sallit.

Kaksi rajaa, eivätkä ne mene päällekkäin

VPN:n raja suojaa paketteja asiakkaan ja yhdyskäytävän välillä. Firebirdin lankasalaus suojaa tietokantaprotokollan asiakaskirjaston ja palvelinprosessin välillä. Molemmat voivat olla olemassa, eikä kumpikaan korvaa toista.

Jos tunneli päättyy ennen tietokanta-isäntää, sen takana oleva liikenne on suojattu vain sillä, mistä tietokantaistunto neuvotteli. Juuri siinä aukossa katselmus yleensä löytää yllätyksen. Tunnelikaavio päättyy yhdyskäytävään, ja kyselyäsi kantava yhteys jatkuu sen ohi. Jokainen, joka lukee kaaviota myöhemmin, perii oletuksen.

Raja yksi: kuka saa avata listenerin

Tunnista palvelimen todellinen osoite ja määritetty portti, joka on 3050 ellei sitä ole muutettu, ja salli sitten vain hyväksytyt VPN-lähteet isännän ja verkon palomuurissa. Ota huomioon mahdollinen osoitteenkäännös VPN-yhdyskäytävässä ja anna tietokanta-isännälle paluureitti asiakasaltaaseen, jos yhdyskäytävä on erillinen.

Todista sitten kielteinen. Ulkoinen polku, joka pitäisi hylätä, on edelleen hylättävä, koska tunnelin avaaminen ei itsessään rajoita Firebirdin listeneria.

Raja kaksi: mitä Firebird neuvottelee

Firebird 3 toi lankasalauksen kehyksen, jossa palvelinkäytäntö voi olla poistettu käytöstä, käytössä tai pakollinen. Käytäntö asettaa vähimmäistason. Varsinainen istunto riippuu edelleen sovelluksen lataamasta asiakaskirjastosta ja lisäosista, joita molemmat osapuolet tukevat.

Firebird 3:n julkaisutiedoissa Arc4 mainitaan kyseisen julkaisun oletusarvoisena lankasalauksen lisäosana. Arc4 on historiallinen oletusarvo, ei nykyaikaisen salauksen suositus, eikä se ole sama asia kuin ulkoinen VPN-suoja.

Todennus on kolmas muuttuja samassa neuvottelussa. Palvelin hyväksyy joukon todennuksen lisäosia, asiakaskirjasto tarjoaa niistä osajoukon, ja näiden kahden on leikattava.

Legacy_Auth-ansa

Legacy_Authin tukeminen vaatii palvelimen oletusarvoisen pakollisen salauskäytännön löyhentämistä. Se on dokumentoitu yhteensopivuuskustannus, ja siksi käytännön laskeminen yhteysvirheen vaientamiseksi on turvallisuusmuutos eikä korjaus.

Jos asiakas alkaa yhtäkkiä epäonnistua palvelimen päivityksen jälkeen, vertaa lisäosaluetteloita ennen kuin heikennät mitään. Epäonnistuminen on yleensä neuvotteluristiriita, ja vastaus on molemmilla puolilla tuettu lisäosa.

Tarkista yhteys, jolla on merkitystä

Buildissa, joka tarjoaa kontekstimuuttujan, tämä kysely raportoi nykyisen yhteyden salauksen tilan:

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

Aja se sovelluksen omalla yhteydellä, älä saman palvelimen ylläpitäjän istunnolla. Salattu ylläpitäjän yhteys ei kerro mitään toisen asiakaskirjaston istunnosta, eikä vanhempi build, joka ei tue muuttujaa, ole todiste siitä, että salaus on pois päältä.

Kirjaa asiakaskirjaston versio, palvelimen build ja tulos yhteen, sillä mikään niistä yksinään ei ole luettavissa.

Oikeudet ja päivityspolku

Lähteiden rajaaminen ja liikenteen salaaminen eivät korvaa todennusta tai vähimmän oikeuden käyttöoikeuksia. Tarkista tavallisen tietokantakäyttäjän oikeudet objekteihin, joihin se todella koskee.

Lopuksi kohtele pitkäikäistä käyttöönottoa ylläpitokysymyksenä. Tunneli ei tee vanhentuneesta asiakaskirjastosta loputtomasti turvallista, ja tuettu päivityspolku on halvempi kuin se, että löytää tarvitsemansa lisäosan poistetun.