Nie jest tajemnicą, że informacje sprawiają, że świat się obecnie kręci. Jeśli przedsiębiorstwo dba o swoją własność intelektualną, a każdy pracownik może łatwo uzyskać potrzebne informacje, przedsiębiorstwo może liczyć na rozwój. Jeśli w danych panuje chaos, przedsiębiorstwo upadnie pomimo ducha zespołu.
W tym artykule przyjrzymy się podstawom bezpieczeństwa baz danych oraz przykładom ochrony informacji w Oracle. W rzeczywistości teoretyczne podstawy ochrony informacji w bazie danych, które rozważymy w tym artykule, przydadzą się również osobom pracującym z innymi bazami danych.
Uprawnienia dostępu
W większości firm, w których pracowałem, wszyscy administratorzy i programiści mieli pełny dostęp do baz danych, a pracownik działu IT był bogiem i mógł robić wszystko, co chciał. Dlaczego tak się dzieje? Są ku temu dwa powody:
- Pracując w jednym dziale, pracownicy mogą spotykać się ze sobą przez 8 godzin dziennie i zaprzyjaźniać się. Jak nie mogą przyznać dostępu? Przyjaźń to jedno, ale biznes to biznes.
- Przyznanie niektórych praw dostępu lub zmodyfikowanie niektórych konfiguracji może wymagać pewnych uprawnień. Czasami administratorzy uważają, że programiści lepiej konfigurują ustawienia. W ten sposób zapewniają programistom niepotrzebne prawa dostępu. Zamiast tego programiści nie mogą być zaangażowani w administrację i nie mogą mieć do tego żadnych praw.
Z mojego doświadczenia wynika, że drugi problem jest bardzo powszechny, dlatego przeanalizujemy go szczegółowo.
Tworząc programy dla baz danych, programiści znają hasło administratora lub po prostu mają uprawnienia administratora baz danych. To jest niepotrzebne i absolutnie niepewne. Tylko administrator bazy danych musi mieć pełne uprawnienia. Nawet szef działu, dyrektor i najlepsi przyjaciele mogą mieć mniej przywilejów.
Na przykład podczas tworzenia programów wystarczy mieć prawa właściciela schematu w bazie danych Oracle, która przechowuje tabele robocze. Uprawnienia te wystarczą do tworzenia nowych tabel, pakietów, indeksów i innych obiektów, a także nadawania praw dostępu do obiektów schematu innym użytkownikom. Nie potrzebujesz uprawnień systemowych do pracy w pełnym wymiarze godzin.
Jeśli nie ma administratora bazy danych na pełny etat, jest bardzo źle. Lepiej, gdy jest ktoś odpowiedzialny za wydajność, optymalizację i bezpieczeństwo bazy danych. Musisz przynajmniej wyznaczyć jednego programistę, który będzie za to odpowiedzialny i będzie miał wyłączne prawa.
Według statystyk pracownicy firmy najczęściej powodują utratę danych. Mimo to większość firm nadal ignoruje ten wątek, a różne bazy danych przechowywane na dyskach przy bezpłatnym dostępie są sprzedawane nawet w metrze.
Użytkownicy i role
Istnieją dwa typy obiektów do nadawania praw dostępu do baz danych:użytkownicy i role. Role to niektóre grupy, które łączą użytkowników, którzy muszą mieć podobne uprawnienia. Na przykład wszyscy księgowi mogą wymagać dostępu do dokumentów finansowych. Aby uniemożliwić Ci przyznawanie uprawnień każdemu księgowemu, możemy połączyć je w role z niezbędnym dostępem.
Jak widać, zasada ról jest podobna do grup w systemie operacyjnym Windows. Mimo to ma pewne różnice. Nie bez powodu w bazie danych można zaimplementować wszystkie trzy typy obiektów, takie jak użytkownicy, grupy i role. Jednak w większości baz danych zaimplementowani są tylko użytkownicy i role. Niezbędne jest zarządzanie i monitorowanie wszystkich tych obiektów, aby każdy użytkownik uzyskujący uprawnienia nadane przez role miał dostęp do danych, które są faktycznie potrzebne do rozwiązywania zadań. Niezbędne jest używanie praw dostępu jako reguł dla firewalla. Korzystając z tych praw, możesz rozwiązać ten sam problem – aby umożliwić użytkownikowi wykonywanie tylko niektórych zadań i zapobiec możliwej utracie lub uszkodzeniu.
Za pomocą ról dość wygodnie jest kontrolować dostęp, nadawać uprawnienia lub blokować całą grupę użytkowników. Jedną rolę można włączyć do drugiej, dziedzicząc w ten sposób jej prawa dostępu. Dlatego możemy stworzyć hierarchiczną strukturę praw.
Wszyscy pracownicy z prawami dostępu do firmowej bazy danych mogą być objęci jedną rolą z minimalnymi uprawnieniami. Teraz, jeśli potrzebujesz dodatkowych uprawnień, dostępu do określonych tabel, musisz dodać użytkownika do innych ról (jeśli grupa wymaga takiego samego dostępu) lub nadać uprawnienia określonemu kontu.
W programie do kontroli dostępu do tabel możliwe jest sprawdzenie wyniku pod kątem błędów po każdej próbie otwarcia zbioru danych. W przypadku wystąpienia błędu dostępu dostęp do określonej tabeli jest blokowany dla użytkownika. Dzięki temu nie ma potrzeby wdrażania praw dostępu do aplikacji klienckiej. Jeśli jednak zechcesz to wdrożyć, nic się nie stanie. Przynajmniej nie widzę w tym nic krytycznego; wydaje się mieć odwrotny skutek.
Audyt bezpieczeństwa
Jeśli każdy użytkownik pracuje pod własnym kontem w Twojej bazie danych, możesz wywołać zmienną użytkownika, aby określić bieżącego użytkownika, na przykład:
SELECT user from dual
Zapytanie to zwróci nazwę użytkownika, pod którą otwierane jest połączenie z serwerem. Jeśli kilka osób może zalogować się przy użyciu jednej nazwy, to zapytanie zwróci tę samą nazwę dla obu i nie będzie miało sensu podczas audytu. Zwłaszcza, jeśli kontrola blokady występuje na poziomie serwera.
Jeśli kilku użytkowników może zalogować się przy użyciu tej samej nazwy użytkownika, trudne, ale nadal możliwe jest zidentyfikowanie, kto zalogował się na konto. Poniższe zapytanie umożliwia uzyskanie szczegółowych informacji o sesji:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Jak widać, zapytanie zwróciło nazwę użytkownika połączoną z bazą danych, nazwę w systemie operacyjnym, nazwę użytkownika terminala i program.
Tutaj możesz uzyskać dostęp do widoku v_$session ze schematu systemu sys. Ten widok zwraca pewne informacje o połączeniach z serwerem. W klauzuli WHERE ograniczamy dane wyjściowe tylko do bieżącego użytkownika. W rezultacie zapytanie zwraca ID użytkownika, nazwę, nazwę w systemie operacyjnym, terminalu i programie, z którego nawiązano połączenie.
Kiedy znasz nazwę użytkownika i nazwę terminala, możesz na pewno zidentyfikować użytkownika. Aby dowiedzieć się, do jakich ról został dodany bieżący użytkownik, możesz uruchomić następujące zapytanie:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Bezpieczeństwo konta
Nie powiemy, że nie powinno być domyślnych haseł. Niektóre bazy danych, na przykład MySQL, działają źle, gdy po instalacji tworzą proste i dobrze znane hasło systemowe. Nie powiemy też, że hasło powinno być skomplikowane. Zasada ta dotyczy wszystkich obszarów IT i powinna być znana nawet początkującemu użytkownikowi. Porozmawiamy o problemach z bazą danych.
Z mojego doświadczenia wynika, że podczas tworzenia programów korporacyjnych programiści korzystają z tego samego konta, aby uzyskać dostęp do bazy danych. Parametry tego konta rejestrowane są bezpośrednio w programie, natomiast dostęp do poszczególnych modułów m.in. księgowości, magazynu, działu personalnego itp. realizowany jest w sposób programowy. Z jednej strony ta metoda jest wygodna, ponieważ program może łączyć się z bazą danych z uprawnieniami administratora i nie będzie musiał dbać o role i prawa dostępu do tabel. Z drugiej strony ta metoda nie jest bezpieczna. Poziom użytkowników rośnie, a znajomi pracowników Twojej firmy mogą kształcić się w zakresie bezpieczeństwa i hakowania. Po poznaniu nazwy i hasła, pod którymi program łączy się z bazą danych, zwykły użytkownik może uzyskać więcej możliwości niż chciał.
Język SQL nie jest językiem tajnym i skomplikowanym. Istnieje wiele programów, za pomocą których można łatwo przeglądać dowolne dane w bazie danych. Dzięki nazwie użytkownika i haśle każdy może ukraść wszystkie Twoje dane. W ten sposób będzie sprzedawany na każdym stoisku, które sprzedaje dyski.
Nazwa użytkownika i hasło nie mogą być przechowywane w programie. Dostęp do programu musi być również ograniczony i niemożliwy dla osób trzecich. Połączenie obu loginów w jedno jest całkiem logiczne. Konieczne jest utworzenie osobnego konta na serwerze bazy danych z minimalnymi niezbędnymi uprawnieniami dla każdego użytkownika w organizacji. Tych nazw i haseł należy używać podczas logowania do programu. Możesz użyć wspólnej i bardzo efektywnej logiki – jeśli możesz zalogować się do bazy z wprowadzonymi danymi, dostęp jest dozwolony; jeśli nie, musisz przerwać program. Ten proces jest prosty i skuteczny, ponieważ użyliśmy autoryzacji bazy danych.
Aby sprawdzić, czy użytkownicy nie pracują jednocześnie z dwóch różnych komputerów pod tą samą nazwą, możesz wykonać następujące zapytanie:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
W rzeczywistości nie może zwracać żadnego rekordu.
Wyświetlenia
Widoki to bardzo wygodny sposób na wyłączenie się ze struktury danych i jednoczesne zbudowanie dodatkowego poziomu ochrony. To prawda, że poglądy mają negatywny wpływ na produktywność, ale mają pozytywny wpływ na bezpieczeństwo. Możemy przyznać im własne prawa dostępu, podczas gdy tabele, z których pobierane są dane, mogą pozostać niedostępne dla tego konta.
Kiedy lepiej korzystać z widoków? Najpierw określmy ich wady. Widok to instrukcja SELECT służąca do pobierania danych. Ma dostęp zarówno do jednej, jak i kilku tabel. Jeśli po prostu wybierzesz dane z widoku, nie nastąpi utrata wydajności. Możemy jednak wykorzystać widoki w innych zapytaniach do selekcji danych i odwoływania się do nich jak do tabel. Na przykład:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
W takim przypadku zapytanie pobiera dane z widoku i dwóch tabel. Ponadto możemy wyświetlić relację między wszystkimi obiektami i ustawić dodatkowy warunek.
Spójrzmy teraz na zapytanie tak, jak widzi je optymalizator bazy danych:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
W tym przypadku zastąpiłem widok abstrakcyjną instrukcją SELECT w nawiasach, z której składa się widok. Okazuje się, że serwer widzi zapytanie z podzapytanie. Jeśli podzapytanie zwraca dane dynamiczne, a nie wartość statyczną, ten wybór danych będzie działał wolniej, niż gdybyśmy napisali to samo zapytanie bez podzapytania.
Bezpieczeństwo danych
Nigdy nie należy udzielać pełnego dostępu do obiektów bez specjalnej potrzeby. Zawsze zaczynam udzielać uprawnień tylko po to, aby zezwolić na wybór danych za pomocą instrukcji SELECT. Jeśli użytkownik naprawdę musi wstawić nowe rekordy i nie może wykonać przydzielonych mu zadań, w takim przypadku dodaj uprawnienia do instrukcji INSERT określonej tabeli.
Najbardziej niebezpieczne operacje na danych to modyfikacja i usuwanie, czyli odpowiednio UPDATE i DELETE. Musisz ostrożnie przyznawać te prawa. Upewnij się, że dane można modyfikować lub usuwać. Tylko w tym przypadku wybierz odpowiednie uprawnienia. Niektóre tabele są rozszerzone tylko z natury.
Należy mieć pewność, że dane będą często zmieniane. Na przykład tabelę pracowników można rozszerzać i modyfikować, ale nigdy nie należy usuwać pojedynczego rekordu. Usunięcie może wpłynąć na tło pracy pracowników, raportowanie i integralność danych. Sytuacja, w której pracownik działu kadr przypadkowo doda dodatkowy rekord i chce go usunąć, jest nadal możliwa. Jednak takie przypadki są rzadkie i błąd może zostać naprawiony przez administratora bazy danych. Rozumiemy, że nikt nie chce się przemęczać i łatwiej jest udzielić pozwolenia, jednak bezpieczeństwo jest bardziej cenne.
Nadawanie uprawnień odbywa się za pomocą operatora GRANT. Ogólnie wygląda to tak:
PRZYZNAJ, co nadać prawa do obiektów ON użytkownikom lub rolom
Na przykład następujące zapytanie przyznaje prawo do wstawiania i przeglądania tabeli TestTable użytkownikowi 1:
GRANT Select, Insert ON TestTable TO User1
Klucze obce
Wielu użytkowników obawia się kluczy obcych, ponieważ zazwyczaj nie pozwalają na usuwanie danych, gdy istnieje sprzężenie zewnętrzne. Problem można łatwo rozwiązać, jeśli zostanie ustalone usuwanie kaskadowe. Jednak większość specjalistów nie lubi takiej możliwości. Jedno absurdalne działanie może uszkodzić bardzo ważne dane bez żadnych próśb o potwierdzenie. Połączone dane muszą zostać wyraźnie usunięte i tylko wtedy, gdy użytkownik świadomie potwierdził, że dane można usunąć.
Nie bój się kluczy obcych. Zapewniają nam wygodny sposób kontrolowania integralności danych z serwera bazy danych, dzięki czemu jest to bezpieczeństwo, które nigdy nie zaszkodzi. Fakt, że mogą wystąpić problemy z usunięciem, to tylko korzyść. Lepiej nie usuwać danych, niż stracić je na zawsze. Klucz obcy wraz z indeksem nie zmniejsza wydajności. To tylko mała kontrola podczas usuwania danych lub modyfikowania pola klucza, z którym dane są połączone w różnych tabelach.
Kopia zapasowa
Kopia zapasowa jest również jednym z czynników bezpieczeństwa, które ignorujemy przed pierwszą utratą danych. Osobiście jednak zaliczyłbym go do głównych. Utrata danych może być spowodowana nie tylko przez hakerów i nieumiejętnych użytkowników, ale także z powodu awarii sprzętu. Awarie sprzętu mogą prowadzić do utraty bazy danych, której przywrócenie może zająć godziny, a nawet dni.
Konieczne jest wcześniejsze opracowanie najskuteczniejszej polityki tworzenia kopii zapasowych. Co przez to rozumiemy? Przestój spowodowany utratą danych do momentu przywrócenia sprawności powinien być minimalny. Utrata danych powinna być również minimalna, a kopia zapasowa nie powinna wpływać na pracę użytkownika. Jeśli są pieniądze i możliwości, lepiej użyć takich systemów jak RAID, klaster, a nawet replikacja danych.
Tworzenie kopii zapasowych i odzyskiwanie to osobny i interesujący temat. Nie mogliśmy tego poruszyć tutaj, ale nie będziemy tego szczegółowo omawiać.
Podsumowanie
Rozważaliśmy podstawy bezpieczeństwa, w szczególności Oracle. Nie zapominaj, że ochrona zapewniana przez bazę danych jest tylko jednopoziomowa, podczas gdy ochrona musi być wielopoziomowa. Aby trochę spać z czystym umysłem, konieczne jest wdrożenie wszystkich funkcji bezpieczeństwa w sieci, serwerach i wszystkich komputerach, w tym antywirusów, programów antyszpiegowskich, VPN, IDS itp. Im więcej poziomów ochrony, tym więcej trudne będzie ich pokonanie.
Powinna istnieć jasna polityka bezpieczeństwa i kontrola. Jeśli pracownik odejdzie, jego konto zostanie usunięte. Jeśli masz użytkowników pracujących z tym samym hasłem lub używających hasła grupowego do wykonywania jakichkolwiek zadań, wszystkie te hasła muszą zostać zmienione. Na przykład, jeśli administrator odejdzie, a wszyscy administratorzy korzystają z tego samego konta, musisz zmienić hasło.
Bezpieczeństwo jest konieczne. Musisz chronić się nie tylko przed hakerami, ale także przed „początkującymi” użytkownikami, którzy swoim brakiem doświadczenia mogą uszkodzić dane. Dobra polityka bezpieczeństwa pomaga zapobiegać takim przypadkom i takiej możliwości nie można wykluczyć. Lepiej jest zapewnić możliwość zabezpieczenia danych przed brakiem doświadczenia z wyprzedzeniem, niż tracić dużo czasu na przywracanie danych i niepotrzebne przestoje.
Przeczytaj również:
Ustawianie uprawnień dostępu do bazy danych
