MySQL sa pamamagitan ng VPN: i-verify ang server, hindi lang ang encryption
Ang pag-encrypt sa maling host ay mali pa rin. Ihambing ang mga halaga ng ssl-mode, pagkatapos ay patakbuhin ang isang koneksyon na pinangalanan ang nilalayong server at pinatutunayan ito.
Nagse-save ka ng koneksyon sa 10.20.4.15, bumabagsak ang VPN, at kumokonekta pa rin ang client. Hindi iyon magandang balita. Ang pribadong address ay isang lokasyon sa loob ng anumang konteksto ng routing kung saan ka naroon, at maraming network ang gumagamit ng parehong mga saklaw. Naabot ng client ang isang MySQL server, marahil hindi lang ang sa iyo.
Ang pag-aayos ay may dalawang kalahati, at isa lang sa kanila ang tungkol sa network. Panatilihin ang koneksyon sa nilalayong landas, at gawing i-authenticate ng client ang server na kausap nito. Ang unang kalahati ay kung saan nakakatulong ang VPN; ang ikalawang kalahati ay kailangang i-configure.
Naka-encrypt sa ano, eksakto?
Pinoprotektahan ng TLS ang usapan mula sa sinumang nasa gitna, at wala itong sinasabi tungkol sa kung sino ang sinasabi ng endpoint na siya, maliban kung susuriin ito ng client. Ang isang sertipiko na nagva-validate laban sa isang pinagkakatiwalaang awtoridad ay nagpapatunay na ang sertipiko ay galing sa awtoridad na iyon. Hindi nito pinatutunayan na ang sertipiko ay inisyu para sa hostname na nilalayon mong maabot, at magkaibang tanong iyon.
Hindi ito teoretikal na puwang. Ang mga captive portal, mga pagkakamali sa maling VRF at magkakapatong na mga plano ng address ay gumagawa ng isang server na lubos na handang makipag-negotiate ng TLS sa iyo. Kung ang client ay nangangailangan lang ng encryption, ang session ay pribado ngunit nakatutok sa maling database.
Kaya ang kaugnay na tanong ay hindi kung naka-encrypt ang koneksyon, kundi kung naka-encrypt ito sa identidad na nilalayon mo. Sa client ng MySQL, ang pagkakaibang iyon ay naninirahan nang buo sa setting na ssl-mode.
Ang limang halaga ng ssl-mode sa pagsasanay
May limang halaga, at isa lang sa kanila ang sumasagot sa tanong ng manwal na ito. Inililista ng talahanayan kung ano ang tunay na ginagarantiyahan ng bawat isa, hindi kung ano ang ipinahihiwatig ng pangalan nito.
| 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 |
Ang huling hilera lang ang sumasagot sa tanong sa artikulong ito. PREFERRED ay dapat bigyang-pansin nang mag-isa, dahil ang client na tahimik na bumabagsak sa plaintext ay mas masahol pa kaysa sa tumatanggi: inaakala mong may encryption ka at hindi sumasang-ayon ang packet capture.
Isang koneksyon na maaari mong patakbuhin ngayon
Ang utos sa ibaba ay ang anyo na dapat gamitin, na may dalawang placeholder: ang aprubadong pangalan ng database at isang CA file na nakuha sa pamamagitan ng aprubadong channel. Wala sa dalawa ang dapat kunin mula sa iniaalok ng server sa unang pakikipag-ugnayan.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password na walang halaga ay nagtatanong ng input, na nagpapanatili ng sikreto sa labas ng listahan ng proseso at sa labas ng kasaysayan ng iyong shell. Ito ay isang maliit na ugali na may malaking pakinabang sa mga shared jump host, kung saan ang command line ay nakikita ng ibang user.
Kapag nabigo ito, mas natutukoy ng error text ang mga kaso kaysa sa intuwisyon. Ang pagkabigo ng CA ay nangangahulugan na hindi nagva-validate ang chain at dapat mong tingnan kung aling CA ang pumirma sa sertipiko ng server. Ang pagkabigo ng hostname ay nangangahulugan na maayos ang chain at hindi tugma ang pangalan, na karaniwang nangangahulugan na kumonekta ka sa tamang server sa maling pangalan, hindi sa maling server.
Ang paglitaw ng prompt ay hindi patunay na naipadala na ang password, at ang nabigong koneksyon ay hindi nagpapatunay na walang lumabas sa client. Kung binubuo mong muli ang nakaraang pangyayari, tukuyin ang client, ang configuration nito, ang authentication plugin at ang yugtong nabigo. Ang pagtantya ng exposure mula sa huling error message ay haka-haka.
Kapag ang pangalan ay galing sa isang tunnel
Sinisira ng local port forwarding ang identity check sa paraang nakakagulat sa mga tao. Kung ipapasa mo ang isang lokal na port sa database at kumonekta sa localhost, ginava-validate ng client ang sertipiko laban sa localhost, at walang sertipikong inisyu para sa pangalang iyon. Maaaring ganap na ligtas ang koneksyon at mabibigo pa rin ang verification, na siyang verification na gumagana ayon sa layunin.
May dalawang tapat na sagot. Bigyan ang forwarded endpoint ng pangalan na nagre-resolve sa loopback address at lumilitaw sa sertipiko ng server, o gamitin ang hostname mula simula hanggang dulo upang ma-verify ng client ang tunay na identidad. Ang una ay maginhawa para sa mga developer at nangangailangan ng gawaing sertipiko; ang pangalawa ay mas madaling isipin at kadalasan ang tamang default para sa automation. Ang pag-off ng verification para gumana ang forwarding ay itinatapon ang property na sinusubukan mong idagdag.
Ang pagtanggap ay tatlong kundisyon
Isulat ang acceptance test bilang tatlong hiwalay na pahayag: ginamit ng koneksyon ang nilalayong ruta, kinakailangan ang encryption hindi lamang ginusto, at na-verify ang identidad ng server laban sa pinagkakatiwalaang materyal. Ang berdeng VPN icon ay hindi nagtatatag ng alinman sa mga ito.
Para sa mga GUI client at para sa MariaDB, tingnan ang dokumentasyon ng vendor mismo sa halip na ipagpalagay na ang spelling ng flag ay nagdadala. Ang dokumentasyon ng MySQL tungkol sa mga naka-encrypt na koneksyon ay sumasaklaw sa mga pagkakaiba sa pagitan ng mga mode at sa pangangailangan ng pamamahagi ng CA, at ito ang reference na dapat suriin bago mo baguhin ang isang production connection string.