Inleiding
Organisaties maken zich steeds meer zorgen over hoe ze de licentiekosten voor databaseoplossingen kunnen verlagen met behulp van consolidatie. Enige consolidatie kan in SQL Server worden bereikt door eenvoudigweg gebruik te maken van de bestaande een-op-veel-relatie tussen instanties en databases. Er zijn echter gevallen waarin de oplossing vereist dat gegevens worden geconsolideerd in één tabel. In een dergelijk geval kunnen er zorgen zijn over hoe de toegang tot de gegevens kan worden beperkt.
Rijniveaubeveiliging is geïntroduceerd in SQL Server 2016 als een oplossing voor scenario's die vergelijkbaar zijn met de bovenstaande. Hiermee kunt u de toegang tot rijen in een tabel beperken op basis van voorwaarden die zijn gedefinieerd in een inline tabelwaardefunctie, een predicaatfunctie genoemd. . Wanneer een predikaatfunctie wordt toegepast op een gebruikerstabel die geconsolideerde gegevens bevat, kan het systeem worden geconfigureerd om verschillende gegevenssets terug te sturen naar verschillende gebruikers, afhankelijk van hun rollen, die op hun beurt afhankelijk zijn van hun functiebeschrijvingen of afdelingen bijvoorbeeld.
Scenario
We zullen een eenvoudig scenario bouwen om dit concept te illustreren met behulp van een financiële instelling. Een bank heeft besloten de rekeningen voor al haar klanten te consolideren in één enkele database en de Transacties tabel is een enkele gepartitioneerde tabel die alle transacties bevat, net als de Klanten tabel voor het opslaan van alle klanten van de bank. De bank is gevestigd in meerdere landen en breidt ook uit. Elk land wordt geïdentificeerd door een AffiliateID kolom. Het bedrijf is zo gestructureerd dat toegang tot sleuteltabellen beperkt is op basis van anciënniteit.
Identificeer Securables
We zullen een Row Level Security-oplossing moeten implementeren die de toegang tot de klant- en transactiegegevens beperkt op basis van rollen en een Row Level Security-beleid. Onze eerste stap is het maken van de vereiste tabellen. Lijst 1 toont de DDL voor de belangrijkste tabellen die we zullen testen. De volledige database die voor deze test is gebruikt, kan hier worden gedownload.
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)
Vervolgens maken we een set tabellen die we kunnen gebruiken om personeel te identificeren. In deze opstelling heeft elk personeelslid een ScopeID die bepaalt in hoeverre hij of zij gegevens kan bekijken of manipuleren:
- Nationaal – Een medewerker kan alleen gegevens manipuleren in het land van de medewerker (waar hij of zij werkt)
- Regionaal – Een medewerker kan alleen gegevens manipuleren in de regio van de medewerker (bijv. West-Afrika)
- Wereldwijd – Een medewerker kan gegevens manipuleren in elk land waar de bank ooit een filiaal zal hebben
Elke scope wordt toegewezen aan het personeel op basis van hun aanwijzing. Het bereik van een Groepsmanager is Globaal , het bereik van een Country Manager is Regionaal en het bereik van een Executive is Nationaal . De traditionele manier om de toegang tot gegevens te beperken, is vaak het gebruik van rollen en machtigingen. Door machtigingen toe te wijzen aan een rol en vervolgens de rol toe te wijzen aan een gebruiker, heeft de gebruiker de machtigingen die aan die rol zijn gekoppeld voor de gehele dataset in de betreffende tabel. Beveiliging op rijniveau geeft ons de mogelijkheid om iets gedetailleerders te doen:de gebruikersrechten voor SELECT/UPDATE/DELETE beperken tot een subset van de gegevensset in de tabel (fijnmazig toegangscontrole).
Afb. 1. StaffScope en Staff Tables
Databaserollen en gebruikers
Lijst 2 toont de gebruikers en rollen die we moeten maken om door te gaan met onze oplossing. Het idee is dat er een relatie is tussen het personeel zoals opgeslagen in de gebruikerstabellen Staff en StaffScope en de Database Principals die dit personeel uiteindelijk zal gebruiken om toegang te krijgen tot de gegevens. Bekijk de kolom in Fig. 1 genaamd DBUserID . Deze kolom wordt gevuld met de functie DATABASE_PRINCIPAL_ID (zie Lijst 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;
Wat we tot nu toe hebben gedaan, is in het kort:
- Maak/identificeer de tabellen die we moeten beveiligen
- Maak tabellen die de criteria aangeven die we zullen gebruiken om de toegang tot gegevens op rijniveau te beperken (Scope)
- Databaserollen en gebruikers gemaakt waarop we beperkingen zullen toepassen
- Beperkte toegang tot de kerntabellen ("Beveiliging op tafelniveau") met behulp van rollen en machtigingen
Voorspellingsfunctie en beveiligingsbeleid
Tot dusver hebben we wat we kunnen noemen Table Level Security geïmplementeerd met behulp van rollen en machtigingen. Nu willen we dieper gaan. We willen dat twee principals met SELECT-rechten voor een tabel de tabel kunnen opvragen, maar verschillende gegevenssets kunnen zien op basis van de voorwaarden die we hebben ingesteld. Vermelding 3 laat ons zien hoe we dit bereiken.
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
De predikaatfunctie definieert de voorwaarden waaraan een principal moet voldoen om een subset van de interessante gegevens te zien. In deze functie zijn er drie voorwaarden:
- De databasegebruiker van het personeel is lid van de National rol en de AffiliateID komt overeen met die van de staf OF
- De databasegebruiker van het personeel is lid van de Regionale rol en de AffiliateID komt overeen met de lijst met AffiliateID ’s die behoren tot de West-Afrikaanse regio OF
- De databasegebruiker van het personeel is lid van de Global
Dit houdt in dat een lid van de Global rol ziet alle gegevens simpelweg omdat hij of zij bij die rol hoort. Leden van de andere twee rollen moeten echter voldoen aan aanvullende criteria die grenzen aan de AffiliateID's .
Om de functie nuttig te maken, past u dit toe op tabellen als FILTER-predikaten of BLOCK-predikaten. FILTER-predikaten beperken wat de principaal kan zien, terwijl BLOCK-predikaten ervoor zorgen dat de principaal geen gegevens kan manipuleren buiten de gegevens die hem/haar worden aangeboden door de beperkingen die in de functie zijn gedefinieerd. Een beveiligingsbeleid is een container waarin we de predikaten FILTER en BLOCK specificeren voor alle tabellen waarin we geïnteresseerd zijn. Bekijk Lijst 3 nogmaals.
Een zeer interessant aspect van deze benadering is de modulariteit. We kunnen de predikaten toepassen op extra tabellen in het beveiligingsbeleid zonder de bestaande gedefinieerde tabellen te beïnvloeden, we kunnen nieuwe database-principals (personeel) toevoegen door databasegebruikers aan te maken en hen de juiste rollen toe te kennen. Wanneer er personeel wordt verplaatst, kunnen we de roltoewijzingen bijwerken, enzovoort.
De implementatie testen
Nu we klaar zijn, kunnen we ons voordoen als de database-principals om te bepalen of we de verwachte resultaten hebben met behulp van de code in Listing 4. Laten we, voordat we daar naar kijken, de rollen bekijken die zijn gekoppeld aan elk personeelslid en hun gelieerde ondernemingen in Fig. 2.
Afb. 2. Personeelslijst
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';
In de eerste regel vraag ik de Klanten tabel als een sysadmin, maar ik krijg GEEN RIJEN. Dit betekent dat zelfs een beheerder de effecten van RLS niet kan overschrijven zonder imitatie.
Afb. 4. SysAdmin ziet geen rijen
Barbara en Edward zijn beide Executives en behoren tot de National Scope, maar ze werken in verschillende landen, zodat ze de klanten zien die geassocieerd zijn met hun respectievelijke filialen. (Zie Stafnamen in Fig. 1).
Afb. 5. Leidinggevenden zien de rijen van hun partner
John en Margaret zijn Country en Group Managers. Ze behoren tot de Regionale en Globaal Bereik respectievelijk. John ziet gegevens voor West-Afrika, terwijl Margaret gegevens voor alle regio's ziet.
Afb. 6. Managers zien de rijen van hun regio
De resultaten zijn hetzelfde voor alle andere tabellen waarop het beveiligingsbeleid is toegepast. Merk op dat zonder toestemmingen op de Transacties tabel, beveiliging op rijniveau heeft geen waarde.
Afb. 7. Geen SELECT-machtigingen voor Transacties Tabel
Listing 5 – Permissions on Transactions Table grant select on dbo.Transactions to [National];
Afb. 8. Transacties Tabel zoals gezien door leidinggevenden
Conclusie
Row Level Security is een krachtige methode om gebruik te maken van de fijnmazige toegangscontrolemogelijkheden van SQL Server. Voor het gebruik van deze functie moet u SQL Server 2016 of hoger gebruiken. Zoals de naam al aangeeft, is het doel om de toegang tot rijen binnen een tabel te beperken met behulp van complexe query's nadat u voor "beveiliging op tabelniveau" hebt gezorgd. De scenario's waarin deze mogelijkheid kan worden toegepast, zijn eindeloos, dus het is zeer nuttig voor een breed scala aan omgevingen. Doe er goed aan om te verkennen en te zien wat het voor u kan doen.
Referenties
Isakov, V. (2018). Examenref 70-764 Beheer van een SQL-database-infrastructuur . Pearson Onderwijs
Beveiliging op rijniveau