Keamanan tingkat baris di pergudangan data Fabric

  • Artikel

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 pada gudang dalam mode Direct Lake akan kembali ke mode Direct Query untuk mematuhi keamanan tingkat baris.

Membatasi akses ke baris tertentu untuk pengguna tertentu

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

Keamanan tingkat baris diterapkan ke gudang bersama atau lakehouse, karena sumber data yang mendasar belum berubah.

Keamanan tingkat baris berbasis predikat

Keamanan tingkat baris di Fabric Synapse 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. Pengguna tidak dapat memilih atau menghapus baris yang difilter. Pengguna tidak dapat memperbarui baris yang difilter. Tetapi dimungkinkan untuk memperbarui baris sedih sehingga baris tersebut akan difilter setelahnya.

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 db_owner peran, atau pemilik tabel meminta tabel yang memiliki kebijakan keamanan yang ditentukan dan diaktifkan, baris difilter atau diblokir seperti 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 menyadari baris apa pun yang difilter untuk SELECToperasi , UPDATE, dan DELETE . Termasuk situasi di mana semua baris difilter. Aplikasi dapat INSERT baris, bahkan jika mereka 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 pada fungsi yang digunakan sebagai predikat.

  • REFERENCES izin pada tabel target yang terikat pada kebijakan.

  • REFERENCES izin pada setiap kolom dari 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 mengamati bahwa manajer kebijakan keamanan berbahaya, dengan izin yang memadai untuk membuat kebijakan keamanan di atas kolom sensitif dan memiliki izin untuk membuat atau mengubah fungsi bernilai tabel sebaris, dapat berkolusi dengan pengguna lain yang memiliki izin pilih pada tabel untuk melakukan eksfiltrasi data dengan membuat fungsi bernilai tabel sebaris yang dirancang untuk menggunakan serangan saluran samping untuk 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 dibuat dengan hati-hati

Dimungkinkan untuk menyebabkan kebocoran informasi dengan menggunakan kueri yang dibuat dengan hati-hati yang menggunakan kesalahan untuk menyelundupkan data. 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 akan berfungsi dengan Gudang di Fabric, tetapi di titik akhir analitik SQL menggunakan tabel yang 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

Konten terkait

Langkah selanjutnya

Menerapkan keamanan tingkat baris di Fabric Data Warehousing