Anhang: Fragenkatalog

Transkript

1 6 Anhang: Fragenkatalog Wenn ich Datenbanken auf Sicherheit überprüfe, durchlaufen solche Projekte immer zwei wesentliche Phasen: 1. Glaube: Ich führe ein Interview mit den Teilnehmern durch. In der Regel sind die Interviewteilnehmer Datenbankadministratoren. In diesem Interview möchte ich das große Bild zu der Datenbank aufnehmen. Ich erfrage also all das, was man nicht aus der Datenbank mittels Skripts herausfinden kann. Ich bezeichne diesen Schritt als Aufnahme des Wissens zu der Datenbank, das der Interviewteilnehmer zu wissen glaubt. 2. Wissen: In diesem Schritt konzentriere ist mich auf die Realität. Ich erfasse das echte Wissen zu der Datenbank. Hierfür nutze ich die Skripts, Konfigurationsdateien und Log-Dateien (wie beispielsweise listener.log), die mir zur Verfügung stehen. Dieses Wissen lässt sich nicht verfälschen, da es den tatsächlichen Zustand der Datenbank aufweist. Mit diesen zwei Schritten erfasst man einen fast vollständigen Blick auf die zu untersuchende Datenbank. Die Antworten auf die Fragen aus dem Interview bestimmen das erste gute oder schlechte Gefühl im Umgang mit der Datenbanksicherheit. Hinzu kommt, dass man Gesagtes durch die Erkenntnisse, welche die Skripts generieren, überprüfen kann. Somit können Aussagen tatsächlich daraufhin überprüft werden, ob diese auch so in der Realität umgesetzt sind. Einige Beispiele zur Überprüfung der Aussagen werden nachfolgend aufgelistet: Das Backup-Konzept definiert, dass die Backups 14 Tage aufbewahrt werden. Realität: RMAN wurde so eingestellt, dass 14 Backups aufbewahrt werden. Dies bedeutet, man könnte auch an einem Tag 14 Backups durchführen und hätte somit alle Backups der letzten 13 Tage verloren. Man hätte für eine Aufbewahrungsfrist von 14 Tagen eine Retention-Policy aufsetzen sollen: CONFIGURE RETENTION POLICY...OF 14 DAYS; External Procedure Calls sind nicht erlaubt. Realität: Der Listener wurde aber entsprechend konfiguriert, so dass dies doch möglich ist. Es existiert eine Passwort-Policy. Realität: In der Datenbank wurde diese aber nicht über Benutzer-Profile umgesetzt.

2 470 6 Anhang: Fragenkatalog Ein umfangreicher Zugriffsschutz auf Basis eines Rollenkonzepts wurde implementiert. Realität: Wichtige Zugriffsberechtigungen auf die Anwendungsobjekte wurden an PUBLIC zugewiesen. Also der Zugriffsschutz wurde ausgehebelt. Darüber hinaus ist es auch notwendig, die verschiedenen Konzepte zu verstehen, die für die Umsetzung von Schutzbedarfen implementiert sind. Oft ist es tatsächlich so, dass mittels einfacher Datenbankkonzepte diese Implementierungen auch umgesetzt werden könnten und man somit die Komplexität erheblich verringern würde. Zwei Beispiele sind: IP-Filter mittels Firewall: Lässt sich auch im Listener der Datenbank einstellen. Entweder kann man TCP.VALIDNODE_CHECKING einstellen oder man nutzt den Connection Manager (Bestandteil einer Datenbank-Enterprise-Edition). Aus Performancegründen werden Daten aus Tabellen extrahiert und eine Tabelle in ein anderes Schema verschoben: Dies erhöht die Komplexität im Zugriffsschutz und in der Verwaltung. Die Oracle-Datenbank kann eine transparente Partitionierung der Daten in der Tabelle vornehmen und somit zu einer guten Performance beitragen und sogar transparent weniger genutzte Daten auf billigere Storages verschieben (Information-Lifecycle-Management-Konzept). Nachfolgend finden Sie Fragen, die ich regelmäßig in meinen Überprüfungsprojekten von Oracle-Datenbanken nutze. Der Fragenkatalog stellt nur einen roten Faden dar. Es besteht also kein Anspruch auf Vollständigkeit. Oft entscheiden die Situationen im Interview, ob man zu einem bestimmten Thema mehr oder weniger wissen will. Sie sollten also keinesfalls einfach nur stur sämtliche Fragen der Reihe nach abarbeiten. Denken Sie immer daran, welche Informationen notwendig sind, um ein vollständiges Bild aufzunehmen, welches für die Sicherheitsüberprüfung notwendig ist. Das Ziel ist, einen guten Eindruck über die Anwendungslandschaft zu erhalten, in der die zu untersuchende Datenbank eingebettet ist, inklusive der Prozesse und der externen Einflüsse wie zu beachtende Gesetze und anderes. Hierfür habe ich insgesamt zwölf Bereiche mit Fragen vorbereitet, die ich im Interview nutze, um somit ein noch besseres Verständnis über die zu untersuchende Datenbank zu bekommen. Für die Durchführung des Interviews nehme ich mir zwei bis drei Stunden Zeit und stelle dem Betreiber der Datenbank die folgenden Fragen. 6.1 Businessbeitrag der IT-Abteilung Auch für die Sicherheit ist es wichtig, die Geschäftsanforderungen zu kennen. Ich erlebe oft, dass IT-Abteilungen immer noch als Budgetnehmer fungieren und wenig zum Geschäfts erfolg beitragen. Betrachtet man das Kerngeschäft aber genauer, lässt sich häufig feststellen, dass viele Unternehmungen ohne die IT-Abteilung gar nicht geschäftsfähig werden. Diese Tatsache und auch die daraus resultierenden Anforderungen wie Verfügbarkeit, Zuverlässigkeit etc. müssen bekannt sein.

3 6.2 Welche Konzepte existieren und sind implementiert? Daher nutze ich diesen Abschnitt, um den Businessbeitrag der IT-Abteilung abzufragen. Die übergeordnete Aufgabe des Interviewteilnehmers lautet deshalb: Erklären Sie kurz den Beitrag Ihrer IT-Abteilung zum Business und die Wichtigkeit der IT-Sicherheit. Tabelle 6.1 Fragenkatalog Businessbeitrag der IT-Abteilung Fragen Wie würden Sie die IT-Abhängigkeit der Unternehmung/Behörde beschreiben? Wie wichtig ist die IT-Sicherheit für Ihr Unternehmen? Wird die IT-Sicherheit vom Vorstand budgetiert? Ist die IT-Abteilung als Profitcenter aufgestellt? Werden also Services auf Basis von Verbrauch und Nutzung abgerechnet (Service Level Agreements)? Gibt es einen Sicherheitsbeauftragten und an wen berichtet er? Warum wollen Sie eine Sicherheitsüberprüfung der Datenbank durchführen? Wer hat die Durchführung beauftragt? Was versprechen Sie sich davon? Was machen Sie mit dem Ergebnis? Wer entscheidet, was mit dem Ergebnis passiert? Welches sind die potenziellen Sicherheitsbedrohungen in Ihrer derzeitigen Systemlandschaft? Haben Sie bereits eine Analyse des Sicherheitsrisikos für Ihr Unternehmen durchgeführt? 6.2 Welche Konzepte existieren und sind implementiert? Habe ich das Business sowie die Erwartungen verstanden, möchte ich die externen Einflüsse kennenlernen. Dazu gehören Unternehmenskonzepte, die existieren und umgesetzt werden müssen, und auch gesetzliche Regularien, die erfüllt werden müssen, um compliant zu sein. Die Antworten aus diesem Bereich kann man mit den Erkenntnissen aus Skripts vergleichen, um so festzustellen, ob diese in der Realität wirklich umgesetzt sind. Im Folgenden werden Fragen vorgestellt, mit denen sich die Konzepte überprüfen lassen, die für einen sicheren Datenbankbetrieb als vorhanden vorausgesetzt werden könnten: 471

4 472 6 Anhang: Fragenkatalog Tabelle 6.2 Fragenkatalog Konzepte Fragen Existiert ein übergreifendes Sicherheitskonzept oder eine Sammlung von Policies entsprechend ISMS (ISO 27001)? Existieren spezielle dokumentierte Sicherheitsanforderungen für Datenbanken? Wurde eine Datenklassifikation definiert? Falls ja, beschreiben Sie bitte die existierende Datenklassifikation. Wie wird die Einhaltung von implementierten Konzepten kontrolliert? Mittels interner Revisionen oder Audit? Oder nutzen Sie bereits Tools, die die implementierte Sicherheit überprüfen? Besteht ein (Security) Patching-Konzept für die Datenbank (also regelmäßiges Installieren von Critical Patch Updates (CPUs))? Besteht ein Backup & Recovery- sowie ein Disaster-Recovery-Konzept? Wurde eine Hochverfügbarkeit implementiert (z. B. mit RAC oder Data Guard)? Warum wurde die Hochverfügbarkeit implementiert, d. h., welche Anforderungen existieren? Maximale Recovery-Zeit (hoch, mittel, gering)? Umgang mit Passwörtern? Existiert ein Passwortmanagement? Wird eine Mindestsicherheit für Datenbank, Server, Client etc. aufgesetzt? Härtung? Besteht ein Test-Konzept? Ein Testkonzept, um die Funktionalität nach Patch-Installationen oder neuen Anwendungsreleases zu testen? Existiert eine Art allgemeiner Smoke-Test? Sozusagen ein einfacher Test, der schnell anzeigt, dass die wesentlichen Funktionen der Anwendungen noch funktionieren. Diese Art von Tests wird in der Regel bei Webshops und Webanwendungen durchgeführt. Werden Daten aus der Produktionsumgebung in Testumgebungen überspielt? Falls ja, werden diese auch maskiert? Existiert ein Firewall-Konzept bzw. Zugriffskontrolle? Befindet sich die Datenbank in einem geschützten Bereich (Netzwerk)? Ist eine Rechenzentrumsicherheit (SAS70) implementiert? Gibt es weitere Konzepte, die für diese Sicherheitsüberprüfung wichtig sind? Welche Regularien müssen erfüllt sein? Wurde die IT-Abteilung bzw. der Datenbankbetrieb an externe Firmen übertragen (Outsourcing)? Wenn ja, werden besondere Richtlinien wie Datenschutz (d. h. die externe Firma (Outsourcer) regelmäßig überprüft, ob der vereinbarte Datenschutz eingehalten wird? Wie kontrollieren Sie die externe Firma (Outsourcer) auf Einhaltung des Datenschutzes (BSDG 11 Auftragsdatenverarbeitung)? Wie viele Oracle-Datenbank-Instanzen/Server werden in Ihrem Unternehmen betrieben? Wie viele davon sind schutzbedürftig? Soll die zu untersuchende Datenbank als Maßstab für alle gelten? Wie ist die zu untersuchende Datenbank in die unternehmensübergreifende Sicherheit eingebettet? Erzwingen Sie vorhandene Sicherheitsrichtlinien? Wenn ja, auf welche Weise? Falls nein, gehen Sie davon aus, dass Ihre Sicherheitsrichtlinien organisatorisch umgesetzt sind? Falls ja, wie kontrollieren Sie die Einhaltung dieser organisatorischen Maßnahmen?

5 6.3 Welche Daten befinden sich in der zu untersuchenden Datenbank? 6.3 W elche Daten befinden sich in der zu untersuchenden Datenbank? Entsprechend der Wichtigkeit der Daten ist auch ein passender Schutzbedarf zu implementieren. Wenn also der Datenbankbetreiber beispielsweise sagt, dass die Daten unternehmenskritisch sind und nicht in falsche Hände gelangen dürfen und Sie anhand der Skripts feststellen, dass Standardpasswörter genutzt werden, Beispielaccounts existieren und jeder Anwendungsuser die Rolle eines Datenbankadministrators hat, stimmt der Schutzbedarf nicht mit den Anforderungen überein und man sollte nach der Sicherheitsüberprüfung sofort Maßnahmen definieren und umsetzen. Daher ist es sehr wichtig zu verstehen, welche Daten in der Datenbank verarbeitet werden und wie die Wichtigkeit der Daten eingeschätzt wird. Tabelle 6.3 Fragenkatalog Daten Fragen Werden Daten klassifiziert? Falls ja, welche klassifizierten Daten befinden sich in der Datenbank? Falls nein, beschreiben Sie, welche Daten in der Datenbank verwaltet werden. Gibt es definierte Schutzmaßnahmen, die Sie für Ihre klassifizierten Daten anwenden müssen? Wie würden Sie den Schutzbedarf der Datenbank einstufen (gering, mittel, hoch)? Wie gelangen die Daten in die Datenbank? Zum Beispiel über eine Benutzerschnittstelle, Batchjobs, Schnittstellen, andere Systeme Hilfreich ist die Anfertigung einer Architekturskizze. Was geschieht, wenn die Daten unerlaubterweise manipuliert werden? Welche Auswirkung hat das auf das Business? Gibt es Datenintegrationspunkte zu anderen Datenbanken und/oder Anwendungen (in der Regel per Datenbank-Links)? Was verstehen Sie unter einem unerlaubten Zugriff? Gab es schon einmal einen unerlaubten Zugriff auf Ihre Daten? Wie wurde dieser festgestellt? Wie können Sie überhaupt feststellen, ob unerlaubte Zugriffe erfolgen? Von welcher Anwendung wird die zu untersuchende Datenbank genutzt? Was macht diese Anwendung (kurze Beschreibung)? 473

6 474 6 Anhang: Fragenkatalog 6.4 W ie sehen die Architektur und das Deployment aus? Für das große Bild ist es wichtig zu verstehen, wie die Datenbank in der Systemlandschaft eingebettet ist. Dieses Verständnis soll dieser Bereich vermitteln. Am besten fertigt man gemeinsam mit dem Interviewteilnehmer eine Skizze der Architektur an. In welcher Umgebung ist die Datenbank eingebettet? Gibt es verschiedene Umgebungen (wie Entwicklung, Test und Produktion) mit dieser Datenbank? Tabelle 6.4 Fragenkatalog Architektur und Deployment Fragen Welche Datenbankversion, Betriebssystemversion, Hardware ist für die zu untersuchende Datenbank im Einsatz? Wo befinden sich die Software-Binärdateien (Installationsdateien) und wo die Datenbankdateien (lokale Festplatte oder NAS/SAN)? Welches Dateisystem nutzt die Datenbank? Ist ASM (Automatic Storage Management) im Einsatz? Ist ACSF (ASM Cluster File System) im Einsatz? Welchen Umfang hat die Datenbank in MB, GB oder TB? Werden Daten verteilt (Replikation)? Existieren Integrationspunkte? Sind Datenbank-Links im Einsatz? Beschreiben Sie die Deployment-Umgebung? Testumgebung? Integrationsumgebung? Abnahmeumgebung? Produktivumgebung? Welche Administrationsumgebung ist im Einsatz (Grid Control, Cloud Control, Enterprise- Manager, Alert.log-Einbindung)? Für welche Zwecke führen Sie Backups durch (Aufbau von Tests, Datensicherung, Standby etc.)? Beschreiben Sie die verwendete Backup-Methode (Full, Incremental, Both, Snapshot by Storage). Nutzen Sie RMAN oder erstellen Sie nur Schema-Export-Dumps? Wie oft wird ein Backup durchgeführt? Werden Backups durch Skripts/Tools automatisiert? Wenn ja, welche Skripts/Tools werden verwendet? Wie stellen Sie sicher, dass genügend Platz im Bereich der Ablage für Archiv-Logs frei ist? Nutzen Sie die FRA (Flash Recovery Area)? Wie oft wird überprüft, dass die Backups in Ordnung sind (Recovery-Test)? Setzen Sie Oracle-Techniken zur Verfügbarkeitssteigerung ein (Partitionierung, Failover, RAC, Data Guard)?

7 6.5 Wie installieren Sie Datenbanken? Fragen Werden Daten archiviert (online, offline)? Größe der Redo-Log-Dateien? Wie viele Redo-Log-Gruppen wurden eingerichtet? Wie viele Member existieren innerhalb der Redo-Log-Gruppen? Nutzen Sie zusätzliche externe Prozesse mit dieser Datenbank (EXTProc, Libraries, Extensible Framework etc.)? 6.5 Wie installieren Sie Datenbanken? Gerade für Betreiber, die oft neue Datenbanken zur Verfügung stellen müssen, ist es wichtig, über geeignete Konzepte zu verfügen, die eine automatisierte Provisionierung von gehärteten Datenbanken erlauben. Daher ist es wichtig zu verstehen, wie der Datenbankbetreiber seine Datenbanken installiert. Oracle liefert hier hervorragende automatisierte Features, die mit dem EnterpriseManager genutzt werden können. Dieser Abschnitt gibt einen Hinweis darauf, ob die geforderte Sicherheit tatsächlich in Prozesse eingebettet ist und von Anfang an in die Datenbanken implementiert wird. Nachfolgend einige Fragen zum Installationsvorgang. Tabelle 6.5 Fragenkatalog Installation Fragen Wie oft installieren Sie neue Datenbankinstanzen? Oder fertigen Sie nur Upgrades an und klonen die produktive Datenbank für Testumgebungen? Beschreiben Sie das Vorgehen einer Oracle-Datenbank-Installation: Vorgaben aus der Anwendungsentwicklung Dateisysteme anlegen Oracle-User einrichten Kernel-Parameter ändern Oracle-Software installieren Skripts erstellen und anpassen Skript ausführen Net Service manuell konfigurieren Bootskript anpassen Wird der Oracle Installation Guide genutzt? Oder haben Sie ein eigenes Vorgehen (Install per Clone, Gold Images, Reference Template etc.)? 475

8 476 6 Anhang: Fragenkatalog Tabelle 6.5 Fragenkatalog Installation (Fortsetzung) Fragen Wie sind die UNIX-Accounts organisiert? Name des Oracle-Software-Eigentümers auf dem UNIX-System? Welche UNIX-Gruppen nutzen Sie? Verfügen die Administratoren über personalisierte UNIX-Accounts und gehen per sudo oder Powerbroker auf den Oracle-Account? Welche System-Accounts haben Zugriff auf die Oracle-Gruppen? $ grep dba: /etc/group $grep oinstall: /etc/group $grep oper: /etc/group Werden bekannte sicherheitsrelevante init.ora-parameter eingestellt? Wird regelmäßig die Alert.log-Datei überprüft? Welche Optionen und Funktionen wie Direct NFS, XML DB werden eingeschaltet und welche nicht? Wann wurde der letzte Patchset, CPU installiert? Wann wird der nächste PSU/CPU eingespielt? Wurde eine sichere (Mindest-)Konfiguration der Datenbank entsprechend den Anforderungen vorgenommen? Wenn ja, welche? Wenn nein, wurde lediglich eine Standardinstallation durchgeführt, mehr nicht? Existiert ein Logbuch für durchgeführte Änderungen oder auf welche andere Weise dokumentieren Sie Änderungen? 6.6 Wer greift auf die Datenbank zu? Ein ganz wichtiger Aspekt ist die Kenntnis, wer auf die Datenbank zugreift. Oft greifen viel mehr Anwender auf die Datenbank zu als der Datenbetreiber glaubt. Wichtig in diesem Bereich ist die Kenntnis, dass es für verschiedene Benutzergruppen verschiedene Schutzbedarfe zu implementieren gilt. Besteht die Kenntnis über die verschiedenen Benutzergruppen nicht, kann man unter Umständen gar keine oder die falsche Sicherheit implementieren. Ebenfalls wichtig ist das Verständnis, dass die Oracle-Datenbank durchaus für verschiedene Benutzergruppen verschiedene Schutzbedarfe implementieren kann. Ist also bekannt, welche Benutzergruppen existieren? Ist das Wissen über alle Zugriffe bekannt oder sieht man während der Überprüfungen ganz andere Zustände? Welche Zugriffsarten existieren in der zu untersuchenden Datenbank?

9 6.6 Wer greift auf die Datenbank zu? Tabelle 6.6 Fragenkatalog Zugriff auf die Datenbank Fragen Wer greift auf die Datenbank zu? Verschiedene Benutzergruppen wie Endbenutzer Anwendungs-User (von der Anwendung genutzt) Anwendungs-Owner (die Besitzer der Anwendungsobjekte sind auch manchmal gleichzeitig die Anwendungs-Owner) Batchjobs Schnittstellen Datenbank-Links (andere Datenbanken) Administratoren/Datenbankadministratoren Entwickler Gibt es eine Syntax für Benutzernamen wie MUELLER_ADM (Nachname und ADM als AdminKürzel)? Wie unterscheiden Sie die verschiedenen Benutzergruppen (z.b. Profile)? Gibt es auch eine Unterscheidung im Zugriffsschutz (besondere Schutzbedarfe wie Sicherheitszonen, Protokollierung etc.)? Gibt es einen Zugriff aus dem Internet auf die Datenbank (auch über Anwendungen, d. h., der Enduser kommt über das Internet)? (Diese Tatsache kann man auch gut mit dem listener.log überprüfen.) Gibt es einen besonderen Schutz, um die Internetzugriffe besonders zu schützen? Haben Sie zusätzliche Firewalls im Einsatz, um die Datenbank zu schützen? Warum und wie genau ist dieser besondere Schutz implementiert? Wo genau befindet sich die Datenbank (internes Netzwerk, DMZ, abgesicherter Bereich...)? Wird die Kommunikation zur Datenbank abgesichert (software- oder hardware-technisch über ASO oder IPSec) oder setzen Sie eine besondere Integritätsmaßnahme? Die Netzwerkverschlüsselung kann für jede Oracle-Datenbank-Edition ohne zusätzliche Kosten aktiviert werden. Wird der Zugriff auf die Datenbank protokolliert? Existiert ein System zur Post-Intrusion-Detection? Kann theoretisch jeder Mitarbeiter auf die Datenbank zugreifen, sofern er die Credential zum TNS (Transparent Network Substrate) kennt? Sind unerlaubte Zugriffe möglich? Welche Authentisierungsverfahren nutzen Sie? Wie wird die Autorisierung in der Datenbank realisiert? Jeder Benutzer bekommt die Berechtigung, die er benötigt, um seine Aufgaben zu erfüllen, und nicht mehr (Least-Privilege-Konzept)? Oder wird eher ein ANY-Grant verwendet, um die Autorisierung zu vereinfachen? 477

10 478 6 Anhang: Fragenkatalog Tabelle 6.6 Fragenkatalog Zugriff auf die Datenbank (Fortsetzung) Fragen Wie viele Endbenutzer greifen auf die Datenbank zu? Wie viele Nutzer existieren in der Datenbank? Wie viele Endbenutzer greifen über die Anwendung zu? Wo befindet sich die Benutzerverwaltung der Datenbank und der Anwendung? Wie heißt das Anwendungsschema bzw. wie heißen die Anwendungsschemata in der Datenbank? Ein Anwendungsschema ist der Datenbank-User, der alle Objekte der Anwendung speichert, auch Anwendungs-Owner (Apps-Owner) genannt. Der Anwendungs-User (Apps-User) ist der Benutzer, der auf die Anwendungsobjekte zugreifen darf. In der Regel wird der AnwendungsUser von einem Anwendungs-Server genutzt. 6.7 Welches Patching-Konzept wird verfolgt? Patching ist ein sehr wichtiges Thema in der IT. Durch das Patching werden in der Regel Sicherheitslöcher gestopft. Nach Bekanntgabe eines Patches wird die Öffentlichkeit1 informiert. Aufgrund dieser öffentlichen Bekanntgabe könnte eigentlich jeder diese Sicher heitslöcher bei nicht gepatchten Versionen ausnutzen. Dies bedeutet, wird ein Patch nicht eingespielt, erhöht sich damit automatisch das Sicherheitsrisiko des IT-Systems (hier Datenbank). Daher ist es wichtig zu verstehen, wie die zu untersuchende Datenbank gepatcht wird. Tabelle 6.7 Fragenkatalog Patching Fragen Welche Patch-Strategie existiert? Oft haben die Kunden eine Patch-Strategie, die aussagt, wie häufig pro Jahr ein Patching durchgeführt wird. Dies ist allerdings keine gute Strategie. Die Strategie muss eindeutig aussagen, wann unbedingt gepatcht werden muss. Welche Patches werden eingespielt und warum? Wie oft wird die Datenbank pro Jahr gepatcht? Sind CPUs (Critical Patch Updates) im Patch-Prozess (jedes Quartal) eingeplant? Kennen Sie die Oracle-Risiko-Matrix? Diese Risiko-Matrix sollte jeder IT-Verantwortliche und Datenbankadministrator kennen. 1 Siehe Oracle Critical Patch Updates, Security Alerts alerts html

11 6.8 Wie wird die Datenbank bzw. das System überwacht? 6.8 W ie wird die Datenbank bzw. das System überwacht? Zur Erkennung und Identifizierung von Fehlern, Problemen und fremden sowie unerlaubten Zugriffen auf Systemressourcen ist es notwendig, entsprechende Monitoring-Werkzeuge einzusetzen. Darüber hinaus müssen Aussagen über die Verfügbarkeit und Performance definiert sein (Grundbedrohung: Verlust der Verfügbarkeit). Ist der Datenbankbetreiber in der Lage, bestimmte Zustände seiner Datenbank zu erkennen? Tabelle 6.8 Fragenkatalog Überwachung Fragen Ist ein Monitor für die Datenbankverwaltung im Einsatz (Grid Control, Cloud Control, Spotlight)? Wurde eine automatische Erkennung von Fehlern etc. implementiert? Wenn ja, wie? Listen/Alerts/Reports? Wer überprüft die Überwachungsreports, Logs? Nutzen Sie kostenlose Oracle-Tools wie Health Monitor (DBMS_HM, TOM, RACCHECK etc.)? Ist ein Monitor für die Systemadministration im Einsatz (Nagios, Tivoli, HP OpenView)? Gibt es eine zentrale Konsole zur Administration von Systemen, Netzwerken, Datenbanken? Gibt es eine sofortige Meldung an verantwortliche Parteien bei kritischen Fehlern? Wie ist die Verfügbarkeit des Systems definiert (Service Level Agreement (SLA))? Wie ist die Performance des Systems definiert (SLA)? Werden Aussagen (z. B. SLA-Erfüllung oder Trends der Sicherheit) automatisiert dokumentiert und Reports erstellt? Wie oft wird ein Anwendungstuning durchgeführt? Wie oft wird ein Datenbanktuning durchgeführt? Sind Datenbankoptionen im Einsatz, die zur Steigerung der Performance führen? Sind Diagnose- und Tuning-Werkzeuge im Einsatz (Advisors)? Wie ist der aktuelle Zustand hinsichtlich der Performance? Bei RAC-Einsatz: Wie viele Nodes existieren und wie ausgelastet in Prozent ist jeder Node? Wie hoch ist die maximale Recovery-Zeit (nächster Tag, wenige Stunden, Minuten)? Welche Aussage beschreibt am besten Ihre Hochverfügbarkeitsanforderungen (Auswahl aus Liste)? Keines; wenn der Server defekt ist, wird ein neuer geleast/gekauft oder ein existierender mit einem neuen Deployment versehen. Cold Failover; ein Standby-Server ist verfügbar, muss aber gebootet werden. Außerdem müssen Festplattenvolumes geladen und die Datenbank gemountet werden etc. Warm Failover; ein neuer Server wird automatisch in den Online-Zustand gebracht, Anwender müssen sich manuell neu verbinden. Hot Failover; sofortiger Failover auf das funktionierende System, Benutzer werden auto matisch auf den neuen Server transferiert oder es ist ein erneuter Login erforderlich. 479

12 480 6 Anhang: Fragenkatalog Tabelle 6.8 Fragenkatalog Überwachung (Fortsetzung) Fragen Welche verlorene Datenmenge kann Ihre Organisation nach einem katastrophalen Systemfehler manuell wiederherstellen (recover)? Was sind die Peaks für RAM- und CPU-Auslastungen auf den Maschinen? Wie sieht der aktuelle und zukünftige Data Storage für die Datenbank aus? Nutzen Sie das Storage nur für die Datenbank oder auch für andere Anwendungs- und File server? Interessant an dieser Stelle ist auch zu erfahren, welche Kosten oder Umsatzausfälle entstehen würden, wenn die Datenbank nicht mehr verfügbar ist, also ausgefallen ist. Es ist erstaunlich, welche Aussagen man hier manchmal zu hören bekommt. Tabelle 6.9 Downtime Calculator Fragen Geplante Auszeit Ungeplante Auszeit Wie viel Auszeit hatten Sie im letzten Jahr (Anzahl)? 10 2 Durchschnittliche Auszeit in Stunden? 10 2 Kosten pro Stunde? Kosten der Auszeit In 10,00 Geplante Auszeit 1.000,00 Ungeplante Auszeit 40,00 Verlorene Produktivität 104 h Abhängig von den Aussagen auch zu den Kosten eines Ausfalls kann man seine Verfügbarkeitsstrategie anpassen. 6.9 I st die Integrität der Datenbank und des Systems sichergestellt? Die Integrität der Systeme spielt in der IT-Sicherheit eine weitere wichtige Rolle. Eine Grundbedrohung Verlust der Integrität zeigt die Wichtigkeit dieser Thematik. Dieser Bereich zielt auf die Systeme wie Server, Hardware, Software (also z. B. die Anwendung) ab. Können Daten verschwinden oder werden diese verfälscht? Können Programme verfälscht werden und liefern sie fehlerhafte Ergebnisse? Um sich ein Bild über die Integrität des Systems machen zu können, ist es wichtig, verschiedene Konzepte wie den Umgang mit Accounts etc. zu verstehen.

13 6.9 Ist die Integrität der Datenbank und des Systems sichergestellt? Tabelle 6.10 Fragenkatalog Integrität Fragen Sind SYSTEM/SYSDBA-Logins eindeutig, d. h., werden diese nur von einer Person benutzt (personalisierte Administratoren)? Sind die Datenbank-Logins eindeutig Personen zugeordnet? Gibt es personalisierte DBA-Accounts? Wer administriert diese? Wie oft wird das ROOT-Passwort geändert? Wie oft wird das Passwort für den ORACLE-Account gewechselt? Wie oft werden die Passwörter der SYSTEM- und SYS-Datenbank-Accounts und weiterer hochprivilegierter Standard-Accounts geändert? Gibt es eine Muss -Passwort-Änderungsprozedur für Benutzer? Wird ein externer Account für das Betriebssystem zum Datenbank-Login genutzt (OPS$)? Wird der Zugriff von außerhalb (Internet) in das Datenbanksystem gewährt? Falls ja, wie sehen die Sicherheitsvorkehrungen aus? Wer hat Zugang zum ROOT-Passwort? Wie wird der Zugriff protokolliert? Wer hat Zugang zum ORACLE-UNIX-Account? Wie wird der Zugriff protokolliert? Wer hat Zugang zu den Datenbankbenutzern SYSTEM und SYS? Werden deren Aktivitäten dokumentiert? Sind Datenbankzugriffsregeln über Datenbankrollen geregelt? Wie sieht der Mechanismus zum Entfernen der Logins aus, wenn Mitarbeiter das Unternehmen verlassen (IDM-Lösung im Einsatz)? Werden die gleichen Passwörter für die Test-, Entwicklungs- und Produktionsumgebung genutzt? Werden Vorkehrungen getroffen, um Daten aus dem Produktivsystem, die für Test- und Entwicklungssysteme zur Verfügung gestellt werden, zu entfernen bzw. zu maskieren? Wird die Integrität aller Dateien auf dem Dateisystem gesichert (Checksum)? Wird die Integrität der Datenbanklogik (PL&/SQL) gesichert (Checksum)? Werden regelmäßige Health Checks durchgeführt? Wird die Integrität der Datenkommunikation (Datenbank-Client) gesichert (Netzwerkverschlüsselung)? Wird die Integrität von Backups, Redos etc. gesichert? Werden Backups mit einem Passwort versehen? Wie ändern die Endbenutzer (Datenbankbenutzer) ihr Passwort (welches Tool)? Wurden Vorkehrungen gegen die unerlaubte Veränderung von Anwendungen getroffen (Konfigurationsparameter verändern, Benutzer anlegen etc.)? 481

14 482 6 Anhang: Fragenkatalog 6.10 Wo steht der Datenbankserver? Das Rechenzentrum wird bei einer Sicherheitsüberprüfung nicht detailliert untersucht. Es ist aber von wesentlichem Interesse, ob der Datenbankserver in einer sicheren Umgebung eingebettet ist. Tabelle 6.11 Fragenkatalog Rechenzentrum Fragen/Antworten Wo wird der Produktivserver mit der Datenbank betrieben (Data Center)? Wurde die Administration der Rechner einer Fremdfirma überlassen? Ist das Rechenzentrum für einen professionellen Betrieb ausgelegt (USV, Klima, Zutritts kontrolle etc.)? Gibt es mehr als ein Rechenzentrum (redundant, Spiegelung)? Ist das Rechenzentrum zertifiziert (SAS70) und wird regelmäßig auditiert? 6.11 Kann die Integrität der Daten sichergestellt werden? Die Datenintegrität ist für den Nutzer von wichtiger Bedeutung. Durch die Datenbankadministration und das Development muss garantiert sein, dass die Daten vollständig, also unverändert und aktuell, sind. Wichtig in diesem Bereich ist es, die Konzepte für eine Datenintegrität kennenzulernen. Tabelle 6.12 Fragenkatalog Integrität der Daten Fragen/Antworten Verschlüsseln Sie Daten in der Datenbank? Wird eine Datenintegrität auf Applikationsebene eingesetzt? Nutzen Sie Virtual Private Database (VPD) oder Label Security für den sogenannten Zugriffsschutz auf Datensatzebene (Row Level Security)? Arbeiten Sie in verteilten Umgebungen (Replikation)? Wie garantieren Sie die Aktualität über alle Systeme? Nutzen Sie Journale oder Archivmechanismen, um die Änderungszustände der Daten zu dokumentieren? Werden also Änderungen an den Daten protokolliert? Wie vermeiden und beheben Sie menschliche Fehler beim Zugriff auf Daten (z. B. ein nicht gewolltes TRUNCATE TABLE)? Überprüfen Sie regelmäßig auf korrupte Datenblöcke? Werden Daten für das Testsystem pseudonymisiert oder anonymisiert?

15 6.12 Was tut der Betreiber für eine sichere Konfiguration? 6.12 W as tut der Betreiber für eine sichere Konfiguration? Die sichere Konfiguration der zu untersuchenden Datenbank wird eigentlich mittels der Skripts geprüft. Trotzdem ist es wichtig, einen verbalen Zustandsbericht zu erhalten, um dann das Gesagte (der Glaube) mit der Realität (das Wissen) vergleichen zu können. Darüber hinaus existieren einige Fragen, die nicht von den Skripts beantwortet werden. Tabelle 6.13 Fragenkatalog Sichere Konfiguration Fragen/Antworten Existieren Validierungs- und Genehmigungsprozesse für Hardware- und Software-Änderungen? Beschreiben Sie die im Einsatz befindlichen Policies zur Durchführung von Änderungen in der Datenbankstruktur. Wie oft werden interne Audits durchgeführt, die sich mit der Überprüfung des guten Zustands der eingesetzten Hard- und Software beschäftigen? Bitte beschreiben Sie, was mit der Datenbank getan werden muss. Existiert ein Netzwerkzugriff auf die Datenbankmaschine (FTP, WEB etc.)? Telnet oder nur SSH? FTP oder FTPS? SAMBA? NFS? Andere Filesharing Tools? Werden Berkley-R-Utilities genutzt? (Falls ja, existiert ein hohes Sicherheitsrisiko. Die Utilities sollten deaktiviert werden.) Welche Software ist auf Clientseite installiert? (Prinzipiell gilt: Alles, was nicht benötigt wird, sollte entfernt werden.) Ist die Anwendung lokal bei jedem Endbenutzer (also Fat-Client) installiert oder handelt es sich um eine webbasierte Anwendung? Gibt es besondere Mechanismen, die den Verbindungsaufbau zu verschiedenen Datenbanken steuern (Test, Development, Produktion)? Ist im Unternehmen eine zentrale Benutzerverwaltung (LDAP, IDM, Access-Management etc.) im Einsatz? Nutzen Sie diese auch für die Datenbank? Wenn Grid Control/Cloud Control im Einsatz ist, wie wird die Kommunikation zwischen Agent und Repository abgesichert? Wie würde man die Produktivität der Datenbankadministratoren beschreiben? Sind die Datenbankadministratoren sehr ausgelastet? Wie ist die Arbeit verteilt? Ist das SQL*Net besonders geschützt? Wurden zusätzliche Sicherheitsvorkehrungen getroffen (z. B. Eigenentwicklungen)? 483

16 484 6 Anhang: Fragenkatalog Tabelle 6.13 Fragenkatalog Sichere Konfiguration (Fortsetzung) Fragen/Antworten Überwachen Sie regelmäßig die Standard-Log-Dateien (Alert.log und Listener.log)? Wissen Sie, wer alles auf die Datenbank zugreift (intern, extern, Lokationen wie Länder, Offices etc.)? Wie entscheiden Sie, welche Audit-Policies implementiert werden? Wie werden die Audit-Daten in den Datenbanken gelöscht? Wie entscheiden Sie, welche Schutzbedarfe implementiert werden?

17 Index A Abwärtskompatibilität 138 Access Control 206 Access Control List der Network Packages 380 Accounts 321 Account-Management 114, 264, 323, 344, 360 Account-Management-Privilegien 362 Account-Manager 67, 347 Active Data Guard 302 Admin-Option 346 Advanced Security Option (ASO) 38, 61, 102, 105, 136, 407, 412 AES AFTER LOGON-Trigger 55 Alerts 317 Alert.log 319 ALTER SESSION 49, 362 Anonymisierung 59 Anwendungsowner 53, 57, 67, 272, 354 Anwendungsrollen 342 Anwendungs-User 53 ANY-Privilegien 354 f. APEX (Oracle Application Express) 207, 210, 452 embedded Gateway 210 Application-Owners 263 Archivierungssysteme 106 ASM 306 Attestierung 73, 354 Attestierungsprozesse 356 Audit 23, 69, 78, 87, 93, 279 ff., 427 AUDIT_ADMIN 89 Audit-Daten 88 Audit-Konzept 89, 94 Audit Policy 92, 227, 232, 237 AUDIT-Privilegien 332 Audit-Trail 221 AUDIT_VIEWER 89 Audit Warehouse 70 Aufgaben, Kompetenzen und Verantworlichkeiten (AKV) 66 Ausfallszenarien 283 Auswertung des Listener-Log 453 Authentisierung 23, 26 AUTHID CURRENT_USER 47 Automatic Storage Management (ASM) 306 f. Automatische Datenoptimiertung (ADO) 118 automatisierte Provisionierung 475 Autorisierung 23 Availability (Verfügbarkeit) 75 B Backdoors 267 Backups 300 Backup-Konzept 298, 300 Backup & Recovery 284 Batchdatei 442 BDSG 68 Bedrohungs- und Risikoanalysen 12 Beispieluser 390 Benutzergruppe 80, 184, 263, 330, 476 Benutzerverwaltungen 33 Berechtigungen 321 für wichtige Datenbankobjekte 390 Berechtigungskonzept 46, 71, 99 Betriebssystemgruppen 95 Bewertungen nach CVSS 467 Bewertungskriterien 461 Bruteforce 42, 249 Bundesamt für Sicherheit in der Informationstechnik (BSI) 9, 324 Bundesdatenschutzgesetz 66, 218, 320 Business-Rolle 321, 333 BY ACCESS 228, 235 C CDB 107 Centralized User Administration for Databases (CUA4DB) 183 CheckOraDBSec.ba 441 CheckOraDBSec.sh 441

18 486 Index CIA Business-Impact-Matrix 13 Triade 11 Client-Identifier 91 Cloud 43 Cloud Computing 63, 114 Cloud Control 71 COMMON USER 109, 324 Compliance Dashboard 71 Compliance/Nachhaltigkeit der Datenbank 122 Confidentiality (Vertraulichkeit) 75 Configuration Management Packs 43, 423 CONNECT 48, 369 Container 81, 93, 125, 245 Container-Clause 114 Container Database 106 CONTEXT 54, 396 CPU Resource Management 63 Critical Patch Updates (CPU) 163, 423 CSV-Dateien 444 CURRENT_USER 87, 410 CVSS 75, 121, 466 DBA-Rolle 329 DB-Creation-Script 130 DB-Link-Sicherheit, Database Link 49 DB-Link-Users 49 DB Vault 67, 69, 93 f., 390 DB-Vault-Owner 424 DB-Vault-Sicherheitszonen 424 Default-Kennwort 166, 179 f. Definer Rights 83 Denial of Service (DoS) 56 Attacken 10, 311 Diagnosability Infrastructure 69 Diagnoseeinstellungen 277 Dictionary managed 290 Directories 400 direkte Berechtigungsvergabe 319 Disaster Recovery 309 Disk Flooding 56 Downtime Calculator 480 DR-Konzept 309 D eigenes Rollenkonzept 372 EM Express 248 Enterprise Manager 43, 71, 135, 248 Enterprise Manager Repository 317 Enterprise-Rollen 35 Enterprise-User 35 Enterprise User Security 33 f. Erhalt des guten Sicherheitszustands 26 Erhaltung der Sicherheit 73 erhöhtes Risiko 381 erhöhte Sicherheit (Datenschutz) 2 Erkennung und Identifizierung 479 EUS (Enterprise User Security) 33, 66 EvaluationDBSetup 460 Evaluierungsdashboard 450 Evaluierungsdatenbank 450 EXECUTE-Berechtigungen 387 Export-Dumps verschlüsselt 61 Extended Audit Information 91 Extensibility Frameworks 81 external Procedures 403 External Procedure Call 81 Externer Passwort-Speicher 189 Database App Development VM 445 Database Control 248 Database Link 26, 146, 162, 188, 347 Database Vault 48, 96, 105, 232 f., 345 Database Vault Auditing 88 Data Dictionary 6, 334 Dataguard 309 Data Masking 62 Data Pump 93 f. Data Redaction 101, 103, 406 Daten Sozialdaten 5 Unternehmensdaten 5 Datenanonymisierung 23 Datenbankaktivitäten 69 Datenbankjobs 427 Datenbank-Links 49 Datenbankprofile 28 Datenbanküberprüfung 121 Datenbank-Upgrade 38 Datenintegrität 482 Datenklassifikation 11 Datenlabels 415 Daten-Lifecyle 117 Datenloads 446 Datenmodell 446 Datenqualität 274 Datenschutz 1, 5, 20, 26, 104, 394 Datenschutzregeln 25 Datentypen 416 Datenverlust 125 Datenverschlüsselung 23 DBA-Account 49 E F Fast Recovery Area 287 feingranulare Zugriffsrechte 205 FGA Policy 92 Fine-grained Auditing 69, 87 Fragenkatalog 470 Fragmentierung 152, 289 Full-Database-Backup 150

19 Index G gefährliche Library 419 gehärtete Datenbank 142 geheimer Schlüssel 413 Genehmigungsprozesse 354, 356 Gesetze 1, 15, 28, 62, 69, 104, 122, Abs. 2 des Aktiengesetzes BGB 17 Aktiengesetz 16 BDSG 19 Bundesdatenschutzgesetz (BDSG) 1, 5, 15, 19, 42, 66, 218, 320 Bundesschutzgesetze 19 Compliance 14 Gesetz zur Bekämpfung der Wirtschaftskriminalität 15, 28 Gesetz zur Kontrolle und Transparenz (KontraG) 16 GmbH-Gesetz 16, 18 Handelsgesetzbuch 19 KonTraG 16 Landesdatenschutzgesetz 364 Richtlinien 1 StrÄndG 21 gesetzeskonform 102 gesetzeskonformer Betrieb 243 gesetzliche Anforderungen 68 gewachsene Datenbank 40, 47 Gewaltenteilung 38, 63, 78, 81, 94, 427 Glaube 469 und Realität 43 und Wahrheit 6 globale Standardrolle 339 glogin.sql 44 GoogleChart-Owner-Hierarchie 451 Graceperiode 77 GRANT 45 Grundbedrohungen 9, 121, 283 Grundschutz 43 H HA-Anforderung 125 Haftungsrisiken 76 Härten 40 Härtung 6, 43 Hashverfahren 324 Health Checks 26, 73 Heatmap 118 hochprivilegierte Accounts 329 hochprivilegierte Rechte 53 hochverfügbare Mindesteinstellung 284 I Identitäten 71, 329 Identity-Management-Lösung 183 Identity Management System 71 ILM-Konzept 116 ILM-Policies 192 Immediate-Write-Modus 89 IMP/EXP_FULL_DATABASE 48 Implementierter Schutzbedarf, Beispiel 11 Information Lifecycle Management 116, 192 INHERIT (ANY) PRIVILEGES 80 init.ora-parameter 38 Instance Caging 310 Integrationspunkte 49 Integrität 9, 75 der Systeme 480 Interaktive Reports 452 invalide Objekte 292 Invoker-Rechte 411 Invoker Rights 47, 83 IT Sicherheit 9 J Java-Permissions 398 Java-VM 430 K Keine Installation 442 Kennwort siehe Passwort Kennwortmanagement siehe Passwortmanagement Kerberos 37 f., 78, 323 Klassifikation siehe Datenklassifikation Klassifizierung 5, 100, 415 Komplexität 34, 38, 45, 78, 88, 116, 162, 237, 308, 319, 333, 352, 388 Komprimierung 119, 300 Konfiguration 461 f. der Datenbank 121, 123 Konsolidierung 114 Kontrolle 68, 78 der Daten 63 und Transparenz 43 Korrelierung 239 korrupte Datenbackups 300 korrupte Datenblöcke 301 f. Kriminalität 28 L Label Security 105 LAST_LOGIN 79, 254, 326 LDAP 51 Least Privilege 40, 46 f., 51, 53, 95 f., 98, 319, 354, 356, 372, 381 Least Software-Install 129 Lifecycle Management Packs 43, 71, 423 Lizenz-Compliance 49,

20 488 Index LOCAL USER 109, 324 Log-Dateien 444 M Management Packs 43 Mandantenfähigkeit 60, 106 Maskierung 102 menschliche Fehler 125 Mindestanforderung 65 Mindestprotokollierung 69 Mindestsicherheit 40, 224, 289 Härtung 6, 26 Missbrauch 43 Mixed Mode, Audit 89 Monitoring/Auditing 462 MS Active Directory 33, 66 multiplexed 148, 288 Multiplexing 149, 287, 289 Multi-Tier-Anwendungen 104 N Nachhaltigkeit und Compliance 465 Nachweisbarkeit 43 Network Packages 193, 195, 376 Netzwerkverschlüsselung 3, 60 New Feature Guide 38 Nicht-Patching 74 NON-CDB 107, 123 O Object-Owner 45, 275 f. Objektprivilegien 45, 80, 319 opatch 423 OPEN_LINK 50, 146 OPS$%-Accounts 323 ORA_ACCOUNT_MGMT 90, 221 ORA_DATABASE_PARAMETER 90, 221 ORA_SECURECONFIG 42, 90, 221, 224 Oracle Advanced Security Option 60 Oracle Audit Vault 70 Oracle Data Pump 114 Oracle Database Firewall 53 Oracle Database Vault 362 Oracle Datenbank Developer VBOX 445 Oracle Enterprise Manager 75 Oracle Enterprise User Security 26, 51 Oracle Identity Manager 72 Oracle Listener 61 Oracle Managed Files 287 Oracle Network Configuration Manager 38 Oracle Privileged Account Manager 329 Oracle Real Application Security 104 Oracle Resource Manager 65 Oracle-Standard-Datenbankbenutzer 261 Oracle-Standardinstallation 335, 394 Oracle Standard Schema 166 Oracle Wallet 413 Owner 45, 57, 84 Owner-Objekte 230 P Packs 135 Password-File 263, 331 PASSWORD-Verify-Funktion 183 Passwort cracken 27 Hashes 80, 181 Komplexität 29, 79 Management 25 f., 28, 186 Richtlinie 28 Verschlüsselung 32 Passwortdatei 181 Passwortversion 324 Patches 42, 217, 264 Patch-Advisor 75 Patching 26, 74, 478 Patching-Prozesse 76 Patching-Strategie 77 Patchset 164, 423 PCI-DSS 100, 394 PDB Historie 128 personalisierte Accounts 329 personalisierter DBA 329 personenbezogene Daten 1, 20, 68, 229, 232 pluggable Datenbanken 106 pluggable DB 245 Policy 52 Privileganalyse 47, 408 Privileged Account Management 181 Privilegien 75, 78, 114 Capture 96 in der XML DB ACL 383 privilegierte Benutzer 253 Produktionsumgebung 323 Produktivitätssteigerungen 34 Profile 65, 67, 183 f., 266 Protokollieren 93 Protokollierung 66, 68 Audit 20, 26, 42, 218 Provisionierungsprozess 71 Provisioning 354 Proxies 397 Prüfsummenbildung 10 Pseudonymisierung 23, 59 PUBLIC DB Link 51, 187 Public Synonyme 162 punktuelle Sicherheitslösungen 6

21 Index Q Queued-Write-Modus 89 R Real Application Security 78, 279 f. Realität 469 Rechenzentrum 482 Reconciliation 73 Recovery Manager 296 Redundanzen 237, 352, 388, 403, 415 Referenzdatenbank 41, 43 Referenz-DB-Erstellungsskript 41 Regelbibliothek 43 Release-Manager 358 Remote Listening 61 Reorganisation 290 Resource Manager 310, 312 RESOURCE-Rolle 39 Ressourcen 48, 63, 369 Ressourcenmanagement 29, 63 Ressourcenverbrauch 64, 184 Ressourcenverbrauch-Policy 303 ff. Retention Policy 297 revisionssicheres Audit 70 REVOKE 45 Rezertifizierung 319 Risiko 74, 187 f., 213 Risikoabschwächung 7, 81 Risikofaktor 43, 75, 467 Risikomanagement 6 Risikomatrix 75, 121 Risikominimierung 7, 43 RMAN 93, 294, 298, 421 Rollen an PL/SQL 402 Rollenhierarchie 352 Rollenkonzepte 319 Rollenmanagement 26, 48, 78 Rootkit 221, 267 Row Level Security 59 Royalty 49, 252 S sanftes Härten 42 Scheduler-Credentials 429 Schutzbedarf 11, 52, 122, 263, 473 Schutzmaßnahme 104 Schwachstellen 75, 121 SCN-Headroom 435 Secure Application Role 57, 339 Secure Password Store 189 security cost of ownership (SCO) 120 Security Patch Updates 423 Security Updates 74, 76 Seggration of duty 331 SELECT-Sammlung 459 sensible Spalten 101 Separation of Duties 94 Serverkonsolidierung 310 SHA Shared Accounts 243, 253, 329 Shared DB Accounts 244 shared library 417 Shell-Script 442 sicherer Datenbankbetrieb 471 sichere Datenbankkonfiguration 23 sichere Konfiguration 483 Sicherheitsdesign 5 Sicherheitspatches 43 Sicherheitspolicy 52 Sicherheitsstandard 43 Sicherheitsüberprüfung 121 Sicherheitsuntersuchung 121 Sicherheitszonen 57 Sicherheitszustand 71, 460 Single Sign-On 38 Slider 462 SoD 71 f., 78, 94, 107, 327, 344 SQL INJECTION 53, 221, 376 SQL-Scripte 442 SSL Handshake 51 Standardeinstellung 394 Standardkennwort 40 Standardrollen 48, 242, 333, 342, 372 Standard-User 276 Standby 308 starke Authentisierungsverfahren 26 starke Privilegien 188 Subsetting 63 Synonyme 293 Syntaxsuche 101 SYS-Objekte 337 SYSBACKUP 94 SYSDBA 94, 264 SYSDG 94 SYSKM 94 SYSLOG-Server 221 System Global Area 434 Systemprivilegien 45, 69, 224, 227, 234 f., 240, 319, 349, 451 T TABLESPACE QUOTA UNLIMITED 39 total cost of ownership (TCO) 120 Transient logical Standby 284 Transparent Data Encryption (TDE) 412 Transparent Sensitive Data Protection 100 transparente Datenverwaltung 119 transparente Verschlüsselung 61 Transparenz 91 und Kontrolle 74, 122 Trennung von Verantwortlichkeiten 354 TSDP

22 490 Index U Überwachen 57 Überwachung 80, 97, 218 der Datenbank 121 des Listener.log 282 von Systemprivilegien 228 Umgebungen 474 Umsatzausfälle 480 unerlaubter Zugriff 69 Unified Audit 94, 278 UNIFIED_AUDIT_TRAIL 89 Unified Auditing 78, 88, 219, 221 unlimited Ouota 366 UNLIMITED QUOTA 49, 80 Unsichtbare Benutzer 266 Unsichtbare Rollen 268 unsichtbare Standardrollen 269 _NEXT_USER 269 PUBLIC 269 Untersuchungsmöglichkeiten 441 unverschlüsseltes Backup 300 von Regeln 69 gegen die Zwecktrennung 390 Vertraulichkeit 9 Virtual Private Database 191, 394 Row Level Security 59 VPD 59, 365 virtuelle Umgebung 43 VPD 101 VPD Policy 60 W Wallets 189 Wichtigkeit der Daten 473 der IT-Sicherheit 471 Windows-Umgebung 38 Wissen 469 X XML-DB-ACL-Dateien 383 V Verbindlichkeit 9 Vereinfachung 34 Verfügbarkeit 9, 283, 300, 463 der Datenbank 121 Verlust der Integrität 10, 121, 273, 480 der Kontrolle 372 der Verbindlichkeit 11 der Verfügbarkeit 10, 121, 303 ff., 311, 416, 479 der Vertraulichkeit 10, 121, 273 Verschlüsselung 59, 78, 105, 144, 300 versteckte Oracle-init.ora-Parameter 142 Verstoß Z Zero-Downtime 284 Zertifikate 323 Zugriffskontrolle 319, 463 f. der Datenbank 122 Zugriffskonzept 160, 162, 350 für Directories 401 Zugriffsrechte 337 Zugriffsschutz 58 auf Zeilenebene 395 Zwecktrennung 26, 57, 66, 264, 320, 330, 333, 345, 358 SoD 67

23 Moderne mobile Webanwendungen entwickeln. Beckmann Oracle Application Express in der Praxis Mit APEX datenbankbasierte Webanwendungen entwicklen 416 Seiten. Hardcover. ISBN Mit kostenlosem E-Book (PDF) Dieses Buch führt leicht verständlich in Entwicklung mit APEX 4.2 ein. Bewusst werden alle notwendigen Entwicklungsschritte bis hin zur fertigen Web-Anwendung anhand eines durchgängigen Beispiels einer»projektmanagementplattform«systematisch vorgestellt. Die didaktische Konzeption und die detaillierten Schritt-fürSchritt Anweisungen ermöglichen es, schnell eigene Anwendungen zu entwickeln. Neben den APEX-Grundlagen werden aber auch Themen wie die Entwicklung multilingualer Anwendungen, die Entwicklung von mobilen Web-Apps ebenso wie das Deployment von APEX-Anwendungen behandelt. Die Verwendung von Neuerungen wie z.b. des DataLoading Wizzards, PlugIns und WebSheet Anwendungen, die seit APEX 4.0 und 4.2 zur Verfügung stehen, runden dieses Werk ab. Mehr Informationen zu diesem Buch und zu unserem Programm unter

24

25 Sinnvolle Lösungen für große Datenmengen. Baron Big Data für IT-Entscheider Riesige Datenmengen und moderne Technologien gewinnbringend nutzen 228 Seiten. ISBN Auch als E-Book erhältlich Die Menge der Geschäftsdaten wächst in allen Branchen rasant. In diesem Buch werden verschiedenste Szenarien und Anwendungsfälle für»big Data«beschrieben. Aufgezeigt werden die damit verbundenen Business Opportunities und Chancen genauso wie die Risiken. Das Thema wird dabei aus unterschiedlichsten Perspektiven betrachtet. Case Studies zeigen, wie New-Economy-Unternehmen und Startups der Moderne sich diesem Thema bereits jetzt stellen. Der Autor vermittelt Ihnen außerdem einen Überblick über die Technologien rund um»big Data«. Als Entscheider finden Sie hier die wichtigsten Informationen, um einschätzen zu können, was Sie für Ihr Unternehmen benötigen, mit welcher Art von»big Data«Sie sich auseinandersetzen sollten und welche Skills Ihre IT-Mitarbeiter haben müssen. Mehr Informationen zu diesem Buch und zu unserem Programm unter

26

27 Lieber No statt SQL Edlich, Friedland, Hampe, Brauer, Brückner NoSQL Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken 410 Seiten. ISBN Auch als E-Book erhältlich NoSQL-Datenbanken sind dabei, die Datenbankwelt zu revolutionieren. Laufend hört man von neuen NoSQL-Datenbanken, die sich jeweils für besondere Einsatzbereiche gut eignen. Dieses Buch hilft Datenbank- und Web-Entwicklern, den Überblick zu behalten und das richtige System für ihre Zwecke zu finden. Sie lernen die Konzepte von NoSQL-Systemen kennen, die sie von den klassischen relationalen Datenbanksystemen unterscheiden. Vorgestellt und erklärt werden die theoretischen Grundlagen Map/Reduce, CAP-Theorem/Eventually Consistent, Consistent Hashing, MVCC-Protokoll, Vector Clocks, Paxos und REST. Detailliert stellen die Autoren die wichtigsten Vertreter der vier großen NoSQL-Datenbanktypen Wide Column Stores, Document Stores, Key/Value-Datenbanken und Graphdatenbanken vor. Sie erfahren, wie die Systeme aufgesetzt und skaliert werden, welche Vor- und Nachteile sie haben und für welche Anwendungsgebiete Sie sie einsetzen können. So haben Sie eine gute Grundlage für die Entscheidung, welche Datenbank in Ihrem Fall am besten geeignet ist. Mehr Informationen zu diesem Buch und zu unserem Programm unter

28

29 Behalten Sie den Überblick! Stefan Zörner Softwarearchitekturen dokumentieren und kommunizieren 280 Seiten ISBN ,90 Auch als E-Book erhältlich Dokumentation wird oft als lästige Pflicht angesehen und in vielen Softwareprojekten stark vernachlässigt. Die Architektur wird manchmal überhaupt nicht beschrieben. Damit das in Ihren Projekten nicht passiert, schlägt dieses Buch praxiserprobte und schlanke Bestandteile für eine wirkungsvolle Architekturdokumentation vor. An einem durchgängigen Beispiel erfahren Sie, wie Sie architekturrelevante Einflussfaktoren erfassen und Ihre Softwarelösung angemessen und ohne Ballast festhalten. Sie lernen nicht nur die Vorgehensweise für das Dokumentieren während des Entwickelns kennen, sondern auch wie Sie bestehende Systeme im Nachhinein beschreiben. Neben der Methodik diskutiert das Buch auch typische Werkzeuge, mit denen Sie Architekturdokumentation erfassen, verwalten und verbreiten können, wie Wikis, UML-Werkzeuge u.a. Mehr Informationen zu diesem Buch und zu unserem Programm unter

30

31 Anforderung gut, alles gut. Chris Rupp & die SOPHISTen Requirements-Engineering und -Management Professionelle, iterative Anforderungsanalyse für die Praxis 5., aktualisierte u. erweiterte Auflage 569 Seiten. Vierfarbig ISBN Auch als E-Book erhältlich Softwareentwickler müssen die Anforderungen (Requirements) an ein Software-System kennen, damit sie und auch die späteren Anwender sicher sein können, dass das richtige System entwickelt wird. Die Anforderungsanalyse entscheidet über den Erfolg von Projekten oder Produkten. In ihrem Bestseller beschreiben die SOPHISTen, ausgewiesene Requirements-Experten, den Prozess, Anforderungen an Systeme zu erheben und ihre ständige Veränderung zu managen. Sie liefern innovative und in der Praxis vielfach erprobte Lösungen. Zahlreiche Expertenboxen, Beispiele, Templates und Checklisten sichern den Know-how-Transfer in die Projektarbeit. Mehr Informationen zu diesem Buch und zu unserem Programm unter

32 ORACLE SECURITY IN DER PRAXIS // Hier finden Sie eine umfangreiche Sammlung von Prüftests und Best Practices sowie eine Einführung in gesetzliche Grundlagen Für Oracle-Datenbanken der Versionen 10g, 11g und 12c Nehmen Sie die Sicherheit Ihrer Oracle Datenbank selbst in die Hand. Dieses Buch zeigt Ihnen alles, was Sie dazu wissen müssen In diesem Buch erfahren Sie alles, was Sie zu möglichst optimalen Sicherheitseinstellungen wissen müssen. Die Konzepte sind zwar teilweise unabhängig von der Datenbankversion und dem Hersteller, der Fokus des Buches liegt aber auf den Oracle-Datenbank-Versionen 10g, 11g und 12c. Zunächst erhalten Sie einen Überblick zu den Grundlagen und Bedrohungen der DB-Sicherheit. Anschließend werden wichtige Lösungen für einen Standardbetrieb mit erhöhten Schutzeinstellungen beschrieben. Sie finden auch die neuen Konzepte für die Oracle-Datenbank 12c und Sie erfahren, welche Informationen über eine Oracle-Datenbank nötig sind, damit sich deren Sicherheitszustand auch mittels CVSS einschätzen lässt. Außerdem wird beschrieben, wie man die Tools zur automatisierten Sicherheitsüberprüfung so ausführt, dass sie zu einem schnellen Ergebnis führt. Damit sind Sie in der Lage, den Zustand Ihrer Datenbanken selbst zu bewerten und dabei entdeckte Risiken dem Sicherheitsbeauftragten Ihres Unternehmens zu melden, damit er die entsprechenden Maßnahmen einleiten kann. Das Sicherheitsziel ist erreicht, wenn in alle Oracle- Datenbanken, die personenbezogene oder andere sensible Daten enthalten, der erhöhte und gesetzeskonforme Datenschutz implementiert ist und dieses Sicherheitsniveau auch langfristig gehalten werden kann. Dipl.-Inform. Carsten MÜTZLITZ arbeitet mit der Oracle-Datenbank seit der Version 6.0. Er ist heute als Master Principal Sales Consultant bei Oracle Deutschland und seit über 20 Jahren als Berater und Softwareentwickler tätig, unter anderem bei IBM, Intershop und Capgemini. Sein Schwerpunktthema ist die IT-Strategie und insbesondere die IT-Security. Er hat in Deutschland die erste Security-Checkliste beim BSI veröffentlicht und schon viele Hundert Sicherheitsüberprüfungen von Oracle-Datenbanken durchgeführt. AUS DEM INHALT // Einführung in die IT-Sicherheit bei Datenbanken inklusive gesetzlicher Grundlagen Lösungen und Best Practices für die Datenbanksicherheit Prüfung der Sicherheit einer Oracle-Datenbank (10g, 11g und 12c) in den Bereichen Konfiguration, Überwachung, Verfügbarkeit, Zugriffskontrolle Prüfung ausführen, Erkenntnisse gewinnen, Zustand bewerten und Lösungen sowie Maßnahmen ableiten Zusätzlicher Fragenkatalog für eine ganzheitliche Sicht auf das System, in dem die zu untersuchende Datenbank eingebettet ist 59,99 [D] 61,70 [A] ISBN