MySQL melalui VPN: verifikasi servernya, bukan hanya enkripsinya
Mengenkripsi ke host yang salah tetap salah. Bandingkan nilai ssl-mode, lalu jalankan koneksi yang menyebut server yang dimaksud dan membuktikannya.
Anda menyimpan koneksi ke 10.20.4.15, VPN terputus, dan klien tetap terhubung. Itu bukan kabar baik. Alamat privat adalah lokasi di dalam konteks perutean apa pun Anda berada, dan banyak jaringan memakai rentang yang sama. Klien mencapai server MySQL, hanya mungkin bukan milik Anda.
Perbaikannya punya dua bagian, dan hanya satu yang soal jaringan. Jaga koneksi pada jalur yang dimaksud, dan buat klien mengautentikasi server yang diajak bicara. Bagian pertama adalah tempat VPN membantu; bagian kedua harus dikonfigurasi.
Dienkripsi ke apa, tepatnya?
TLS melindungi percakapan dari siapa pun di tengah, dan tidak mengatakan apa pun tentang siapa yang diklaim endpoint kecuali klien memeriksanya. Sertifikat yang tervalidasi terhadap otoritas tepercaya membuktikan sertifikat itu berasal dari otoritas tersebut. Itu tidak membuktikan sertifikat diterbitkan untuk nama host yang ingin Anda capai, dan itu pertanyaan yang berbeda.
Ini bukan celah teoretis. Portal captive, kesalahan VRF yang salah, dan rencana alamat yang tumpang tindih semuanya menghasilkan server yang sepenuhnya bersedia bernegosiasi TLS dengan Anda. Jika klien hanya mensyaratkan enkripsi, sesinya privat dan mengarah ke basis data yang salah.
Jadi pertanyaan yang relevan bukanlah apakah koneksinya terenkripsi, melainkan apakah koneksi itu terenkripsi ke identitas yang Anda maksud. Di klien MySQL, perbedaan itu sepenuhnya hidup di pengaturan ssl-mode.
Lima nilai ssl-mode dalam praktik
Ada lima nilai, dan hanya satu yang menjawab pertanyaan buku panduan ini. Tabel mencantumkan apa yang sebenarnya dijamin masing-masing, bukan apa yang disiratkan namanya.
| 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 |
Hanya baris terakhir yang menjawab pertanyaan dalam artikel ini. PREFERRED layak disorot tersendiri, karena klien yang diam-diam turun ke teks polos lebih buruk daripada yang menolak: Anda yakin punya enkripsi dan tangkapan paket tidak setuju.
Koneksi yang bisa Anda jalankan hari ini
Perintah di bawah adalah bentuk yang digunakan, dengan dua placeholder: nama basis data yang disetujui dan file CA yang diperoleh melalui saluran yang disetujui. Keduanya tidak boleh diambil dari apa pun yang ditawarkan server pada kontak pertama.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password tanpa nilai meminta masukan, yang menjaga rahasia dari daftar proses dan dari riwayat shell Anda. Itu kebiasaan kecil dengan hasil besar pada host lompat bersama, tempat baris perintah terlihat oleh pengguna lain.
Ketika ini gagal, teks kesalahan membedakan kasus lebih baik daripada intuisi. Kegagalan CA berarti rantai tidak tervalidasi dan Anda harus melihat CA mana yang menandatangani sertifikat server. Kegagalan nama host berarti rantainya baik dan namanya tidak cocok, yang biasanya berarti Anda terhubung ke server yang benar dengan nama yang salah, bukan ke server yang salah.
Munculnya prompt bukan bukti kata sandi sudah terkirim, dan koneksi yang gagal tidak membuktikan tidak ada yang keluar dari klien. Jika Anda merekonstruksi peristiwa masa lalu, identifikasi klien, konfigurasinya, plugin autentikasi, dan tahap yang gagal. Memperkirakan paparan dari pesan kesalahan terakhir adalah tebakan.
Ketika namanya datang dari terowongan
Penerusan port lokal merusak pemeriksaan identitas dengan cara yang mengejutkan orang. Jika Anda meneruskan port lokal ke basis data dan terhubung ke localhost, klien memvalidasi sertifikat terhadap localhost, dan tidak ada sertifikat yang diterbitkan untuk nama itu. Koneksinya bisa sepenuhnya aman dan verifikasinya tetap gagal, yang berarti pemeriksaan bekerja sebagaimana mestinya.
Ada dua jawaban jujur. Beri endpoint yang diteruskan sebuah nama yang diselesaikan ke alamat loopback dan muncul di sertifikat server, atau gunakan nama host dari ujung ke ujung agar klien memverifikasi identitas sebenarnya. Yang pertama nyaman bagi pengembang dan memerlukan pekerjaan sertifikat; yang kedua lebih mudah dicerna dan sering menjadi default yang tepat untuk otomatisasi. Menonaktifkan verifikasi agar penerusan berfungsi membuang properti yang ingin Anda tambahkan.
Penerimaan adalah tiga syarat
Tulis tes penerimaan sebagai tiga pernyataan terpisah: koneksi menggunakan jalur yang dimaksud, enkripsi diwajibkan bukan diutamakan, dan identitas server diverifikasi terhadap materi tepercaya. Ikon VPN hijau tidak menetapkan satu pun dari itu.
Untuk klien GUI dan MariaDB, periksa dokumentasi vendor itu sendiri alih-alih menganggap ejaan flag ikut berlaku. Dokumentasi koneksi terenkripsi MySQL mencakup perbedaan mode dan persyaratan distribusi CA, dan itulah rujukan yang harus diperiksa sebelum Anda mengubah string koneksi produksi.