Mengamankan konektivitas dengan TLS dan SSL di server fleksibel Azure Database for PostgreSQL

2024-11-09

BERLAKU UNTUK: Azure Database for PostgreSQL - Server Fleksibel

Server fleksibel Azure Database for PostgreSQL memberlakukan menghubungkan aplikasi klien Anda ke server fleksibel Azure Database for PostgreSQL dengan menggunakan Keamanan Lapisan Transportasi (TLS). TLS adalah protokol standar industri yang memastikan koneksi jaringan terenkripsi antara server database dan aplikasi klien. TLS adalah protokol terbaru dari SSL (Secure Sockets Layer).

Apa itu TLS?

TLS dibuat dari protokol SSL Netscape dan telah menggantinya secara teratur. Istilah SSL atau TLS/SSL terkadang masih digunakan secara bergantian. TLS terbuat dari dua lapisan: rekaman TLS menunjukkan dan pertunjukan jabat tangan TLS. Rekaman menunjukkan memberikan keamanan asosiasi. Jabat tangan menunjukkan memberdayakan server dan pelanggan untuk menegaskan satu sama lain dan untuk mengoordinasikan penilaian enkripsi dan kunci kriptografi sebelum informasi apa pun diperdagangkan.

Diagram sebelumnya menunjukkan urutan jabat tangan TLS 1.2 yang khas, yang terdiri dari langkah-langkah berikut:

Klien mulai dengan mengirim pesan yang disebut ClientHello yang menyatakan kesediaan untuk berkomunikasi melalui TLS 1.2 dengan serangkaian suite sandi yang didukung klien.
Server menerima pesan, jawaban dengan ServerHello, dan setuju untuk berkomunikasi dengan klien melalui TLS 1.2 dengan menggunakan rangkaian sandi tertentu.
Server juga mengirim berbagi kuncinya. Spesifikasi perubahan berbagi kunci ini berdasarkan cipher suite yang dipilih. Agar klien dan server menyetujui kunci kriptografi, mereka perlu menerima bagian satu sama lain, atau berbagi.
Server mengirim sertifikat (ditandatangani oleh otoritas sertifikat [CA]) dan tanda tangan pada bagian ClientHello dan ServerHello. Ini juga termasuk berbagi kunci. Dengan cara ini, klien tahu bahwa mereka autentik.
Setelah klien berhasil menerima data dan kemudian menghasilkan berbagi kuncinya sendiri, klien mencampurnya dengan berbagi kunci server untuk menghasilkan kunci enkripsi untuk sesi tersebut.
Klien mengirim server berbagi kuncinya, mengaktifkan enkripsi, dan mengirim Finished pesan. Pesan ini adalah hash dari transkrip dari apa yang telah terjadi sejauh ini. Server melakukan hal yang sama. Ini mencampur berbagi kunci untuk mendapatkan kunci dan mengirim pesannya sendiri Finished .
Sekarang data aplikasi dapat dikirim dienkripsi pada koneksi.

Rantai sertifikat

Rantai sertifikat adalah daftar sertifikat yang diurutkan yang berisi sertifikat TLS/SSL dan sertifikat CA. Mereka memungkinkan penerima untuk memverifikasi bahwa pengirim dan semua CA dapat dipercaya. Rantai atau jalur dimulai dengan sertifikat TLS/SSL. Setiap sertifikat dalam rantai ditandatangani oleh entitas yang diidentifikasi oleh sertifikat berikutnya dalam rantai.

Rantai berakhir dengan sertifikat OS akar. Sertifikat ini selalu ditandatangani oleh CA itu sendiri. Tanda tangan semua sertifikat dalam rantai harus diverifikasi hingga sertifikat CA akar.

Sertifikat apa pun yang berada di antara sertifikat TLS/SSL dan sertifikat CA akar dalam rantai disebut sertifikat perantara.

Versi TLS

Beberapa entitas pemerintah di seluruh dunia mempertahankan pedoman untuk TLS mengenai keamanan jaringan. Dalam Amerika Serikat, organisasi-organisasi ini termasuk Departemen Kesehatan dan Layanan Manusia dan Institut Standar dan Teknologi Nasional. Tingkat keamanan yang disediakan TLS paling dipengaruhi oleh versi protokol TLS dan suite sandi yang didukung.

Suite sandi adalah sekumpulan algoritma yang mencakup sandi, algoritma pertukaran kunci, dan algoritma hash. Mereka digunakan bersama-sama untuk membuat koneksi TLS yang aman. Sebagian besar klien dan server TLS mendukung beberapa alternatif. Mereka harus bernegosiasi ketika mereka membuat koneksi yang aman untuk memilih versi TLS umum dan cipher suite.

Azure Database for PostgreSQL mendukung TLS versi 1.2 dan yang lebih baru. Dalam 8996, Internet Engineering Task Force (IETF) secara eksplisit menyatakan bahwa TLS 1.0 dan TLS 1.1 tidak boleh digunakan. Kedua protokol tersebut tidak digunakan lagi pada akhir 2019.

Semua koneksi masuk yang menggunakan versi protokol TLS yang lebih lama, seperti TLS 1.0 dan TLS 1.1, ditolak secara default.

IETF merilis spesifikasi TLS 1.3 di RFC 8446 pada Agustus 2018, dan TLS 1.3 sekarang menjadi versi TLS yang paling umum dan direkomendasikan yang digunakan. TLS 1.3 lebih cepat dan lebih aman daripada TLS 1.2.

Catatan

Sertifikat SSL dan TLS menyatakan bahwa koneksi Anda diamankan dengan protokol enkripsi canggih. Dengan mengenkripsi koneksi Anda melalui kabel, Anda mencegah akses tidak sah ke data Anda saat transit. Kami sangat menyarankan Anda menggunakan TLS versi terbaru untuk mengenkripsi koneksi Anda ke server fleksibel Azure Database for PostgreSQL.

Meskipun kami tidak merekomendasikannya, jika diperlukan, Anda dapat menonaktifkan TLS\SSL untuk koneksi ke server fleksibel Azure Database for PostgreSQL. Anda dapat memperbarui require_secure_transport parameter server ke OFF. Anda juga dapat mengatur versi TLS dengan mengatur ssl_min_protocol_version dan ssl_max_protocol_version parameter server.

Autentikasi sertifikat dilakukan dengan menggunakan sertifikat klien SSL untuk autentikasi. Dalam skenario ini, server PostgreSQL membandingkan atribut nama umum (CN) sertifikat klien yang disajikan terhadap pengguna database yang diminta.

Saat ini, server fleksibel Azure Database for PostgreSQL tidak mendukung:

Autentikasi berbasis sertifikat SSL.
Sertifikat SSL\TLS kustom.

Catatan

Microsoft membuat perubahan CA akar untuk berbagai layanan Azure, termasuk server fleksibel Azure Database for PostgreSQL. Untuk informasi selengkapnya, lihat Perubahan sertifikat Azure TLS dan bagian Mengonfigurasi SSL pada klien.

Untuk menentukan status koneksi TLS\SSL Anda saat ini, Anda dapat memuat ekstensi sslinfo lalu memanggil ssl_is_used() fungsi untuk menentukan apakah SSL sedang digunakan. Fungsi mengembalikan t jika koneksi menggunakan SSL. Jika tidak, ia kembali f. Anda juga dapat mengumpulkan semua informasi tentang penggunaan SSL server fleksibel Azure Database for PostgreSQL berdasarkan proses, klien, dan aplikasi dengan menggunakan kueri berikut:

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Untuk pengujian, Anda juga dapat menggunakan perintah secara openssl langsung:

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

Perintah ini mencetak informasi protokol tingkat rendah, seperti versi TLS dan cipher. Anda harus menggunakan opsi -starttls postgres. Jika tidak, perintah ini melaporkan bahwa tidak ada SSL yang digunakan. Menggunakan perintah ini memerlukan setidaknya OpenSSL 1.1.1.

Untuk menerapkan versi TLS terbaru yang paling aman untuk perlindungan konektivitas dari klien ke server fleksibel Azure Database for PostgreSQL, atur ssl_min_protocol_version ke 1.3. Pengaturan tersebut mengharuskan klien yang tersambung ke server fleksibel Azure Database for PostgreSQL Anda untuk menggunakan versi protokol ini hanya untuk berkomunikasi dengan aman. Klien lama mungkin tidak dapat berkomunikasi dengan server karena mereka tidak mendukung versi ini.

Mengonfigurasi SSL pada klien

Secara default, PostgreSQL tidak melakukan verifikasi sertifikat server apa pun. Untuk alasan ini, dimungkinkan untuk memalsukan identitas server (misalnya, dengan memodifikasi catatan DNS atau dengan mengambil alih alamat IP server) tanpa diketahui klien. Semua opsi SSL membawa overhead dalam bentuk enkripsi dan pertukaran kunci, sehingga trade-off dilakukan antara performa dan keamanan.

Untuk mencegah spoofing, verifikasi sertifikat SSL pada klien harus digunakan.

Ada banyak parameter koneksi untuk mengonfigurasi klien untuk SSL. Beberapa yang penting adalah:

ssl: Sambungkan menggunakan SSL. Properti ini tidak memerlukan nilai yang terkait dengannya. Kehadirannya saja menentukan koneksi SSL. Untuk kompatibilitas dengan versi mendatang, nilainya true lebih disukai. Dalam mode ini, saat Anda membuat koneksi SSL, driver klien memvalidasi identitas server untuk mencegah serangan man-in-the-middle. Ini memeriksa bahwa sertifikat server ditandatangani oleh otoritas tepercaya dan bahwa host yang Anda sambungkan sama dengan nama host dalam sertifikat.

sslmode: Jika Anda memerlukan enkripsi dan ingin koneksi gagal jika tidak dapat dienkripsi, atur sslmode=require. Pengaturan ini memastikan bahwa server dikonfigurasi untuk menerima koneksi SSL untuk alamat host/IP ini dan bahwa server mengenali sertifikat klien. Jika server tidak menerima koneksi SSL atau sertifikat klien tidak dikenali, koneksi gagal. Tabel berikut ini mencantumkan nilai untuk pengaturan ini:

Modus SSL	Penjelasan
`disable`	Enkripsi tidak digunakan.
`allow`	Enkripsi digunakan jika pengaturan server memerlukan atau menerapkannya.
`prefer`	Enkripsi digunakan jika pengaturan server memungkinkannya.
`require`	Enkripsi digunakan. Ini memastikan bahwa server dikonfigurasi untuk menerima koneksi SSL untuk alamat IP host ini dan bahwa server mengenali sertifikat klien.
`verify-ca`	Enkripsi digunakan. Verifikasi tanda tangan sertifikat server terhadap sertifikat yang disimpan pada klien.
`verify-full`	Enkripsi digunakan. Verifikasi tanda tangan sertifikat server dan nama host terhadap sertifikat yang disimpan pada klien.

Mode default sslmode yang digunakan berbeda antara klien berbasis libpq (seperti psql) dan JDBC. Klien berbasis libpq default ke prefer. Klien JDBC default ke verify-full.

sslcert, , sslkey, dan sslrootcert: Parameter ini dapat mengambil alih lokasi default sertifikat klien, kunci klien PKCS-8, dan sertifikat akar. Mereka default ke /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8, dan /defaultdir/root.crt, masing-masing, di mana defaultdir berada ${user.home}/.postgresql/ dalam sistem nix dan %appdata%/postgresql/ di Windows.

CA adalah institusi yang bertanggung jawab untuk menerbitkan sertifikat. Otoritas sertifikat tepercaya adalah entitas yang berhak memverifikasi bahwa seseorang adalah orang yang mereka katakan. Agar model ini berfungsi, semua peserta harus menyetujui serangkaian CA tepercaya. Semua sistem operasi dan sebagian besar browser web dikirim dengan sekumpulan CA tepercaya.

Menggunakan verify-ca pengaturan konfigurasi dan verify-fullsslmode juga dapat dikenal sebagai penyematan sertifikat. Dalam hal ini, sertifikat OS akar di server PostgreSQL harus cocok dengan tanda tangan sertifikat dan bahkan nama host terhadap sertifikat pada klien.

Anda mungkin perlu memperbarui sertifikat yang disimpan klien secara berkala saat CA berubah atau kedaluwarsa pada sertifikat server PostgreSQL. Untuk menentukan apakah Anda menyematkan CA, lihat Penyematan sertifikat dan layanan Azure.

Untuk informasi selengkapnya tentang konfigurasi SSL\TLS pada klien, lihat dokumentasi PostgreSQL.

Untuk klien yang menggunakan verify-ca pengaturan verify-fullsslmode konfigurasi (yaitu, penyematan sertifikat), mereka harus menyebarkan tiga sertifikat OS akar ke penyimpanan sertifikat klien:

Sertifikat CA akar CA 2017 DigiCert Global Root G2 dan Microsoft RSA Root, karena layanan bermigrasi dari Digicert ke Microsoft CA.
Digicert Global Root CA, untuk kompatibilitas warisan.

Mengunduh sertifikat OS akar dan memperbarui klien aplikasi dalam skenario penyematan sertifikat

Untuk memperbarui aplikasi klien dalam skenario penyematan sertifikat, Anda dapat mengunduh sertifikat:

Untuk mengimpor sertifikat ke penyimpanan sertifikat klien, Anda mungkin harus mengonversi file .crt sertifikat ke format .pem setelah Mengunduh file sertifikat dari URI sebelumnya. Anda dapat menggunakan utilitas OpenSSL untuk melakukan konversi file ini:

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

Informasi tentang memperbarui penyimpanan sertifikat aplikasi klien dengan sertifikat OS akar baru didokumenkan dalam Memperbarui sertifikat TLS klien untuk klien aplikasi.

Penting

Beberapa pustaka klien Postgres, saat menggunakan sslmode=verify-full pengaturan, mungkin mengalami kegagalan koneksi dengan sertifikat CA akar yang ditandatangani silang dengan sertifikat perantara. Hasilnya adalah jalur kepercayaan alternatif. Dalam hal ini, kami sarankan Anda menentukan sslrootcert parameter secara eksplisit. Atau, atur PGSSLROOTCERT variabel lingkungan ke jalur lokal tempat sertifikat CA akar CA 2017 Akar Microsoft RSA ditempatkan, dari nilai %APPDATA%\postgresql\root.crtdefault .

Membaca replika dengan skenario penyematan sertifikat

Dengan migrasi CA akar ke Microsoft RSA Root CA 2017, memungkinkan replika yang baru dibuat berada pada sertifikat OS akar yang lebih baru daripada server utama yang dibuat sebelumnya. Untuk klien yang menggunakan verify-ca pengaturan verify-fullsslmode konfigurasi (yaitu, penyematan sertifikat), sangat penting bagi konektivitas yang terganggu untuk menerima tiga sertifikat OS akar:

Saat ini, server fleksibel Azure Database for PostgreSQL tidak mendukung autentikasi berbasis sertifikat.

Menguji sertifikat klien dengan menyambungkan dengan psql dalam skenario penyematan sertifikat

Anda dapat menggunakan psql baris perintah dari klien Anda untuk menguji konektivitas ke server dalam skenario penyematan sertifikat:


$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Untuk informasi selengkapnya tentang parameter SSL dan sertifikat, lihat dokumentasi psql.

Menguji konektivitas TLS/SSL

Sebelum Anda mencoba mengakses server yang didukung SSL dari aplikasi klien, pastikan Anda bisa mengaksesnya melalui psql. Jika Anda membuat koneksi SSL, Anda akan melihat output yang mirip dengan contoh berikut:

koneksi psql (14.5)SSL (protokol: TLSv1.2, sandi: ECDHE-RSA-AES256-GCM-SHA384, bit: 256, kompresi: off)Ketik "bantuan" untuk bantuan.

Anda juga dapat memuat ekstensi sslinfo lalu memanggil ssl_is_used() fungsi untuk menentukan apakah SSL sedang digunakan. Fungsi mengembalikan t jika koneksi menggunakan SSL. Jika tidak, ia kembali f.

Cipher suite

Rangkaian sandi adalah sekumpulan algoritma kriptografi. Protokol TLS/SSL menggunakan algoritma dari cipher suite untuk membuat kunci dan mengenkripsi informasi.

Rangkaian sandi ditampilkan sebagai string panjang informasi yang tampaknya acak, tetapi setiap segmen string tersebut berisi informasi penting. Umumnya, string data ini mencakup beberapa komponen utama:

Protokol (yaitu, TLS 1.2 atau TLS 1.3)
Pertukaran kunci atau algoritma perjanjian
Algoritma tanda tangan digital (autentikasi)
Algoritma enkripsi massal
Algoritma kode autentikasi pesan (MAC)

Versi TLS/SSL yang berbeda mendukung suite sandi yang berbeda. Suite sandi TLS 1.2 tidak dapat dinegosiasikan dengan koneksi TLS 1.3, dan sebaliknya.

Saat ini, server fleksibel Azure Database for PostgreSQL mendukung banyak cipher suite dengan versi protokol TLS 1.2 yang termasuk dalam kategori HIGH:!aNULL .

Memecahkan masalah kesalahan konektivitas TLS/SSL

Langkah pertama untuk memecahkan masalah kompatibilitas versi protokol TLS/SSL adalah mengidentifikasi pesan kesalahan yang Anda atau pengguna Anda lihat saat mereka mencoba mengakses server fleksibel Azure Database for PostgreSQL di bawah enkripsi TLS dari klien. Tergantung pada aplikasi dan platform, pesan kesalahan mungkin berbeda. Dalam banyak kasus, mereka menunjuk ke masalah yang mendasar.
Untuk memastikan kompatibilitas versi protokol TLS/SSL, periksa konfigurasi TLS/SSL server database dan klien aplikasi untuk memastikan mereka mendukung versi yang kompatibel dan cipher suite.
Analisis perbedaan atau kesenjangan antara server database dan versi TLS/SSL klien dan cipher suite. Cobalah untuk mengatasinya dengan mengaktifkan atau menonaktifkan opsi tertentu, meningkatkan atau menurunkan perangkat lunak, atau mengubah sertifikat atau kunci. Misalnya, Anda mungkin perlu mengaktifkan atau menonaktifkan versi TLS/SSL tertentu di server atau klien, tergantung pada persyaratan keamanan dan kompatibilitas. Misalnya, Anda mungkin perlu menonaktifkan TLS 1.0 dan TLS 1.1, yang dianggap tidak aman dan tidak digunakan lagi, dan mengaktifkan TLS 1.2 dan TLS 1.3, yang lebih aman dan modern.
Sertifikat terbaru yang dikeluarkan dengan Microsoft RSA Root CA 2017 memiliki perantara dalam rantai yang ditandatangani silang oleh Digicert Global Root G2 CA. Beberapa pustaka klien Postgres, saat menggunakan sslmode=verify-full atau sslmode=verify-ca pengaturan, mungkin mengalami kegagalan koneksi dengan sertifikat CA akar yang ditandatangani silang dengan sertifikat perantara. Hasilnya adalah jalur kepercayaan alternatif.

Untuk mengatasi masalah ini, tambahkan ketiga sertifikat yang diperlukan ke penyimpanan sertifikat klien atau tentukan sslrootcert parameter secara eksplisit. Atau, atur PGSSLROOTCERT variabel lingkungan ke jalur lokal tempat sertifikat CA akar CA 2017 Akar Microsoft RSA ditempatkan, dari nilai %APPDATA%\postgresql\root.crtdefault .

Pelajari cara membuat server fleksibel Azure Database for PostgreSQL dengan menggunakan opsi Akses privat (integrasi VNet) di portal Azure atau Azure CLI.
Pelajari cara membuat server fleksibel Azure Database for PostgreSQL dengan menggunakan opsi Akses publik (alamat IP yang diizinkan) di portal Azure atau Azure CLI.

Bagikan melalui