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.

Weiterlesen

/von

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. Weiterlesen

/von

Oracle Database Standard Edition 2 nur noch mit 2 Sockets

Mit der Oracle Datenbank Version 12.1.0.2 wird es keine Standard Edition (SE) und Standard Edition One (SEO) Lizenzen mehr geben.

Stattdessen gibt es eine Standard Edition 2 (SE2), die auf Server mit zwei Sockets begrenzt ist. Bisher waren 4 Sockets in der Standard Edition möglich. Wie bisher ist auch in der SE2 die RAC Lizenz für zwei Konten enthalten. Die alten Lizenzen SE und SEO sind nur noch bis Version 12.1.0.1 nutzbar, werden aber noch 6 Monate nach 12.1.0.2 unterstützt.

Ein Standard Edition Linux RAC mit zwei Knoten und jeweils zwei Sockets war bisher die oft genutzte leistungsfähige Einstiegslizenz für eine Oracle RAC Datenbank.

Siehe auch:

Update:

/1 Kommentar/von

DMU 2.1 erschienen

,

Eine neue Version des Database Migration Assistant for Unicode (DMU) ist erschienen. In der Version 2.1 bietet das Tool nun Unterstützung bei der Unicode-Migration mit Hilfe von Golden Gate zur Minimierung der Ausfallzeit:

Oracle DMU 2.1, released in May 2015, supports a near-zero downtime migration model in conjunction with the Oracle GoldenGate replication technology. Using DMU 2.1 and GoldenGate 12.1.2.1.0 or later, you can set up a migration procedure that takes advantage of the DMU data preparation and in-place conversion capabilities while leveraging GoldenGate to replicate incremental data changes on the production system during the migration process, thereby effectively eliminating the downtime window requirement. Other new features in DMU 2.1 include migration profile support, problem data report, and transparent repository upgrade. 

Wir hatten über die Unicode-Migration und die Möglichkeit zur entkoppelten Migration auf einem parallel aufgebauten System bereits berichtet. Damals war noch das inzwischen eingestellte Streams das Mittel der Wahl für die Nachbefüllung der migrierten Datenbank.

Die Release Notes sind hier zu finden. Siehe auch Mike Dietrichs Upgrade Blog.

/von

Probleme mit dem Snapshop Management Utility

,

In einem Kundenprojekt werden Test- und Entwicklungs-Datenbanken vorbereitet, indem ein Backup der Produktion auf einem ZFS Appliance Cluster geklont wird. Auf diese Weise können schnell und ohne überflüssigen Platzverbrauch neue Datenbanken erzeugt werden.

Das Klonen eines ZFS Shares (datasets) selbst erfordert keine spezielle Vorbereitung und ist mit einem Klick in der Appliance GUI beziehungsweise einem CLI-Befehl erledigt. Soll allerdings eine ganze Datenbank geklont werden, ist etwas mehr Umsicht erforderlich, denn die Klone aller ZFS Shares, auf denen Datafiles der Datenbank liegen, müssen zusammenhängend ausgeführt werden, und es muss sichergestellt werden, das kein Share, auf dem Dateien der Datenbank liegen, vergessen wird. Außerdem müssen bei Online Backups die Archive Redo Files separat geklont werden. Und beim De-kommissionieren einer Datenbank muss geprüft werden, welche Klone aufgelöst werden können.

Um all dies zu berücksichtigen, ohne sich die Finger wund zu skripten, hat Oracle das Snapshop Management Utility (SMU) entwickelt. In der GUI lassen sich alle Datenbanken, die verwaltet werden sollen, sowie alle Storage Server, die verwendet werden, eintragen, und dann lässt sich jede Datenbank wahlweise online oder offline mit einem Befehl per Snapshot sichern und auch klonen. Es steht sowohl eine Web GUI als auch ein Command Line Interface (CLI) zur Verfügung.

Ein feine Sache, die viel eigenen Entwicklungsaufwand sparen kann, und ein Produkt mit Oracle Support. Unser Kunde plant, das SMU in das eigene Skript-Framework inkl. der lokalen Vor- und Nachbereitungen bei der Erstellung von Testumgebungen einzubauen und per CLI aufzurufen.

In der letzten SMU-Version 1.1 liefen die Tests vielversprechend, aber eine Sache fehlte noch: SMU konnte nur Datenbanken verwalten, deren Datafiles auf einem einzigen Kopf eines ZFS-Appliance-Clusters liegen. Hat man eine ZFS Cluster, wird man seine größeren Datenbanken aber selten nur auf einem Kopf belassen. Stattdessen wird man in der Regel versuchen, die Datafiles auf beide Köpfe zu verteilen, um die Bandbreite beider Köpfe zu nutzen und so die Gesamtperformance zu erhöhen.

Daher war die Freude groß, als es im README zur Version 1.2 hieß:

„Important: Previously, all of the database shares had to reside with one head of a clustered Oracle ZFS Storage system. With the Snap Management Utility 1.2 release, this is no longer a requirement. Shares can span both heads of a clustered appliance.“

Leider ist es aber nicht möglich, diese Funktionalität auch zu nutzen. Auch nur der Versuch, mit dem SMU 1.2 ein Offline-Backup einer Datenbank, deren Datendateien sich über beide Köpfe eines Clusters erstrecken, auszuführen, führt zum Fehler:

„The number of remote shares is greater than the number of shares to backup.“

Für dieses Problem haben wir im Dezember 2014 einen Oracle Service Request eröffnet, der mittlerweile zu einem Bug (20469398) geführt hat. Das bisherige Fazit ist aber leider: SMU ist für größere Installationen, die an Performance interessiert sind, nicht zu verwenden.

/von