630 likes | 777 Views
Zarządzanie bezpieczeństwem w SZBD Oracle. Użytkownicy, uprawnienia i role, profile. Ochrona systemu: weryfikacja nazwy użytkownika i hasła określenie czy użytkownik ma możliwość połączenia się z bazą danych (autoryzacja) przydzielanie miejsca na dysku dla obiektów użytkownika
E N D
Zarządzanie bezpieczeństwem w SZBD Oracle Użytkownicy, uprawnienia i role, profile
Ochrona systemu: weryfikacja nazwy użytkownika i hasła określenie czy użytkownik ma możliwość połączenia się z bazą danych (autoryzacja) przydzielanie miejsca na dysku dla obiektów użytkownika określenie ograniczeń na zasoby dla użytkownika Określenie jakie operacje systemowe użytkownik może wykonywać Możliwość monitorowania bazy danych Ochrona danych: Określenie jacy użytkownicy mają prawo dostępu do określonych schematów obiektów Określenie jakie typy operacji są dozwolone określonym użytkownikom Wybranie operacji, które będą monitorowane dla każdego schematu obiektów Dwie kategorie ochrony SZBD
Sposób funkcjonowania SZBD ORACLE jest zgodny z modelem Dyskrecjonalnej (uznaniowej) kontroli dostępu (Discretionary Access Control – DAC) Ograniczanie dostępu do informacji oparte na uprawnieniach • Odpowiednie uprawnienia muszą być związane z użytkownikiem, by miał dostęp do obiektu • Uprzywilejowany użytkownik może przekazywać innym użytkownikom uprawnienia zgodnie z własnym uznaniem
Sposoby utrzymywania bezpieczeństwa bazy danych • Użytkownicy bazy danych • Schematy • Uprawnienia (przywileje) • Role • Ograniczenia pamięci (quota) • Profile • Obserwacja
Kontrola dostępu do bazy poprzez modyfikowanie, usuwanie i monitorowanie użytkowników • Tworzenie użytkowników i przypisywanie im haseł • autoryzowanie użytkowników do podłączenia się do bazy • ograniczanie dostępnej przestrzeni dyskowej dla każdego użytkownika
Użytkownik a jego schemat • Każda baza danych w SZBD ORACLE ma zdefiniowaną listę nazw użytkowników • Z każdym użytkownikiem związany jest schemat o tej samej nazwie (tworzony, gdy tworzony użytkownik) • Wszystkie obiekty użytkownika są logicznymi strukturami i znajdują się w schemacie użytkownika (który jest logiczną kolekcją obiektów użytkownika) • po podłączeniu się do bazy użytkownik ma dostęp do wszystkich obiektów zawartych w jego schemacie • Każdy użytkownik ma domenę ochrony (a security domain) - zbiór właściwości, które określają: • akcje (przywileje i role) dostępne dla użytkownika • ograniczenia zasobów przestrzeni tabel • ograniczenia zasobów systemowych • dostęp do bazy i jej obiektów jest kontrolowany poprzez przywileje nadane każdemu schematowi
Obszary kontroli dostępu • Ograniczenia dla dostępnych przestrzeni tabel • Domyślna przestrzeń tabel • Tymczasowa przestrzeń tabel • Informacje o uwiarygodnieniu • Ograniczenia zasobów systemowych • Przywileje i role
Mechanizmy ochrony dostępu do zasobów bazyi systemu związane z użytkownikiem • Domyślna przestrzeń tabel (TABLESPACE DEFAULT) • Tymczasowa przestrzeń tabel (TEMPORARY TABLESPACE) • ograniczenia zasobów w przestrzeni tablic (TABLESPACE QUOTA) • ograniczenia zasobów systemowych (SYSTEM RESOURCE LIMIT)
Kontrola praw dostępu - uwiarygodnienie • poprzez system operacyjny • poprzez bazę Oracle
Użytkownicy sys i system • SYS - właściciel słownika danych SYS - hasło po instalacji „CHANGE_ON_INSTALL” • SYSTEM - pierwszy administrator bazy, który ma wszystkie prawa do zarządzania bazą danych SYSTEM - hasło po instalacji „MANAGER”
Tworzenie użytkowników Polecenie CREATE USER: CREATE USER user IDENTIFIED BY password EXTERNALLY DEFAULT TABLESPACE tablespace TEMPORARY TABLESPACE tablespace PROFILE profile QUOTA integer ON tablespace (np.: dla kilku przestrzeni) UNLIMITED PASSWORD EXPIRE ACCOUNT LOCK | UNLOCK
Przykład CREATE USER student IDENTIFIED BY studencik DEFAULT TABLESPACE stud_grup TEMPORARY TABLESPACE stud_temp PROFILE default QUOTA 150M ON stud_grup
Uwiarygodnienie powiązane z systemem operacyjnym Podłączanie do bazy przy użyciu weryfikacji konta systemu operacyjnego CREATE USER user IDENTIFIED EXTERNALLY; możliwe podłączenie się do bazy poprzez wpisanie komendy sqlplus /
CREATE USER kadrowy IDENTIEFIED EXTERNALLY • baza danych tworzy konto użytkownika, które musi być zweryfikowane przez system operacyjny, • należy ustawić parametr OS_AUTHENT_PREFIX i użyć go jako prefix nazwy użytkownika (definiuje on prefix jaki Oracle dodaje do początku nazwy użytkownika systemu operacyjnego) • Oracle porównuje nazwy użytkowników poprzedzone prefixem z nazwami użytkowników w bazie, jeśli są jednakowe następuje połączenie z bazą (sqlplus/) • niech OS_AUTHENT_PREFIX=OPS$ • nazwa użytkownika w SO „kadrowy” • w bazie Oracle’a konto o nazwie „OPS$kadrowy” • następuje dołożenie prefixu do nazwy użytkownika zdefiniowanego w systemie operacyjnym i porównanie z nazwą użytkownika z bazie
OPS$ kadrowy = sqlplus / OPS$kadrowy BD OPS$kadrowy SO OS_AUTHENT_PREFIX = OPS$ kadrowy weryfikacja uprawnień użytkownika ops$kadrowy w bd CREATE USER OPS$kadrowy IDENTIEFIED EXTERNALLY
Zmiana definicji użytkownika Polecenie ALTER USER: ALTER USER user IDENTIFIED BY password EXTERNALLY DEFAULT TABLESPACE tablespace TEMPORARY TABLESPACE tablespace PROFILE profile QUOTA integer ON tablespace PASSWORD EXPIRE ACCOUNT LOCK | UNLOCK
Przykład ALTER USER student IDENTIFIED BY studencik DEFAULT TABLESPACE prac_ts TEMPORARY TABLESPACE temp_ts PROFILE default QUOTA 260M ON prac_ts DEFAULT ROLE studenci
Usunięcie użytkownika Polecenie DROP USER: DROP USER user CASCADE Użytkownik aktualnie podłączony do bazy nie może być usunięty.
Monitorowanie użytkowników Słownik bazy danych zawiera informacje o: • wszystkich użytkownikach bazy danych • domyślnych przestrzeniach tabel, klasterów, indeksów dla każdego użytkownika • przestrzeniach używanych dla obiektów tymczasowych • ograniczeniach przestrzeni Potrzebne perspektywy słownika danych: USER_USERS, ALL_USER, DBA_USER, USER_TS_QUOTAS, DBA_TS_QUOTAS
Przerwanie sesji użytkownika • nie dopuszcza użytkowników do dalszej pracy z bazą • zwalnia zablokowane zasoby i stany użytkowników • może wyświetlać wiadomość dla użytkownika • wymaga przywileju ALTER SYSTEM • KIEDY należy przerwać? • Gdy użytkownik blokuje zasoby niezbędne natychmiast innemu użytkownikowi • DBA musi zamknąć bazę
Zakończenie sesji użytkownika Polecenie ALTER SYSTEM: ALTER SYSTEM KILL SESSION ‘integer1, integer2’ integer1 - identyfikator użytkownika SID integer2 - numer użytkownika (integer1, integer2 określane na podstawie perspektywy V$SESSION)
Zadania DBA związane z obsługą użytkowników • zarządzanie bezpieczeństwem bazy danych • tworzenie, modyfikacja, monitorowanie i usuwanie użytkowników • przerywanie sesji użytkowników w razie konieczności
Przywileje i role Przywileje bazodanowe - prawa do wykonywania określonych operacji na bazie przez uprawnionych przywilejem Przywileje dzielimy na: obiektowe systemowe
Przywileje systemowe Pozwalają na wykonywanie określonych czynności na bazie danych i typach obiektów bazy (tabelach, sekwencjach, klasterach) Typy przywilejów: • we własnym schemacie (create table) • na wszystkich obiektach w dowolnym schemacie (update any table) • w systemie (create session) Informacje o przywilejach systemowych: Dba_sys_privs, user_sys_privs, role_sys_privs, session_privs
Przykłady przywilejów systemowych (perspektywa System_privilege_map) • ALTER DATABASE - pozwala użytkownikowi na modyfikację struktury bazy, • CREATE PROCEDURE - pozwala użytkownikowi na tworzenie w obrębie swojego schematu procedur, funkcji i pakietów zapisywanych w bazie, • CREATE ROLE - umożliwia użytkownikowi tworzenie ról bazodanowych, • CREATE SESSION - przywilej ten pozwala użytkownikowi bazy na otwarcie sesji, czyli połączenie z bazą, • CREATE TABLE - umożliwia użytkownikowi bazy utworzenie tablicy w obrębie własnego schematu, • UPDATE ANY TABLE - umożliwia użytkownikowi zmianę zawartości wierszy każdej tablicy w dowolnym schemacie bazy, • ALTER TABLESPACE - zezwala użytkownikowi bazy na dodawanie nowych plików przestrzenie już istniejące, • CREATE USER - umożliwia tworzenie definicji nowych użytkowników bazy.
Przywileje obiektowe Pozwalają na wykonywanie określonych czynności na konkretnych obiektach bazy (tabeli, perspektywie, sekwencji, procedurze wbudowanej) Przykład: SELECT TABLE adm.pracownik Użytkownik ma wszystkie przywileje obiektowe na obiektach własnego schematu. Przywileje obiektowe nadawane są użytkownikom bazy, którzy nie są właścicielami obiektu.
Przykłady przywilejów obiektowych • ALTER - ALTER obiekt (tabela lub sekwencja), CREATE TRIGGER ON obiekt (tylko dla tabel), • DELETE - DELETE FROM obiekt (tabela lub perspektywa), TRUNCATE obiekt (tylko tabela), • EXECUTE - EXECUTE obiekt (procedura lub funkcja), • INSERT - INSERT INTO obiekt (tabela lub perspektywa), • SELECT - SELECT .....FROM obiekt (tabela, perspektywa lub replikacja), • UPDATE - UPDATE obiekt (tabela lub perspektywa). Pełną listę można uzyskać wykonując zapytanie do perspektywy słownika danych TABLE_PRIVILEGE_MAP.
Nadawanie i odbieranie przywilejów systemowych Polecenie GRANT: GRANT system_priv TO user role role PUBLIC WITH ADMIN OPTION Polecenie REVOKE: REVOKE system_priv FROM user role role PUBLIC
Przykład GRANT CREATE SESSION , CREATE TABLE TO STUDENT WITH ADMIN OPTION; REVOKE SELECT ANY TABLE, CREATE USER FROM STUDENT WITH ADMIN OPTION;
Nadawanie i odbieranie przywilejów obiektowych Polecenie GRANT: GRANT list of object_priv (column1, column2) ON object TO user schemarole role PUBLIC WITH GRANT OPTION Polecenie REVOKE: REVOKE objct_priv ON object schema FROM user role CASCADE CONSTRAINTS PUBLIC
Przykład Nadawanie uprawnień: GRANT select, update, insert ON adm.pracownik TO student; Odbieranie uprawnień: REVOKE delete, update ON adm.dochody FROM student;
Role a przywileje U1 U2 U3 UŻYTKOWNICY P1 P2 P3 P4 PRZYWILEJE N*M operacji nadania przywileju U1 U2 U3 UŻYTKOWNICY R ROLE N+M operacji P1 P2 P3 P4 PRZYWILEJE
Role - cechy • mogą składać się zarówno z przywilejów obiektowych jak i systemowych • nie należą do żadnego użytkownika i schematu • mogą być nadane dowolnemu użytkownikowi lub roli z wyjątkiem siebie • mogą być włączone lub wyłączone dla każdego użytkownika • mogą wymagać autoryzacji (hasła) do włączania • mogą być sterowane z poziomu systemu operacyjnego
Zalety używania ról • Ograniczenie liczby wymienianych uprawnień • nadawanie i odbieranie wielu przywilejów jednym poleceniem • nadawanie roli nowemu użytkownikowi bez pamiętania wszystkich niezbędnych przywilejów • uproszczenie zarządzania przywilejami w systemach z wieloma użytkownikami, wieloma tabelami • Dynamiczna obsługa uprawnień • zmienianie przywilejów roli, gdy zmieniają się obowiązki • zmienianie przywilejów wielu użytkownikom zmieniając jedną rolę • Wybiórcze udostępnianie uprawnień • włączanie i wyłączanie ról, by włączyć i wyłączyć przywileje tymczasowo • aplikacja może przeglądać słownik danych i włączać lub wyłączać role w razie potrzeby
Dodatkowe korzyści • zarządzanie przywilejami baz kaskadowych odbierań przywilejów • możliwość użycia systemu zabezpieczeń systemu operacyjnego przy zabezpieczaniu bazy danych • Wydajność • mniej indywidualnych przywilejów do sprawdzania i kodowania w aplikacji
Tworzenie i modyfikacja roli Polecenie CREATE ROLE CREATE ROLE role NOT IDENTIFIED IDENTIFIED BY password EXTERNALLY Polecenie ALTER ROLE ALTER ROLE role NOT IDENTIFIED IDENTIFIED BY password EXTERNALLY
Przykłady CREATE ROLE pierwsza; CREATE ROLE druga IDENTIFIED BY xxzz; CREATE ROLE trzecia IDENTIFIED EXTERNALLY;
Nadawanie, odbieranie i usuwanie ról Nadawanie uprawnień roli GRANT: GRANT create synonym, create table TO manager Nadawanie ról - polecenie GRANT: GRANT role TO user Odbieranie ról - polecenie REVOKE: REVOKE role FROM user Usuwanie ról - polecenie DROP ROLE: DROP ROLE role
Włączanie i wyłączanie ról • można włączać i wyłączać role, które zostały uprzednio nadane • przywileje nadane wyłączonej roli nie są dostępne użytkownikowi • może być wymagane hasło lub autoryzacja przez system operacyjny • polecenie SET ROLE włącza tylko podane role i wyłącza uprzednio włączone SET ROLErole IDENTIFIED BY password ALL EXCEPT role NONE
Występowanie efektu kaskady przywileje obiektowe przywileje systemowe i role with grant option with grant option ADM PRAC STUD Użytkownik ADM odbiera uprawnienie użytkownikowi PRAC lub usuwa użytkownika Efekt: KASKADY – ani użytkownik ADM ani STUD nie mają już tego prawa with admin option with admin option ADM PRAC STUD Użytkownik ADM odbiera uprawnienie użytkownikowi PRAC lub usuwa użytkownika Efekt: BRAK KASKADY – użytkownik STUD posiada nadal te uprawnienia
Role OSOPER i OSDBA • OSOPER - pozwala użytkownikowi na wykonanieSTARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP CONTROLFILE, ALTER TABLESPACE BEGIN/END BACKUP, ARCHIVE LOG, RECOVER. Rola ta zawiera także - przywilej RESTRICTED SESSION • OSDBA - zawiera wszystkie przywileje systemowe z opcją WITH ADMIN OPTION i rolę OSOPER. Tylko ta rola pozwala na wykonanie CREATE DATABASE i odtwarzanie „do czasu” (time-based recovery)
Obsługa ról na poziomie systemu operacyjnego • System operacyjny przechowuje listę autoryzowanych ról • role nadawane przez system operacyjny: • muszą być najpierw utworzone w bazie • mogą być nadane lub odebrane innej roli w Oracle’u • mogą być włączane i wyłączane w Oracle’u • nie mogą być nadane lub odebrane użytkownikowi w Oracle’u • role kontrolowane przez system operacyjny są nadawane podczas podłączania, ale są wyłączone (jeśli nie są rolami domyślnymi)
Co należy zrobić aby móc zarządzać rolami z poziomu systemu operacyjnego? • Utworzyć role w Oracle’u • nadać utworzonym rolom odpowiednie przywileje • ustawić parametr inicjalizacyjny OS_ROLES na TRUE • zamknąć i otworzyć bazę danych • nadać każdemu użytkownikowi prawa w systemie operacyjnym do korzystania z ról • format przywileju SO : • ORA_SID_ROLE[_D][A] D - rola jest domyślna dla użytkownika A - rola została nadana z opcją WITH ADMIN OPTION • użytkownik musi mieć nadany przywilej CREATE SESSION • SET ROLE może być użyte do włączenia ról systemu operacyjnego, które nie są zdefiniowane jako domyślne
Przykład: • Konto użytkownika w systemie operacyjnym musi mieć zdefiniowane role w swoim profilu np.: • ORA_NowaBaza_ROLA1 • ORA_NowaBaza_ROLA2_A • ORA_NowaBaza_ROLA3_D • ORA_NowaBaza_ROLA4_DA • Rola3 i rola4 są domyślne, rola2 i rola4 są dostępne z opcją ADMIN OPTION
Predefiniowane role Role tworzone przez skrypt catalog.sql • CONNECT - przywileje: Alter Session, Create Database Link, Create Sequence, Create Session, Create Synonym, Create Table, Create View • RESOURCE - Create Cluster, Create Procedure, Create Sequence, Create Table, Create Trigger • DBA - EXP_FULL_DATABASE, IMP_FULL_DATABASE, wszystkie przywileje systemowe z wyjątkiem: SYSTEM GRANT, READUP, WRITEUP, WRITEDOWN, TRUNCATE • nadanie użytkownikowi roli RESOURCE lub DBA spowoduje nadanie przywileju UNLIMITED TABLESPACE • przywilej UNLIMITED TABLESPACE nie może być nadany roli
Zadania administratora • Nadawanie użytkownikom praw do wykonania określonych operacji • zezwalanie i zabranianie dostępu do danych i możliwości ich zmieniania • zezwalanie i zabranianie możliwości wykonania funkcji systemowych i zmian struktury bazy danych • nadawanie przywilejów użytkownikom i rolom • nadawanie przywileju wszystkim użytkownikom (PUBLIC)
Profile i limity zasobów Każdy użytkownik jest połączony z jakimś profilem, który określa ograniczenia do korzystania z różnych zasobów systemu dostępnych dla danego użytkownika. Zasoby systemowe: • liczba równoległych sesji użytkownika, • czas CPU • na poziomie sesji użytkownika, • na poziomie pojedynczego wywołania podczas wykonania zdania SQL, • operacje we/wy • na poziomie sesji użytkownika, • na poziomie pojedynczego wywołania podczas wykonania zdania SQL, • czas spoczynku (idle time) • czas podłączenia
Profile stosowane są w celu: • Ograniczenia ilości zasobów systemowych dostępnych dla użytkownika, • Uniemożliwienia użytkownikom operacji zbyt mocno obciążających zasoby, • Uproszczenia zarządzania zasobami, • Przypisania indywidualnych lub domyślnych limitów użytkownikom, • Specyfikacji ograniczenia zasobów dla grupy użytkowników, • Zarządzania zasobami w dużych, złożonych systemach • Ograniczenia użycia zasobów na poziomie sesji lub odwołania (call), • Odłączenia po odpowiednio długim czasie oczekiwania w sesji, • Wylogowania użytkowników jeśli nie pracują (idle).
Na poziomie sesji bieżące polecenie jest wycofywane, poprzednie polecenia są nienaruszane, dozwolone są tylko operacje: COMMIT, ROLLBACK i odłączenie, nie można wykonać żadnej, znaczącej pracy w tej sesji. Na poziomie wywołania wykonanie zdania jest zatrzymane, zadnie jest wycofywane, poprzednie polecenia są nienaruszone, dalsza praca w sesji odbywa się normalnie. Wprowadzanie ograniczeń może być na poziomie: sesji, wywołania lub na obydwu.Co dzieje się, gdy ograniczenia na poziomie sesji są przekroczone?
Na poziomie sesji: CPU_PER_SESSION, SESSION_PER_USER, CONNECT_TIME, IDLE_TIME, LOGICAL_READS_PER_SESSION, PRIVATE_SGA Na poziomie wywołania: CPU_PER_CALL LOGICAL_READS_PER_CALL Zasoby kontrolowane na poziomie sesji lub na poziomie wywołania