Wszystkie relacyjne systemy zarządzania bazą danych zapewniają pewien rodzaj wewnętrznych mechanizmów bezpieczeństwa zaprojektowanych w celu zminimalizowania zagrożeń związanych z utratą danych, uszkodzeniem danych lub kradzieżą danych. Obejmują one od prostej ochrony hasłem oferowanej przez Microsoft Access do złożonej struktury użytkowników/roli wspieranej przez zaawansowane relacyjne bazy danych, takie jak Wyrocznia iMicrosoft SQL Serwer. Niektóre mechanizmy bezpieczeństwa są wspólne dla wszystkich baz danych, które implementująStrukturalny język zapytań.
Bezpieczeństwo na poziomie użytkownika
Bazy danych oparte na serwerze obsługują a użytkownik koncepcja podobna do tej stosowanej w komputerowych systemach operacyjnych. Jeśli znasz hierarchię użytkowników/grup znalezioną w Microsoft Windows NT i Windows 2000, zauważysz, że grupowanie użytkowników/roli obsługiwane przez SQL Server i Oracle są podobne.
Utwórz indywidualne konta użytkowników bazy danych dla każdej osoby z dostępem do Twojej bazy danych.
Unikaj udostępniania kont ogólnych dostępnych dla kilku różnych osób. Po pierwsze, ta praktyka eliminuje indywidualną odpowiedzialność — jeśli użytkownik dokona zmiany w Twojej bazie danych (powiedzmy dając sobie 5000 $ podwyżki), nie będziesz w stanie prześledzić go z powrotem do konkretnej osoby za pomocą audytu dzienniki. Po drugie, jeśli określony użytkownik opuści Twoją organizację i chcesz usunąć jego dostęp z bazy danych, musisz zmienić hasło, na którym polegają wszyscy użytkownicy.
Metody tworzenia kont użytkowników różnią się w zależności od platformy i będziesz musiał zapoznać się z dokumentacją dotyczącą konkretnego systemu DBMS, aby uzyskać dokładną procedurę. Użytkownicy Microsoft SQL Server powinni zbadać użycie sp_adduser procedura składowana. Administratorzy baz danych Oracle znajdą te STWÓRZ UŻYTKOWNIKA przydatne polecenie. Możesz także zbadać alternatywne schematy uwierzytelniania. Na przykład Microsoft SQL Server obsługuje korzystanie ze zintegrowanych zabezpieczeń systemu Windows NT. W ramach tego schematu użytkownicy są identyfikowani w bazie danych na podstawie ich kont użytkowników systemu Windows NT i nie muszą wprowadzać dodatkowego identyfikatora użytkownika i hasła w celu uzyskania dostępu do bazy danych. Takie podejście jest popularne wśród administratorów baz danych, ponieważ przenosi ciężar konta zarządzanie dla personelu administracyjnego sieci i zapewnia łatwość pojedynczego logowania do użytkownik końcowy.
Bezpieczeństwo na poziomie roli
Jeśli pracujesz w środowisku z niewielką liczbą użytkowników, prawdopodobnie okaże się, że tworzenie kont użytkowników i przypisywanie im uprawnień bezpośrednio jest wystarczające dla Twoich potrzeb. Jeśli jednak masz dużą liczbę użytkowników, będziesz przytłoczony utrzymywaniem kont i odpowiednimi uprawnieniami. Aby złagodzić to obciążenie, obsługują relacyjne bazy danych role. Role bazy danych działają podobnie do grup Windows NT. Konta użytkowników są przypisywane do ról, a uprawnienia są następnie przypisywane do roli jako całości, a nie do poszczególnych kont użytkowników. Na przykład możesz utworzyć rolę DBA, a następnie dodać do niej konta użytkowników pracowników administracyjnych. Następnie możesz przypisać określone uprawnienia wszystkim obecnym (i przyszłym) administratorom, po prostu przypisując uprawnienia do roli. Po raz kolejny procedury tworzenia ról różnią się w zależności od platformy. Administratorzy MS SQL Server powinni zbadać sp_addrole procedura składowana, podczas gdy administratorzy baz danych Oracle powinni używać UTWÓRZ ROLĘ składnia.
Udzielanie uprawnień
Teraz, gdy dodaliśmy użytkowników do naszej bazy danych, nadszedł czas na wzmocnienie bezpieczeństwa poprzez dodanie uprawnień. Naszym pierwszym krokiem będzie przyznanie naszym użytkownikom odpowiednich uprawnień do bazy danych. Osiągniemy to za pomocą instrukcji SQL GRANT.
Oto składnia instrukcji:
DOTACJA.
[NA.
DO.
[Z OPCJĄ DOTACJI]
Przyjrzyjmy się teraz tej instrukcji wiersz po wierszu. Pierwsza linia, DOTACJA , pozwala nam określić konkretne uprawnienia do tabeli, które przyznajemy. Mogą to być uprawnienia na poziomie tabeli (takie jak SELECT, INSERT, UPDATE i DELETE) lub uprawnienia do bazy danych (takie jak CREATE TABLE, ALTER DATABASE i GRANT). W jednej instrukcji GRANT można przyznać więcej niż jedno uprawnienie, ale uprawnienia na poziomie tabeli i uprawnienia na poziomie bazy danych nie mogą być połączone w jednej instrukcji.
Druga linia, NA
Wreszcie czwarta linia, Z OPCJĄ DOTACJI, jest opcjonalne. Jeśli ten wiersz znajduje się w oświadczeniu, użytkownik, którego dotyczy problem, może również przyznać te same uprawnienia innym użytkownikom. Należy zauważyć, że opcji WITH GRANT OPTION nie można określić, gdy uprawnienia są przypisane do roli.
Przykładowe dotacje na bazę danych
Spójrzmy na kilka przykładów. W naszym pierwszym scenariuszu zatrudniliśmy ostatnio grupę 42 operatorów wprowadzania danych, którzy będą dodawać i utrzymywać rekordy klientów. Muszą uzyskać dostęp do informacji w tabeli Klienci, zmodyfikować te informacje i dodać nowe rekordy do tabeli. Nie powinni mieć możliwości całkowitego usunięcia rekordu z bazy danych.
Najpierw powinniśmy stworzyć konta użytkowników dla każdego operatora, a następnie dodać ich wszystkich do nowej roli, Wprowadzanie danych. Następnie powinniśmy użyć następującej instrukcji SQL, aby nadać im odpowiednie uprawnienia:
PRZYZNAJ WYBIERZ, WSTAW, AKTUALIZUJ.
NA Klientach.
DO Wprowadzanie danych.
Przeanalizujmy teraz przypadek, w którym przypisujemy uprawnienia na poziomie bazy danych. Chcemy umożliwić członkom roli DBA dodawanie nowych tabel do naszej bazy danych. Ponadto chcemy, aby mogli udzielać innym użytkownikom uprawnień do robienia tego samego. Oto instrukcja SQL:
DOTACJE UTWÓRZ TABELĘ.
DO DBA.
Z OPCJĄ DOTACJI.
Zwróć uwagę, że dodaliśmy wiersz WITH GRANT OPTION, aby zapewnić, że nasi administratorzy mogą przypisywać to uprawnienie innym użytkownikom.
Usuwanie uprawnień
SQL zawiera polecenie REVOKE, które usuwa wcześniej przyznane uprawnienia. Oto składnia:
COFNIĘCIE [OPCJA PRZYZNANIA NA]
NA.
Z.
Zauważysz, że składnia tego polecenia jest podobna do składni polecenia GRANT. Jedyna różnica polega na tym, że opcja WITH GRANT jest określona w wierszu polecenia REVOKE, a nie na końcu polecenia. Jako przykład wyobraźmy sobie, że chcemy cofnąć przyznane wcześniej przez Mary uprawnienie do usuwania rekordów z bazy danych Klientów. Użylibyśmy następującego polecenia:
COFNIJ USUŃ.
NA Klientach.
OD Maryi.
Jest jeden dodatkowy mechanizm obsługiwany przez Microsoft SQL Server, o którym warto wspomnieć — polecenie DENY. To polecenie może służyć do jawnego odmowy użytkownikowi uprawnień, które w przeciwnym razie mogliby mieć poprzez członkostwo w obecnej lub przyszłej roli. Oto składnia:
ZAPRZECZAĆ.
NA.
DO.