Viele Risiken beim Software-Rollout

Blindes Vertrauen empfiehlt sich beim Rollout neuer Applikationen oder Updates in komplexen IT-Umgebungen nicht. Probleme macht vor allem die Inkompatibilität der Systeme. Sicherheit bringen nur dynamische Analysen. [...]

Pannen beim Rollout neuer Applikationen, Versionen, Betriebssystem-Patches oder -Hotfixes sind der Albtraum jedes IT-Verantwortlichen, bedeuten sie doch auf alle Fälle Kosten und beim Ausfall geschäftskritischer Systeme auch einen Imageschaden. Der Grund für solche Störungen liegt meist in den Inkompatibilitäten zwischen der neu installierten Software und der existierenden Umgebung. Derzeit hat ein durchschnittliches Unternehmen zwischen 100 und 1.500 Softwarepakete einschließlich unterschiedlicher Versionen der gleichen Software, Patches, Hotfixes, Betriebssystem-Updates etc. im Einsatz. Probleme beim Rollout neuer Applikationen sind somit geradezu programmiert. Genau aus diesem Grund wird Qualitätssicherung beim Ausrollen neuer Softwarekomponenten immer wichtiger.
 
Vermeiden lassen sich Pannen nur durch wirksame Maßnahmen zur Qualitätssicherung im Vorfeld des Rollouts, also durch Untersuchungen, ob und wie Software­pakete sich gegenseitig beeinflussen. Zu reduzieren beziehungsweise vermeiden sind Konflikte durch das so genannte Glass Box Testing, bei dem zwischen statischer (White Box Testing) und dynamischer Analyse unterschieden wird. Statische Analysen haben in jüngerer Vergangenheit zweifellos die Qualitätssicherung beim Rollout verbessert und die Kosten gesenkt. Bei dieser Technik wird in der Regel das Installationspaket analysiert, wobei man davon ausgeht, dass der Softwarehersteller das Standard-Installationspaketformat MSI von Microsoft verwendet. Dieses Format ist dokumentiert und offengelegt. Allerdings findet je nach Unternehmen nur bei etwa 75 bis 95 Prozent der erwähnten Softwarepakete das MSI-Format Verwendung. Fünf bis 25 Prozent der Installationspakete setzen Non-MSI-Installer ein.

Im besten Fall wird der MSI-Installer in einer Weise verwendet, die mehr oder weniger vollständig analysierbar ist. Vollständig meint hier, dass ausschließlich Installer-Aktionen genutzt werden, etwa das Kopieren von Dateien durch den Installer, Änderungen an der Registry und die Vergabe von Berechtigungen. In diesem Fall müsste man die Applikation nicht real installieren, es würde genügen, die MSI-Datei mit Hilfe eines Tools zu analysieren. Sämtliche Veränderungen wären in einem Application-Fingerprint enthalten. So viel zur Theorie. In der Praxis enthalten allerdings zwischen 25 und 55 Prozent der MSI-Installer so genannte Custom Actions, die während der Installation aufgerufen werden. Damit lassen sich beliebige Dateien ansprechen. Das können exe-Dateien sein, aber auch ein weiteres Installer-File (geschachtelte MSI) oder eine Batch-Datei. Alles, was unter einem Windows-Betriebssystem ausführbar ist, kann durch den Installer aufgerufen werden.

An dieser Stelle beginnt die Crux: Executables und andere Binärdateien können – technisch bedingt – nicht analysiert werden. Damit tut sich in der Analyse die erste Lücke auf, da man nicht vollständig feststellen kann, wie eine Installation das System beeinflusst. Die zweite Lücke beginnt mit dem ersten Start einer neuen Applikation. Dabei werden von der Applikation oft selbst noch Einträge in der Registry vorgenommen, weitere Dateien auf das System kopiert oder Berechtigungen geändert. Alle diese Vorgänge lassen sich mit rein analytischen Verfahren technisch bedingt nicht erfassen. Ein Applikations-Monitoring ist nötig, um solche Veränderungen zur Laufzeit der Software feststellen zu können.

PROBLEME OHNE MSI-FORMAT
Theoretisch ist es zwar möglich, die verwendeten Batch- oder Script-Dateien auf ihr Verhalten gegenüber dem Zielsystem zu analysieren, aber der Aufwand, Pseudo-Interpreter für all diese unterschiedlichen Skriptformate zu schreiben, steht in keinem vernünftigen Kosten-Nutzen-Verhältnis. Diese Überlegungen führen zu einem Schluss: Bei der statischen Analyse ist der Anwender an ein bestimmtes Format gebunden, er muss mit einigen „schwarzen Löchern“ leben und weiß nicht exakt, was die Applikation bei der Installation, beim ersten Starten oder zur Laufzeit tut. Der Application-Fingerprint ist in vielen Fällen unvollständig.

Verschärft werden diese Probleme durch die Themen Virtualisierung und Cloud Computing. Der Anteil virtualisierter Applikationen liegt momentan zwischen 15 und 55 Prozent des gesamten Applikationsportfolios – mit steigender Tendenz. In zunehmendem Maße werden auch Desktops virtualisiert, die dann entsprechende Anwendungssoftware benötigen. Dabei muss sichergestellt sein, dass diese Applikationen, auch in unterschiedlichen Versionen, auf den physischen oder virtuellen Desktops kollisionsfrei nebeneinander laufen. Wird beispielsweise ein Hotfix ausgerollt, das eine Sicherheitslücke im Betriebssystem schließen soll, muss der IT-Verantwortliche sicher sein, dass die gesamte Installation auch nach dem Rollout reibungslos funktioniert.

In diesem Kontext stoßen statische Analyseverfahren vollends an ihre Grenzen, denn virtuelle Applikationen lassen sich mit statischen Methoden nur teilweise analysieren, nie aber vollständig. Besondere Aufmerksamkeit verdienen geschäftskritische Applikationen, die häufig als Fachanwendungen mit unternehmensspezifischen Erweiterungen im Einsatz sind. Gerade hier sind die Installationsvorgänge und Abhängigkeiten von hoher Bedeutung. Die logische Konsequenz ist ein physikalischer Test, der auch mögliche Konflikte wie Probleme mit Benutzerberechtigungen oder Konflikte beim Zugriff auf Ressourcen aufdecken kann. Hier greift die dynamische Analyse; treffender wäre eigentlich die Bezeichnung „dynamischer Test“.

VERÄNDERUNGEN AUF DER SPUR
Bei einer dynamischen Analyse wird die Applikation real in einer definierten Umgebung installiert. Damit ist der Test vollkommen unabhängig vom eingesetzten Installer, die Ergebnisse bei MSI-Installern sind ebenso zuverlässig wie die bei Non-MSI-Installern. Der grundsätzliche Unterschied zur statischen Analyse besteht darin, dass hier das tatsächliche Ergebnis einer Aktion betrachtet wird und nicht die Installer-Komponente, die eine Aktion anstößt. Das Ergebnis ist eine hundertprozentige Testabdeckung.

Für die weitere Untersuchung gibt es nun zwei Möglichkeiten. Die erste besteht darin, einen Base-Snapshot des „jungfräulichen“ Systems aufzunehmen, die Applikation zu installieren und zu starten, dann einen zweiten Snapshot zu erstellen und beide miteinander zu vergleichen, also eine Differenzmenge zu ermitteln. Diese Vorgehensweise hat jedoch einen gravierenden Nachteil: Aufgrund der großen Datenmengen muss man mit erheblichen Laufzeiten rechnen. Die zweite, zeitsparende Alternative besteht darin, die Applikation durch einen so genannten Agent während der ­Installation auf die vorgenommenen Änderungen hin beobachten zu lassen. Der Agent protokolliert, welche Dateien tatsächlich in das System geschrieben, welche Registry-Einträge vorgenommen werden und was generell am Betriebssystem verändert wird. Damit erhält man ein exaktes Abbild der Modifikationen, die die Applikation während der Installation und beim ersten Start vorgenommen hat. Hier versagen natürlich die rein analytischen Methoden, da sie an dieser Stelle technikbedingt „blind“ sind.

Der erwähnte Agent, der die Änderungen am System aufzeichnet, muss selbstverständlich möglichst portabel konzipiert sein, so dass er selbst keine Modifikationen am System vornimmt, die dann eventuell dem Fingerprint der Applikation zugerechnet werden. Bei dieser Methode wird jede in Frage kommende Applikation einmal gegen das Betriebssystem getestet und so ein spezifischer Application Fingerprint erzeugt, der dann in ein Repository geladen werden kann. Durch das Vergleichen dieser Fingerprints lassen sich nun potenzielle Konflikte ermitteln.

LERNFÄHIGES EXPERTENSYSTEM
Um nichtrelevante Konfliktmeldungen zu unterdrücken, wird der Test durch ein lernfähiges Expertensystem unterstützt. Es enthält einen vorkonfigurierten Regelsatz, kann aber ebenso bestimmte Ausnahmen lernen, die nicht relevant für die Funktion des Betriebssystems oder der Applikation sind. Ebenso lassen sich Include-Filter definieren, die dem Testsystem mitteilen, nur bestimmte Teile der Registry, des Dateisys-tems oder auch nur bestimmte Dateien zu betrachten. Damit lässt sich das Daten­volumen des OS-Snapshots reduzieren, schließlich nimmt der Snapshot einer aktuellen Windows-7-Version mit allen Patches rund 500 MB in Anspruch. Der Fingerprint eines SAP-GUI ist rund 200 MB groß, immerhin werden hier rund 750.000 Änderungen gespeichert. Im weiteren Verlauf wird eine Konfliktmatrix erstellt, die zeigt, zwischen welchen Applikationen es Schnittmengen gibt, die Konfliktpotenzial bergen. Benötigen beispielsweise zwei Applikationen gleiche DLL, allerdings in ­unterschiedlichen Versionen, besteht die Gefahr eines Konflikts. Es lässt sich so zwar nicht zu hundert Prozent prognostizieren, dass es tatsächlich zu Konflikten kommt, man hat aber einen Ansatzpunkt für zusätzliche Tests.

Deren Ergebnisse fließen wiederum in die Wissensbasis zurück, auf die in späteren Fällen ohne weitere Tests zurückgegriffen werden kann. Dabei ist es vollkommen gleichgültig, ob es sich um Applikationen, Patches, Hotfixes oder unterschiedliche Versionen des Betriebssystems handelt. Mit zunehmender Größe und Aktualität der Wissensbasis verringert sich der zeitliche Aufwand bei der Bewertung von Problemstellungen. Die automatische Bewertung durch Erkennung bekannter, ähnlicher Situationen unterstützt und verkürzt die Entscheidungsfindung und sorgt für eine höhere Qualität der Entscheidungen.

* Der Autor Eberhard Rademeier ist freier Journalist und IT-Experte.