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.
expertpaper Validierung im Rechenzentrum | Seite 3
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.
expertpaper Validierung im Rechenzentrum | Seite 4
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· CPU: 2· RAM: 12 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
· VMWare system· SUSE Linux SLES 11· CPU: 2· RAM: 12 GB· Disk: 200 GB· Wily Introscope 9
Prod
uctio
n
BWWily EM
Wily EM
Wily MoMSolution ManagerSLD
Prod
uctio
n
Prod
uctio
n
expertpaper Validierung im Rechenzentrum | Seite 5
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
expertpaper Validierung im Rechenzentrum | Seite 6
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.
expertpaper Validierung im Rechenzentrum | Seite 7
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
expertpaper Validierung im Rechenzentrum | Seite 8
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
expertpaper Validierung im Rechenzentrum | Seite 9
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.
expertpaper Validierung im Rechenzentrum | Seite 10
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.
expertpaper Validierung im Rechenzentrum | Seite 11
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.
expertpaper Validierung im Rechenzentrum | Seite 12
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.