Revisionssichere Archivierung der Batchproduktion in einem BMC CONTROL-M/DS Umfeld unter Nutzung der ATICS Lösung

Transkript

1 Revisionssichere Archivierung der Batchproduktion in einem BMC CONTROL-M/DS Umfeld unter Nutzung der ATICS Lösung ATICS-Tage 18./19.Juni 2009 Andreas Kaiser Seite: 1

2 Agenda Warum Joblogarchivierung im DS Umfeld? Problematik aus der Sicht der Gesetzgebung Jobscheduling und Regulatory Compliance Lösungsmöglichkeit und Problematik Die ATICS Schnittstelle Beispiel CONTROL-M an verschiedene Outputmanagement-Systeme Fazit 2009 Seite: 2

3 Warum Joblogarchivierung im DS Umfeld? Betriebsprozesse eines Unternehmens werden sowohl in einer Software Application (z.b. SAP) als auch in der Batchverarbeitung abgebildet. Oft abhängig voneinander. Beide Verfahren dokumentieren je nach Einstellung in unterschiedlicher Ausprägung die Updates der Prozesse durch Logs unterschiedlicher Kategorien bzw. Job-Reports. Diese digitale Datenbasis ist die Grundlage für Wirtschaftprüfer, Revisoren und Auditoren, um u.a. Auffälligkeiten zu lokalisieren und so als Früherkennung Unternehmensrisiken zu minimieren Seite: 3

4 Problematik aus Sicht der Gesetzgebung Regulatory Compliance Regulatory Compliance bedeutet die Einhaltung von gesetzlichen Vorgaben, die für die Unternehmen gelten Unterschiedlichste Regularien (national und international) definieren die einzuhaltenden Richtlinien mit der einheitlichen Zielsetzung von Transparenz und Nachvollziehbarkeit von Unternehmensprozessen Was bedeutet Compliance für Jobsteuerung, Scheduling? Die Umsetzung von Regularien wird nach unserer Überzeugung die Batch-Operationen erheblich beeinflussen, gerade auch mit Blick auf plattformübergreifende Prozesse. Seite: 4

5 Problematik aus Sicht der Gesetzgebung Regulatory Compliance 2009 Nationale Vorschriften HGB KonTrag BVerfG BDSG GdPdU Internationale Vorschriften Sarbanes-Oxley Act (SOX) Consumer Privacy Protection Act HIPAA (Gesundheitswesen) Basel II (Kreditwesen) Es handelt sich bei der Darstellung um einen kleinen Ausschnitt vorhandener Vorschriften... Seite: 5

6 Problematik aus Sicht der Gesetzgebung Regulatory Compliance 2009 * Compliance is required for private sector companies only. Public sector companies do not have to comp Regulation All Businesses Financial Insurance Banking Services SOX X PIPEDA X* GLBA X X X CA SBs 1386 and 1950 X Source: IDC, 2005 PIPEDA SOX GLBA Canadian Personal Information Protection and Electronic Documents Act Sarbanes-Oxley Act Gramm-Leach-Bliley Act Empfehlung für Aufbewahrungsfristen von Log-Daten: Basel II 3 7 Jahre SOX 7 Jahre Seite: 6

7 Problematik aus Sicht der Gesetzgebung Compliance Anforderungen der unterschiedlichen Regulierungen Sicherheit (Transparenz von Richtlinien) Datenschutz und Datentransfer wer? 2009 Prozessmanagement (Überwachung der Betriebsprozesse) Batch, Filetransfer, Datensicherung was? Reporting (Datenqualität & Datenverfügbarkeit) wann? Audit Joblogs, Systemlogs, Application Logs Recordmanagement (Archivierung Compliance relevanter Daten) Vollständige Sicherung aller produzierten Prozess-Logs Seite: 7

8 Problematik aus Sicht der Gesetzgebung 2009 Die Umsetzung dieser vier genannten Hauptaspekte bringen Unternehmen in eine Ausgangsposition, auf künftige Regulierungsanforderungen schnell und effektiv zu reagieren. Seite: 8

9 Datensicherungsmaßnahmen nicht erst seit SOX! Alle Organisationseinheiten eines Unternehmens, die in ihren Betriebsprozessen Unternehmensdaten verändern, müssen Maßnahmen zur Gewährleistung der Datensicherheit treffen (z.b. 321 Abs. 4 des HGB) 2009 Dabei ist je nach Art der produzierten Daten nach unterschiedlichen Richtlinien zu verfahren. Hier schreibt der Gesetzgeber unterschiedliche Aufbewahrungsfristen vor, jedoch gilt für die Gesamtheit aller Daten eines Unternehmens: Datensicherung ist auch Log-Sicherung Seite: 9

10 Datensicherungsmaßnahmen 2009 Ordnungsgemäße, sichere, transparente und nachvollziehbare Archivierung von Protokolle, die in ihrem Ergebnis eine betriebswirtschaftliche Relevanz darstellen. Seite: 10

11 Jobscheduling und Regulatory Compliance Betriebsprozesse eines Unternehmens werden sowohl in einer Software Application (z.b. SAP) als auch in der Batchverarbeitung abgebildet, oft abhängig voneinander 2009 Beide Verfahren dokumentieren je nach Einstellung in unterschiedlicher Ausprägung die Updates der Prozesse durch Logs unterschiedlicher Kategorien bzw. Job-Reports. Diese digitale Datenbasis ist die Grundlage für Wirtschaftprüfer, Revisoren und Auditoren, um u.a. Auffälligkeiten zu lokalisieren und so als Früherkennung Unternehmensrisiken zu minimieren Seite: 11

12 Jobscheduling und Regulatory Compliance 2009 Nur Unternehmen, die die Gesamtheit aller Daten archivieren (System-Logs, Job- Logs und Betriebsdaten) können jederzeit vorhandene und zukünftige Compliance-Anforderungen erfüllen. Seite: 12

13 Ein Beispiel: SAP R/3 in einem Unternehmen Ein SAP Report wird mit einer Wechselkurs- Variante ausgeführt, der Wert ( ) der Variante ist nur auf dem Deckblatt der Spool-Liste verfügbar 2009 Eine Weiterverarbeitung der Daten in ein Datawarehouse erfolgt mittels Filetransfer (File Transfer Log) Der SAP Report ist beispielsweise ein Betriebsprozess nach 321 Abs. 4 des HGB, der Unternehmensdaten verändert und Variablen enthält, die sich im Laufe der Zeit verändern (Wert Wechselkurs Variante). Daher müssen hierfür Maßnahmen zur Datensicherheit getroffen werden. Seite: 13

14 Ein Beispiel: 2009 Durch die Archivierung des Jobreports und die Archivierung der SAP XMI Log kann dieser Betriebsprozess langfristig entsprechend nachgewiesen werden. Seite: 14

15 Die Forderungen Protokoll-Informationen aus Quellen wie Schedulern und Betriebssystemen oder Datenbankanwendungen müssen zentral verarbeitet und archiviert werden Eine übersichtliche und revisionssichere Datenhaltung über lange Zeiträume soll ermöglicht werden. Weiterer Benefit, wenn diese Forderungen eingehalten werden: IT-Auditoren können durch Analyse dieser Prozessinformationen prüfen, ob Workflows den gesetzlichen Richtlinien entsprechen Seite: 15

16 Lösungsmöglichkeit Job Scheduler geben Prozess- und Loginformationen aus 2009 Scheduler: UC4 CONTROL-M/DS von BMC $UNIVERS von Orsyp Tivoli Workload Scheduler von IBM Cronacle von Redwood Autosys Workload Automation von CA ESP Workload Automation von CA Seite: 16

17 Lösungsmöglichkeit Output Management Systeme verarbeiten und archivieren diese 2009 Output Management Systeme: Beta UX History Management von Betasystems ReportSafe von NuPSoft CONTROL-D (WebAccess) von BMC ABER: Die Daten aus den Job Schedulern können nicht 1:1 im Output Management System verarbeitet werden. So fehlt z. B. jegliche Möglichkeit die Protokolle zu indizieren um sie im OMS wieder zu finden. Seite: 17

18 Problematik Ein Zugriff auf ältere SYSOUTs ist nur dann möglich, wenn diese vorher EXTERN gesichert wurden (TSM, LEGATO, VERITAS,...) und auch nur direkt auf dem Rechner, auf dem dieser angelegt wurde Die Probleme des Online-Viewings auf einem entfernten WINDOWS-Rechner kommen noch dazu 2009 Die SYSOUTs und auch die Protokolle werden aus Plattenplatz und Datenbank technischen Gründen nur eine bestimmte Zeit vorgehalten (Default 1-2 Tage verschieden je nach Scheduler) Eine Selektion der Logdaten nach dieser Zeit ist im Prinzip nur dem Server Administrator möglich Seite: 18

19 ATICS-Schnittstelle Von der wurde ein Tool entwickelt, das SYSOUT/Logdateien des CONTROL-M/Server an JEDES Output-Tool weiter gibt Damit ist man in der Lage, SYSOUT und CTMLOG sofort nach Jobende zu spoolen. Runcounts können bei der CTMLOG berücksichtigt werden (z.b. bei RERUN sieht man auch nur die CTMLOG-Einträge des RERUN Laufes!) Einsatz eines zentralen Programms Einsammeln der vorhandenen Jobprotokolle. Pro Joblauf werden JOBLOG und SYSOUT in einem File zusammengefasst. Innerhalb dieses Files wird jeweils eine IDENT-Zeile eingesteuert, die eine klare Zuordnung im Output- Management System zulässt. Seite: 19

20 Beispiel CONTROL-M CONTROL-D 2009 CONTROL-M Z/OS-Job CONTROL-M/Server SYSOUT + CTMLOG SHOUT-Destination CONTROL-D/V Z/OS FTP ATICS- Schnittstelle UNIX Z/OS In einem frei wählbaren Zeitintervall werden alle CONTROL-M Jobprotokolle eingesammelt und per FTP an den HOST transferiert Seite: 20

21 Beispiel CONTROL-M CONTROL-D Übersicht gefundene Protokolle 2009 Seite: 21

22 Beispiel CONTROL-M CONTROL-D Anzeige des archivierten UNIX Jobprotokolls über Webbrowser 2009 Grüne Leselinien werden hinterlegt. Links oben steht das Firmen Logo. Seite: 22

23 Beispiel CONTROL-M Reportsafe 2009 CONTROL-M/Server SYSOUT + CTMLOG ReportSafe Server ATICS-Schnittstelle TCP/IP Printqueue MS WINDOWS UNIX Basiert auf LPR/LPD Protokoll Webbasierter Zugriff auf die Dokumente Regelbasierte Verteilung der Dokumente möglich. "WYSIWYG" Darstellung, auch für die Regelerstellung der Verteilung Seite: 23

24 Beispiel CONTROL-M Reportsafe Übersicht der einzelnen Protokolle 2009 Seite: 24

25 Beispiel CONTROL-M Reportsafe 2009 Ansicht JOBLOG und SYSOUT Seite: 25

26 Beispiel CONTROL-M Beta UX 2009 CONTROL-M/Server SYSOUT + CTMLOG ATICS-Schnittstelle incl. Beta- Programm für Transfer TCP/IP Beta UX EMC Centerea oder TSM Interface UNIX Seite: 26

27 Beispiel CONTROL-M Beta UX Übersicht der einzelnen Protokolle 2009 Seite: 27

28 Beispiel CONTROL-M Beta UX Das CONTROL-M Log 2009 Seite: 28

29 Beispiel CONTROL-M Beta UX Der SYSOUT 2009 Seite: 29

30 Beispiel CONTROL-M Filesystem 2009 CONTROL-M/Server SYSOUT + CTMLOG ATICS-Schnittstelle Printqueue UNIX TCP/IP Beliebiges Filesystem EMC Centerea oder TSM Interface oder??? Seite: 30

31 Beispiel CONTROL-M Filesystem Web 2009 Seite: 31

32 Fazit 2009 Die Notwendigkeit, dass Prozess- und Protokolldaten langfristig archiviert werden müssen wurde erkannt. Die verschiedenen Outputmanagement- Systeme sind darauf eingestellt. Unsere Schnittstelle unterstützt diese OMS, damit auch langfristige Archivierung und Wiederfinden erreicht wird. Seite: 32

33 Vielen Dank für Ihre Aufmerksamkeit! 2009 Seite: 33