DB 12.2: Neue Security Features

Oracle hat die Dokumentation für die Datenbank Version 12.2 veröffentlicht. Es sind eine Reihe neuer Security Features enthalten, insbesondere im Bereich TDE (Transparent Data Encryption). Wir bereits vermutet wurde, wird der Krypto-Algorithmus GOST unterstützt. Auch in der Kerberos-Implementierung soll sich einiges verbessert haben: Kerberos kann nun auch für Direct NFS genutzt werden und die Client-Konfiguration wird einfacher.

Eine kurze Übersicht über die neuen Security Features gibt der New Features Guide12c Release 2:

Encryption

  • TDE Tablespace Live Conversion
  • Fully Encrypted Database
  • Support for ARIA, SEED, and GOST Encryption Algorithms in TDE
  • TDE Tablespace Offline Conversion

Kerberos in der Standard Edition

Stefan Oehrli beschreibt in seinem Blog, wie man Kerberos in der Oracle Datenbank Standard Edition verwenden kann.

In der Datenbank 11g Standard Edition wird Kerberos nicht unterstützt. In MOS Note 2145731.1 ist beschrieben, wie der RADIUS Adapter in dieser Datenbank-Version eingeschaltet werden kann. Die gleiche Vorgehensweise kann auf benutzt werden, um Kerberos einzuschalten, auch wenn MOS Note 2028070.1 ausführt, das Kerberos in der SE nicht verfügbar ist.

 

Oracle CPU Advisory April: Kerberos Schwachstelle

CVE-2016-0677 ist eine Schwachstelle in der Kerberos-Implementation der Oracle Datenbank. Betroffen sind die Versionen 12.1.0.1 und 12.1.0.2, also die neue Kerberos-Implementation in Oracle 12.

“Die einfach auszunutzende Schwachstelle kann durch einen entfernten, nicht authentisierten Angreifer zum Herbeiführen eines kompletten Denial-of-Service-Zustands ausgenutzt werden” (DFN-CERT-2016-0646). Das Oracle Critical Patch Upgrade April 2016 beseitigt noch 5 weitere sicherheitsrelevante Datenbank-Fehler. Zwei dieser Schwachstellen, darunter das Kerberos-Problem, können aus der Ferne ohne Authentifizierung eines Benutzers ausgenutzt werden.

Flash Cache Compression besser abschalten

Wer auf Exadata Flash Cache Compression eingeschaltet hat, sollte diese zunächst wieder abschalten. In einer eMail von gestern Abend empfiehlt Oracle mit Verweis auf MOS Doc ID 2115005.1: “(EX28) High risk of data loss on X3 or X4 Exadata storage when flash compression is enabled and running late 2015 or early 2016 software release “, auf allen Exadata Systeme in Version 12.1.2.3.0 die Flash Cache Compression abzuschalten. Für Versionen 12.1.2.2.1 und 12.1.2.2.0 lautet die Empfehlung, den Patch 22917774 bzw. 22928622 einzuspielen. Für ältere Systeme wird ein Upgrade empfohlen.

Hintergrund ist Bug 22909764:

Unterstützt Oracle russische Krypto-Algorithmen?

Gerüchten zufolge unterstützt Oracle in zukünftigen Versionen der Datenbank für Transparent Data Encryption (TDE), DBMS_CRYPTO und vor allem für die Database Cloud neben 3DES und AES auch nationale Krypto-Algorithmen aus Russland und Südkorea: GOST und ARIA.

Bei GOST handelt es sich um einen sowjetischen Algorithmus aus den 1970’er Jahren. Ursprünglich streng geheim, wurde er seit 1990 heruntergestuft und letztlich 2010 als ISO-Standard eingereicht und analysiert. Es handelt sich um um eine symmetrische Block-Chiffrierung mit einer Blockgröße von 64 und einer Schlüssellänge von normalerweise 256 Bit.

ARIA wurde 2003 von einer Gruppe südkoreanischer Forscher entworfen und 2004 als südkoreanischer Standard definiert. ARIA ist ein 128bit Blockchiffre mit Schlüssellängen von 128 bis 256 Bit. ARIA steht seit 2011 auch als TLS-Erweiterung zur Verfügung.

SMU 1.3.0

Das Oracle Snap Management Utility (SMU) für die Administration von Snapshots und Klonen auf der ZFS Storage Appliance ist in der Version 1.3 erschienen. Damit können nun auch 12c Container-Datenbanken verwendet werden.

Neben der Unterstützung von Snap Cloning für Multitenant Databases bringt die neue Version weitere Features mit:

  • Clone Copy (Binärkopie der Quelldatenbank)
  • Standby Clone (Einrichtung von Data Guard aus einem Klon)
  • Incomplete Recovery (Point in Time Recovery einer Datenbank auf einen Zeitpunkt oder eine SCN zwischen zwei Snapshot Backups)
  • Refresh Clone (Ein Klon muss für einen Refresh nicht mehr neu angelegt werden)

Neuer Kerberos Stack: AD Authentifikation für Datenbank 12c

Wir haben in diesem Blog des öfteren die Empfehlung ausgesprochen, eine zentrale Benutzerverwaltung statt lokaler Benutzerkonten für den Zugang zu Oracle Datenbanken zu verwenden. Für Umgebungen mit bestehender Active Directory Infrastruktur bietet sich hierfür in erster Linie die AD-Anbindung über LDAP und Kerberos an.

Die Kerberos-Unterstützung ist bereits seit Version 7 der Oracle Datenbank vorhanden und gut dokumentiert. Für die Anbindung an Active Directory wird in der Regel ein Oracle LDAP-Server (OID oder OUD) verwendet, um die Oracle-spezifischen Einstellungen nicht im Active Directory Verzeichnis speichern zu müssen. Die Einrichtung dieser Komponenten mit der Datenbank 11gR2, dem Oracle Internet Directory als LDAP-Server und Microsoft Windows Server 2008 haben wir bereits in diesem Blog und in unserem Wiki beschrieben.

Oracle Wallets hacken

Oracle Wallets werden benutzt, um SSL Zertifikate, die dazugehörigen Schlüssel, aber auch Klartext-Passwörter (Secure Enterprise Password Store) abzulegen. Sie werden normalerweise durch ein Wallet-Passwort geschützt, das bei jedem Öffnen oder Auslesen eingegeben werden muß.

Um auch automatisiert mit Wallets arbeiten zu können, gibt es die Auto-Login-Funktion. Wird diese aktiviert, wird eine zusätzliche Datei im Wallet erzeugt, die sogenannte Single Sign On Datei (.sso). Diese ist ebenfalls verschlüsselt, aber nicht mit einem benutzerdefinierten Passwort, sondern mit einem Standard-Passwort. Auto-Login-Wallets werden in der Regel verwendet, um eine automatisierte Anmeldung an der Datenbank durchführen zu können, ohne dass ein Passwort im Klartext in Skripten, Konfigurationsdateien oder Umgebungsvariablen abgelegt werden muss.

Damit es nicht möglich ist, ein Wallet einfach zu kopieren und von einem anderen Rechner aus zu verwenden, gibt es die Auto-Login-Local-Funktion. Wird diese für ein Wallet eingestellt, so kann das Auto Login Wallet nur auf dem Rechner verwendet werden, auf dem es erzeugt wurde.

Enterprise Security mit LDAP und PKI – Varianten der zentralen Benutzerverwaltung für Oracle Datenbanken

Einleitung

Direkte Benutzerkonten und Passwörter in der Datenbank sind eine Sicherheits-Schwachstelle, da in der Regel keine eindeutige Zuordnung von natürlichen Personen zu Benutzerkonten möglich ist, keine unternehmenseinheitliche Sicherheitsregel durchgesetzt werden kann und ausgeschiedene Mitarbeiter nicht sicher und sofort aus sämtlichen Systemen ausgeschlossen werden können.

In diesem Artikel werden die verschiedenen Möglichkeiten aufgezeigt, Enterprise Single Sign On und Public Key Infrastructure (PKI) zu nutzen, um Datenbankbenutzer zu authentifizieren. Anhand von Projekterfahrungen aus der Praxis wird die Integration der Oracle Datenbank mit LDAP-Verzeichnissen (OID, OUD) und Microsoft ActiveDirectory mit und ohne Oracle Virtual Directory (OVD) erklärt sowie die Einführung von SmartCard-basierter PKI als Alternative vorgestellt.