Pengantar
Organisasi menjadi lebih dan lebih peduli tentang bagaimana mengurangi biaya solusi database lisensi menggunakan konsolidasi. Beberapa konsolidasi dapat dicapai di SQL Server hanya dengan memanfaatkan hubungan satu-ke-banyak yang ada antara instans dan database. Namun, ada kasus di mana solusi menuntut agar data dikonsolidasikan ke dalam satu tabel. Dalam kasus seperti itu, mungkin ada kekhawatiran tentang cara membatasi akses ke data.
Keamanan Tingkat Baris diperkenalkan di SQL Server 2016 sebagai solusi untuk skenario yang serupa dengan di atas. Ini memungkinkan Anda untuk membatasi akses ke baris dalam tabel berdasarkan kondisi yang ditentukan dalam Fungsi Bernilai Tabel sebaris yang disebut Fungsi Predikat . Ketika Fungsi Predikat diterapkan ke tabel pengguna yang berisi data gabungan, sistem dapat dikonfigurasi untuk mengembalikan kumpulan data yang berbeda ke pengguna yang berbeda tergantung pada peran mereka yang pada gilirannya bergantung pada deskripsi pekerjaan atau departemen mereka misalnya.
Skenario
Kami akan membangun skenario sederhana untuk menggambarkan konsep ini menggunakan lembaga keuangan. Sebuah bank telah memutuskan untuk menggabungkan rekening untuk semua pelanggannya pada satu database dan Transaksi tabel adalah tabel yang dipartisi tunggal yang berisi semua transaksi seperti Pelanggan meja untuk menyimpan semua nasabah bank. Bank tersebut berlokasi di beberapa negara dan juga sedang berkembang. Setiap negara diidentifikasi oleh IDAfiliasi kolom. Perusahaan terstruktur sedemikian rupa sehingga akses ke tabel kunci dibatasi berdasarkan senioritas.
Identifikasi Yang Dapat Dilindungi
Kami perlu menerapkan solusi Keamanan Tingkat Baris yang membatasi akses ke pelanggan dan data transaksi berdasarkan peran dan kebijakan Keamanan Tingkat Baris. Langkah pertama kita adalah membuat tabel yang dibutuhkan. Listing 1 menunjukkan DDL untuk tabel-tabel kunci yang akan kita uji. Seluruh database yang digunakan untuk pengujian ini dapat diunduh dari sini.
Listing 1 – Core Tables in West African Commercial Bank Database; -- Customers; create table Customers (CustID int identity (1000,1) not null Primary Key ,FirstName varchar(100) ,LastName varchar(100) ,PhoneNo bigint ,ContactAddress varchar(4000) ,AffiliateID char(3) foreign key references Affiliates(AffiliateID) ,AccountNo1 bigint ,AccountNo2 bigint ,AccountNo3 bigint ,AccountNo1Curr char (3) ,AccountNo2Curr char (3) ,AccountNo3Curr char (3) ) GO -- Transactions; create table Transactions (TranID int identity (1000,1) not null ,AcctID int foreign key references Accounts (AcctID) ,TranDate datetime ,TranAmt money ,AffiliateID char(3) foreign key references Affiliates(AffiliateID) ,primary key (TranID,TranDate)) ON PartSch (TranDate) -- Transaction_History; create table Transaction_History (TranID int identity (1000,1) not null ,AcctID int foreign key references Accounts (AcctID) ,TranDate datetime ,TranAmt money ,AffiliateID char(3) foreign key references Affiliates(AffiliateID) ,primary key (TranID,TranDate)) ON PartSch (TranDate)
Kami kemudian membuat satu set tabel yang dapat kami gunakan untuk mengidentifikasi staf. Dalam pengaturan ini, setiap staf memiliki ScopeID yang menentukan sejauh mana dia dapat melihat atau memanipulasi data:
- Nasional – Seorang staf hanya dapat memanipulasi data di negara staf (tempat dia bekerja)
- Regional – Seorang staf hanya dapat memanipulasi data di wilayah staf (misalnya Afrika Barat)
- Global – Seorang staf dapat memanipulasi data di negara mana pun di mana bank akan memiliki cabang
Setiap ruang lingkup ditugaskan kepada staf berdasarkan penunjukan mereka. Cakupan Manajer Grup adalah Global , cakupan Country Manager adalah Regional dan ruang lingkup Eksekutif adalah Nasional . Cara tradisional untuk membatasi akses ke data sering menggunakan peran dan izin. Menetapkan izin ke peran dan selanjutnya menetapkan peran ke pengguna berarti pengguna memiliki izin yang terkait dengan peran tersebut untuk seluruh kumpulan data dalam tabel yang dimaksud. Keamanan Tingkat Baris memberi kita kesempatan untuk melakukan sesuatu yang lebih terperinci:membatasi izin SELECT/UPDATE/DELETE pengguna ke subset kumpulan data dalam tabel (kontrol akses berbutir halus).
Gbr. 1. StaffScope dan Tabel Staf
Peran dan Pengguna Basis Data
Daftar 2 menunjukkan pengguna dan peran yang harus kami buat untuk melanjutkan solusi kami. Idenya adalah bahwa ada hubungan antara staf yang disimpan dalam tabel pengguna Staff dan StaffScope dan Prinsipal Basis Data yang nantinya akan digunakan oleh staf ini untuk mengakses data. Amati kolom pada Gambar 1 yang disebut DBUserID . Kolom ini diisi menggunakan fungsi DATABASE_PRINCIPAL_ID (lihat Daftar 2)
Listing 2 – Staff, Database User IDs and Roles
-- Populate Staff Table
use WACB
go
insert into Staff values ('John','Edu',DATABASE_PRINCIPAL_ID(),'Manager','233205678493','2','Accra, Ghana','EGH');
insert into Staff values ('Margaret','Harrison',DATABASE_PRINCIPAL_ID(),'Group Manager','2348030006574','3','Lagos, Nigeria','ENG');
insert into Staff values ('Edward','Antwi',DATABASE_PRINCIPAL_ID(),'Executive','22824567493','1','Lome, Togo','ETG');
insert into Staff values ('Barbara','Orji',DATABASE_PRINCIPAL_ID(),'Executive','22424567493','1','Abuja, Nigeria','ENG');
GO
-- Create Database User IDs for Staff
create user jedu without login;
create user mharrison without login;
create user eantwi without login;
create user borji without login;
-- Associate Database Principal IDs with Staff
update staff set DBUserID=DATABASE_PRINCIPAL_ID(concat(left(firstname,1),lastname));
-- Create Database Roles
create role [National] ;
create role [Regional] ;
create role [Global] ;
-- Grant Permissions on Desired Tables to Database Roles
grant select on customers to [National];
grant select, update on customers to Regional;
grant select, update on customers to Global;
grant select on Transactions to Regional, Global;
grant select on Transaction_History to Regional, Global;
grant update on Transactions to Global;
-- Grant Database Roles to Database Users Associated with Staff
alter role [National] add member eantwi;
alter role [National] add member borji;
alter role [Regional] add member jedu;
alter role [Global] add member mharrison;
Sejauh ini ringkasan yang telah kami lakukan adalah:
- Buat/identifikasi tabel yang perlu kita amankan
- Buat tabel yang menunjukkan kriteria yang akan kita gunakan untuk membatasi akses ke data pada tingkat baris (Cakupan)
- Membuat peran dan pengguna basis data yang akan kami terapkan batasannya
- Akses terbatas ke tabel inti (“Keamanan Tingkat Tabel”) menggunakan peran dan izin
Fungsi Prediksi dan Kebijakan Keamanan
Sejauh ini kami memiliki apa yang kami sebut Keamanan Tingkat Tabel yang diimplementasikan menggunakan peran dan izin. Sekarang kami ingin masuk lebih dalam. Kami ingin dua prinsipal yang memiliki hak istimewa SELECT pada tabel untuk dapat mengkueri tabel tetapi melihat kumpulan data yang berbeda berdasarkan kondisi yang kami siapkan. Daftar 3 menunjukkan kepada kita bagaimana kita mencapainya.
Listing 3 - Implement Row Level Security
-- Create Predicate Function
create schema rls;
go
create function rls.AccessPredicate (@AffiliateID char(3))
returns table
with schemabinding
as
return select 1 as access
from dbo.Staff as s
join dbo.StaffScope ss on s.ScopeID=ss.ScopeID
join dbo.Affiliates a on s.AffiliateID=a.AffiliateID
where (
IS_MEMBER('National')=1
and s.DBUserID=DATABASE_PRINCIPAL_ID()
and @AffiliateID=s.AffiliateID
)
OR
(
IS_MEMBER('Regional')=1
and @AffiliateID in (select a.AffiliateID from dbo.Affiliates where Region='West Africa')
)
OR
(
IS_MEMBER('Global')=1
);
GO
-- Create Security Policy
create security policy rls.dataSecurityPol
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Customers,
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transactions,
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Customers after update,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transactions after update,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History after update;
GO
-- Alter Security Policy
alter security policy rls.dataSecurityPol
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History after update;
GO
Fungsi predikat mendefinisikan kondisi yang harus dipenuhi untuk prinsipal untuk melihat subset dari data yang menarik. Dalam fungsi ini, ada tiga kondisi:
- Pengguna database Staf adalah anggota Nasional peran dan IDAfiliasi cocok dengan staf ATAU
- Pengguna database Staf adalah anggota Regional peran dan IDAfiliasi cocok dengan daftar IDAfiliasi milik Wilayah Afrika Barat ATAU
- Pengguna database Staf adalah anggota Global
Ini menyiratkan bahwa anggota Global role melihat semua data hanya karena dia termasuk dalam role tersebut. Namun, anggota dari dua peran lainnya harus memenuhi kriteria tambahan yang berbatasan dengan ID Afiliasi .
Agar fungsi bermanfaat, terapkan ini ke tabel sebagai predikat FILTER atau predikat BLOCK. Predikat FILTER membatasi apa yang dapat dilihat prinsipal sementara predikat BLOK memastikan bahwa prinsipal tidak dapat memanipulasi data apa pun di luar apa yang disajikan kepadanya oleh batasan yang ditentukan dalam fungsi. Kebijakan Keamanan adalah wadah tempat kami menentukan predikat FILTER dan BLOK untuk semua tabel yang kami minati. Lihat Listing 3 lagi.
Salah satu aspek yang sangat menarik dari pendekatan ini adalah modularitas. Kita bisa menerapkan predikat ke tabel tambahan di Kebijakan Keamanan tanpa mempengaruhi tabel yang sudah ada, kita bisa menambahkan prinsipal database baru (Staf) dengan membuat pengguna database dan memberi mereka peran yang sesuai. Saat terjadi perpindahan Staf, kami dapat memperbarui penugasan peran dan sebagainya.
Menguji Penerapan
Jadi sekarang setelah kita selesai, kita dapat meniru prinsipal database untuk menentukan apakah kita memiliki hasil yang diharapkan dengan menggunakan kode di Listing 4. Sebelum kita melihat itu, mari kita lihat peran yang terkait dengan masing-masing staf dan afiliasinya di Gambar 2.
Gbr. 2. Daftar Staf
Listing 4 – Testing the Implementation
select * from Customers;
execute ('select * from Customers') as user='eantwi';
execute ('select * from Customers') as user='borji';
execute ('select * from Customers') as user='jedu';
execute ('select * from Customers') as user='mharrison';
Di baris pertama, saya menanyakan Pelanggan tabel sebagai sysadmin, tapi saya TIDAK mendapatkan BARIS. Artinya, bahkan seorang administrator tidak dapat mengesampingkan efek RLS tanpa peniruan identitas.
Gbr. 4. SysAdmin Tidak Melihat Baris
Barbara dan Edward keduanya Eksekutif dan termasuk dalam Lingkup Nasional tetapi mereka bekerja di negara yang berbeda sehingga mereka melihat Pelanggan yang terkait dengan afiliasi masing-masing. (Lihat Nama staf pada Gambar 1).
Gbr. 5. Eksekutif melihat Baris Afiliasi mereka
John dan Margaret adalah Manajer Negara dan Grup. Mereka milik Regional dan Global Lingkup masing-masing. John melihat data untuk Afrika Barat, sementara Margaret melihat data untuk semua wilayah.
Gbr. 6. Manajer melihat Baris Wilayah mereka
Hasilnya sama untuk semua tabel lain yang telah menerapkan Kebijakan Keamanan. Perhatikan bahwa tanpa izin pada Transaksi tabel, Keamanan Tingkat Baris tidak ada nilainya.
Gbr. 7. Tidak ada Izin SELECT pada Transaksi Tabel
Listing 5 – Permissions on Transactions Table grant select on dbo.Transactions to [National];
Gbr. 8. Transaksi Tabel seperti yang Dilihat oleh Eksekutif
Kesimpulan
Keamanan Tingkat Baris adalah metode yang kuat untuk mengeksploitasi kemampuan kontrol akses berbutir halus SQL Server. Menggunakan fitur ini mengharuskan Anda menjalankan SQL Server 2016 atau lebih tinggi. Seperti namanya, tujuannya adalah untuk membatasi akses ke baris dalam tabel menggunakan kueri kompleks setelah Anda menangani "keamanan tingkat tabel". Skenario di mana kemampuan ini dapat diterapkan tidak terbatas, sehingga sangat berguna untuk berbagai lingkungan. Lakukan dengan baik untuk menjelajahi dan melihat apa yang dapat dilakukannya untuk Anda.
Referensi
Isakov, V. (2018). Ujian Ref 70-764 Mengelola Infrastruktur Database SQL . Pendidikan Pearson
Keamanan Tingkat Baris
