Dogłębna eksploracja zabezpieczeń na poziomie wiersza

Wprowadzenie

Organizacje coraz bardziej martwią się o to, jak zredukować koszty licencjonowania rozwiązań bazodanowych za pomocą konsolidacji. Pewną konsolidację można osiągnąć w SQL Server, po prostu wykorzystując istniejącą relację jeden-do-wielu między instancjami i bazami danych. Istnieją jednak przypadki, w których rozwiązanie wymaga konsolidacji danych w jednej tabeli. W takim przypadku mogą pojawić się obawy dotyczące ograniczenia dostępu do danych.

Row Level Security został wprowadzony w SQL Server 2016 jako rozwiązanie dla scenariuszy podobnych do powyższych. Pozwala na ograniczenie dostępu do wierszy w tabeli na podstawie warunków zdefiniowanych we wbudowanej funkcji o wartości tabeli zwanej Funkcją predykatu . Gdy funkcja predykatu zostanie zastosowana do tabeli użytkowników zawierającej skonsolidowane dane, system można skonfigurować tak, aby zwracał różne zestawy danych różnym użytkownikom w zależności od ich ról, co z kolei zależy na przykład od ich opisów stanowisk lub działów.

Scenariusz

Zbudujemy prosty scenariusz, aby zilustrować tę koncepcję za pomocą instytucji finansowej. Bank zdecydował się skonsolidować rachunki dla wszystkich swoich klientów w jednej bazie danych i Transakcjach tabela to pojedyncza podzielona na partycje tabela zawierająca wszystkie transakcje, podobnie jak Klienci stół do przechowywania wszystkich klientów banku. Bank jest zlokalizowany w kilku krajach i również się rozwija. Każdy kraj jest identyfikowany przez AffiliateID kolumna. Firma ma taką strukturę, że dostęp do tabel kluczy jest ograniczony ze względu na staż pracy.

Zidentyfikuj zabezpieczenia

Będziemy musieli wdrożyć rozwiązanie Row Level Security, które ograniczy dostęp do danych klientów i transakcji w oparciu o role i politykę Row Level Security. Naszym pierwszym krokiem jest stworzenie wymaganych tabel. Listing 1 pokazuje DDL dla tabel kluczy, które będziemy testować. Całą bazę danych wykorzystaną do tego testu można pobrać stąd.

Listing 1 – Podstawowe tabele w bazie danych banków komercyjnych Afryki Zachodniej;-- Klienci;utwórz tabelę Klienci (tożsamość CustID int (1000,1) nie null Klucz podstawowy, FirstName varchar (100), LastName varchar (100), PhoneNo bigint ,ContactAddress varchar(4000),AffiliateID char(3) Odwołania do kluczy obcych Podmioty stowarzyszone(AffiliateID),AccountNo1 bigint,AccountNo2 bigint,AccountNo3 bigint,AccountNo1Curr char(3),AccountNo2Curr char(3),AccountNo3Curr char(3))GO-- Transakcje;utwórz tabelę Transakcje(TranID int tożsamość (1000,1) nie null ,AcctID int odniesienia do kluczy obcych Konta (AcctID),TranDate datetime ,TranAmt money,AffiliateID char(3) Odniesienia do kluczy obcych Podmioty stowarzyszone (AffiliateID),klucz podstawowy (TranID) ,TranDate))ON PartSch (TranDate)-- Transaction_History;utwórz tabelę Transaction_History(TranID int tożsamość (1000,1) nie null ,AcctID int odwołanie do klucza obcego Konta (AcctID),TranDate datetime ,TranAmt money,AffiliateID char(3) obcy kluczowe odniesienia Podmioty stowarzyszone (AffiliateID), klucz podstawowy (TranID,TranDate) )ON PartSch (data transakcji)

Następnie tworzymy zestaw tabel, które możemy wykorzystać do identyfikacji personelu. W tej konfiguracji każdy personel ma ScopeID która określa, w jakim stopniu może przeglądać lub manipulować danymi:

Krajowy – Pracownik może manipulować danymi tylko w kraju pracownika (w którym pracuje)
Regionalne – Pracownik może manipulować danymi tylko w regionie pracownika (np. Afryka Zachodnia)
Globalny – Pracownik może manipulować danymi w dowolnym kraju, w którym bank kiedykolwiek będzie miał oddział

Każdy zakres jest przypisywany pracownikom na podstawie ich przeznaczenia. Zakres menedżera grupy to Globalny , zakres Country Managera jest Regionalny a zasięgiem Kierownika jest Krajowy . Tradycyjnym sposobem ograniczania dostępu do danych jest często wykorzystanie ról i uprawnień. Przypisanie uprawnień do roli, a następnie przypisanie roli użytkownikowi oznacza, że użytkownik ma uprawnienia związane z tą rolą dla całego zestawu danych w danej tabeli. Row Level Security daje nam możliwość zrobienia czegoś bardziej szczegółowego:ogranicz uprawnienia użytkownika SELECT/UPDATE/DELETE do podzbioru zestawu danych w tabeli (dokładna kontrola dostępu).

Rys. 1. StaffScope i stoły pracownicze

Role i użytkownicy bazy danych

Listing 2 pokazuje użytkowników i role, które musimy utworzyć, aby kontynuować nasze rozwiązanie. Pomysł polega na tym, że istnieje relacja między pracownikami przechowywanymi w tabelach użytkowników Staff i StaffScope a głównymi zasadami bazy danych, z których pracownicy będą ostatecznie korzystać w celu uzyskania dostępu do danych. Obserwuj kolumnę na rys. 1 o nazwie DBUserID . Ta kolumna jest wypełniana przy użyciu funkcji DATABASE_PRINCIPAL_ID (patrz Listing 2)

Listing 2 – Personel, identyfikatory użytkowników bazy danych i role — Wypełnij tabelę personelu WACBgoinsert do wartości personelu ('John', 'Edu',DATABASE_PRINCIPAL_ID(), 'Manager','233205678493','2','Accra, Ghana','EGH');wstaw do wartości personelu ('Margaret','Harrison',DATABASE_PRINCIPAL_ID(),'Group Manager','2348030006574','3','Lagos, Nigeria','ENG');wstaw do wartości personelu ('Edward','Antwi',DATABASE_PRINCIPAL_ID(),'Executive','22824567493','1','Lome, Togo','ETG');wstaw do wartości personelu ('Barbara','Orji ',DATABASE_PRINCIPAL_ID(),'Executive','22424567493','1','Abuja, Nigeria','ENG');GO-- Utwórz identyfikatory użytkowników bazy danych dla Staffutwórz użytkownika jedu bez logowania;utwórz użytkownika mharrison bez logowania;utwórz użytkownik eantwi bez loginu;utwórz użytkownika borji bez logowania;-- Powiąż identyfikatory główne bazy danych z zestawem personelu Staffupdate DBUserID=DATABASE_PRINCIPAL_ID(concat(left(imię,1),nazwisko));-- Utwórz role bazy danychcreate role [krajowy];utwórz rolę [Regionalne];utwórz rolę [Global];-- Przyznaj uprawnienia do pożądanej tabeli s do Role bazy danychudziel wyboru klientów na [Krajowy];przyznaj wybór, aktualizacja klientów na regionalną;przyznaj wybór, aktualizacja klientów na globalny;przyznaj wybór transakcji na regionalną, globalną;przyznaj wybór na Transaction_History na regionalną, globalną;przyznaj aktualizację on Transactions to Global;-- Przyznaj role bazy danych użytkownikom bazy danych powiązanym z rolą Staffalter [National] dodaj członka eantwi;alter rolę [National] dodaj członka borji;alter rolę [Regional] dodaj członka jedu;alter rolę [Global] dodaj członka mharrison;

Jak dotąd podsumowując to, co zrobiliśmy, to:

Utwórz/zidentyfikuj tabele, które musimy zabezpieczyć
Utwórz tabele wskazujące kryteria, których będziemy używać do ograniczenia dostępu do danych na poziomie wiersza (zakres)
Utworzone role bazy danych i użytkownicy, wobec których zastosujemy ograniczenia
Ograniczony dostęp do podstawowych tabel („Bezpieczeństwo na poziomie tabeli”) przy użyciu ról i uprawnień

Funkcja przewidywania i polityka bezpieczeństwa

Jak dotąd mamy coś, co możemy nazwać bezpieczeństwem na poziomie tabeli, zaimplementowane przy użyciu ról i uprawnień. Teraz chcemy wejść głębiej. Chcemy, aby dwaj administratorzy, którzy mają uprawnienia SELECT do tabeli, mogli wysyłać zapytania do tabeli, ale widzieli różne zestawy danych w oparciu o ustawione przez nas warunki. Lista 3 pokazuje nam, jak to osiągamy.

Listing 3 - Implementuj zabezpieczenia na poziomie wiersza — Utwórz funkcję predykatuutwórz schemat rls;gocreate funkcja rls.AccessPredicate (@AffiliateID char(3))zwraca tablewith schemabindingasreturn wybierz 1 jako dostęp z dbo.Staff jako s dołącz do dbo.StaffScope ss na s.ScopeID=ss.ScopeID join dbo.Affiliate a on s.AffiliateID=a.AffiliateIDwhere (IS_MEMBER('National')=1and s.DBUserID=DATABASE_PRINCIPAL_ID()and @AffiliateID=s.AffiliateID)OR(IS_MEMBER('Region) ')=1 i @AffiliateID in (wybierz a.AffiliateID z dbo.Affiliates gdzie Region='West Africa'))OR(IS_MEMBER('Global')=1);GO-- Utwórz politykę bezpieczeństwautwórz politykę bezpieczeństwa rls.dataSecurityPoladd predykat filtra rls.AccessPredicate (AffiliateID) na dbo.Customers, dodaj predykat filtra rls.AccessPredicate (AffiliateID) na dbo.Transactions,dodaj predykat filtra rls.AccessPredicate (AffiliateID) na dbo.Transaction_History,dodaj predykat bloku rls.AccessPredicate) (AffidboIDPredicate) .Klienci po aktualizacji dodają predykat blokowy rls.AccessPredicate (Affilia teID) na dbo.Transakcje po aktualizacji, dodaj predykat blokowy rls.AccessPredicate (AffiliateID) na dbo.Transaction_History po aktualizacji;GO-- Polityka bezpieczeństwa Alter Security Policyalter rls.dataSecurityPoladd predykat filtra rls.AccessPredicate (AffiliateID) na dbo.Transaction_History predykat blokowy rls.AccessPredicate (AffiliateID) na dbo.Transaction_History po aktualizacji;GO

Funkcja predykatu definiuje warunki, które muszą być spełnione, aby zleceniodawca mógł zobaczyć podzbiór interesujących danych. W tej funkcji są trzy warunki:

Użytkownik bazy danych Sztabu jest członkiem Narodowego rolę i AffiliateID pasuje do personelu LUB
Użytkownik bazy danych Sztabu jest członkiem Regionalnego rolę i AffiliateID pasuje do listy AffiliateID należy do Regionu Afryki Zachodniej OR
Użytkownik bazy danych Personelu jest członkiem Globalnego

Oznacza to, że członek Globalnego rola widzi wszystkie dane tylko dlatego, że należy do tej roli. Jednak członkowie pozostałych dwóch ról muszą spełniać dodatkowe kryteria graniczące z AffiliateID .

Aby funkcja była użyteczna, zastosuj to do tabel jako predykaty FILTER lub predykaty BLOCK. Predykaty FILTER ograniczają to, co może zobaczyć zleceniodawca, podczas gdy predykaty BLOCK zapewniają, że zleceniodawca nie może manipulować żadnymi danymi poza tymi, które są mu prezentowane przez ograniczenia zdefiniowane w funkcji. Polityka bezpieczeństwa to kontener, w którym określamy predykaty FILTER i BLOCK dla wszystkich interesujących nas tabel. Spójrz na Listing 3 ponownie.

Bardzo interesującym aspektem tego podejścia jest modułowość. Możemy zastosować predykaty do dodatkowych tabel w Security Policy bez wpływu na istniejące już zdefiniowane tabele, możemy dodać nowe podmioty bazy danych (Staff) tworząc użytkowników bazy danych i nadając im odpowiednie role. Gdy nastąpi ruch personelu, możemy zaktualizować przypisania ról i tak dalej.

Testowanie implementacji

Teraz, gdy skończyliśmy, możemy podszywać się pod dyrektorów bazy danych, aby ustalić, czy mamy oczekiwane wyniki, korzystając z kodu z Listingu 4. Zanim to przyjrzymy, spójrzmy na role związane z każdym personelem i jego podmiotami stowarzyszonymi na Rys. 2.

Rys. 2. Lista pracowników

Listing 4 – Testowanie implementacjiselect * od klientów;execute ('wybierz * od klientów') as user='eantwi';execute ('wybierz * od klientów') as user='borji';execute ('wybierz * od klientów') as user='jedu';execute ('wybierz * z klientów') as user='mharrison';

W pierwszym wierszu wysyłam zapytanie do Klientów tabeli jako sysadmin, ale nie dostaję ŻADNYCH WIERSZY. Oznacza to, że nawet administrator nie może obejść skutków RLS bez podszywania się.

Rys. 4. SysAdmin nie widzi żadnych wierszy

Barbara i Edward są zarówno Kierownikami, jak i należą do Krajowego Zasięgu, ale pracują w różnych krajach, więc widzą Klientów powiązanych z ich odpowiednimi podmiotami stowarzyszonymi. (Patrz nazwiska pracowników na rys. 1).

Rys. 5. Kierownicy widzą wiersze swoich partnerów

John i Margaret są menedżerami krajowymi i grupowymi. Należą do regionalnego i Globalne Zakresy odpowiednio. John widzi dane dla Afryki Zachodniej, a Margaret widzi dane dla wszystkich regionów.

Rys. 6. Menedżerowie widzą wiersze swojego regionu

Wyniki są takie same dla wszystkich innych tabel, do których zastosowano politykę bezpieczeństwa. Zauważ, że bez uprawnień w Transakcjach tabeli, zabezpieczenia na poziomie wiersza nie mają żadnej wartości.

Rys. 7. Brak uprawnień SELECT do transakcji Stół

Listing 5 – Uprawnienia do transakcji Tablegrant select na dbo.Transactions do [Krajowy];

Rys. 8. Transakcje Tabela według kadry kierowniczej

Wniosek

Row Level Security to potężna metoda wykorzystania precyzyjnych możliwości kontroli dostępu SQL Server. Korzystanie z tej funkcji wymaga korzystania z programu SQL Server 2016 lub nowszego. Jak sama nazwa wskazuje, celem jest ograniczenie dostępu do wierszy w tabeli za pomocą złożonych zapytań po zadbaniu o „bezpieczeństwo na poziomie tabeli”. Scenariusze, w których można zastosować tę możliwość, są nieskończone, dlatego jest bardzo przydatne w wielu różnych środowiskach. Zrób dobrze, aby zbadać i zobaczyć, co może dla Ciebie zrobić.

Referencje

Isakow, V. (2018). Egzamin nr 70-764 Administrowanie infrastrukturą bazy danych SQL . Edukacja Pearson

Bezpieczeństwo na poziomie wiersza