Bagikan melalui

Konektivitas aman dengan TLS di Azure Database for PostgreSQL

Azure Database for PostgreSQL memberlakukan menghubungkan aplikasi klien Anda ke instans 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 Anda. TLS adalah protokol terbaru dari Secure Sockets Layer (SSL). Istilah SSL dan TLS masih digunakan secara bergantian.

Penting

Mulai 11 November 2025, wilayah Azure dalam daftar berikut direncanakan untuk rotasi sertifikat TLS/SSL yang menggunakan sertifikat CA menengah baru.

  • Barat Sentral AS
  • Asia Timur
  • UK Selatan

Mulai 19 Januari 2026, rotasi ini direncanakan akan meluas ke semua wilayah Azure yang tersisa, termasuk Azure Government dan semua wilayah lainnya.

Untuk informasi tentang pemecahan masalah, lihat Masalah penyematan sertifikat.

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. Di 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 RFC 8996, Internet Engineering Task Force (IETF) secara eksplisit menyatakan bahwa TLS 1.0 dan TLS 1.1 tidak boleh digunakan. Kedua protokol 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.

Nota

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

Meskipun kami tidak merekomendasikannya, jika diperlukan, Anda dapat menonaktifkan TLS\SSL untuk koneksi ke instans server fleksibel Azure Database for PostgreSQL Anda. 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, Azure Database for PostgreSQL tidak mendukung:

Nota

Microsoft membuat perubahan CA akar untuk berbagai layanan Azure, termasuk 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 mengembalikan f. Anda juga dapat mengumpulkan semua informasi tentang penggunaan SSL instans 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 instans server fleksibel Azure Database for PostgreSQL, atur ssl_min_protocol_version ke 1.3. Pengaturan tersebut mengharuskan klien yang tersambung ke instans 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:

    Mode SSL Explanation
    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/ di sistem Linux 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:

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 .

  1. Mengalami hilangnya konektivitas dari aplikasi klien ke instans server fleksibel Azure Database for PostgreSQL - tiket dukungan dibuka.
  2. Jika sertifikat perantara Anda diubah, Anda mungkin perlu memperbarui penyimpanan sertifikat untuk klien Anda dengan sertifikat perantara yang baru.
  3. cara memeriksa untuk melihat apakah Anda menyematkan sertifikat perantara Anda - lihat Penyematan sertifikat dan layanan Azure.

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, 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 mengembalikan f.

Suite sandi

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, Azure Database for PostgreSQL mendukung banyak suite sandi dengan versi protokol TLS 1.2 yang termasuk dalam kategori HIGH:!aNULL .

Troubleshoot

Gunakan panduan di bagian Pemecahan Masalah ini untuk mengidentifikasi dan menyelesaikan masalah TLS/SSL umum dengan cepat. Mulailah dengan mereproduksi masalah dan mengumpulkan data diagnostik (pesan kesalahan sisi klien, output psql, output s_client OpenSSL, dan log server), lalu verifikasi parameter server (require_secure_transport, ssl_min_protocol_version, ssl_max_protocol_version), rantai sertifikat, dan pengaturan sslmode/sslrootcert klien untuk menentukan ketidakcocokan dalam versi protokol, suite sandi, atau sertifikat yang hilang/diputar.

Kesalahan konektivitas TLS/SSL

  1. Langkah pertama untuk memecahkan masalah kompatibilitas versi protokol TLS/SSL adalah mengidentifikasi pesan kesalahan yang Anda atau pengguna Anda lihat saat mereka mencoba mengakses instans 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.
  2. 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.
  3. 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.
  4. 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 .

Masalah penyematan sertifikat

Nota

Jika Anda tidak menggunakan pengaturan sslmode=verify-full atau sslmode=verify-ca dalam string koneksi aplikasi klien Anda, maka rotasi sertifikat tidak memengaruhi Anda. Oleh karena itu, Anda tidak perlu mengikuti langkah-langkah di bagian ini.

  1. Verifikasi apakah Anda menggunakan penyematan sertifikat di aplikasi Anda.
  2. Buat daftar sertifikat Anda yang ada di penyimpanan root tepercaya Anda
    1. Misalnya, Anda bisa mendapatkan daftar sertifikat tepercaya di Java Key Store secara terprogram.
    2. Misalnya, Anda dapat memeriksa keystore java cacert untuk melihat apakah sudah berisi sertifikat yang diperlukan.
  3. Anda menggunakan penyematan sertifikat, jika Anda memiliki sertifikat perantara individual atau sertifikat server PostgreSQL individual.
  4. Untuk menghapus penyematan sertifikat, hapus semua sertifikat dari penyimpanan akar tepercaya Anda dan tambahkan sertifikat baru.
    1. Anda dapat mengunduh sertifikat yang diperbarui dari repositori resmi Microsoft: Detail Otoritas Sertifikat Azure.
      1. Rantai saat ini:
        1. DigiCert Global Root G2
        2. Microsoft Azure RSA TLS Mengeluarkan CA 03 / 04 / 07 / 08
      2. Rantai baru
        1. DigiCert Global Root G2
        2. Microsoft TLS RSA Root G2
        3. Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16

Jika Anda mengalami masalah bahkan setelah mengikuti langkah-langkah ini, hubungi dukungan Microsoft. Sertakan dalam judul Rotasi ICA 2026.

Konten terkait

  • Last updated on