Oracle Database Security:Datenbanküberwachung

In diesem Artikel werde ich mit Oracle Database Security fortfahren und einige wichtige Fakten über standardmäßige Datenbanküberwachung, Überwachungsauslöser und Überwachungsrichtlinien in Oracle vorstellen. Die Datenbankprüfung besteht aus zwei Komponenten:Überwachung und dauerhafte Registrierung von etablierten Datenbankaktivitätssätzen und -ereignissen. Die Zwecke der Datenbankprüfung sind die Unbestreitbarkeit, die Untersuchung verdächtiger Aktivitäten, die Erkennung von Problemen, die durch Konfigurationen in Bezug auf die Autorisierung (Zugriff auf Ressourcen), die Einhaltung geltender Gesetze und die Kontrolle entstehen.

Standardprüfung

Welche Aktivitäten prüfen wir? Das Starten und Stoppen der Datenbank sowie die vom Datenbankadministrator hergestellten Verbindungen werden implizit von Oracle überwacht und die Daten werden automatisch im Betriebssystem gespeichert. Die folgende Tabelle zeigt andere Aktivitäten, die überwacht werden können:

Wo bewahren wir die geprüften Aktivitäten auf?

in der Datenbank , mit Datenbank-Audit-Trail, wobei wir zwei Möglichkeiten haben:
- audit_trail =DB
  was mit folgendem Code erfolgen kann:
```
alter system set audit_trail=db scope=spfile;
```

- audit_trail =DB,EXTENDED
  unter Verwendung des folgenden Codes:
```
alter system set audit_trail= db, extended scope=spfile;
```
Der Unterschied zwischen DB und DB,EXTENDED besteht darin, dass die zweite die Spalten SQLBIND und SQLTEXT CLOB der Tabelle SYS.AUD$ füllt.

extern , unter Verwendung des Betriebssystem-Audit-Trails, mit den folgenden Möglichkeiten:
- audit_trail =OS
  und der verwendete Code lautet:
```
alter system set audit_trail=os scope=spfile;
```
- audit_trail =XML und der AUDIT_FILE_DEST =Dateipfad (ist implizit $ORACLE_BASE/admin/$ORACLE_SID/adump)
  mit dem Code:
```
alter system set audit_trail=xml scope=spfile;
```

Um die aktuelle Konfiguration der gespeicherten geprüften Aktivitäten zu finden, kann man die folgende kleingeschriebene Abfrage ausführen:

select value from v$parameter where name='audit_trail';

Weitere nützliche Befehle:

[Tabellen-ID=43 /]

Sehen wir uns nun einige Beispiele für die Datenbankprüfung an.

Hier ist ein Beispiel für eine Standardprüfung mit geprüften Informationen, die in der Datenbank gespeichert sind:

Die geprüften Informationen bestehen aus den SELECT-Anweisungen, die für die Datenbanktabellen ausgeführt werden.

Führen Sie in SQL Developer das folgende Skript aus:

alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

Anschließend muss die Datenbank neu gestartet werden. Verbinden Sie sich dazu im SQLPlus-Terminal mit dem Benutzernamen sys als sysdba / password und führen Sie die folgenden Anweisungen aus:

SHUTDOWN IMMEDIATE
STARTUP

Beachten Sie, dass sich die oben genannten Größen von einem System zum anderen unterscheiden.

Führen Sie die folgende Abfrage aus, um zu überprüfen, ob der Audit-Trail richtig eingestellt ist:

select value from v$parameter where name='audit_trail';

oder:

show parameter audit_trail;

Wenn Sie die Prüfung stoppen möchten, führen Sie Folgendes aus:

NOAUDIT SELECT TABLE;

Um anzuzeigen, welche Aussagen bei der Prüfung aufgezeichnet wurden, können Sie Folgendes verwenden:

select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

oder

select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);

Ein weiteres Beispiel ist eine Standardprüfung mit geprüften Daten, die in einer XML-Datei im Standardpfad gespeichert sind.

alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

Starten Sie die Datenbank erneut neu:Verbinden Sie sich mit dem SQLPlus-Terminal mit dem Benutzernamen sys als sysdba / Passwort und führen Sie die Befehle SHUTDOWN IMMEDIATE und STARTUP aus.

Dann sollte jedes Mal, wenn eine Abfrage zum Auswählen, Einfügen, Aktualisieren und Löschen in der Employees-Tabelle fehlschlägt, dies in der XML-Datei aufgezeichnet werden.

Wenn wir die Prüfung stoppen wollen, führen wir die folgenden Befehle in der Datenbankentwicklungsumgebung aus:

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

Und stellen Sie den Standard-Audit-Trail wieder her:

alter system set audit_trail=db scope=spfile;

Unten sehen Sie ein Beispiel für einen Teil einer XML-Audit-Datei:

Wie löschen wir die geprüften Informationen?

Die Menge der geprüften Daten kann aufgrund der Anzahl der geprüften Tätigkeiten und ihrer Häufigkeit sehr groß werden. Aus diesem Grund wird empfohlen, die geprüften Daten regelmäßig zu archivieren und aus dem Produktivsystem zu löschen.

Wenn die geprüften Daten in der Datenbank gespeichert sind (Datenbank-Audit-Trail), können wir Löschanweisungen verwenden (aber erst, nachdem wir die Daten archiviert haben!):

DELETE FROM SYS.AUD$;

Sie können die geprüften Informationen für ein bestimmtes Datenbankobjekt löschen, beispielsweise eine Tabelle mit dem Namen Produkte:

DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

Audit-Trigger

Ein Trigger ist ein PL/SQL-Block oder die CALL-Anweisung einer PL/SQL-Prozedur, die automatisch ausgeführt wird, wenn ein Ereignis eintritt. Es gibt zwei Arten von Triggern:auf Datenbankebene (Datenbankanweisungen) und auf Anwendungsebene (z. B. das Drücken einer Schaltfläche in einem Oracle-Formular). Die für die Überwachung verwendeten Trigger sind die Trigger auf Datenbankebene. Sie werden in die folgenden Kategorien eingeteilt:

DML-Trigger – wo eine DML-Anweisung auf einer Tabelle ausgelöst wird. Diese Trigger können unabhängig von der Anzahl der Datensätze einmal auf Befehlsebene ausgeführt werden (Trigger auf Anweisungsebene) oder sie können FÜR JEDE REIHE (Trigger auf Datensatzebene) ausgeführt werden. Arten von Auslösern auf Datensatzebene:BEFORE STATEMENT, AFTER STATEMENT, VOR JEDER REIHE, NACH JEDER REIHE;
INSTEAD OF Triggers – wo eine DML-Anweisung in einer Ansicht ausgelöst wird;
SYSTEM-Trigger – ausgelöst durch Ereignisse wie das Starten/Stoppen der Datenbank, DDL-Anweisungen, Benutzeranmeldung/-abmeldung. Arten von Systemauslösern:NACH DEM EREIGNIS, VOR DEM EREIGNIS.

Abfragen von SYS.TRIGGER$ Tabelle oder die ALL_TRIGGERS view bietet Informationen zu allen Triggern auf Datenbankebene. Beispielsweise kann der eindeutige Triggertyp aus der Datenbank wie folgt gefunden werden:

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

Die Ansicht DBA_TRIGGERS bietet Informationen zu den Triggern, die automatisch von den Oracle-Produkten bei der Installation erstellt werden. Wenn wir Informationen über die SYSTEM-Trigger („BEFORE EVENT“ und „AFTER EVENT“) finden möchten, können wir die folgende Anweisung ausführen:

SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

Außerdem werden bei der Installation DML-Trigger automatisch im HR-Benutzerschema erstellt:

SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

Für die Prüfung können wir benutzerdefinierte Auslöser erstellen, um die gewünschten Informationen aufzuzeichnen, aber man sollte eine spezielle Tabelle erstellen, um die geprüften Informationen zu speichern.

Es ist wichtig sicherzustellen, dass die entwickelten Trigger die normale Datenbankaktivität nicht beeinflussen. Der Zweck der Überwachung besteht darin, die normale, tägliche Datenbankaktivität passiv zu überwachen und für spätere Analysen zu speichern. Folglich wird nicht empfohlen, INSTEAD OF-Trigger zu erstellen, um die Ergebnisse aus den Zieltabellen an die Audit-Tabelle zurückzugeben.

DML-Trigger auf Anweisungsebene können mit DML-Triggern auf Datensatzebene koexistieren. Die Aufrufreihenfolge ist:

Vorher-Anweisung auslösen
für jeden betroffenen Datensatz
- Vor dem Datensatz auslösen
- aktuelle DML-Aktion
- NACH Datensatz auslösen
AFTER-Anweisung auslösen

Benutzerdefinierte Trigger werden nur ausgeführt, wenn laut Oracle die Anweisung korrekt ist und auftreten kann. Bei einer falschen DML-Anweisung oder einer, die gegen eine Einschränkung verstößt, wird ein Fehler zurückgegeben und der Trigger wird nicht ausgeführt. Daher empfiehlt es sich, für Auditing insbesondere die LMD-Trigger auf Anweisungsebene zu verwenden.

Beispiel für Audit-Trigger:

Angenommen, wir möchten einen Trigger erstellen, um in einer Audit-Tabelle (namens TAB_AUDIT_EMP) Informationen über die DML-Auszüge aufzuzeichnen, die Gehälter über 20000 (Währung ist hier nicht wichtig) für die Mitarbeiter des Unternehmens ermitteln. Wir wollen in TAB_AUDIT_EMP die Sequenznummer der Abfrage, den Benutzernamen, die Sitzung, den Host und das Datum speichern.

Dies kann folgendermaßen erfolgen:

CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;

Angenommen, wir nehmen eine Gehaltsänderung für die Mitarbeiter in einer bestimmten Abteilung vor:

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

Und dann überprüfen wir die Überwachung:

select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;

Audit-Richtlinien

Die dritte Prüfmethode bezieht sich auf Prüfrichtlinien. Die Definition einer Prüfrichtlinie enthält Folgendes:

Spezifikation des zu überwachenden Objekts (Schema, Objektname, Spalten)
Spezifikation der für ein Objekt geprüften Aktionen (SELECT, INSERT, UPDATE, DELETE):implizit ist es SELECT
Spezifikation der Bedingungen, die erfüllt sein müssen, um die geprüften Informationen aufzuzeichnen, erfolgt in der WHEN-Klausel des Auslösers und ist optional
Ein Event-Handler, der zusätzlich das Event behandelt, was optional ist.

Eine Überwachungsrichtlinie kann aktiv (Status AKTIVIERT) oder inaktiv (Status DEAKTIVIERT) sein. Die Liste der Audit-Richtlinien kann durch Abfragen der Ansicht ALL_AUDIT_POLICIES abgerufen werden:

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

Für die Verwaltung von Überwachungsrichtlinien haben wir das DBMS_FGA-Paket. Um dieses Paket zu verwenden, ist es notwendig, den Benutzern, die PL/SQL-Code schreiben werden, Berechtigungen zu erteilen:

grant execute on dbms_fga to username;

Beispiel einer Überwachungsrichtlinie:

Wir möchten eine Überwachungsrichtlinie zum Aufzeichnen der DML-Anweisungen erstellen, die die Manager (MANAGER_ID) in der Tabelle DEPARTMENTS ändern. Wir können einen Handler für die Richtlinie namens proc_audit_alert erstellen, der uns über eine Änderung bezüglich des Managers informiert:

CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

Und die Richtlinie kann sein:

CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

Beachten Sie, dass object_schema, object_name, policy_name, audit_column, statement_types und handler_module an die Richtlinie angepasst werden müssen, die Sie schreiben möchten.

Dann führen wir die Prozedur aus:

EXECUTE proc_audit_manager;

Wir können überprüfen, ob die Richtlinie aktiviert ist:

SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';

Überprüfen Sie dann, ob das Verfahren und die Richtlinie korrekt funktionieren, indem Sie ein Update ausführen:

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

Zusammenfassend lässt sich sagen, dass für jede Datenbank eine Überwachung erforderlich ist, und die oben angegebenen Methoden helfen Ihnen dabei, verdächtige Aktivitäten zu finden, die Ihre Datenbanksicherheit beeinträchtigen könnten. Weitere Einzelheiten zur Prüfung von Oracle-Datenbanken finden Sie in der nachstehenden Bibliographie.

Literaturverzeichnis:

http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
http://docs.oracle.com/cd/B10501_01/server.920/a96521/audit.htm
https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000