DataChangeRecorder der perfekte Zusatz für Ihre Oracle-Datenbank

Das Audit-Feature einer Oracle-Datenbank ist überaus mächtig und vielseitig. Wichtige Ereignisse, wie fehlerhafte Logins oder DDL-Operationen lassen sich stabil und sicher protokollieren. Bei der fein granularen Protokollierung von Änderungen ist man jedoch auf das Enterprise Edition Feature Fine Grained Auditing angewiesen. Im Umfeld der Standard Edition gibt es hierfür kein entsprechendes Pendant.

An dieser Stelle schließt der H&L DataChangeRecorder die Lücke, ganz gleich ob als Ergänzung zum bestehenden Funktionsumfang des Audit-Features oder als eigenständige Lösung. Zudem geht der DataChangeRecorder noch einen Schritt weiter und speichert die Änderungen auf Datensatz-und Feldebene ab. DCR protokolliert transaktionsbasiert jegliche Änderung bzw. DML-Operation (Insert, Update, Delete). Keine Datenänderung oder Datensatzlöschung geht mehr verloren. Der besondere Vorteil, die Details, welche Spalteninhalte geändert wurden oder welchen Inhalt ein Datensatz vor seiner Löschung hatte, werden ebenfalls protokolliert.

Über eine leicht zu bedienende Oberfläche lassen sich die Protokolleinträge sichten und auswerten. Eine Vorher-Nachher-Darstellung ist selbstverständlich enthalten. Über die Steuerungsoberfläche erfolgt die Konfiguration der Überwachungsobjekte.

Oracle Produkte und die log4j-Sicherheitslücke (CVE-2021-44228 „Log4Shell“, CVE-2021-45046 und CVE-2021-45105)

Letzte Änderung dieses Blog Posts: 13.1.2022 8:45

Die Sicherheitslücken CVE-2021-44228 „Log4Shell“, CVE-2021-45046, CVE-2021-45105 sowie CVE-2021-44832 betreffen die Java-Komponente log4j der Apache Foundation.

Der Patch für die erste Sicherheitslücke CVE-2021-44228 in Form der log4j-Version 2.15 war nicht vollständig, so dass am 14.12.2021 CVE-2021-45046 für diese Version veröffentlicht wurde. Alle Patches, die log4j 2.15 enthalten, sind somit hinfällig. Dies gilt nun auch für die Patches, die log4j 2.16 enthalten, da am 19.12.2021 mit CVE-2021-45105 eine weitere Lücke hinzugekommen ist, die DOS-Angriffe auf ungepatchte Installationen ermöglicht. Diese Lücke ist mit log4j 2.17 beseitigt. Die aktuellste Version für log4j ist 2.17.1 und enthält zusätzlich Fixes bzgl. CVE-2021-44832.

Die Log4Shell Sicherheitslücke betrifft sehr viele Oracle Produkte. Das ursprüngliche zentrale Dokment bei Oracle (Impact of December 2021 Apache Log4j Vulnerabilities on Oracle Products and Services (CVE-2021-44228, CVE-2021-45046) (Doc ID 2827611.1)) verweist nun auf zwei Unterdokumente, je eines für die Oracle Cloud (Impact of December 2021 Apache Log4j Vulnerabilities on Oracle cloud environments (CVE-2021-44228, CVE-2021-45046) (Doc ID 2830129.1)) und für On-Premises-Produkte (Impact of December 2021 Apache Log4j Vulnerabilities on Oracle on-premises products (CVE-2021-44228, CVE-2021-45046) (Doc ID 2830143.1)). Hier gibt es einen Überblick über alle vorhandenen und geplanten Patches, sowie über Produkte, die keinen Patch benötigen. In diesem Blog Post fassen wir zusammen, was wir über die wichtigsten (On-Premises-) Produkte wissen und welche Vorgehensweise wir empfehlen. Sobald wir relevante neue Informationen bekommen werden wir diese hier einfließen lassen.

Weiterlesen

Monitoring Module ist nicht von kritischer log4j-Sicherheitslücke (CVE-2021-44228 „Log4Shell“) betroffen

Das Monitoring Module (HLMM) verwendet als Basis Spring Boot, welches im Standard wiederum kein log4j2 verwendet. In den ausgelieferten Libraries (exemplarisch für die Web-Application des aktuellen Releases) findet man auf dem Monitoring-Server einige JAR-Dateien, die auf log4j in einer der betroffenen Versionen hindeuten:

# locate log4j | grep jar$ | grep webapp
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-api-2.14.1.jar
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-over-slf4j-1.7.32.jar
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-to-slf4j-2.14.1.jar

Hier fehlt allerdings explizit die Datei beginnend „log4j-core“, welche von den aktuellen Sicherheitsproblemen betroffen ist. Spring Boot und damit auch HLMM enthält zwar die Log4J-API, nutzt im Standard intern allerdings SLF4J/Logback.

Weiterführende Informationen dazu finden Sie auch unter dem folgenden Link:
https://github.com/spring-projects/spring-boot/issues/28958

Spring Boot does not use log4j2 by default and those of you who are opting-in for log4j2 can update to a version that fixes the problem.

Quelle

Im Kern heißt dies also: HLMM ist von dem Problem nicht betroffen und es sind keine außerplanmäßigen Patches erforderlich.

Update 15.12.2021: HLMM ist auch nicht von der Sicherheitslücke CVE-2021-45046 betroffen.

Update 18.12.2021: HLMM ist auch nicht von der Sicherheitslücke CVE-2021-45105 betroffen.

Weitere Informationen zu der Sicherheitslücke:

Oracle Java wieder mit kostenfreiem JDK

Seit Oracle die das Java Java Development Kit vor einigen Jahren in eine kostenpflichtige Subscription verwandelt hat, gab es diverse kontroverse Diskussionen darüber. Im Gegensatz zum wahrscheinlich von Oracle erwarteten Effekt, dass jetzt alle Java-Nutzer Subscriptions abschließen (und bezahlen) würden, war offenbar eher das Gegenteil der Fall: viele User wendeten sich von Oracle Java ab und kostenlosen OpenSource-Alternativen zu. Doch nun gibt es neue Nachrichten:

Weiterlesen

SQL Macros: neu in Oracle 21c… und in Oracle 19c!

Oracle 21c ist in diversen Cloud-Umgebungen bereits verfügbar. Die on-premises-Version wird für das erste Halbjahr 2021 erwartet – also schon recht bald. Neu und sehr interessant sind SQL Macros.

SQL und PL/SQL sind zwei sehr unterschiedliche Sprachen mit unterschiedlichen Konzepten. Oracle hat grundsätzlich Möglichkeiten eingebaut, die beiden Sprachen zu verbinden. SQLs können in PL/SQL-Code ausgeführt werden und PL/SQL-Funktionen können in SQLs verwendet werden: in der SELECT-Liste in in WHERE-Bedingungen.

Weiterlesen

DPLOAD-Patch für 19.10 – aber (noch?) nicht für Windows

Oracle hat vor einigen Tagen einen Merger-Patch für das RU 19.10 herausgebracht. Dieser soll bekannte Performance-Probleme bei der Verwendung von dpload.sql (im Zusammenhang mit datapatch) beheben. Ob dies tatsächlich der Fall ist, kann man leider unter Windows nicht herausfinden – denn obwohl der Patch Nr. 32551008 als „generic“, also für alle Plattformen, deklariert ist, funktioniert die Installation nicht unter Windows.

Weiterlesen

Neues vom SYSAUX-Tablespace…

Der SYSAUX-Tablespace wurde von Oracle in der Version 10g eingeführt. Hier werden diverse sog. „Auxiliary“ Objekte gespeichert, die Oracle-eigenen Schemata zuzuordnen sind. Die Menge der enthaltenen Objekte sowie der Platzbedarf hängen u.a. von der Anzahl der in der Datenbank installierten Komponenten ab. In der Regel sind diese unkritisch – es kann aber vorkommen, dass der Platzbedarf im SYSAUX-Tablespaces plötzlich stark ansteigt, ohne dass etwas neues installiert oder überhaupt irgendetwas getan wurde.

Weiterlesen

Der ODA-Patch 19.10 ist da!

Am 08. März wurde das neueste ODA-Software-Release 19.10 veröffentlicht. Warum ist dies ein Anlass zur Freude? Schließlich gibt es diese Patches für die Database Appliance, die kleine Schwester der Exadata, mehrmals pro Jahr.

Nun – in dieser sind einige Neuerungen enthalten, die die Verwendungs- und Konfigurationsmöglichkeiten mehr als sonst bei Patchen üblich verändern…

Weiterlesen

Review DOAG Konferenz 2018

Mit großem Erfolg haben wir als Aussteller an der diesjährigen DOAG Konferenz in Nürnberg teilgenommen.

Als Highlight hatte das neue HL-Monitoring Feature „RAC Health- & Performance-Analyzer“ Premiere. So bieten wir das erste Monitoring, das nicht nur Fehlerquellen meldet, sondern diese auch definiert und integrierte Lösungsvorschläge bietet!

Weiterlesen

Clone PDB from NON$CDB in Oracle 18

 

Es ist soweit – nach und nach nehmen die Migrationsprojekte auf Oracle 18 Fahrt auf.

Eine sehr cooles Feature in Oracle 18 ist, dass man in einer Multi- oder auch Single-Tenant-Umgebung eine neue PDB aus einer vorhandenen Non-CDB clonen kann.

Weiterlesen