Oracle Encryption und das Solaris Cryptographic Framework

Seit Oracle 10gR2 gibt es die Moeglichkeit, einzelne Spalten einer Tabelle zu verschluesseln[1].  Als Erweiterung hiervon ist es seit Release 11gR1 moeglich, ganze Tablespaces zu verschluesseln[2].  Beide Features ermoeglichen es, sensitive Daten davor zu schuetzen, dass der Datentraeger auf irgend eine Weise ausgespaeht wird.


Der Master Key, der die Schluessel fuer die Verschluesselung von Spalten bzw. Tablespaces absichert, wird im sogenannten "Oracle Wallet" gespeichert.  Dies ist ueblicherweise eine Datei, deren Speicherort in der sqlnet.ora festgelegt werden kann.  Fuer Anwendungen mit besonders hohem Schutzbedarf ist es jedoch auch moeglich, diesen Master Key in einem externen Geraet, einem sogenannten "Hardware Security Modul" (HSM) abzulegen[3].  Der Zugriff auf diese Geraete erfolgt ueber den Standard PKCS#11.  Da nicht jeder immer gleich Zugriff auf tatsaechliche HSM-Hardware wie z.B. die Sun Crypto Accelerator Karte SCA 6000 hat, kann man statt dessen auch den Softtoken-Store des Solaris Cryptographic Framework [4,5] als HSM nutzen.  Die Oracle-seitige Konfiguration ist die gleiche, und ggf. kann man zu einem spaeteren Zeitpunkt ein "echtes" HSM dazu konfigurieren.  Die Schluessel lassen sich dann mit geschicktem export/import migrieren.


Hier nun die notwendigen Schritte:


Als erstes legt man ein normales Oracle Wallet an.  In der sqlnet.ora traegt man dazu folgendes ein:



ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
(method_data=
(directory=/opt/oracle/product/11.1.0/oracle/network/admin)))


Dann erzeugt man den Masterkey mit:



alter system set encryption key identified by "walletpasswd" ;


Damit kann man nun bereits Spalten (alter table oe.customer modify (credit_limit encrypt); ) oder Tablespaces (create tablespace test datafile '+DATA' size 10M encryption default storage(encrypt); ) verschluesseln. Bis hierher wird noch das "normale" Oracle Wallet verwendet.


Als naechstes migriert man nun die jetzt bereits vorhandenen Master-Keys fuer Spalten bzw. Tablespaces in den Softtoken.  Dazu muss dieser erst vorbereitet werden.  Da jeder Solaris-User einen eigenen Softtoken-Store hat (~/.sunw), muss dies als der Oracle-User erfolgen, unter dessen UID die Datenbank betrieben wird.  Dieser Benutzer setzt mit dem Kommando "pktool setpin" ein eigenes Passwort fuer den Tokenstore.  (Das Defaultpasswort ist "changeme", ein Ratschlag, den man natuerlich beherzigen sollte.)  Damit ist der Tokenstore bereit. 


Nun muss Oracle noch Zugriff auf die PKCS#11-Library bekommen:



mkdir ­p /opt/oracle/extapi/32/hsm/sun/1.0.0
mkdir ­p /opt/oracle/extapi/64/hsm/sun/1.0.0
cp /usr/lib/libpkcs11.so /opt/oracle/extapi/32/hsm/sun/1.0.0
cp /usr/lib/sparcv9/libpkcs11.so /opt/oracle/extapi/64/hsm/sun/1.0.0


Als letzte Vorbereitung wird nun die sqlnet.ora geaendert:



ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM)
(method_data=
(directory=/opt/oracle/product/11.1.0/oracle/network/admin)))


Die Migration der beiden Master-Keys dorthin erfolgt nun mit:



alter system set encryption key identified by "scfpasswd" migrate using "walletpasswd";


Das Wallet auf und zu (und die Daten damit zugaenglich oder auch nicht) macht man mit den Kommandos



alter system set wallet open identified by "scfpasswd";
alter system set wallet close ;


Damit verwendet Oracle jetzt den Softtoken-Store des Solaris Cryptographic Framework, um seine Masterkeys zu speichern. Wer moechte, kann nun das alte, obsolete Wallet von Oracle entweder loeschen oder in ein auto-open Wallet wandeln. Letzteres geht mit dem WalletManager (owm) von Oracle. (Danke an Peter Wahl fuer diesen Hinweis).


Das ganze funktioniert natuerlich nicht nur Single-Instance, sondern auch im RAC.  Meine Empfehlung dazu: Die Vorbereitung vollstaendig auf einem Knoten machen, dann den Softtoken, also ~/.sunw, auf die anderen Knoten kopieren, dann erst diese starten.  Ansonsten laeuft man Gefahr, dass einzelne Knoten unterschiedliche Masterkeys erzeugen, und dann bleibt, soweit ich weiss, nur ein "drop database"...  Synchronisation der Keys zwischen den Knoten gibt es mit Release 11.2.0.1. [6].  Dabei wird allerdings ein Wallet auf einem gemeinsamen Filesystem vorausgesetzt.  Da dies mit dem SCF normalerweise nicht moeglich ist (da ja die Oracle-User eigene Homeverzeichnisse haben), muss der Softtoken hier weiterhin manuell kopiert werden.  Besonders angenehm macht es hier die Software der SCA 6000, die es ermoeglicht, mittels LDAP zu synchronisieren...


Nachtrag (2010-02-23): Der Speicherort des Softtoken, normalerweise ~/.sunw, kann mittels der Umgebungsvariablen SOFTTOKEN_DIR beliebig gesetzt werden, und damit auch auf ein von allen Knoten aus zugaengliches gemeinsames Verzeichnis [7].


[1] Transparent Data Encryption (TDE)
[2] Tablespace Encryption
[3] Anleitungen
[4] SCF auf BigAdmin
[5] SCF auf docs.sun.com
[6] Neu mit 11gR2
[7] manpage zu pkcs11_softtoken(5)


2010-02-10:  This blog entry is now also available in english.

Kommentare:

Wieso muss man die PKCS 11 Bibliotheken in ${ORACLE_HOME}/admin bzw. ${TNS_ADMIN}/ kopieren???

Gesendet von UX-admin am Februar 08, 2010 at 07:58 AM MEZ #

Man muss sie in /opt/oracle/extapi/... verfuegbar machen. Nicht in ${ORACLE_HOME}/admin bzw. ${TNS_ADMIN}/. Es muss keine Kopie sein, es darf auch ein Symbolic Link sein. Es \*muss\* jedoch in /opt/oracle/extapi/... liegen. Die Oracle-Binaries sehen nur dort nach, nirgendwo sonst. Auch ein LD_LIBRARY_PATH hilft hier nicht. Der Grund ist vermutlich, dass man so sicherstellen will, dass nur root, und nicht etwa ein boeswilliger Benutzer, diese Libraries dort ablegen kann.

Gesendet von Stefan Hinker am Februar 08, 2010 at 08:24 AM MEZ #

Dem Hinweis, das 'obsolete' Wallet zu löschen, muss ich widersprechen; dass führt dazu, dass Daten, die vor der Migration mit dem MK aus dem Wallet verschlüsselt wurden, nicht mehr lesbar sind (backup, export files, Daten in redo und undo files).

Wie in meinem TDE best practices paper beschrieben ('http://www.oracle.com/technology/deploy/security/database-security/pdf/twp_transparent-data-encryption_bestpractices.pdf') entweder das wallet zu einem (local) auto-open wallet ändern, oder was wallet password ändern so dass es gleich dem 'scfpasswd' ist (beides entweder mit Oracle Wallet Manager, oder 'orapki' CLI).

Gesendet von Peter Wahl am Februar 08, 2010 at 11:26 AM MEZ #

Senden Sie einen Kommentar:
Kommentare sind ausgeschaltet.
About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute