Administrative Aktionen in Ihrem Oracle RDS und EC2 auditiere(n)

Vorwort

Amazon Relational Database Service (Amazon RDS) ist ein Webdienst, der das Einrichten, Betreiben und Skalieren einer relationalen Datenbank in der AWS Cloud erleichtert. Er bietet kosteneffiziente, anpassbare Kapazitäten für eine branchenübliche relationale Datenbank und übernimmt gängige Aufgaben der Datenbankadministration.

DataSunrise ist ein AWS Advanced Technology Partner, zertifiziert im Bereich Security Competency in Data Protection and Encryption sowie weiteren von AWS validierten Qualifikationen. DataSunrise kann vor Ort, auf einem EC2-Server, oder als Cluster auf mehreren EC2-Instanzen – in einer virtuellen Maschine oder auf Bare-Metal – betrieben werden. Die DataSunrise Data and Database Security Suite (DataSunrise) für alle Arten von Amazon RDS fungiert als Datenbank-Anwendungsfirewall (DAF) und übernimmt die Rolle eines Man-in-the-Middle für alle Sitzungen, Abfragen und Befehle von jedem Client an die Amazon RDS-Instanz. Und da DataSunrise Software und keine SaaS-Lösung ist, sind Sie dafür verantwortlich, Ihre DataSunrise-Instanz korrekt einzurichten und zu konfigurieren.

Das Hauptziel dieses Artikels ist es, den Ansatz vorzustellen, wie die Aktivität privilegierter Konten auditiert werden kann. Wir werden sehen, wie DataSunrise so eingerichtet wird, dass die DBA-Aktivitäten in Oracle RDS auditiert werden. Allerdings gelten die allgemeinen Schritte für jede Amazon RDS-Instanz.

Überblick über Oracle RDS und Voraussetzungen

Wie Sie wahrscheinlich wissen, unterstützt Amazon RDS den Datenbankzugriff über jede standardmäßige SQL-Client-Anwendung und erlaubt keinen direkten Hostzugriff mittels SSH etc. Diese Architektur erlaubt es nicht, Datenbankagenten in Amazon RDS zu installieren und schränkt die Verwendung mächtiger DBA-Berechtigungen wie SYSDBA ein. Amazon RDS verwendet ein Shared-Responsibility-Modell, das direkte menschliche Eingriffe in die Rechenplattform ausschließt. Mit Amazon RDS können Sie Ihre Aufgaben jedoch auf etwas andere und einheitliche Weise ausführen. Beispielsweise kann ein DBA Datenbankprotokolle einsehen oder Amazon RDS-Instanzen mit Snapshots sichern, entweder über die AWS Management Console, die AWS CLI oder die RDS API. Andererseits ist es Ihnen nicht möglich, mithilfe von SSH- oder RDP-Verbindungen auf Amazon RDS für datenbank- oder betriebssystembezogene (und potenziell schädliche) Aktivitäten zuzugreifen. Bitte bedenken Sie daher, dass Sie mit der erforderlichen IAM-Rolle Ihre Amazon RDS-Instanz anpassen und verwalten können, um Ihre Systemanforderungen zu erfüllen, ohne sich per SSH/RDP mit Amazon RDS verbinden zu müssen.

Ein wichtiger Aspekt betrifft Oracle SYSDBA und ähnliche Privilegien/Rollen. Die SYSDBA-Rolle ist ausschließlich dem Benutzer RDSADMIN vorbehalten (AWS verwendet den OS-Benutzer „rdshm“) und das Passwort von RDSADMIN ist unbekannt. Ebenso können Sie bei Oracle RDS das SYS-Passwort nicht kennen. All dies bedeutet, dass:

• Sie sich nicht mit Ihrem Oracle RDS über den Benutzer RDSADMIN oder SYS verbinden können;
• Ihre Datenbankbenutzer können nicht die SYSDBA- oder andere mächtige Oracle-Datenbankrollen erhalten;
• Sie sich nicht remote mit der Oracle RDS-Instanz unter Verwendung von SYSDBA oder einer anderen mächtigen Oracle-Datenbankrolle verbinden können.

Diese eingeschränkten Berechtigungen sichern und schützen jede einzelne RDS-Instanz. Oracle RDS erstellt für Sie einen eingeschränkten DBA-Benutzer (z. B. den standardmäßig generierten „admin“-Benutzer), über den Sie sich mit der Oracle RDS-Instanz verbinden können. Später können Sie einen weiteren Benutzer anlegen, der jedoch nicht mehr Privilegien erhält als Ihr „admin“-Benutzer. Auch dies steht im Zusammenhang mit dem Shared-Responsibility-Modell der Verwaltung bei AWS. Das Amazon RDS-Team hat hier eine klare Grenze gesetzt, die Sie nicht überschreiten können.

Wir belassen das Einrichten von Oracle RDS außerhalb des Geltungsbereichs dieses Artikels. Um mit den nächsten Schritten fortzufahren, benötigen Sie eine laufende Oracle RDS-Instanz und hoffen, dass Sie eine neue Oracle RDS starten können oder Sie haben bereits Zugriff auf eine bestehende Oracle RDS-Instanz. Falls Sie Best Practices zum Betrieb von Oracle RDS erfahren möchten, lesen Sie bitte die AWS-Dokumentation.

Im nächsten Abschnitt werden wir uns ansehen, welche Möglichkeiten zur Auditierung der DBA-Aktivitäten zur Verfügung stehen.

DBA-Aktivitäten in Oracle RDS und Audit-Optionen

Die Einschränkungen der RDS-Instanzen werfen viele Fragen auf, wie beispielsweise die Auditierung DBA-spezifischer Aktionen wie ALTER SYSTEM, CREATE USER, DROP DATABASE etc. Und wie kann man die internen RDS-Benutzer wie RDSADMIN auditieren? Schauen wir uns alle verfügbaren Optionen an.

• Sie können die internen RDS-Aktivitäten einsehen, indem Sie die Amazon RDS-Datenbankprotokolldateien betrachten. Sie können Datenbankprotokolle ansehen, herunterladen und beobachten, entweder über die Amazon RDS-Konsole, die AWS Command Line Interface (AWS CLI) oder die Amazon RDS API. Amazon stellt einen Point-In-Time-Recovery-Dienst bereit und behauptet, dass RDS Transaktionsprotokolle für DB-Instanzen alle 5 Minuten in Amazon S3 hochlädt. So helfen sowohl die Datenbankprotokolldateien als auch der CloudTrail-Dienst, die Aktivitäten des RDSADMIN-Benutzers zusammen mit weiteren Informationen zu Oracle-RDS-Ereignissen zu analysieren. All diese Optionen sind gut, solange Sie keine Echtzeit-Transaktionsüberwachung und Alarmierung benötigen.
• Mit DAF-Instanzen, die auf separaten EC2-VMs laufen, können Sie alle Sitzungen und Abfragen, die an Ihre Amazon RDS-Instanz gesendet werden, auditieren. Der Zweck der DAF-Instanzen besteht darin, als Ihr Datenbankwächter zu fungieren und da Sie die DBA-Aktivität überwachen müssen, werden wir diese Option im Folgenden detailliert betrachten. Die DataSunrise-Instanzen auf EC2-Boxen sind in der Lage, den Netzwerkverkehr zu Ihrer Amazon RDS zu überwachen und abzusichern.

Überblick zu DataSunrise auf AWS und Voraussetzungen

Die Einrichtung und Konfiguration gesicherter DataSunrise-Instanzen umfasst mehrere wichtige Schritte. Um Ihre gesicherte DataSunrise-Instanz in der AWS-Umgebung vorzubereiten, befolgen Sie bitte die in unserem Dokument DataSunrise AWS Security Best Practices beschriebenen Schritte. Einige der zu erwähnenden Schritte sind:

• Zuweisung entsprechender IAM-Rollen an Ihre EC2-Instanzen mit DataSunrise;
• Erstellen und Zuweisen von VPC-Sicherheitsgruppen zu Ihrer Amazon RDS-Instanz und den EC2-Instanzen, auf denen die DataSunrise-Software läuft;
• Verwendung gesicherter und einzigartiger Passwörter für jedes Konto.

Die untenstehende Architektur besteht aus einer Datenbankinstanz (RDS oder auf EC2-Instanz) hinter DAF, einer separaten Audit-Speicher-Datenbank (RDS oder auf EC2-Instanz) sowie einer DataSunrise-Instanz, die als Proxy-Server für Benutzerverbindungen dient.

Optional bietet DataSunrise CloudFormation-Skripte zur Bereitstellung in AWS für gesicherte und kosteneffiziente Datenbanksicherheitslösungen an. Nach der Erstellung Ihrer Amazon RDS-Instanz automatisieren diese Skripte alle erforderlichen Aufgaben zur Bereitstellung von EC2-Instanzen, zur Installation von DataSunrise auf diesen EC2-Instanzen, zur Einrichtung eines Amazon Load Balancer sowie zur Erstellung aller anderen erforderlichen AWS-Ressourcen. Wir überspringen die CloudFormation-Option und fahren mit einem Szenario mit einer einzigen EC2-Instanz fort. Wir haben Videos vorbereitet, die zeigen, wie man eine DataSunrise-Instanz installiert; bitte sehen Sie sich eines der Videos an und folgen Sie den erforderlichen Schritten:

• Installation von DataSunrise unter Linux Installation von DataSunrise unter Linux — YouTube
• Installation von DataSunrise unter Windows Installation von DataSunrise unter Windows — YouTube

Am Ende des Installationsprozesses sollte Ihre DataSunrise-Instanz über Ihren Webbrowser zugänglich sein. Sie benötigen eine laufende DataSunrise-Instanz, um über die Webkonsole mit den erforderlichen Berechtigungen auf diese zugreifen zu können.

Die nächste Voraussetzung ist die Datenbankkonfiguration, die Sie in der DataSunrise-Instanz vornehmen sollten, um einen Proxy für Amazon RDS zu starten. Bitte entnehmen Sie dem DataSunrise User Guide die Abschnitte „3.1 Creating a Target Database Profile and a Proxy“ und „5.1.6 Creating Database Users Required for Getting the Database’s Metadata“. Da DataSunrise im Proxy-Modus als Man-in-the-Middle agiert, indem es alle nicht-AWS TCP-Pakete an die Amazon RDS-Instanz abfängt, können Sie denselben Standard-Orakel-Datenbankport 1521 verwenden, da die DataSunrise-Instanz auf einer anderen EC2-Instanz läuft. Stellen Sie abschließend sicher, dass Ihre Amazon RDS-Instanz NICHT über eine andere, nicht-AWS IP/Name und Port zugänglich ist, als über die DataSunrise-Instanz. All diese Schritte stellen sicher, dass alle Ihre Client-Anwendungen Ihre Oracle RDS-Instanz ausschließlich über Ihre DataSunrise-Instanz erreichen können.

Konfiguration von DataSunrise zur Auditierung von DBA-Aktivitäten

Wie bereits erwähnt, erhalten Sie bei der Erstellung Ihrer Oracle RDS einen eingeschränkten DBA-Account und dessen Passwort; standardmäßig bietet Oracle RDS den Datenbankbenutzer „admin“ zur Verbindung mit Ihrer Instanz an. Und wie Sie sich erinnern, deaktiviert Amazon RDS für Sie das SYSDBA-Privileg. Dies schränkt den möglichen Bereich potenzieller Bedrohungen für die Amazon RDS-Instanz erheblich ein. Falls Ihre Oracle RDS von Ihrem Desktop-Rechner aus zugänglich ist, versuchen Sie sich als SYSDBA mit Ihrer Oracle RDS zu verbinden, um dies zu überprüfen; siehe dazu das folgende Beispiel.

Sie werden feststellen, dass weder SYSDBA, noch SYSOPER oder andere SYS-bezogene Berechtigungen in Oracle RDS verfügbar sind – weder über TCP noch über SSH.

Daher müssen Sie darauf achten, Netzwerkverbindungen – Remote-Verbindungen – mit dem richtigen Werkzeug wie DataSunrise DAF zu auditieren. Wir werden die DataSunrise-Instanz so konfigurieren, dass alle Arten von Aktionen, die Ihr DBA remote an der Amazon RDS-Instanz ausführen kann, erfasst werden.

Zusammenfassung der nächsten Schritte

Zur Auditierung von DBA-Aktionen werden wir folgende Schritte durchführen:

1. Identifizieren Sie Ihre DBA-Benutzernamen / Accounts. DataSunrise speichert Datenbankbenutzer unter dem Menüpunkt Konfiguration. Wenn Sie mehr als einen DBA haben, erstellen Sie eine neue Gruppe von Datenbankbenutzern unter Konfiguration → Datenbankbenutzer. In unserem Beispiel verwenden wir den DBA mit dem Namen „admin“, der von unserer Oracle RDS-Instanz generiert wurde.
2. Erstellen Sie über Konfiguration → Objektgruppen einen neuen Eintrag und fügen Sie ein einzelnes Element mit dem regulären Ausdruck “.*” hinzu.
3. Erstellen Sie eine neue Audit-Regel, um die Gruppen der Datenbankbenutzer und Abfragen einzubeziehen, und auditieren Sie so die DBA-Aktivität.
4. Überprüfen Sie die DBA-Aktivität in der DataSunrise-Instanz.

1. Identifizieren und konfigurieren Sie Ihre DBA-Benutzer in DataSunrise

Gehen wir alle diese Schritte durch. Zunächst überprüfen wir unter Konfiguration → Datenbankbenutzer, ob der Benutzer „admin“ in unserer DataSunrise-Instanz vorhanden ist. Falls DataSunrise diesen Benutzer nicht hat, erstellen Sie den Benutzer „admin“ manuell. Falls Sie mehrere Oracle RDS-Instanzen haben und überall derselbe DBA-Benutzername „admin“ verwendet wird, können Sie die Option <Any> Instance wählen. Bitte vergessen Sie nicht, auf jeder Seite auf den Speichern-Button zu klicken, um Ihre Einstellungen zu sichern.

Im obigen Bild haben wir den Benutzer ADMIN erstellt und der DBA-Team-Gruppe hinzugefügt. Falls Sie mehrere DBA-Benutzer erstellt haben, fügen Sie diese bitte der Oracle DBA Team-Benutzergruppe in der DataSunrise-Instanz hinzu.

2. Konfigurieren Sie eine neue Abfragegruppe

Im zweiten Schritt erstellen wir unsere neue Abfragegruppe „AnyQuery“ und fügen lediglich einen Eintrag „.*“ im Abfrageelement hinzu. Bitte entnehmen Sie den Einstellungen dem folgenden Bild.

Wenn Sie eine neue Abfrage für die Abfragegruppe erstellen (siehe „Hinzufügen“-Button im Bild), aktivieren Sie bitte das Kontrollkästchen „Regulärer Ausdruck“.

Zu diesem Zeitpunkt haben wir den Datenbankbenutzer „ADMIN“, die Benutzergruppe „Oracle DBA Team“ in der DataSunrise-Instanz sowie unsere Abfragegruppe „AnyQuery“ mit einer Abfrage, die ein reguläres Ausdrucksmuster “.*” enthält, registriert. Wir sind etwa auf halbem Weg.

3. Erstellen und konfigurieren Sie eine neue Audit-Regel

Als Nächstes erstellen wir eine neue Audit-Regel mit dem Namen „Oracle: admin queries“ unter Verwendung der zuvor in der DataSunrise-Instanz erstellten Einstellungen. Bitte öffnen Sie die Webkonsole und navigieren Sie zu Audit → Regeln. Klicken Sie auf „Erstellen“, um die neue Regel anzulegen. Die Details entnehmen Sie bitte den folgenden Bildern.

Wir werden den Tab Filter Statements und Abfragegruppe auf der Seite nutzen, um unsere Regel mit den entsprechenden Einstellungen zu verbinden, die wir zuvor vorgenommen haben – siehe die folgenden Bilder.

Wenn Sie für den Sitzungsparameter DB User Group die Gruppe „Oracle DBA Team“ auswählen, bewirkt dies, dass DataSunrise jede Sitzung von jeder IP bzw. jedem Host erfasst, sofern der Benutzername auf der Liste der „Oracle DBA Team“ steht. Falls Sie einen weiteren Datenbankbenutzer der Gruppe „Oracle DBA Team“ hinzufügen, wird diese Regel den neuen Benutzer automatisch ebenfalls prüfen. Und da Sie den Tab Abfragegruppe auf der Seite der Audit-Regel nutzen und dort „AnyQuery“ ausgewählt haben, prüft DataSunrise jede Ausführung, die Ihr DBA-Team über die DataSunrise-Instanz tätigt. Später werden Sie diese Ereignisse unter Audit → Transactional Trails einsehen können.

Zusätzlich und optional können Sie die Details von Audit-Ereignissen über das Syslog-Protokoll an ein externes SIEM übertragen oder Alarme an andere externe Systeme senden (SMTP/E-Mail, Jira, ZenDesk, Instant Messenger). Um eine Syslog-kompatible Serververbindung zu konfigurieren, navigieren Sie bitte zu Konfiguration → Syslog-Einstellungen und nehmen die erforderlichen Einstellungen vor. Weitere Details finden Sie in unserem User Guide in den Abschnitten „7.7 Syslog Settings (CEF Groups)“ und „10.6 Syslog Integration Settings“. Um Alarme an Empfänger zu senden, die nicht Syslog sind, fügen Sie neue Einträge unter Subscribers hinzu (Webkonsole: Konfiguration → Subscribers → Server hinzufügen… – fügen Sie die Menüeinträge Subscriber hinzu). Weitere Informationen zu Subscribers finden Sie im Abschnitt „7.5 Subscriber Settings“ des DataSunrise User Guide. Später können Sie die Syslog-Einstellungen und/oder die Subscriber in Ihren DataSunrise-Regeln verwenden (siehe erstes Bild oben); bitte entnehmen Sie die entsprechenden Abschnitte dem DataSunrise User und Administrative Guide. Vergessen Sie nicht, am Ende der Seite der Audit-Regel auf den Speichern-Button zu klicken, um die neuen Einstellungen zu sichern.

Auf diese Weise haben wir jene Abfragetypen ausgewählt, die wir auditieren möchten (und vermutlich einige Personen per Alarm benachrichtigen möchten) – entweder für eine konkrete Amazon RDS-Instanz oder für mehrere Instanzen, falls Sie im Dropdown-Menü Instanz den Eintrag „<ANY>“ wählen. Es gibt mehrere Optionen, um typische Abfragen wie DBMS-Tools von der Auditierung auszuschließen. Weitere Informationen finden Sie im Abschnitt „6.4.2 Query Group Filter“ des DataSunrise User Guide in Zusammenhang mit dem Parameter Skip Group of Query der Regeln.

4. Überprüfen Sie die DBA-Aktivität in der DataSunrise-Instanz

Um zu überprüfen, ob unsere neue Audit-Regel Abfragen erfasst, werden wir CREATE USER- und DROP USER-Abfragen mit dem Oracle SQL Developer-Tool ausführen. Wir werden uns über die DataSunrise-Instanz mit der Oracle RDS-Instanz verbinden.

Anschließend können wir unter Audit → Transactional Trails in der DataSunrise-Instanz nachsehen.

Da wir die Option „Log Event in Storage“ in unserer Audit-Regel gesetzt haben, finden Sie diese Ereignisse unter

auf der Seite Audit → Transactional Trails der Webkonsole unserer DataSunrise-Instanz.

Anmerkungen zu EC2 mit Oracle-Datenbankinstanz

Es gibt einige Überlegungen zur Verwendung von Datenbankinstanzen auf Amazon EC2 zusammen mit DataSunrise. Da Sie diese Instanzen selbst einrichten und konfigurieren, können Sie – aus bestimmten Gründen – lokale Verbindungen (SSH, RDP etc.) oder Remote-Verbindungen (Datenbank-TCP) zulassen, die die DataSunrise-Instanz (oder Ihren Load Balancer) umgehen. All diese Verbindungen müssen strikt eingeschränkt werden, um ein maximales Sicherheits- und Verwaltungsniveau zu gewährleisten. In Ihrem VPC empfehlen wir die Implementierung strenger Regeln mittels Sicherheitsgruppen und Network ACLs. Ziel all dieser Einschränkungen sollte es sein, den direkten Zugriff auf Ihre Datenbankinstanz von jeglicher IP oder Netzwerkquelle auszuschließen, sodass ausschließlich die DataSunrise-Instanz auf dem Datenbankport zugreift.

Die nächsten Schritte entnehmen Sie bitte dem Abschnitt „Konfiguration der DataSunrise-Einstellungen“ dieses Artikels. Und falls Sie sich noch fragen, wie Sie potenziell schädliche SYSDBA- (und ähnliche) Rollen auditieren können, werden wir uns die Audit-Funktionalitäten von DataSunrise ansehen, die hierbei unterstützen.

Ab DataSunrise 6.2 können Sie Sitzungsparameter in den Filter Sessions-Bedingungen einbeziehen. Unten sehen Sie unsere Audit-Regel mit der Bedingung, zusätzlich zum „Oracle DBA Team“ in der DB User Group, SYSDBA- und ähnliche Privilegien zu auditieren. Wir gehen davon aus, dass wir unsere DataSunrise-Instanz so konfiguriert haben, dass sie eine Oracle-Datenbank auf einer EC2-Instanz schützt, und dass es keinen anderen Weg gibt, sich mit dem Datenbankserver zu verbinden, außer ausschließlich über den DataSunrise-Proxy-Modus.

Da unser DAF die Oracle-Datenbank auf EC2 schützt, werden wir versuchen, über den DataSunrise-Proxy eine Verbindung zur Oracle herzustellen. In den folgenden Bildern verbinden wir uns mittels Oracle SQL Developer über die DataSunrise-Instanz mit der Datenbank und verwenden dabei den Benutzernamen „sys“ sowie die SYSDBA-Rolle. Wir haben in unserer Oracle-Datenbank konfiguriert, dass dies gestattet ist. Das Testergebnis der Verbindung sehen Sie im folgenden Bild.

Falls der Test mit dem Status „Erfolgreich“ bestanden wurde, können wir versuchen, einige Abfragen auszuführen – analog zu dem, was wir zuvor im Abschnitt „Konfiguration von DataSunrise zur Auditierung von DBA-Aktivitäten“ dieses Artikels getan haben. Der Oracle SQL Developer führt die Abfragen über die DataSunrise-Instanz aus. Anschließend können wir in der DataSunrise-Webkonsole unter Audit → Transactional Trail oder Session Trails alle Abfragen und Sitzungen des Benutzers „sys“ einsehen. Unsere Audit-Regel erfasst den Datenbankbenutzer „sys“, obwohl dieser Benutzer nicht in der zuvor in der DataSunrise-Instanz erstellten Liste „Oracle DBA Team“ steht. Sobald Sie Audit → Session Trail öffnen und einen konkreten Eintrag auswählen, sehen Sie, dass die DataSunrise-Instanz auch Details zu den Oracle-Datenbankrollen sowie weitere nützliche Informationen speichert.

So haben wir die DataSunrise-Instanz so konfiguriert, dass jede DBA-Aktivität – einschließlich SYSDBA und ähnlicher Systemprivilegien der Oracle-Datenbank – auditiert wird.

Fazit

Wir haben gesehen, dass Oracle RDS weniger Aufwand erfordert, um die Oracle-Datenbankinstanz abzusichern und die DBA-Aktivität zu auditieren. Bei EC2-Instanzen erfordert es, dass Sie selbst Hand anlegen und Sitzungseinstellungen vornehmen – und dank DataSunrise Version 6.2 können Sie auch die in Oracle integrierten Rollen auditieren. Weitere Informationen entnehmen Sie bitte dem DataSunrise User Guide und den beigefügten Referenzen.

Referenzen

Überblick über Amazon RDS

AWS RDS – Überblick zur DB-Instanz

DataSunrise Inc. und AWS

DataSunrise Security für Amazon RDS

Überblick über die Amazon RDS-Datenbankprotokolldateien

AWS RDS – Überblick zu Datenbankprotokolldateien

AWS Point-In-Time Recovery Service

AWS RDS – Point-In-Time Recovery

DataSunrise AWS Security Best Practices

DataSunrise – AWS Security Best Practices

DataSunrise unterstützt AWS CloudFormation

DataSunrise – AWS CloudFormation Support

DataSunrise im AWS Marketplace

DataSunrise – AWS Marketplace Profil

Oracle Datenbankhandbuch zu SYSDBA- und SYSOPER-Systemprivilegien

Oracle Database – SYSDBA- und SYSOPER-Berechtigungen

DataSunrise User Guide

DataSunrise – User Guide Download