Row Level Security w SQLAzure v12

W poprzednim poście opisującym nowości SQLAzure v12 wspominałem o nowej funkcjonalności dotyczącej bezpieczeństwa, o Row Level Security (RLS). W tym poście chciałem przybliżyć tą funkcjonalność na konkretnym przykładzie.

Chcąc przeprowadzić taki test musimy posiadać bazę danych SQLAzure utworzoną na serwerze zgodnym z wersją v12. Na portalu Microsoft Azure widać to przy liście serwerów, tak jak na poniższym obrazku.

Chcąc przetestować działanie Row Level Security, – czyli bezpieczeństwa na poziomie wiersza, założymy trzech przykładowych użytkowników. Biznesowo byliby to dwaj sprzedawcy i jeden kierownik. Każdy ze sprzedawców wprowadza swoje dane sprzedażowy i każdy z nich może oglądać tylko wiersze, które wstawił, kierownik może zobaczyć wszystkie transakcje.

Zakładamy 3 użytkowników

Tworzymy tabelę sprzedaży – Sales, w której jedna z kolumn przechowuje nazwę użytkownika wstawiającego dane.

Następnie tabelę Sales wypełniamy przykładowymi danymi

Kolejnym krokiem jest nadanie stosownych praw użytkownikom do tabeli Sales, by mogli ją przeglądać.

W tym momencie wykonują zapytanie w kontekście dowolnego z tych użytkowników otrzymujemy wynik zawartości całej tabeli.

Przechodzimy, więc do zarządzania bezpieczeństwem poprzez RLS. W tym celu musimy utworzyć SCHEME

Następnie tworzymy funkcję identyfikującą użytkownika

W tym wypadku działa ona w ten sposób, jeżeli @SalesRep zgodne z nazwą użytkownika, lub nazwą użytkownika jest Kierownik funkcja zwraca wartość 1. Utworzoną w ten sposób funkcję wykorzystujemy w tworzonej polisie bezpieczeństwa.

Sprawdźmy teraz jak zadziała taka polisa na danych w tabeli Sales. W tym celu uruchomimy takie samo zapytanie w 3 różnych kontekstach uruchomienia.

Wynik takich trzech zapytań jest następujący

W pierwszym i drugim przypadku otrzymaliśmy tylko dane dotyczące poszczególnych sprzedawców, natomiast w przypadku trzecim, gdy zapytanie wykonywał Kierownik są widoczne wszystkie informację.

Zróbmy teraz test na modyfikację danych. W tym celu nadajemy prawa na modyfikację tabeli.

Następnie wykonujemy polecenie modyfikacji danych w kontekście Sprzedawcy1, oraz zweryfikujemy cały zbiór w kontekście Kierownika.

Wynik takiego działania

Jak widać na powyższym wyniku, mimo, że Sprzedawca1 nie ograniczał zbioru w poleceniu modyfikacji danych, uległy zmianie jedynie rekordy, do których ma dostęp.

Spróbujmy dokonać zmiany wprost podając rekord, do których nie ma prawa Sprzedawca1.

Otrzymujemy następujący rezultat.

Jak widać modyfikacja się nie udała. Co potwierdza komunikat

Podobnie sytuacja wygląda z poleceniem DELETE.

 

Myślę, że wielu osobom spodobał się mechanizm RLS, niestety nie ma obecnie go jeszcze w rozwiązaniu SQL Server on-premise. RLS ma kilka ograniczeń, nie wspiera In-Memory OLTP, Change Data Capture, oraz Full Text Search. Również polecenie DBCC SHOW_STATISTICS może spowodować podgląd danych.

Share this article ...

Google Plus
Ihren LinkedIn Kontakten zeigen



This entry was posted in Azure, Security and tagged , , , , , by Lukasz Grala. Bookmark the permalink.
Lukasz Grala

About Lukasz Grala

A Data Platform and Business Intelligence architect and consultant. An authorized Microsoft trainer and university lecturer. A holder of numerous Microsoft certificates, since 2010 Microsoft Most Valuable Professional (MVP) in the SQL Server category. An author of articles and webcasts available on TechNet portal. He runs two blogs, SQL Research and PowerPivot’s Blog. The author of various trainings and a speaker at numerous IT conferences, as well as the Polish SQL Server User Group (PLSSUG) leader.

One thought on “Row Level Security w SQLAzure v12

Leave a Reply

Connect with:
  • This field its required.
  • This field its required.
    • Message is required