Zarządzanie użytkownikami bazy danych Oracle 11gmst.webd.pl/_sggw/oracle/laboratorium_nr_5_i_6_-_zarz_dzanie_u... · Oracle Virtual Private Databese (VPD) – niskopoziomowe zarządzanie

Zarządzanie użytkownikami bazy danych Oracle 11g

Strona: 1 | Administracja bazą Oracle 11g | Studia Podyplomowe SGGW | Laboratorium nr 5 i 6

Zarządzanie użytkownikami bazy danych Oracle11g

Wstęp Baza danych Oracle jest systemem do którego może podłączyć się wielu użytkowników równoległych w

tym samym czasie. Tożsamością i uprawnieniami zarządza się poprzez:

konta,

uprawnienia,

role

profile

virtual private database

Najprostszą metodą uwierzytelniania jest podanie nazwy i hasła użytkownika. Istnieją również bardziej

zaawansowane metody sprawdzania tożsamości użytkowników lecz nie będą one omawiane w ramach

tego laboratorium.

Zarządzanie kontami administratorów bazy danych Użytkownik SYS jest specjalnym kontem do zarządzania całą instancją bazy danych. Posiada pełny zbiór

uprawnień systemowych i obiektowych. Jest też właścicielem słownika danych. Łącząc się do bazy jako

SYS należy zawsze podać klauzulę “as sysdba” np:

sqlplus sys as sysdba

lub będąc już w programie sqlplus

CONN SYS AS SYSDBA

Klauzula “as sysdba” upewnia bazę danych o tym, że użytkownik rzeczywiście chce połączyć się jako

administrator, a nie w wyniku błędu czy pomyłki.

SYS może łączyć się do bazy danych:

lokalnie (z tej samej maszyny na której działa instancja bazy) lub

zdalnie (z innego komputera przez sieć).

Połączenia lokalne

W przypadku połączeń lokalnych administrator bazy danych może być uwierzytelniany na dwa sposoby:

za pomocą systemu operacyjnego

za pomocą pliku haseł bazy danych



Połączenia zdalne

Połączenia zdalne jako SYS możliwe są w podstawowej konfiguracji tylko za pomocą pliku haseł

Użytkownicy systemu operacyjnego i użytkownicy bazy danych Należy rozróżnić dwa typy użytkowników:

1. użytkownicy systemu operacyjnego, a więc Ci na których logujemy się do Linux-a czy Windows-a

a. Przykładowi użytkownicy w systemie Linux:

i. administrator systemu operacyjnego: “root”

ii. zwykły użytkownik: “oracle”

2. użytkownicy bazy danych, a więc Ci użytkownicy, którzy mają konta w bazie danych

a. Przykładowo w bazie Oracle 11g

i. administrator bazy danych: “SYS”

ii. zwykli użytkownicy: “scott”, hr”, “jan”, “u1”, “u2”

Uruchamiając komputer, najpierw logujemy się do systemu operacyjnego za pomocą konta np. “oracle”,

a dopiero później logujemy się do bazy danych jako użytkownicy bazy np. SYS czy U1. Będąc

zalogowanym użytkownikiem w systemie operacyjnym (np. jako “oracle”) możemy dowolnie zmieniać

tożsamość w bazie danych przełączając się pomiędzy użytkownikami w bazie np:


sqlplus jan/haslo

sqlplus u1/test

lub bez wychodzenia z sqlplus

CONN SYS AS SYSDBA

CONN JAN/haslo

CONN U1/test

Uwierzytelnianie przez system operacyjny Linux W przypadku uwierzytelnienia przez system operacyjny, użytkownik Linuxa (np. oracle) musi być w

grupie systemu operacyjnego “dba”. Aby sprawdzić jaki użytkownik systemu operacyjnego jest

aktualnie zalogowany oraz do jakich grup jest przydzielony należy wykonać w terminalu Linuxa

następujące polecenie:

id

Jako wynik możemy otrzymać następujące informacje:

uid=500(oracle) gid=501(oracle) groups=500(vboxsf), 501(oracle),

504(dba)



Powyższa linia oznacza, że aktualnie zalogowany do systemu operacyjnego jest użytkownik “oracle” o

numerze identyfikacyjnym 500 i należy do następujących grup: “oracle”, “vboxsf”, “dba”.

W tym konkretnym przypadku, użytkownik “oracle” należy do grupy systemu operacyjnego “dba”, a

więc może się łączyć do instancji bazy danych jako “SYS” i nie musi podawać hasła bo uwierzytelnia go

system operacyjny (poprzez grupę “dba” do której należy) np:


Dla przykładu, inny użytkownik systemu operacyjnego, który nie należy do grupy “dba”, będzie musiał

jawnie podać hasło bo system operacyjny sam go nie uwierzytelni.

Aby odebrać użytkownikowi “oracle” członkostwo w grupie “dba” należy wykonać jako administrator

Linuxa następujące polecenia:

1. przelogować się w terminalu tekstowym na administratora Linuxa “root” z hasłem “oracle”:

su – root

2. Wyłączamy usługe nscd (buforującą inne usługi nazewnicze)

/etc/init.d/nscd stop

3. przydzielamy użytkownikowi “oracle” tylko domyślną grupę “oracle”, bez “dba”

usermod –G oracle oracle

4. ponownie przelogowujemy się na użytkownika “oracle”

su - oracle

5. łączymy się do bazy danych jako użytkownik “SYS”


6. baza prosi o podanie hasła – ponieważ “oracle” nie należy do grupy “dba” nie może

wejść do bazy bez hasła.

7. wracamy do poprzednich ustawień, a więc ponownie przydzielamy użytkownika “oracle”

do grupy “dba”, a także do pozostałych grup do których wcześniej należał. Włączamy usługę

buforującą nscd

su – root

usermod –a –G vboxsf,dba oracle

/etc/init.d/nscd start



8. przelogowujemy się ponownie na użytkownika “oracle” i sprawdzamy w jakich jest grupach

i łączymy się do bazy jako “SYS” bez hasła bo tym razem należy do grupy “dba”

su - oracle

id


Uwierzytelnianie administratorów za pomocą pliku haseł Podczas połączeń zdalnych oraz lokalnych jako SYS, gdy użytkownik systemu operacyjnego nie należy

do grupy “dba” wykorzystuje się plik haseł zamiast uwierzytelniania przez system operacyjny. W pliku

haseł przechowywane są hasła i uprawnienia tylko tych użytkowników, którzy posiadają uprawnienia

SYSDBA lub SYSOPER. Aby sprawdzić czy plik haseł jest wykorzystywany należy sprawdzić parametr

bazy danych REMOTE_LOGIN_PASSWORDFILE po zalogowaniu do bazy:


SHOW PARAMETER REMOTE_LOGIN_PASSWORDFILE

Parametr powinien być ustawiony na wartość EXCLUSIVE co oznacza, że ten plik haseł jest używany

tylko przez tę instancję bazy danych.

W przypadku wartości NONE oznacza to, że plik haseł nie jest wykorzystywany.

Dodatkowo, można sprawdzić zawartość pliku haseł w widoku V$PWFILE_USERS np:

SELECT * FROM V$PWFILE_USERS;

Można wyłączyć uwierzytelnianie administratorów bazy (np. SYS-a) przez plik haseł i pozostawić jako

jedyną metodę uwierzytelniania system operacyjny:

ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=NONE SCOPE=SPFILE;

SHUTDOWN IMMEDIATE;

STARTUP;

Od tego momentu plik haseł nie będzie używany. Będzie można się zalogować jako SYS tylko za pomocą

uwierzytelnienia przez system operacyjny.

Domyślny plik haseł orapwSID standardowo w systemie Linux znajduje się w katalogu:

$ORACLE_HOME/dbs

np:

/u01/app/oracle/product/11.2.0/db_home_1/dbs/orapworcl



Zarządzanie zwykłymi kontami użytkowników w bazie danych Tożsamość aktualnie zalogowanego użytkownika w sqlplus można sprawdzić w zmiennej USER za

pomocą następującego zapytania:

SELECT USER FROM DUAL;

Administrator (np. SYS) może sprawdzić istniejące konta użytkowników w widoku DBA_USERS:

DESC DBA_USERS

SELECT USERNAME, ACCOUNT_STATUS, EXPIRY_DATE FROM DBA_USERS;

Aby stworzyć nowego użytkownika należy wykonać następujące polecenie:

CREATE USER TEST IDENTIFIED BY password DEFAULT TABLESPACE USERS

ACCOUNT LOCK;

Powyższe polecenie tworzy konto użytkownika TEST z hasłem “password”, z domyślną przestrzenią

tabel USERS które od razu jest zablokowane.

Aby je odblokować należy wykonać:

ALTER USER TEST ACCOUNT UNLOCK;

Aby zmienić hasło tego użytkownika należy wykonać polecenie:

ALTER USER TEST IDENTIFIED BY new_password;

Przydział 1MB limitu (quota) w przestrzeni tabel USERS:

ALTER USER TEST QUOTA 1M ON USERS;

Aby zmusić użytkownika do zmiany hasła przy następnym logowaniu należy wygasić mu aktualne hasło:

ALTER USER TEST PASSWORD EXPIRE;

Aby zmienić profil użytkownika np. na profil o nazwie “RESTRICT” należy wykonać polecenie (profil musi

istnieć):

ALTER USER TEST PROFILE RESTRICT;

Przywrócenie domyślnego profilu:

ALTER USER TEST PROFILE DEFAULT;

Usunięcie użytkownika wraz ze wszystkimi jego obiektami i danymi

DROP USER TEST CASCADE;



Zarządzanie uprawnieniami użytkowników Uprawnienia użytkowników dzielą się na:

systemowe (dotyczące zarządzania instancją bądź możliwością manipulacji na obiektach)

obiektowe (dotyczące zarządzania danymi w obiektach np. select, insert, update)

Do systemowych należą np:

CREATE SESSION

ALTER USER

ALTER SYSTEM

CREATE TABLE

itp.

Kilka przykładów przydzielania uprawnień systemowych:

GRANT CREATE SESSION TO TEST;

GRANT ALTER SYSTEM TO TEST;

GRANT SYSDBA TO TEST;

GRANT CREATE TABLE TO TEST WITH ADMIN OPTION;

Klauzula “WITH ADMIN OPTION” oznacza, że użytkownik któremu przydzielamy to uprawnienie może je

sam dalej nadawać innym użytkownikom.

Do obiektowych należą między innymi:

SELECT

INSERT

DELETE

UPDATE

Przydzielanie uprawnień odbywa się przez osobę która jest właścicielem obiektu lub dostała

uprawnienia z opcją WITH GRANT OPTION np:

GRANT SELECT, UPDATE, DELETE, INSERT ON MY_TABLE TO TEST;

GRANT SELECT ANY TABLE TO TEST WITH GRANT OPTION;



Klauzula “WITH GRANT OPTION” oznacza, że użytkownik któremu przydzielamy to uprawnienie może je

sam dalej nadawać innym użytkownikom.

Uprawnienia zabiera się poleceniem REVOKE:

REVOKE SELECT ANY TABLE FROM TEST;

REVOKE CREATE SESSION FROM TEST;

REVOKE SYSDBA FROM TEST;

Administratorzy i zwykli użytkownicy mogą sprawdzać swoje uprawnienia w następujących widokach

Użytkownicy:

USER_SYS_PRIVS – uprawnienia systemowe zalogowanego użytkownika

USER_TAB_PRIVS – uprawnienia obiektowe zalogowanego użytkownika

USER_ROLE_PRIVS – role przydzielone zalogowanemu użytkownikowi

Administratorzy mogą sprawdzać uprawnienia wszystkich użytkowników w widokach:

DBA_SYS_PRIVS

DBA_TAB_PRIVS

DBA_ ROLE_PRIVS

Zarządzanie rolami Przydzielanie pojedynczych uprawnień systemowych czy obiektowych może być pracochłonne i

uciążliwe. Dlatego dużo lepiej zarządzać autoryzacją użytkowników poprzez role. Rola może zawierać w

sobie:

uprawnienia systemowe

uprawnienia obiektowe

inne role

Oto kilka przykładów operacji na rolach:

Stworzenie nowej zwykłej roli:

CREATE ROLE POWER_USER;

Stworzenie roli zabezpieczonej hasłem:

CREATE ROLE VERY_POWER_USER IDENTIFIED BY password;

Przydzielenie uprawnień do roli



GRANT CREATE SESSION TO POWER_USER;

GRANT SELECT ANY TABLE, UPDATE ANY TABLE TO POWER_USER;

przydzielenie roli do innej roli:

GRANT POWER_USER TO VERY_POWER_USER;

przydzielenie roli do użytkownika:

GRANT VERY_POWER_USER TO TEST;

Przydzielona rola zwykła jest uaktywniana w momencie logowania użytkownika. Jeśli rola jest chroniona

hasłem to użytkownik musi ją samodzielnie uaktywnić:

SET ROLE VERY_POWER_USER IDENTIFIED BY password;

Uaktywnione samodzielnie przez użytkownika role można sprawdzić w widoku SESSION_ROLES:

SELECT ROLE FROM SESSION_ROLES;

Wyłączenie wszystkich uaktywnionych samodzielnie ról:

SET ROLE NONE;

Przydział uprawnień do ról można sprawdzać w następujących widokach:

ROLE_SYS_PRIVS – uprawnienia systemowe w rolach

ROLE_TAB_PRIVS – uprawnienia obiektowe w rolach

ROLE_ROLE_PRIVS – inne role przydzielone w rolach

Profile Profil to zbiór ograniczeń i restrykcji jakie można nałożyć na konta użytkowników. Za pomocą profili

można sterować:

złożoność haseł użytkowników

czas aktywności haseł

czasu trwania sesji i bezczynności

ilości operacji I/O

ilości używanego procesora

itp.

Aby profile zaczęły działać w bazie należy włączyć tę funkcjonalność ustawiając parametr:

RESOURCE_LIMIT



ALTER SYSTEM SET RESOURCE_LIMIT=TRUE;

Następnie można utworzyć profil i określić w nim kolejne ograniczenia zużycia zasobów serwera lub

polityki haseł:

CREATE PROFILE MY_PROFILE LIMIT

CPU_PER_SESSION 60000

LOGICAL_READS_PER_SESSION 1000

CONNECT_TIME 30

PRIVATE_SGA 102400

CPU_PER_CALL UNLIMITED

COMPOSITE_LIMIT 60000000

FAILED_LOGIN_ATTEMPTS 3

PASSWORD_LIFE_TIME 90

PASSWORD_REUSE_TIME 180

PASSWORD_LOCK_TIME 3

PASSWORD_GRACE_TIME 3;

Utworzony profil następnie należy przedzielić użytkownikom:

ALTER USER TEST PROFILE MY_PROFILE;

Zarządzanie za pomocą narzędzia Enterprise Manager Zarządzanie użytkownikami, uprawnieniami, rolami i profilami można również z poziomu narzędzia

Enterprise Manager (EM). Aby włączyć EM należy wykonać polecenie w terminalu Linuxa

emctl start dbconsole

Następnie wewnątrz maszyny wirtualnej uruchomić przeglądarkę i skorzystać z linka: Enterprise

Manager. Po zalogowaniu jako użytkownik sys z hasłem oracle jako sysdba należy przejść do

zakładki Server i w sekcji Security wybrać właściwą opcję tak jak na rysunku poniżej:



Oracle Virtual Private Databese (VPD) – niskopoziomowe zarządzanie

uprawnieniami Mechanizm Virtual Private Database to bardzo przydatna funkcjonalność, stosowana kiedy chcemy

ograniczyć użytkownikom uprawnienia na poziomie niższym niż tabela, a więc na poziomie wierszy lub

kolumn. Za pomocą standardowych mechanizmów uprawnień systemowych i obiektowych nie da się

zrealizować na przykład ograniczenia widoczności pewnych konkretnych wierszy w tabeli czy

dostępności wartości w kolumnach. Przeanalizujmny poniższy przykład:

W tabeli EMP (employees – czyli pracownicy) są wpisy dotyczące wszystkich pracowników w firmie (wraz

z ich zarobkami, które najczęściej są tajne i dostępne indywidualnie tylko dla pracownika. Jedynie osoby

zatrudnione w kadrach (dział HR) mają wgląd w dane wszystkich pracowników. Tak więc pracownik i

jednocześnie użytkownik bazy danych MIKE, wykonując zapytania typu SELECT na tabeli EMP powinien

widzieć tylko swoje dane (1 wiersz), a pracownik kadr - HR powinien widzieć wszystkie wiersze z tabeli.

Tak więc bez względu na zalogowanego użytkownika do bazy danych (HR lub MIKE) po wykonaniu tego

samego polecenia

SELECT * FROM HR.EMP;

1. Użytkownik MIKE otrzyma tylko jeden wiersz z wpisem dotyczącym jego samego

2. Użytkownik HR otrzyma rekordy wszystkich pracowników z tabeli EMP.

Obaj użytkownicy (HR i MIKE) posiadają uprawnienie SELECT do tabeli EMP, a więc zgodnie ze

standardowym mechanizmem uprawnień obiektowych powinni mieć dostęp do wszystkich rekordów.

Dopiero zastosowanie dodatkowych polityk VPD pozwala osiągnąć planowany efekt.



Przygotowanie bazy danych do pracy z VPD VPD w celu ograniczenia dostępu do wierszy niejawnie dodaje do zapytań SQL wydawanych przez

użytkowników dodatkową klauzulę WHERE bazując na funkcji PL/SQL np:

CREATE OR REPLACE FUNCTION VPD_FILTER_EMP_ROWS (

schema_var IN VARCHAR2,

table_var IN VARCHAR2

)

RETURN VARCHAR2

IS

return_val VARCHAR2 (400);

BEGIN

return_val := 'SALARY < 6000';

RETURN return_val;

END vpd_filter_emp_rows;

/

Powyższa funkcja PL/SQL o nazwie VPD_FILTER_EMP_ROWS zwraca dodatkowy składnik w klauzuli

WHERE: SALARY < 6000. Czyli ta funkcja ogranicza użytkownikom widoczność wierszy dla których

wartości w kolumnie SALARY są większę lub równe od 6000.

Mając już skompilowaną funkcję w bazie (najczęściej w schemacie SYS) należy jeszcze zarejestrować ją

jako politykę w VPD wywołując procedurę PL/SQL ADD_POLICY z pakietu DBMS_RLS:

DBMS_RLS.ADD_POLICY (

OBJECT_SCHEMA => 'HR',

OBJECT_NAME => 'EMP',

POLICY_NAME => 'FILTER_EMP_ROWS_POLICY',

FUNCTION_SCHEMA => 'SYS',

POLICY_FUNCTION => 'VPD_FILTER_EMP_ROWS',

STATEMENT_TYPES => 'SELECT, INSERT, UPDATE, DELETE'

);

Powyższa polityka będzie mieć zastosowanie na tabeli EMP w schemacie HR na poleceniach SQL typu

SELECT, INSERT, UPDATE, DELETE.

Wszyscy użytkownicy bazy danych, którzy nie posiadają uprawnienia EXEMPT ACCESS POLICY

będą pod kontrolą polityki VPD o nazwie z przykładu powyżej: FILTER_EMP_ROWS_POLICY i będą

widzieć tylko wiersze z wartością kolumny SALARY mniejszej od 6000.



Ćwiczenia

Ćwiczenie 1 – Logowanie jako administrator bazy danych

Wszystkie poniższe ćwiczenia wykonywać na działającej instancji bazy danych

1. Z poziomu systemu operacyjnego Linux sprawdzić w jakich grupach znajdują się użytkownicy

systemu operacyjnego “oracle” oraz “root” oraz czy któryś z nich należy do grupy “dba”.

2. Otworzyć nowy terminal tekstowy Linuxa, a następnie:

a. upewnić się, że zalogowany użytkownik systemu operacyjnego to “oracle”

b. podłączyć się za pomocą sqlplus do instancji bazy danych jako użytkownik “jan” z

hasłem “test” jako sysdba

c. sprawdzić czy użytkownik “jan” jest zarejestrowanym kontem w bazie danych

d. jeśli nie jest, to zastanowić się dlaczego udało się zalogować do bazy danych jako

użytkownik “jan”?

e. sprawdzić w sqlplus tożsamość zalogowanego użytkownika

3. Zarządzanie plikami haseł

a. zlokalizować w systemie operacyjnym Linux jak nazywa się i w jakim katalogu znajduje

się plik haseł

b. po zalogowaniu do bazy za pomocą sqlplus sprawdzić zawartość pliku haseł, a więc

kto ma uprawnienia SYSDBA i SYSOPER

4. Blokowanie uwierzytelniania przez system operacyjny Linux administratorów bazy danych

a. jako administrator systemu operacyjnego “root” odebrać członkostwo w grupie “dba”

użytkownikowi “oracle”

b. ponownie zmienić tożsamość na użytkownika “oracle” i upewnić się, że nie jest w

grupie “dba”

c. spróbować zalogować się do bazy jako “sys” za pomocą sqlplus. Czy baza prosi o

hasło dla użytkownika “sys”?

d. przywrócić członkostwo w grupie systemu operacyjnego “dba” użytkownikowi

“oracle”

Ćwiczenie 2 – Zarządzanie kontami użytkowników bazy danych

Wszystkie operacje w tym ćwiczeniu wykonać w SQLPLUS

1. Zalogować się do bazy danych jako “sys”

2. Sprawdzić jakie są zarejestrowane konta użytkowników w bazie wraz z ich statusem

3. Utworzyć nowego użytkownika bazy danych



a. o nazwie “u1” z hasłem “test”

b. z domyślną przestrzenią tabel USERS

c. z domyślną przestrzenią tymczasową TEMP

d. z odblokowanym statusem konta

4. Spróbować zalogować się za pomocą sqlplus na konto użytkownika “u1” z hasłem “test”.

Jeśli się nie udało to zastanowić się dlaczego?

5. Ponownie zalogować się jako “sys”

6. Przydzielić uprawnienie CREATE SESSION użytkownikowi “u1”

7. Ponownie spróbować się zalogować na konto użytkownika “u1”. Czy teraz się udało?

8. Spróbować utworzyć dowolną tabele o nazwie “t1” jako użytkownik “u1”. Czy się udało?

9. Jako “sys” przydzielić uprawnienie CREATE TABLE użytkownikowi “u1”

10. Ponownie spróbować utworzyć tabele “t1” jako “u1”. Czy tym razem się udało?

11. Spróbować wprowadzić kilka wierszy to utworzonej tabeli. Czy się udało?

12. Jako “sys” przydzielić limit (quota) w przestrzeni tabel USERS użytkownikowi “u1” na poziomie

1MB

13. Ponownie sprawdzić czy użytkownik “u1” może tworzyć wiersze we wcześniej utworzonej tabeli.

Ćwiczenie 3 – Uprawnienia

Wszystkie operacje w tym ćwiczeniu wykonać w SQLPLUS

1. Utworzyć dwóch kolejnych użytkowników “u2” i “u3”.

2. Przydzielić uprawnienie CREATE SESSION WITH ADMIN OPTION użytkownikowi “u1”

3. Zalogować się jako “u1” i przydzielić uprawnienie CREATE SESSION użytkownikom “u2” i

“u3”

4. Sprawdzić czy użytkownicy “u2” i “u3” mogą się zalogować do bazy.

5. Jako “sys” odebrać uprawnienie CREATE SESSION użytkownikowi “u1”. Czy pozostali

użytkownicy, którym “u1” przydzielił to uprawnienie nadal je mają?

6. Przywrócić uprawnienie CREATE SESSION użytkownikowi „u1”

7. Jako “u1” nadać uprawnienie czytania tabeli “u1.t1” użytkownikowi “u2” z opcją WITH

GRANT OPTION

8. Jako “u2” nadać uprawnienie czytania tabeli “u1.t1” użytkownikowi “u3”.

9. Sprawdzić czy “u3” może czytać tabele “u1.t1”

10. Jako “u1” odebrać uprawnienie do czytania tabeli “u1.t1” użytkownikowi “u2”

11. Sprawdzić czy nadal użytkownicy “u2” , a w szczególności “u3” mogą czytać tabelę “u1.t1”.

Jeśli nie to dlaczego?

Ćwiczenie 4 – Role

1. Stworzyć dwie role:



a. “power”

b. “super_power” chronioną hasłem

2. Przydzielić kilka uprawnień systemowych i obiektowych roli “power”

3. Przydzielić kilka uprawnień systemowych i obiektowych roli “power_user”

4. Przydzielić obie role użytkownikowi u1;

5. Sprawdzić czy użytkownik posiada przydzielone uprawnienia poprzez rolę “power”.

6. Aktywować rolę “super_power” i sprawdzić uprawnienia

Ćwiczenie 5 – Profile 1. Aktywować funkcjonalność ograniczania zasobów za pomocą profili.

2. Za pomocą SQLPLUS-a lub za pomocą Enterprise Manager-a stworzyć profil “RESTRICT” z

następującymi parametrami:

a. CPU_PER_SESSION 10 [setnych sekundy]

b. LOGICAL_READS_PER_SESSION 2 [ilość odczytanych bloków]

c. CONNECT_TIME 5 [minut]

d. PRIVATE_SGA 1 [KB lub MB]

e. CPU_PER_CALL 1 [czas procesora w setnych sekundy]

f. FAILED_LOGIN_ATTEMPTS 3 [razy]

g. PASSWORD_LIFE_TIME 1 [dni]

h. PASSWORD_REUSE_TIME 3 [dni]

i. PASSWORD_LOCK_TIME 3 [razy]

j. PASSWORD_GRACE_TIME 3 [dni]

3. Przypisać stworzony profil użytkownikowi “u1”

4. Zalogować się jako U1 i sprawdzić jak profil wpływa na konto użytkownika

Ćwiczenie 6 – Virtual Private Database 1. Pobrać plik vpd.zip z systemu http://moodle.porozum.pl

2. Przenieść plik do maszyny wirtualnej zgodnie z procedurą pokazaną na zajęciach przez

prowadzącego lub według kroków spisanych w dokumencie: Instrukcja używania VirtualBox-a i

SQLPLUS-a

a. rodział: “Virtual Box – podłączanie zewnętrznych katalogów do maszyny wirtualnej”

3. Rozpakować archiwum zip za pomocą polecenia unzip w systemie Linux.

a. unzip vpd.zip

4. Uruchomić SQLPLUS i zalogować się jako SYS

5. Otworzyć, zapoznać się, a nastęnie uruchomić następujące skrypty w podanej niżej kolejności:

a. vpd_user_table.sql

b. vpd_func.sql

c. vpd_policy.sql

6. Uruchamianie skryptów odbywa się w SQLPLUS za pomocą symbolu @ podając pełną scieżkę do

pliku w systemie Linux np:

http://moodle.porozum.pl/

http://moodle.porozum.pl/mod/resource/view.php?id=428

http://moodle.porozum.pl/mod/resource/view.php?id=428



d. @/mnt/vpd_user_table.sql

e. Skrypty tworzą nowego użytkownika MIKE oraz tabele EMP w schemacie HR.

7. Testowanie czy VPD działa:

f. zalogować się jako użytkownik HR z hasłem oracle

g. pobrać wiersze z tabeli: SELECT * FROM EMP

h. Następnie zalogować się jako użytkownik MIKE z hasłem oracle

i. Ponownie pobrać wszystkie wiersze w tabeli EMP: SELECT * FROM EMP

8. Czy użytkownicy HR i MIKE widzą te same dane w tabeli HR? Jeśli nie to analizując kod funkcji w

skrypcie vpd_func.sql znaleźć dodatkową klauzulę dodawaną do sekcji WHERE przez Virtual

Private Database.

9. Wyczyścić środowisko bazy danych uruchamiając skrypt vpd_clean.sql

a. @/mnt/vpd_clean.sql



Odpowiedzi do zadań

Ćwiczenie 1 1. Otwieram terminal tekstowy i sprawdzam użytkowników

a. id [aktualnego użytkownika]

b. su – root

c. id [użytkownika root po wcześniejszym przelogowaniu]

2. Otwieram nowy terminal tekstowy

a. id

b. sqlplus jan/test as sysdba

c. SELECT USERNAME FROM DBA_USERS;

d. użytkownik JAN nie istnieje w bazie. Zamiast tego został uwierzytelniony SYS

e. SELECT USER FROM DUAL;

3. Plik haseł domyślnie znajduje się w katalogu $ORACLE_HOME/dbs

a. /u01/app/oracle/product/11.2.0/db_home_1/dbs/orapworcl

b. sqlplus / as sysdba

c. SELECT * FROM V$PWFILE_USERS;

4. Jako administrator Linuxa odbieram członkostwo w grupie “dba” użytkownikowi “oracle”.

Wcześniej wyłączam buforowanie usług nazewniczych: nscd

a. su – root

b. /etc/init.d/nscd stop

c. usermod –G oracle oracle

d. su – oracle

e. sqlplus sys as sysdba [bez wpisania hasła SYS nie wejdzie

do bazy]

f. su – root

g. usermod –G dba,vboxsf oracle

h. /etc/init.d/nscd start



Ćwiczenie 2 1. sqlplus sys as sysdba

2. SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS;

3. Tworzę nowego użytkownika “u1”

A. CREATE USER U1 IDENTIFIED BY TEST DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP ACCOUNT UNLOCK;

4. Logowanie się nie powiedzie bo użytkownik nie posiada uprawnienia CREATE SESSION

5. sqlplus sys as sysdba

6. GRANT CREATE SESSION TO U1;

7. CONN U1

8. Tabeli się nie da utworzyć bo użytkownik nie ma uprawnienia CREATE SESSION

9. CONN / AS SYSDBA

A. GRANT CREATE TABLE TO U1;

10. CREATE TABLE T1 (ID NUMBER);

11. Nie da się wprowadzić wierszy do tabeli bo użytkownik nie ma ustawionego limitu w domyślnej przestrzeni tabel

12. ALTER USER U1 QUOTA 1M ON USERS;

13. Tym razem uda się wprowadzić wiersze do tabeli.

Ćwiczenie 3 1. Tworzenie użytkowników u2 i u3

A. CREATE USER U2 IDENTIFIED BY test;

B. CREATE USER U3 IDENTIFIED BY test;

2. GRANT CREATE SESSION TO U1 WITH ADMIN OPTION;

3. Łącze się jako u1 i przydzielam CREATE SESSION do U2 i U3

A. CONN U1

B. GRANT CREATE SESSION TO U2, U3;

4. CONN U2/test

5. Odbieram uprawnienia CREATE SESSION użytkownikowi U1



A. CONN SYS AS SYSDBA

B. REVOKE CREATE SESSION FROM U1;

c. Tak, U2 i U3 mają ciągle te uprawnienia bo przydzielone zostały z opcją WITH ADMIN

OPTION więc nie są potem usuwane kaskadowo

6. Uprawnienia obiektowe z GRANT OPTION

A. CONN U1

B. GRANT SELECT ON U1.T1 TO U2 WITH GRANT OPTION;

7. Jako U2 przydzielić uprawnienie select on U1.T1 do U3

A. CONN U2

B. GRANT SELECT ON U1.T1 TO U3;

8. Jako U3 sprawdzam czy mogę czytać tabelę U1.T1

A. CONN U3

B. SELECT * FROM U1.T1;

c. U3 ma takie uprawnienie

9. Jako U1 odbieram uprawnienie do czytania tabeli U1.T1 użytkownikowi U2

A. CONN U1

B. REVOKE SELECT ON U1.T1 FROM U2;

10. Sprawdzam czy U3 może czytać tabele U1.T1

A. CONN U3

B. SELECT * FROM U1.T1;

c. U3 nie ma już uprawnień do czytania tabeli u1.t1 bo po odebraniu tych uprawnień od U2

zostały one kaskadowo odebrane również U3.

Ćwiczenie 4 – role

1. Tworzę dwie role


B. CREATE ROLE POWER;

C. CREATE ROLE SUPER_POWER IDENTIFIED BY test;



2. Przydzielam kilka uprawnień do dwóch ról

A. GRANT CREATE SESSION TO POWER;

B. GRANT CRATE TABLE TO POWER;

C. GRANT CREATE VIEW TO POWER;

3. GRANT ALTER SYSTEM TO SUPER_POWER;

4. Przydzielam obie role użytkownikowi U1

A. GRANT POWER TO U1;

B. GRANT SUPER_POWER TO U1;

5. Sprawdzam czy U1 ma przydzielone uprawnienia poprzez rolę POWER

A. CONN U1

b. Tak, U1 ma te uprawnienia

6. Aktywuje uprawnienia SUPER_POWER

A. SET ROLE SUPER_POWER IDENTIFIED BY test;

B. SELECT * FROM SESSION_ROLES;

Ćwiczenie 5 – profile

1. Aktywowanie funkcjonalności profili w bazie


B. ALTER SYSTEM SET RESOURCE_LIMIT=TRUE;

2. CREATE PROFILE RESTRICT LIMIT

CPU_PER_SESSION 10

LOGICAL_READS_PER_SESSION 2

CONNECT_TIME 5

PRIVATE_SGA 1K

CPU_PER_CALL 1

FAILED_LOGIN_ATTEMPTS 3

PASSWORD_LIFE_TIME 1

PASSWORD_REUSE_TIME 3

PASSWORD_LOCK_TIME 3

PASSWORD_GRACE_TIME 3;

3. ALTER USER U1 PROFILE RESTRICT;



4. CONN U1

5. Użytkownik nawet nie może się zalogować bo operacja logowania wykorzystuje wszystkie

ustawione limity.

Documents

Zarządzanie użytkownikami bazy danych Oracle 11gmst.webd.pl/_sggw/oracle/laboratorium_nr_5_i_6_-_zarz_dzanie_u... · Oracle Virtual Private Databese (VPD) – niskopoziomowe zarządzanie