DB2 Verfügbarkeit, Stabilität und Sicherheit aus der Perspektive eines Auditors

Transkript

1 BMC Availability and Recovery Best Practices Seminar Vol. 4 DB2 Verfügbarkeit, Stabilität und Sicherheit aus der Perspektive eines Auditors Thomas Baumann Die Mobiliar thomas.baumann@mobi.ch

2 Ziele Unterscheide Rollen und Verantwortlichkeiten von DBA und IT Audit Nutze Präsentation als Hilfsmittel für Risk Self Assessment für den DBA zur Vorbereitung und Durchführung eines DB Audits für den Auditor Kein Ziel dieser Präsentation: Umfassende Richtlinie für Auditor

3 Inhalt Datenbank Risiken und Schwachstellen DBA vs. Auditor Rollen in Entwurf und Ueberwachung von Kontrollen Teil I: Kontinuierliche Analyse von Risiko Indikatoren High-Level Audit Reports Teil II:Detaillierte Audit Reports zur Eingrenzung und Reduktion von Risiken Vertraulichkeit/Zugriffsschutz Integrität Verfügbarkeit Effizienz (Performance) Zusammenfassung

4 Die Mobiliar auf einen Blick

5 Disclaimer The Information contained in this presentation has not been submitted to any formal Swiss Mobiliar or other review and is distributed on an as is basis without any warranty either expressed or implied. The use of this information is the user s responsibility. The procedures, results and measurements presented in this paper were run in either the test and development environment or in the production environment at Swiss Mobiliar in Berne, Switzerland. There is no guarantee that the same or similar results will be obtained elsewhere. Users attempting to adapt these procedures and data to their own environments do so at their own risk. All procedures presented have been designed and developed for educational purposes only.

6 Datenbank Risiken und Schwachstellen Intentional Risks Häufig nur Vertraulichkeits Risiken betrachtet C Traditionelles Gebiet für Audits Unintentional Risks Integrität I Verfügbarkeit A Häufig vernachlässigte Gebiete in Datenbank Audits Risiken sind auch Chancen Effizienz (Performance): Was könnte optimiert werden? E

7 Kampf gegen Datenbank Schwachstellen Aktueller Maintenance Stand Wirkt sowohl gegen intentional wie gegen unintentional Risiken Regelmässige DB Scans zur Identifikation von Schwachstellen Confidentiality, Integrity, Availability, Efficiency Themen Implementiere aktives Datenbank Monitoring Inklusiv Intrusion Detection

8 Auditor vs. DBA: Aufgaben und Kompetenzen DBA Identifiziert Risiken Definiert Kontrollen zur Risiko Reduktion Implementiert Kontrollen, reagiert auf Monitor-Alarm Meldungen Auditor Evaluiert Design Effectiveness der Kontrollen Prüft Einhaltung (compliance) der Kontrollen Kontinuierliches Monitoring vs. Kontinuierliches Auditing Auditor muss unabhängig bleiben Auditing Reports werden auch von DBA benutzt

9 Aufgaben und Kompetenzen Aufgaben Prüfe Kontroll Einhaltung Prüfe Wirksamkeit der Kontrollen Risikoi Identifikation und beurteilung Risiko Ueberwachung Ueberwachung und Unterhalt der Kontrollen Entwurf und Implementierung der Kontrollen Regulatoren Externes Audit Internes IT Audit Risiko Management Interne Kontrollen verantw. IT Audit IT Audit IT Audit/DBA DBA/IT Audit DBA DBA

10 Wahrung der Auditor Unabhängigkeit: High Level vs. Detail Reports Kontinuierliches Risiko Assessment durch Auditor High Level Reports zur Identifikation von Risiko Gebieten Definiere, Berechne, Evaluiere Vertraulichkeits-, Integritäts-, Verfügbarkeits-, Effizienz Risiko Indikatoren Ein (von mehreren) Input für Jahresplanung Kontinuierliches Monitoring durch DBA Detail Reports als Teil des kontinuierlichen Monitorings mit Alarmierung bei Problemen Detaillierte Key Performance Indicators für Vertraulichkeit, Integrität, Verfügbarkeit, Effizienz

11 Kontinuierliches Risiko Assessment: Gebiet 1 (von 4): Vertraulichkeit Risiko Indikator Anzahl direkter Zugriffsprivilegien Messung (monatlich) Sind Anzahl und Vergabe- Methoden direkter Zugriffsprivilegien angemessen? 500% time C 100 x no of privileges granted total no of views 0% Privileges should be granted according to roles, not directly to users

12 Kontinuierliches Risiko Assessment: Gebiet 2 (von 4): Integrität Risiko Indikator Anzahl durchgeführter Utilities (LOAD, RECOVER) Messung (wöchentlich) Sind Anzahl von LOAD und Recover Aktionen angemessen? 100% time I 100 x no of util executions no of tablespaces 0% Data manipuluation should be done by queries, not by utilities

13 Kontinuierliches Risiko Assessment: Gebiet 3 (von 4): Verfügbarkeit Risiko Indikator Elapsed time für Recovery Messung (mind. täglich) Ist Schätzung der elapsed time für Tablespace/Index Recovery/Rebuild innerhalb SLA Limite? 200% time A 100 x max(tspce recovery time estimation ) SLA recovery time 0% A predictable outage time is always better than an unpredictable, even if it lasts longer

14 Kontinuierliches Risiko Assessment : Gebiet 4 (von 4): Effizienz (Performance) Risiko Indikator Query CPU Verbrauch Messung (täglich) Ist das Verhältnis von CPU Verbrauch pro durchgeführtem Query innerhalb vordef. Grenzen und tendenziell sinkend? 100 msec time E sum of CPU sec used total no of queries 0 msec Eventually, applications are always judged by their response times

15 Kontinuierliches Risiko Assessment: Gebiet 5 (von 4!): DSNMSTR Risiko Indikator Anzahl schwerer, spezifischer Fehlermeldungen C I A E Messung (täglich) K Ist die Anzahl spezifischer Fehlermessages angemessen? time time no of messages of selected types in DSNMSTR, no of total rows written to DSNMSTR 0 0

16 Evaluation von Risiko Indikatoren Kontrollen gelten als schwach, C falls Wert einmal rot oder mehr als zweimal hintereinander gelb ist mittel, falls Wert nur vereinzelt im gelben Bereich liegt I stark, falls Wert stets in der grünen Zone liegt A E

17 Kontinuierliches Monitoring (1/7): Scans von Kundendaten Risiko Indikator Kundendaten veröffentlicht Messung (häufig) Gibt es ungewöhnliche Scans durch Kunden Datenbestände? audit report *) of dynamic statement cache content C E durch Mobiliar s M3 tool gemessen

18 Beispiel von Kundenadress-Scan durch user U100997

19 Kontinuierliches Monitoring (2/7): Entdeckung von Datenbank Befehlen Risiko Indikator Datenbank Integrität zb durch STA ACCESS(FORCE) command gefährdet Messung (häufig) Gibt es undokumentierte d STA DB( ) SP ( ) ACCESS(FORCE) commands? log analysis reports *) DSN1LOGP: LRSNSTART(C57ABDE3B9A0) LRSNEND(C57ABF01D3D0) TYPE(10) (SUBTYPE(82) zeigt sta access force commands, aber ohne User Informationen) C I durch DSN1LOGP gemessen

20 DSN1LOGP (Type/Subtype Report) List of selected log records LOAD Analysis Intermediate Result Set Tables DSN2LOGP Type / Subtype Report

21 Kontinuierliches Monitoring (3/7): Trigger-Regeln überschrieben Risiko Indikator Trigger-basierende Daten Integritätsregeln verletzt Messung (täglich) Gab es im letzten Beobachtungsintervall Utilities, welche u.u. triggerbasierende Integritätsregeln verletzten? C I catalog query

22 Wurde diese Recovery Aktion dokumentiert? Wurden die Trigger-basierten Regeln danach nachweislich überprüft?

23 Kontinuierliches Monitoring (4/7): Zyklische Ref. Integrity Definitionen Risiko Indikator Daten Inkonsistenzen Messung (monatlich) Existieren zyklische RI- Strukturen in den Daten Schemen? catalog query SYSIBM.SYSRELS T1 T3 T4 Zyklen: T3 T3 T4 T8 T7 T4 I T8 (und T8 T7 T4 T8 etc.) T6 T7 Siehe Query Details auf Notizenseite 26

24

25 Kontinuierliches Monitoring (5/7): Tablespace/Index Wiederherstellungs Zeit Risiko Indikator Hohe Ausfallzeit von Anwendungen Messung (2x täglich) Liegt die Schätzung der längsten erwarteten Wiederherstellungszeit innerhalb der SLA Limite? A catalog query to estimate recovery time for all tablespaces, and rebuild/recover time for all indexes

26

27 Kontinuierliches Monitoring (6/7): Physische Dataset Limiten Risiko Indikator Nicht verfügbare Ressourcen aufgrund Erreichens physischer Limiten Messung (täglich) Welche Objekte sind nahe an ihrer maximal möglichen Ausdehnung? Address "ISPEXEC "LMDINIT LISTID(db2ds) LEVEL(DB2P.DSNDBD.*)" "LMDLIST LISTID(&db2ds) OPTION(SAVE)STATS(YES) GROUP(DB2P)" "LMDFREE LISTID(&db2ds) REXX LOAD A filled resources 100 x max ( ) available resources SQL COMPARE LOAD

28 Kontinuierliches Monitoring (7/7): Pageset I/O Aktivität Risiko Indikator Lange resp. länger werdende Antworzeiten wegen intensiver I/O Verarbeitung Messung (täglich) Untersuche, ob I/O Aktivität pro Pageset oder pro Applikation ansteigt -STA TRACE(P) C(30) IFCID(198) DEST(SMF) SORT LOAD E -STO TRACE(P) C(30) time IFCID(198) pfm trace analysis Analyze

29 ! DBNAME! IXNAME! NO_OF_IO! BUFFERPOOL! _! DPVERT! XVERDAD2! 844! BP2! 2_! DPVERT! XPA09411! 323! BP2! 3_! DPVERT! XPA97921! 30! BP2! 4_! DPVERT! XPA08007! 24! BP2! 5_! DPVERT! XVERDAD4! 14! BP2! 6_! DPVERT! XBA08011! 5! BP2! 7_! DPGESCH! XGESGBA5! 4! BP2! 8_! DPAFTRG! XPA56002! 3! BP2!

30 Kontinuierliches Monitoring: Weitere Reports Access Matrix Detail Informationen vergebener Zugriffsrechte Detaillierte Performance Reports Detail Reports aus dem Dynamic Statement Cache E Liste nicht (mehr) benutzter Indexes Indexes welche nie für Zugriff verwendet werden (ohne unique und clustering Indexes) Verlorene Optimizer Hints C Optimizer Hint nach Re-Bind verloren Liste von Usern mit Admin Rechten SYSADM, INSTALL SYSADM, etc. A E E C

31 Zusammenfassung aus Auditor Sicht Kontinuierliches Assessment von Risiko Indikatoren Z.B. mit Beispiel Prozeduren aus Teil 1 Prüfe interne Kontrollen mit Reports aus Teil 2 Sind Reports verfügbar und aktuell? Ja: Analysiere Resultate über längeren Zeitraum Nein: Führe Prozeduren selbst durch, falls Resultate ok sind, müssten kompensierende Kontrollen vorhanden sein; falls nicht, rapportiere entsprechende Schwachstellen und deren Risiken

32 Zusammenfassung aus DBA Sicht Erstelle und veröffentliche Risk Indikatoren Z.B. Prozeduren aus Teil 1 Führe kontinuierliches Risiko self-assessment durch (mit Prozeduren aus Teil 2) Analysiere Anzahl Exceptions und deren Art über längeren Zeitraum

33 Zusammenfassung: 5 Tipps Audit Unabhängigkeit Auditoren und DBA sollten nicht dieselben Reports verwenden Mehr Audit Unabhängigkeit Auditoren und DBA sollten verschiedene Datenquellen nutzen Verwende kontinuierliches Risiko Assessment sowohl auf Audit wie auf DBA Ebene Stay patched! Dehne Audit Scope auf alle Aspekte der Informations Sicherheit aus Vertraulichkeit, Integrität, Verfügbakeit, aber auch Effizienz (Performance)

34 Vielen Dank!

35 Referenzen IDUG NA and European Conference 2008 Proceedings Session B01 (IDUG Europe): Memory Management for Dynamic SQL Dansk IT-Sikkerhedsforum Audit Guideline for DB2, Copenhagen, October 2002 Implementing Database Security and Auditing Ron Ben Natan, Elsevier Digital Press, ISBN Security, Audit and Control Features Oracle Database 3 rd Edition, ISACA, ISBN ISACA Journal, Vol.6, 2009 Achieving Continuous IT Auditing, pp.37-41

36 Thomas Baumann