Oracle 8i DBA-Handbuch - ReadingSample - beck-shop.de€¦ · Oracle 8i DBA-Handbuch Bearbeitet von...

Oracle 8i DBA-Handbuch

Bearbeitet vonHans Hajer, Kevin Loney, Marlene Theriault

1. Auflage 2001. Buch. XVIII, 965 S. HardcoverISBN 978 3 446 21569 6

Format (B x L): 16,2 x 22,7 cmGewicht: 1468 g

Zu Inhaltsverzeichnis

schnell und portofrei erhältlich bei

Die Online-Fachbuchhandlung beck-shop.de ist spezialisiert auf Fachbücher, insbesondere Recht, Steuern und Wirtschaft.Im Sortiment finden Sie alle Medien (Bücher, Zeitschriften, CDs, eBooks, etc.) aller Verlage. Ergänzt wird das Programmdurch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr

als 8 Millionen Produkte.

http://www.beck-shop.de/Loney-Theriault-Oracle-8i-DBA-Handbuch/productview.aspx?product=476877&utm_source=pdf&utm_medium=clickthru_lp&utm_campaign=pdf_476877&campaign=pdf/476877

http://www.beck-shop.de/fachbuch/inhaltsverzeichnis/9783446215696_TOC_001.pdf

99Datenbanksicherheit

und Auditing

Massive Schlösser, geheime Passwörter, Lichtschranken, vergitterte Zufahrten, Zu-gangskarten, Sicherheitspatrouillen – diese Schichten der physischen Sicherheit in derrealen Welt finden sich auch bei den Datenbanken.

Der Aufbau und die Erzwingung von Sicherheitsprozeduren hilft das zu schützen, wasschnell der wertvollste Aktivposten eines Unternehmens wird: die Daten. Und währenddas Speichern der Daten in einer Datenbank sie viel nützlicher und unternehmensweitverfügbar macht, sind sie dadurch gleichzeitig der Gefahr von nicht autorisierten Zu-griffen ausgesetzt. Solche Zugriffsversuche müssen verhindert und aufgedeckt werden.

Die ORACLE-Datenbank verfügt über verschiedene Sicherheitsschichten und die Fä-higkeit, jede Ebene im Zuge eines Audits zu überwachen. In diesem Kapitel finden Siedie Beschreibungen jeder Schicht des Auditing-Prozesses. Sie werden auch Methodenzur Einstellung unmöglicher Passwörter und für das Begrenzen der Gültigkeitsdauervon Passwörtern kennen lernen.

9.1 Leistungsmerkmale zur SicherheitORACLE stellt dem DBA mehrere Sicherheitsebenen zur Verfügung:

� Account-Sicherheit zur Bestätigung der Benutzer

� Zugriffssicherheit für Datenbankobjekte

� Sicherheit auf Systemebene zur Verwaltung globaler Berechtigungen

Jedes dieser Leistungsmerkmale wird in einem der folgenden Abschnitte beschrieben;unter der Überschrift „Implementierung der Sicherheit“ finden Sie Einzelheiten zumeffektiven Einsatz dieser Optionen.

372 9 Datenbanksicherheit und Auditing

9.1.1 Account-Sicherheit

Für den Zugriff auf die Daten in einer ORACLE-Datenbank müssen Sie Zugang zueinem Account in dieser Datenbank haben. Dieser Zugang kann – über die Benutzer-verbindungen zur Datenbank – direkt oder indirekt sein. Indirekte Verbindungen be-inhalten den Zugang über vordefinierte Autorisierungen in den Datenbank-Links.Jedem Acount muss ein Passwort zugeordnet sein. Ein Datenbank-Account kannauch mit einem System-Account verknüpft sein.

Die Passwörter für einen Benutzer werden bei der Einrichtung des Accounts gesetztund können entweder vom DBA oder vom Benutzer geändert werden. Die Datenbankspeichert eine verschlüsselte Version des Passworts in einer Data Dictionary-Tabelle.Ist der Account direkt mit einem Betriebssystem-Account verknüpft, kann die Pass-wortprüfung umgangen werden.

Seit ORACLE8 können Passwörter verfallen, wobei der DBA festlegt, unter welchenBedingungen ein Passwort erneut verwendet werden kann. Zur Erzwingung von Stan-dards für die Passwörter (beispielsweise einer Mindestlänge) können Profile eingesetztwerden. Zudem besteht die Möglichkeit, Accounts automatisch zu sperren, bei denenmehrere aufeinander folgende Fehlversuche der Verbindungsaufnahme stattgefundenhaben.

9.1.2 Objektberechtigungen

Der Zugriff auf Objekte innerhalb einer Datenbank erfolgt über Berechtigungen. Sie er-lauben über den grant-Befehl die Ausführung spezieller Datenbankbefehle auf be-stimmte Datenbankobjekte. Wenn der Benutzer THUMPER beispielsweise eineTabelle namens EMPLOYEE besitzt und den Befehl

grant select on EMPLOYEE to PUBLIC;

ausführt, können alle Benutzer (PUBLIC) Daten aus dieser Tabelle auswählen. Rollen– benannte Gruppen von Berechtigungen – vereinfachen die Verwaltung der Berech-tigungen. Bei Anwendungen mit vielen Benutzern reduzieren die Rollen die Anzahlder notwendigen grant-Befehle. Da Rollen passwortgeschützt sind und sich dyna-misch aktivieren oder deaktivieren lassen, stellen sie eine weitere Sicherheitsebene inder Datenbank dar.

9.1.3 Rollen und Berechtigungen auf Systemebene

Zur Verwaltung der Befehle auf Systemebene, die den Benutzern zur Verfügung stehen,bieten sich die Rollen an. Zu diesen Befehlen gehören create table und alter index. Ak-tionen auf jeden Datenbankobjekttyp werden über eigene Berechtigungen gewährt. So

9.2 Implementierung der Sicherheit 373

kann ein Benutzer beispielsweise zwar die CREATE TABLE-, aber nicht die CREATETYPE-Berechtigung besitzen. Über spezifische Systemebenenrollen haben Sie die Mög-lichkeit, den Benutzern exakt die notwendigen Berechtigungen zuzuordnen. Wie in Ka-pitel 5 angemerkt, sind die CONNECT- und die RESOURCE-Rollen ideal für diegrundlegenden Systemberechtigungen, die Benutzer und Entwickler benötigen.

9.2 Implementierung der SicherheitZu den Sicherheitsmerkmalen in ORACLE gehören Rollen, Profile und die direkte Zu-weisung von Berechtigungen. In den folgenden Abschnitten werden Sie die Verwen-dung dieser Leistungsmerkmale und einige nicht dokumentierte Leistungsmerkmalekennen lernen.

9.2.1 Der Startpunkt: die Betriebssystemsicherheit

Der Zugriff auf eine Datenbank ist unmöglich, wenn Sie vorher nicht direkt oder in-direkt auf den Server zugreifen können, auf dem die Datenbank läuft. Der erste Schrittzur Sicherung Ihrer Datenbank ist die Absicherung der Plattform und des Netzwerks,auf dem die Komponenten liegen. Danach muss man sich mit der Betriebssystemsi-cherheit beschäftigen.

ORACLE benutzt eine Reihe von Dateien, auf die der Benutzer keinen direkten Zugriffhaben muss. So werden beispielsweise die Datendateien und die Online Redo Log-Da-teien nur von den ORACLE-Hintergrundprozessen gelesen und geschrieben. Das be-deutet, dass nur der DBA, der diese Dateien anlegt und löscht, einen direktenZugriffspfad auf Betriebssystemebene benötigt. Auch die Export-Dump-Dateien undandere Sicherungsdateien müssen gesichert werden.

9.2.2 Benutzer einrichten

Beim Anlegen eines Benutzers besteht das Ziel in der Einrichtung eines sicheren undangemessenen Accounts, der die adäquaten Berechtigungen und richtigen Standard-einstellungen besitzt. Über den create user-Befehl legen Sie einen neuen Datenbank-Account an. Nach dem Anlegen besitzt der Account keinerlei Fähigkeiten – er kann sichbeispielsweise nicht anmelden, bis die entsprechende Berechtigung gewährt wurde.

Alle notwendigen Einstellungen für einen Benutzer-Account lassen sich in einem ein-zigen create user-Befehl hinterlegen. Diese Einstellungen umfassen die Werte für allein Tabelle 9-1 aufgeführten Parameter.

Das folgende Listing zeigt ein Beispiel für den create user-Befehl. In diesem Beispielwird der Benutzer THUMPER mit dem Passwort RABBIT, dem Standard-Tablespace


USERS, einem temporären Tablespace TEMP, ohne Speicherplatzkontingent und mitdem Standardprofil angelegt:

create user THUMPERidentified by RABBITdefault tablespace USERStemporary tablespace TEMP;

Da kein Profil angegeben war, wird das Standardprofil für die Datenbank genutzt. Dasist ein existierendes Profil namens DEFAULT; dessen Anfangseinstellung setzt alleGrenzen für den Ressourcenverbrauch auf UNLIMITED. Für weitere Einzelheiten zuden Profilen siehe „Benutzerprofile“.

Da kein Speicherplatzkontingent angegeben wurde, kann der Benutzer in der Daten-bank keine Objekte anlegen. Zur Gewährung von Ressourcenkontingenten wird derquota-Parameter des create user- oder alter user-Befehls verwendet (siehe folgendesListing). In diesem Beispiel wird THUMPER im Tablespace USERS ein Speicherplatz-kontingent von 100MB zugewiesen.

alter user THUMPERquota 100M on USERS;

Tabelle 9-1: Parameter für den create user-Befehl.

Parameter Verwendung

Username Passwörter für den Account; kann auch direkt mit dem Account-

Namen des Betriebssystems verknüpft sein.

Default tablespace Der Standard-Tablespace, in dem alle in diesem Schema

angelegten Objekte gespeichert sind. Diese Einstellung gibt dem

Benutzer keine Berechtigung zur Einrichtung von Objekten; sie

setzt nur einen Standardwert.

Temporary tablespace Der Tablespace, in dem die temporären Segmente bei Sortier-

transaktionen gespeichert werden.

Quota [on tablespace] Ermöglicht dem Benutzer das Speichern von Objekten im

angegebenen Tablespace bis zur festgelegten Obergrenze.

Profile Weist dem Benutzer ein Profil zu. Ist keines angegeben, wird das

Standardprofil verwendet. Profile werden zur Einschränkung der

Nutzung von Systemressourcen und zur Erzwingung von

Verwaltungsregeln für Passwörter eingesetzt.

Default Role[s] Aktiviert für den Benutzer die Standardrollen.


Der Benutzer THUMPER kann jetzt im Tablespace USERS Segmente bis zu einer Grö-ße von insgesamt 100MB anlegen.

Hinweis:Um bei Abfragen im Tablespace TEMP temporäre Segmente anlegen zu können, benötigen die Benutzer keine Speicherplatzkontingente.

Außer dem Benutzernamen lassen sich alle Parameter im create user-Befehl mit alteruser ändern.

Im OEM Security Manager können Sie einen neuen Benutzer anlegen. Dieser neueBenutzer kann auch die Attribute eines bestehenden Benutzers übernehmen. Abbil-dung 9-1 zeigt den Eingangsbildschirm des Security Managers, in dem der BenutzerTHUMPER ausgewählt ist. Mit dem OEM-Tool lassen sich beim Anlegen des Benut-zers Rollen, Systemberechtigungen, Objektberechtigungen und Speicherplatzkontin-gente zuweisen.

Im Bildschirm in Abbildung 9-1 weist man dem Benutzer ein bestimmtes Passwort zuund legt fest, ob der Account global – also auch für die Verwaltung von Ferndatenban-ken – oder extern identifiziert ist. Ausführungen zu weiteren Optionen finden Sie un-ter der Überschrift „Passwortmanagement“.

Abbildung 9-1: Passwort-Authentisierung.


Einen neuen Benutzer legen Sie über die Auswahl der Registerkarte General und dasKlicken der rechten Maustaste an. Alternativ wählen Sie auf der linken Seite den BereichUsers aus und selektieren aus dem Object-Menü die Option „Create“. Wenn Sie dieOption „Create“ oder Create Like“ wählen, wird ein Assistent gestartet, wo Sie die Rol-len, Berechtigungen etc. des neuen Benutzers eintragen. Standardmäßig wird dem neu-en Benutzer die CONNECT-Rolle zugewiesen. Als Standard-Tablespace und temporä-rer Tablespace ist jeweils der SYSTEM-Tablespace eingetragen. Abbildung 9-2 zeigt dasFenster „Create User“ mit den verfügbaren Optionen, wenn man einen Benutzer mitdenselben Attributen wie denen des Benutzers THUMPER anlegen möchte. Da demBenutzer THUMPER als Standard-Tablespace USERS und als temporärer TablespaceTEMP zugewiesen wurde, besitzt der neue Benutzer die gleichen Zuweisungen undauch alle anderen Berechtigungen, die für THUMPER gelten. Als zusätzliche Informa-tionen sind nur der Benutzername und das Passwort des neuen Benutzers sowie alleAngaben einzutragen, die von den Einstellungen von THUMPER abweichen.

Abbildung 9-2: Das Fenster Create User mit der Registerkarte General.

9.2.3 Benutzer löschen

Über den drop user-Befehl kann ein Benutzer aus der Datenbank gelöscht werden.Dieser Befehl hat nur einen Parameter, cascade, der vor dem Löschen des Benutzersalle dazugehörigen Objekte im Schema entfernt. Gehören dem Benutzer irgendwelcheObjekte, muss man zum Löschen dieses Benutzers die cascade-Option einsetzen:


drop user THUMPER cascade;

Alle Views, Synonyme, Prozeduren, Funktionen oder Packages, die Objekte im Schemades gelöschten Benutzers referenzierten, werden als INVALID markiert. Sollte zu einemspäteren Zeitpunkt ein Benutzer mit dem gleichen Namen angelegt werden, erbt er vondem früheren Benutzer gleichen Namens nichts. Der OEM bietet im Security Managereine Funktion namens remove, mit der Sie einen Benutzer löschen können. Ein Bestä-tigungsbildschirm stellt sicher, dass der ausgewählte Benutzer tatsächlich gelöscht wer-den soll.

9.2.4 Berechtigungen auf Systemebene

Zur Verteilung der Verfügbarkeit von Systembefehlen können Sie Systemebenenrol-len einsetzen, mit denen die Datenbank verwaltet wird. Entweder legen Sie spezifischeSystemebenenrollen an oder nutzen das Standardangebot der Datenbank. Die verfüg-baren Berechtigungen, die über Systemebenenrollen gewährt werden können, findensich in Anhang A unter dem Eintrag „GRANT“ (Systemberechtigungen und Rollen).

Über die Klausel with grant option des grant-Befehls erhält der Berechtigungsempfän-ger das Recht, die zugewiesene Berechtigung an andere Benutzer weiterzugeben.

Tabelle 9-2 führt alle 11 Rollen auf Systemebene auf, die bei ORACLE verfügbar sind.Mithilfe dieser Rollen können Sie die Berechtigungen einschränken, die den Daten-bankverwaltungsrollen zugewiesen werden. Zusätzlich zu den Rollen in Tabelle 9-2kann Ihre Datenbank weitere Rollen enthalten, die zur Unterstützung der AdvancedQueuing Option (AQ_USER_ROLE und AQ_ADMINISTRATOR_ROLE) und für dieOEM Intelligent Agents (die Rolle SNMPAGENT) eingerichtet wurden.

Hinweis:Zusätzlich zu den in Tabelle 9-2 aufgeführten Berechtigungen erhalten die Benutzer der Rollen DBA und RESOURCE die Systemberechtigung UNLIMITED TABLESPACE.

Tabelle 9-2: Rollen auf Systemebene, die ORACLE8i zur Verfügung stellt.

Rollenname Gewährte Berechtigungen

CONNECT ALTER SESSION, CREATE CLUSTER, CREATE

DATABASE LINK, CREATE SEQUENCE, CREATE

SESSION, CREATE SYNONYM, CREATE TABLE,

CREATE VIEW

RESOURCE CREATE CLUSTER, CREATE PROCEDURE, CREATE

SEQUENCE, CREATE TABLE, CREATE TRIGGER


Die CONNECT-Rolle wird üblicherweise dem Endbenutzer erteilt. Obwohl man mitdieser Rolle Objekte anlegen kann (inklusive der CREATE TABLE-Berechtigung), er-wirbt der Benutzer damit kein Speicherkontingent für irgendeinen Tablespace. Da derBenutzer solange keine Tablespace-Kontingente besitzt, bis sie ihm zugewiesen wer-den, kann er keine Tabellen anlegen.

Die RESOURCE-Rolle wird den Entwicklern zugewiesen. Wie in Kapitel 5 beschrie-ben, erteilt die RESOURCE-Rolle den Entwicklern die üblichen Berechtigungen, dieim Zusammenhang mit der Anwendungsentwicklung benötigt werden.

Die DBA-Rolle umfasst alle Systemebenenberechtigungen, mit der Option, diese anandere Benutzer weiterzugeben.

Die Rollen IMP_FULL_DATABASE und EX_FULL_DATABASE werden bei einemvollständigen Import oder Export der Datenbank eingesetzt (siehe Kapitel 10). DieseRollen gehören zur DBA-Rolle; mit dieser Rolle können Sie Benutzern eingeschränkteDatenbankmanagement-Berechtigungen erteilen.

Die SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE und DELETE_CATALOG_ROLE sind seit ORACLE8 neu.

DBA Alle Systemberechtigungen WITH ADMIN OPTION

EXP_FULL_DATABASE SELECT ANY TABLE, BACKUP ANY TABLE, INSERT,

DELETE, AND UPDATE ON THE TABLES SYS.INCVID,

SYS.INCFIL, und SYS.INCEXP

IMP_FULL_DATABASE BECOME USER

DELETE_CATALOG_ROLE DELETE-Berechtigung auf alle Dictionary-Packages

EXECUTE_CATALOG_ROLE EXECUTE-Berechtigung auf alle Dictionary-Packages

SELECT_CATALOG_ROLE SELECT-Berechtigung auf alle Katalogtabellen und Views

CREATE TYPE CREATE TYPE, EXECUTE, EXECUTE ANY TYPE,

ADMIN OPTION, GRANT OPTION

RECOVERY_CATALOG_OWNER DROP ROLE RECOVERY_CATALOG_OWNER,

CREATE ROLE RECOVERY_CATALOG_OWNER,

CREATE TRIGGER, CREATE PROCEDURE TO

RECOVERY_CATALOG_OWNER

HS_ADMIN_ROLE HS_EXTERNAL_OBJECT, HS_EXTERNAL_USER

Tabelle 9-2: Rollen auf Systemebene, die ORACLE8i zur Verfügung stellt. (Fortsetzung)

Rollenname Gewährte Berechtigungen


Die einfachere dieser drei Rollen ist DELETE_CATALOG_ROLE. Gewähren Sie ei-nem Benutzer DELETE_CATALOG_ROLE, kann er Datensätze aus der TabelleSYS.AUD$ löschen. In diese Tabelle werden die Audit-Datensätze geschrieben. Überdie Zuweisung dieser Rolle geben Sie dem Benutzer die Möglichkeit, Datensätze ausder Audit-Tabelle zu löschen, ohne ihm damit andere DBA-Berechtigungen zu ertei-len. Mit diesen Rollen soll die Verwaltung der Prüfprotokolle vereinfacht werden.

Die Rollen EXECUTE_CATALOG_ROLE und SELECT_CATALOG_ROLE erteilenBenutzerberechtigungen zur Auswahl oder Ausführung von exportierbaren Data Dic-tionary-Objekten. Das bedeutet, dass bei einem vollständigen Export nicht jedes Daten-bankobjekt exportiert wird (siehe Kapitel 10). Ein Beispiel sind die dynamischenPerformance-Views (siehe Kapitel 6). Damit gibt SELECT_CATALOG_ROLE dem Be-nutzer nicht die Möglichkeit, Daten aus den dynamischen Performance-Tabellen aus-zuwählen; der Benutzer kann jedoch den größten Teil des Data Dictionarys abfragen.Ganz ähnlich erteilt EXECUTE_CATALOG_ROLE dem Benutzer die Berechtigung zurAusführung von Prozeduren und Funktionen, die zum Data Dictionary gehören.

Wenn Sie in ORACLE8 die Objects Option nutzen, ist die Rolle CREATE TYPE akti-viert. Benutzer, bei den diese Rolle aktiviert ist, können neue abstrakte Datentypenanlegen.

Angesichts der verfügbaren Berechtigungen und Rollen möchten Sie vielleicht denProzess zum Anlegen der Accounts überprüfen. Wie bei der Datenbanksicherung wer-den zum Anlegen eines Accounts DBA-Berechtigungen benötigt. Zur Einrichtung vonBenutzern können Sie jedoch eine Untermenge der verfügbaren Berechtigungen aus-wählen.

So kann man beispielsweise eine neue Systemebenenrolle namens

ACCOUNT_CREATOR einrichten, mit der man ausschließlich Benutzer anlegenkann. Die Befehle zur Einrichtung dieser Rolle sehen wie folgt aus:

create role ACCOUNT_CREATOR;grant CREATE SESSION, CREATE USER, ALTER USER to ACCOUNT_CREATOR;

Der erste Befehl in diesem Listing legt eine Rolle namens ACCOUNT_CREATOR an.Der zweite Befehl erteilt der Rolle die Fähigkeit zur Anmeldung (CREATE_SESSION),zum Anlegen und Ändern von Accounts (CREATE_USER und ALTER_USER). DieACCOUNT_CREATOR-Rolle kann dann dem zentralen Helpdesk erteilt werden, dasdie Koordination bei der Einrichtung neuer Benutzer übernimmt. Im OEM wählen Siezum Anlegen dieser Rolle die Option Create Role und tragen die entsprechenden In-formationen ein. Abbildung 9-3 zeigt die Rolle ACCOUNT_CREATOR, die über denOEM Security Manager angelegt wurde, während Sie in Abbildung 9-4 die Zuweisungder Berechtigungen für diese Rolle finden.


Abbildung 9-3: Einrichten der Rolle Account Creator.

Abbildung 9-4: Zuweisung der Systemberechtigungen für die Rolle Account Creator.

Diese Zentralisierung hilft sicherzustellen, dass bei der Anforderung von Accounts dierichtigen Autorisierungsprozeduren ausgeführt werden. Die Flexibilität der Berechti-gungen und Rollen auf Systemebene ermöglichen einerseits, diese Arbeiten einem Be-nutzer – in diesem Fall einem Helpdesk – zu übergeben, und stellen gleichzeitig sicher,dass dieser Benutzer keine Daten in der Datenbank abfragen kann.


Das Anlegen einer ACCOUNT_CREATOR-Rolle ist insbesondere bei der Einrichtungvon Softwarepaketen nützlich. Viele Anwendungen von Fremdherstellern gehen ein-fach davon aus, dass sie in Ihrer Datenbank die vollen DBA-Berechtigungen besitzen:tatsächlich führen die Programme aber lediglich die create user- und alter user-Befeh-le aus. Über eine ACCOUNT_CREATOR-Rolle können Sie die Benutzerberechtigun-gen des Paketschemas in der übrigen Datenbank einschränken.

Die Standardrolle für einen Benutzer ändern Sie über die default role-Klausel des alteruser-Befehls. Sie können einen Benutzer beispielsweise so ändern, dass er standardmä-ßig keine Rolle besitzt:

alter user THUMPER default role NONE;

Zur Aktivierung der Rollen verwenden Sie folgenden Befehl:

alter user THUMPER default role CONNECT;

Und Sie können die Rollen angeben, die beim Start der Sitzung nicht aktiviert sein soll-ten:

alter user THUMPER default role all except ACCOUNT_CREATOR;

Wurde dem Benutzer die angegebene Rolle nicht gewährt, scheitert alter user. Besitztder Benutzer keine Rolle auf Systemebene wie CONNECT, führt der Versuch, dieseRolle als Standardrolle des Benutzer zu setzen, zu folgender Fehlermeldung:

ORA-01919: role ’CONNECT’ does not exist

Handelt es sich bei der angegebenen Rolle um eine datenbankspezifische Rolle, diedem Benutzer nicht zugewiesen wurde, scheitert der alter user-Befehl mit folgenderFehlermeldung:

ORA-01955: DEFAULT ROLE ’ACCOUNT_CREATOR’ not granted to user

Bevor Sie die Standardrollen der Benutzer einrichten können, müssen sie ihnen zuge-wiesen sein.

Bei Verwendung der default role all-Klausel werden alle Rollen des Benutzers beimStart der Sitzung aktiviert. Wenn Sie planen, die Rollen in verschiedenen Teilen derAnwendung dynamisch zu aktivieren und zu deaktivieren (über die set role-Befehle),sollten Sie prüfen, welche dieser Rollen standardmäßig aktiviert sind.

Hinweis:Der init.ora-Parameter MAX_ENABLED_ROLES beschränkt die Anzahl der Rollen, die ein Benutzer gleichzeitig aktiviert haben kann. Der Standardwert ist 20.


Hinweis:Wenn Sie eine Rolle einrichten, ist sie standardmäßig aktiviert. Legen Sie mehrere Rollen an, kann der Wert für MAX_ENABLED_ROLES überschritten werden, selbst wenn Sie nicht der Benutzer dieser Rollen sind.

9.2.5 Benutzerprofile

Über Profile können Sie Beschränkungen hinsichtlich der Menge der System- und Da-tenbankressourcen für einen Benutzer einrichten und die Passwortbeschränkungenverwalten. Sind in einer Datenbank keine Rollen angelegt, wird das Standardprofil ver-wendet, das für alle Benutzer uneingeschränkte Ressourcen vorgibt.

Die Ressourcen lassen sich über die Profile in Tabelle 9-3 beschränken.

Hinweis:PASSWORD_REUSE_MAX und PASSWORD_REUSE_TIME schließen sich gegenseitig aus. Falls eine dieser Ressourcen auf einen Wert gesetzt ist, muss die andere auf UNLIMITED gesetzt sein.

Tabelle 9-3: Über Profile eingeschränkte Ressourcen.

Ressource Beschreibung

SESSIONS_PER_USER Die Anzahl gleichzeitiger Sitzungen, die ein Benutzer in

einer Instanz haben kann.

CPU_PER_SESSION Die CPU-Zeit, in Hundertstelsekunden, die eine

Sitzung nutzen kann.

CPU_PER_CALL Die CPU-Zeit, in Hundertstelsekunden, die ein parse,

execute oder fetch nutzen kann.

CONNECT_TIME Die Anzahl Minuten, die eine Sitzung mit einer

Datenbank verbunden sein kann.

IDLE_TIME Die Anzahl Minuten, die eine Sitzung im Leerlauf mit

einer Datenbank verbunden sein kann.

LOGICAL_READS_PER_SESSION Die Anzahl Datenblöcke, die während einer Sitzung

gelesen werden können.

LOGICAL_READS_PER_CALL Die Anzahl Datenblöcke, die bei einem parse, execute

oder fetch gelesen werden können.


Wie in Tabelle 9-3 zu sehen ist, lassen sich die Ressourcen einschränken. Alle diese Re-striktionen sind jedoch reaktiv: es wird keine Aktion ausgeführt, bis der Benutzer be-stimmte Ressourcengrenzen überschritten hat. Deshalb bieten die Profile keine großeHilfe, wenn es darum geht, außer Kontrolle geratene Abfragen von der Nutzung um-fangreicher Ressourcen abzuhalten, bevor ein bestimmter Grenzwert erreicht ist. Istdie Schwelle erreicht, wird die SQL-Anweisung gestoppt.

Profile werden über den create profile-Befehl angelegt (siehe folgendes Listing). Deralter profile-Befehl wird in diesem Beispiel zur Änderung bestehender Profile genutzt.Das DEFAULT-Profil für die Datenbank wird so geändert, dass die maximale Leer-laufzeit auf eine Stunde gesetzt wird:

alter profile DEFAULTidle_time 60;

PRIVATE_SGA Der private Speicherplatz, der im gemeinsamen Pool

der SGA zugewiesen werden kann.

COMPOSITE_LIMIT Ein zusammengesetztes Limit, basierend auf den

vorhergehenden Limits.

FAILED_LOGIN_ATTEMPTS Die Anzahl aufeinander folgender fehlerhafter Logins,

die zur Sperrung eines Accounts führen.

PASSWORD_LIFE_TIME Die Anzahl Tage, die ein Passwort vor dem Verfall

genutzt werden kann.

PASSWORD_REUSE_TIME Die Anzahl Tage, die vergehen müssen, bevor ein

Passwort erneut verwendet werden kann.

PASSWORD_REUSE_MAX Wie häufig ein Passwort geändert werden muss, bis ein

Passwort erneut verwendet werden kann.

PASSWORD_LOCK_TIME Die Anzahl Tage, die ein Account gesperrt bleibt, wenn

die Einstellung FAILED_LOGIN_ATTEMPTS

überschritten ist.

PASSWORD_GRACE_TIME Die Länge der „Gnadenfrist“ in Tagen, in der ein

Passwort noch geändert werden kann, nachdem es die

Einstellung PASSWORD_LIFE_TIME erreicht hat.

PASSWORD_VERIFY_FUNCTION Der Name einer Funktion zur Beurteilung der

Komplexität eines Passworts; die von ORACLE

angebotene Funktion kann bearbeitet werden.

Tabelle 9-3: Über Profile eingeschränkte Ressourcen. (Fortsetzung)

Ressource Beschreibung


Der OEM Security Manager bietet eine grafische Schnittstelle zur Einrichtung undVerwaltung von Profilen. Abbildung 9-5 zeigt den Standardbildschirm für Profile mitden Ressourcen, die für das Profil reserviert wurden.

Abbildung 9-5: Einstellungen für ein Standardprofil.

Profile werden in erster Linie zur Verwaltung der Lebensdauer von Passwörtern ein-gesetzt.

9.2.6 Passwortmanagement

Seit ORACLE8 können Sie für den Verfall, die Wiederverwendung und die Komplexi-tät der Passwörter Profile einsetzen. Man kann beispielsweise die Gültigkeitsdauer ei-nes Passworts einschränken und einen Account sperren, dessen Passwort zu alt ist.Zudem lässt sich erzwingen, dass ein Passwort zumindest einigermaßen komplex ist,und jeder Account gesperrt wird, bei dem eine bestimmte Anzahl von Anmeldeversu-chen erfolglos war.

Wenn Sie die FAILED_LOGIN_ATTEMPTS-Ressource des Benutzerprofils beispiels-weise auf 5 setzen, kann man bei diesem Account fünf aufeinander folgende erfolgloseAnmeldungsversuche ausführen; beim sechsten Versuch wird der Account gesperrt.


Hinweis:Wird beim fünften Versuch das richtige Passwort angegeben, wird der Zähler „failed login attempt count“ auf 0 zurückgesetzt. Vor dem Sperren des Accounts sind damit weitere fünf Fehlversuche möglich.

Im folgenden Listing wird für den Benutzer JANE die LIMITED_PROFILE-Ressourceeingerichtet:

create profile LIMITED_PROFILE limitFAILED_LOGIN_ATTEMPTS 5;

create user JANE identified by EYREprofile LIMITED_PROFILE;

grant CREATE SESSION to JANE;

Falls sich beim Account JANE jemand sechsmal hintereinander vergeblich anmeldet,wird der Account von ORACLE automatisch gesperrt. Wenn Sie danach das korrektePasswort verwenden, erhalten Sie folgende Fehlermeldung:

connect jane/eyreERROR: ORA-28000: the account is locked

Um den Account wieder freizugeben, nutzen Sie die account unlock-Klausel des alteruser-Befehls (von einem DBA-Account):

alter user JANE account unlock;

Nach Freigabe des Accounts sind wieder Verbindungen zum Account JANE möglich.Eine manuelle Sperrung eines Accounts erfolgt über die account lock-Klausel des alteruser-Befehls:

alter user JANE account lock;

Falls ein Account wegen wiederholter Verbindungsfehler gesperrt ist, wird er automa-tisch freigegeben, wenn der PASSWORD_LOCK_TIME-Wert des Profils überschrit-ten ist. Wenn PASSWORD_LOCK_TIME beispielsweise auf 1 gesetzt ist, wird derAccount JANE aus dem vorigen Beispiel für einen Tag gesperrt und danach wiederfreigegeben.

Über PASSWORD_LIFE_TIME richten Sie für ein Passwort in Profilen eine maximaleLebensdauer ein. So könnten Sie die Benutzer des Profils LIMITED_PROFILE zwin-gen, ihre Passwörter alle 30 Tage zu ändern:

alter profile LIMITED_PROFILE limitPASSWORD_LIFE_TIME 30;


In diesem Beispiel wird mit dem alter profile-Befehl das Profil LIMITED_PROFILEgeändert. Der PASSWORD_LIFE_TIME-Wert ist auf 30 gesetzt, sodass bei jedem Ac-count mit diesem Profil das Passwort nach 30 Tagen abläuft. Wenn Ihr Passwort ab-gelaufen ist, müssen Sie es bei der nächsten Anmeldung ändern. Eine Ausnahme istnur dann gegeben, wenn in Ihrem Profil eine Gnadenfrist für abgelaufene Passwörterhinterlegt ist. Der dazugehörige Parameter heißt PASSWORD_GRACE_TIME. Wirddas Passwort nicht innerhalb dieser Frist geändert, erlischt der Account.

Hinweis:Setzen Sie den Parameter PASSWORD_LIFE_TIME ein, müssen Sie den Benutzern eine einfache Möglichkeit zur Änderung des Passworts anbieten.

Ein „abgelaufener“ unterscheidet sich von einem „gesperrten“ Account. Ein gesperrterAccount wird, wie weiter oben ausgeführt, nach Ablauf eines bestimmten Zeitraumswieder freigegeben. Bei einem abgelaufenen Account muss der DBA eingreifen undden Account wieder aktivieren.

Zur Reaktivierung eines abgelaufenen Accounts führen Sie den alter user-Befehl aus.Im folgenden Beispiel wird das Passwort des Benutzers JANE manuell auf „ungültig“gesetzt:

alter user jane password expire;

User altered.

Danach möchte JANE eine Verbindung zu ihrem Account aufbauen. Bei der Angabeihres Passworts wird sie unmittelbar zur Eingabe eines neuen Passworts aufgefordert:

connect jane/eyreERROR: ORA-28001: the account has expired

Changing password for janeOld password:New password:Retype new password:Password changedConnected.SQL>

Über die password expire-Klausel des create user-Befehls können Sie jeden Benutzerzwingen, beim ersten Zugang zum Account das Passwort zu ändern. Der create user-Befehl erlaubt jedoch nicht das Setzen eins Ablaufdatums für das neue Benutzerpass-wort: dazu müssen Sie die Profilparameter von PASSWORD_LIFE_TIME im vorigenBeispiel verwenden.


Zur Ansicht des Ablaufdatums für alle Accounts fragen Sie die Expiry_Date-Spalte derData Dictionary-View DBA_USERS ab. Die Anwender können an der gleichen Stelledie Information für ihre jeweiligen Accounts über die Expiry_Date-Spalte der DataDictionary-View USERS_USERS abfragen (entweder über SQL*PLus oder ein client-basiertes Abfragewerkzeug).

9.2.7 Die Wiederverwendung des Passworts verhindern

Um die Wiederverwendung eines Passworts zu verhindern, setzen Sie einen der beidenfolgenden Profilparameter ein: PASSWORD_REUSE_MAX oder PASSWORD_REUSE_TIME. Diese beiden Parameter schließen sich gegenseitig aus;wenn Sie für einen der beiden Parameter einen Wert setzen, muss der andere auf UN-LIMITED gesetzt sein.

Der Parameter PASSWORD_REUSE_TIME gibt die Anzahl der Tage an, die vor derWiederverwendung eines Passworts vergehen müssen. Setzen Sie PASSWORD_REUSE_TIME beispielsweise auf 60, kann das Passwort innerhalb die-ser Frist nicht benutzt werden.

Der Parameter PASSWORD_REUSE_MAX gibt an, wie oft das Passwort geändertwerden muss, bevor ein bestimmtes Passwort erneut verwendet werden darf. WennSie versuchen, das Passwort vor dem Erreichen der gesetzten Frist zu nutzen, wird die-ser Versuch von ORACLE zurückgewiesen.

Sie können beispielsweise PASSWORD_REUSE_MAX für das weiter oben angelegteLIMITED_PROFILE wie folgt setzen:

alter profile LIMITED_PROFILE limitPASSWORD_REUSE_MAX 3PASSWORD_REUSE_TIME UNLIMITED;

Wenn die Anwenderin JANE jetzt versucht, das letzte Passwort erneut einzugeben,scheitert sie. Nehmen wir an, die Benutzerin ändert das Passwort:

alter user JANE identified by austen;

Danach ändert sie es erneut:

alter user JANE identified by eyre;

Bei der nächsten Passwortänderung versucht sie, das vorige Passwort einzugeben:

alter user jane identified by austen;alter user jane identified by austen*ERROR at line 1:ORA-28007: the password cannot be reused


Da dieser Versuch zurückgewiesen wird, muss sie ein anderes Passwort eingeben.

Die Passwort-Historien sind in der Tabelle USER_HISTORY$ unter dem SYS-Schemagespeichert. In dieser Tabelle speichert ORACLE die Benutzerkennung, den verschlüs-selten Passwortwert und den Datum/Zeitstempel für die Einrichtung des Passworts.Wenn der PASSWORD_REUSE_TIME-Wert überschritten oder die Anzahl der Än-derungen PASSWORD_REUSE_MAX übertrifft, werden die alten Passwort-Daten-sätze aus USER_HISTORY$ gelöscht. Stimmt die neue Verschlüsselung mit einer altenüberein, wird das neue Passwort zurückgewiesen.

Weil die alten Passwörter in einer Tabelle gespeichert sind, die SYS gehört, werden dieDaten im SYSTEM-Tablespace hinterlegt. Falls Sie für viele Benutzer, die ihre Pass-wörter häufig ändern, Passwort-Historien über einen längeren Zeitraum speichernmöchten, wirken sich die Speicherplatzanforderungen dieser Tabelle unter Umstän-den auf den Platzbedarf des SYSTEM-Tablespace aus.

9.2.8 Vorgabe der Komplexität für ein Passwort

Die Komplexität des Passworts kann zur Erfüllung bestimmter Standards gezwungenwerden. Sie können beispielsweise verlangen, dass die Passwörter eine Mindestlängehaben, keine einfachen Wörter sind und mindestens eine Zahl oder ein Satzzeichenbeinhalten. Der Parameter PASSWORD_VERIFY_FUNCTION der create profile-und alter profile-Befehle legen den Namen der Funktion fest, die das Passwort prüfenwird. Erfüllt ein Benutzerpasswort die gesetzten Kriterien nicht, wird es abgelehnt.

Zur Vereinfachung dieses Prozesses bietet ORACLE eine Funktion namensVERIFY_FUNCTION an, die standardmäßig nicht angelegt wird. Das geschieht nur,wenn Sie das Skript utlpwdmg.sql im Verzeichnis /rdbms/admin unter dem ORACLEHome-Verzeichnis ausführen. Im folgenden Listing finden Sie eine gekürzte Versiondieses Skripts. Die fett gedruckten Elemente werden in den nachfolgenden Abschnit-ten besprochen:

Rem utlpwdmg.sqlRemRem Copyright (c) Oracle Corporation 1996. All Rights Reserved.RemRem NAMERem utlpwdmg.sql - script for Default Password Resource LimitsRemRem DESCRIPTIONRem This is a script for enabling the password management featuresRem by setting the default password resource limits.Rem


Rem NOTESRem This file contains a function for minimum checking of passwordRem complexity. This is more of a sample function that the customerRem can use to develop the function for actual complexity checksRem that the customer wants to make on the new password.RemRem asurpur 12/12/96 - Changing the name ofRem password_verify_function-- This script sets the default password resource parameters-- This script needs to be run to enable the password features.-- However the default resource parameters can be changed based-- on the need.-- A default password complexity function is also provided.-- This function makes the minimum complexity checks like-- the minimum length of the password, password not same as the-- username, etc. The user may enhance this function according to-- the need.-- This function must be created in SYS schema.-- connect sys/<password> as sysdba before running the script

CREATE OR REPLACE FUNCTION verify_function(username varchar2, password varchar2, old_password varchar2) RETURN boolean IS n boolean; m integer; differ integer; isdigit boolean; ischar boolean; ispunct boolean; digitarray varchar2(20); punctarray varchar2(25); chararray varchar2(52);

BEGIN digitarray:= ’0123456789’; chararray:= ’abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ’; punctarray:=’!"#$%&()’’*+,-/:;<>?_’;

-- Check if the password is same as the username IF password = username THEN raise_application_error(-20001, ’Password same as user’); END IF;

-- Check for the minimum length of the password IF length(password) < 4 THEN raise_application_error(-20002, ’Password length less than 4’); END IF;


-- Check if the password is too simple. A dictionary of words may be -- maintained and a check may be made so as not to allow the words -- that are too simple for the password. IF password IN (’welcome’, ’password’, ’oracle’, ’computer’, ’abcd’) THEN raise_application_error(-20002, ’Password too simple’); END IF; -- Check if the password contains at least one letter, one digit -- and one punctuation mark. -- 1. Check for the digit isdigit:=FALSE; m := length(password); FOR i IN 1..10 LOOP FOR j IN 1..m LOOP IF substr(password,j,1) = substr(digitarray,i,1) THEN isdigit:=TRUE; GOTO findchar; END IF; END LOOP; END LOOP; IF isdigit = FALSE THEN raise_application_error(-20003, ’Password should contain atleast one digit, one character and one punctuation’); END IF; -- 2. Check for the character <<findchar>> ischar:=FALSE; FOR i IN 1..length(chararray) LOOP FOR j IN 1..m LOOP IF substr(password,j,1) = substr(chararray,i,1) THEN ischar:=TRUE;

GOTO findpunct; END IF; END LOOP; END LOOP; IF ischar = FALSE THEN raise_application_error(-20003, ’Password should contain at least one \ digit, one character and one punctuation’); END IF; -- 3. Check for the punctuation <<findpunct>> ispunct:=FALSE; FOR i IN 1..length(punctarray) LOOP FOR j IN 1..m LOOP IF substr(password,j,1) = substr(punctarray,i,1) THEN ispunct:=TRUE; GOTO endsearch;


END IF; END LOOP; END LOOP; IF ispunct = FALSE THEN raise_application_error(-20003, ’Password should contain at least \ one digit, one character and one punctuation’); END IF;

<<endsearch>> -- Check if the password differs from the previous password by at -- least 3 letters IF old_password = ’’ THEN raise_application_error(-20004, ’Old password is null’); END IF; -- Everything is fine; return TRUE ; RETURN(TRUE); differ := length(old_password) - length(password);

IF abs(differ) < 3 THEN IF length(password) < length(old_password) THEN m := length(password); ELSE m := length(old_password); END IF; differ := abs(differ); FOR i IN 1..m LOOP IF substr(password,i,1) != substr(old_password,i,1) THEN differ := differ + 1; END IF;

END LOOP; IF differ < 3 THEN raise_application_error(-20004, ’Password should differ by at \ least 3 characters’); END IF; END IF; -- Everything is fine; return TRUE ; RETURN(TRUE);END;/

-- This script alters the default parameters for Password Management

-- This means that all the users on the system have Password Management

-- enabled and set to the following values unless another profile is

-- created with parameter values set to different value or UNLIMITED

-- is created and assigned to the user.


ALTER PROFILE DEFAULT LIMITPASSWORD_LIFE_TIME 60PASSWORD_GRACE_TIME 10PASSWORD_REUSE_TIME 1800PASSWORD_REUSE_MAX UNLIMITEDFAILED_LOGIN_ATTEMPTS 3PASSWORD_LOCK_TIME 1/1440PASSWORD_VERIFY_FUNCTION verify_function;

Hinweis:Diese Funktion sollte nicht unter dem SYS-Schema angelegt werden.

Die drei ersten if-Klauseln in der Funktion prüfen, ob das Passwort und der Benutzer-name identisch sind und ob das Passwort mit einer Reihe vorgegebener Wörter über-einstimmt. Sie können jede Prüfung ändern oder eigene einfügen. So können Ihreunternehmensinternen Richtlinien für das Passwort eine Mindestlänge von sechs Zei-chen vorgeben: ändern Sie vor der Ausführung des Skripts einfach die betreffende Stel-le.

Der nächste größere Abschnitt der Funktion ist eine dreiteilige Überprüfung der Pass-wort-Zeichenkette. Um diesen Test zu bestehen, muss das Passwort mindestens einenBuchstaben, eine Zahl und ein Satzzeichen enthalten. Auch dieser Test kann bearbeitetwerden. Falls Sie beispielsweise von den Benutzern nicht die Verwendung von Satzzei-chen verlangen, umgehen Sie einfach diesen Teil der Passwortprüfung.

Der folgende Abschnitt der Funktion vergleicht zeichenweise das alte mit dem neuenPasswort. Lassen sich nicht mindestens drei Unterschiede feststellen, wird das neuePasswort zurückgewiesen.

Der letzte Befehl in diesem Skript gehört nicht zur Funktion; es ist ein alter profile-Be-fehl, der das DEFAULT-Profil ändert. Von der Änderung dieses Profils ist jeder Benut-zer betroffen, der mit diesem Profil arbeitet. Der im Listing aufgeführte Befehl setztfolgende Grenzwerte: die Lebensdauer des Passworts beträgt 60 Tage mit einer „Gna-denfrist“ von 10 Tagen; keine Wiederverwendung des Passworts für 1800 Tage; Sper-rung des Passworts nach drei fehlerhaften Anmeldungsversuchen und automatischeFreigabe des Accounts nach einer Minute (1/1.440 eines Tages). Diese Einstellungenmüssen nicht die von Ihnen gewünschten Werte wiedergeben. Die letzte Einstellungist die wichtigste – sie legt fest, dass VERIFY_FUNCTION, die über das Skript utlp-wdmg.sql angelegt wurde, als PASSWORD_VERIFY_FUNCTION zu verwenden ist.


Hinweis:Diese Funktion wird nur auf die Benutzer des angegebenen Profils angewendet.

Beachten Sie, dass die VERIFY_FUNCTION keine Datenbankzugriffe ausführt undkeine Datenbankwerte aktualisiert. Bei einer Änderung der Funktion sollten Sie si-cherstellen, dass Ihre Änderungen keine Datenbankzugriffe oder -modifizierungen er-fordern.

Sie können das Standardprofil so ändern, dass die VERIFY_FUNCTION verwendetwird, ohne die Parameter für den Verfall des Passworts zu modifizieren:

alter profile DEFAULT limitPASSWORD_VERIFY_FUNCTION VERIFY_FUNCTION;

Bei einer Änderung des DEFAULT-Profils müssen Sie sicherstellen, dass diese Modi-fikationen bei allen Benutzern des Profils einsetzbar sind. So nutzen beispielsweise dieSYS- und SYSTEM-Anwender DEFAULT; können Sie deren Passwörter anhand derhier vorgenommenen Einstellungen verwalten? Zur Vereinfachung der Profilverwal-tung kann es sinnvoll sein, eine neue Rolle anzulegen, die allen Nicht-DBA- undNicht-Anwendungsbenutzern zugewiesen wird. Das Problem bei diesem Ansatz ist,dass Sie nicht vergessen dürfen, das Profil allen neuen Benutzern zuzuweisen.

Der Name der Funktion zur Passwortprüfung darf nicht VERIFY_FUNCTION lauten.Wie im letzten Listing gezeigt, übergeben Sie den Namen der Funktion als Parameteran den alter profile-Befehl. Da der Name VERIFY_FUNCTION für beinahe jedeFunktion vergeben werden kann, sollten Sie einen sinnvollen Namen vergeben: einBeispiel ist VERIFY_ORACLE_PASSWORD. Der Name sollte selbstbeschreibend undleicht zu merken sein; damit steigt die Wahrscheinlichkeit, dass andere DBAs dieFunktion dieses Programms nachvollziehen können.

Der OEM Security Manager ermöglicht das Anlegen von Profilen. Mit diesem Werk-zeug können Sie sehr einfach sowohl die Grenzen der profilgesteuerten als auch derPasswortressourcen definieren. Abbildung 9-6 zeigt die Einstellungen für das allge-meine Profil und Abbildung 9-7 den Bildschirm für die Passwortwerte.

Zusätzliche Managementoptionen für Passwörter finden sich im weiteren Verlauf die-ses Kapitels unter der Überschrift „Passwortverschüsselung und Kniffe“.


Abbildung 9-6: Allgemeine Einstellungen für LIMITED_PROFILE.

Abbildung 9-7: Passworteinstellungen für LIMITED_PROFILE.

9.2.9 Datenbank- und Host-Accounts verbinden

Geben die Benutzer eine gültige Benutzerkennung und ein gültiges Passwort ein, ha-ben sie die Berechtigung für den Zugang zur Datenbank. Dennoch kann man die Vor-teile des Betriebssystems nutzen und für die Benutzerbeglaubigung eine zusätzlicheEbene einrichten.


Ein Datenbank-Account kann mit einem Betriebssystem-Account auf dem gleichenServer gepaart sein. Die beiden Account-Namen unterscheiden sich nur durch das Prä-fix des Datenbank-Account-Namens, der standardmäßig OPS$ ist, sich aber über denParameter OS_AUTHENT_PREFIX ändern lässt. Dieses Präfix kann auch auf eineNULL-Zeichenkette gesetzt werden, sodass kein Präfix zum Einsatz kommt.

Hinweis:Wenn Sie OS_AUTHENT_PREFIX auf einen anderen Wert als OPS$ setzen, können die Datenbank-Accounts entweder als Autologin-Accounts oder über Benutzername/Passwort zugänglich sein (aber nicht über beides). Falls Sie OPS$ als Beglaubigungspräfix nutzen, ist der Account sowohl als Autologin-Account als auch über eine Benutzername/Passwort-Kombination zugänglich. Die meisten Installationen arbeiten mit OPS$.

Sehen wir uns als Beispiel einen System-Account namens FARMER an. Der dazugehö-rige Datenbank-Account für diesen Benutzer ist OPS$FARMER. Ist der BenutzerFARMER bei ihrem oder seinem System-Account angemeldet, kann sie oder er ohneAngabe eines Passworts auf den OPS$FARMER-Account zugreifen:

> sqlplus /

Der Schrägstrich / nimmt die Stelle der Benutzername/Passwort-Kombination ein, dienormalerweise für den Zugang benötigt wird.

Hinweis:Das Leistungsmerkmal für das Autologin wird nicht auf allen Plattformen unterstützt. Die Eingabe von sqlplus / bei der Eingabeaufforderung von NT DOS liefert die Fehlermeldung ORA-01004 zurück.

Accounts können mit Passwörtern angelegt werden. Beim Account OPS$FARMERkönnte der Befehl das folgende Format haben:

create user OPS$FARMERidentified by SOME_PASSWORDdefault tablespace USERStemporary tablespace TEMP;

Auch wenn das Passwort gegebenenfalls nicht eingesetzt wird, kann es trotzdem ange-geben werden. Weil der Account ein Passwort besitzt, können Sie von einem anderenBetriebssystem-Account auf den Datenbank-Account OPS$FARMER zugreifen (falls


Sie das Passwort kennen). Das folgende Listing zeigt eine Beispielverbindung zum Da-tenbank-Account OPS$FARMER von einem anderen System-Account:

> sqlplus ops$farmer/some_password

Zur Umgehung dieses Problems bieten sich zwei Möglichkeiten an. Als Erstes könnenSie den Account über die identified externally-Klausel mit einem bestimmten Pass-wort anlegen (siehe folgendes Listing). Diese Klausel umgeht die Notwendigkeit fürein explizites Passwort, während die Verbindung zwischen den Namen des Host- unddes Datenbank-Accounts erhalten bleibt:

create user OPS$FARMERidentified externallydefault tablespace USERStemporary tablespace TEMP;

Bei Verwendung der identified externally-Klausel wird die Datenbankbestätigung desBetriebssystem-Accounts erzwungen, über den der Zugang zur Datenbank realisiertwurde. Die Namen des System- und des Datenbank-Accounts müssen identisch sein.

Die zweite Option ist die Einrichtung eines Accounts mit einem unmöglichen Pass-wort. Diese Methode wird im weiteren Verlauf des Kapitels unter der Überschrift „Set-zen eines unmöglichen Passworts“ erläutert und stellt sicher, dass sich der Benutzernur über den dazugehörigen System-Account bei einem Datenbank-Account anmel-den kann.

Es gibt eine Situation, in der Sie Benutzern vielleicht erlauben möchten, einen OPS$-Account mit einem gültigen Passwort zu haben. Meldet sich der Benutzer gleichzeitigdirekt von der Betriebssystemebene und über SQL*Net von einem Remote Accountan, kann sich die Benutzung eines Accounts mit einem Passwort für den Remotezu-griff als vorteilhaft erweisen. Verbindet sich ein Entwickler auf Systemebene mit derDatenbank, möchte er nicht bei jedem Test eines Skripts nach dem Passwort gefragtwerden, eine Anforderung, die vom Autologin von OPS$ unterstützt wird. Verbindeter sich über einen Remote-Zugriff (und REMOTE_OS_AUTHENT in der init.ora istnicht auf TRUE gesetzt), benötigt er für den Zugriff auf die Datenbank ein Passwort.

9.2.10 Einsatz einer Passwortdatei für die Benutzerbeglaubigung

In den meisten Fällen können die DBA-Benutzer über das Betriebssystem beglaubigtwerden. So kann beispielsweise auf einem UNIX-System ein Mitglied der DBA-Gruppein der /etc/group-Datei mit connect internal intern verbunden werden. Werden ihreDBA-Benutzer nicht über das Betriebssystem authentifiziert, müssen Sie eine Passwort-datei einrichten und verwalten.


Zur Einrichtung einer Passwortdatei führen Sie folgende Schritte aus:

1. Legen Sie die Passwortdatei mit dem Dienstprogramm ORAPWD an.

>> ORAPWD FILE=filename PASSWORD=password ENTRIES=max_users

ORAPWD ist ein Dienstprogramm, das eine Passwortdatei generiert. Bei der Aus-führung von ORAPWD geben Sie den Namen der anzulegenden Passwortdateiund die Passwörter für den SYS- und INTERNAL-Zugang an. Der ENTRIES-Pa-rameter teilt ORACLE mit, wie viele Passworteinträge in der Datei hinterlegt wer-den sollen. Da sich die Datei später nicht mehr vergrößern lässt, sollten Sie denWert für ENTRIES möglichst hoch setzen. Wird die Grenze überschritten, erhal-ten Sie einen ORA-1996-Fehler. Legen Sie die Passwortdatei neu an, sind die SYS-DBA- und SYSOPER-Berechtigungen neu zuzuweisen.

2. Setzen Sie den Initialisierungsparameter REMOTE_LOGIN_PASSWORDFILE in der init.ora auf EXCLUSIVE. Zur Aktivierung der neuen Werte fahren Sie die Da-tenbank herunter und starten sie neu.

3. Weisen Sie jedem Benutzer, der Arbeiten im Rahmen der Datenbankverwaltung auszuführen hat, die Berechtigungen SYSOPER und SYSDBA zu (siehe folgende Beispiele). SYSDBA gibt dem Benutzer die DBA-Berechtigung; SYSOPER lässt den Benutzer Supportaktivitäten ausführen. Um einem Benutzer diese Berechti-gungen zuzuweisen, müssen Sie connected as internal sein. Privilegierte Benutzer sollten sich jetzt mit einem Befehl wie dem Folgenden mit der Datenbank verbin-den können:

connect george/[email protected] AS SYSDBA

Über den Befehl revoke lassen sich die Systemberechtigungen SYSDBA oder SYS-OPER für einen Benutzer widerrufen:

revoke SYSDBA from George;

Um die Benutzer mit den Systemberechtigungen SYSDBA und SYSOPER zu sehen,fragen Sie V$PWFILE_USERS ab. Besitzt ein Benutzer die SYSDBA-Berechtigung, istder dazugehörige Wert in der SysDBA-Spalte TRUE. Ist der Wert der SysOper-SpalteTRUE, besitzt der Benutzer die SYSOPER-Berechtigung.

9.2.11 Passwortschutz

Rollen und Profile lassen sich mit Passwörtern schützen. Die Passwörter für beide Ele-mente werden bei der Einrichtung festgelegt und lassen sich über den alter user- undalter role-Befehl ändern.


Das Anfangspasswort des Accounts setzt man über den create user-Befehl. Im folgen-den Beispiel wird der Account THUMPER mit dem Anfangspasswort RABBIT einge-richtet:

create user THUMPERidentified by RABBIT;

Die Passwörter für Accounts sollten über den alter user-Befehl geändert werden. EinBeispiel dazu im folgenden Listing:

alter user THUMPER identified by NEWPASSWORD;

Seit ORACLE8 können Sie das Passwort eines Benutzers mit dem SQL*Plus-Befehlpassword ändern. Der password-Befehl verlangt von Ihnen das alte Passwort, ein neu-es Passwort und eine Bestätigung des neuen Passworts. Die eingetragenen Passwort-werte sind am Bildschirm nicht sichtbar.

Um Ihr eigenes Passwort in SQL*Plus zu ändern, geben Sie den password-Befehl ein:

password

Um das Passwort eines anderen Benutzers zu ändern, nutzen Sie den password-Befehl,gefolgt vom Benutzernamen:

password JANE

Sie werden nach JANEs neuem Passwort und einer Bestätigung gefragt. Der password-Befehl ist insbesondere für Ihre Endanwender sehr nützlich, da sich damit die Ände-rung von Passwörtern vereinfacht. Andernfalls müssen sie den folgenden Befehl ein-setzen:

alter user USERNAME identified by NEWPASSWORD;

Der password-Befehl vereinfacht den Prozess zur Änderung des Passworts, was insbe-sondere bei ORACLE8 wichtig ist, da Sie die Änderung des Passworts durch den Be-nutzer erzwingen können. Für eine Rolle benötigen Sie kein Passwort; sollte einesangegeben sein, muss es bei Aktivierung der Rolle durch den Benutzer eingegebenwerden:

create role ACCOUNT_CREATOR identified by HELPDESK_ONLY;

Der alter role-Befehl dient der Änderung des Passworts für die Rolle. Wie die Benut-zerpasswörter können auch Rollen identified externally sein, und erzwingen damit ei-nen Link zwischen dem Host-Account und dem Rollennamen. Im Gegensatz zu denBenutzer-Accounts kann man Rollen ohne Passwörter haben (der Standard). Mithilfeder not identified-Klausel löschen Sie das Passwort der Rolle:

alter role ACCOUNT_CREATOR not identified;


Nach der Ausführung dieses Befehls ist die ACCOUNT_CREATOR-Rolle nicht mehrpasswortgeschützt.

Rollen können mit Betriebssystemberechtigungen verknüpft sein. Wenn dieses Leis-tungsmerkmal bei Ihrem Betriebssystem zur Verfügung steht, lässt es sich mit deridentified externally-Klausel des alter role-Befehls aktivieren. Ist eine Rolle aktiviert,prüft ORACLE zur Bestätigung Ihres Zugangs das Betriebssystem. Das folgende Bei-spiel zeigt die Änderung einer Rolle zur Nutzung dieses Sicherheitsmerkmals:

alter role MANAGER identified externally;

In VMS nutzt der Bestätigungsprozess die Rechte-Identifier des Betriebssystems. Beiden meisten UNIX-Systemen greift dieser Prozess auf die Datei /etc/group zu. Damitsich dieses Leistungsmerkmal bei allen Betriebssystem einsetzten lässt, setzt man denParameter OS_ROLES in der init.ora auf TRUE.

Das folgende Beispiel für diesen Prüfprozess gilt für eine Datenbankinstanz namens Lo-cal auf einem UNIX-System. Der Server /etc/group kann folgenden Eintrag enthalten:

ora_local_manager_d:NONE:1:dora

Dieser Eintrag weist die MANAGER-Rolle dem Account Dora zu. Das Suffix _d ist einHinweis darauf, dass diese Rolle bei der Anmeldung von Dora standardmäßig zuge-wiesen wird. Das Suffix _a wäre ein Hinweis darauf, dass die Rolle über with adminoption aktiviert wird. Ist diese Rolle gleichzeitig die Standardrolle des Benutzers, wür-de das Suffix _ad lauten. Sollte diese Rolle mehr als einem Benutzer zugewiesen sein,werden die zusätzlichen Benutzernamen den Einträgen in /etc/group angefügt:

ora_local_manager_d:NONE:1:dora,judy

Beim Einsatz dieser Option werden alle Rollen in der Datenbank über das Betriebssys-tem aktiviert.

9.2.12 Berechtigungen auf Objektebene

Berechtigungen auf Objektebene gewähren Benutzern den Zugriff auf Daten, die ihnennicht gehören. Zur einfacheren Verwaltung von Berechtigungen können Sie Rolleneinsetzen. Explizite Berechtigungen stehen gleichfalls zur Verfügung und sind unterbestimmten Bedingungen auch notwendig.

Berechtigungen werden über den grant-Befehl angelegt und im Data Dictionary auf-gezeichnet. Dem Benutzer kann der Zugriff auf Tabellen, Views und Sequenzen – so-wie deren Synonyme – zuzüglich der Fähigkeit zur Ausführung von Prozeduren,Funktionen, Packages und Typen gewährt werden. Die Berechtigungen können aufdie in Tabelle 9-4 aufgeführten Objekte gewährt werden.


Mit der with grant option-Klausel geben Sie dem Berechtigungsempfänger die Mög-lichkeit, die Berechtigungen auf die Basistabelle weiterzugeben. Das folgende Listingaus SQL*Plus zeigt dazu ein Beispiel: Der Benutzer THUMPER gewährt dem BenutzerMCGREGOR den SELECT- sowie einen partiellen UPDATE-Zugriff auf die EMPLO-YEE-Tabelle, die dieser Benutzer dann wiederum an JFISHER weitergibt:

grant select, update (Employee_Name, Address)on EMPLOYEE to MCGREGORwith grant option;

connect MCGREGOR/FARMERgrant select on THUMPER.EMPLOYEE to JFISHER;

Hinweis:Die Zuweisung der Berechtigungen an PUBLIC macht sie allen Benutzern der Datenbank zugänglich.

Das Management der Berechtigungen kann sehr schnell eine Zeit raubende Angele-genheit werden. Jedem Benutzer sind für jedes Objekt in der Datenbank die entspre-chenden Berechtigungen zuzuweisen. Gehen wir von einer kleinen Anwendung mit 20Tabellen und 30 Benutzern aus: in diesem Fall sind 600 Berechtigungen (30 Benutzermal 20 Tabellen) zu verwalten.

Tabelle 9-4: Verfügbare Objektberechtigungen.

Berechtigung Gewährte Berechtigung

SELECT Kann das Objekt abfragen.

INSERT Kann Zeilen in das Objekt einfügen. Diese Berechtigung kann für

bestimmte Spalten im Objekt gewährt werden.

UPDATE Kann Zeilen im Objekt aktualisieren. Diese Berechtigung kann für

bestimmte Spalten im Objekt gewährt werden.

DELETE Kann Zeilen im Objekt löschen.

ALTER Kann Zeilen im Objekt ändern.

INDEX Kann Indizes auf die Tabelle anlegen.

REFERENCES Kann Fremdschlüssel anlegen, die auf die Tabelle verweisen.

EXECUTE Kann Funktionen, Packages, Prozeduren, Bibliotheken oder Typen

ausführen.

READ Kann auf das Verzeichnis zugreifen.


Mit dem Aufkommen der Rollen vereinfachte sich die Verwaltung solcher Berechti-gungen zusehends. Rollen sind Gruppen von Berechtigungen; die Rollen werden denBenutzern zugewiesen – damit wird alles sehr viel einfacher.

Das folgende Listing zeigt ein Beispiel, in dem zwei Rollen angelegt werden. Der ersten,APPLICATION_USER, wird die Systemberechtigung CREATE SESSION zugewiesen;mit dieser Berechtigung kann sich ein Benutzer bei der Datenbank anmelden. Derzweiten Rolle, DATA_ENTRY_CLERK, wird die Berechtigung auf Tabellen gewährt.

create role APPLICATION_USER;grant CREATE SESSION to APPLICATION_USER;

create role DATA_ENTRY_CLERK;grant select, insert on THUMPER.EMPLOYEE to DATA_ENTRY_CLERK;grant select, insert on THUMPER.TIME_CARDS to DATA_ENTRY_CLERK;grant select, insert on THUMPER.DEPARTMENT to DATA_ENTRY_CLERK;

Rollen lassen sich auch anderen Rollen zuweisen. So kann man APPLICATION_USERbeispielsweise DATA_ENTRY_CLERK zuordnen:

grant APPLICATION_USER to DATA_ENTRY_CLERK;

Die Rolle kann dann einem Benutzer gewährt werden. Über den set role-Befehl lässtsich die Rolle während der Benutzersitzung dynamisch aktivieren und deaktivieren.

grant DATA_ENTRY_CLERK to MCGREGOR;

Im OEM Security Manager wählen Sie den Benutzer oder die Rolle, der/die eine Ob-jektberechtigung erhalten soll, und wählen im Fenster Object Privileges das Schemaund die Berechtigungen aus. Abbildung 9-8 zeigt den Benutzer THUMPER, dem dieBerechtigungen SELECT, INSERT und UPDATE auf die LOCATION-Tabelle gewährtwurden.

Rollen und Systemberechtigungen (wie CREATE TABLE) können anderen Benutzernmit dem Recht übergeben werden, diese Berechtigungen wiederum an andere Anwen-der weiterzureichen. Das gilt für Rollen mit der with admin option-Klausel. Im folgen-den Listing wird die DATA_ENTRY_CLERK-Rolle einem Benutzer (BPOTTER)zusammen mit der Berechtigung zur Verwaltung dieser Rolle weitergereicht:

grant DATA_ENTRY_CLERK to BPOTTER with admin option;

Mit diesen Berechtigungen kann der Anwender BPOTTER die Rolle mit grant weiter-reichen, mit revoke wieder entziehen, oder auch löschen.


Abbildung 9-8: Zuweisung von Objektberechtigungen an einen Benutzer.

Hinweis:Benutzer, denen Tabellenberechtigungen über Rollen erteilt wurden, können für diese Tabellen keine Views oder Prozeduren anlegen. Diese Einschränkung ist notwendig, da die über Rollen gewährten Berechtigungen nur gültig sind, wenn der Benutzer angemeldet und die Rolle aktiviert ist. Das Anlegen von Views durch Nicht-Eigentümer setzt explizite Berechtigungen auf die Tabellen voraus.

Die dynamische Natur der Rollen eignet sich hervorragend zur Beschränkung von Be-nutzerberechtigungen. Ist beim Start einer Anwendung durch einen Benutzer eineRolle aktiviert (über den Befehl set role), die bei Beendigung der Applikation wiederdeaktiviert wird, kann der Benutzer diese Rolle nur im Rahmen dieser Anwendungeinsetzen.

Wenn sich MCGREGOR beispielsweise bei einer Anwendung anmeldet, wird der Be-fehl

set role DATA_ENTRY_CLERK;

ausgeführt. Beim Verlassen der Applikation deaktiviert der Befehl


set role NONE;

sämtliche Berechtigungen, die über Rollen zugewiesen wurden.

Über den revoke-Befehl widerrufen Sie Berechtigungen und Rollen von Benutzern. Siekönnen dem Benutzer entweder bestimmte (über eine explizite Angabe) oder alle Be-rechtigungen (über das Schlüsselwort all) entziehen. Im folgenden Beispiel werden füreinen Benutzer eine bestimmte Berechtigung auf die EMPLOYEE-Tabelle und bei ei-nem anderen Benutzer sämtliche Berechtigungen auf diese Tabelle widerrufen:

revoke delete on EMPLOYEE from PETER;revoke all on EMPLOYEE from MCGREGOR;

Im folgenden Beispiel wird dem Benutzer-Account namens HELPDESK die RolleACCOUNT_CREATOR entzogen:

revoke ACCOUNT_CREATOR from HELPDESK;

Weil die Benutzer-Accounts über den Befehl

drop user USERNAME cascade;

vollständig gelöscht werden können, müssen die Berechtigungen für die gelöschtenAccounts nicht separat aufgeräumt werden. Der revoke-Befehl wird deshalb überwie-gend dann eingesetzt, wenn sich der Benutzerstatus ändert oder die Anwendungenvon einer Umgebung (z.B. dem Akzeptanztest) in eine andere verschoben wird (z.B.die Produktion).

Zwischen den revokes von Berechtigungen with grant option und denjenigen withadmin option gibt es einen wichtigen Unterschied. Nehmen wir an, THUMPER ge-währt MCGREGOR den Zugriff auf die EMPLOYEE-Tabelle with grant option:

grant SELECT on EMPLOYEE to MCGREGOR with grant option;

MCGREGOR kann dies jetzt mit der Berechtigung with grant option an BPOTTERweitergeben:

grant SELECT on THUMPER.EMPLOYEE to BPOTTER with grant option;

Widerruft THUMPER (mit revoke) jetzt die zuvor erteilte Berechtigung an MCGRE-GOR:

revoke SELECT on EMPLOYEE from MCGREGOR;

stellt sich die Frage, welche Berechtigung BPOTTER nun besitzt, da er den Zugriff aufdie EMPLOYEE-Tabelle von MCGREGOR erhalten hat? BPOTTER kann nicht mehrauf die EMPLOYEE-Tabelle von THUMPER zugreifen, da MCGREGOR dieser Zu-griff entzogen wurde.


Ein revoke von Berechtigungen, die with admin option gewährt wurden, funktioniertetwas anders. Wenn Sie MCGREGOR eine Systemberechtigung with admin optionzuweisen, kann MCGREGOR diese Systemberechtigung an BPOTTER weiterreichen.Widerrufen Sie MCGREGORS Berechtigung, behält BPOTTER die neue Systembe-rechtigung.

9.2.13 Auflistung der Berechtigungen

Informationen über gewährte Berechtigungen sind im Data Dictionary gespeichertund über die Data Dictionary-Views zugänglich.

Die in Tabelle 9-5 aufgeführten Views geben einen Überblick über die in der Daten-bank zugewiesenen Berechtigungen.

Wenn Sie beispielsweise wissen möchten, welche Systemberechtigungen welchen Rol-len zugewiesen wurden, erhalten Sie die gewünschten Informationen über folgendeAbfrage:

select Role, /*Name der Rolle*/ Privilege, /*Systemberechtigung*/ Admin_Option /*Mit admin option?*/ from ROLE_SYS_PRIVS;

Um Tabellenberechtigungen zu finden, die den Benutzern gewährt wurden, müssenSie nach zwei verschiedenen Zuweisungstypen suchen: explizite Zuweisung von Be-rechtigungen an Benutzer, und Berechtigungen, die über Rollen gewährt wurden. Zur

Tabelle 9-5: Data Dictionary-Views zur Ansicht von Berechtigungen.

Data Dictionary-View Inhalte

DBA_ROLES Namen der Rollen und ihr Passwortstatus

DBA_ROLE_PRIVS Benutzer, denen Rollen erteilt wurden

DBA_SYS_PRIVS Benutzer, denen Systemberechtigungen erteilt wurden

DBA_TAB_PRIVS Benutzer, denen Berechtigungen auf Tabellen erteilt wurden

DBA_COL_PRIVS Benutzer, denen Berechtigungen auf Spalten ereilt wurden

ROLE_ROLE_PRIVS Rollen, die anderen Rollen zugewiesen wurden

ROLE_SYS_PRIVS Systemberechtigungen, die Rollen zugewiesen wurden

ROLE_TAB_PRIVS Tabellenberechtigungen, die Rollen zugewiesen wurden


Ansicht der Zuweisungen, die explizit gewährt wurden, fragen Sie die DBA_TAB_PRIVS-View ab:

select Grantee, /*Berechtigungseempfänger*/ Owner, /*Objekteigentümer*/ Table_Name, /*Name des Objekts*/ Grantor, /*Benutzer, der die Berechtigung gewährt*/ Privilege, /*gewährte Berechtigung*/ Grantable /*wurde admin-Option gewährt?*/ from DBA_TAB_PRIVS;

Zur Ansicht der Tabellenberechtigungen, die über Rollen zugewiesen wurden, suchenSie die Datensätze der Benutzer in DBA_ROLE_PRIVS und vergleichen Sie mit denTabellenberechtigungen für die Rollen, die sich in ROLE_TAB_PRIVS befinden:

select DBA_ROLE_PRIVS.Grantee, /*Berechtigungsemfpänger*/ ROLE_TAB_PRIVS.Owner, /*Objekteigentümer*/ ROLE_TAB_PRIVS.Table_Name, /*Name des Objekts*/ ROLE_TAB_PRIVS.Privilege, /*gewährte Berechtiung*/ ROLE_TAB_PRIVS.Grantable /*wurde admin-Option gewährt?*/ from DBA_ROLE_PRIVS, ROLE_TAB_PRIVSwhere DBA_ROLE_PRIVS.Granted_Role = ROLE_TAB_PRIVS.Role and DBA_ROLE_PRIVS.Grantee = 'some username’;

Diese Abfrage ermittelt die Tabellenberechtigungen für einen bestimmten Benutzer,die über eine Rolle zugewiesen wurden.

Zur Ansicht der Profileinschränkungen für die aktuelle Sitzung fragen SieUSER_RESOURCE_LIMITS ab. Deren Spalten sehen wie folgt aus:

USER_PASSWORD_LIMITS beschreibt die Passwort-Profilparameter für den Benut-zer und besteht aus den gleichen Spalten wie USER_RESOURCE_LIMITS.

Für die View USER_PASSWORD_LIMITS gibt es keine DBA-Version; sie enthält aus-schließlich Informationen über die aktuellen Benutzersitzungen. Um sich die Kostenanzusehen, die mit allen verfügbaren Ressourcen verbunden sind, fragen Sie die ViewRESOURCE_COST ab. Der DBA kann sich über DBA_PROFILES sämtliche Ressour-cenbeschränkungen für alle Profile ansehen. Die Resource_Type-Spalte vonDBA_PROFILES zeigt, ob das Ressourcenprofil ein PASSWORD- oder ein KERNEL-Profil ist.

Resource_Name Der Name der Ressource (z.B. SESSIONS_PER_USER).

Limit Das auf diese Ressource gesetzte Limit.


Zusätzlich zu diesen Views gibt es zwei weitere Views mit jeweils einer Spalte, in der dieBerechtigungen und Rollen aufgeführt sind, die für die aktuelle Sitzung aktiviert sind:

SESSION_PRIVS und SESSION_ROLES stehen allen Benutzern zur Verfügung.

9.3 Beschränkung der verfügbaren Befehle: Product User Profile

In SQL*Plus steht eine zusätzliche Sicherheitsebene zur Verfügung – für bestimmteBenutzer lassen sich einzelne Befehle deaktivieren. Auf diese Weise kann man Benut-zer mit der UPDATE-Berechtigung auf eine Tabelle davon abhalten, über die Befehls-zeilenschnittstelle von SQL*Plus die Tabelle unkontrolliert zu aktualisieren.

Dieses Leistungsmerkmal erlaubt dem DBA, den Benutzern den Zugriff auf das Be-triebssystem aus SQL*Plus heraus zu verwehren (über den host-Befehl). Dieses Ver-fahren ist hilfreich, wenn eine Anwendung die Option zum Zugriff auf SQL*Plusenthält und Sie nicht möchten, dass die Anwender in irgendeiner Form auf das Be-triebssystem zugreifen.

Zusätzlich kann den Benutzern auch der connect-Befehl entzogen werden. Damitwird sichergestellt, dass die Benutzer im eigenen Account verbleiben. Das folgendeListing zeigt das Ergebnis dieser Befehle, wenn diese Sicherheitsebene eingerichtet ist:

SQL> hostinvalid command: hostSQL> connect system/managerinvalid command: connect

In beiden Fällen wird die Meldung „ungültiger Befehl“ zurückgegeben, und die Benut-zer müssen im eigenen Account bleiben.

Zur Einrichtung dieser Sicherheitsebenen müssen die Product User Profile-Tabellenangelegt werden. Das entsprechende Skript heißt pupbld.sql und befindet sich unter-halb des ORACLE Home-Verzeichnisses in /sqlplus/admin. Dieses Skript legt ver-schiedene Tabellen und Views an und sollte im SYSTEM-Account ausgeführt werden.

SESSION_PRIVS Die Privilege-Spalte führt alle Systemberechtigungen auf, die

der Sitzung zur Verfügung stehen, und entweder direkt oder

über Rollen zugewiesen wurden.

SESSION_ROLES Die Role-Spalte enthält alle Rollen, die aktuell für die Sitzung

aktiviert sind.

9.4 Passwortsicherheit beim Login 407

Für SQL*Plus ist die wichtigste Tabelle über ein Synonym namensPRODUCT_USER_PROFILE zugänglich. Zur Deaktivierung einer Rolle setzen Sie dieAttribut-Spalte auf ROLES und hinterlegen den Rollennamen in der Char_Value-Spalte. Die Deaktivierung von Rollen erfolgt üblicherweise zusammen mit der Deak-tivierung des set-Befehls (siehe Tabelle 9-6):

9.4 Passwortsicherheit beim LoginWenn Sie sich von einer Client-Maschine mit einem Datenbankserver oder von einerDatenbank zu einer anderen über einen Datenbank-Link verbinden, überträgt ORA-CLE die eingegebenen Passwörter so lange unverschlüsselt, wie keine anderen Vorga-ben gemacht werden. Seit ORACLE8 können Sie Parameter setzen, über die ORACLEgezwungen wird, das Passwort vor der Übertragung zu verschlüsseln. Zur Aktivierungder Passwortverschlüsselung setzen Sie die folgenden Parameter:

� Für Ihre Client-Maschinen setzen Sie den ORA_ENCRYPT_LOGIN-Parameter in der sqlnet.ora-Datei auf TRUE.

� Für Ihre Server-Maschinen setzen Sie den DBLINK_ENCRYPT_LOGIN-Parame-ter in der init.ora-Datei auf TRUE.

Nach dem Setzen dieser Parameter (und nachdem die Datenbank heruntergefahrenund neu gestartet wurde) wird Ihr Passwort vom Client zum Server und von Server zuServer verschlüsselt übertragen.

Tabelle 9-6: Die Spalten in PRODUCT_USER_PROFILE.

Spaltenname Beschreibung

PRODUCT Ist auf SQL*Plus zu setzen. Der Eintrag erfolgt in der gezeigten Weise in

Groß-/Kleinschreibung.

USERID Der Benutzername (in Großbuchstaben) für Anwender, deren Befehle

deaktiviert sind. Über die Wildcard „%“ können mehrere Benutzer

angegeben werden. Der alleinige Eintrag von „%“ gilt für alle Benutzer.

ATTRIBUTE Der Name des deaktivierten Befehls in Großbuchstaben. Die Deaktivierung

des SET-Befehls in SQL*Plus deaktivert auch set role und set transaction.

CHAR_VALUE Ist auf „DISABLED“ zu setzen (in Großbuchstaben).


9.5 Passwortverschlüsselung und KniffeDas Wissen darüber, wie die Datenbank Passwörter verschlüsselt und setzt, gibt demDBA die Möglichkeit zur Ausführung von Aufgaben, die andernfalls unmöglich wä-ren. Dazu gehört die Einstellung von unmöglichen Passwörtern und die Möglichkeit,ein anderer Benutzer zu werden.

9.5.1 Wie Passwörter gespeichert werden

Wenn für einen Benutzer-Account ein Passwort oder eine Rolle festgelegt wird, spei-chert die Datenbank die verschlüsselte Version dieses Passworts im Data Dictionary.Die Angabe des gleichen Passworts für zwei verschiedene Accounts führt zu verschie-denen Verschlüsselungen. Der verschlüsselte Wert aller Passwörter ist 16 Zeichen langund besteht aus Zahlen und Großbuchstaben.

Wie werden Passwörter geprüft? Wenn ein Passwort im Zuge einer Benutzerbestäti-gung eingegeben wird, ist das Passwort verschlüsselt. Diese verschlüsselte Version wirdmit dem im Data Dictionary hinterlegten Eintrag für den entsprechenden Benutzerverglichen. Stimmen die beiden Versionen überein, ist das Passwort korrekt und dieAnmeldung ist erfolgreich.

9.5.2 Setzen von unmöglichen Passwörtern

Das Wissen, wie die Datenbank Passwörter speichert, ist wichtig, weil sich damit hin-sichtlich der Account-Sicherheit neue Optionen eröffnen. Was würde passieren, wennSie nicht das Passwort selbst, sondern dessen Verschlüsselung festlegen könnten? Undwas geschähe, wenn die von Ihnen generierte Verschlüsselung nicht den Formatregelnfür verschlüsselte Passwörter entspricht? Das Ergebnis wäre ein Account, mit demman sich niemals anmelden kann, da kein Passwort die ungültige Verschlüsselung ge-nerieren könnte.

Sehen wir uns die Accounts und die verschlüsselten Passwörter an, die über die folgen-de Abfrage ausgewählt wurden. Die Abfrage wählt die Username- und Password-Fel-der aus der DBA_USERS-View aus.

select Username, /*Username*/ Password /*Encrypted password*/from DBA_USERSwhere Username in (’MCGREGOR’,’THUMPER’,’OPS$FARMER’);

Oracle 8i DBA-Handbuch - ReadingSample - beck-shop.de€¦ · Oracle 8i DBA-Handbuch Bearbeitet von...

Documents

Transcript of Oracle 8i DBA-Handbuch - ReadingSample - beck-shop.de€¦ · Oracle 8i DBA-Handbuch Bearbeitet von...