W tym artykule przyjrzymy się narzędziom bezpieczeństwa SQL Server i sprawdzonym metodom konfigurowania i zabezpieczania tego DBMS..
Treść
- Uwierzytelnianie w SQL Server
- Autoryzacja w SQL Server
- Role aplikacji
- Filtrowanie danych w SQL Server
- Schematy w SQL Server
- Szyfrowanie danych za pomocą SQL Server
- Korzystanie z kont usług zarządzanych przez grupę dla programu SQL Server
- Ocena luki w zabezpieczeniach programu SQL Server za pośrednictwem SSMS
- Kontrola działalności w SQL Server
- Najważniejsze wskazówki dotyczące bezpieczeństwa SQL Server
Najpierw przypomnijmy sobie podstawowe pojęcia bezpieczeństwa SQL Servera. MSSQL kontroluje dostęp do obiektów poprzez uwierzytelnienie i autoryzacja.
- Uwierzytelnianie - Jest to proces logowania do SQL Server, gdy użytkownik prześle swoje dane na serwer. Uwierzytelnianie identyfikuje uwierzytelnionego użytkownika;
- Zaloguj się - jest to proces określania, do których chronionych obiektów użytkownik może uzyskać dostęp i jakie operacje są dozwolone dla tych zasobów.
Wiele obiektów SQL Server ma własne uprawnienia, które można dziedziczyć z obiektu nadrzędnego. Uprawnienia można przyznawać indywidualnemu użytkownikowi, grupie lub roli.
Uwierzytelnianie w SQL Server
Konto SQL Server można podzielić na 2 części: Nazwa logowania i Użytkownik.
- Nazwa logowania - Jest to globalny login dla całej instancji SQL Server. Dzięki niemu przejdziesz proces uwierzytelnienia;
- Użytkownik - jest to członek bazy danych powiązany z określoną nazwą logowania.
Na przykład login do serwera może być domena \ nazwa użytkownika, i użytkownik w bazie danych związany z tym loginem może zostać wywołany domain_databaseUser. Prawie zawsze nazwa użytkownika i nazwa użytkownika w bazie danych pokrywają się z nazwą, ale należy pamiętać, że mogą się różnić, mają różne nazwy.
SQL Server obsługuje 2 tryby uwierzytelnienie:
- Uwierzytelnianie systemu Windows (Uwierzytelnianie systemu Windows) - uwierzytelnianie odbywa się przy użyciu zabezpieczeń systemu Windows. Użytkownicy, którzy są już uwierzytelnieni w systemie Windows i mają uprawnienia do SQL Server, nie muszą podawać dodatkowych danych uwierzytelniających.
- Mieszane uwierzytelnianie (Uwierzytelnianie w trybie mieszanym) - w tym trybie oprócz uwierzytelniania systemu Windows uwierzytelnianie samego programu SQL Server jest obsługiwane za pomocą loginu i hasła.
Microsoft zaleca korzystanie z uwierzytelniania Windows, jeśli to możliwe. W celu uwierzytelnienia za pomocą loginu i hasła dane (login i hasło) są przesyłane przez sieć, aczkolwiek w formie zaszyfrowanej. W przypadku uwierzytelniania systemu Windows szereg zaszyfrowanych wiadomości jest przesyłanych przez sieć, w której hasło użytkownika nie jest zaangażowane..
Ale niektóre aplikacje, zwłaszcza starsze, nie obsługują uwierzytelniania systemu Windows, dlatego przy ustawianiu trybu uwierzytelniania warto zastanowić się, które aplikacje połączą się z serwerem.
SQL Server obsługuje trzy typy Nazwa logowania (nazwy logowania):
- Konto lokalne Użytkownik lub konto systemu Windows domena/ zaufana domena.
- Grupa Windows. Udzielanie dostępu do lokalnej grupy Windows lub grupy z domeny AD. Umożliwia dostęp do wszystkich użytkowników będących członkami grupy.
- Logowanie do SQL Server (Uwierzytelnianie programu SQL Server). SQL Server przechowuje skrót nazwy użytkownika i hasła w bazie danych mistrz, za pomocą wewnętrznych metod uwierzytelniania w celu weryfikacji logowania.
SQL Server automatycznie integruje się z Active Directory. Jeśli chcesz rozdzielić prawa do konta domeny, musisz użyć nazwy domeny NetBios i loginu do konta. Na przykład dla nazwy użytkownika w domenie.lokalny będzie „domena \ nazwa użytkownika”.
Autoryzacja w SQL Server
Do autoryzacji SQL Server używa zabezpieczeń opartych na rolach, które pozwalają przypisywać uprawnienia do roli lub grupy / domeny systemu Windows, a nie do poszczególnych użytkowników. SQL Server ma wbudowane role serwera i bazy danych, które mają predefiniowany zestaw uprawnień.
Istnieją 3 poziomy bezpieczeństwa w SQL Server; mogą być reprezentowane jako hierarchia od najwyższej do najniższej:
- Poziom serwera - na tym poziomie możesz rozpowszechniać prawa do baz danych, kont, ról serwerów i grup dostępności;
- Poziom bazy danych obejmują schematy, użytkowników bazy danych, role baz danych i katalogi pełnotekstowe;
- Poziom obwodu obejmują obiekty, takie jak tabele, widoki, funkcje i procedury składowane.
Wbudowane role serwera
| Rola | Opis |
| sysadmin | Członek roli ma pełne prawa do wszystkich zasobów SQL Server. |
| serveradmin | Członkowie roli mogą zmieniać ustawienia konfiguracji na poziomie serwera i wyłączać serwer. |
| securityadmin | Uczestnicy roli zarządzają loginami i ich właściwościami. Mogą przyznawać prawa dostępu GRANT, DENY i REVOKE na poziomie serwera i na poziomie bazy danych, jeśli mają do niego dostęp. securityadmin niewiele różni się od roli sysadmin, ponieważ członkowie tej roli mogą potencjalnie uzyskać dostęp do wszystkich zasobów SQL Server. |
| procesadmin | Uczestnicy roli mogą zakończyć procesy uruchomione w SQL Server. |
| setupadmin | Członkowie roli mogą dodawać i usuwać połączone serwery za pomocą TSQL. |
| bulkadmin | Członkowie roli mogą uruchamiać operacje BULK INSERT. |
| diskadmin | Członkowie roli mogą zarządzać urządzeniami do tworzenia kopii zapasowych. W praktyce rola ta praktycznie nie jest stosowana.. |
| dbcreator | Członkowie roli mogą tworzyć, modyfikować, usuwać i przywracać bazy danych. |
| publiczne | Każde logowanie do SQL Server ma tę rolę. Członkostwa publicznego nie można zmienić. Gdy użytkownik nie ma uprawnień do obiektu, do którego ma dostęp, dziedziczy uprawnienia roli publicznej dla tego obiektu. |
Schemat roli programu SQL Server:
W praktyce użycie ról serwera nie jest szczególnie powszechne, ponieważ często użytkownik potrzebuje unikalnego zestawu uprawnień. Wyjątkiem może być rola sysadmin dla administratorów systemu i rola publiczna.
Wbudowane role bazy danych
| Rola | Opis |
| db_owner | Uczestnicy roli mogą wykonać wszystkie kroki, aby skonfigurować i utrzymywać bazę danych, w tym usunięcie. |
| db_securityadmin | Członkowie roli mogą zmieniać członkostwo innych ról. Członkowie tej grupy mogą potencjalnie zwiększyć swoje uprawnienia do właściciela_db, dlatego należy uznać tę rolę za równoważną z właścicielem_db. |
| db_accessadmin | Członkowie roli mogą kontrolować dostęp do bazy danych dla istniejących danych logowania na serwerze. |
| db_backupoperator | Członkowie roli mogą tworzyć kopię zapasową bazy danych. |
| db_ddladmin | Członkowie roli mogą wykonywać dowolne polecenia DDL w bazie danych. |
| db_datawriter | Członkowie roli mogą tworzyć / modyfikować / usuwać dane we wszystkich tabelach użytkowników w bazie danych. |
| db_datareader | Członkowie roli mogą odczytywać dane ze wszystkich tabel użytkowników. |
| db_denydatawriter | |
| db_denydatareader | Członkowie roli odmówili dostępu do tabel bazy danych użytkowników. |
Warto również osobno podkreślić specjalne role w bazie danych msdb.
| db_ssisadmin db_ssisoperator db_ssisltduser | Członkowie tych ról mogą administrować SSIS (SQL Server Integration Services) i korzystać z nich. |
| dc_admin dc_operator dc_proxy | Członkowie tych ról mogą administrować modułem gromadzącym dane i korzystać z niego.. |
| PolicyAdministratorRole | Członkowie tej roli mają pełny dostęp do zasad programu SQL Server. |
| ServerGroupAdministratorRole ServerGroupReaderRole | Członkowie tych ról mają pełny dostęp do zarejestrowanych grup serwerów.. |
| SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole | Członkowie tych ról mają pełny dostęp do zadań agenta SQL Server. |
Schemat wbudowanych ról bazy danych w programie SQL Server:
Role aplikacji
Rola aplikacji to obiekt bazy danych (taki sam jak zwykła rola bazy danych), który umożliwia uwierzytelnianie hasłem w celu zmiany kontekstu bezpieczeństwa w bazie danych. W przeciwieństwie do ról bazy danych, role aplikacji są domyślnie nieaktywne i są aktywowane, gdy aplikacja wykonuje sp_setapprole i wprowadza odpowiednie hasło.
W przeciwieństwie do zwykłych ról role aplikacji prawie nigdy nie są używane. Jako wyjątek, ich zastosowanie można znaleźć w aplikacjach wielowarstwowych..
Filtrowanie danych w SQL Server
Filtrowanie danych w SQL Server przez procedury składowane / widoki / funkcje można przypisać realizacji zasady najmniejszych uprawnień, ponieważ nie zapewniasz dostępu do wszystkich danych w tabeli, ale tylko do niektórych z nich.
Na przykład możesz przyznać użytkownikowi tylko uprawnienia SELECT z widoku i uniemożliwić bezpośredni dostęp do tabel używanych w widoku. W ten sposób zapewnisz dostęp tylko do części danych z tabeli, ustawiając filtr where w widoku.
Filtrowanie danych przez zabezpieczenia na poziomie wiersza
Bezpieczeństwo na poziomie wiersza lub Bezpieczeństwo na poziomie wiersza (RLS) pozwala filtrować dane tabeli dla różnych użytkowników według niestandardowego filtra. Odbywa się to poprzez POLITYKĘ BEZPIECZEŃSTWA w języku T-SQL
Na tym zrzucie ekranu zasady są skonfigurowane w taki sposób, że użytkownik Sales1 zobaczy wiersze tabeli, w której wartością kolumny Sales jest nazwa użytkownika (Sales1), a użytkownik Manager zobaczy wszystkie wiersze.
Schematy w SQL Server
Niektóre obiekty SQL Server (tabele, procedury, widoki, funkcje) mają schemat. Schematy można traktować jako kontenery dla różnych obiektów (lub przestrzeń nazw, jeśli znasz programowanie).
Na przykład, jeśli użytkownik ma uprawnienia do wybierania ze schematu, wówczas może również wybierać spośród wszystkich obiektów tego schematu. Oznacza to, że obiekty należące do schematu dziedziczą jego uprawnienia. Gdy użytkownicy tworzą obiekty na diagramie, obiekty należą do właściciela diagramu, a nie do użytkownika. Uprawnienia nie są dziedziczone z systemu przez użytkowników. Tj. użytkownicy z domyślnym schematem dbo nie mają uprawnień przyznanych temu schematowi - muszą zostać wyraźnie określone.
Główną różnicą między schematami i rolami jest to, że uprawnienia do schematu mogą być przyznawane rolom. Na przykład rola testrole może mieć uprawnienia do wybierania ze schematu 1 i uprawnienia do wybierania / aktualizacji na schemacie 2. Obiekt może należeć tylko do jednego schematu, ale kilka ról może mieć do niego prawa.
Obwody osadzone
SQL Server ma wbudowane schematy systemowe:
- dbo
- gość
- sys
- INFORMACJE_SCHEMA
Schemat dbo jest domyślnym schematem dla nowych baz danych, a użytkownik dbo jest właścicielem schematu dbo. Domyślnie nowi użytkownicy w bazie danych mają schemat dbo jako schemat domyślny. Inne wbudowane schematy są potrzebne dla obiektów systemowych SQL Server..
Szyfrowanie danych za pomocą SQL Server
SQL Server może szyfrować dane, procedury i połączenia z serwerem. Szyfrowanie jest możliwe przy użyciu certyfikatu, klucza asymetrycznego lub symetrycznego. SQL Server używa modelu szyfrowania hierarchicznego, to znaczy każda warstwa hierarchii szyfruje warstwę pod nią. Obsługiwane są wszystkie znane i popularne algorytmy szyfrowania. Do implementacji algorytmów szyfrowania wykorzystywany jest interfejs Windows Crypto API..
Najczęstsze rodzaje szyfrowania to TDE (Transparent Data Encryption) i Always Encrypted.
Przejrzyste szyfrowanie danych
Przejrzyste szyfrowanie danych lub Przejrzyste szyfrowanie danych szyfruje całą bazę danych. W przypadku kradzieży nośnika fizycznego lub pliku .mdf / .ldf osoba atakująca nie będzie mogła uzyskać dostępu do informacji w bazie danych.
Wykres, aby przedstawić cały proces
Podstawowe szyfrowanie bazy danych za pomocą T-SQL:
USE master;
GO
UTWÓRZ GŁÓWNE SZYFROWANIE KLUCZEM WEDŁUG HASŁA = „hasło”;
idź
UTWÓRZ CERTYFIKAT ServerCert Z SUBJEKTEM = „DEK Certificate”;
idź
USE AdventureWorks2012;
GO
UTWÓRZ KLUCZ SZYFROWANIA BAZY DANYCH
Z ALGORYTMEM = AES_128
SZYFROWANIE CERTYFIKATU SERWERA ServerCert;
GO
ZMIEŃ BAZY DANYCH AdventureWorks2012
WŁĄCZ SZYFROWANIE;
GO
Zawsze szyfrowane
Ta technologia umożliwia przechowywanie zaszyfrowanych danych w SQL Server bez przesyłania kluczy szyfrowania do samego SQL Server. Zawsze szyfrowane, podobnie jak TDE, szyfruje dane w bazie danych, ale nie na poziomie bazy danych, ale na poziomie kolumny.
Do szyfrowania Always Encrypted używa 2 kluczy:
- Klucz szyfrowania kolumny (CEK)
- Klucz główny kolumny (CMK)
Wszystkie procesy szyfrowania i deszyfrowania danych odbywają się na kliencie, tylko zaszyfrowana wartość klucza szyfrowania (CEK) jest przechowywana w bazie danych.
Zawsze zaszyfrowane pozwala również ograniczyć dostęp do danych, nawet w przypadku DBA, co daje możliwość martwienia się, że administrator uzyska dostęp do danych, które nie powinny.
Kiedy używać szyfrowania SQL Server?
Szyfrowanie danych jest jednym z ważnych środków bezpieczeństwa, ale szyfrowanie może wymagać zasobów serwera, a czasem może być zbyteczne..
Jeśli użytkownicy uzyskują dostęp do danych za pośrednictwem sieci publicznej, może być konieczne szyfrowanie w celu zapewnienia bezpieczeństwa, ale jeśli dane są przesyłane za pośrednictwem bezpiecznego intranetu lub sieci VPN, nie ma potrzeby szyfrowania danych. Warto również rozważyć możliwość szyfrowania danych, jeśli istnieje zagrożenie kradzieżą fizycznych nośników danych.
Wdrożenie szyfrowania powinno być dobrze zaplanowane: należy wziąć pod uwagę dodatkowe obciążenie serwera, czy aplikacje współpracujące z serwerem mogą implementować obsługę tego rodzaju szyfrowania po swojej stronie i wiele innych niuansów.
Korzystanie z kont usług zarządzanych przez grupę dla programu SQL Server
Konta usług zarządzanych przez grupę lub gMSA - To jest specjalne konto, które jest automatycznie zarządzane przez Active Directory. gMSA jest ewolucją technologii MSA, ponieważ MSA nie było możliwe do zastosowania w scenariuszach klastrowych.
gMSA eliminuje potrzebę ręcznej zmiany haseł do konta. Podczas konfigurowania gMSA wskazujesz, na których serwerach konto gMSA będzie uruchamiane, jak często Active Directory zmieni hasło i kto ma prawo do przeglądania hasła. Na serwerach, na których zostanie zainstalowany gMSA, nie trzeba podawać hasła podczas określania odpowiedniego konta gMSA.
Należy pamiętać, że wersja systemu Windows Server do pracy z gMSA musi być co najmniej 2012.
Ocena luki w zabezpieczeniach programu SQL Server za pośrednictwem SSMS
SQL Server Management Studio ma funkcję oceny podatności bazy danych..
Wybierz bazę danych -> Zadania -> Ocena podatności -> Skanuj w poszukiwaniu luk.
Skaner oceni bazę danych pod kątem popularnych błędów w konfiguracji zabezpieczeń i wyda odpowiednie zalecenia..
Zdecydowanie powinieneś przejść przez ten skaner bazy danych za pomocą tego skanera. Może ujawnić ukryte problemy, które nie są widoczne na pierwszy rzut oka..
Kontrola działalności w SQL Server
SQL Server zapewnia możliwość inspekcji dowolnej aktywności użytkownika w instancji serwera.
Jest to bardzo potężne narzędzie, które pozwala w pełni kontrolować działania użytkowników / programistów..
Rozważ podstawową konfigurację audytu:
W SSMS, na karcie Bezpieczeństwo -> Audyty, utwórz nowy audyt.
Następnie w celu przeprowadzenia kontroli musisz utworzyć specyfikację kontroli, aby wskazać zdarzenia, które będą monitorowane.
Po utworzeniu i aktywacji audytu w dzienniku kontroli można zobaczyć zdarzenia zarejestrowane przez procedurę kontroli..
Najważniejsze wskazówki dotyczące bezpieczeństwa SQL Server
Zawsze przestrzegaj zasady najmniejszych przywilejów. W tym skonfiguruj konto usługi SQL Server za pomocą gMSA. Nigdy nie używaj konta domeny z uprawnieniami administratora domeny..
Zasada najmniejszych uprawnień
Podczas tworzenia nowych użytkowników zaleca się stosowanie zasady LUA (Najmniej uprzywilejowane konto użytkownika lub Konto Least Rights) Ta zasada jest ważną częścią bezpieczeństwa serwera i danych..
W przypadku użytkowników z uprawnieniami administracyjnymi zaleca się wydawanie uprawnień tylko dla tych operacji, których będą potrzebować. Roli serwera wbudowanego należy używać tylko wtedy, gdy ich zestaw uprawnień odpowiada zadaniom użytkownika..
Nadawanie ról, a nie użytkowników
Gdy jest wielu użytkowników, zarządzanie ich uprawnieniami staje się trudniejsze, a także trudniejsze jest zapobieganie błędom w przyznawaniu uprawnień.
Zaleca się przyznanie uprawnień do ról i dodanie użytkowników do ról. W ten sposób uzyskasz większą przejrzystość, ponieważ wszyscy użytkownicy określonej roli będą mieli te same prawa. Dodawanie lub usuwanie użytkowników z roli jest łatwiejsze niż ponowne tworzenie indywidualnych zestawów uprawnień dla poszczególnych użytkowników. Role można zagnieżdżać, ale nie jest to zalecane ze względu na mniejszą przezroczystość i potencjalne obniżenie wydajności (jeśli jest zbyt wiele zagnieżdżonych ról).
Możesz przyznać prawa użytkownika do programu. W takim przypadku użytkownicy będą mogli natychmiast pracować z nowo utworzonymi obiektami w tym schemacie, w przeciwieństwie do ról, podczas tworzenia nowego obiektu role będą musiały uzyskać do niego uprawnienia.
