Dienstag Jun 01, 2010

SCA 6000 fuer Oracle TDE

Im Februar  hatte ich beschrieben, wie man den Softtoken Store des Solaris Cryptographic Framework als "Software-HSM" fuer Oracle TDE konfiguriert.  In der Zwischenzeit wurde nicht nur die SCA 6000 als HSM fuer Oracle TDE zertifiziert und die Konfiguration dokumentiert, sondern ich konnte das auch selbst einmal testen.  Dass es funktioniert, versteht sich von selbst.  Was die Verwendung der Karte attraktiv macht, sind die zusaetzlichen Moeglichkeiten, die die Karte bietet.  So kann man den Keystore sperren, was ein erneutes "open wallet" sowie die einzelnen Funktionen der Spaltenverschluesselung verhindert.  Auch ein 4-Augen Prinzip laesst sich hier realisieren.  Damit kann in einer Umgebung mit entsprechenden Sicherheits-Anforderungen der Zugriff auf den Master-Key von der "normalen" Datenbank-Administration getrennt werden.  Und das ist, gerade in solchen Umgebungen, ein Vorteil.

Montag Feb 08, 2010

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.

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