Uygulamanız veritabanına bağlanırken tüm yetkilere sahip bir kullanıcı kullanıyor. Kod düzgün, sorgular parametreli. Ama bir gün bir açık bulunursa, o açık yalnızca veri okumakla kalmaz — tabloları da silebilir.
Bu yazı, veritabanı yetkilerini daraltmayı ele alıyor.
Neden Önemli?
Yetki kısıtlaması bir savunma katmanıdır:
- Açığın etkisini sınırlar.
- Kazara silmeyi engeller.
- Sızan şifrenin değerini düşürür.
- Uyum gereksinimlerini karşılar.
Birinci madde asıl gerekçedir: bir enjeksiyon açığı bulunduğunda saldırganın yapabilecekleri, uygulamanın veritabanı yetkileriyle sınırlıdır — tablo silme yetkisi yoksa tablo silinemez.
Bu, açığı önlemez ama sonucunu dramatik biçimde küçültür.
İkinci madde ise günlük hayatta daha sık işe yarar. Yanlış bir betiğin veritabanını silmesini engeller.
Üçüncü madde ise yapılandırma dosyası sızdığında devreye girer.
Hangi Yetkiler Gerekir?
| Yetki | Uygulamaya gerekli mi? |
|---|---|
| Okuma | Evet |
| Ekleme | Evet |
| Güncelleme | Evet |
| Silme | Genellikle evet |
| Tablo oluşturma | Hayır |
| Tablo silme | Hayır |
| Yetki verme | Kesinlikle hayır |
| Dosya işlemleri | Kesinlikle hayır |
Sekizinci satır en tehlikeli yetkidir: dosya okuma-yazma yetkisi olan bir veritabanı kullanıcısı, bir enjeksiyon açığıyla sunucuya doğrudan dosya yazabilir ve bu, kod çalıştırmaya kadar giden bir yol açar.
Bu yetki hiçbir normal uygulamada gerekmez.
Beşinci ve altıncı satırlar ise yalnızca kurulum ve güncelleme sırasında gereklidir; sonraki bölümde ele alınıyor.
Ayrı Kullanıcı Yaklaşımı
Farklı işler için farklı kimlikler kullanılabilir:
- Uygulama kullanıcısı. Günlük işlemler.
- Göç kullanıcısı. Şema değişiklikleri.
- Yedekleme kullanıcısı. Yalnızca okuma.
- Raporlama kullanıcısı. Yalnızca okuma.
İkinci madde şema yetkisi sorununu çözer: tablo oluşturma yetkisini yalnızca göç işlemi sırasında kullanılan ayrı bir kullanıcıya vermek, uygulamanın günlük çalışmasında o yetkiyi taşımamasını sağlar.
Güncelleme yaparken bu kullanıcı kullanılır, sonra uygulama normal kimliğiyle devam eder.
Dördüncü madde ise performans koruması da sağlar. Raporlama kullanıcısına ayrıca kaynak sınırı tanımlanabilir.
Üçüncü madde ise yedekleme betiklerinin yazma yetkisi taşımamasını sağlar.
Paylaşımlı Hostingde Durum
Panel üzerinden yönetim biraz farklıdır:
- Kullanıcı oluşturma paneldedir.
- Yetkiler seçilebilir.
- Tüm yetkiler varsayılan olabilir.
Üçüncü madde en yaygın durumdur: panel üzerinden veritabanı kullanıcısı oluştururken "tüm yetkiler" seçeneği genellikle önceden işaretlidir ve çoğu kullanıcı onu değiştirmeden devam eder.
Oysa panel, yetkileri tek tek seçme imkânı sunar.
Kurulum sırasında geniş yetki verip kurulum bitince daraltmak pratik bir yaklaşımdır.
Bazı içerik yönetim sistemleri güncelleme sırasında şema değiştirdiği için, güncelleme öncesi yetki geçici olarak açılıp sonra kapatılabilir.
Bağlantı Kaynağı Kısıtı
| Ayar | Etkisi |
|---|---|
| Her yerden bağlanabilir | Riskli |
| Yalnızca yerel | Güvenli, yaygın |
| Belirli bir adresten | Uzak sunucu için |
İkinci satır çoğu paylaşımlı hosting için doğru yapılandırmadır: veritabanı kullanıcısını yalnızca yerel bağlantılara sınırlamak, şifre sızsa bile dışarıdan bağlanılmasını imkânsız kılar.
Bu tek ayar, sızan bir yapılandırma dosyasının etkisini büyük ölçüde ortadan kaldırır.
Birinci satır ise yalnızca gerçekten gerekiyorsa kullanılmalıdır ve o durumda güçlü bir şifre ile birlikte kaynak adres kısıtı da tanımlanmalıdır.
Ayrı Veritabanı Kullanmak
Birden fazla siteniz varsa:
- Her site kendi veritabanını kullansın.
- Her sitenin kendi kullanıcısı olsun.
- Kullanıcı yalnızca kendi veritabanını görsün.
Üçüncü madde yalıtımın anahtarıdır: tek bir kullanıcıya tüm veritabanları üzerinde yetki vermek, bir sitedeki açığın diğer tüm sitelerin verisini açığa çıkarması demektir.
Yetkiler veritabanı bazında tanımlanmalıdır.
Bu, aynı hesapta birden fazla müşteri sitesi barındıranlar için zorunlu bir uygulamadır.
Yetkileri Doğrulamak
- Mevcut yetkileri listeleyin.
- Yasak bir işlem deneyin.
- Uygulamanın çalıştığını doğrulayın.
İkinci madde tek gerçek kanıttır: uygulama kullanıcısıyla bir tablo silme komutu deneyip reddedildiğini görmek, kısıtlamanın gerçekten uygulandığını kanıtlayan tek testtir.
Yetki listesine bakmak yeterli değildir; bazen beklenmedik bir üst yetki devrededir.
Üçüncü madde ise daraltmanın uygulamayı bozmadığını doğrular ve tüm işlevler test edilmelidir.
Özellikle arama, raporlama ve yönetim işlevleri beklenmedik yetkiler kullanabilir.
Yetki Daraltınca Çıkan Hatalar
| Belirti | Olası neden |
|---|---|
| Kurulum tamamlanmıyor | Tablo oluşturma yetkisi yok |
| Güncelleme başarısız | Şema değişikliği engellendi |
| Bazı raporlar boş | Geçici tablo yetkisi yok |
| Arama çalışmıyor | Dizin veya görünüm yetkisi |
Üçüncü satır beklenmedik bir bağımlılığı ortaya çıkarır: bazı raporlama sorguları ara sonuçları geçici tablolarda tutar ve bu yetki kaldırıldığında rapor sessizce boş döner — hata bile vermez.
Bu tür sessiz başarısızlıklar, daraltma sonrası kapsamlı test yapmanın neden gerekli olduğunu gösterir.
Çözüm, gerçekten gereken yetkiyi eklemek ve gerekçesini belgelemektir.
Veritabanı kullanıcıları ve yetkilerini panelinizden yönetebilirsiniz; hosting barındırma hizmeti kontrol panelinde kullanıcı bazında yetki seçimi yapılabilir.
Sonuç
Veritabanı yetkilerini daraltmak açığı önlemez ama sonucunu küçültür: bir enjeksiyon açığında saldırganın yapabilecekleri uygulamanın yetkileriyle sınırlıdır — tablo silme yetkisi yoksa tablo silinemez. En tehlikeli yetki dosya işlemleridir; hiçbir normal uygulamada gerekmez ve kod çalıştırmaya kadar giden bir yol açar. Kullanıcıyı yalnızca yerel bağlantılara sınırlayın — bu tek ayar, sızan bir yapılandırma dosyasının etkisini büyük ölçüde ortadan kaldırır.
Sıkça Sorulan Sorular (SSS)
Uygulamaya hangi yetkileri vermeliyim?
Okuma, ekleme, güncelleme ve genellikle silme yeterlidir. Tablo oluşturma ve silme yetkilerini vermeyin — bunlar yalnızca kurulum ve güncelleme sırasında gerekir ve ayrı bir kullanıcıya verilebilir. Yetki verme ve dosya işlemleri yetkilerini ise kesinlikle vermeyin.
Dosya yetkisi neden bu kadar tehlikeli?
Dosya okuma-yazma yetkisi olan bir veritabanı kullanıcısı, bir enjeksiyon açığıyla sunucuya doğrudan dosya yazabilir. Bu, kod çalıştırmaya kadar giden bir yol açar ve sitenin tamamının ele geçirilmesiyle sonuçlanabilir. Hiçbir normal uygulamada bu yetki gerekmez.
Şema değişikliği gerekince ne yapmalıyım?
Tablo oluşturma yetkisini yalnızca göç işlemlerinde kullanılan ayrı bir kullanıcıya verin. Güncelleme yaparken o kullanıcıyı kullanın, sonra uygulama normal kimliğiyle devam etsin. Paylaşımlı hostingde yetkiyi geçici açıp sonra kapatmak da pratik bir yöntemdir.
Kısıtlamanın çalıştığını nasıl doğrularım?
Uygulama kullanıcısıyla bir tablo silme komutu deneyip reddedildiğini görün — bu tek gerçek kanıttır. Yetki listesine bakmak yeterli değildir, bazen beklenmedik bir üst yetki devrededir. Ardından uygulamanın tüm işlevlerini test edin; özellikle raporlar geçici tablo yetkisi gerektirebilir ve hata vermeden boş dönebilir.
