Informationen zur Anwendung

Der Skriptcontent auf dieser Seite ist ausschließlich für Navigationszwecke vorgesehen und bewirkt keinerlei Änderung des Contents.

Die Anwendung hat die folgenden Zweck-, Struktur- und Benennungskonventionen.

Zweck der Anwendung

Die Anwendung ist für zwei Arten von Benutzern in einem Unternehmen bestimmt.

• Typische Benutzer (Manager von Mitarbeitern)

• Anwendungsadministratoren

Typische Benutzer können die folgenden Aufgaben ausführen:

• Mitarbeiter in einer bestimmten Abteilung abrufen

• Jobhistorie für einen bestimmten Mitarbeiter abrufen

• Allgemeine Informationen für einen bestimmten Mitarbeiter anzeigen (Name, Abteilung, Tätigkeit, Manager, Gehalt usw.)

• Gehalt eines bestimmten Mitarbeiters ändern

• Tätigkeit eines bestimmten Mitarbeiters ändern

Anwendungsadministratoren können die folgenden Aufgaben ausführen:

• ID, Titel oder Gehaltsbereich einer vorhandenen Tätigkeit ändern

• Neuen Job hinzufügen

• ID, Name oder Manager einer bestehenden Abteilung ändern

• Neue Abteilung hinzufügen

Struktur der Anwendung

Die Anwendung verwendet die folgenden Schemaobjekte und Schemas.

Schemaobjekte der Anwendung

Die Anwendung setzt sich aus folgenden Schemaobjekten zusammen:

• Vier Tabellen, in denen die folgenden Daten gespeichert werden:

  • Jobs

  • Abteilungen

  • Mitarbeiter

  • Tätigkeitshistorie der Mitarbeiter

• Vier Editionsansichten, die sich auf die Tabellen beziehen, sodass Sie die fertige Anwendung bei Verwendung mit einer Editions-basierten Neudefinition (EBR) aktualisieren können

• Zwei Trigger, die Geschäftsregeln durchsetzen

• Zwei Sequenzen, die eindeutige Primärschlüssel für neue Abteilungen und neue Mitarbeiter generieren

• Zwei Pakete:

  • employees_pkg, die Anwendungsprogrammschnittstelle (API) für typische Benutzer

  • admin_pkg, die API für Anwendungsadministratoren

  Die typischen Benutzer und Anwendungsadministratoren greifen nur über ihre APIs auf die Anwendung zu. Daher können sie die Daten nur ändern, indem sie Packageunterprogramme aufrufen.

Siehe:

• "Info zu Oracle Database" für Informationen zu Schemaobjekten

• Oracle Database Development Guide für Informationen zu EBR

Schemas für die Anwendung

Aus Sicherheitsgründen verwendet die Anwendung die folgenden fünf Schemas (oder Benutzer), von denen jedes nur über die erforderlichen Berechtigungen verfügt.

• app_data ist Eigentümer aller Schemaobjekte mit Ausnahme der Packages und lädt die zugehörigen Tabellen mit Daten aus Tabellen im Beispielschema HR

  Die Entwickler, die Packages erstellen, funktionieren nie in diesem Schema. Daher können sie Anwendungsschemaobjekte nicht versehentlich ändern oder löschen.

• app_code ist nur Eigentümer des Pakets employees_pkg

  Die Entwickler von employees_pkg arbeiten in diesem Schema.

• app_admin ist nur Eigentümer des Packages admin_pkg

  Die Entwickler von admin_pkg arbeiten in diesem Schema.

• app_user, der typische Anwendungsbenutzer, besitzt nichts und kann nur employees_pkg ausführen

  Der Middle Tier Application Server meldet sich als app_user bei der Datenbank im Connection Pool an. Wenn dieses Schema kompromittiert ist – beispielsweise durch einen SQL-Injection-Bug – kann der Angreifer nur sehen und ändern, welche employees_pkg-Unterprogramme es sehen und ändern. Der Angreifer kann keine Tabellen löschen, Berechtigungen eskalieren, Schemaobjekte erstellen oder ändern oder irgendetwas anderes.

• app_admin_user, ein Anwendungsadministrator, besitzt nichts und kann nur admin_pkg und employees_pkg ausführen

  Der Verbindungspool für dieses Schema ist sehr klein, und nur berechtigte Benutzer können darauf zugreifen. Wenn dieses Schema kompromittiert ist, kann der Angreifer nur die Unterprogramme admin_pkg und employees_pkg anzeigen und ändern.

Angenommen, die Anwendung hatte anstelle von app_user und app_admin_user nur ein Schema, dessen Eigentümer nichts war und das sowohl employees_pkg als auch admin_pkg ausführen konnte. Der Connection Pool für dieses Schema muss groß genug für die typischen Benutzer und die Anwendungsadministratoren sein. Wenn ein SQL-Injection-Bug in employees_pkg vorhanden war, konnte ein typischer Benutzer, der diesen Bug ausnutzte, auf admin_pkg zugreifen.

Angenommen, die Anwendung hatte statt app_data, app_code und app_admin nur ein Schema, das Eigentümer aller Schemaobjekte war, einschließlich der Packages. Die Packages hätten dann alle Berechtigungen für die Tabellen, was unnötig und unerwünscht wäre.

Beispiel: Sie haben die Audittrailtabelle AUDIT_TRAIL. Sie möchten, dass die Entwickler von employees_pkg in AUDIT_TRAIL schreiben, es aber nicht lesen oder ändern können. Sie möchten, dass die Entwickler von admin_pkg AUDIT_TRAIL lesen und darauf schreiben können, aber nicht ändern können. Wenn AUDIT_TRAIL, employees_pkg und admin_pkg zum selben Schema gehören, haben die Entwickler der beiden Packages alle Berechtigungen für AUDIT_TRAIL. Wenn AUDIT_TRAIL jedoch zu app_data gehört, employees_pkg zu app_code gehört und admin_pkg zu app_admin gehört, können Sie sich als app_data bei der Datenbank anmelden und dies tun:

GRANT INSERT ON AUDIT_TRAIL TO app_code;
GRANT INSERT, SELECT ON AUDIT_TRAIL TO app_admin;

Siehe:

• "Info zu Oracle Database" für Informationen zu Schemas

• "Info zum Beispielschema HR" für Informationen zum Beispielschema HR

• "Empfohlene Sicherheitsverfahren"

Benennungskonventionen in der Anwendung

Die Anwendung verwendet diese Benennungskonventionen.

Element	Name
Tabelle	Tabellen-Nr.
Editionsansicht für Tabelle#	Tabelle
Trigger für Editionierungsansicht der Tabelle	table_{a|b}event[_fer] wobei: einen AFTER-Trigger kennzeichnet. b identifiziert einen BEFORE-Trigger. fer identifiziert einen FOR EACH ROW Trigger. event gibt das Ereignis an, das den Trigger auslöst. Beispiel: i für INSERT, iu für INSERT oder UPDATE, d für DELETE.
PRIMARY KEY-Constraint in Tabelle#	table_pk
NOT NULL-Constraint für table#.column	table_column_not_null (Fußnote 1)
UNIQUE-Constraint für table#.column	table_column_unique (Fußnote 1)
CHECK-Constraint in table#.column	table_column_check (Fußnote 1)
REF-Constraint auf table1#.column in table2#.column	table1_to_table2_fk (Fußnote 1)
REF-Constraint auf table1#.column1 zu table2#.column2	table1_col1totable2_col2_fk (Fußnote 1) (Fußnote 2)
Folge für Tabellenr	table_sequence
Parametername	p_Name
Lokaler Variablennamen	l_Name

Fußnote 1: Tabelle, Tabelle 1 und Tabelle 2 sind abgekürzt als emp für Mitarbeiter, Abteilung für Abteilungen und job_hist für job_history.

Fußnote 2: col1 und col2 sind Abkürzungen der Spaltennamen column1 und column2. Ein Constraint-Name darf nicht mehr als 30 Zeichen enthalten.