Rotasyon önce envanter ister
Bir kimlik bilgisini değiştirmeden önce nerede kullanıldığını bilmeniz gerekir. Uygulama runtime, worker, CI/CD, BI aracı, migration jobu ve geliştirici ortamı aynı kullanıcıyı paylaşıyorsa rotasyon operasyonu gereksiz yere büyür.
Bu yüzden en iyi güvenlik yatırımı çoğu zaman şifreyi daha karmaşık yapmak değil, kimlik bilgisini küçük parçalara bölmektir. app_rw, bi_readonly, migration_admin gibi kullanıcılar rotasyonu daha az korkutucu hale getirir.
- Her kimlik bilgisinin sahibi, kullanım yeri ve amacı yazılı olmalı.
- Uygulama kullanıcısı ile migration/admin kullanıcısı ayrılmalı.
- BI ve destek erişimi salt okunur kalmalı.
- Eski kimlik bilgisini kapatmadan önce yeni kimlik bilgisiyle canlı trafik doğrulanmalı.
Kesintisiz yöntem: yeniyi ekle, trafiği taşı, eskiyi kapat
Rotasyonda en güvenli sıra genellikle şudur: yeni kullanıcı veya key oluşturulur, uygulama gizli değeri güncellenir, uygulama yeniden bağlanır, metrikler izlenir, sonra eski kimlik bilgisi kapatılır. Eskiyi önce kapatmak, hangi servisin unutulduğunu kullanıcıya buldurur.
Bu akış özellikle çok podlu uygulamalarda önemlidir. Bazı podlar yeni gizli değeri almışken bazıları eski bağlantıyı tutabilir. Bu nedenle rotasyon sonrası connection error, auth failed ve pool reconnect sinyalleri izlenmelidir.
TürkDB ile yeni veritabanı kullanıcısı oluşturma
turkdb cluster users list app-pg turkdb cluster users create app-pg --username app_rw_202606 --role readwrite # Uygulama gizli değeri/env yeni kullanıcıya geçirilir. # Trafik ve auth hataları izlendikten sonra eski kullanıcı kapatılır. turkdb cluster users delete app-pg <old-user-id>
Amaç tek komutla şifre değiştirmek değil, eski ve yeni kimlik bilgisinin kısa süre kontrollü birlikte yaşayabildiği güvenli bir geçiş yapmaktır.
Rotasyon sırasında hangi sinyaller izlenir?
Rotasyon başarılı görünse bile bazı arka plan işleri eski kimlik bilgisini kullanmaya devam edebilir. Özellikle cron job, queue worker, raporlama entegrasyonu ve migration pipeline unutulmaya yatkındır.
Bu yüzden rotasyonu sadece yayına alma olarak değil, kısa bir gözlem penceresi olarak düşünün. Auth failed sayısı, connection retry, 5xx oranı ve uygulamanın kritik iş akışları kontrol edilir.
- Yeni kimlik bilgisiyle okuma/yazma temel doğrulama testi geçti mi?
- Auth failed logları rotasyon sonrası sıfıra indi mi?
- Eski kimlik bilgisini kullanan servis kaldı mı?
- Secret manager, CI/CD ve runtime aynı değeri mi görüyor?
Sızıntı şüphesinde normal rotasyon yetmez
Bir kimlik bilgisinin sızdığından şüpheleniyorsanız rahat tempolu rotasyon yerine daha dar bir olay akışı gerekir. Erişim kaynağı, izin listesi, denetim kayıtları ve son başarılı bağlantılar birlikte okunur.
TürkDB için hedef, kullanıcı listesi, izin listesi durumu ve olay kayıtlarını aynı cluster bağlamında gösterebilmektir. Ama karar yine iş bağlamıyla verilir: önce erişimi daraltmak mı, uygulamayı yeni kimlik bilgisine geçirmek mi, eski anahtarı hemen kesmek mi?