XML Web Services brauchen eine Firewall

Der Einbau von Anwendungssicherheit in den spezifischen Anwendungsknoten, der ein bestimmtes Geschäftssystem implementiert, unterliegt einigen grundlegenden Einschränkungen. Folgendes ist schwierig zu erreichen:

• Legacy Code und gepackte Anwendungen erweitern
• über alle Knoten hinweg konsistente Verfahrensweisen einführen und aufrechterhalten
• beweisen, dass bestimmte Sicherheitsrichtlinien umgesetzt worden sind

Die Implementierung von Anwendungssicherheit in der Netzwerkinfrastruktur trägt diesen Einschränkungen Rechnung. Eine XML Application Firewall ist ein Beispiel für eine solche Netzwerkinfrastruktur.

Zu den Initiativen zur Eingliederung von Anwendungssicherheit in den Knoten des Geschäftssystems gehören oft:

• Überprüfung der Sicherheit des Designs und Quellcodes nach der Entwicklung
• Fortbildung für Entwickler
• Verbesserte Entwicklungs-Tools

Diese Initiativen sind zwar produktiv und sollten beibehalten werden, doch sie berücksichtigen nicht die volle Bandbreite der Erfordernisse. Für Unternehmen ist es im Allgemeinen schwierig und ineffizient, nachträglich Sicherheit herzustellen. Es ist das gleiche Problem wie bei dem Versuch, nachträglich Qualität zu erreichen. Ein allgemein anerkannter Grundsatz des Management der Softwareentwicklung ist, dass eine Veränderung umso kostspieliger sein wird, je später im Verlaufe der Entwicklung sie vorgenommen wird, und umso wahrscheinlicher sind auch unbeabsichtigte Auswirkungen. Deshalb ist eine nachträgliche Sicherheitsüberprüfung zwar ein äußerst wertvolles Mittel, sie ist jedoch als vorrangiges Verfahren, um Anwendungssicherheit zu erreichen, nicht geeignet.

Im Allgemeinen sind bessere Ausbildung und besseres Management der Entwickler äußerst wertvoll. Dieser Ansatz reicht jedoch nicht aus. In der Praxis enthalten voll entwickelte Umgebungen immer verschiedene Anwendungen, die von verschiedenen Teams zu verschiedenen Zeiten nach verschiedenen Entwicklungsverfahren gestaltet worden sind. Deshalb kann auch mit einer besseren Ausbildung des jeweils vor Ort arbeitenden Teams nicht die erforderliche Breite und Konsistenz erreicht werden.

In ähnlicher Weise reichen Mittel wie z. B. Verschlüsselungsbibliotheken und Verbindungen zu Authentifizierungsbehörden, die in eine einzige Entwicklungsumgebung oder einen Laufzeit-Anwendungsserver eingebaut sind, für die vollständigen Sicherheitsbedürfnisse eines Unternehmens nicht aus. Diese Möglichkeiten stünden dann zwar Entwicklern zur Verfügung, die neuen Code für einen bestimmten Anwendungsserver oder eine bestimmte Entwicklungsumgebung schreiben, doch für Legacy- oder gepackte Anwendungen, die diese Tools nicht verwenden, sind sie keine Lösung.

Außerdem ist es nicht genug, einfach nur einen Mechanismus als Basis zur Verfügung zu stellen. Es bliebe immer noch dem Entwickler überlassen, Code zu schreiben, der die Logik herstellt, die für eine bestimmte Kombination von Operationen, Service-Anforderungen und Nachrichteninhalten festlegt, welcher bestimmte Sicherheitsmechanismus verwendet werden soll.

Es ist beispielsweise hilfreich, Bibliotheken in einen Anwendungsserver zu integrieren, um XML- und SSL-Verschlüsselungen zu erreichen. Das ist jedoch nur die halbe Miete. Sie brauchen nach wie vor Logik, die festlegt, ob Verschlüsselung verwendet werden soll und falls ja, welcher Verschlüsselungstyp, welcher Schlüssel, wo Zugang zu dem Schlüssel möglich ist usw.