Validierung im Rechenzentrum - SAP Solutions · PDF fileüberwachen wir mit Nagios und mit dem SAP Solution Manager. ... · SAP SolMan used as BI ... !4 1 5

In unseren Rechenzentren betreiben wir etliche Kundensysteme, die auf-

grund diverser gesetzlicher Vorgaben qualifiziert oder validiert betrieben

werden müssen.

Validierung im Rechenzentrum

Die Validierung eines Systems wird beispielsweise von folgenden Regularien gefordert:

■ SOX (Sarbanes-Oxley Act) oder ISAE No. 3402 (International Standard on Assurance

Engagements)

■ IT-Sicherheitsmanagement nach ISO/IEC 27001

■ Good Automated Manufacturing Practice (GAMP, GxP)

■ Payment Card Industry Data Security Standard (PCI DSS)

■ Zahlungsdienstleistungsaufsichtsgesetz (ZAG, BaFin)

Wo liegt der Unterschied zwischen Qualifizierung und Validierung?

Eine Validierung ist notwendig, wenn das zu untersuchende System kritische Daten direkt ver-

arbeiten kann, zum Beispiel bei GxP-relevanten ERP-Systemen. Die weniger aufwändige Qua-

lifizierung kommt zum Einsatz, wenn das zu untersuchende System selbst keinen direkten Zu-

gang zu solchen Daten besitzt – aber ein System steuert oder überwacht, das wiederum über

den direkten Datenzugang verfügt. Ein System zu qualifizieren bedeutet, den Nachweis zu er-

bringen, dass es nach gewissen vorgegebenen Standards und Regeln aufgebaut wurde. Validie-

rung bietet darüber hinaus den Beweis, dass ein System den zuvor definierten Anforderungen

genügt.

Wozu ist das notwendig?

Sicherlich haben Sie schon von Rückrufaktionen im Automobilbereich oder in der Pharma- und

Lebensmittelbranche gehört. Wenn verunreinigte Produkte zurückgerufen werden oder Bautei-

le ersetzt werden müssen, weil sie die Funktion gefährden, ist dies nur mit einer guten Daten-

pflege machbar. Zugleich muss aber auch gewährleistet sein, dass die Systeme eine solche Da-

tenkonsistenz sicherstellen. Und genau da setzen Qualifizierung und Validierung an. Die

ordnungsgemäße Funktion wird anfänglich geprüft und durch ein sauberes Change-Manage-

ment fortgeschrieben.

Der Betrieb von qualifizierten und validierten Systemen führt zu einem erhöhten Dokumenta-

tionsaufwand. Änderungen müssen zwar auch für andere Systeme nachvollziehbar dokumen-

tiert werden, doch sind die Anforderungen hier deutlich höher. Nach einer Änderung muss das

System ggf. erneut geprüft, das heißt re-validiert oder erneut qualifiziert werden. Und diese Do-

kumentation muss externen Auditoren standhalten. Ein hoher Anspruch, den die Kolleginnen

und Kollegen in unseren Rechenzentren erfüllen.

AG ■ Königsbreede 1 ■ D-33605 Bielefeld ■ Telefon: +49 (0) 5 21/9 14 48-0 ■ Fax: +49 (0) 5 21/9 14 45-100 ■ www.itelligence.de

expertpaper Validierung im Rechenzentrum | Seite 2

Ein Beispiel

Validierung der itelligence Monitoring-Landschaft

Wir können die Systeme unserer Kunden nicht unbeaufsichtigt betreiben. Da es sich um eini-

ge hundert Systeme handelt, kommt ein automatisches Monitoring zum Einsatz: SAP-Systeme

überwachen wir mit Nagios und mit dem SAP Solution Manager.

Mit dem neuen Solution Manager 7.1 hat SAP das Monitoring komplett umgebaut und neben

das alte CCMS die neue Monitoring and Alerting Infrastructure (MAI) gesetzt, die wir nun nut-

zen wollen. Im Rahmen der Umstellung befassen wir uns zurzeit mit der Validierung dieses neu-

en Monitorings.

Der Validierungsprozess besteht aus mehreren Schritten:

1. Risikobewertung Anhand einer Checkliste wird ermittelt, ob eine Qualifizierung oder Validierung erforderlich

ist.

2. AnforderungsspezifikationEin Lastenheft entsteht, aus dem die Funktionen des Tools hervorgehen. Aus diesem Lasten-

heft werden später Testpläne abgeleitet.

3. RisikoanalyseEtwaige Schwachstellen müssen beschrieben werden. Falls möglich, werden Maßnahmen er-

griffen, um die Schwachstellen zu mindern oder zu eliminieren. Die Risikoanalyse dient auch

zur Berechnung möglicher Schäden, die z. B. durch Vertragsstrafen entstehen können.

4. ValidierungsplanEin Validierungsplan wird erstellt, der genehmigt werden muss.

5. InstallationsplanDie einzelnen Schritte zum Aufbau des Systems werden beschrieben. Dabei wird auf vorhandene

Dokumentationen und Anleitungen verwiesen. Insbesondere der Verweis auf SAP Installa-

tion Guides ist hilfreich.

6. TestanleitungenAus der Anforderungsspezifikation werden Testpläne abgeleitet, mit denen ein ordnungsge-

mäßer Betrieb des Tools überprüft wird.


An die Planung der Validierung schließt sich die Umsetzung an, die wiederum in mehreren Schrit-

ten erfolgt. Die Umsetzung orientiert sich an der erstellten Planung.

1. InstallationDas Tool wird anhand des erstellten Plans installiert. Hierbei werden ggf. Angaben aus der

Anforderungsspezifikation umgesetzt. Abweichungen von der Planung aufgrund von uner-

warteten Fehlersituationen oder Neuerungen werden dokumentiert.

2. TestprotokolleDie geplanten Tests werden durchgeführt und protokolliert. Abweichungen werden doku-

mentiert und möglichst behoben.

3. ValidierungsberichtDie Testprotokolle werden in einem Validierungsbericht zusammengefasst.

Danach wird das Tool an den Betrieb übergeben. Änderungen unterliegen dem Change-Ma-

nagement, das bei Bedarf Revalidierungen einleitet. Zudem wird im zweijährigen Rhythmus ge-

prüft, ob eine grundlegende Revalidierung notwendig ist. Falls nicht, muss dies begründet wer-

den.

Bei der Revalidierung werden die genannten Schritte erneut durchgeführt. Sie baut, wenn mög-

lich, auf den bereits erstellten Validierungsplan und die Testanleitungen auf.


Aufbau der produktiven Monitoring-Landschaft

Im Rahmen des automatischen Monitorings werden diverse Komponenten benutzt – so zum

Beispiel

■ SLD (Software Landscape Directory) – ein J2EE-basiertes Verzeichnis der installierten Systeme

■ SAP BW als zentrale Datenhaltung der eingesammelten Monitoring-Daten

■ MAI als Teil des SAP Solution Managers

■ Wily Introscope für die Überwachung von J2EE-Systemen

Außerdem nutzen wir den Solution Manager für die Bereitstellung von Early Watch Alerts (EWA)

und für Maintenance Optimizer Transactions.

Aus Performance-Gründen haben wir uns entschieden, die Komponenten zu entkoppeln und

auf verschiedene Systeme zu verteilen. Dies wird nach unseren Überlegungen auch die Wartung

und Weiterentwicklung der Monitoring-Landschaft, die in der folgenden Grafik dargestellt ist,

vereinfachen.

Denkbar ist, jedes einzelne System zu validieren. Wir teilen jedoch die gesamte Landschaft in

Module auf, die einzeln validiert werden, um eine Revalidierung deutlich zu vereinfachen. Wir

versprechen uns davon eine höhere Transparenz der Validierung und eine erhebliche Reduzie-

rung des Aufwands bei anstehenden Änderungen.

· VMWare system· SUSE Linux SLES 11· Sybase ASE database· CPU: 2· RAM: 8 GB· Disk: 200 GB· SAP NW 7.31 standalone SLD

· VMWare system· SUSE Linux SLES 11· Sybase ASE database· CPU: 4 (6)· RAM: 32 (48) GB· Disk: 400 (500) GB· SAP Solution Manager 7.1 SP11

· VMWare system· SUSE Linux SLES 11· CPU: 2· RAM: 4 GB· Disk: 200 GB· Wily Introscope 9


· VMWare system· SUSE Linux SLES 11· Sybase ASE database· CPU: 4· RAM: 32 GB· Disk: 700 GB· SAP SolMan used as BI


Prod

uctio

n

BWWily EM

Wily EM

Wily MoMSolution ManagerSLD

Prod

uctio

n

Prod

uctio

n


Bei der Validierung durchlaufen die einzelnen Module sämtliche Prozessschritte, die dafür not-

wendig sind. Allerdings fassen wir Dokumente zusammen, wo es möglich ist. So wird es bei-

spielsweise nur eine Anforderungsspezifikation geben, also ein Lastenheft für die gesamte Land-

schaft. Die Testpläne werden jedoch auf Modulebene

Betriebssystem

Datenbank

SAP Solution Managerincl . System Preparation und Basic Configuration

LMD

B(L

ands

cape

Mgm

t. D

atab

ase)

MAI

(Mon

itorin

g an

d Al

ertin

gIn

fras

truc

ture

)

Man

aged

Sys

tem

Se

tup

EWA

(Ear

ly W

atch

Ale

rt)

MO

pz(M

aint

enan

ce O

ptim

izer

)

MonitoringTemplates

Alert Mails

ExtS

ID

Gen

erat

or

Betriebssystem

Datenbank

SAP Netweaver SLD

Betriebssystem

Datenbank

SAP Solution Managergenutzt als BW

Betriebssystem

CA Wily Introscope

itelli

genc

e Ei

gene

ntw

ickl

unge

n

ExtS

ID

Monitoring

Alert Mails

Gen

erat

orLM

DB

)

)

Setu

p

WA

emplatesGen

erat

orD

atab

ase

. La

ndsc

ape

Mgm

t

Infr

astr

uctu

reM

onito

ring

and

Aler

ting

(M

AI

Man

aged

Sys

tem

E

TTe

)

Mai

nten

ance

Opt

imiz

er)

Eige

nent

wic

klun

gen

atch

Ale

rtEa

rly W

(

WA

E

(

MO

pz

itelli

genc

e

Betriebssystem

Datenbank

SAP Netweaver SLD

Betriebssystem

Datenbank

System Preparation und Basic Configuration

Land

scap

e M

gmt

. inclSAP Solution Manager

(

Betriebssystem

System Preparation und Basic Configuration

Betriebssystem

genutzt als BWSAP Solution Manager SAP Solution Manager

Betriebssystem

Datenbank

genutzt als BW

Betriebssystem

CA Wily Introscope

SAP Solution Manager

Betriebssystem

CA Wily Introscope


Die Anforderungsspezifikation

Im Lastenheft werden sämtliche Anforderungen, die an die Monitoring-Landschaft gestellt wer-

den, beschrieben. Da dieses Dokument für die gesamte Landschaft gelten soll, ist es recht um-

fangreich und besteht zurzeit aus ca. 60 Seiten. Neben einleitenden Abschnitten, die zum Vali-

dierungs-Overhead gehören, finden sich Kapitel zu den einzelnen Modulen unserer Landschaft.

Im Folgenden möchten wir nicht das gesamte Lastenheft präsentieren, sondern lediglich einige

Details benennen:

Externe Dokumente: Im Lastenheft verweisen wir häufig auf externe Dokumente – beispiels-

weise Verfahrens- und Arbeitsanweisungen unseres Qualitätsmanagements oder Installations-

leitfäden von SAP. Damit gehen die referenzierten Dokumente in die Validierungsdokumenta-

tion ein und müssen reproduzierbar gespeichert und teils sogar ausgedruckt werden. Wir sammeln

solche Dokumente zunächst in einem speziellen Verzeichnis. Der Verweis auf Internet-Quellen

reicht nicht, da der Link später eventuell nicht mehr gültig ist.

Vorgaben für die Installation: Damit die Installationspläne kurz gehalten werden können, be-

schreiben wir bereits im Lastenheft die Vorgaben für die Installation. Der Installationsplan ver-

weist dann einfach auf ein Kapitel der Anforderungsspezifikation. So enthält das Lastenheft die

Aufteilung der Festplattenbereiche ebenso wie die Details der Grundkonfiguration eines Solu-

tion Managers.

Dokumentation: Im Abschnitt zum Thema Dokumentation wird festgelegt, wo das Betriebs-

führungshandbuch, das Berechtigungskonzept und weitere Dokumentationen hinterlegt sind.

Abschließend werden auch Schulungs- und Qualifizierungsmaßnahmen benannt sowie die Zu-

ständigkeiten für die Monitoring-Landschaft definiert.


Die Risikoanalyse

Jede Validierung erfordert eine Risikoanalyse. Aber was ist überhaupt ein Risiko? Ein Risiko tritt

ein, wenn ein System gewissen Gefahren ausgesetzt ist. Zu jeder Gefahr lassen sich die Ein-

trittswahrscheinlichkeit und der Schaden ermitteln. Diese Kennzahlen können mit verschiede-

nen Einheiten angegeben werden.

In unserem Rechenzentrum genügt nach Absprache mit externen Prüfern die Klassifizierung in

die Risikoklassen gering / mittel / hoch.

Das Risiko selbst ergibt sich dann nach folgender Formel:

Die Ergebnisse der Multiplikation werden in der Spalte „Kritikalität“ hinterlegt und sind wie

folgt definiert:

Eine Herausforderung der Risikoanalyse ist die Bewertung von Auftrittswahrscheinlichkeit und

Auswirkung. Es gibt diverse Normen, die sich mit dem Thema „Risikomanagement“ befassen

und in unserem Rechenzentrum zum Einsatz kommen. Unsere Zertifizierung gemäß ISO 27001

und unser Qualitätsmanagement nach ISO/IEC 20000-1 erfordern ein Risikomanagement. Pro-

jektmanagement-Empfehlungen (z. B. der GPM, IPMA) oder DIN 69901 beschreiben ebenfalls

Vorgehen und Prozesse, u. a. für die Bewertung von Wahrscheinlichkeiten und Auswirkungen.

ID Anf.-Nr. Beschreibung GxP-relev. [J/N]

M / IT

Fehler/Fehlverhalten/Schaden

Auftritts-wahrschein-

lichkeit Auswirkung Kritikalität

Maßnahmen zur Risikovermeidung, -minimierung, -kontrolle

Bemerkungen

1 1.1 In der Landschaft sollen später weitere Funktionen genutzt werden. Dies kann die validierten Funktionen beeinträchtigen.

J M, IT Ausfall des Monitorings Ausfall des Maintenance Optimizers Fehlende Daten im Reporting

Gering Hoch Kritisch

Die Monitoring Landschaft wird modular aufgebaut und validiert. Kommen neue Module (Funktionen) hinzu, ist im Einzelfall zu prüfen, inwieweit eine Re-Validierung existierender Module erforderlich ist. Neue Module sind in jedem Fall zu validieren.

2 2.1 Es ist keine separate Testlandschaft vorgesehen. Tests werden im Entwicklungssystem vorgenommen.

N IT Im Entwicklungssystem könnten Tests durch parallele Entwicklungen beeinflusst werden.

Gering Mittel Unkritisch

Parallele Entwicklungen werden weitestgehend vermieden. Es gibt in der Monitoring Landschaft relativ wenige Entwicklungen. Im Bedarfsfall kann ein Testsystem temporär aufgebaut werden (z.B. als VMWare Clone).

Auswirkung

Eintrittswahrscheinlichkeit gering mittel hoch

gering unkritisch unkritisch kritisch

mittel unkritisch un-/kritisch kritisch

hoch unkritisch kritisch kritisch

Risiko = Eintrittswahrscheinlichkeit × Schaden


Ziel der Risikoanalyse ist es, Maßnahmen zur Reduzierung der Risiken zu ergreifen. Dazu müs-

sen zunächst die Risiken vollständig benannt werden. Risiken zurückzuhalten ist nicht zielführend,

weil das Risiko damit nicht ausgelöscht wird. Auch im Kundenkontakt ist es sinnvoller, Risiken

offen anzusprechen und ergriffene Maßnahmen offensiv zu kommunizieren.

Die Liste der Risiken ist nie vollständig. Neue Risiken kommen mit neuen Techniken oder ver-

änderten Prozessen hinzu. Externe Einflussfaktoren (z. B. Gesetze, Richtlinien) ändern sich. Um

ein möglichst umfassendes und aktuelles Bild zu erhalten, diskutieren wir die Risiken regelmäßig

im Expertenteam. Dabei werden neue Risiken erkannt und mögliche Gegenmaßnahmen be-

sprochen. So umfasst unsere Risikoanalyse für die Monitoring-Landschaft inzwischen über 70

Gefahren. Einige Risiken haben wir als „kritisch“ eingestuft, dazu zählen neben technischen Ge-

fahren auch:

■ Verstöße gegen das Change Management

■ Mängel im laufenden Betrieb


Der Installationsplan

Der Risikoanalyse folgt der Validierungsplan. Ist dieser erstellt, folgt der Installationsplan, der

sich ebenfalls an der Anforderungsspezifikation orientiert: Er beschreibt die Installation jeder

einzelnen Komponente. Der Plan selbst dient als Checkliste, die Vorgaben zur Installation sind

dem Lastenheft zu entnehmen.

Ein beispielhafter Ausschnitt:

Da wir im Rahmen unserer Monitoring-Landschaft mehrere Systeme aufsetzen, müssen einige

im Installationsplan definierte Arbeiten im Rahmen der Installation auf jedem System durch-

geführt werden. Im Plan beschreiben wir diese Schritte nur einmal, das später anzufertigende

Protokoll enthält jedoch für jedes einzelne System ein Ergebnis.


Die Testanleitungen

Nach dem Installationsplan werden die Testanleitungen erstellt.

Häufig werden die Testpläne dabei als Kontrolle angesehen, ob Systeme richtig installiert wur-

den. Dies ist allerdings eine Fehlinterpretation. Mit den Tests soll verifiziert werden, dass die

Systeme einsatzbereit sind und den Anforderungen genügen. Bei solch komplexen Systemen wie

der beschriebenen MAI-Monitoring-Landschaft können immer einmal Probleme auftreten oder

Fehler gemacht werden. Tests bieten da eine letzte Chance, Korrekturen vor dem Go-Live vor-

zunehmen.

So stellen unsere Testanleitungen zum einen sicher, dass die installierten Systeme der Anforde-

rungsspezifikation genügen. Andererseits berücksichtigen sie aber auch die in der Risikoanaly-

se aufgeführten Kontrollen und Tests. Beide zuvor erstellten Dokumente, Anforderungsspezifi-

kation und Risikoanalyse, finden hier also Verwendung.

In der Testanleitung werden einzelne Testschritte aufgeführt. Für jeden Schritt ist anzugeben, ob

er direkt erfüllt werden konnte oder ob zuvor noch Korrekturen vorgenommen werden mus-

sten. Diese Anpassungen werden im Rahmen des Testprotokolls dann genauer beschrieben. Test-

protokolle können die Wissensdatenbank mit Fehlern und Lösungen anreichern. Es ist daher

unbedingt erforderlich, Tests nicht als Kontrolle der eigenen, individuellen Arbeit zu sehen, son-

dern als Abnahme eines bereitgestellten Systems.

Mit den Testanleitungen ist der Planungsprozess abgeschlossen – nun folgt die Umsetzung der

Validierung. Und die startet mit der Installation.

Die Installation

Die Installation der MAI Monitoring-Landschaft erfolgt auf Basis des Lastenheftes und des In-

stallationsplans.

Die Systeme sind mittels VMWare virtualisiert und werden über eine Software-Verteilung installiert.

Wir setzen dazu die HP Software Automation Suite (HPSA) ein. Erst wenn unser Serverma-

nagement-Team alle erforderlichen Dokumentationen erstellt hat, liefert die HPSA ein bereits

valides Betriebssystem.

Eine weitere Herausforderung ergibt sich aus der VMWare-Landschaft. Der Betrieb von virtua-

lisierten Systemen muss ebenfalls den Anforderungen der Validierung genügen. Die dazu er-

forderlichen Dokumente werden derzeit erarbeitet.


Testprotokolle und Validierungsbericht

Ist die Validierungslandschaft installiert, so werden die einzelnen Systeme anhand der Testpläne

geprüft und abgenommen. In den Testprotokollen wird vermerkt, ob es zu Abweichungen bei den

Testergebnissen gekommen ist und welche Korrekturmaßnahmen ggf. ergriffen wurden. Wenn all

diese Tests abgeschlossen sind, werden die Dokumente unterschrieben und archiviert. Diese Ak-

tivitäten stehen dann ebenfalls noch für die Produktivlandschaft an, bevor die Systeme letztlich

ihrer Bestimmung übergeben werden. Sämtliche Testprotokolle werden in einem Validierungsbericht

zusammengefasst. Danach ist die Validierung unserer MAI-Monitoring-Landschaft abgeschlossen.

Was ist bei Änderungen zu tun?

Wenn nach Freigabe von Dokumenten, z.B. der Anforderungsspezifikation, noch Änderungen

nötig werden, werden solche Nacharbeiten als Change dokumentiert, getestet und abgenommen.

Die Verwaltung der Dokumente

Die Validierung erfordert eine revisionssichere Ablage der verschiedenen Dokumente, denn die-

se müssen insbesondere vor Änderungen geschützt werden. Deshalb werden die Dokumente

üblicherweise ausgedruckt, unterschrieben und an einem sicheren Ort archiviert.

Die Dokumente liegen zunächst in elektronischer Form vor. Über eine geschickte Namensge-

bung gewährleisten wir die Wiederauffindbarkeit und eine gewisse Strukturierung der Doku-

mente. In größeren Projekten, die viele Dokumente umfassen, stellt dies eine echte Herausfor-

derung dar: Der Überblick geht schnell verloren, zumal Dokumente nach und nach erstellt und

teilweise laufend angepasst werden. Zur Namensgebung tritt also noch die Versionierung hin-

zu. Im Rahmen unserer Validierung werden die Dokumente mit einer Nummer versehen, die

sich auf das Validierungsmodell bezieht.

Eine softwaregestützte Dokumentenverwaltung (DMS) ist hier sehr hilfreich. Es ist jedoch dar-

auf zu achten, dass die Dokumente revisionssicher abgelegt sind, um den Anforderungen der

diversen Zertifizierungen (z.B. ISO 20000-1) gerecht zu werden. Mittels elektronischer Unter-

schriften lassen sich im DMS abgelegte Dokumente finalisieren und gegen künftige Änderun-

gen schützen. Dadurch wird der Umfang der auszudruckenden Dokumente reduziert.


Kurzvita

Dipl.-Math. Rainer Kunert

Der Validierungs- und Auditexperte sammelte seine langjährige Erfahrung als

SAP-Berater mit dem Schwerpunkt SAP-Security. Heute arbeitet Rainer Kunert

als Projektleiter zur Überwachung von SAP-Systemen im itelligence Rechen-

zentrum Bautzen.

Documents

Validierung im Rechenzentrum - SAP Solutions · PDF fileüberwachen wir mit Nagios und mit dem SAP Solution Manager. ... · SAP SolMan used as BI ... !4 1 5