Konuyu Açan
#1
Giriş
PostgreSQL’te yeni bir veritabanı, kullanıcı veya şema oluşturduğunuzda, varsayılan yetkiler çoğunlukla güvenli yapılandırmaya hizmet eder. Ancak bazı durumlarda bu varsayılanlar istenmeyen erişimlere yol açabilir. Bu tartışmada, karşılaşılan tipik sorunlar, nedenleri ve güvenli yapılandırma önerilerini paylaşalım.
- 2 aşamalı olarak ele alınması gereken temel alanlar
- Kapsamlı varsayılan yetkiler: CREATE USER/ROLE, CREATE SCHEMA, CONNECT ve TEMP gibi yetkilerin yeni objeler üzerinde nasıl geçtiği.
- Şema ve tablo seviyesinde tam izinler: PUBLIC rolü üzerinden yayılan yaygın etkiler; çoğu zaman çoğu kullanıcıya gereksiz geniş yetkiler verilmesi.
- Veritabanı oturum açma ve rol mirası: SET ROLE ile geçici yetkiler; GRANT ALTER, REFERENCES, TRIGGER gibi özel izinlerin etkileşimleri.
- Karşılaşılan tipik problemler ve örnekler
- PUBLIC’e otomatik verilen izinler nedeniyle yeni tabloların istemeden erişilebilir olması.
- Şema sahipliğinin yanlış atanması nedeniyle içteki fonksiyonlar veya prosedürler için beklenmeyen erişim esnekliği.
- Aynı anda birden çok veritabanı veya şema üzerinde çalışırken rol mirasıyla ilgili çakışmalar.
- Doğru yapılandırma için pratik öneriler
- En erken aşamada hedefleri belirlemek: hangi objeler hangi kullanıcılar tarafından erişilecek? Gerektiğinde özel roller oluşturmak.
- Varsayılan izinleri sınırlamak: CREATE ... WITH ENCRYPTED PASSWORD gibi varsayılan özellikleri gerektiği kadar kısıtlamak.
- Şemaya özel güvenlik politikaları kurmak: GRANT USAGE, CREATE on schema; tablolar için PRIVATE veya SPECIFIC deyimlerle sınırlama.
- Denetim ve test süreçleri: yeni obje eklemelerinde otomatik testlerle izinlerin istenen davranışı sergilediğini doğrulamak.
Sizin deneyimleriniz
Yeni bir projede, varsayılan PUBLIC erişiminin bazı modüllere veya fonksiyonlara sızmasıyla karşılaştığınız oldu mu? Hangi stratejiyle riskleri sınırladınız, hangi denetim araçları veya görsel izleme yöntemlerini kullandınız? Deneyimleri ve önerileri paylaşabilir misiniz?
