Bezpieczeństwo serwera zależy głównie od tego, jak poprawnie możesz skonfigurować uprawnienia dostępu do obiektów. Nadanie użytkownikowi nadmiernych uprawnień może spowodować wiele problemów. Nie, użytkownik nie wykorzysta Twoich błędów. Zamiast tego zrobi to każdy haker lub ja. W takim przypadku możesz zapomnieć o swoich tabelach z danymi lub o całej bazie danych.
Z jakiegoś powodu bezpieczeństwo bazy danych to ochrona z zewnątrz, np. haker. Jednak zdarza się to bardzo rzadko. Jestem programistą w dużej firmie, a administrator nawet nie myśli o ochronie portów serwera, gdzie wszystko jest otwarte. Na jednym serwerze znajduje się wiele baz danych, programów, a nawet serwer FTP, który nigdy nie został zhakowany przez ostatnie 5 lat. Na szczęście udało mi się namówić administratora na wdrożenie serwera WEB na osobnym sprzęcie. W przeciwnym razie, gdyby ktoś znał adres IP naszego głównego serwera, każdy próżniak byłby w stanie go zhakować. Ani baza danych, ani system Windows nie były łatane od kilku lat.
Jednak codziennie pojawiają się problemy wewnętrzne z powodu nieprawidłowej polityki bezpieczeństwa. Wszyscy użytkownicy logują się z uprawnieniami administratora i mogą tworzyć co tylko chcą. To prawdziwy problem, ponieważ nadmierne uprawnienia pozwalają próżniakom pokazywać swój całkowity analfabetyzm. Dlatego rozważymy bezpieczeństwo niezależnie od tego, skąd pochodzi zagrożenie – od hakera czy od użytkownika.
W tym artykule omówimy wszystkie niezbędne podstawy ochrony przed hakerami i użytkownikami. Jako przykład wybrałem MS SQL Server, ponieważ zawiera on wszystko, co jest dostępne w innych bazach danych (Oracle, MySQL itp.) i ma dodatkowe możliwości zarządzania bezpieczeństwem. Ktoś mógłby pomyśleć , że to sprawia, że stwardnienie rozsiane staje się bardziej strome. Czasami jednak dodatkowe funkcje mogą być nadmierne, powodując problemy.
Role serwera
W systemie Windows i innych systemach operacyjnych uprawnieniami zarządzają grupy i użytkownicy. Możemy połączyć użytkowników w grupę i nadać uprawnienia wszystkim na raz, co jest znacznie prostsze niż nadawanie uprawnień każdemu użytkownikowi z osobna. W tym celu w bazach danych istnieje pojęcie „rola”.
Załóżmy, że 100 użytkowników ma mieć uprawnienia do odczytu danych z określonej tabeli. Nadanie każdemu użytkownikowi tego uprawnienia jest kłopotliwe. Dużo prościej jest stworzyć rolę, którą można czytać, a następnie dodać do niej wszystkich wymaganych użytkowników. Wynik jest podobny do grupowania.
W SQL Server istnieją dwa rodzaje ról:serwer i baza danych. Role serwera są wstępnie zdefiniowane i nie można ich zmienić.
Otwórz gałąź Security/Server role w Enterprise Manager, aby zobaczyć listę dostępnych ról w prawej części okna. Opis określa, co użytkownik może zrobić z odpowiednią rolą.
Role serwera w MS SQL Server i okno menedżera ról
Aby dodać istniejącego użytkownika do roli, kliknij dwukrotnie wiersz roli. W wyświetlonym oknie możesz dodać użytkowników do roli lub ich usunąć. Zakładka Uprawnienia opisuje szczegółowo, co każdy użytkownik może zrobić.
Użytkownicy
Aby zarządzać użytkownikami, otwórz gałąź Bezpieczeństwo/Loginy w Enterprise Manager. W prawej części zobaczysz listę wszystkich użytkowników serwera. Domyślnie dostęp jest przyznawany administratorom domeny i wbudowanym kontom logowania, takim jak sa.
Aby dodać nowego użytkownika, kliknij prawym przyciskiem myszy gdziekolwiek w pustej prawej części okna i wybierz Nowy login z menu, które się pojawi. Na samej górze okna wybierz nazwę użytkownika. Jeśli chcesz wybrać istniejącą domenę lub użytkownika komputera, kliknij przycisk (...) po prawej stronie pola wejściowego, a zobaczysz pole wyszukiwania użytkownika w domenie.
Dodawanie nowego użytkownika
Poniżej możesz wybrać rodzaj uwierzytelniania – Windows lub SQL Server. Jeśli wybierzesz Windows, nie musisz podawać hasła, ponieważ serwer pobierze je z systemu. Możesz jednak przełączyć opcję Udziel dostępu (zezwól na dostęp) lub Odrzuć dostęp (zabroń). W tym drugim przypadku użytkownik zostanie zarejestrowany w bazie danych, ale nie będzie mógł się połączyć – jest to zabronione.
Jeśli wybierzesz uwierzytelnianie SQL Server, będziesz musiał ustawić hasło, ponieważ w tym przypadku będzie ono przechowywane w tabelach systemowych serwera bazy danych. Pamiętaj, że nawet jeśli w ustawieniach serwera określono tylko uwierzytelnianie Windows, możesz tworzyć rekordy serwera SQL, ale nie będziesz mógł zalogować się do systemu za pomocą tych rekordów.
Na karcie Role serwera możesz określić, jaka rola serwera zostanie przyznana użytkownikowi. Dlatego nawet na etapie tworzenia możesz dodać użytkowników do niezbędnych ról.
Dostęp użytkownika do baz danych
Na karcie Dostęp do bazy danych określ bazy danych, z którymi użytkownik może pracować. W tym miejscu okno podzielone jest na dwie części:w górnej połowie możesz wybrać bazę danych, do której masz dostęp, a na dolnej liście możesz wybrać rolę bazy danych. Ta rola w bazie danych zdefiniuje uprawnienia użytkownika. Jednemu użytkownikowi można przypisać kilka ról.
Utwórz konto qq, które będzie miało dostęp do bazy danych Northwind. To jest standardowa testowa baza danych tworzona podczas wdrażania serwera.
Zapisz zmiany.
Teraz otwórz gałąź Databases/Northwind/Users i zobacz listę użytkowników, którzy mają dostęp do wybranej bazy danych. Zwróć uwagę, że tutaj jest konto qq. Nie ma konta w innych bazach danych, ponieważ dostęp do nich dla naszego nowego użytkownika jest zabroniony.
Role bazy danych
Każda baza danych może mieć własne role, które definiują uprawnienia dostępu do obiektów. Wielu administratorów nie lubi zawracać sobie głowy tymi uprawnieniami. W ten sposób instalują wbudowaną domyślną publiczną, która pozwala na prawie wszystko. Jeśli brakuje uprawnień do roli publicznej, po prostu dodaj użytkownika do roli administratora systemu. W takim przypadku baza danych staje się podatna na ataki.
Każdy użytkownik powinien mieć własne i niezbędne uprawnienia. To, co nie jest dozwolone, musi być zabronione. Nie wolno używać ról, które już istnieją na serwerze, ponieważ ich uprawnienia są otwarte dla wszystkich. Zaleca się nawet usunięcie ich wszystkich, zwłaszcza publicznych.
Tworzenie roli
Aby utworzyć nową rolę bazy danych, kliknij prawym przyciskiem myszy gałąź Bazy danych/Nazwa bazy danych/Role. W wyświetlonym menu wybierz Nowa rola bazy danych. Otworzy się okno Właściwości roli bazy danych – Nowa rola. W górnej części okna wpisz nazwę roli.
Na przykład chcemy stworzyć rolę dla księgowych. Aby to zrobić, wpisz Buh w polu Nazwa.
Tworzenie roli bazy danych
Poniżej wybierz typ roli, na przykład standardową domyślną. Na środku okna znajduje się lista użytkowników, którzy zostaną dodani do roli. Jak dotąd lista jest pusta. Jeśli jednak klikniemy Dodaj, dodamy użytkowników np. do utworzonego wcześniej konta qq. Na etapie tworzenia roli nie pozostaje nic innego do zrobienia. Zapisz zmiany, klikając OK.
Uprawnienia dostępu
Teraz zobaczymy, jak możemy ustawić uprawnienia. Kliknij dwukrotnie utworzoną rolę Buh, aby otworzyć okno do edycji. Pamiętaj, że przycisk Zezwolenie jest już dostępny. Dopiero gdy rola zostanie zarejestrowana w bazie, możemy zmienić jej uprawnienia. Kliknij ten przycisk, aby otworzyć okno Właściwości roli bazy danych.
Ustawianie uprawnień dostępu dla ról
W górnej części okna znajduje się lista ról bazy danych, dzięki czemu można szybko się między nimi przełączać. Teraz wybrano rolę Buh. Na środku okna znajduje się duża siatka z następującymi kolumnami:
- Obiekt – nazwy obiektów;
- Właściciel – właściciel obiektu;
- SELECT – uprawnienie do przeglądania danych lub wykonania instrukcji SELECT. Jest dostępny tylko dla tabel i widoków;
- INSERT – uprawnienie do dodawania danych lub wykonania instrukcji INSERT. Jest dostępny tylko dla tabel i widoków;
- UPDATE – uprawnienie do modyfikacji danych lub wykonania instrukcji UPDATE. Jest dostępny tylko dla tabel i widoków;
- Uprawnienie DELETE do usuwania danych lub wykonywania instrukcji DELETE. Jest dostępny tylko dla tabel i widoków;
- EXEC – uprawnienie do wykonywania procedur i funkcji składowanych. Jest dostępny tylko dla procedur i funkcji składowanych;
- DRI (deklaratywna integralność referencyjna). Jest dostępny tylko dla tabel, widoków i funkcji.
Brak uprawnień do nowej roli. Aby móc wyświetlić tabelę, na przykład Kategorie, zaznacz pole na przecięciu wiersza Kategorie i kolumny WYBIERZ. W polu zobaczysz zielony haczyk, co oznacza pozwolenie. Drugie kliknięcie zmienia haczyk na czerwony krzyżyk i oznacza zakaz. Może to być konieczne, jeśli przyznasz uprawnienia użytkownikowi i dodasz go do innej roli, w której uzyskasz dostęp do wybranej akcji. Trzecie kliknięcie usuwa wszelkie uprawnienia do akcji i pozostawia pole puste. Oznacza to, że nie ma dostępu; jednak można ją delegować, jeśli użytkownik zostanie dodany do innej roli z uprawnieniami do obiektu lub uprawnieniami są wyraźnie określone.
Jeśli wybierzesz wiersz z obiektem tabeli lub widoku, przycisk Kolumny stanie się dostępny w dolnej części okna. Załóżmy, że wybrałeś tabelę i kliknąłeś ten przycisk. Otworzy się okno, w którym możesz ustawić uprawnienia dla poszczególnych kolumn tabeli.
Ustawianie uprawnień do kolumn
Jest to rzeczywiście duża możliwość, ponieważ niektóre kolumny odpowiedzialne za integralność bazy danych nie mogą być zmieniane przez użytkowników lub hakerów. Lepiej zabronić operacji UPDATE lub SELECT (jeśli to możliwe) dla tych kolumn.
Indywidualizm
Role są wygodne w użyciu, gdy konieczne jest połączenie podobnych użytkowników. Na przykład wielu księgowych musi uzyskać dostęp do tabel finansowych. Nadanie uprawnień każdemu księgowemu jest czasochłonne. Dużo łatwiej jest stworzyć rolę dla księgowego, nadać jej uprawnienia, a następnie dodać wszystkie konta księgowe do tej roli.
Zdarzają się jednak przypadki, w których uprawnienia powinny być unikatowe dla użytkownika lub oprócz uprawnień przyznanych przez rolę konieczne jest nadanie dodatkowych uprawnień. Na przykład jeden z księgowych musi mieć dostęp do tabel działu kadr. W takim przypadku lepiej jest dodać uprawnienia bezpośrednio do księgowego, zamiast tworzyć nową rolę.
Najpierw zbadaliśmy role, aby się do nich przyzwyczaić. W większości przypadków istnieje osobne konto dla księgowych, osobne konto dla ekonomistów itp. W tym przypadku większość osób łączy się z serwerem za pomocą jednego konta. W ten sposób kontrolować, kto robi to, co jest niemożliwe. W razie potrzeby lepiej jest używać indywidualnych uprawnień, podczas gdy każdy użytkownik musi mieć własne konto.
Uprawnienia na stołach
Zobaczmy, jak możemy przyznać uprawnienia do określonych obiektów, na przykład do tabel.
Wybierz gałąź Bazy danych/Northwind/Tabele w drzewie obiektów. W prawej części otwiera się lista wszystkich stołów. Kliknij prawym przyciskiem myszy dowolną tabelę i wybierz Wszystkie zadania/Zarządzaj uprawnieniami. Otworzy się okno Właściwości uprawnień, które jest podobne do okna Właściwości roli bazy danych z listą użytkowników zamiast listy obiektów. Obiektem jest tabela, którą kliknęliśmy, a jej nazwa zostanie wyświetlona w rozwijanym menu okna. Teraz musimy ustawić uprawnienia do tego obiektu dla różnych użytkowników.
Ustawianie uprawnień do stołu
Lista uprawnień jest następująca:przeglądanie, aktualizacja, dodawanie, usuwanie, wykonywanie i zarządzanie. Jeśli klikniesz przycisk Kolumny, otworzy się okno umożliwiające ustawienie uprawnień do obiektu na poziomie pól tabeli dla konkretnego użytkownika.
Wyświetlenia
Mamy dwa stoły. Jedna z nich przechowuje listę pracowników, podczas gdy inna tabela zawiera informacje o liczbie przepracowanych godzin w miesiącu i otrzymywanych zarobkach (płace oficjalne i ukryte).
Załóżmy, że przychodzi do ciebie urzędnik podatkowy i prosi o pokazanie zarobków pracowników. Ponadto pytają, czy zapłaciłeś wszystkie podatki. Jakie działania musisz wykonać po swojej stronie?
Pierwsza propozycja pochodziła z trzeciego rzędu – aby utworzyć nowego użytkownika, który będzie mógł czytać tabele zawierające listę pracowników i wynagrodzeń. Ponadto nie należy zapominać o zamknięciu kolumny z ukrytą płacą. Właściwie rozwiązanie jest poprawne, ale absolutnie nieskuteczne.
Najlepszą opcją jest utworzenie widoku, zapytania SQL, które wybiera dane. W bazie wygląda jak tabela. Możesz wybrać dane SQL za pomocą zapytań i nadawać uprawnienia. Okazuje się, że zapytanie zostanie wykonane względem zapytania.
Aby utworzyć widok, uruchom następujące zapytanie:
CREATE VIEW salary AS SELECT fields for a tax official FROM Employees, Wages WHERE joins
Teraz w gałęzi Databases/Northwind/Views pojawił się nowy obiekt Wage. Jeśli klikniesz go prawym przyciskiem myszy i wybierzesz Wszystkie zadania/Zarządzaj uprawnieniami, otworzy się okno nadawania uprawnień. Ustaw zezwolenie dla urzędnika podatkowego i zapisz je. Aby przejrzeć zawartość widoku, uruchom zapytanie:
SELECT * FROM salary
Jak widać, jest dostęp jak do prostej tabeli. Urzędnik podatkowy pomyśli też, że widzi rzeczywiste dane. Jednak w rzeczywistości to zapytanie będzie zawierało tylko te dane, których potrzebujemy.
W prawdziwym życiu urzędnika podatkowego nie można tak łatwo oszukać, ponieważ nie jest głupcem. Jednak ten przykład pokazuje, że widok może być doskonałym zabezpieczeniem. Możemy wyświetlić dane potrzebne użytkownikom i nic więcej. Jednocześnie mamy wszystkie narzędzia do zarządzania uprawnieniami do widoku bez wpływu na uprawnienia dostępu do tabel.
W związku z tym różne widoki tych samych tabel mogą pokazywać różne dane. Jeśli chcesz wyświetlić dodatkową kolumnę, dodaj widoki do zapytania. W takim przypadku nie ma potrzeby zmiany uprawnień.
Widoki systemowe
W każdej bazie danych mogą znajdować się automatycznie tworzone przez serwer widoki systemowe. Nie polecam nadawania im uprawnień, ponieważ mogą pokazać dodatkowe informacje, które mogą pomóc hakerowi ustawić uprawnienia lub po prostu zniszczyć dane. Widoki systemowe zaczynają się od prefiksu sys, a System jest określony w kolumnie Typ listy.
Procedury i funkcje
Nowoczesne serwery baz danych obsługują procedury i funkcje składowane. Jest to kod PL/SQL lub Transact-SQL w zależności od bazy danych, która jest wykonywana na serwerze bazy danych. Korzystając z tych procedur możemy wykonać dowolne operacje na serwerze lub po prostu wybrać dane, tak jak w widoku. Możemy ustawić uprawnienia dla każdej procedury.
Podczas przeglądania ról widzieliśmy już procedury na liście obiektów, dla których można ustawić uprawnienia, a w tych wierszach dostępna jest tylko kolumna EXEC, ponieważ procedury można wykonać tylko.
Przechowywane procedury i funkcje są przechowywane w określonej bazie danych. Aby wyświetlić procedury bazy danych Northwind, wybierz gałąź Databases/Northwind/Stored Procedures. Istnieje wiele procedur systemowych, których nazwy zaczynają się od przedrostka dt_, a System jest określony w kolumnie Typ. Zaleca się, aby w miarę możliwości nie udzielać dostępu do tych procedur. Możesz zobaczyć funkcje w gałęzi Bazy danych/Northwind/Funkcje zdefiniowane przez użytkownika.
Aby zmienić uprawnienia do procedur i funkcji, kliknij prawym przyciskiem myszy jego nazwę i wybierz z menu Wszystkie zadania/Zarządzaj uprawnieniami. W wyświetlonym oknie możesz zmienić tylko kolumnę EXEC dla procedur oraz kolumny EXEC i DRI dla funkcji.
Polityka uprawnień
Niektórzy administratorzy ustawiają uprawnienia na podstawie istniejącej roli, na przykład public. Nie jest to prawdą, ponieważ w tej roli mogą istnieć uprawnienia, których użytkownicy nie potrzebują. Dlatego spróbuj ustawić zupełnie nowe uprawnienia.
Jeśli chodzi o mnie, zawsze tworzę nową rolę i nadaję minimalny zestaw uprawnień. Jeśli użytkownicy proszą o więcej uprawnień i są one rzeczywiście potrzebne, dodaję więcej uprawnień. Jeśli domyślnie zezwolisz na wszystko, nie ma gwarancji, że w przyszłości niepotrzebne i niebezpieczne prawa zostaną usunięte.
Inną kwestią związaną z ustawieniem mniejszej liczby uprawnień jest przyzwyczajenie. Użytkownicy mogą przyzwyczaić się do tego, że przyznaje się im wiele uprawnień i wtedy zakaz wywoła poważny skandal. Nikt nie lubi, gdy jego prawa są naruszane.
Tabele/bazy danych
Bazy danych przechowują swoje ustawienia i ukryte właściwości w tabelach systemowych i bazach danych. Nie różnią się one od innych obiektów bazy danych i można na nich ustawić uprawnienia. W żadnym wypadku nie zezwalaj użytkownikom na dostęp do tych tabel bez specjalnej potrzeby.
W SQL Server ważne dane systemowe są przechowywane w bazach danych master i msdb. Dlatego te bazy danych mają być chronione. W Oracle każda baza danych istnieje jako osobny obiekt, a tabele systemowe są przechowywane razem z tabelami użytkowników.
Prawie wszystkie serwery bazodanowe oferują instalację testowych baz danych, które można wykorzystać do nauki lub testowania systemu. Jeśli je posiadasz, usuń – ponieważ do tych baz danych jest ustawiony publiczny dostęp. Jeśli haker zna nazwy lub właściwości dowolnego istniejącego obiektu w systemie, znacznie uprości to jego zadanie.
Łącząc się z testową bazą danych, możesz wykonać niektóre polecenia na serwerze i uszkodzić system operacyjny lub działającą bazę danych. Żadne dodatkowe rzeczy nie powinny znajdować się w systemie. Co więcej, takie tabele/bazy danych mają dość wysokie uprawnienia nawet dla gościa.
Podsumowanie
Pomimo tego, że użyliśmy MS SQL Server jako przykładu, koncepcje uprawnień, ról i uwierzytelniania istnieją we wszystkich bazach danych.
Znając wszystkie rozważane przez nas zasady, jedyne, czego potrzebujesz, to zbadanie specyfiki ich użycia w Twojej bazie danych.
