Liebe Leserinnen und Leser, - BankPraktiker

Programmierer und Qualitätssicherer müssen
ihre Tätigkeit nachvollziehbar dokumentieren.
Die Nachvollziehbarkeit erhöht den Qualitätsdruck,
da der für Fehler Verantwortliche
im Nachhinein identifiziert werden kann. Zum
Ende der Qualitätssicherungstests ist die fachlich­funktionale
Abnahme der IDV­Anwendung
durch den Fachbereich zu dokumentieren.
Die Interne Revision sollte in inhaltliche Fragen
nicht eingebunden sein. Immer wieder ist zu
beobachten, dass die Interne Revision IDV­
Anwendungen inhaltlich freigeben muss.
Solche prozessualen Einbindungen gefährden
die Unabhängigkeit der Revision und werden
den Anforderungen des BT 2.2 Rdn. 2 der MaRisk
nicht gerecht. Die Interne Revision muss die
IDV­Anwendung im Rahmen ihrer Tätigkeiten
prozessunabhängig überprüfen können. Wie
könnte sie dies tun, wenn sie zuvor deren Richtigkeit
unterschriftlich bescheinigt hat?
Im Rahmen der technischen Funktionstrennung
ist sicherzustellen, dass der Programmierer
die Qualitätssicherung technisch nicht
beeinflussen kann. Sonst könnte er während
der Tests am Programmcode manipulieren
und damit die Testergebnisse verfälschen. So
könnten fehlerhafte Programme in den regulären
IDV­Anwendungsbetrieb gelangen.
5. Sicherer Produktivbetrieb
von IDV-Anwendungen
Oft gelangen Fehlerkorrekturen und Updates
des Programmierers unkontrolliert in den Produktivbetrieb,
weil sämtliche Beschäftigte
des Fachbereichs schreibenden Zugriff auf
IDV­Anwendungen haben. Dies gefährdet die
Qualität der IDV­Anwendung und auch die
Sicherheit der verarbeiteten Daten durch Vertuschung
und Manipulation. Ein bewährtes
Verfahren hierzu ist die Programmsiegelung.
Preiswerte Abhilfe ist die Einschränkung der
Benutzerrechte auf die produktive Programmversion.
Hierbei ist sicherzustellen, dass der
Programmierer die qualitätsgesicherten Version
nicht produktiv stellen kann.
6. Zugriffsrechte innerhalb
von IDV-Anwendungen
Ist die Rechenlogik gegen Veränderungen
durch Anwender geschützt?
Wird ein fachlich gebotenes Vier­Augen­Prinzip
auch technisch implementiert oder zumindest
organisatorisch abgefangen?
Sind Datenänderungen hinsichtlich Verursacher,
Datum und Uhrzeit nachvollziehbar?
Häufig ist keine Benutzerberechtigungssteuerung
in IDV­Anwendungen implementiert.
Obwohl entsprechende Mechanismen in IDV­
Plattformen nicht immer gegen Hacker tauglich
sind, reduzieren sie immerhin das Risiko
versehentlicher Veränderungen. Standard sollte
zumindest die Nutzung des Zellschutzes in Excel
für sämtliche berechnete Werte sein. Ebenso
wichtig ist ein Schreibschutz für Makros. Meist
lassen sich Vier­Augen­Prinzip und Nachvollziehbarkeit
nur implementieren, indem der Anwender
nicht mehr direkt in der Tabelle, sondern in
einer Erfassungsmaske arbeitet.
7. Backup der Daten von
IDV-Anwendungen
I. d. R. sind die IDV­Anwendungsdaten in die
Datensicherung der Dateiserver integriert und
stellen hinsichtlich des Backup damit kein
Problem dar.
8. Integrität der Daten von
IDV-Anwendungen
Häufig werden die Quelldaten der IDV­Anwendung
auf unsicheren Wegen aus den bestandsführenden
Anwendungen exportiert. Risiko ist
hierbei die Manipulation der Quelldaten. Eine
preiswerte Problemlösung ist die automatisierte
Extraktion der Quelldaten und Speicherung in
ein schreibgeschütztes Dateiverzeichnis.
Wichtig sind hierbei die Qualitätssicherung
der Extraktionsprozedur und die regelmäßige
Abstimmung, ob der Datenextrakt auch alle
Daten enthält. Wie wird der Fachbereich zu
Änderungen der bestandsführenden Anwendung
informiert, die Auswirkungen auf die IDV­
Anwendung haben könnten (z. B. Migration von
Feldinhalten, Umwidmung von Werten)?
9. Dokumentation von
IDV-Anwendungen
Oft verzichtet der Programmierer des Fachbereichs
auf die Dokumentation der Anwen­
06 / 2009 BankPraktiker
Beitrag
297