MySQL tra VPN: kontrolu la servilon, ne nur la ĉifradon
Ĉifri al la malĝusta gastiganto restas malĝuste. Komparu la valorojn de ssl-mode, poste rulu konekton, kiu nomas la intencitan servilon kaj pruvas tion.
Vi konservas konekton al 10.20.4.15, la VPN falas, kaj la kliento ankoraŭ konektiĝas. Tio ne estas bona novaĵo. Privata adreso estas loko ene de kiu ajn enkursigada kunteksto vi troviĝas, kaj multaj retoj uzas la samajn gamojn. La kliento atingis MySQL-servilon, nur eble ne vian.
La korekto havas du duonojn, kaj nur unu el ili temas pri la reto. Tenu la konekton sur ĝia intencita vojo, kaj igi la klienton aŭtentikigi la servilon, kun kiu ĝi parolas. La unua duono estas kie VPN helpas; la dua duono devas esti agordita.
Ĉifrita al kio, precize?
TLS protektas la konversacion kontraŭ iu ajn en la mezo, kaj ĝi diras nenion pri tio, kiu la finpunkto asertas esti, se la kliento ne kontrolas. Atestilo, kiu validiĝas kontraŭ fidinda aŭtoritato, pruvas, ke la atestilo venis de tiu aŭtoritato. Ĝi ne pruvas, ke la atestilo estis eligita por la gastigantnomo, kiun vi intencis atingi, kaj tiuj estas malsamaj demandoj.
Tio ne estas teoria manko. Captive-portaloj, eraroj kun malĝusta VRF kaj koincidaj adresplanoj ĉiuj produktas servilon, kiu estas tute preta negocadi TLS kun vi. Se la kliento postulas nur ĉifradon, la sesio estas privata kaj direktita al la malĝusta datumbazo.
Do la koncerna demando ne estas ĉu la konekto estas ĉifrita, sed ĉu ĝi estas ĉifrita al la identeco, kiun vi intencis. En la kliento de MySQL, tiu distingo vivas tute en la agordo ssl-mode.
La kvin valoroj de ssl-mode en praktiko
Ekzistas kvin valoroj, kaj nur unu el ili respondas al la demando de ĉi tiu gvidlibro. La tabelo listigas, kion ĉiu efektive garantias, anstataŭ kion ĝia nomo sugestas.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
Nur la lasta vico respondas al la demando en ĉi tiu artikolo. PREFERRED indas memstare elstari, ĉar kliento, kiu silente falas al klarteksto, estas pli malbona ol unu, kiu rifuzas: vi kredas, ke vi havas ĉifradon, kaj la paketregistrado malkonsentas.
Konekto, kiun vi povas ruli hodiaŭ
La komando sube estas la formo uzi, kun du anstataŭigiloj: la aprobita datumbaznomo kaj CA-dosiero akirita per aprobita kanalo. Neniu el ili prenu el tio, kion la servilo proponas al vi ĉe la unua kontakto.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password sen valoro petas entajpon, kio tenas la sekreton ekster la procezlisto kaj ekster via ŝelhistorio. Tio estas malgranda kutimo kun granda profito sur komunaj saltgastigantoj, kie komandlinio estas videbla al aliaj uzantoj.
Kiam ĉi tio malsukcesas, la erarteksto distingas la kazojn pli bone ol intuicio. CA-malsukceso signifas, ke la ĉeno ne validiĝas, kaj vi devus rigardi, kiu CA subskribis la servilan atestilon. Gastigantnoma malsukceso signifas, ke la ĉeno estas en ordo kaj la nomo ne kongruas, kio kutime signifas, ke vi konektiĝis al la ĝusta servilo sub la malĝusta nomo, ne al la malĝusta servilo.
La apero de prompto ne estas pruvo, ke pasvorto jam transdoniĝis, kaj malsukcesa konekto ne pruvas, ke nenio lasis la klienton. Se vi rekonstruas pasintan okazaĵon, identigu la klienton, ĝian agordon, la aŭtentikigan kromaĵon kaj la etapon, kiu malsukcesis. Taksi la elmeton el la fina erarmesaĝo estas diveno.
Kiam la nomo venas el tunelo
Loka pordplusendado rompas la identeckontrolon laŭ maniero, kiu surprizas homojn. Se vi plusendigas lokan pordon al la datumbazo kaj konektiĝas al localhost, la kliento validigas la atestilon kontraŭ localhost, kaj neniu atestilo estis eligita por tiu nomo. La konekto povas esti tute sekura kaj la kontrolo ankoraŭ malsukcesos, kio estas la kontrolo funkcianta laŭ la intenco.
Estas du honestaj respondoj. Donu al la plusendita finpunkto nomon, kiu solviĝas al la bukloreta adreso kaj aperas en la servila atestilo, aŭ uzu la gastigantnomon de komenco ĝis fino, por ke la kliento kontrolu la veran identecon. La unua estas oportuna por programistoj kaj postulas atestilan laboron; la dua estas pli facile pripensebla kaj ofte la ĝusta defaŭlto por aŭtomatigo. Malŝalti la kontrolon por ke la plusendado funkciu forĵetas la econ, kiun vi provis aldoni.
Akcepto estas tri kondiĉoj
Skribu la akceptan teston kiel tri apartajn asertojn: la konekto uzis la intencitan vojon, ĉifrado estis postulata anstataŭ preferata, kaj la servila identeco estis kontrolita kontraŭ fidinda materialo. Verda VPN-ikono establas neniun el ili.
Por GUI-klientoj kaj por MariaDB, kontrolu la propran dokumentaron de la vendisto anstataŭ supozi, ke la literumado de la flago transdoniĝas. La MySQL-dokumentaro pri ĉifritaj konektoj kovras la diferencojn inter reĝimoj kaj la postulon pri disdonado de CA, kaj ĝi estas la referenco kontrolenda antaŭ ol vi ŝanĝos produkcian konektoĉenon.