18c: Verschlüsselung von Anmeldeinformationen im Data Dictionary

Immer häufiger werden sogenannte Datenbank-Schwachstellen-Scanner eingesetzt, um potenzielle Sicherheitsrisiken in Datenbanken aufzuspüren. Die durch diese Werkzeuge entdeckten Schwachstellen und Fehlkonfigurationen lassen sich meist durch entsprechende Sicherheitsmaßnahmen mildern beziehungsweise komplett beheben. Es gibt allerdings auch Findings, welche leider nicht ohne weiteres gemildert oder behoben werden können, da diese systembedingt sind oder waren. Dazu gehören die im Oracle Dictionary gespeicherten Anmeldeinformationen für Datenbank Links und Datenbank Scheduler. Die hier verwendeten Kennwörter lassen sich über die Data Dictionary Tabellen SYS.LINK$ und SYS.SCHEDULER$_CREDENTIAL auslesen.

Zur Demonstration dieses Features lege ich zunächst einen Database Link an.

sqlplus / as sysdba

SQL> CREATE PUBLIC DATABASE LINK my_public_dblink CONNECT TO cloneadmin identified by welcome1 using 'DB_LINK1';

Nun Frage ich die LINK$ Tabelle ab, um das „Kennwort“ zu erhalten.

SQL> select PASSWORDX from SYS.LINK$;

PASSWORDX
--------------------
07AAA610A6F5486F00E56453E8963C05BCDBE509D682E23FB8662FC67A764571552C
50ECBA4E8A243F386398E003C6EF997CC7AA96E592DF43FA3802CEB40F93E8ECBC57
D9AA72A672086B7788119A965B5C95D663736CBC1D9DE2B3849015E69058DF79907B
27034ECA3424D12D82CBDD71566A8CD86802A1A51203760D550

Hier darf man sich von der Darstellung des PasswordX Wertes nicht täuschen lassen. Der hier angezeigte Wert sieht zwar verschlüsselt aus, ist es aber nicht. Er wurde zum Beispiel nicht durch einen SHA-512 Hashing-Algorithmus verschlüsselt, wie es bei der Speicherung des Datenbank Benutzer-Kennwortes ab der Oracle Datenbank 12c möglich ist. Zur „sicheren“ Speicherung der Anmeldinformationen von Datenbank-Links und Scheduler-Jobs werden die Kennwörter vielmehr „verschleiert“ -obfuscated- gespeichert. Bei der Verschleierung werden Informationen durch einen rückrechenbaren Algorithmus augenscheinlich unkenntlich gemacht. Hierbei handelt es sich nicht um ein Verschlüsselungs-Algorithmus im klassischen Sinne, sondern um ein vom entsprechenden Entwickler konzipiertes Verfahren. Ist also das Verfahren einem Dritten bekannt, kann er die über die Data Dictionary Tabellen SYS.LINK$ und SYS.SCHEDULER$_CREDENTIAL ausgelesenen Kennwörter lesbar machen. Aus diesem Grund sollte der Zugriff auf diese sensiblen Tabellen weiterhin sehr restriktiv gehandhabt bleiben, obwohl es ab der Oracle Datenbank Version 18c die Möglichkeit gibt, diese sensiblen Informationen mit einem echten Verschlüsselungs-Algorithmus AES256 (Advanced Encryption Standard) zu verschlüsseln. In einer Standardinstallation der 18c Datenbank sind diese Werte weiterhin nur verschleiert.

Verschlüsselung der Anmeldeinformationen von Datenbank-Links und Scheduler-Jobs

Der COMPATIBLE Parameter der Datenbank muss dabei auf mindestens 18.0.0 gesetzt sein.

Die Verschlüsselung der Anmeldeinformationen in den SYS.LINK$ und SYS.SCHEDULER$_CREDENTIAL Tabellen ist ähnlich zur Verschlüsselung von Spalten und Tablespaces mittels TDE. Es existiert jeweils ein Schlüsselpaar, bestehend aus einem Master Encryption Key -MEK- und jeweils einem Data Encryption Key -DEK- für die Tabellen SYS.LINK$ und SYS.SCHEDULER$_CREDENTIAL. Anders als bei dem Master Encryption Key, der extern gespeichert wird, werden die Data Encryption Keys verschlüsselt innerhalb der Datenbank gespeichert. Zur Ver- und Entschlüsselung der Data Encryption Keys wird der Master Encryption Key benötigt. Mit dem so entschlüsselten Data Encryption Keys können dann die Anmeldeinformationen in den SYS.LINK$ und SYS.SCHEDULER$_CREDENTIAL Tabellen gelesen werden.

Wie gerade beschrieben, benötigt die Datenbank für diese Funktionalität einen Master Encryption Key. Das ist derselbe, der beim Einsatz von Transparent Data Encryption benötigt wird.

ACHTUNG: Sollten Sie Transparent Data Encryption bereits einsetzen, müssen Sie die nächsten Schritte bis einschließlich der Erstellung des Master Encryption Keys überspringen, da für die Datenbank bereits ein Keystore und ein Master Encryption Key existiert.

Sollten Sie einen Oracle Datenbank Cloud Service in der Oracle Public Cloud verwenden, ist der Keystore und der Master Encryption Key ebenfalls bereits vorhanden und Sie brauchen keine weiteren Vorbereitungen durchzuführen.

Trifft das alles nicht zu, benötigen Sie zunächst einen Keystore für die Speicherung des Master Encryption Keys. Im Standard ist der Keystore eine PKCS12 Datei (ewallet.p12), die in einem Verzeichnis auf dem Datenbank-Server gespeichert ist. In der Regel liegt der Keystore unter $ORACLE_BASE/admin/$ORACLE_SID/wallet. Das „wallet“ Verzeichnis muss vorab angelegt werden. Es besteht natürlich die Möglichkeit, ein alternatives Verzeichnis (Beispiel: /u01/oracle/db/orcl/wallet ) zu verwenden. Dieses müssen Sie in der SQLNET.ORA Ihres Datenbank-Servers angeben.

[oracle]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
ENCRYPTION_WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /u01/oracle/db/orcl/wallet)
    )
  )

Nachdem Sie die SQLNET.ORA entsprechend angepasst haben, können Sie den Keystore erstellen und öffnen. Diese Tätigkeiten müssen Sie mit dem SYSKM oder SYSDBA Administrations-Privileg durchführen. Melden Sie sich zum Beispiel als SYS mit dem SYSKM Privileg an Ihrer Datenbank an.

[oracle]$ sqlplus / as syskm

SQL*Plus: Release 18.0.0.0.0 Production on Tue Apr 3 09:55:27 2018
Version 18.1.0.0.0

Copyright (c) 1982, 2017, Oracle.  All rights reserved.


Connected to:
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.1.0.0.0

SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/oracle/db/orcl/wallet' IDENTIFIED BY password;

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/oracle/db/orcl/wallet'
keystore altered.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;

keystore altered.

Ist das erfolgt, kann der Master Encryption Key erstellt werden.

SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY password WITH BACKUP;

keystore altered.

Dies können Sie überprüfen, indem Sie die View V$ENCRYPTION_KEYS abfragen..

SQL> SELECT KEY_ID, KEY_USE FROM V$ENCRYPTION_KEYS;

KEY_ID                                                KEY_USE
------------------------------------------------      ------------------------------
AXiF8qGCy08Lv4qa1rfHa74AAAAAAAAAAAAAAAAAAAAAAAAAAAAA  TDE IN PDB

Nun sind alle Voraussetzungen zum Verschlüsseln der Anmeldeinformation in der SYS.LINK$ und SYS.SCHEDULER$_CREDENTIAL Tabelle gegeben.

Damit alle aktuellen und alle zukünftigen Anmeldeinformation verschlüsselt gespeichert werden, müssen Sie einmalig ein neues ORACLE DDL Statement ausführen. Ab der Oracle Datenbank 18c steht dafür das Statement „ALTER DATABASE DICTIONARY“ zur Verfügung. Die Ausführung des Statements ist sehr schön überschaubar. Es existieren lediglich drei Ausführungsvarianten.

Dieses neue Statement lässt sich nur ausführen, wenn Sie das SYSKM Administrations-Privilegien besitzen.

Dieser Befehl verschlüsselt nun alle Anmeldeinformationen in den SYS.LINK$ und SYS.SCHEDULER$_CREDENTIAL Tabellen.

SQL> ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS;

Database dictionary altered

Fertig. Mehr ist nicht zu tun.

Das Ergebnis lässt sich durch Abfrage der SYS.LINK$ Tabelle überprüfen. Diese Tabelle kann nur der SYSDBA abfragen.

sqlplus / as sysdba
SQL> select PASSWORDX from SYS.LINK$;

PASSWORDX
--------------------
0806FD96C46FD721EA7D218432F2E59DBC4C13242F50551C0F1BDDCE3879D2893254
2298B98F542F48EE084B03AC1ACF0C2ABAB2F13B716A57B39EEBB2A654745D2DE3D7
35A9CC864CD18563ECEC2381B78E621163BF85A95E3A2A8616F13D8A57269CAE5A5D
443342805FAC0C3B28FEB0968D31F07C3EB8A3D62D788E7B58D

Vergleicht man nun die Werte von PASSWORX mit dem originalen Wert (ohne Verschlüsselung) lässt sich ein Unterschied erkennen.

07AAA610A6F5486F00E56453E8963C05BCDBE509D682E23FB8662FC67A764571552C
50ECBA4E8A243F386398E003C6EF997CC7AA96E592DF43FA3802CEB40F93E8ECBC57
D9AA72A672086B7788119A965B5C95D663736CBC1D9DE2B3849015E69058DF79907B
27034ECA3424D12D82CBDD71566A8CD86802A1A51203760D550
<>
0806FD96C46FD721EA7D218432F2E59DBC4C13242F50551C0F1BDDCE3879D2893254
2298B98F542F48EE084B03AC1ACF0C2ABAB2F13B716A57B39EEBB2A654745D2DE3D7
35A9CC864CD18563ECEC2381B78E621163BF85A95E3A2A8616F13D8A57269CAE5A5D
443342805FAC0C3B28FEB0968D31F07C3EB8A3D62D788E7B58D

Besteht Grund, die Anmeldinformationen in den Tabellen SYS.LINK$ und SYS.SCHEDULER$_CREDENTIAL mit einem neuen Data Encryption Key neu zu verschlüsseln, kann dies einfach durch folgenden Befehl durchgeführt werden.

sqlplus / as syskm

SQL> ALTER DATABASE DICTIONARY REKEY CREDENTIALS;

Database dictionary altered

Durch eine wiederholte Abfrage der SYS.LINK$ Tabelle können Sie die Neu-Verschlüsselung überprüfen.

sqlplus / as sysdba
SQL> select PASSWORDX from SYS.LINK$;

PASSWORDX
--------------------
08BD87AC23FFF3D2B189AF71B2928ADE698730248759F8A4D098355A81736CE10F74
E78BC325B3FC05F1A3D863CB035619E7C16393986DC74F1D035359283A906EF934C0
2BC1832461D81541733C536C38632CF2E3AB131228AC9A4E46CF45572CEE5A212271
D8FFB11A7D49940FC2056EED4F385D962C2B114F2304F5F0EE0

Wenn Sie nun die beiden PASSWORDX Werte vergleichen, erkennen Sie die Unterschiede.

08BD87AC23FFF3D2B189AF71B2928ADE698730248759F8A4D098355A81736CE10F74
E78BC325B3FC05F1A3D863CB035619E7C16393986DC74F1D035359283A906EF934C0
2BC1832461D81541733C536C38632CF2E3AB131228AC9A4E46CF45572CEE5A212271
D8FFB11A7D49940FC2056EED4F385D962C2B114F2304F5F0EE
<>
0806FD96C46FD721EA7D218432F2E59DBC4C13242F50551C0F1BDDCE3879D2893254
2298B98F542F48EE084B03AC1ACF0C2ABAB2F13B716A57B39EEBB2A654745D2DE3D7
35A9CC864CD18563ECEC2381B78E621163BF85A95E3A2A8616F13D8A57269CAE5A5D
443342805FAC0C3B28FEB0968D31F07C3EB8A3D62D788E7B58D

Zu beachten ist jetzt, dass der Keystore der Datenbank geöffnet sein muss, bevor entsprechende Database-Links beziehungsweise Scheduler-Jobs benutzt oder gestartet werden können.

sqlplus / as syskm

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY password;

keystore altered.

Ist der Keystore geschlossen, erhalten Sie folgende Fehlermeldung bei der Verwendung eines Database-Links.

sqlplus / as sysdba

SQL> SELECT SYSDATE from DUAL@MY_PUBLIC_DBLINK;
SELECT SYSDATE from DUAL@MY_PUBLIC_DBLINK
ERROR at line 1:
ORA-28365: wallet is not open

Nach Öffnung des Keystores durch den SYSDBA oder SYSKM funktioniert natürlich wieder alles wie gewohnt.

sqlplus / as syskm

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;

keystore altered.

SQL> SELECT SYSDATE from DUAL@MY_PUBLIC_DBLINK;

SYSDATE
---------
14-MAR-18

Möchten Sie alles wieder rückgängig machen, können Sie dies mit folgendem Befehl durchführen.

sqlplus / as syskm

SQL> ALTER DATABASE DICTIONARY DELETE CREDENTIALS KEY;

Database dictionary altered

Sollten Sie jetzt versuchen zum Beispiel einen Database-Link zu verwenden, erhalten Sie folgende Fehlermeldung.

sqlplus / as sysdba

SQL> SELECT SYSDATE from DUAL@MY_PUBLIC_DBLINK;
SELECT SYSDATE from DUAL@MY_PUBLIC_DBLINK

ERROR at line 1:
ORA-28449: cannot use an invalidated database link

Dies lässt sich durch das Neusetzen des Kennwortes des Database-Links korrigieren.

sqlplus / as sysdba

SQL> ALTER PUBLIC DATABASE LINK my_public_dblink CONNECT TO cloneadmin identified by welcome1;

Database link altered.
 
SQL> SELECT SYSDATE from DUAL@MY_PUBLIC_DBLINK;

SYSDATE
---------
14-MAR-18

Fazit

Dieses Feature schließt eine Sicherheitslücke, die ständig bei Datenbank-Sicherheitsüberprüfungen als Risiko angezeigt wurde und jetzt mit der 18c geschlossen ist. Wie hier zu sehen war, auch relativ einfach.

Lizenz

Dieses Feature verwendet Funktionalitäten der Transparent Data Encryption (TDE). Eine Advanced Security Option-Lizenz wird hierfür jedoch nicht benötig und steht in allen Editionen ab Oracle 18c zur Verfügung.

Weitere Informationen

• Dokumentation: Encryption of Sensitive Credential Data in the Data Dictionary
• Dokumentation: ALTER DATABASE DICTIONARY

 

Zurück zur Community-Seite