Autorisierung

Während des Autorisierungsprozesses erhält der Datenbankmanager Informationen über die Autorisierungs-ID des authentifizierten Benutzers. Die Autorisierungs-ID gibt an, welche Datenbankoperationen der Benutzer ausführen kann, einschließlich der Datenbankobjekte, auf die der Benutzer zugreifen kann. Die Berechtigungen, die explizit in Db2 deklariert werden, ermöglichen es Benutzern, bestimmte Aktionen auszuführen.

Für eine Autorisierungs-ID können Berechtigungen auf verschiedenen Ebenen erteilt werden:

• Primär — Primäre Berechtigungen werden der Autorisierungs-ID direkt erteilt.

• Sekundär — Sekundäre Berechtigungen werden den Gruppen und Rollen erteilt, zu denen die Autorisierungs-ID gehört.

• Öffentlich — Die öffentliche Ebene ist eine spezielle Db2-Gruppe, die alle Mitglieder der Organisation repräsentiert.

• Kontextsensitiv — Diese Berechtigungen werden einer vertrauenswürdigen Kontextrolle gewährt.

Db2-Autoritätsebenen

Db2 verwaltet Autoritäten auf den folgenden Ebenen:

• Instanz- oder Systemebene:SYSADM,,SYSCTRL, SYSMAINT SYSMON

  • Datenbankebene: DBADM (SQLADM(EXPLAIN),WLMADM), SECADM (ACCESSCTRL), DATAACCESS

    • Schemaebene: SCHEMAADM (LOAD)ACCESSCTRL, DATAACCES S

    • Zusätzliche Rechte auf Schemaebene

Db2 unterstützt die folgenden zusätzlichen Rechte auf Schemaebene:

• SELECTINermöglicht es dem Benutzer, Zeilen aus allen im Schema definierten Tabellen oder Ansichten abzurufen.

• INSERTINermöglicht es dem Benutzer, Zeilen einzufügen und das IMPORT Hilfsprogramm für alle im Schema definierten Tabellen oder Ansichten auszuführen.

• UPDATEINermöglicht dem Benutzer, die Update Anweisung für alle im Schema definierten Tabellen oder aktualisierbaren Ansichten auszuführen.

• DELETEINermöglicht dem Benutzer, Zeilen aus allen im Schema definierten Tabellen oder aktualisierbaren Ansichten zu löschen.

• EXECUTEINermöglicht es dem Benutzer, alle im Schema definierten benutzerdefinierten Funktionen, Methoden, Prozeduren, Pakete oder Module auszuführen.

• CREATEINermöglicht dem Benutzer, Objekte innerhalb des Schemas zu erstellen.

• ALTERINermöglicht dem Benutzer, Objekte innerhalb des Schemas zu ändern.

• DROPINermöglicht es dem Benutzer, Objekte innerhalb des Schemas zu löschen.

Autorisierungs-ID

Eine Db2-Autorisierungs-ID besteht aus folgenden Elementen:

• Typ der Autorisierungs-ID

  • Einzelner Benutzer (U)

  • Gruppe (G)

  • Rolle (R)

  • Öffentlich (P)

• Wert der Autorisierungs-ID

Eine Autorisierungs-ID, der die Berechtigungen und Rechte zugeordnet werden können, wird zur Identifizierung zusammen mit der Überprüfung der Db2-Autorisierung verwendet.

Die folgenden Begriffe werden in Db2 häufig als primäre Autorisierungs-ID verwendet:

• Systemautorisierungs-ID — Die Autorisierungs-ID, die für alle anfänglichen Autorisierungsprüfungen verwendet wird, z. B. für die Überprüfung von Rechten CONNECT während der CONNECT Verarbeitung.

• Sitzungsautorisierungs-ID — Die Autorisierungs-ID, die für alle Überprüfungen der Sitzungsautorisierung verwendet wird, die auf die ersten Prüfungen während der CONNECT Verarbeitung folgt. Um den aktuellen Wert der Sitzungsautorisierungs-ID zu sehen, verwenden Sie das SESSION_USER spezielle Register.

• Autorisierungs-ID für Anweisungen — Die Autorisierungs-ID (zusammen mit der zugehörigen sekundären Autorisierung IDs für Gruppen oder Rollen), die für die Autorisierungsanforderungen einer SQL-Anweisung verwendet wird. Dies wird auch verwendet, um gegebenenfalls den Eigentümer des Objekts zu bestimmen. Sie kann je nach Art der SQL-Anweisung und dem Kontext, in dem sie ausgegeben wird, variieren.

Befugnisse und Privilegien werden durch explizite Mechanismen wie GRANT REVOKE UND-Anweisungen oder durch implizite Mechanismen, wie z. B. Rechte, die durch Objekteigentum erlangt werden, erworben. Sie können auch vorübergehend durch mehrere Verarbeitungskontexte erworben werden. Sie haben beispielsweise Zugriff auf eine Ansicht erhalten, wodurch Sie implizit auf die Objekte in dieser Ansichtsdefinition zugreifen können. Außerdem erhalten Sie mit einer EXECUTE Berechtigung für ein Paket Zugriff auf alle statischen SQL-Befehle in diesem Paket. Die andere Möglichkeit, temporäre Autorität und Privilegien zu erlangen, ist die Verwendung eines vertrauenswürdigen Kontextes.

Vertrauenswürdiger Kontext

Ein vertrauenswürdiger Kontext ist ein Datenbankobjekt, das eine Vertrauensbeziehung zwischen der Datenbank und einem externen Anwendungsserver oder einem anderen Datenbankserver definiert. Die Vertrauensstellung basiert auf den folgenden Vertrauensattributen:

• IP-Adresse

• Systemautorisierungs-ID

• Verschlüsselungsgrad für die Datenkommunikation

Wenn eine Verbindung den Vertrauensattributen innerhalb eines definierten vertrauenswürdigen Kontextobjekts entspricht, wird eine vertrauenswürdige Verbindung hergestellt. Es gibt zwei Arten von vertrauenswürdigen Verbindungen:

• Implizite vertrauenswürdige Verbindung — Eine implizite vertrauenswürdige Verbindung ermöglicht es einem Benutzer, eine Rolle zu erben, die ihm außerhalb des Geltungsbereichs dieser vertrauenswürdigen Verbindungsdefinition nicht zur Verfügung steht. Der Sitzungsautorisierungs-ID der Verbindung wird eine temporäre Mitgliedschaft in einer Rolle zugewiesen, die in der vertrauenswürdigen Kontextdefinition deklariert ist.

  Das folgende Diagramm zeigt ein Beispiel für eine implizite vertrauenswürdige Verbindung, bei der nur eine Verbindung von einer IP-Adresse aus zulässig ist.

   

  

  1. Die Rolle dbconnrole wird erstellt und ihr wird eine Verbindung zur Datenbank gewährt. Der vertrauenswürdige Kontext ctximpl wird anhand der authid ABC Verbindung unter Verwendung der IP-Adresse 10.10.10.1 und der Standardrolle erstelltdbconnrole.

  2. Der Benutzer ABC kann von der IP-Adresse aus eine Verbindung zur Datenbank herstellen10.10.10.1.

  3. Der Benutzer ABC kann von der IP-Adresse aus keine Verbindung herstellen10.10.10.2.

• Explizite vertrauenswürdige Verbindung — Eine explizite vertrauenswürdige Verbindung ermöglicht es einem vertrauenswürdigen Anwendungsserver oder einem anderen DB2-Datenbankserver, die aktuelle Benutzer-ID für die bestehende Verbindung auf effiziente Weise zu ändern. Ein Anwendungsserver stellt die ursprüngliche Verbindung mit einer ausdrücklichen Vertrauensanfrage her. Sobald die Vertrauensstellung hergestellt ist, kann der Anwendungsserver Anfragen an den Datenbankserver stellen, um die Sitzungsautorisierungs-ID für jede neue Arbeitseinheit zu ändern. Die ID, die zur Ausführung der ersten Verbindungsanforderung verwendet wird, benötigt CONNECT nur Rechte auf dem Server.

  Explizite vertrauenswürdige Verbindungen sind hilfreich, wenn Sie über einen Middle-Tier-Server verfügen, der Datenbankanfragen im Namen mehrerer Benutzer mit unterschiedlichen Zugriffsmustern für verschiedene Datenbankobjekte wie Tabellen stellen muss. Das auf dem Datenbankserver erstellte vertrauenswürdige Kontextobjekt ermöglicht es dem Middle-Tier-Server, eine explizite vertrauenswürdige Verbindung zur Datenbank herzustellen und dann die aktuelle Benutzer-ID der Verbindung auf die entsprechende Benutzer-ID umzuschalten, ohne dass eine erneute Authentifizierung beim Datenbankserver erforderlich ist. Basierend auf den Rechten, die den Datenbankobjekten für die Benutzerautorisierungs-ID gewährt wurden, kann der Benutzer weiterhin Operationen ausführen, wobei die tatsächliche Identität des Benutzers, der bestimmte Aufgaben ausführt, erhalten bleibt.

  Das folgende Diagramm zeigt ein Beispiel für eine explizite vertrauenswürdige VerbindungUSER1, bei derUSER2, und USER3 alle Verbindungen über die herstellen authidAPPID.

  

  1. Der vertrauenswürdige Kontext ctxexpl wird auf der Grundlage einer authid APPID Verbindung erstellt, die 10.10.10.1 die IP-Adresse für Benutzer USER1USER2, und verwendetUSER3.

  2. Die Benutzer stellen eine Verbindung zu einem Server der mittleren Ebene her.

  3. Die vertrauenswürdige Verbindung wird mit APPID hergestellt.