Setiap kali klien database mengirimkan query atau menerima kumpulan hasil, data tersebut dikirim melalui jaringan. Pada jaringan pribadi dan terisolasi tanpa akses eksternal, hal ini mungkin merupakan risiko yang dapat diterima. Namun, di sebagian besar lingkungan dunia nyata, di mana lalu lintas data melintasi infrastruktur bersama, jaringan cloud, atau internet terbuka, koneksi database yang tidak terenkripsi merupakan risiko yang signifikan. Enkripsi SSL/TLS menutup celah tersebut, dan mengonfigurasinya dengan benar merupakan salah satu langkah paling penting namun sering diabaikan dalam mengamankan lingkungan database.
Kenapa Koneksi Tanpa Terenkripsi Adalah Risiko Nyata
Tanpa enkripsi, data yang dipertukarkan antara klien dan server database dikirimkan dalam bentuk teks biasa. Siapa pun yang berada di jalur jaringan yang sama—baik melalui router yang diretas, jaringan virtual cloud yang salah konfigurasi, maupun ancaman dari dalam—berpotensi membaca lalu lintas tersebut. Hal ini mencakup tidak hanya hasil query, tetapi juga kredensial otentikasi. Paket login yang disadap dari koneksi database yang tidak terenkripsi memberikan penyerang nama pengguna dan kata sandi yang valid tanpa memerlukan upaya tambahan dari pihak mereka. Risikonya bukan sekadar teori; intersepsi di tingkat jaringan adalah teknik serangan yang telah didokumentasikan dengan baik, dan dampaknya jauh lebih parah ketika lalu lintas yang disadap berasal dari database.
Memahami Rantai Sertifikat
Transport Layer Security (TLS) dibangun di atas sistem sertifikat digital. Sebelum komunikasi terenkripsi dapat dimulai, server menunjukkan sertifikat kepada klien yang membuktikan identitasnya, yang secara efektif menyatakan: “Saya adalah siapa yang saya klaim, dan inilah dokumen yang ditandatangani secara kriptografis dari otoritas tepercaya untuk membuktikannya.” Otoritas tepercaya tersebut adalah Certificate Authority (CA), dan perannya adalah menjamin keaslian identitas sertifikat yang diterbitkannya.
Dalam praktiknya, ini berarti Anda memerlukan tiga hal untuk membangun koneksi TLS yang terverifikasi dengan benar ke server database:
- Server harus memiliki sertifikat yang valid yang diterbitkan oleh CA.
- Klien harus memiliki salinan sertifikat CA agar dapat memverifikasi identitas server.
- (opsional) Untuk mutual TLS (mTLS) - klien juga menunjukkan sertifikatnya sendiri kepada server, sehingga otentikasi berjalan dua arah. Otentikasi sisi klien opsional ini kadang-kadang disebut otentikasi berbasis sertifikat, dan memberikan jaminan yang jauh lebih kuat daripada otentikasi berbasis kata sandi saja.
Opsi Konfigurasi Utama yang Perlu Dipahami
Saat mengonfigurasi TLS untuk koneksi database, terdapat beberapa parameter yang secara konsisten muncul di berbagai sistem database dan klien:
- Berkas sertifikat CA berfungsi sebagai titik acuan kepercayaan. Berkas ini memberitahu klien otoritas sertifikat mana yang harus dipercaya saat memverifikasi identitas server.
- Berkas sertifikat klien dan berkas kunci klien digunakan ketika TLS timbal balik diperlukan, sehingga server dapat memverifikasi identitas klien sebagai balasannya.
- Spesifikasi cipher menentukan algoritma enkripsi mana yang dapat diterima untuk sesi tersebut; menentukan cipher yang kuat dan modern daripada menerima pengaturan default merupakan praktik yang baik, karena rangkaian cipher yang lebih lama memiliki kelemahan yang diketahui.
Opsi PostgreSQL SSL
PostgreSQL menambahkan fitur yang sangat berguna dalam hal ini melalui pengaturan mode SSL-nya, yang memungkinkan Anda menentukan seberapa ketat koneksi tersebut harus diterapkan. Opsi-opsinya berkisar dari allow (coba tanpa SSL terlebih dahulu, beralih ke SSL jika diperlukan) dan prefer (coba SSL terlebih dahulu, beralih ke koneksi tanpa enkripsi) hingga require (hanya SSL, tetapi tidak memverifikasi sertifikat) hingga verify-ca (SSL dan memverifikasi bahwa sertifikat berasal dari CA tepercaya) dan verify-full (SSL, CA terverifikasi, dan nama host server harus sesuai dengan sertifikat). Untuk lingkungan produksi, verify-ca atau verify-full adalah pilihan yang tepat karena pengaturan yang kurang ketat dari require memberikan celah bagi serangan man-in-the-middle.
Tunneling SSH sebagai Pendekatan Alternatif
SSL/TLS mengenkripsi protokol database itu sendiri. Tunneling Secure Shell (SSH) menggunakan pendekatan yang berbeda: ia membungkus seluruh koneksi database di dalam sesi SSH yang terenkripsi. Klien database terhubung ke port lokal, terowongan SSH meneruskan lalu lintas tersebut melalui koneksi terenkripsi ke server jarak jauh, dan server basis data melihat koneksi lokal dari titik akhir terowongan. Terowongan SSH sangat berguna dalam situasi di mana server database tidak memiliki konfigurasi TLS, atau di mana port database langsung tidak terpapar secara eksternal karena alasan firewall, karena hanya memerlukan akses SSH daripada konfigurasi TLS tingkat database. Ini juga merupakan cara yang mudah untuk mengamankan akses jarak jauh bagi administrator yang perlu terhubung secara interaktif ke database yang berada di balik host benteng.
Bagaimana Navicat Support SSL/TLS dan Tunneling SSH
Produk desktop Navicat — termasuk Navicat Premium dan klien khusus database individual — menyediakan konfigurasi SSL/TLS langsung di dalam antarmuka pengaturan koneksi, yang dapat diakses melalui tab SSL khusus saat membuat atau mengedit koneksi. Dari sana, pengguna dapat mengaktifkan SSL, menyediakan berkas sertifikat CA yang diperlukan untuk memverifikasi identitas server, dan secara opsional menyediakan sertifikat klien serta berkas kunci klien untuk TLS timbal balik. Bidang spesifikasi cipher memungkinkan administrator membatasi suite cipher mana yang dapat diterima untuk koneksi tersebut, daripada mengandalkan default yang dinegosiasikan. Khusus untuk koneksi PostgreSQL, Navicat menampilkan berbagai opsi mode SSL yang dijelaskan di atas, sehingga administrator dapat mengontrol secara tepat seberapa ketat koneksi tersebut diverifikasi.
Tunneling SSH juga didukung secara native di seluruh rangkaian produk Navicat. Tab SSH di dialog koneksi memungkinkan pengguna mengonfigurasi tunnel melalui server SSH perantara, dengan dukungan untuk otentikasi berbasis kata sandi maupun pasangan kunci publik/pribadi. Hal ini memudahkan untuk terhubung secara aman ke database yang tidak terpapar langsung ke jaringan eksternal.
Navicat On-Prem Server memperluas dukungan SSL/TLS ini ke kolaborasi juga. Koneksi antara On-Prem Server dan kliennya dapat dienkripsi menggunakan SSL/TLS, dengan administrator dapat mengonfigurasi rangkaian cipher spesifik yang digunakan untuk sesi tersebut. SSL/TLS juga dapat diterapkan pada koneksi antara Navicat On-Prem Server dan database repositori dasarnya, memastikan bahwa infrastruktur internal platform kolaborasi dienkripsi dari ujung ke ujung, bukan hanya koneksi dari pengguna akhir.
Kesimpulan
Mengonfigurasi SSL/TLS untuk koneksi database bukanlah tugas yang rumit, tetapi memerlukan perhatian terhadap detail-detail seperti pengelolaan sertifikat, pemilihan mode, dan konfigurasi cipher, yang mudah salah dilakukan atau dibiarkan pada pengaturan default yang tidak aman. Imbalannya jika dilakukan dengan benar adalah pengurangan risiko yang signifikan terhadap kemungkinan intersepsi di tingkat jaringan yang berujung pada pencurian kredensial atau kebocoran data. Untuk setiap database yang menangani data sensitif atau diakses melalui jaringan apa pun selain jaringan yang sepenuhnya pribadi dan terisolasi, konfigurasi TLS yang tepat bukanlah pilihan—melainkan persyaratan dasar.
