Oracle Transparent Data Encryption

Transkript

1 Oracle Transparent Data Encryption Markus Flechtner Consultant DOAG-Regionaltreffen NRW 22. April 2009 Baden Basel Bern Brugg Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien 1

2 Agenda Motivation Column Encryption (ab Oracle 10gR2) Tablespace Encryption (ab Oracle 11g) Einschränkungen, Schwächen & Risiken Wissen vermitteln ist erst der Anfang. Wissen umsetzen das Entscheidende. Fazit 2 2

3 Warum Verschlüsselung? (1) Anforderungen an die Datensicherheit steigen ( Compliance ) Z.B. PCI (Payment Card Industry Data Security Standard) SOX (Sarbanes-Oxley Act) Datendiebstähle und verluste häufen sich 48 Prozent der Daten- und Informationslecks sollen 2008 durch den Verlust oder Diebstahl von Computern und Datenträgern entstanden sein (Symantec Internet Threat Security Report 4/09) Verschlüsselung ist ein Baustein zur Erhöhung der Sicherheit 3 3

4 Warum Verschlüsselung? (2) #!" # Ziel von Verschlüsselung: Unberechtigten (direkten) Zugang auf die Datenbank-Dateien, Backups und Exports verhindern! 4 4

5 Wie verschlüsseln? Durch das System Hardware Software (im PC-Bereich z.b. EFS, PointSec, DriveCrypt, TrueCrypt u.v.m.) Durch die Applikation DBMS_OBFUSCATION_TOOLKIT (nur DES, nicht mehr empfohlen) DBMS_CRYPTO (ab 10gR1, AES) Eigenentwicklungen, externe Libraries Durch die Datenbank Oracle Transparent Data Encryption 5 5

6 Transparent Data Encryption Transparent Data Encryption (TDE) ermöglicht die Ver- und Entschlüsselung von sensiblen Daten, so dass sie auch nach dem Zurückschreiben auf die Datenfiles vor unberechtigten Zugriffen geschützt sind Verfügbar ab Oracle 10gR2 Teil der Advanced Security Option (für die Enterprise Edition) Varianten Verschlüsselung einzelner Spalten (ab 10gR2) Verschlüsselung von Tablespaces (ab 11g) 6 6

8 Transparent Data Encryption Master Key Grundlage für die Verschlüsselung ist ein Master Key, der außerhalb der Datenbank in einem Wallet abgelegt wird Der Master Key wird mit folgendem Befehl erstellt ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY {password} {password} = Wallet Passwort Existiert kein Wallet wird es automatisch erstellt Speicherung in $ORACLE_BASE/admin/$ORACLE_SID/wallet Alternativer Speicherort kann in der sqlnet.ora angegeben werden Existiert bereits ein Master Key, wird er überschrieben 8 8

9 Column Encryption Basis sind Encryption Keys, die in- und ausserhalb der Datenbank gespeichert werden Jede Tabelle hat ihren eigenen Encryption Key Die Keys werden mit einem Master Key verschlüsselt und im Data Dictionary abgespeichert (SYS.ENC$) Der Master Key wird in einem Wallet gespeichert Information über verschlüsselte Spalten liefern die Data Dictionary- Views ALL DBA USER_ENCRYPTED_COLUMNS 9 9

10 Column Encryption ENCRYPT Klausel Die Verschlüsselung kann für jede Spalte einzeln definiert werden Unterstützte Verschlüsselungsalgorithmen AES128 AES192 (Default) AES256 3DES168 Quelle: Oracle 10 10

11 Neu in 11g Verschlüsselung von LOBs (Securefiles) Erweiterung von Transparent Data Encryption (TDE)... LOB (y) STORE AS SECUREFILE ([ENCRYPT [SALT] [USING 'algo'] DECRYPT]) LOB Daten sind verschlüsselt in Datenfiles und Memory Buffer Cache Undo Segmente Log Buffer Es wird zwischen BASICFILE (traditionelle LOBs) und SECUREFILE (erweiterte LOBs) unterschieden Zusätzliche Informationen in der Data Dictionary-View DBA ALL USER_LOBS 11 11

13 Tablespace Encryption (2) Mit Oracle 11g können komplette Tablespaces verschlüsselt werden Ist nur beim Anlegen des Tablespaces einschaltbar Alle Daten im Tablespace (einschliesslich Lobs, Indexes,...) sind verschlüsselt ausser BFILES Daten bleiben verschlüsselt bei Dateioperationen wie Joins und Sorts, damit sind sie auch verschlüsselt in UNDO, REDO und TEMP Aber im Gegensatz zu Column Encryption nicht in den Memory- Bereichen!! 13 13

14 Vorgehen Identisch wie bei TDE wird mit folgendem Befehl ein Master-Key in einem Wallet erstellt: ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY {password} Im Wallet muss Autologin eingeschaltet sein $ orapki wallet create -wallet <wallet_location> - auto_login Oder das Wallet muss nach dem Mounten (oder Öffnen) der Datenbank geöffnet werden: ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY {password} 14 14

15 Tablespace erzeugen CREATE TABLESPACE enc_test DATAFILE SIZE 50M ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT) Als Verschüsselungsalgorithmen können 3DES168, AES128, AES192 oder AES256 gewählt werden Informationen zu verschlüsselten Tablespaces liefert die Data Dictionary-View DBA_TABLESPACES (Spalte ENCRYPTED) und die V$-View V$ENCRYPTED_TABLESPACES 15 15

16 TDE und Hardware Security Modules (HSM) (ab 11g) Um die potentiell unsichere Konfiguration mit Wallets zu verbessern, können Hardware Security Module benutzt werden Der Master Encryption Key wird dabei nicht im Wallet gespeichert, sondern im HSM, die Tablespace- bzw. Tabellen-Keys weiterhin in der Datenbank Die Entschlüsslung dieser Keys erfolgt dann innerhalb des HSM, so dass der Master Encryption Key niemals das HSM verlässt Daten werden innerhalb DB ver- und entschlüsselt Leider ist ein 4-Augenprinzip nicht möglich Konfiguration nicht einfach Vor nur für Column Encryption 16 16

17 Transparent Data Encryption & Performance Daten müssen beim Schreiben verschlüsselt, beim Lesen entschlüsselt werden dies benötigt Ressourcen... Tests im Trivadis Technology Center (TTC) ergaben (Tabelle mit 150'000 Zeilen, Tablespace verschlüsselt mit AES256): Operation CPU-Verbrauch ist höher Impact Massen-Insert (zeilenweise) 10% Massen-Deletes/Updates 10% Massen-Insert (IDL) 1% Full-Table Scan 1% Index-Scan <1% Grösse der Datenfiles ändert sich bei Verschlüsselung nicht 17 17

18 Transparent Data Encryption & Tools (1) Export/Import exp exportiert keine verschlüsselten Tabellen (EXP-00107) und keine Daten aus verschlüsselten Tablespaces (EXP-00111) Data Pump Verschlüsselung ist transparent für DataPump Mit dem Parameter ENCRYPTION_PASSWORD kann ein Dumpfile unabhängig von TDE verschlüsselt werden 11g Erweiterung der Verschlüsselungsmöglichkeiten ENCRYPTION = {ALL DATA_ONLY ENCRYPTED_COLUMNS_ONLY METADATA_ONLY NONE} ENCRYPTION_ALGORITHM = { AES128 AES192 AES256 } ENCRYPTION_MODE = { DUAL PASSWORD TRANSPARENT } 18 18

19 Transparent Data Encryption & Tools (2) RMAN Speicherung verschlüsselter Backup Sets möglich Analog DataPump: Transparent Mode, Password Mode, Dual Transportable Tablespaces Nicht unterstützt bei Column Encryption Tablespace Encryption: Zielsystem muss gleiche Endianess haben, Wallet muss zum Zielsystem kopiert werden Ab 11gR1 wird unterstützt DataGuard Logical Standby Database Streams (mit Einschränkungen) SQL*Loader - Direct Path LogMiner 19 19

21 Einschränkungen (1) Column Encryption Datentypen Nicht alle Datentypen können verschlüsselt werden (z.b. keine Objekttypen) Nutzbare Länge ist kleiner als bei unverschlüsselten Spalten (z.b. VARCHAR Bytes anstelle von 4000 Bytes), Storage Overhead im Mittel zwischen 32 und 48 Byte Keine Verschlüsselung von Spalten, die in Foreign Key-Beziehungen verwendet werden Indizes Keine Salt-Verschlüsselung von indizierten Spalten (10g) Nur B*Tree-Indizes Keine Unterstützung von Index Range Scans (11g) Function-Based Indexes (eingeschränkt) 21 21

22 Einschränkungen (2) Tablespace Encryption SYSTEM, SYSAUX, UNDO und TEMP-Tablespace können nicht verschlüsselt werden Verschlüsselungsalgorithmus ist nicht änderbar Kein nachträgliches Verschlüsseln Verschlüsselte Tablespaces sind nicht auf Plattformen mit anderer Endianness migrierbar Kein Re-Keying des Master-Keys und der Tablespace-Keys möglich 22 22

23 Schwächen Nicht alles ist verschlüsselt ALTER TABLE.. MODIFY COLUMN ENCRYPT ALTER TABLE MOVE TABLESPACE <<ENC_TS>> In beiden Fällen verbleiben die unverschlüsselten Original-Daten auf der Platte Daten aus verschlüsselten Tablespaces sind im Memory unverschlüsselt (10g) unverschlüsselte Daten im Redolog, Undo-Tablespace oder TEMP- Tablespace möglich Performance Höherer CPU-Verbrauch durch Verschlüsselung Ggf. andere Zugriffspfade aufgrund von verschlüsselten Index-Spalten (z.b. Bug Select from a View on Encrypted Columns does not make use of indexes) 23 23

24 Risiken Wallet Keine Chance, wenn das Wallet verloren geht oder wenn man das Wallet- Password vergisst! Empfehlungen Wallet getrennt von der Datenbank zusätzlich sichern Wallet außerhalb von $ORACLE_BASE speichern, Rechte beschränken Gewaltenteilung : Oracle-DBA startet die Instanz, Security-DBA öffnet das Wallet Bugs Security-related (z.b. Keys im Klartext) Performance (schlechtere Ausführungspläne) Falsche Ergebnisse!!!! Wer oder was hindert einen bösen DBA, Daten zu verschlüsseln und das Wallet anschließend zu löschen und mitzunehmen? 24 24

26 Transparent Data Encryption Fazit TDE ist geeignet für den Einsatz in sicherheitskritischen Umgebungen. Es hat aber einige Restriktionen, die es abzuwägen gilt Funktionalität in Oracle 11g deutlich verbessert Wissen vermitteln ist der Anfang. Wissen umsetzen das Entscheidende. Verschlüsselung der Backups und Exports nicht vergessen Für Performance-kritische Systeme muss abgewogen werden, ob die zusätzliche Last durch das System getragen werden kann 26 26

27 Weitergehende Informationen Oracle Technet Whitepaper Transparent Data Encryption Best Practices Steve Bobrowski, Transparent Data Encryption: Experience from the Trenches ( Transparent Data Encryption Frequently Asked Questions Metalink Note g R2 New Feature TDE : Transparent Data Encryption Note g New Feature : Transparent Data Encryption at Tablespace Level 27 27

28 Fragen? Baden Basel Bern Brugg Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien 28

29 Danke für Ihre Aufmerksamkeit! Baden Basel Bern Brugg Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien 29