DBA jest strażnikiem danych i istnieją dwa aspekty bycia strażnikiem. Pierwsza to uczciwość. Obejmuje takie zadania, jak sprawdzanie spójności bazy danych, tworzenie kopii zapasowych oraz, w przypadku wystąpienia jakichkolwiek problemów, posiadanie dobrze zaprojektowanego, kompleksowego planu odzyskiwania bazy danych.
Drugi aspekt to bezpieczeństwo. Sugeruje upewnienie się, że tylko upoważnieni użytkownicy mają dostęp do danych i tylko do tych danych, których potrzebują.
W sieci można znaleźć wiele zasobów poświęconych bezpieczeństwu. Myślę jednak, że niektórym ważnym rzeczom brakuje należytej uwagi. W tym artykule chciałbym skupić się na tych opcjach i pokazać, dlaczego ważne jest, aby być ich świadomym i prawidłowo się z nimi obchodzić.
Misja polegająca na skompromitowaniu serwera SQL
Zróbmy grę fabularną, w której jesteś tajnym agentem, a twoją misją, jeśli ją zaakceptujesz, jest kradzież bardzo ważnych danych z TargetDB baza danych obsługiwana przez serwer SQL. Musisz uzyskać te dane i je usunąć.
Możliwe jest uzyskanie loginu dla Ciebie, ale każde logowanie na serwerze ma jawne ZABRONIONE uprawnienia do docelowej bazy danych i danych. Jedyne informacje, które nasz agent może Ci przekazać, to te, które zostały wygenerowane do weryfikacji przez protokół bezpieczeństwa podczas tworzenia Twojego loginu.
Informacje o bazie danych z serwera docelowego.
Uprawnienia serwera:
Uprawnienia do bazy danych:
Jak każdy porządny agent, odróbmy zadanie domowe i sprawdźmy, z czym masz do czynienia.
Nie możesz po prostu zalogować się i połączyć z TargetDB , ponieważ każde pojedyncze uprawnienie do logowania jest odmawiane, a jego zmapowany użytkownik jest jawnie. Musisz uzyskać dostęp z innej bazy danych.
Zamknięte drzwi
Akcje między bazami danych nie są łatwe do wykonania. Potraktuj to jako zamknięte drzwi z dwoma zamkami. Nie skupimy się tutaj na szczegółach technicznych, ale możesz zapoznać się z artykułem Rozszerzanie personifikacji bazy danych przy użyciu EXECUTE AS MSDN (bardzo polecam to zrobić).
Pierwsza blokada to Zaufanie do uwierzytelniacza , a drugi to Zaufanie do bazy danych .
Zacznijmy od pierwszego zamka. Zaufanie do strony uwierzytelniającej oznacza, że aby uzyskać dostęp do innej bazy danych B, właściciel bazy danych A musi otrzymać (jawnie lub niejawnie) AUTENTYKUJ uprawnienia w bazie danych B.
Poczekaj minutę! Uwierzytelniający na poziomie bazy danych jest właścicielem samej bazy danych (nie mieszaj jej z db_owner rola bazy danych!).
Sprawdź właścicieli bazy danych:
Mimo że stosują całkiem dobrą praktykę, używając jednego konta na serwer, co nie jest SA , w ten sposób uprzejmie otworzyli dla ciebie pierwszy zamek.
Skupmy się na drugim zamku.
Jakoś musisz mieć bazę danych utworzoną na serwerze z ZAUFANYM właściwość WŁĄCZONA . Najlepszą praktyką jest tutaj ustawienie właściwości bazy danych ZAUFANE na WYŁ .
To jest czas, w którym powinniśmy powiedzieć:co, jeśli masz już taką bazę danych?
Jest to baza danych MSDB.
Drugi zamek jest gotowy. Nie trzeba było nawet łamać żadnego z zamków.
Znaczenie roli db_owner
W tej chwili masz do czynienia z jednym wyzwaniem. Jakoś musisz dostać się do bazy danych MSDB za pomocą db_owner rolę bazy danych, ponieważ ma niejawne uprawnienia personifikacji.
Ponieważ MSDB zwykle nie jest w centrum zainteresowania administratorów baz danych, misja ta nie jest już niemożliwa. Zobaczmy, co możesz zrobić tylko dlatego, że masz użytkownika z db_owner rola bazy danych w bazie danych MSDB:
Spróbuj połączyć się z Docelową bazą danych :
To jest oczekiwany błąd. Zapamiętaj protokół bezpieczeństwa zastosowany do podanego loginu. Zacznijmy.
Spróbuj połączyć się z Docelową bazą danych i aby wybrać dane docelowe:
To działa! Zmodyfikujmy to, a następnie zweryfikujmy działanie.
To wszystko.
Misja zakończona.
Jak widzieliście, skupiłem się na konkretnej kombinacji konfiguracji bazy danych bezpieczeństwa. Byli to właściciele bazy danych i ZAUFANE opcja bazy danych zwracając szczególną uwagę na MSDB. Przedstawiony scenariusz był tylko takim, w którym wrażliwe dane mogą zostać naruszone w ten sam sposób. Przyjrzyjmy się teraz kolejnemu możliwemu scenariuszowi.
Właściciel bazy danych + GODNY ZAUFANIA
Sprawdźmy szczegóły tła, zaczynając od dobrze znanego problemu:własności bazy danych. Jakich danych logowania powinien używać właściciel Twoich baz danych? Wiele osób twierdzi, że SA jest właściwym wyborem.
Przeszukałem szybko Google i znalazłem odpowiedzi podobne do następujących:
„Nie pamiętam, żeby kiedykolwiek było to dla mnie problemem. Poza tym, że wygląda na irytującego w raportach lub nie jest w stanie usunąć użytkownika, jeśli jest właścicielem bazy danych, ale nie sądzę, że wpływa to na operacje serwera. Możesz po prostu wybrać sa dla spójności”.
Lub
„Nie sądzę, że posiadanie bazy danych przez SA lub jakikolwiek inny użytkownik powinno być problemem. Liczy się to, kto „co” wykonuje w Twojej bazie danych. Dlatego dobrym pomysłem jest tworzenie użytkowników z ważnymi uprawnieniami. Dla uproszczenia możesz określić właściciela jako SA”.
Obecna sytuacja jest taka, że używanie konta SA jako właściciela bazy danych jest NAJGORSZĄ praktyką . Osobiście uważam, że powinno to być podkreślone na każdym blogu i w każdej dokumentacji związanej z tym tematem.
Jeśli tworzymy użytkowników tylko z ważnymi uprawnieniami, to wystarczy, ale niestety nie tak to zwykle działa. Musisz być przygotowany na „możliwe najgorsze” scenariusze. Pomyśl tylko, co moglibyśmy zrobić w naszych wcześniejszych przykładach, gdyby domyślnym właścicielem bazy danych był SA !
Przejdźmy do drugiej opcji, GODNEJ ZAUFANIA opcja bazy danych. Sytuacja jest nieco lepsza, ale nadal ma wspólny problem. Jak się powszechnie uważa, najlepszą praktyką jest ustawienie właściwości bazy danych „Wiarygodna” na Wył. . Właśnie widzieliśmy, dlaczego ta opcja jest zła .
Ale to nie wszystko. Jeśli spróbujesz znaleźć jakieś skrypty do sprawdzenia tej właściwości, prawdopodobnie znajdziesz skrypt podobny do tego:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'sp_Blitz Skrypt sprawdzający kondycję SQL Server sprawdza również domyślne ustawienia baz danych (w tym ZAUFANIE jako domyślną wartość 0) i zgłasza każdą bazę danych, która ma inne ustawienia niż domyślne. Jednak skrypt pomija systemowe bazy danych.
Ponadto istnieje artykuł MS KB, który koncentruje się na tym temacie. Zapoznaj się z wytycznymi dotyczącymi korzystania z ustawień zaufanej bazy danych w programie SQL Server:
W artykule znajduje się przykładowy kod, który zawiera listę baz danych z włączonym bitem ZAUFANIE i których właściciele baz danych należą do roli serwera sysadmin:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
Co jest wspólne w tych skryptach? Każdy skrypt wyklucza bazę danych MSDB, ale jak zauważa artykuł MS KB, właśnie widzieliście go w naszej „misji”:
Uwaga :Domyślnie ustawienie ZAUFANE jest włączone dla bazy danych MSDB. Zmiana tego ustawienia z wartości domyślnej może spowodować nieoczekiwane zachowanie składników SQL Server, które korzystają z bazy danych MSDB.
Chciałbym podkreślić, że głównym tematem tej sekcji nie jest opcja bazy danych ZAUFANE ani sama właściwość właściciela bazy danych, ale połączenie tych dwóch opcji. Skupiłem się głównie na MSDB, ponieważ ustawienie WARTO WIEDZIEĆ jest domyślnie włączone dla bazy danych MSDB.
Wniosek
To wszystko na teraz. Przejrzeliśmy i sprawdziliśmy praktyczne scenariusze związane z bezpieczeństwem SQL Server. Przeanalizowaliśmy również takie ważne opcje bazy danych, jak właściciel bazy danych i ustawienie bazy danych WARTO WIEDZIEĆ.
Chciałem tylko zwrócić uwagę na te opcje, ponieważ – ponieważ są one krytyczne, zwłaszcza gdy mówimy o nich w połączeniu.
