Konuyu Açan
#1
Giriş
PostgreSQL’in search_path ayarı, hangi şema ve içinde hangi nesnelerin varsayılan olarak görünür olacağını belirler. Bu mekanizma, uygulama güvenliği ve çok kiracılı (multi-tenant) ortamlarda kritik bir rol oynar. Ancak yanlış yapılandırılmış bir search_path, yetkisiz nesnelere erişim ya da kazara isim çakışmalarına yol açabilir. Bu nedenle güvenlik açısından dikkat edilmesi gereken birkaç temel sorunu ve uygulanabilir tedbirleri özetlemek isterim.
Sorun alanları ve riskler
Güvenlik odaklı tedbirler
Örnek senaryo ve uygulama önerisi
Bir uygulamada prod veritabanında iki ana şema olsun: public ve prod_ext. Uygulama süreçleri, yalnızca prod_ext içindeki güvenli fonksiyonları çağırmalı ve varsayılan olarak search_path’i [prod_ext, public] şeklinde sabitlemeli. Ancak herhangi bir kullanıcı, kurallı rol üzerinden gerçekten ihtiyaç duyduğu yetkiyle çalışmalı. Örneğin:
Sizce hangi stratejileri uyguluyorsunuz?
Görüşlerinizi ve deneyimlerinizi paylaşın: hangi pratikler sizin için çalıştı, hangi hatalara dikkat çekti?
PostgreSQL’in search_path ayarı, hangi şema ve içinde hangi nesnelerin varsayılan olarak görünür olacağını belirler. Bu mekanizma, uygulama güvenliği ve çok kiracılı (multi-tenant) ortamlarda kritik bir rol oynar. Ancak yanlış yapılandırılmış bir search_path, yetkisiz nesnelere erişim ya da kazara isim çakışmalarına yol açabilir. Bu nedenle güvenlik açısından dikkat edilmesi gereken birkaç temel sorunu ve uygulanabilir tedbirleri özetlemek isterim.
Sorun alanları ve riskler
- Genelde varsayılan şemaların önceliği: Eğer bir kullanıcı belirli bir şemaya doğrudan bağlanmazsa, arka planda search_path’in sırası, hangi nesnelerin hangi kullanıcı için öncelikli olduğunu belirler. Bu durum, uygulama kodunda güvenilir olmayan nesnelere referans verilmesiyle sonucunda istenmeyen nesnelerin çalıştırılmasına yol açabilir.
- Extension veya üçüncü taraf modülleri: Eğer arka uç araçları veya eklentiler, beklenmedik şemalarda bulunan nesnelere erişebiliyorsa, güvenlik kapsamı genişleyebilir ve yetkisiz eylemler tetiklenebilir.
- Ortama özgü farklılıklar: Geliştirme, staging ve üretim arasında search_path farklılıkları, güvenlik politikalarının uygulanmasını zayıflatabilir.
- İsim çakışması: Aynı isimli tablo veya fonksiyon farklı şemalarda olduğunda, yanlış şemadan gelen nesne çağrısı hatalara veya güvenlik ihlallerine yol açabilir.
Güvenlik odaklı tedbirler
- En az ayrıcalık prensibi: Kullanıcı hesaplarını sadece ihtiyaç duydukları şemalara ve nesnelere erişebilecek biçimde sınırla. Gereksiz yetkileri kaldır.
- Search_path’in sıkılaştırılması: Uygulama başlatma sırasında veya oturum açıldığında, net bir ve sabit search_path belirt. Çevresel değişkenlerden bağımsız olarak uygulanabilir bir yapı kullan.
- Şema izolasyonu: Önemli nesneleri kendi şemalarında tut ve güvenilir olmayan kullanıcıların erişimini bu şemalardan kısıtla.
- Uygulama katmanı denetimi: T-SQL içerisinde doğrudan tablo adları yerine schema-qualified nesnelere referans verin; böylece hangi şemadan geldiği açıkça bellidir.
- İzleme ve anomali tespiti: Hangi kullanıcıların hangi şemalardan nesne çağırdığını düzenli olarak kaydedin ve anormal erişimleri alert ile izleyin.
Örnek senaryo ve uygulama önerisi
Bir uygulamada prod veritabanında iki ana şema olsun: public ve prod_ext. Uygulama süreçleri, yalnızca prod_ext içindeki güvenli fonksiyonları çağırmalı ve varsayılan olarak search_path’i [prod_ext, public] şeklinde sabitlemeli. Ancak herhangi bir kullanıcı, kurallı rol üzerinden gerçekten ihtiyaç duyduğu yetkiyle çalışmalı. Örneğin:
KOD
123
SET search_path TO prod_ext, public;
SELECT my_secure_function(arg1) FROM some_table;
Sizce hangi stratejileri uyguluyorsunuz?
- Uygulama başlangıcında sabit bir search_path belirlemek mi, yoksa her oturum için ayrı ayrı mı yönetiyorsunuz?
- Şema izolasyonu ve fonksiyon güvenlik politikalarını nasıl kodluyorsunuz?
- Üretimde izleme ve uyarı mekanizmalarıyla hangi metrikleri takip ediyorsunuz?
Görüşlerinizi ve deneyimlerinizi paylaşın: hangi pratikler sizin için çalıştı, hangi hatalara dikkat çekti?
