La VPN konektiĝas, la kliento malfermas sesion, kaj ĉiuj supozas, ke la datumbaza konekto estas sekurigita. Ĝuste nun tri malsamaj aferoj estis konfuzitaj. Ĉu la aŭskultanto entute estas atingebla, ĉu la servilo akceptis la uzanton kaj ĉu Firebird interkonsentis dratan ĉifradon estas apartaj mekanismoj kun apartaj pruvoj. Tunelo respondas nur la unuan, kaj nur por la fontoj, kiujn vi permesis.

Du limoj, kiuj ne interkovras

La VPN-limo protektas pakaĵojn inter kliento kaj pordego. La drata ĉifrado de Firebird protektas la datumbazan protokolon inter la klienta biblioteko kaj la servila procezo. Ambaŭ povas ĉeesti, kaj neniu anstataŭas la alian.

Se la tunelo finiĝas antaŭ la datumbaza gastiganto, la trafiko preter ĝi protektiĝas nur per tio, kion interkonsentis la datumbaza sesio. Ĝuste en tiu breĉo revizio kutime trovas la surprizon. La tunela diagramo finiĝas ĉe pordego, kaj la konekto portanta vian pridemandeton daŭras preter ĝi. Ĉiu, kiu poste legas tiun diagramon, heredas la supozon.

Limo unu: kiu povas malfermi la aŭskultanton

Identigu la veran servilan adreson kaj la agorditan pordon, kiu estas 3050 se ĝi ne estis ŝanĝita, poste permesu nur la aprobitajn VPN-fontojn ĉe la fajroŝirmiloj de la gastiganto kaj de la reto. Konsideru ajnan adresan tradukon ĉe la VPN-pordego, kaj donu al la datumbaza gastiganto revenan itineron al la klienta baseno se la pordego estas aparta.

Poste pruvu la negativon. Ekstera vojo, kiu devus esti rifuzata, devas resti rifuzata, ĉar malfermi la tunelon mem ne limigas la aŭskultanton de Firebird.

Limo du: kion Firebird interkonsentas

Firebird 3 enkondukis kadron por drata ĉifrado kun servila politiko, kiu povas esti malŝaltita, ŝaltita aŭ deviga. La politiko starigas la minimumon. La fakta sesio ankoraŭ dependas de la klienta biblioteko ŝarĝita de la aplikaĵo kaj de la kromaĵoj, kiujn ambaŭ flankoj subtenas.

En la eldonaj notoj de Firebird 3 Arc4 estas listigita kiel la defaŭlta kromaĵo por drata ĉifrado de tiu eldono. Arc4 estas historia defaŭlto, ne rekomendo por moderna ĉifro, kaj ĝi ne estas la sama afero kiel la ekstera VPN-protekto.

Aŭtentikigo estas tria variablo en la sama intertraktado. La servilo akceptas aron da aŭtentikigaj kromaĵoj, la klienta biblioteko proponas iun subaron, kaj la du devas interkovri.

La kaptilo Legacy_Auth

Subteni Legacy_Auth postulas malstreĉi la defaŭltan devigan ĉifradan politikon de la servilo. Tio estas la dokumentita kosto de kongruo, kaj tial malaltigi la politikon por silentigi konektan eraron estas sekureca ŝanĝo, ne riparo.

Se kliento subite fiaskas post servila ĝisdatigo, komparu la listojn de kromaĵoj antaŭ ol malfortigi ion ajn. La fiasko kutime estas malkongruo en la intertraktado, kaj la respondo estas subtenata kromaĵo ĉe ambaŭ flankoj.

Kontrolu la konekton, kiu gravas

En versio, kiu provizas la kuntekstan variablon, ĉi tiu pridemando raportas la ĉifradan staton de la nuna konekto:

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

Rulu ĝin tra la propra konekto de la aplikaĵo, ne tra administranta sesio sur la sama servilo. Ĉifrita administra konekto diras nenion pri la sesio de alia klienta biblioteko, kaj pli malnova versio, kiu ne subtenas la variablon, ne estas pruvo, ke la ĉifrado estas malŝaltita.

Notu kune la version de la klienta biblioteko, la version de la servilo kaj la rezulton, ĉar neniu el ili sola estas legebla.

Rajtoj kaj la ĝisdatiga vojo

Limigi la fontojn kaj ĉifri la transporton ne anstataŭas aŭtentikigon nek rajtojn de minimuma privilegio. Kontrolu la permesojn de la ordinara datumbaza uzanto sur la objektoj, kiujn ĝi vere tuŝas.

Fine, traktu longdaŭran deplojon kiel prizorgan demandon. Tunelo ne igas malaktualan klientan bibliotekon sekura senfine, kaj subtenata ĝisdatiga vojo estas pli malmultekosta ol malkovri, ke la kromaĵo, kiun ĝi bezonas, estis forigita.

Rilataj artikoloj