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
, DELETE
ve UPDATE
. Her tablonun ayrı ayrı tanımlanmış kendi satır düzeyi güvenliği olmalıdır. Satır düzeyi güvenlik ilkesi olmayan tabloları sorgulayan kullanıcılar filtrelenmemiş verileri görüntüler.
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, ,
UPDATE
veDELETE
işlemleri içinSELECT
filtrelenen 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şturabilirINSERT
.
İ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
veREFERENCES
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 = OFF
bir 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 FUNCTION
ve CREATE SECURITY POLICY
yapabilirsinizCREATE SCHEMA
.
Bu örnekte, önce bir şema sales
, bir tablo sales.Orders
oluş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_securitypredicate
ve güvenlik ilkesi SalesFilter
oluş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
Satır düzeyi güvenlik işlevini değiştirmek için önce güvenlik ilkesini bırakmanız gerekir. Aşağıdaki betikte, üzerinde Security.tvf_securitypredicate
bir ALTER FUNCTION
deyim vermeden önce ilkeyi SalesFilter
bırakacağız. Ardından ilkesini SalesFilter
yeniden oluşturacağız.
-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO
-- Alter the function for the SalesRep evaluation
ALTER 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() = 'president@contoso.com';
GO
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO