Doku veri ambarında satır düzeyi güvenlik

Şunlar için geçerlidir: Microsoft Fabric'te SQL analiz uç noktası ve Ambarı

Satır düzeyi güvenlik (RLS), veritabanı tablosundaki satırlara erişimi denetlemek için grup üyeliğini veya yürütme bağlamını kullanmanızı sağlar. Örneğin, çalışanların yalnızca kendi departmanlarıyla ilgili veri satırlarına erişmesini sağlayabilirsiniz. Diğer bir örnek de müşterilerin veri erişimini yalnızca çok kiracılı mimarideki şirketleriyle ilgili verilerde kısıtlamaktır. Bu özellik, SQL Server'daki satır düzeyi güvenliğe benzer.

Veri düzeyinde satır düzeyi güvenlik

Satır düzeyi güvenlik, uygulamanızda güvenliğin tasarımını ve kodlamasını basitleştirir. Satır düzeyi güvenlik, veri satırı erişiminde kısıtlamalar uygulamanıza yardımcı olur.

Erişim kısıtlama mantığı, tek bir uygulama katmanında değil veritabanı katmanındadır. Veritabanı, Power BI dahil olmak üzere herhangi bir uygulama veya raporlama platformundan her veri erişimi denenişinde erişim kısıtlamalarını uygular. Bu, güvenlik sisteminizin yüzey alanını azaltarak güvenlik sisteminizi daha güvenilir ve sağlam hale getirir. Satır düzeyi güvenlik yalnızca Doku'daki bir Ambar veya SQL analiz uç noktasındaki sorgular için geçerlidir. Direct Lake modundaki bir ambardaki Power BI sorguları, satır düzeyi güvenliğe uymak için Doğrudan Sorgu moduna geri döner.

Belirli satırlara erişimi belirli kullanıcılarla kısıtlama

CREATE SECURITY POLICY Transact-SQL deyimini ve satır içi tablo değerli işlevler olarak oluşturulan koşullarını kullanarak RLS'yi uygulayın.

Temel alınan veri kaynağı değişmediğinden, paylaşılan ambara veya lakehouse'a satır düzeyi güvenlik uygulanır.

Koşul tabanlı satır düzeyi güvenlik

Fabric Synapse Veri Ambarı'nda satır düzeyi güvenlik, koşul tabanlı güvenliği destekler. Filtre koşulu, okuma işlemleri için kullanılabilir satırları sessizce filtreler.

Tablodaki satır düzeyi verilere erişim, satır içi tablo değerli işlev olarak tanımlanan bir güvenlik koşuluyla kısıtlanır. İşlev daha sonra bir güvenlik ilkesi tarafından çağrılır ve zorlanır. Filtre koşullarında, uygulama sonuç kümesinden filtrelenen satırların farkında değildir. Tüm satırlar filtrelenirse null bir küme döndürülür.

Temel tablodan veriler okunurken filtre önkoşulları uygulanır. Tüm alma işlemlerini etkiler: SELECT, DELETEve UPDATE. Kullanıcılar filtrelenmiş satırları seçemez veya silemez. Kullanıcı filtrelenmiş satırları güncelleştiremez. Ancak satırları daha sonra filtrelenecek şekilde güncelleştirmek mümkündür.

Filtre koşulu ve güvenlik ilkeleri aşağıdaki davranışlara sahiptir:

• Başka bir tabloyla birleştiren ve/veya işlev çağıran bir koşul işlevi tanımlayabilirsiniz. Güvenlik ilkesi ile SCHEMABINDING = ON oluşturulursa (varsayılan), birleştirme veya işlev sorgudan erişilebilir ve ek izin denetimleri olmadan beklendiği gibi çalışır.

• Tanımlanmış ancak devre dışı bırakılmış bir güvenlik koşulu olan bir tabloya yönelik bir sorgu yayımlayabilirsiniz. Filtrelenen veya engellenen satırlar etkilenmez.

• Bir dbo kullanıcısı, rolün db_owner bir üyesi veya tablo sahibi tanımlanmış ve etkin bir güvenlik ilkesi olan bir tabloyu sorgularsa, satırlar güvenlik ilkesi tarafından tanımlandığı şekilde filtrelenir veya engellenir.

• Şemaya bağlı bir güvenlik ilkesiyle ilişkili bir tablonun şemasını değiştirme girişimleri hataya neden olur. Ancak koşul tarafından başvurulmayan sütunlar değiştirilebilir.

• Belirtilen işlem için zaten tanımlanmış olan bir tabloya koşul ekleme girişimleri hatayla sonuçlanır. Koşulun etkin olup olmadığı bu durum oluşur.

• Şemaya bağlı bir güvenlik ilkesi içindeki bir tabloda koşul olarak kullanılan bir işlevi değiştirme girişimleri hataya neden olur.

• Çakışmayan koşullar içeren birden çok etkin güvenlik ilkesi tanımlama başarılı olur.

Filtre önkoşulları aşağıdaki davranışa sahiptir:

• Tablonun satırlarını filtreleyen bir güvenlik ilkesi tanımlayın. Uygulama, , UPDATEve DELETE işlemleri için SELECTfiltrelenen satırların farkında değildir. Tüm satırların filtrelendiği durumlar dahil. Uygulama, başka bir işlem sırasında filtrelense bile satırlar oluşturabilir INSERT .

İzinler

Güvenlik ilkelerini oluşturmak, değiştirmek veya bırakmak için izin gerekir ALTER ANY SECURITY POLICY . Güvenlik ilkesi oluşturmak veya bırakmak için şema üzerinde izin gerekir ALTER .

Ayrıca, eklenen her koşul için aşağıdaki izinler gereklidir:

• SELECT ve REFERENCES koşul olarak kullanılan işlev üzerindeki izinler.

• REFERENCES ilkeye bağlı olan hedef tablo üzerindeki izin.

• REFERENCES bağımsız değişken olarak kullanılan hedef tablodaki her sütunda izin.

Güvenlik ilkeleri, veritabanındaki dbo kullanıcıları da dahil olmak üzere tüm kullanıcılar için geçerlidir. Dbo kullanıcıları güvenlik ilkelerini değiştirebilir veya bırakabilir ancak güvenlik ilkelerindeki değişiklikleri denetlenebilir. Yönetici, Üye veya Katkıda Bulunan gibi rollerin üyelerinin veri sorunlarını gidermek veya doğrulamak için tüm satırları görmesi gerekiyorsa, buna izin vermek için güvenlik ilkesinin yazılması gerekir.

ile SCHEMABINDING = OFFbir güvenlik ilkesi oluşturulursa, hedef tabloyu sorgulamak için kullanıcıların koşul işlevi ve koşul işlevinde kullanılan ek tablolar, görünümler veya işlevler üzerinde veya EXECUTE iznine sahip SELECT olması gerekir. ile SCHEMABINDING = ON bir güvenlik ilkesi oluşturulursa (varsayılan), kullanıcılar hedef tabloyu sorguladığında bu izin denetimleri atlanır.

Güvenlikle ilgili dikkat edilmesi gerekenler: yan kanal saldırıları

Aşağıdaki iki senaryoyu göz önünde bulundurun ve hazırlayın.

Kötü amaçlı güvenlik ilkesi yöneticisi

Hassas bir sütunun üzerinde güvenlik ilkesi oluşturmak için yeterli izinlere sahip olan ve satır içi tablo değerli işlevler oluşturma veya değiştirme izni olan kötü amaçlı bir güvenlik ilkesi yöneticisinin verileri çıkarmak için yan kanal saldırılarını kullanmak üzere tasarlanmış satır içi tablo değerli işlevleri kötü amaçlı olarak oluşturarak veri sızdırma gerçekleştirmek için tablo üzerinde seçme izinlerine sahip olan başka bir kullanıcıyla işbirliği yapabildiğini gözlemlemek önemlidir. Bu tür saldırılar harmanlama (veya kötü amaçlı bir kullanıcıya aşırı izinler verilmesi) gerektirebilir ve büyük olasılıkla ilkeyi değiştirme (şema bağlamasını bozmak için koşulu kaldırma izni gerektiren), satır içi tablo değerli işlevleri değiştirme ve hedef tabloda sürekli seçme deyimlerini çalıştırma gibi çeşitli yinelemeler gerektirir. İzinleri gerektiği gibi sınırlamanızı ve şüpheli etkinlikleri izlemenizi öneririz. Satır düzeyi güvenlikle ilgili sürekli değişen ilkeler ve satır içi tablo değerli işlevler gibi etkinlikler izlenmelidir.

Dikkatlice hazırlanmış sorgular

Verileri dışarı aktarmak için hataları kullanan dikkatle hazırlanmış sorgular kullanarak bilgi sızıntısına neden olmak mümkündür. Örneğin, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; kötü niyetli bir kullanıcıya John Doe'nun maaşının tam olarak 100.000 ABD doları olduğunu bildirir. Kötü amaçlı bir kullanıcının diğer kişilerin maaşını doğrudan sorgulamasını önlemek için bir güvenlik koşulu olsa da, kullanıcı sorgunun ne zaman sıfıra bölme özel durumu döndürdüğünü belirleyebilir.

Örnekler

Microsoft Fabric'te satır düzeyi güvenlik Ambarı ve SQL analiz uç noktasını gösterebiliriz.

Aşağıdaki örnek, Doku'da Warehouse ile çalışacak örnek tablolar oluşturur, ancak SQL analiz uç noktasında mevcut tabloları kullanır. SQL analizi uç noktasında yapamazsınızCREATE TABLE, ancak , CREATE FUNCTIONve CREATE SECURITY POLICYyapabilirsinizCREATE SCHEMA.

Bu örnekte, önce bir şema sales, bir tablo sales.Ordersoluşturun.

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

Şema Security , işlev Security.tvf_securitypredicateve güvenlik ilkesi SalesFilteroluşturun.

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

İlgili içerik

• Microsoft Fabric'te veri ambarı güvenliği
• Ambarınızı paylaşma ve izinleri yönetme
• Doku veri ambarında sütun düzeyinde güvenlik
• Doku veri ambarında dinamik veri maskeleme

Sonraki adım

Doku Veri Depolama satır düzeyi güvenlik uygulama