Postgres MD5'den SCRAM'a şifre geçişi RHEL sunucularında FIPS modunu açtı

Ne oldu

dev.to'da yayınlanan bir yazıya göre, bir ekibin UAT veritabanı sunucularını FIPS moduna geçirme girişimi ilk seferde etkili olmadı ve sorun işletim sistemi tarafında değildi. Sunucular Red Hat Enterprise Linux 9.5 çalıştırıyor ve FIPS gereksinimi Hindistan Merkez Bankası denetim maddesinden gelmişti, bu da onu isteğe bağlı değil zorunlu kılmıştı.

İlk etkinleştirme denemesinden sonra neden veritabanı katmanında ortaya çıktı: PostgreSQL örnekleri hâlâ FIPS moduyla uyumlu olmayan eski MD5 şifre hash yöntemini kullanıyordu. Bu uyumsuzluk giderilene kadar sunucular uyumluluk durumunu koruyamayacaktı.

Bahisin bir yapılandırma ayarından daha büyük olmasının nedeni

Bunlar bağımsız veritabanları değil. Ekibin UAT Keycloak kimlik sağlayıcısı bunlar üzerinde çalışıyor ve yazar, bir veritabanı kesintisinin ardından yaşanacak zincirlemeyi özetliyor: PostgreSQL düşerse Keycloak durur; Keycloak durursa BI katmanı olan Superset de onunla birlikte durur; ve Vault erişilemez olursa uygulama pod'ları CrashLoopBackOff durumunda takılı kalır. Dolayısıyla veritabanındaki bir şifre hash değişikliği, kimlik sağlayıcısının, analitik yığınının ve uygulamaların başlayabilmesi için ihtiyaç duyduğu sırlar altyapısının üstünde konumlanır.

Çözüm, doğru sırayla

Kritik kısmın sıralama olduğu ortaya çıktı; üç adım var:

• PostgreSQL'in şifre hash'lemesini MD5'den SCRAM'a geçirin.
• Mevcut şifreleri yeniden hash'leyin ve yeni şemayla yeniden ekleyin.
• FIPS'i yeniden etkinleştirin — bu kez tuttu.

Ortadaki adım ekipleri zorlayan adımdır. Hash yapılandırmasını değiştirmek yalnızca o noktadan sonra belirlenen şifreleri yönetir; hâlâ MD5 hash'i saklayan her rol, şifre sıfırlanana kadar onu korur. SCRAM-SHA-256, PostgreSQL'de sürüm 10'dan beri mevcut ve sürüm 14'ten beri yeni şifreler için varsayılan yöntem; ama uzun ömürlü cluster'lar, kimse sıfırlamayı zorlamazsa MD5 hash'lerini süresiz taşıyabilir. Yazar, geçiş tamamlandıktan sonra yazıda gösterilen etkinleştirme komutuyla (sudo fips enable) FIPS modunun etkin olduğunu doğruladığını bildiriyor.

Yazarın farklı yapacağı şeyler

Geriye dönük bakınca yazar, FIPS'i etkinleştirmeden önce, sonra değil, sunucudaki servislerin bağlı olduğu kimlik doğrulama ve kripto ayarlarının kontrol edilmesi gerektiğini yazıyor. Sunucu Keycloak, Superset ve Vault'un üstünde konumlandığında FIPS tek sunuculuk bir değişiklik değildir. Bu bağımlılık zincirini önce haritalamak, MD5'den SCRAM'a geçişi sonradan keşfedilen bir çözüm değil bir önkoşul olarak ortaya çıkarabilirdi.

Neden önemli

Uyum kaynaklı FIPS etkinleştirmesi regüle sektörlerde rutindir ve MD5 gibi izin verilmeyen algoritmaları sistemin kripto yığınından çıkarır. FIPS modundaki bir sunucuda PostgreSQL çalıştıran her ekip er ya da geç bu duvara çarpar ve bu hikaye aynı zamanda pratik bir kontrol listesi olarak da iş görür: FIPS'e dokunmadan önce şifre hash'lemeyi envanterleyin; saklanan hash'ler kendiliğinden göç etmediği için her rolün şifresini sıfırlamayı planlayın; ve bir veritabanı kimlik doğrulama değişikliğini altyapı değişikliği olarak görün, çünkü üstteki bir veritabanının etki alanı kimlik, BI ve sırlar araçlarına, o tek sunucunun çok ötesine ulaşır.