MySQL caur VPN: pārbaudiet serveri, ne tikai šifrēšanu
Šifrēšana uz nepareizo resursdatoru joprojām ir nepareiza. Salīdziniet ssl-mode vērtības, pēc tam izpildiet savienojumu, kas nosauc paredzēto serveri un to pierāda.
Jūs saglabājat savienojumu ar 10.20.4.15, VPN nokrīt, un klients joprojām savienojas. Tās nav labas ziņas. Privāta adrese ir vieta jebkurā maršrutēšanas kontekstā, kurā jūs atrodaties, un daudzi tīkli izmanto tos pašus diapazonus. Klients sasniedza MySQL serveri, tikai varbūt ne jūsējo.
Labojumam ir divas puses, un tikai viena no tām ir par tīklu. Turiet savienojumu paredzētajā ceļā un lieciet klientam autentificēt serveri, ar kuru tas runā. Pirmā puse ir vieta, kur palīdz VPN; otrā puse ir jākonfigurē.
Šifrēts uz ko, tieši?
TLS aizsargā sarunu no jebkura, kas atrodas vidū, un neko nesaka par to, ko galapunkts apgalvo esam, ja vien klients to nepārbauda. Sertifikāts, kas validējas pret uzticamu iestādi, pierāda, ka sertifikāts nāca no šīs iestādes. Tas nepierāda, ka sertifikāts tika izsniegts tam resursdatora nosaukumam, kuru gribējāt sasniegt, un tie ir dažādi jautājumi.
Tā nav teorētiska nepilnība. Captive portāli, kļūdas ar nepareizu VRF un pārklājošies adrešu plāni visi rada serveri, kas ir pilnīgi gatavs apspriest TLS ar jums. Ja klients pieprasa tikai šifrēšanu, sesija ir privāta un vērsta uz nepareizo datubāzi.
Tātad attiecīgais jautājums nav par to, vai savienojums ir šifrēts, bet gan par to, vai tas ir šifrēts uz identitāti, kuru bijāt iecerējis. MySQL klientā šī atšķirība pilnībā dzīvo iestatījumā ssl-mode.
Piecas ssl-mode vērtības praksē
Pastāv piecas vērtības, un tikai viena no tām atbild uz šīs rokasgrāmatas jautājumu. Tabula uzskaita, ko katra faktiski garantē, nevis to, ko liek domāt tās nosaukums.
| 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 |
Uz šī raksta jautājumu atbild tikai pēdējā rinda. PREFERRED ir vērts izcelt atsevišķi, jo klients, kas klusi pāriet uz vienkāršu tekstu, ir sliktāks par to, kas atsakās: jūs ticat, ka jums ir šifrēšana, un pakešu tveršana tam nepiekrīt.
Savienojums, ko varat izpildīt šodien
Tālāk esošā komanda ir forma, kas jāizmanto, ar diviem vietturētājiem: apstiprināto datubāzes nosaukumu un CA failu, kas iegūts apstiprinātā kanālā. Nevienu no tiem nevajadzētu ņemt no tā, ko serveris piedāvā pirmajā kontaktā.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password bez vērtības prasa ievadi, kas glabā noslēpumu ārpus procesu saraksta un ārpus jūsu čaulas vēstures. Tas ir mazs ieradums ar lielu ieguvumu koplietotos lēciena resursdatoros, kur komandrinda ir redzama citiem lietotājiem.
Kad tas neizdodas, kļūdas teksts atšķir gadījumus labāk nekā intuīcija. CA kļūda nozīmē, ka ķēde nevalidējas, un jums jāskatās, kura CA parakstīja servera sertifikātu. Resursdatora nosaukuma kļūda nozīmē, ka ķēde ir kārtībā un nosaukums nesakrīt, kas parasti nozīmē, ka savienojāties ar pareizo serveri nepareizā nosaukumā, nevis ar nepareizo serveri.
Uzvednes parādīšanās nav pierādījums, ka parole jau ir pārsūtīta, un neizdevies savienojums nepierāda, ka nekas nav atstājis klientu. Ja rekonstruējat pagātnes notikumu, identificējiet klientu, tā konfigurāciju, autentifikācijas spraudni un posmu, kas neizdevās. Ietekmes novērtēšana no pēdējā kļūdas ziņojuma ir minējums.
Kad nosaukums nāk no tuneļa
Vietējā porta pāradresācija salauž identitātes pārbaudi tā, ka cilvēki tiek pārsteigti. Ja pāradresējat vietējo portu uz datubāzi un savienojaties ar localhost, klients validē sertifikātu pret localhost, un šim nosaukumam sertifikāts netika izsniegts. Savienojums var būt pilnīgi drošs, un pārbaude tomēr neizdosies, kas ir pārbaude, kas darbojas, kā paredzēts.
Ir divas godīgas atbildes. Piešķiriet pāradresētajam galapunktam nosaukumu, kas atrisinās uz loopback adresi un parādīsies servera sertifikātā, vai izmantojiet resursdatora nosaukumu no sākuma līdz beigām, lai klients pārbaudītu īsto identitāti. Pirmais ir ērts izstrādātājiem un prasa sertifikātu darbu; otrais ir vieglāk pārdomājams un bieži vien pareizais noklusējums automatizācijai. Pārbaudes izslēgšana, lai pāradresācija darbotos, izmet īpašību, ko mēģinājāt pievienot.
Pieņemšana ir trīs nosacījumi
Uzrakstiet pieņemšanas testu kā trīs atsevišķus apgalvojumus: savienojums izmantoja paredzēto maršrutu, šifrēšana bija prasīta, nevis vēlamā, un servera identitāte tika pārbaudīta pret uzticamu materiālu. Zaļa VPN ikona nenodibina nevienu no tiem.
GUI klientiem un MariaDB pārbaudiet paša piegādātāja dokumentāciju, nevis pieņemiet, ka karodziņa rakstība pārnesas. MySQL dokumentācija par šifrētiem savienojumiem aptver atšķirības starp režīmiem un CA izplatīšanas prasību, un tā ir atsauce, kas jāpārbauda pirms ražošanas savienojuma virknes maiņas.