Höhere Sicherheit für SAP-Daten durch Oracle Database Vault und Transparente Datenverschlüsselung

Transkript

1 Höhere Sicherheit für SAP-Daten durch Oracle Database Vault und Transparente Datenverschlüsselung Andreas Becker Oracle Deutschland B.V. & Co. KG Walldorf (Baden) Schlüsselworte: SAP und Oracle, Datenbanksicherheit, Datenschutz, Sensible Daten, Sicherheit Oracle Database Vault, Trennung von Aufgabenbereichen - Separation of Duty SoD, Realm Transparente Datenverschlüsselung, Transparent Data Encryption TDE Verschlüsselte Tablespaces Tablespace Encryption TSE Verschlüsselung des Netzverkehrs, Oracle Network Encryption Advanced Security Option (ASO) SOX, Basel II, HIPAA, Graham-Leach-Bliley, PCI, J-SOX Einleitung Ein SAP-System speichert in der Oracle Datenbank wertvolle und sensible Daten, mit denen verantwortungsbewußt umgegangen werden muß. Nur berechtigte Personen sollen auf sensible- Daten zugreifen können, der Zugriff durch unberechtige Personen soll verhindert werden. Sind die Daten in Ihrem SAP-System sicher vor unberechtigtem Zugang geschützt? Innerhalb der SAP-Anwendung steuern SAP-Benutzerprofile, welcher SAP-Benutzer auf welche SAP- Daten zugreifen darf und schützen so den Zugang. Aber wie sicher sind die Daten, wenn sie in der Datenbank gespeichert sind? Wer kann dort auf die Daten zugreifen und wie? Wie ist der Zugang geschützt? Wie könnte er noch sicherer gemacht werden? Bevor man sich fragt, wie man die Daten in der Datenbank vor unberechtigten Personen besser schützen kann, muß man sich zuerst fragen, wo die Daten liegen und welche Zugangsmöglichkeiten es jeweils gibt. Prinzipiell kann auf folgende Weisen auf Daten in der Datenbank zugegriffen werden: 1. Über das Betriebssystem bzw. Dateisystem direkt auf die Datenbankdateien 2. Über die SQL-Schnittstelle der Datenbank Betrachten wir zunächst 1) über das Betriebssystem: Alle SAP-Anwendungsdaten, die logisch in Tabellen in Tablespaces gespeichert sind, liegen physisch in Blöcken von Datenbankdateien. Jeder Administrator, der Zugang zu den Datenbankdateien hat oder zu Datenbanksicherungen hat, kann sich mit geeigneten Betriebssystemmitteln - z.b. mit einem Hex-Editor- den Inhalt von Datenbankdateien ansehen. Mit der Information, welche Tabelle in welcher Datei in welchem Block ihre Daten speichert, kann man so gezielt auf SAP-Daten zugreifen, ohne sich als Datenbankbenutzer an der Datenbank anzumelden und ohne die entsprechende Datenbankberechtigung zu besitzen.

2 Vor dieser Art von unberechtigtem Datenzugriff schützt Oracle Transparent Data Encryption (TDE). Kommen wir nun zu 2) Zugang über die SQL-Schnittstelle: In der Oracle-Datenbank regeln Datenbankberechtigungen (Datenbankrollen, -privilegien), welcher Benutzer auf welche Daten zugreifen darf. Ein normaler Datenbankbenutzer wie z.b. der Benutzer der SAP-Anwendung (z.b. SAPSR3) kann in der Standardkonfiguration nur auf Daten in seinen eigenen Tabellen zugreifen. Ein hochprivilegierter Datenbankbenutzer wie z.b. ein Datenbank- oder Systemadministrator (SYSDBA, DBA) kann hingegen auch auf Tabellen in einem anderen Benutzerschema zugreifen. Dies wird durch die Datenbankrolle DBA bzw. das Systemprivileg SELECT ANY TABLE ermöglicht. Somit besteht also das Dilemma, daß man auf der einen Seite für die Administration der Datenbank entsprechend hochprivilegierte DBAs benötigt, auf der anderen Seite aber auch den Zugang zu sensiblen SAP-Anwendungsdaten so kontrollieren möchte, daß selbst ein DBA a) gar nicht, b) nicht immer oder c) wenn, dann zumindest nicht unkontrolliert Zugang zu sensiblen Anwendungsdaten haben soll. Mit Oracle Database Vault (DV) hat Oracle daher einen Sicherheitsmechanismus entwickelt, der es auf der einen Seite Datenbankadministratoren weiterhin erlaubt, die Datenbank zu administrieren, auf der anderen Seite aber hochprivilegierten Benutzern den Einblick auf sensible Anwendungsdaten verhindert oder zumindest einschränkt. Im folgenden wird nun zunächst erläutert, wie Sie TDE zur Verschlüsselung von Daten in einem SAP- System einsetzen können. Danach wird der Einsatz von Oracle Database Vault mit SAP beschrieben. Zum Abschluß wird auf die Frage eingegangen, was zu einem Sicherheitskonzept gehören sollte, und wie ein solches Konzept umgesetzt werden kann. Schutz von SAP-Daten im Dateisystem mit TDE Oracle s Transparente Datenverschlüsselung (TDE) kann mit SAP ab Oracle Release 10.2 eingesetzt werden. Alle Details dazu sind im SAP-Hinweis beschrieben. TDE gibt es in zwei verschiedenen Ausprägungen: in Release 10.2 können Daten auf Tabellenspaltenebene verschlüsselt werden ( TDE Column Encryption ), ab Release 11.2 ganze Tablespaces ( TDE Tablespace Encryption TSE ). Das Verschlüsseln kompletter Tablespaces bietet gegenüber der Verschlüsselung von Spalten einige Vorteile: zum einen entfällt die schwierig zu beantwortende Frage, in welchen Spalten welcher SAP- Tabellen denn sensible Daten liegen, die zu verschlüsseln wären. Außerdem gibt es bei der spaltenbasierten Verschlüsselung einige technische Einschränkungen, die bei TSE komplett entfallen. Daher dürfte beim Einsatz von TDE ab Release 11.2 die Wahl wohl meistens auf die Tablespaceverschlüsselung (TSE) fallen. Im folgenden betrachten wir daher nur TSE. Um TDE zu verwenden, muß zunächst ein Hauptschlüssel (Masterkey) erzeugt werden. Dieser wird in einem Encryption Wallet, das außerhalb der Datenbank liegt, gespeichert. Der Speicherort für das Encryption Wallet wird in der sqlnet.ora angegeben: ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA =

3 (DIRECTORY = <wallet_location> ))) Damit das Encryption Wallet später auch von BRBACKUP automatisch mitgesichert wird, muß als <wallet_location> $ORACLE_HOME/dbs (Unix) bzw. ORACLE_HOME/DATABASE (Windows) spezifiziert sein. Ob das richtige Verzeichnis angegeben ist, kann mit V$ENCRYPTION_WALLET überprüft werden. Nachdem <wallet_location> in der sqlnet.ora konfiguriert ist, kann das Encryption Wallet mit dem Masterkey erzeugt werden: SQL> alter system set encryption key identified by "<wallet_password>"; Als Walletpaßwort <wallet_password> sollte logischerweise ein möglichst sicheres Paßwort gewählt werden. Auf der anderen Seite aber muß auch gewährleistet sein, daß dieses Paßwort nicht vergessen werden oder verloren gehen kann. Denn ohne dieses Paßwort kann das Encryption Wallet nicht geöffnet und damit nicht mehr auf den darin gespeicherten Masterkey zugegriffen werden und ohne den Master Key nicht auf verschlüsselte Daten. Gehen wir nun beispielsweise davon aus, daß ein bestimmter SAP-Datentablespace verschlüsselt werden soll. Dazu legt man jetzt, da der Masterkey erzeugt worden ist, zunächst einen neuen, verschlüsselten Tablespace an (mit BRSPACE): OS> brspace -f tscreate -encryption yes BRSPACE legt nun einen verschlüsselten Tablespace an: SQL> create tablespace <tablespace> extent management local autoallocate segment space management auto encryption default storage (encrypt) datafile '<path>' size <size>; In diesen neu angelegten verschlüsselten Tablespace überträgt man nun alle Tabellen und Indizes des Ausgangstablespaces. Danach kann man den alten, leeren Tablespace löschen. Dabei ist zu beachten, daß die Datendateien des alten Tablespace noch die Daten in unverschlüsselter Form (Klartext) enthalten. Beim Löschen der Dateien im Dateisystem werden die Blöcke nicht sofort überschrieben und bleiben mit Betriebssystemmitteln noch als sog. Ghost-Copy bzw. Klartextkopien lesbar. Es wird daher empfohlen, die alten Datendateien auf eine sichere Weise zu überschreiben. Durch die Verschlüsselung mit TDE sind sensible Anwendungsdaten im Dateisystem sicher vor dem Zugriff durch unberechtigte Personen geschützt. Der Schutz erstreckt sich sowohl auf Datenbankdateien der Datentablespaces, auf temporary Tablespaces (PSAPTEMP), Undo-Tablespaces (PSAPUNDO) sowie Redo- und Archivelogs. Innerhalb der Datenbank können Benutzer auf verschlüsselte Daten zugreifen, wenn das Encryption Wallet mit dem Masterkey geöffnet ist. Die Ver- und Entschlüsselung erfolgt dann automatisch durch die Datenbank und transparent für Benutzer und Anwendung. TDE schützt sensible Anwendungsdaten nicht vor hochprivilegierten Datenbankbenutzern!

4 Abb. 1: Transparente Datenverschlüsselung (TDE) Die wichtigsten Eigenschaften und Voraussetzungen von TDE sind: 1. Der Einsatz von TDE ist für die SAP-Anwendung vollkommen transparent. 2. Der zusätzliche Administrationsaufwand für den DBA ist relativ gering. 3. Die Verwaltung der beteiligten Tabellen- oder Tablespace-Schlüssel erfolgt automatisch. 4. Die gesamte Funktionalität zur Administration von TDE ist in die SAP BR*Tools integriert (BRSPACE-Funktion "-f mdencr", SAP Hinweise , ) 5. Die Sicherung des Encryption Wallet mit dem Masterkey muß gewährleistet sein. Dies wird von den SAP BR*Tools (BRBACKUP) automatisch sichergestellt. 6. Für das Encryption Wallet muß ein sicheres Wallet Paßwort gewählt werden. 7. Der durchschnittliche CPU-Overhead bei TSE liegt im einstelligen Prozentbereich (ca. 5-8%) 8. Für den Einsatz von TDE wird die Lizenz für die Advanced Security Option (ASO) benötigt. Verschlüsseln von Export Dumps und RMAN-Sicherungen Nicht nur Datenbankdateien können sensible SAP-Daten enthalten, sondern auch Datenbanksicherungen und Exportdateien. Daher sollten auch die Inhalte dieser Dateien vor unberechtigtem Zugriff geschützt werden. Die Verschlüsselung kann mit TDE durchgeführt werden, wenn TDE in der Datenbank konfiguriert ist, oder passwortbasierend, wenn kein TDE konfiguriert ist. Nur durch konsequentes Verschlüsseln aller Datenbankdateien, aller Datensicherungen und aller Export Dumps werden Klartextkopien von sensiblen Anwendungsdaten im Dateisystem im Laufe der Zeit eliminiert.

5 Details zur Verschlüsselung von Export Dumps mit BRSPACE sind in SAP Hinweis beschrieben. Informationen zum Verschlüsseln von RMAN-Sicherungen mit BRBACKUP sind in SAP Hinweis enthalten. Schutz von SAP-Daten bei der Übertragung im Netz Bei den eingangs erwähnten Möglichkeiten des Zugangs zu Daten in der Datenbank mit Betriebssystemmitteln auf Datenbankdateien bzw. über die SQL-Schnittstelle wurde eine Möglichkeit noch nicht angesprochen, nämlich folgende: die Übertragung von Daten im Netz. Auch wenn normalerweise davon ausgegangen wird, daß sich Oracle Datenbank-Server und SAP- Applikations-Server in einem sicheren Firmennetz befinden, wäre der Schutz vor unberechtigtem Zugang nicht vollständig, wenn man auf der einen Seite sensible Anwendungsdaten im Dateisystem verschüsselt, sie aber im Klartext durch das Netzwerk übertragen würde. Um auch hier vor Überraschungen sicher zu sein, kann bzw. sollte in der sqlnet.ora Oracle Netzwerkverschlüsselung aktiviert werden: SQLNET.ENCRYPTION_SERVER = REQUIRED SQLNET.ENCRYPTION_CLIENT = REQUIRED SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED SQLNET.CRYPTO_CHECKSUM_CLIENT = REQUIRED Voraussetzung für dieses Feature ist eine ASO-Lizenz. Wer sich für den Einsatz dieses Feature mit SAP interessiert, findet in SAP-Hinweis weitere Informationen dazu. Schutz von SAP-Daten vor hochprivilegierten Datenbankbenutzern mit Database Vault Kommen wir nun zu Oracle Database Vault: wie eingangs erwähnt, können hochprivilegierte Datenbankbenutzer (DBA, SYSDBA) auch auf Daten in Tabellen anderer Benutzer zugreifen. Dies widerspricht jedoch Bestimmungen und Richtlinien, die verlangen, sensible Daten vor unberechtigten Zugriff zu schützen. Oracle Database Vault implementiert nun, über das Konzept der in der Datenbank existierenden Rollen und Privilegien hinausgehend, ein Konzept, mit dem der Zugriff auf Daten durch hochprivilegierte Benutzer eingeschränkt, kontrolliert und verhindert werden kann. Die Installation von Database Vault erfolgt in Release 11.2 über den Database Configuration Assistant (DBCA). Bei dieser Installation werden die beiden Datenbankbenutzer SECADMIN und SECACCTMGR angelegt. Die Aufgabenbereiche sind damit wie folgt neu aufgeteilt: 1. Datenbank-Administrator: DBA/SYSDBA 2. Security-Administrator: SECADMIN 3. Benutzerverwaltung (Account Administrator): SECACCTMGR Bei einem SAP-System gibt es typischerweise einen ABAP-Stack und einen Java-Stack ( Double- Stack ). Der ABAP-Stack ist in der Datenbank über einen Datenbankbenutzer repräsentiert (Default: SAPSR3), der Java-Stack sofern vorhanden ebenso (Default: SAPSR3DB). Um nun die SAP-Daten in den Tabellen des ABAP-Stacks zu schützen, wird ein Schutzbereich, ein sog. realm definiert, der alle Objekte (Tabellen, Indizes,..) des ABAP-Stacks umfaßt. Analog wird ein Realm für den Java- Stack definiert.

6 Berechtigt für den Zugriff auf Objekte des ABAP-Realms ist der Datenbankbenutzer SAPSR3, für den Java-Stack analog der Datenbankbenutzer SAPSR3DB. Versucht nun ein Datenbankadministrator, der mit der DBA-Rolle und dem SELECT ANY TABLE Privileg ausgestattet ist, auf Daten des ABAP- Stacks zuzugreifen, so erhält er folgende Fehlermeldung: SQL> select * from sapsr3.t100; select * from sapsr3.t100 * ERROR at line 1: ORA-01031: insufficient privileges SQL> Abb. 2: SAP mit Oracle Database Vault (DV) Alle administrativen Aufgaben des DBAs, bei denen nicht auf realm-geschützte SAP-Daten zugegriffen wird, können unverändert durchgeführt werden. Aufgaben, die in in irgendeiner Weise versuchen, diese realm-geschützten Daten zu lesen oder zu ändern, werden durch Database Vault blockiert (SELECT, INSERT, UPDATE, DELETE, export/import). Der Security-Administrator (SECADMIN) hat die Möglichkeit, in bestimmten Situationen (z.b. im Support-Fall oder in einer Notsituation) den Realm oder Database Vault zu deaktivieren oder weitere Benutzer als berechtigt für den Realm zu authorisieren, wenn es erforderlich ist. Die Administration von Database Vault erfolgt über den Database Vault Administrator (DVA), eine graphische Benutzeroberfläche ähnlich wie Oracle Enterprise Manager. Für die SAP-Standard- Database-Vault-Konfiguration gibt es entsprechende Skripte, die auf dem DVSYS.DBMS_MACADM

7 PL/SQL Package basieren und eine automatische Konfiguration ermöglichen. Bei der SAP-Standard- Konfiguration ist inbesondere darauf geachtet worden, daß die Oracle-Datenbank-Administration über die SAP BR*Tools, die Standard-Administrationswerkzeuge von SAP für die Oracle Datenbank, (bis auf wenige Ausnahmen) unverändert funktioniert. Oracle Database Vault (DV) ist eine lizenzpflichtige Datenbankoption, deren Einsatz mit SAP für Oracle Releases 10.2 und 11.2 freigegeben ist. Alle Details für den Einsatz von DV mit SAP (Installation, Konfiguration, Voraussetzungen, usw.) findet man über den SAP Hinweis Zusammenfassung Mit Oracle Transparent Data Encryption (TDE) werden Daten in der Datenbank sicher verschlüsselt und damit vor dem unberechtigten Zugriff über das Dateisystem geschützt. Oracle Database Vault schützt SAP-Anwendungsdaten in der Datenbank vor dem unberechtigten Zugang durch hochprivilegierte Datenbankbenutzer. Oracle Netzwerkverschlüsselung sichert sensible Daten bei der Übertragung im Netz vor dem Mitlesen durch unauthorisierte Personen. Auch wenn es eine Vielzahl von Features gibt, die man zum Bereich Oracle Security dazuzählt, so gehört doch etwas mehr dazu, als diese Features einfach nur einzuschalten. Es gehört ein umfassendes Sicherheitskonzept dazu, welche Personen welche Aufgaben durchführen, welche Rechte und Privilegien sie dazu benötigten, welche Werkzeuge sie dazu einsetzen, usw. Ein solches Konzept kann, wenn es neu erstellt ist, sicher nicht von heute auf morgen vollständig umgesetzt werden. Ein solches Konzept wird meistens auch organisatorische Änderungen erfordern, beispielsweise die Definition neuer Aufgabenbereiche (Stichwort Separation of Duty ) wie z.b. den Aufgabenbereich eines Security Administrators, der für die Einführung und Überwachung von solchen Vorgehensweisen und Regeln zuständig ist, die die Sicherheit erhöhen und den Schutz von Daten verbessern sollen. Dazu gehört u.u. auch die strikte Umsetzung eines Kernprinzips für den sicheren Datenbankbetrieb, nämlich das Prinzip der Minimalausstattung mit Berechtigungen ( principle of least privilege ). Neben dem Verhindern von unberechtigtem Zugang zu Daten (TDE, DV) muß man sich aber auch Gedanken über die Überwachung machen ( Auditing ). Die Schwierigkeit hier liegt oft darin, nicht zu viele Audit-Daten zu generieren, damit man die relevanten Audit-Daten nicht in der Flut der Daten übersieht. Neben Security-Features wie z.b. Database Vault oder Transparent Data Encryption sollte man aber immer noch die einfachen Tips beherzigen wie beispielsweise keine Standardpaßworte oder einfachen Paßworte zu verwenden, Paßworte regelmäßig zu ändern, personalisierte Benutzer zu verwenden und schon bei der betrieblichen Organisation auf Sicherheit achten. Ein Sicherheitskonzept ist in einem permanenten Prozeß immer wieder zu überprüfen, zu hinterfragen und auf diese Weise im Laufe der Zeit zu verbessern (Revision). Oracle Technology Network: Kontaktadresse: Andreas Becker Oracle Deutschland B.V. & Co. KG Altrottstraße 31 D Walldorf (Baden) Telefon: +49 (0) andreas.becker@oracle.com Internet: