MySQL přes VPN: ověřte server, ne jen šifrování
Šifrování ke špatnému hostiteli je pořád špatné. Porovnejte hodnoty ssl-mode a pak spusťte připojení, které pojmenuje zamýšlený server a dokáže to.
Ukládáte připojení k 10.20.4.15, VPN spadne a klient se přesto připojí. To není dobrá zpráva. Soukromá adresa je místo v jakémkoli směrovacím kontextu, ve kterém se právě nacházíte, a mnoho sítí používá stejné rozsahy. Klient dosáhl serveru MySQL, jen možná ne toho vašeho.
Oprava má dvě poloviny a jen jedna z nich je o síti. Držte připojení na zamýšlené cestě a přimějte klienta ověřit server, se kterým mluví. První polovina je tam, kde pomáhá VPN; druhá se musí nakonfigurovat.
Šifrováno k čemu, přesně?
TLS chrání rozhovor před kýmkoli uprostřed a neříká nic o tom, kým se koncový bod prohlašuje, pokud to klient neověří. Certifikát, který se ověří proti důvěryhodné autoritě, dokazuje, že certifikát pochází od této autority. Nedokazuje, že byl certifikát vydán pro název hostitele, kterého jste chtěli dosáhnout, a to jsou různé otázky.
To není teoretická mezera. Captive portály, chyby se špatným VRF a překrývající se plány adres všechny vytvářejí server, který je zcela ochotný s vámi vyjednávat TLS. Pokud klient vyžaduje jen šifrování, je relace soukromá a míří do špatné databáze.
Správná otázka tedy není, zda je připojení šifrované, ale zda je šifrované k identitě, kterou jste zamýšleli. V klientu MySQL tato rozlišnost žije zcela v nastavení ssl-mode.
Pět hodnot ssl-mode v praxi
Existuje pět hodnot a jen jedna z nich odpovídá na otázku této příručky. Tabulka uvádí, co každá skutečně zaručuje, nikoli co naznačuje její název.
| 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 |
Na otázku v tomto článku odpovídá jen poslední řádek. PREFERRED stojí za samostatné zmínění, protože klient, který tiše přejde na čistý text, je horší než ten, který odmítne: věříte, že máte šifrování, a zachytávání paketů nesouhlasí.
Připojení, které můžete spustit dnes
Níže uvedený příkaz je podoba, kterou použijte, se dvěma zástupnými údaji: schválený název databáze a soubor CA získaný schváleným kanálem. Ani jeden by se neměl brát z toho, co vám server nabídne při prvním kontaktu.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password bez hodnoty vyzve k zadání, což udrží tajemství mimo seznam procesů a mimo historii shellu. Je to malý zvyk s velkým přínosem na sdílených jump hostech, kde je příkazový řádek viditelný ostatním uživatelům.
Když to selže, text chyby rozlišuje případy lépe než intuice. Selhání CA znamená, že se řetězec neověřuje, a měli byste se dívat, která CA podepsala certifikát serveru. Selhání názvu hostitele znamená, že řetězec je v pořádku a název nesouhlasí, což obvykle znamená, že jste se připojili ke správnému serveru pod špatným názvem, nikoli ke špatnému serveru.
Objevení výzvy není důkazem, že heslo už bylo přeneseno, a neúspěšné připojení nedokazuje, že z klienta nic neodešlo. Pokud rekonstruujete minulou událost, určete klienta, jeho konfiguraci, autentizační plugin a fázi, která selhala. Odhadovat expozici z konečné chybové zprávy je hádání.
Když název přichází z tunelu
Lokální přesměrování portu rozbíjí kontrolu identity způsobem, který lidi překvapuje. Pokud přesměrujete lokální port k databázi a připojíte se k localhost, klient ověří certifikát proti localhost, a pro tento název nebyl vydán žádný certifikát. Připojení může být zcela bezpečné a ověření přesto selže, což je kontrola fungující podle záměru.
Existují dvě čestné odpovědi. Dejte přesměrovanému koncovému bodu název, který se překládá na adresu zpětné smyčky a objevuje se v certifikátu serveru, nebo použijte název hostitele od začátku do konce, aby klient ověřil skutečnou identitu. První je pohodlné pro vývojáře a vyžaduje práci s certifikáty; druhé se snáz promýšlí a často je správným výchozím nastavením pro automatizaci. Vypnutí ověření, aby přesměrování fungovalo, zahazuje vlastnost, kterou jste se snažili přidat.
Přijetí jsou tři podmínky
Napište akceptační test jako tři samostatná tvrzení: připojení použilo zamýšlenou trasu, šifrování bylo vyžadováno, nikoli preferováno, a identita serveru byla ověřena proti důvěryhodnému materiálu. Zelená ikona VPN neustavuje ani jedno z nich.
U GUI klientů a u MariaDB si projděte vlastní dokumentaci dodavatele, místo abyste předpokládali, že pravopis přepínače se přenáší. Dokumentace MySQL o šifrovaných připojeních pokrývá rozdíly mezi režimy a požadavek distribuce CA a je odkazem, který je třeba zkontrolovat, než změníte produkční připojovací řetězec.