Tek kullanıcıyla başlamak normal, orada kalmak risklidir
İlk günlerde tek bir kullanıcıyla başlamak anlaşılırdır. Uygulama bağlanır, migration çalışır, geliştirici test eder. Sorun, bu düzenin üretime taşınıp yıllarca sürmesidir.
Bir kullanıcı fazla yetkiliyse hata da fazla yetkili olur. Yanlış çalışan script veri silebilir, raporlama aracı yazma yapabilir, sızan bir parola tüm veritabanını etkileyebilir. Least privilege kulağa güvenlik sloganı gibi gelir ama aslında hasarı sınırlama yöntemidir.
- Uygulama kullanıcısı günlük işini yapacak kadar yetkili olmalı.
- Raporlama/BI kullanıcısı varsayılan olarak salt okunur olmalı.
- Migration kullanıcısı geçici veya kontrollü kullanılmalı.
- Admin kullanıcı günlük uygulama trafiğinde kullanılmamalı.
- Acil erişim kullanıcı varsa erişimi ve kullanımı ayrıca kayıt altında olmalı.
Rol isimleri yetmez, kullanıcı amacı da görünmeli
app_rw, bi_readonly, migration_admin gibi isimler sıkıcı görünebilir; ama olay anında hayat kurtarır. Kullanıcı adı size o kimlik bilgisinin nerede kullanıldığını hatırlatmıyorsa, ileride silmeye korkarsınız.
Şifre rotasyonu da bu yüzden kullanıcı ayrımı ister. Tek kullanıcıyı döndürmek tüm sistemi etkiler; servis bazlı kullanıcıda ise değişiklik daha küçük bir alanda test edilir.
TürkDB ile servis bazlı kullanıcı oluşturma
turkdb cluster users create app-pg --username app_rw --role readwrite turkdb cluster users create app-pg --username bi_readonly --role readonly turkdb cluster users create app-pg --username migration_admin --role admin turkdb cluster users list app-pg
Admin rolünü günlük uygulama bağlantısında değil, kontrollü bakım veya migration ihtiyacında kullanın.
Hangi iş için hangi rol?
Rol seçimi bazen teknik ayrıntı gibi görünür ama ürün güvenliğiyle doğrudan ilgilidir. BI aracı yanlışlıkla DELETE çalıştıramamalı; uygulama kullanıcısı şema değiştirememeli; migration kullanıcısı da iş bittikten sonra unutulmamalıdır.
Pratik rol matrisi
app_rw -> uygulama okur/yazar, şema yönetmez worker_okuma-yazma -> arka plan işleri okur/yazar bi_readonly -> raporlama ve pano, yazma yok support_readonly -> geçici inceleme, yazma yok migration_admin -> migration penceresinde kullanılır, sonra kapatılır breakglass_admin -> acil durum, ayrı kayıt ve onayla kullanılır
Kullanıcı temizliği de bakım işidir
Veritabanı kullanıcıları bir kere oluşturulup unutulmamalıdır. Eski servisler, eski entegrasyonlar, geçici migration kullanıcıları ve artık kullanılmayan BI bağlantıları düzenli aralıklarla temizlenmelidir.
TürkDB kullanıcı listesini cluster bağlamında gösterdiği için bu temizlik daha görünür hale gelir. Ayda bir kez “bu kullanıcı hâlâ gerekli mi?” sorusunu sormak küçük ama etkili bir güvenlik alışkanlığıdır.
Kullanıcı envanteri ve silme
turkdb cluster users list app-pg turkdb cluster users delete app-pg <user-id>