Konteks dan cakupan
Sebuah tim berencana meningkatkan dari PostgreSQL 18 ke PostgreSQL 19. Kluster saat ini menggunakan RADIUS dan beberapa autentikasi kata sandi MD5; klien mencakup aplikasi, skrip operasional, dan alat BI. Jelaskan bagaimana Anda menginventarisasi dependensi, memilih pengganti, memvalidasi klien, dan menentukan kondisi henti.
Pemberitahuan resmi Beta PostgreSQL menjelaskan pratinjau fitur pra-rilis dan menyarankan agar tidak digunakan langsung di lingkungan produksi. Catatan migrasi versi 19 menghapus dukungan RADIUS dan mengeluarkan peringatan setelah autentikasi MD5 berhasil; RADIUS hanya didukung melalui UDP, yang digambarkan oleh proyek tersebut sebagai tidak aman dan tidak dapat diperbaiki. Pertanyaan ini menguji migrasi autentikasi berbasis bukti, tanpa berasumsi bahwa setiap lingkungan terpengaruh.
Apa yang dinilai oleh pewawancara
Pewawancara ingin Anda memisahkan penghapusan protokol, format kata sandi, dan kapabilitas klien; membangun inventaris dependensi yang lengkap; serta mendefinisikan pengganti berprinsip hak akses terendah (least-privilege), peluncuran yang dapat diamati (observable), dan rollback. Jawaban yang kuat juga menyatakan bahwa hasil Beta bukanlah komitmen versi final dan tidak salah mengartikan peringatan MD5 sebagai pemblokiran koneksi langsung.
Pertanyaan klarifikasi sebelum menjawab
- Berapa versi PostgreSQL saat ini dan versi target, serta kapan rilis final diharapkan?
- Titik masuk mana yang menggunakan RADIUS, dan pengguna atau koneksi mana yang masih menggunakan MD5?
- Apakah driver, pool, dan alat operasional mendukung SCRAM, sertifikat, atau proksi identitas?
- Bagaimana server autentikasi, jalur jaringan, persyaratan audit, failover, dan akun darurat dikelola?
- Berapa waktu henti (outage time), jendela rollback, dan siapa pemilik keamanan yang tersedia?
Kerangka jawaban 30 detik
“Saya akan memperlakukan Beta sebagai target validasi yang terisolasi. Pertama, saya akan menginventarisasi setiap aturan pg_hba.conf, format kata sandi, klien, dan dependensi RADIUS, kemudian memvalidasi SCRAM, sertifikat, atau proksi identitas terkontrol pada kluster pengujian PostgreSQL 19. Saya akan mempertahankan jalur lama dan baru tetap tersedia untuk identitas yang sama selama pemutaran ulang (replay) koneksi, failover, dan skenario audit, lalu memigrasikan penyewa (tenant) berisiko rendah terlebih dahulu sambil memantau kegagalan autentikasi, latensi, dan celah audit. Setiap kegagalan login, eskalasi hak akses, hilangnya audit, atau kegagalan rollback akan menghentikan peluncuran, dengan kluster lama dan jalur autentikasi tetap dipertahankan.”
Jawaban mendalam langkah demi langkah
1. Membangun inventaris dependensi
Ekspor dan tinjau pg_hba.conf, atribut peran (role), penyimpanan kata sandi, sumber koneksi, versi klien, pool, dan skrip otomatisasi. Tandai RADIUS, MD5, SCRAM, sertifikat, dan proksi eksternal secara terpisah; catat pengguna, jaringan, basis data, prioritas aturan, dan pemilik untuk setiap aturan. Jangan hanya mencari di repositori aplikasi: skrip sementara dan alat BI mungkin juga menyimpan kredensial koneksi.
2. Memisahkan penghapusan dari peringatan
Catatan migrasi PostgreSQL 19 menghapus RADIUS; autentikasi MD5 yang berhasil menghasilkan peringatan klien yang dapat dikontrol dengan md5_password_warnings. Sebuah peringatan menandakan adanya pekerjaan migrasi; ini tidak berarti koneksi saat ini langsung ditolak. Ganti dependensi RADIUS sebelum pembaruan, dan jadwalkan migrasi kata sandi serta aturan untuk dependensi MD5 alih-alih menganggap risikonya identik.
3. Memilih pengganti dan membatasi hak akses
Evaluasi SCRAM-SHA-256, sertifikat klien, atau proksi identitas perusahaan yang ada, berdasarkan dukungan klien, siklus hidup kunci, batas jaringan, dan persyaratan audit. Buat akun migrasi berhak akses terendah yang berumur pendek, jangan pernah menggunakan superuser bersama; pisahkan akun lama dan baru serta tetapkan masa kedaluwarsa dan kepemilikan. Rancangan harus mencakup failover, replika baca-saja, akun darurat operasi (break-glass), dan pemulihan luring (offline).
4. Memvalidasi matriks koneksi secara terisolasi
Buat ulang topologi produksi dengan data yang dide-identifikasi dan kredensial terpisah. Uji aplikasi, pool, alat migrasi, pemulihan cadangan (backup restore), pemantauan, dan failover satu per satu. Tetapkan versi driver untuk setiap klien dan catat metode autentikasi, TLS, waktu koneksi, alasan kegagalan, dan peristiwa audit. Mempertahankan jalur login lama dan baru untuk satu peran selama pengujian adalah hal yang wajar, tetapi kredensial pengujian tidak boleh masuk ke produksi.
psql "host=pg19-test dbname=app user=app_scram sslmode=verify-full" -c 'select 1'
psql "host=pg19-test dbname=app user=app_cert sslmode=verify-full" -c 'select 1'5. Merancang canary, gerbang kendali (gates), dan rollback
Pindahkan penyewa berisiko rendah atau pekerjaan non-kritis terlebih dahulu. Tetapkan ambang batas untuk kegagalan autentikasi, latensi koneksi, keberhasilan reset kata sandi, kelengkapan audit, dan keberhasilan failover; hentikan jika terjadi eskalasi hak akses, kegagalan login, celah audit, atau kegagalan pemulihan. Simpan salinan PostgreSQL 18 yang dapat di-boot, versi aturan lama, catatan rotasi kata sandi, dan skrip rollback, serta verifikasi bahwa klien lama dapat pulih dalam jendela rollback.
6. Mencatat ketidakpastian Beta
Perilaku dan antarmuka Beta masih dapat berubah. Tulis kesimpulan sebagai hasil untuk klien, konfigurasi autentikasi, dan kumpulan data uji yang dinyatakan; catat versi, hash konfigurasi, dan masalah umum, lalu minta persetujuan akhir setelah rilis final. Kluster pengujian yang berhasil tidak membuktikan kompatibilitas untuk setiap klien.
Contoh jawaban berkualitas tinggi
Saya akan membekukan dasar pengukuran (baseline) autentikasi PostgreSQL 18 dan membangun matriks pg_hba.conf, peran, klien, dan dependensi RADIUS berdasarkan titik masuk dan pemilik. Karena PostgreSQL 19 menghapus RADIUS, saya akan memvalidasi SCRAM, sertifikat, atau proksi identitas perusahaan untuk identitas yang terpengaruh dalam kluster terisolasi, sambil menangani pengguna MD5 yang tersisa secara terpisah; peringatan keberhasilan MD5 menandakan pekerjaan migrasi tetapi bukan penolakan menyeluruh. Saya akan memutar ulang aplikasi, pool, skrip, pemulihan cadangan, dan failover sambil mengamati kegagalan, latensi, audit, dan batas hak akses. Hanya setelah canary berisiko rendah melewati setiap gerbang kendali, saya akan memperluasnya; eskalasi hak akses, hilangnya audit, kegagalan login, atau kegagalan rollback akan menghentikan peluncuran. Bukti Beta tetap menjadi masukan untuk persetujuan versi final.
Kesalahan umum
- Memperlakukan penghapusan RADIUS dan peringatan MD5 sebagai peristiwa yang sama → yang satu menghapus dukungan, yang lain menandakan migrasi → inventarisasi dan rencanakan secara terpisah.
- Hanya mengubah
pg_hba.conftanpa menguji klien → driver dan pool mungkin tidak memiliki dukungan → putar ulang matriks klien secara lengkap. - Memutar semua kata sandi produksi sekaligus → area kegagalan dan permukaan rollback terlalu besar → isolasi, gunakan akun sementara berhak akses terendah, dan migrasikan secara bertahap (batch).
- Mengabaikan akun darurat (break-glass) → pemadaman dapat menghilangkan akses pemulihan → siapkan akses darurat yang terkontrol dan diaudit.
- Menyajikan keberhasilan Beta sebagai jaminan kompatibilitas final → perilaku pra-rilis dapat berubah → catat batasan dan setujui kembali versi final.
Pertanyaan lanjutan dan respons
Kapan peningkatan harus dihentikan?
Hentikan jika terjadi kegagalan login, eskalasi hak akses, celah audit, ketidakcocokan klien kritis, kegagalan failover, atau rollback yang tidak dapat diselesaikan dalam jendela waktu.
Mengapa tidak mengganti RADIUS dengan metode kata sandi apa pun?
Kekuatan autentikasi, siklus hidup kunci, batasan jaringan, dan persyaratan audit berbeda-beda. Pengganti harus memenuhi kebijakan keamanan dan mencakup klien serta skenario kegagalan.
Apakah peringatan MD5 berarti memutuskan semua pengguna MD5 dengan segera?
Tidak. Peringatan tersebut menyoroti jalur yang masih memerlukan migrasi. Identifikasi klien, putar kredensial, validasi SCRAM, sertifikat, atau proksi, dan beralihlah secara bertahap.
Bagaimana Anda membuktikan tidak ada klien tersembunyi yang terlewat?
Korelasikan log koneksi, catatan audit, penggunaan peran, sumber jaringan, pencarian repositori, dan wawancara operasional selama jendela waktu tetap; pantau sumber yang tidak dikenal dan kegagalan autentikasi sebelum dan sesudah migrasi.
Kapan perubahan yang diuji di Beta dapat masuk ke produksi?
Setelah rilis final, validasi versi baru dan matriks klien, latihan rollback dan audit yang berhasil, serta persetujuan bersama dari pemilik keamanan, basis data, dan bisnis, diikuti oleh canary yang dapat diamati.