Safety first in Service-orientierten Architekturen

Harald Weimer, Sales Director bei Iona Technologies,  Anbieter des ESB-Produkts ‘Artix’, legt den Fokus auf die Authentifizierung und Autorisierung von Services. Diese Sicherheitsbelange gebe es zwar in anderen Bereichen auch schon, doch verschärften sie sich, weil Services von unterschiedlichen Benutzergruppen in verschiedenen Applikationen differenziert benutzt werden könnten. “Da wird es höllisch kompliziert”, warnt er. Das zeigten unter anderem die bisherigen mehr oder minder gescheiterten Versuche für ein Single Sign-on im Internet nach dem Kerberos-Prinzip.

Tokens, Fallbacks oder PKI?

Der digitale Höllenhund Kerberos soll eine sichere und einheitliche Authentisierung in ungesicherten TCP/IP-Netzwerken aus sicheren Host-Rechnern garantieren. Dabei übernimmt die Authentisierung eine vertrauenswürdige dritte Partei, ein besonders geschützter Kerberos-5-Netzwerkdienst. Das Iona-eigene ‘Intelligent Security Framework’ unterstützt zwar das Format und transformiert es in welche, die unter anderem auch von IBM-Mainframes verstanden werden, doch den Anspruch des HP-Entwicklers Trautmann an SOA-Security scheint es noch nicht zu erfüllen. Single Sign-on realisiert Iona mit Hilfe von Tokens, virtuellen Eintrittskarten, die von Service zu Service “durchgereicht” werden. Runder wird das Iona-Angebot vielleicht durch die neue Kooperation mit Metasecure, einem IT Consultant sowie Entwickler von Security-Integrationslösungen, die kürzlich geschlossen wurde.

Auch Computer Associates (CA) schießt sich mit seinem ‘Federated Identity Management’ allmählich auf Service-orientierte Architekturen ein und unterstützt das Prinzip der SAML-Token. Georg Hübbers, Consulting Manager Security Management bei CA, beschreibt mit einem Beispiel die Umgebung, für die CA-Tools gemacht sind: Fährt ein Auto mit einem Bordcomputer heute in eine Werkstatt, liest ein angeschlossenes Gerät etwa die Servicedaten aus, überträgt sie an eine Datenbank des Automobilherstellers und überspielt ein vom Autobauer stammendes Software-Update an die Fahrzeug-IT. “Dafür braucht man Security”, betont Hübbers.

Für das Authentifizieren kann laut Hübbers die CA-Software Techniken nutzen wie Fallbacks, PKIs (Public Key Infrastructure) und Passwörter, die Autorisierung geschehe zentralisiert und Policy-basiert, und das Single Sign-on kann entweder Agent- und Proxy-basiert vollzogen werden, mit Hilfe von SAML, beruhend auf Passport oder Kerberos. Die Aufgabe von SOA-Entwicklern besteht darin, jede angesprochene Applikation mit einer Art virtuellem Pförtner zu versehen. Die Schnittstellen fordern den Service auf, sich zu identifizieren und autorisieren den Zutritt. Eine andere Möglichkeit sei es, ein residentes Cookie einzuschleusen, das diese Formalie erledigt. Das Zertifikat, das den Service oder auch Benutzer ausweist, wird an zentraler Stelle erstellt und verwaltet.

Die Diskussion hält an

Während der CA-Vertreter die Unterstützung möglichst vieler Standards, Verfahrensweisen und deren Machbarkeit betont, sieht Markus Popp, Berater bei SD&M, wie Trautmann eher den Klärungsbedarf: “Im Bereich Authentifizierung laufen derzeit die meisten Diskussionen. Die Frage ist nach wie vor: Wie konfiguriert man die Berechtigungssysteme so, dass die Services miteinander interagieren dürfen?” Einverstanden ist er mit der Zentralisierung des Authentifizierungsdienstes, so wie es Microsoft mit ‘Passport’ für Dotnet-Umgebungen schon vorgemacht habe.

Hier habe sich aber auch die Problematik deutlich gezeigt. Die Zielsysteme müssen mit den Authentifizierungsmerkmalen (Tickets) eines Authentifizierungsdienstes umgehen können. Denn es brauche nicht nur eine zentrale vertrauenswürdige Ausgabestelle für diese Tickets, sondern auch passende Schnittstellen bei den Services, die auf Basis der Interpretation dieser Tickets entscheiden müssen, ob sie ihren Service für die anfordernde Komponente freischalten oder nicht, erläutert Popp. Gerade bei der Weiternutzung bestehender Anwendungen im Webservice-Umfeld werden dafür Plug-ins notwendig, die, der Anwendung vorgeschaltet, ein Ticket auswerten und etwa eine Signatur verifizieren können. Den Aufwand für solche digitalen Türsteher schätzt Popp auf 15 bis 30 Tage, abhängig vom Schutzbedarf des Services, dem das Plug-in vorgeschaltet wird.

Wie HP-Experte Trautmann siedelt auch Popp die zentrale Ticketstelle im ESB an. Das stelle sicher, dass alle Services, die an diesem Bus hingen, mit diesem Ticket auch umgehen könnten. Auch Federated Identity Management stelle Maßnahmen bereit, Authentifizierung und Identitäts-Management Internet-weit zur Verfügung zu stellen. Das Angebot an Konzepten und Produkten sei aber noch weit von interoperablen Standards entfernt und zudem oft auf menschliche Interaktion ausgelegt. So wundert es nicht, wenn der SD&M-Berater schließt: Security in SOAs sei, wie so oft, ein Thema, das in Projekten gerne nach hinten geschoben werde. Dennoch müsse die IT-Security gerade in SOAs Thema in der Konzeptionsphase sein. “Obwohl derzeit gerade in großen Unternehmen SOAs entstehen, habe ich aber leider Referenz-Implementierungen mit entsprechenden Security-Features noch nicht gesehen.”
 
Test, Test, Test …

Durchaus erfreulich dagegen dürfte es sein, dass es bereits Test-Werkzeuge für SOA-Implementierungen gibt, zum Beispiel von Parasoft. Das Unternehmen interpretiert Security etwa als Konsistenz und Fehlerfreiheit. Das Mitglied im insgesamt 53 Mitglieder zählenden SOA Leaders Council bietet Tools an, die bei der Erstellung von Services eingesetzt werden, sowie zur Überprüfung einer Implementierung. Es lassen sich in statischen Tests etwa WSDL-Beschreibungen auf Widerspruchsfreiheit prüfen. Darüber hinaus sind Messages generierbar, mit denen kontrolliert werden kann, ob die Antwort die ist, die erwartet wurde. Voraussetzung für alle Überprüfungen ist eine Protokollgrundlage, die die Tools verstehen: Soap, MQ von IBM und JMS (Java Messaging Service).