MySQL VPN baten bidez: egiaztatu zerbitzaria, ez soilik enkriptazioa
Ostalari oker batera enkriptatzea okerra da oraindik. Alderatu ssl-mode balioak, eta gero exekutatu nahi zenuen zerbitzariari izena ematen dion eta hori frogatzen duen konexio bat.
Konexio bat gordetzen duzu 10.20.4.15 helbidera, VPN-a erortzen da, eta bezeroak konektatzen jarraitzen du. Hori ez da albiste ona. Helbide pribatua zauden bideratze-testuinguruaren barruko kokapena da, eta sare askok tarte berak erabiltzen dituzte. Bezeroa MySQL zerbitzari batera iritsi zen, agian ez zureera.
Konponketak bi erdi ditu, eta horietako bat baino ez da sareari buruzkoa. Eutsi konexioari xede duen bideari, eta egin bezeroak hitz egiten duen zerbitzaria autentifikatzeko. Lehen erdia VPN-ak laguntzen duen tokia da; bigarren erdia konfiguratu behar da.
Zerera enkriptatuta, zehazki?
TLS-k elkarrizketa erdian dagoen edonorengandik babesten du eta ez du ezer esaten muturrak nor den dioenari buruz, bezeroak egiaztatzen ez badu. Autoritate fidagarri baten aurka baliozkotzen den ziurtagiriak frogatzen du ziurtagiria autoritate horretatik datorrela. Ez du frogatzen ziurtagiria lortu nahi zenuen ostalari-izenerako jaulki zenik, eta horiek galdera desberdinak dira.
Hau ez da hutsune teorikoa. Captive atariak, VRF okerreko erroreak eta gainjarritako helbide-planak guztiek zerbitzari bat sortzen dute, zurekin TLS-a negoziatzeko erabat prest dagoena. Bezeroak enkriptazioa soilik eskatzen badu, saioa pribatua da eta datu-base okerrean zentratuta dago.
Beraz, galdera garrantzitsua ez da konexioa enkriptatuta dagoen, baizik eta nahi zenuen identitatera enkriptatuta dagoen. MySQL-ren bezeroan, bereizketa hori ssl-mode ezarpenean bizi da erabat.
Bost ssl-mode balioak praktikan
Bost balio daude, eta horietako batek baino ez dio erantzuten eskuliburu honetako galderari. Taulak bakoitzak benetan bermatzen duena zerrendatzen du, ez bere izenak iradokitzen duena.
| 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 |
Artikulu honetako galderari azken errenkadak baino ez dio erantzuten. PREFERRED bere horretan nabarmena da, isilpean testu soileko ibilbidera jaisten den bezero bat ukatzen duen bat baino okerragoa delako: enkriptazioa duzula uste duzu eta paketeen kapturak ez du bat egiten.
Gaur exekuta dezakezun konexio bat
Beheko komandoa erabili beharreko forma da, bi leku-markatzailekin: onartutako datu-basearen izena eta onartutako kanal bidez lortutako CA fitxategia. Inor ez litzateke hartu behar zerbitzariak lehen kontaktuan eskaintzen dizunetik.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password baliorik gabe galdetzen du, eta horrek sekretua prozesuen zerrendatik eta zure shell-historialetik kanpo mantentzen du. Ohitura txiki bat da, irabazi handikoa partekatutako jauzi-ostalarrietan, non komando-lerroa beste erabiltzaileentzat ikusgai dagoen.
Honek huts egiten duenean, errorearen testuak kasuak intuizioak baino hobeto bereizten ditu. CA hutsegiteak katea ez dela baliozkotzen adierazten du, eta zerbitzariaren ziurtagiria zein CA-k sinatu zuen begiratu beharko zenuke. Ostalari-izen hutsegiteak katea ondo dagoela eta izena bat ez datorrela adierazten du, eta horrek normalean esan nahi du zerbitzari zuzenarekin konektatu zinela izen okerrarekin, ez zerbitzari okerrarekin.
Gonbita bat agertzeak ez du frogatzen pasahitz bat jada bidali denik, eta konexio huts batek ez du frogatzen bezeroa ezer utzi ez zuenik. Iraganeko gertaera bat berreraikitzen ari bazara, identifikatu bezeroa, haren konfigurazioa, autentifikazio-plugina eta huts egin zuen etapa. Azken errore-mezutik esposizioa kalkulatzea asmatzea da.
Izena tunel batetik datorrenean
Tokiko ataka-birbidalketak identitate-egiaztapena hausten du jendea harritzen duen moduan. Tokiko ataka bat datu-basera birbidaltzen baduzu eta localhost helbidera konektatzen bazara, bezeroak ziurtagiria localhost-ren aurka baliozkotzen du, eta izen horretarako ez zen ziurtagiririk jaulki. Konexioa erabat segurua izan daiteke eta egiaztapenak huts egingo du hala ere, hau da, egiaztapena xede bezala funtzionatzen ari da.
Bi erantzun zintzo daude. Eman birbidalitako muturrari loopback helbidera ebazten den eta zerbitzariaren ziurtagirian agertzen den izen bat, edo erabili ostalari-izena hasieratik amaierara bezeroak benetako identitatea egiazta dezan. Lehena garatzaileentzat erosoa da eta ziurtagiri-lana eskatzen du; bigarrena errazagoa da pentsatzen eta askotan automatizaziorako balio lehenetsi egokia da. Birbidalketa funtziona dezan egiaztapena desgaitzeak gehitzen saiatzen ari zinen propietatea botatzen du.
Onarpena hiru baldintza dira
Idatzi onarpen-proba hiru baieztapen bereizi gisa: konexioak xede zuen bidea erabili zuen, enkriptazioa beharrezkoa zen, ez hobetsia, eta zerbitzariaren identitatea material fidagarriaren aurka egiaztatu zen. VPN ikono berde batek ez du horietako bat ere ezartzen.
GUI bezeroentzat eta MariaDBrentzat, egiaztatu saltzailearen beraren dokumentazioa, ez suposatu banderaren idazkera aldatzen denik. MySQL-en konexio enkriptatuei buruzko dokumentazioa moduen arteko desberdintasunak eta CA banaketaren baldintza biltzen ditu, eta ekoizpeneko konexio-kate bat aldatu aurretik egiaztatu beharreko erreferentzia da.