Keamanan tingkat baris di Fabric Data Warehouse

Berlaku untuk:✅ Titik akhir analitik SQL dan Gudang di Microsoft Fabric

Keamanan tingkat baris (RLS) memungkinkan Anda menggunakan keanggotaan grup atau konteks eksekusi untuk mengontrol akses ke baris dalam tabel database. Misalnya, Anda dapat memastikan bahwa pekerja hanya mengakses baris data yang relevan dengan departemennya. Contoh lain adalah membatasi akses data pelanggan hanya ke data yang relevan dengan perusahaan mereka dalam arsitektur multipenyewa. Fitur ini mirip dengan keamanan tingkat baris di SQL Server.

Keamanan tingkat baris di tingkat data

Keamanan tingkat baris menyederhanakan desain dan pengodean keamanan dalam aplikasi Anda. Keamanan tingkat baris membantu Anda menerapkan pembatasan pada akses baris data.

Logika pembatasan akses berada di tingkat database, bukan di tingkat aplikasi tunggal. Database menerapkan pembatasan akses setiap kali akses data dicoba, dari aplikasi atau platform pelaporan apa pun termasuk Power BI. Tindakan ini membuat sistem keamanan Anda lebih andal dan kuat dengan mengurangi luas permukaan sistem keamanan Anda. Keamanan tingkat baris hanya berlaku untuk kueri pada titik akhir analitik Gudang atau SQL di Fabric. Kueri Power BI terhadap gudang data dalam mode Direct Lake akan beralih ke mode Direct Query agar mematuhi keamanan tingkat baris.

Membatasi akses ke baris tertentu untuk pengguna tertentu

Terapkan RLS dengan menggunakan perintah Transact-SQL CREATE SECURITY POLICY dan predikat yang dibuat sebagai fungsi bernilai tabel sebaris.

Keamanan tingkat baris diterapkan pada warehouse bersama atau lakehouse, karena sumber data dasarnya belum berubah.

Keamanan tingkat baris berbasis predikat

Keamanan tingkat baris di Fabric Data Warehouse mendukung keamanan berbasis predikat. Predikat filter memfilter baris yang tersedia untuk membaca operasi secara diam-diam.

Akses ke data tingkat baris dalam tabel dibatasi oleh predikat keamanan yang didefinisikan sebagai fungsi bernilai tabel sebaris. Fungsi ini kemudian dipanggil dan diberlakukan oleh kebijakan keamanan. Untuk predikat filter, aplikasi tidak menyadari baris yang difilter dari kumpulan hasil. Jika semua baris difilter, maka set null akan dikembalikan.

Predikat filter diterapkan saat membaca data dari tabel dasar. Mereka mempengaruhi semua operasi get: SELECT, , DELETEdan UPDATE. Setiap tabel harus memiliki keamanan tingkat barisnya sendiri yang ditentukan secara terpisah. Pengguna yang mengkueri tabel tanpa kebijakan keamanan tingkat baris akan melihat data yang tidak difilter.

Pengguna tidak dapat memilih atau menghapus baris yang difilter. Pengguna tidak dapat memperbarui baris yang difilter. Tetapi dimungkinkan untuk memperbarui baris sedemikian rupa sehingga setelah itu baris tersebut akan difilter.

Predikat filter dan kebijakan keamanan memiliki perilaku berikut:

  • Anda dapat menentukan fungsi predikat yang bergabung dengan tabel lain dan/atau memanggil fungsi. Jika kebijakan keamanan dibuat dengan SCHEMABINDING = ON (default), maka gabungan atau fungsi dapat diakses dari kueri dan berfungsi seperti yang diharapkan tanpa pemeriksaan izin tambahan.

  • Anda dapat mengeluarkan kueri terhadap tabel yang memiliki predikat keamanan yang ditentukan tetapi dinonaktifkan. Baris apa pun yang difilter atau diblokir tidak terpengaruh.

  • Jika pengguna dbo, anggota peran db_owner, atau pemilik tabel membuat kueri pada tabel yang memiliki kebijakan keamanan yang ditentukan dan diaktifkan, baris akan difilter atau diblokir sesuai dengan yang ditentukan oleh kebijakan keamanan.

  • Upaya untuk mengubah skema tabel yang terikat oleh kebijakan keamanan terikat skema akan mengakibatkan kesalahan. Namun, kolom yang tidak direferensikan oleh predikat dapat diubah.

  • Upaya untuk menambahkan predikat pada tabel yang sudah memiliki predikat yang ditentukan untuk operasi yang ditentukan menghasilkan kesalahan. Ini akan terjadi apakah predikat diaktifkan atau tidak.

  • Upaya untuk mengubah fungsi, yang digunakan sebagai predikat pada tabel dalam kebijakan keamanan terikat skema, akan mengakibatkan kesalahan.

  • Menentukan beberapa kebijakan keamanan aktif yang berisi predikat yang tidak tumpang tindih, berhasil.

Predikat filter memiliki perilaku berikut:

  • Tentukan kebijakan keamanan yang memfilter baris tabel. Aplikasi ini tidak mengetahui baris mana pun yang difilter untuk operasi SELECT, UPDATE, dan DELETE. Termasuk dalam situasi ketika semua baris terfilter. Aplikasi dapat INSERT baris, meskipun baris tersebut akan difilter selama operasi lain.

Izin

Membuat, mengubah, atau menghilangkan kebijakan keamanan memerlukan ALTER ANY SECURITY POLICY izin. Membuat atau menghilangkan kebijakan keamanan memerlukan ALTER izin pada skema.

Selain itu, izin berikut diperlukan untuk setiap predikat yang ditambahkan:

  • SELECT dan REFERENCES izin untuk fungsi yang digunakan sebagai predikat.

  • REFERENCES izin akses pada tabel target yang diikat ke kebijakan.

  • REFERENCES izin untuk setiap kolom pada tabel target yang digunakan sebagai argumen.

Kebijakan keamanan berlaku untuk semua pengguna, termasuk pengguna dbo dalam database. Pengguna Dbo dapat mengubah atau menghilangkan kebijakan keamanan namun perubahan kebijakan keamanan mereka dapat diaudit. Jika anggota peran seperti Administrator, Anggota, atau Kontributor perlu melihat semua baris untuk memecahkan masalah atau memvalidasi data, kebijakan keamanan harus ditulis untuk mengizinkannya.

Jika kebijakan keamanan dibuat dengan SCHEMABINDING = OFF, maka untuk mengkueri tabel target, pengguna harus memiliki SELECT izin atau EXECUTE pada fungsi predikat dan tabel, tampilan, atau fungsi tambahan yang digunakan dalam fungsi predikat. Jika kebijakan keamanan dibuat dengan SCHEMABINDING = ON (default), pemeriksaan izin ini akan dilewati saat pengguna mengkueri tabel target.

Pertimbangan keamanan: serangan saluran samping

Pertimbangkan dan bersiaplah untuk dua skenario berikut.

Manajer kebijakan keamanan berbahaya

Penting untuk diperhatikan bahwa pengelola kebijakan keamanan yang berniat jahat, dengan izin yang memadai untuk membuat kebijakan keamanan pada kolom sensitif serta izin untuk membuat atau mengubah fungsi inline bernilai tabel, dapat berkolusi dengan pengguna lain yang memiliki izin SELECT pada tabel untuk melakukan eksfiltrasi data dengan secara sengaja membuat fungsi inline bernilai tabel yang dirancang untuk menggunakan serangan saluran samping guna menyimpulkan data. Serangan tersebut akan memerlukan kolusi (atau izin berlebihan yang diberikan kepada pengguna berbahaya) dan kemungkinan akan memerlukan beberapa iterasi untuk memodifikasi kebijakan (memerlukan izin untuk menghapus predikat untuk memutus pengikatan skema), memodifikasi fungsi bernilai tabel sebaris, dan berulang kali menjalankan pernyataan pemilihan pada tabel target. Sebaiknya batasi izin seperlunya dan pantau aktivitas yang mencurigakan. Aktivitas seperti kebijakan yang terus berubah dan fungsi bernilai tabel sebaris yang terkait dengan keamanan tingkat baris harus dipantau.

Kueri yang disusun dengan cermat

Kebocoran informasi dapat terjadi dengan menggunakan kueri yang dirancang secara cermat dan memanfaatkan error untuk mengekstraksi data secara diam-diam. Misalnya, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; akan membiarkan pengguna jahat tahu bahwa gaji John Doe tepat $ 100.000. Meskipun ada predikat keamanan untuk mencegah pengguna jahat mengkueri gaji orang lain secara langsung, pengguna dapat menentukan kapan kueri mengembalikan pengecualian bagi-demi-nol.

Contoh

Kami dapat menunjukkan gudang keamanan tingkat baris dan titik akhir analitik SQL di Microsoft Fabric.

Contoh berikut membuat tabel sampel yang dapat digunakan dengan Warehouse di Fabric, tetapi untuk titik akhir analitik SQL gunakan tabel yang sudah ada. Di titik akhir analitik SQL, Anda tidak dapat CREATE TABLE, tetapi Anda dapat CREATE SCHEMA, CREATE FUNCTION, dan CREATE SECURITY POLICY.

Dalam contoh ini, pertama-tama buat skema sales, tabel sales.Orders.

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');

Buat Security skema, fungsi Security.tvf_securitypredicate, dan kebijakan SalesFilterkeamanan .

-- 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

Untuk mengubah fungsi keamanan tingkat baris, Anda harus terlebih dahulu menghilangkan kebijakan keamanan. Dalam skrip berikut, kita menghapus kebijakan SalesFilter sebelum menjalankan pernyataan ALTER FUNCTION terhadap Security.tvf_securitypredicate. Kemudian, kami membuat ulang kebijakan SalesFilter.

-- 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

Langkah selanjutnya

Terapkan keamanan tingkat baris di Fabric Data Warehouse

Konten terkait

  • Last updated on