RLS Politikaları Doğru Uygulansa Bile Veri Sızdırmanın Altı Yolu

RLS Politikaları Doğru Uygulansa Bile Veri Sızdırmanın Altı Yolu

Veritabanı güvenliğinde Row-Level Security (RLS) (Satır Seviyesi Güvenlik), kullanıcıların yalnızca yetkili oldukları verilere erişmesini sağlamak için güçlü bir mekanizmadır. Ancak, RLS politikaları doğru bir şekilde yapılandırılmış ve uygulanmış gibi görünse bile, hassas verilerin sızdırılmasına yol açabilecek beklenmedik yollar mevcuttur. Bu makale, RLS’in sağladığı sahte güvenlik hissinin ötesine geçerek, doğru uygulanan RLS politikalarına rağmen veri sızıntısına neden olabilecek altı farklı senaryoyu detaylandırıyor ve bu tuzaklardan nasıl kaçınılacağını açıklıyor.

Row-Level Security (RLS) Nedir ve Neden Önemlidir?

Row-Level Security (RLS), veritabanı motoru seviyesinde uygulanan bir erişim kontrol mekanizmasıdır. Temel amacı, farklı kullanıcıların aynı tabloya erişirken yalnızca kendi yetkileri dahilindeki satırları görebilmesini sağlamaktır. Örneğin, bir satış müdürü sadece kendi bölgesindeki satış verilerini, bir insan kaynakları çalışanı ise sadece kendi departmanındaki çalışan bilgilerini görebilir. Bu, uygulama katmanında karmaşık filtreleme mantığı yazma ihtiyacını ortadan kaldırarak hem geliştirme maliyetini düşürür hem de güvenlik açığı riskini azaltır.

RLS, özellikle çok kiracılı (multi-tenant) uygulamalarda, yani aynı veritabanını kullanan birden fazla müşteriye hizmet veren sistemlerde hayati bir rol oynar. Her müşterinin verisinin diğer müşteriler tarafından görülmemesini garanti eder. RLS, bir veritabanı kullanıcısının belirli bir tabloya sorgu gönderdiğinde, bu sorguya otomatik olarak bir filtre predicate’i (koşul) ekleyerek çalışır. Bu predicate, kullanıcının yetkileriyle eşleşen satırları döndürür. Örneğin, bir Sales tablosunda, kullanıcının Region bilgisine göre filtreleme yapan bir RLS politikası tanımlanabilir. Bu sayede, kullanıcı yalnızca kendi bölgesine ait satış kayıtlarını görüntüleyebilir. RLS’in doğru bir şekilde uygulanması, veri gizliliği ve uyumluluk (örneğin GDPR, KVKK) açısından kritik öneme sahiptir. Ancak, çoğu zaman gözden kaçan detaylar, en iyi niyetli RLS uygulamalarını bile zayıflatabilir ve hassas veri sızıntılarına yol açabilir.

1. Şema ve Metaveri Erişimi Üzerinden Veri Sızdırma: Görünmez Bilgiler

RLS politikaları genellikle belirli tablolardaki verilere erişimi kısıtlar. Ancak, veritabanının şeması (schema) veya metaverileri (metadata) üzerindeki yetkilendirme gözden kaçırıldığında, saldırganlar bu bilgileri kullanarak dolaylı yoldan veri sızdırabilirler. Bir kullanıcının doğrudan veri satırlarını görmesi engellense bile, tablonun yapısını, sütun adlarını, veri tiplerini ve hatta diğer tablolarla olan ilişkilerini öğrenmesi, potansiyel bir saldırı vektörü oluşturur. Örneğin, bir saldırgan, bir tablonun Salary (Maaş) veya TCKN (Türkiye Cumhuriyeti Kimlik Numarası) gibi hassas bilgiler içeren sütunlara sahip olduğunu metaveri sorguları aracılığıyla keşfedebilir. Bu bilgi, daha sonra hedefli saldırılar düzenlemek veya başka bir güvenlik açığından yararlanmak için kullanılabilir.

Gerçek dünya senaryosunda, bir kullanıcının yalnızca kendi müşteri kayıtlarını görmesine izin veren bir RLS politikası olduğunu varsayalım. Bu politika Customers tablosundaki CustomerID sütununu kullanıcının oturum kimliğiyle eşleştirir. Ancak, kullanıcıya INFORMATION_SCHEMA görünümlerine veya sistem tablolarına erişim izni verilmişse, bu kullanıcı Employees tablosunun varlığını, bu tabloda SSN (Sosyal Güvenlik Numarası) veya Salary gibi sütunların bulunduğunu öğrenebilir. Bu bilgiler, doğrudan verilere erişim sağlamasa da, saldırganın sistem hakkında değerli istihbarat toplamasına olanak tanır. Daha sonra, SQL Enjeksiyonu gibi başka bir zafiyet bulunduğunda, bu metaveri bilgisi hedefli saldırıların başarılı olma olasılığını artırır. Bu nedenle, RLS uygularken yalnızca veri satırlarını değil, aynı zamanda veritabanı şeması ve metaverileri üzerindeki erişim kontrollerini de sıkı bir şekilde yönetmek hayati öneme sahiptir. Kullanıcılara yalnızca ihtiyaç duydukları en az yetki (least privilege) ilkesine göre izinler verilmelidir, bu da sistem tablolarına ve metaveri görünümlerine gereksiz erişimin kısıtlanmasını içerir.

-- Bir RLS politikası örneği
CREATE FUNCTION dbo.fn_securitypredicate(@CustomerID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS accessResult
    WHERE @CustomerID = CAST(SESSION_CONTEXT(N'CustomerID') AS INT);
GO

CREATE SECURITY POLICY CustomerFilter
ADD FILTER PREDICATE dbo.fn_securitypredicate(CustomerID)
ON dbo.Customers
WITH (STATE = ON);
GO

-- Saldırganın metaveri sorgusu ile bilgi toplaması
SELECT COLUMN_NAME, DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'Employees' AND COLUMN_NAME LIKE '%SSN%';
-- Bu sorgu, RLS tarafından korunmayan Employees tablosundaki SSN sütununun varlığını ortaya çıkarabilir.
    

2. Zaman Tabanlı ve Çıkarımsal Saldırılar: Gecikmelerden Veri Sızdırma

RLS politikaları, genellikle bir kullanıcının yetkisi dışındaki satırların sorgu sonuçlarında görünmesini engeller. Ancak, bu satırların varlığı veya yokluğu, sorgu yürütme süresindeki küçük farklılıklar (zaman tabanlı saldırılar) veya hata mesajlarındaki değişiklikler (çıkarımsal saldırılar) aracılığıyla ifşa edilebilir. Bu tür saldırılar, doğrudan veri döndürmeden, sistemin davranışındaki ince farklılıkları analiz ederek bilgi edinmeye dayanır. Bir saldırgan, RLS tarafından gizlenen bir satırın var olup olmadığını, sorgunun tamamlanma süresini gözlemleyerek anlayabilir.

Örneğin, bir veritabanında “gizli” bir müşteri kaydının olup olmadığını öğrenmek isteyen bir saldırgan düşünelim. RLS politikası, kullanıcının yalnızca kendi müşteri kayıtlarını görmesine izin veriyor. Saldırgan, belirli bir CustomerID ile sorgu yapar. Eğer bu CustomerID, kullanıcının erişebileceği bir kayıt değilse ve veritabanında hiç yoksa, sorgu çok hızlı bir şekilde “kayıt bulunamadı” yanıtı dönebilir. Ancak, eğer bu CustomerID veritabanında mevcut fakat kullanıcının RLS politikası tarafından gizleniyorsa, veritabanı motoru yine de bu kaydı bulmak için bir miktar işlem yapacak ve ardından RLS filtresini uygulayarak “erişim reddedildi” (veya boş sonuç) döndürecektir. Bu durumda, sorgu süresi, kaydın hiç olmamasından daha uzun olabilir. Bu küçük zaman farkları, yeterli sayıda deneme ve dikkatli analizle, gizli kayıtların varlığını ortaya çıkarabilir.

Bir başka çıkarımsal saldırı türü, hata mesajları üzerinden gerçekleşebilir. Eğer RLS politikası bir satırı gizlerken, belirli bir işlemde (örneğin, birincil anahtar kısıtlaması ihlali) bu gizli satırla ilgili bir hata mesajı üretirse, bu hata mesajının içeriği veya tipi, saldırgana gizli veriler hakkında bilgi verebilir. Bu tür saldırılar, özellikle yüksek güvenlik gerektiren sistemlerde, RLS’in tek başına yeterli olmadığını ve yan kanal (side channel) saldırılarına karşı ek önlemler alınması gerektiğini göstermektedir. Sorgu optimizasyonlarının ve veritabanı motorunun davranışlarının dikkatlice incelenmesi, bu tür zafiyetlerin tespit edilmesi ve giderilmesi için kritik öneme sahiptir.

3. Agrega Fonksiyonları ve Satır Sayıları ile Bilgi Sızdırma: Sayılar Asla Yalan Söylemez

RLS politikaları, genellikle tek tek satırlara uygulanır ve kullanıcının yetkisi dışındaki satırların doğrudan görünmesini engeller. Ancak, agrega fonksiyonları (COUNT, SUM, AVG, MAX, MIN) kullanıldığında, RLS’in bu koruması dolaylı yoldan delinebilir ve hassas bilgiler sızdırılabilir. Bir kullanıcı, doğrudan göremediği satırlar hakkında bile, bu satırların toplam sayısını veya belirli bir özelliğin ortalamasını öğrenerek değerli bilgiler edinebilir.

Bu senaryoyu bir örnekle açıklayalım: Bir şirketin Employees (Çalışanlar) tablosu var ve bu tabloda Salary (Maaş) sütunu bulunuyor. RLS politikası, her yöneticinin yalnızca kendi departmanındaki çalışanların detaylarını görmesine izin veriyor. Ancak, bir yönetici kendi departmanındaki çalışanların ortalama maaşını (AVG(Salary)) ve tüm şirketin çalışanlarının toplam sayısını (COUNT(*)) sorgulayabilirse, bu bilgiler üzerinden kendi departmanının maaş bütçesini veya çalışan sayısını, şirketin genel rakamlarıyla karşılaştırarak çıkarımlar yapabilir. Daha da tehlikelisi, eğer saldırgan, RLS tarafından gizlenen bir koşula sahip bir sorgu çalıştırır ve bu sorgunun toplam satır sayısını (COUNT(*)) alırsa, bu sayı üzerinden gizli verilerin varlığı veya dağılımı hakkında bilgi edinebilir.

Örneğin, bir saldırgan, belirli bir SSN (Sosyal Güvenlik Numarası) değerine sahip bir çalışanın olup olmadığını merak ediyor. RLS, bu çalışanın detaylarını göstermese bile, saldırgan şu sorguyu deneyebilir:

SELECT COUNT(*) FROM Employees WHERE SSN = '123-45-6789';
    

Eğer RLS bu sorguyu engellemeyip sadece sonuçları filtrelerse, ve veritabanında böyle bir SSN‘e sahip bir çalışan varsa (ancak RLS nedeniyle görünmüyorsa), COUNT(*) sonucu 1 dönebilir. Eğer böyle bir çalışan yoksa, 0 döner. Bu, saldırganın gizli bir SSN‘in varlığını doğrudan veri görmeden tespit etmesine olanak tanır. Bu tür bir sızıntıyı önlemek için, RLS politikalarının agrega fonksiyonlarını da kapsayacak şekilde genişletilmesi veya agrega sorgularının yalnızca yetkili kullanıcılar için belirli görünümler üzerinden yapılması sağlanmalıdır. Bazı veritabanları, RLS’in agrega fonksiyonlarına uygulanması için özel mekanizmalar sunar, ancak bunlar dikkatlice yapılandırılmalıdır.

4. Hata Mesajları Aracılığıyla Yan Kanal Sızıntıları: Hatalar Konuşur

RLS politikaları, veri erişimini kısıtlarken, arka planda meydana gelen veritabanı hataları veya istisnaları (exceptions), saldırganlara hassas bilgiler hakkında ipuçları verebilir. Bu, bir tür yan kanal (side channel) saldırısıdır; burada doğrudan veri sızdırılmasa da, sistemin hata tepkileri analiz edilerek gizli bilgiler çıkarılabilir. Eğer bir RLS politikası, kullanıcının görmemesi gereken bir satırı içeren bir işlemi engellerken, bu engelleme sonucunda oluşan hata mesajı, engellenen satır hakkında detaylar içeriyorsa, bu bir veri sızıntısı riski oluşturur.

Örneğin, bir Products (Ürünler) tablosu ve bir Orders (Siparişler) tablosu olduğunu varsayalım. RLS politikası, bir kullanıcının yalnızca kendi bölgesindeki ürünleri görmesine izin veriyor. Kullanıcı, kendi bölgesinde olmayan bir ürünle ilgili bir sipariş oluşturmaya çalışırsa ve veritabanı, bu ürünün ProductID‘sine dayalı bir yabancı anahtar (foreign key) kısıtlaması ihlali hatası döndürürse, bu hata mesajının içeriği kritik olabilir. Eğer hata mesajı, “ProductID: 12345 ile ilişkili ürün bulunamadı” gibi detaylı bilgi içeriyorsa, saldırgan bu ProductID‘nin var olduğunu (ancak kendi bölgesi için erişilebilir olmadığını) öğrenmiş olur. Bu, RLS’in amacını boşa çıkarır, çünkü saldırgan, doğrudan göremese bile belirli bir ürünün varlığını kanıtlamış olur.

Bir başka senaryo, SQL enjeksiyonu denemelerinde ortaya çıkabilir. Saldırgan, RLS tarafından korunan bir tabloya yönelik SQL enjeksiyonu denemesi yaptığında, eğer veritabanı motoru, RLS filtresi nedeniyle “erişim reddedildi” yerine, örneğin bir veri tipi uyumsuzluğu veya sütun adı hatası gibi daha spesifik bir hata döndürürse, bu hata mesajı saldırganın şema hakkında bilgi edinmesine yardımcı olabilir. Bu tür sızıntıları önlemek için, uygulama katmanında hata mesajlarının genel ve bilgilendirici olmayan bir şekilde işlenmesi ve son kullanıcıya sunulması esastır. Veritabanı seviyesinde ise, hata mesajlarının detay seviyesi minimuma indirilmeli ve hassas bilgiler içermediğinden emin olunmalıdır. Ayrıca, veritabanı loglarının düzenli olarak izlenmesi, bu tür yan kanal saldırı denemelerini tespit etmek için önemlidir.

-- Hata mesajı ile veri sızdırma örneği
-- Varsayalım ki ProductID 500, kullanıcının erişimine kapalı bir üründür.
-- Kullanıcı, bu ProductID ile bir sipariş eklemeye çalışır.
INSERT INTO Orders (OrderID, CustomerID, ProductID, Quantity)
VALUES (1001, 123, 500, 1);

-- Eğer veritabanı "Foreign key violation: ProductID '500' does not exist in Products table."
-- gibi bir hata mesajı dönerse, saldırgan ProductID 500'ün varlığını öğrenmiş olur.
-- Doğru yaklaşım: Hata mesajını genel bir ifadeyle değiştirmek: "İşlem başarısız oldu. Lütfen tekrar deneyin."
    

5. Yanlış Yapılandırılmış Birleştirmeler (Joins) ve Görünümler (Views) ile RLS Bypass

RLS politikaları genellikle temel tablolara (base tables) uygulanır. Ancak, veritabanı tasarımında veya uygulama kodunda yapılan yanlış yapılandırılmış birleştirmeler (joins) veya görünümler (views), RLS’in korumasını atlatarak veri sızıntılarına yol açabilir. RLS’in yalnızca belirli bir tabloya uygulandığı, ancak bu tablonun hassas verilerini içeren başka bir tabloyla birleştirildiğinde veya bir görünüm aracılığıyla ifşa edildiğinde bu durum ortaya çıkar. Eğer RLS, birleştirme yapılan tüm tablolara veya görünümlere tutarlı bir şekilde uygulanmazsa, güvenlik zafiyeti oluşur.

Örneğin, bir Employees tablosu ve bir Departments tablosu olduğunu varsayalım. Employees tablosunda Salary (Maaş) gibi hassas bilgiler var ve bu tabloya RLS uygulanmış durumda; yani bir yönetici sadece kendi departmanındaki çalışanların maaşlarını görebiliyor. Ancak, Departments tablosuna RLS uygulanmamış ve tüm kullanıcılara erişilebilir durumda. Eğer bir geliştirici, Employees ve Departments tablolarını birleştiren bir görünüm (view) oluşturur ve bu görünüme RLS politikasını uygulamazsa, bu görünüm üzerinden tüm çalışanların maaş bilgileri, departman bilgileriyle birlikte ifşa edilebilir. Yönetici, kendi departmanı dışındaki çalışanların maaşlarını doğrudan Employees tablosundan göremese bile, bu yanlış yapılandırılmış görünüm aracılığıyla tüm maaş bilgilerine erişebilir.

-- Employees tablosuna RLS uygulanmış
-- CREATE SECURITY POLICY EmployeeFilter ... ON dbo.Employees

-- Departments tablosuna RLS uygulanmamış
CREATE TABLE Departments (
    DepartmentID INT PRIMARY KEY,
    DepartmentName NVARCHAR(100)
);

-- Yanlış yapılandırılmış görünüm
CREATE VIEW v_AllEmployeeDetails AS
SELECT e.EmployeeID, e.EmployeeName, e.Salary, d.DepartmentName
FROM Employees e
JOIN Departments d ON e.DepartmentID = d.DepartmentID;
-- Bu görünüme RLS uygulanmadığı için, bir kullanıcı bu görünüm üzerinden tüm çalışanların maaşlarını görebilir.
    

Bu tür bir sızıntıyı önlemek için, RLS politikalarının uygulanması gereken tüm tabloların ve bu tabloları kullanan tüm görünümlerin, saklı yordamların (stored procedures) ve fonksiyonların dikkatlice incelenmesi gerekir. Her bir RLS politikası, veri akışının her noktasında tutarlı bir şekilde uygulanmalı ve hassas verilerin dolaylı yollarla ifşa edilmediğinden emin olunmalıdır. Veritabanı şemasını tasarlarken, güvenlik katmanlarının her seviyede dikkate alınması ve yetkilendirmelerin baştan sona tutarlı olması esastır. Ayrıca, yeni görünümler veya birleştirmeler oluşturulduğunda, mevcut RLS politikalarının bu yeni yapılar üzerindeki etkisinin titizlikle değerlendirilmesi gerekmektedir.

6. Uygulama Katmanında Veri İhracı ve Önbellekleme: Güvenlik Sınırlarını Aşmak

RLS politikaları, veritabanı seviyesinde güçlü bir koruma sağlasa da, uygulama katmanında verilerin işleniş şekli veya dışa aktarılması (export) ile ilgili zafiyetler, doğru RLS uygulamalarını bile etkisiz hale getirebilir. Veriler, veritabanından doğru bir şekilde filtrelenmiş olarak çekilse bile, eğer uygulama bu verileri güvensiz bir şekilde önbellekler (cache), dışa aktarır veya başka sistemlere aktarırsa, RLS’in sağladığı koruma kaybolur.

Gerçek dünya senaryosunda, bir web uygulaması düşünelim. Kullanıcı, RLS tarafından filtrelenmiş olarak yalnızca kendi müşteri listesini görüntüler. Ancak, uygulama, kullanıcının “Tüm Müşterileri CSV Olarak Dışa Aktar” veya “Rapor Oluştur” gibi bir özelliğe sahipse ve bu dışa aktarma işlemi, RLS filtresini atlayarak veya sunucu tarafında farklı bir yetkilendirme bağlamında çalışarak tüm müşteri verilerini çekerse, bu büyük bir veri sızıntısına yol açabilir. Örneğin, sunucu tarafında çalışan bir raporlama servisi, veritabanına daha yüksek yetkilerle (örneğin, sysadmin veya RLS’den muaf bir kullanıcı olarak) erişebilir ve bu yetkileri kullanarak tüm verileri çekip dışa aktarabilir. Bu durumda, son kullanıcının veritabanı erişimi kısıtlı olsa bile, uygulama katmanı bu kısıtlamayı aşmış olur.

Bir diğer yaygın senaryo, uygulama katmanında verilerin önbelleğe alınmasıdır. Eğer hassas veriler, RLS tarafından filtrelendikten sonra bile, uygulama sunucusunun belleğinde veya dosya sisteminde güvensiz bir şekilde önbelleğe alınırsa, bu önbelleğe erişebilen başka bir süreç veya saldırgan bu verilere ulaşabilir. Örneğin, bir kullanıcının oturumu sona erdiğinde bile, eski oturuma ait hassas veriler sunucu tarafındaki önbellekte kalmış olabilir. Bu tür sızıntıları önlemek için, uygulama katmanında veri işleme, dışa aktarma ve önbellekleme süreçlerinin RLS ile uyumlu ve güvenli olduğundan emin olunmalıdır. Dışa aktarma veya raporlama işlevleri, veritabanından veri çekerken her zaman RLS politikalarını göz önünde bulundurmalı ve kullanıcı yetkileriyle eşleşen filtrelemeyi uygulamalıdır. Önbellekleme stratejileri ise hassas verilerin ömrünü, erişimini ve depolama yöntemlerini dikkatlice yönetmelidir.

Sonuç ve Öneriler

Row-Level Security (RLS) veritabanı güvenliği için temel bir araç olsa da, doğru bir şekilde uygulandığı varsayılan durumlarda bile veri sızıntılarına yol açabilecek birçok potansiyel zafiyet bulunmaktadır. Şema ve metaveri erişimi, zaman tabanlı saldırılar, agrega fonksiyonları, hata mesajları, yanlış yapılandırılmış birleştirmeler ve uygulama katmanındaki veri işleme süreçleri, RLS’in ötesinde dikkat edilmesi gereken kritik noktalardır. Bu makalede ele alınan altı farklı senaryo, RLS’in tek başına yeterli bir çözüm olmadığını, katmanlı bir güvenlik yaklaşımının (defense-in-depth) gerekliliğini vurgulamaktadır.

Veritabanı yöneticileri ve geliştiriciler, RLS politikalarını tasarlarken ve uygularken sadece satır filtrelemesine odaklanmamalı, aynı zamanda verinin yaşam döngüsünün her aşamasını (oluşturulmasından depolanmasına, işlenmesinden sunulmasına kadar) göz önünde bulundurmalıdır. Kullanıcılara en az yetki (least privilege) ilkesine göre izinler vermek, hata mesajlarını genelleştirmek, agrega sorgularını dikkatlice yönetmek, tüm birleştirme ve görünümleri RLS ile uyumlu hale getirmek ve uygulama katmanındaki veri işleme süreçlerini güvenli kılmak, bu tür sızıntıları önlemek için hayati adımlardır. Unutmayın, güvenlik bir süreçtir, tek seferlik bir uygulama değil; sürekli denetim, test ve iyileştirme gerektirir.

Sıkça Sorulan Sorular

• RLS neden tek başına yeterli değildir?

  RLS, veritabanı seviyesinde satır bazında erişimi kısıtlamada çok etkilidir. Ancak, metaveri erişimi, yan kanal saldırıları, agrega fonksiyonları ve uygulama katmanındaki yanlış yapılandırmalar gibi RLS’in doğrudan kapsamadığı alanlar üzerinden veri sızıntıları yaşanabilir. Güvenlik, çok katmanlı bir yaklaşımla sağlanmalıdır.

• Uygulama katmanında RLS’i nasıl desteklemeliyim?

  Uygulama katmanı, veritabanından çekilen verileri işlerken RLS politikalarını dikkate almalıdır. Veri dışa aktarma, raporlama ve önbellekleme gibi özellikler, RLS’in uyguladığı filtrelemeyi atlamamalıdır. Mümkünse, uygulama, veritabanına bağlanırken kullanıcının kendi yetki bağlamını kullanmalı veya RLS’i tetikleyecek şekilde tasarlanmalıdır.

• Agrega fonksiyonları ile veri sızıntısı nasıl önlenebilir?

  Agrega fonksiyonları kullanılırken, RLS politikalarının bu fonksiyonlara da uygulanmasını sağlayacak mekanizmalar araştırılmalıdır. Bazı veritabanları, RLS fonksiyonlarının agrega sorgularında da çalışmasını destekler. Alternatif olarak, hassas veriler içeren tablolar için agrega sorguları, yalnızca tam yetkili kullanıcılar veya özel olarak tasarlanmış, RLS’i göz önünde bulunduran görünümler üzerinden yapılmalıdır.

• Hata mesajlarının veri sızdırmasını nasıl engellerim?

  Uygulama katmanında, veritabanından gelen hata mesajları yakalanmalı ve son kullanıcıya genel, bilgilendirici olmayan mesajlar olarak sunulmalıdır. Veritabanı yapılandırmasında ise, hata mesajlarının detay seviyesi minimuma indirilmeli ve hassas şema veya veri bilgileri içermediğinden emin olunmalıdır.

• RLS politikalarını test ederken nelere dikkat etmeliyim?

  RLS politikalarını test ederken sadece doğrudan veri erişimini değil, aynı zamanda yan kanal saldırılarını (zamanlama, hata mesajları), agrega sorgularını, farklı kullanıcı rollerini ve çeşitli uygulama katmanı senaryolarını da kapsamlı bir şekilde test etmelisiniz. Farklı yetki seviyelerindeki kullanıcılar olarak sisteme giriş yaparak, beklenen ve beklenmeyen tüm davranışları gözlemlemelisiniz.

#RLS #VeritabanıGüvenliği #VeriSızıntısı #SiberGüvenlik #ErişimKontrolü #GüvenlikPolitikaları