ASI: sichere Anwendungen mit standardisierten Infrastrukturen
Seite 3: Voraussetzungen
Organisatorische Voraussetzungen
Die vielleicht größte Herausforderung beim Konzept der Anwendungssicherheitsinfrastrukturen liegt darin, dass zwei meist organisatorisch getrennte Bereiche des Unternehmens – Anwendungsarchitektur/-entwicklung sowie IT-Infrastruktur – zusammenarbeiten müssen. Oft gibt es innerhalb dieser beiden "Silos" noch viele getrennte Bereiche, die keineswegs zwingend an einem Strang ziehen.
Deshalb lässt sich ein solches Modell nicht von einem Bereich definieren, sondern nur gemeinsam entwickeln. Daher stehen auch die Services im Mittelpunkt. Sie sind so zu gestalten, dass sie sich einerseits sinnvoll realisieren lassen, andererseits aber effizient in der Softwareentwicklung zu nutzen sind. Das kann durchaus bedeuten, dass man beispielsweise unterschiedliche Varianten für .Net- und für Java-EE-Anwendungen bereitstellt. Außerdem sollte man von Beginn an überlegen, welches Niveau die Services erhalten sollen.
LDAP ist sicher ein Ansatz, der allerdings keineswegs einfach zu nutzen und meist viel zu abstrakt ist. Wenn man stattdessen Komponenten auf höherer Abstraktionsebene mit einfach verwendbaren, klar definierten Methoden und Eigenschaften definiert, ist der einmalige Aufwand zwar höher – die Akzeptanz aber auch.
Eine erfolgreiche Umsetzung lässt sich nur in einem Team mit Mitgliedern aus unterschiedlichen IT-Bereichen erreichen. Es muss kontinuierlich an ihr feilen, weil sich die Services auch mit neuen Anforderungen weiterentwickeln lassen. So sind inzwischen beispielsweise Attestierfunktionen ins Blickfeld gerückt, die sich durchaus über standardisierte Services unterstützen lassen.
Umfang von Anwendungssicherheitsinfrastrukturen
Bei der Beschäftigung mit dem Konzept muss man sich damit auseinander setzen, was die Anwendungen genau abdecken sollen. Die grundlegende Herausforderung ist, Sicherheit zentral konfigurierbar und nachvollziehbar zu gestalten sowie "kodierte Sicherheit" zu vermeiden. Solcher Code ist durchaus typisch. Das beginnt bei eigenen Anwendungsverzeichnissen und geht über eigene (oftmals unzureichende) Authentifizierungsmechanismen bis hin zu einem lokalen Logging und Auditing oder der Steuerung der Autorisierung. Oft konfiguriert man die Rollen von Benutzern in Anwendungen und steuert (kodiert hart) über die Rollen, wer welche Rückgabewerte einer im Kontext eines technischen Benutzers gelaufenen Datenbankabfrage zu sehen bekommt.
Die Kernelemente einer Anwendungssicherheitsinfrastruktur sind damit zunächst die klassischen "4A" – Administration, Authentifizierung, Autorisierung und Auditing. Hinzu kommen Verschlüsselungsfunktionen. Die Administration ist, wie im Beispiel beschrieben, vergleichsweise einfach zu lösen. Auch Authentifizierungsdienste lassen sich einfach realisieren, sei es gegen das Active Directory, ein anderes LDAP-Verzeichnis, auf X.509-Basis oder mit Standards der Identity Federation.
Deutlich spannender gestaltet sich die Autorisierung. Die Zielsetzung ist hier, in einer Anwendung nur granulare Tasks zu beschreiben. Die Zuordnung von Benutzern zu Rollen und von Rollen zu Tasks sollte aber außerhalb geschehen. Damit ist schon einiges erreicht. Eine weitergehende Ende-zu-Ende-Sicherheit, bei der Benutzerabfragen auf Datenbanken erfolgen, gestaltet sich damit einfacher. Interessant ist auch, ob sich die Autorisierungsentscheidungen aus den Anwendungen herausnehmen und von externen Systemen durchführen lassen. Damit sind beispielsweise Änderungen in Richtlinien einfacher zu realisieren. Ein Beispiel dafür wäre, das Limit für die Kreditvergabe durch einen Sachbearbeiter herunterzusetzen. Der Vorteil davon, so etwas von außen ohne Anpassungen in der Anwendung steuern zu können, ist offensichtlich. Das Problem mit externen Engines ist allerdings einerseits die Frage nach dem funktionalen Umfang und andererseits die Herausforderung der Performance – wenn Millionen von Autorisierungen pro Tag durchzuführen sind, braucht es leistungsfähige Lösungen.
Auch das Auditing ist nicht ohne Herausforderungen. Über das Niveau von einfachen Ansätzen wie Syslog hinaus fehlen schlicht Standards für generische Lösungen. Wenn es um das Verschlüsseln und das Management von Schlüsseln und Zertifikaten geht, sieht es besser aus. Hier gibt es einige Standards, auf die man setzen kann, aber auch proprietäre Konzepte wie im Windows-Umfeld. Man muss die einzelnen Punkte natürlich nicht alle gleichzeitig realisieren. Administration und Authentifizierung bieten sich als Einstieg an, um darauf schrittweise andere Themen anzusprechen.
