Gesaan dan skop
Satu pasukan merancang untuk menaik taraf daripada PostgreSQL 18 ke PostgreSQL 19. Kluster semasa menggunakan RADIUS dan beberapa pengesahan kata laluan MD5; klien termasuk aplikasi, skrip operasi dan alatan BI. Terangkan cara anda menginventori kebergantungan, memilih penggantian, mengesahkan klien dan menentukan syarat henti.
Notis Beta rasmi PostgreSQL menerangkan pratonton ciri pra-pelepasan dan menasihatkan agar tidak menggunakannya secara langsung dalam pengeluaran (production). Nota migrasi versi 19 mengalih keluar sokongan RADIUS dan mengeluarkan amaran selepas pengesahan MD5 berjaya; RADIUS hanya disokong melalui UDP, yang disifatkan oleh projek tersebut sebagai tidak selamat dan tidak boleh diperbaiki. Soalan ini menguji migrasi pengesahan berasaskan bukti, tanpa menganggap setiap persekitaran terjejas.
Perkara yang dinilai oleh penemu duga
Penemu duga mahu anda mengasingkan penyingkiran protokol, format kata laluan dan keupayaan klien; membina inventori kebergantungan yang lengkap; serta mentakrifkan penggantian keistimewaan paling sedikit (least-privilege), pelancaran yang boleh diperhatikan (observable) dan pengunduran (rollback). Jawapan yang kukuh juga menyatakan bahawa keputusan Beta bukan komitmen versi akhir dan tidak menyalahertikan amaran MD5 sebagai sekatan sambungan serta-merta.
Soalan penjelasan sebelum menjawab
- Apakah versi PostgreSQL semasa dan sasaran, dan bilakah pelepasan akhir dijangkakan?
- Titik masuk manakah yang menggunakan RADIUS, dan pengguna atau sambungan manakah yang masih menggunakan MD5?
- Adakah pemacu (drivers), kolam sambungan (pools) dan alatan operasi menyokong SCRAM, sijil atau proksi identiti?
- Bagaimanakah pelayan pengesahan, laluan rangkaian, keperluan audit, failover dan akaun kecemasan diuruskan?
- Apakah masa henti (outage time), tetingkap pengunduran dan pemilik keselamatan yang tersedia?
Kerangka jawapan 30 saat
"Saya akan menganggap Beta sebagai sasaran pengesahan yang terpencil. Mula-mula, saya akan menginventori setiap peraturan pg_hba.conf, format kata laluan, klien dan kebergantungan RADIUS, kemudian mengesahkan SCRAM, sijil atau proksi identiti terkawal pada kluster ujian PostgreSQL 19. Saya akan memastikan laluan lama dan baharu tersedia untuk identiti yang sama semasa memainkan semula sambungan, failover dan senario audit, kemudian memigrasikan penyewa (tenants) berisiko rendah terlebih dahulu sambil memerhatikan kegagalan pengesahan, kependaman (latency) dan jurang audit. Sebarang kegagalan log masuk, peluasan keistimewaan, kehilangan audit atau kegagalan pengunduran akan menghentikan pelancaran, dengan kluster lama dan laluan pengesahan dikekalkan."
Jawapan mendalam langkah demi langkah
1. Membina inventori kebergantungan
Eksport dan semak pg_hba.conf, atribut peranan, storan kata laluan, sumber sambungan, versi klien, kolam sambungan dan skrip automasi. Tandakan RADIUS, MD5, SCRAM, sijil dan proksi luaran secara berasingan; rekod pengguna, rangkaian, pangkalan data, keutamaan peraturan dan pemilik bagi setiap peraturan. Jangan hanya mencari dalam repositori aplikasi: skrip sementara dan alatan BI juga mungkin memegang kelayakan sambungan.
2. Mengasingkan penyingkiran daripada amaran
Nota migrasi PostgreSQL 19 mengalih keluar RADIUS; pengesahan MD5 yang berjaya menghasilkan amaran klien yang boleh dikawal dengan md5_password_warnings. Amaran menandakan kerja migrasi; ia tidak bermakna sambungan semasa telah ditolak serta-merta. Gantikan kebergantungan RADIUS sebelum peningkatan, dan jadualkan migrasi kata laluan serta peraturan untuk kebergantungan MD5 dan bukannya menganggap risikonya adalah sama.
3. Memilih penggantian dan mengehadkan keistimewaan
Nilai SCRAM-SHA-256, sijil klien atau proksi identiti perusahaan sedia ada, berdasarkan sokongan klien, kitaran hayat kunci, sempadan rangkaian dan keperluan audit. Cipta akaun migrasi keistimewaan paling sedikit yang berjangka hayat pendek, jangan sesekali menggunakan superuser yang dikongsi; asingkan akaun lama dan baharu serta tetapkan tempoh luput dan pemilikan. Reka bentuk mesti meliputi failover, replika baca sahaja, akaun kecemasan operasi (break-glass) dan pemulihan luar talian.
4. Mengesahkan matriks sambungan dalam pengasingan
Cipta semula topologi pengeluaran dengan data yang dinyahkenal pasti dan kelayakan berasingan. Uji aplikasi, kolam sambungan, alatan migrasi, pemulihan sandaran (backup restore), pemantauan dan failover satu demi satu. Tetapkan versi pemacu bagi setiap klien dan rekod kaedah pengesahan, TLS, masa sambungan, sebab kegagalan dan peristiwa audit. Adalah munasabah untuk mengekalkan laluan log masuk lama dan baharu untuk satu peranan semasa ujian, tetapi kelayakan ujian tidak boleh sesekali masuk ke persekitaran pengeluaran.
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. Mereka bentuk canary, pintu kawalan (gates) dan pengunduran
Pindahkan penyewa berisiko rendah atau tugas tidak kritikal terlebih dahulu. Tetapkan ambang untuk kegagalan pengesahan, kependaman sambungan, kejayaan tetapan semula kata laluan, kelengkapan audit dan kejayaan failover; hentikan jika berlaku peluasan keistimewaan, kegagalan log masuk, jurang audit atau kegagalan pemulihan. Simpan salinan PostgreSQL 18 yang boleh dibut, versi peraturan lama, rekod giliran kata laluan dan skrip pengunduran, serta sahkan bahawa klien lama boleh dipulihkan dalam tetingkap pengunduran.
6. Merekod ketidaktentuan Beta
Tingkah laku dan antara muka Beta masih boleh berubah. Tulis kesimpulan sebagai hasil untuk klien, konfigurasi pengesahan dan set data ujian yang dinyatakan; rekod versi, cincangan (hash) konfigurasi dan isu yang diketahui, kemudian dapatkan kelulusan akhir selepas pelepasan versi akhir. Kluster ujian yang berjaya tidak membuktikan keserasian untuk setiap klien.
Contoh jawapan berkualiti tinggi
Saya akan membekukan garis dasar pengesahan PostgreSQL 18 dan membina matriks pg_hba.conf, peranan, klien dan kebergantungan RADIUS mengikut titik masuk dan pemilik. Oleh kerana PostgreSQL 19 mengalih keluar RADIUS, saya akan mengesahkan SCRAM, sijil atau proksi identiti perusahaan untuk identiti yang terjejas dalam kluster terpencil, sambil mengendalikan baki pengguna MD5 secara berasingan; amaran kejayaan MD5 menandakan kerja migrasi tetapi bukan penolakan menyeluruh. Saya akan memainkan semula aplikasi, kolam sambungan, skrip, pemulihan sandaran dan failover sambil memerhatikan kegagalan, kependaman, audit dan sempadan keistimewaan. Hanya selepas canary berisiko rendah melepasi setiap pintu kawalan barulah saya mengembangkannya; peluasan keistimewaan, kehilangan audit, kegagalan log masuk atau kegagalan pengunduran akan menghentikan pelancaran. Bukti Beta kekal sebagai input kepada kelulusan versi akhir.
Kesilapan lazim
- Menganggap penyingkiran RADIUS dan amaran MD5 sebagai peristiwa yang sama → satu mengalih keluar sokongan, satu lagi menandakan migrasi → inventori dan rancang secara berasingan.
- Hanya menukar
pg_hba.conftanpa menguji klien → pemacu dan kolam sambungan mungkin tiada sokongan → mainkan semula matriks klien yang lengkap. - Menggilirkan semua kata laluan pengeluaran sekali gus → ruang kegagalan dan permukaan pengunduran terlalu besar → asingkan, gunakan akaun sementara dengan keistimewaan paling sedikit dan migrasikan secara kelompok (batch).
- Mengabaikan akaun kecemasan (break-glass) → gangguan mungkin mengalih keluar akses pemulihan → sediakan akses kecemasan yang terkawal dan diaudit.
- Membentangkan kejayaan Beta sebagai jaminan keserasian muktamad → tingkah laku pra-pelepasan boleh berubah → rekod sempadan dan luluskan semula versi akhir.
Soalan susulan dan respons
Bilakah peningkatan mesti dihentikan?
Hentikan jika berlaku kegagalan log masuk, peluasan keistimewaan, jurang audit, ketidakserasian klien kritikal, kegagalan failover atau pengunduran yang tidak dapat diselesaikan dalam tetingkap masa.
Mengapakah tidak menggantikan RADIUS dengan sebarang kaedah kata laluan?
Kekuatan pengesahan, kitaran hayat kunci, sempadan rangkaian dan keperluan audit adalah berbeza. Penggantian mesti memenuhi dasar keselamatan dan meliputi klien serta senario kegagalan.
Adakah amaran MD5 bermakna memutuskan sambungan setiap pengguna MD5 serta-merta?
Tidak. Amaran tersebut mendedahkan laluan yang masih memerlukan migrasi. Kenal pasti klien, gilirkan kelayakan, sahkan SCRAM, sijil atau proksi, dan tukar secara berkelompok.
Bagaimanakah anda membuktikan tiada klien tersembunyi yang terlepas?
Korelasikan log sambungan, rekod audit, penggunaan peranan, sumber rangkaian, carian repositori dan temu bual operasi dalam tetingkap masa tetap; pantau sumber yang tidak diketahui dan kegagalan pengesahan sebelum dan selepas migrasi.
Bilakah perubahan yang diuji dalam Beta boleh memasuki pengeluaran?
Selepas pelepasan akhir, pengesahan versi baharu dan matriks klien, latihan pengunduran dan audit yang berjaya, serta kelulusan bersama daripada pemilik keselamatan, pangkalan data dan perniagaan, diikuti oleh canary yang boleh diperhatikan.