Die firmenweite Verbreitung von serviceorientierten Architekturen (SOA) nimmt rapide zu. Daten und Applikationen werden oft als Services für verschiedene Bereiche zur Verfügung gestellt. Daraus stellen sich ganz neue Anforderungen an die IT-Sicherheit.

1. Wenn sich ein Kunde in eine Onlinebanking-
Applikation einloggt, um dort Zahlungen zu
tätigen, ist es von enormer Bedeutung, dass
die Sicherheit dieser Transaktion gewährleis-
tet ist. So hat eine für den Benutzer einfach
erscheinende Anwendung bereits zahlreiche
Sicherheitsaspekte zu berücksichtigen:
• Authentication: Die Identität des ange-
meldeten Benutzers muss überprüft wer-
den.
• Authorization: Der Benutzer muss be-
mächtigt sein, die Transaktion durchfüh-
ren.
• Integrity: Die Daten, die der Benutzer
übermittelt, müssen die gleichen sein wie
diejenigen, die empfangen werden.
• Confidentiality: Niemand darf die über-
tragenen Daten unautorisiert lesen.
• Auditing: Gewisse Transaktionen müssen
zur nachträglichen Kontrolle richtig abge-
speichert werden.
Aspekte wie Single Sign-On (SSO) kön-
nen ebenfalls wichtig werden. Dies vor allem
dann, wenn bestehende Applikationen, wie
beispielsweise «Secure-E-Mail», integriert
werden. Heute wird die Sicherheit von IT-Lö-
sungen durch Technologien wie Streichliste,
SecureID, Zertifikate, SSL und so weiter ge-
währleistet. Was in welchem Fall zum Einsatz
kommt, ist abhängig von den Anforderungen
der Applikation.
Sicherheit in einer SOA
Die gleichen Sicherheitsansprüche, wie oben
für «normale» Applikationen beschrieben,
gelten im Wesentlichen auch für den Aufruf
vonServicesineinerSOA.Dainnerhalbeiner
SOA die Applikationen durch Orchestrierung
von Services erstellt werden, reicht es aber
nicht mehr, nur die Applikationen zu schüt-
zen. Jeder einzelne Service ist dafür verant-
wortlich, wie und mit welchen Sicherheits-
vorkehrungen er aufgerufen werden kann.
Dieser Umstand stellt ganz neue Anforde-
Sicherheit für service-
orientierte Architekturen
Die firmenweite Verbreitung von serviceorientierten Architekturen (SOA) nimmt rapide zu.
Daten und Applikationen werden oft als Services für verschiedene Bereiche zur Verfügung
gestellt. Daraus stellen sich ganz neue Anforderungen an die IT-Sicherheit. Peter Affolter
SOA
Abbildung 1: Identity Management Grid
©Netzmedien AG 2
Peter Affolter
ist Software-Architekt bei der
Sun Microsystems (Schweiz) AG
www.sun.com/soa
www.sun.com/security

2. rungen an das Identity- und Access Manage-
ment innerhalb einer Firma. So wird es bei-
spielsweise unumgänglich, dass für alle Au-
thentication Requests jeder einzelne User
mit einem einzigen, individuellen Benutzer-
namen authentisiert werden kann. Auch al-
le Policies zum Aufruf von Services müssen
zentral verwaltet und überprüft werden. Es
wird für Unternehmen also immer wichtiger,
ein sauberes Identity-Management-System
einzuführen und zu unterhalten.
Service-Aufrufe
In einer SOA muss ein Service nicht zwangs-
läufig via Web Services aufgerufen werden.
Andere Methoden wie JMS, RMI oder native
EJB-Calls sind definiert und bieten, je nach
Umgebung,einesehrguteAlternativezuWeb
Services. Allerdings sind die Anforderungen
und die Art der Implementierung der Sicher-
heit je nach Binding und Context (Internet,
Extranet, Intranet) sehr unterschiedlich.
EinServiceistirgendwieimmereinekleine
Applikation in Java oder .NET, die innerhalb
eines Containers ausgeführt wird. Typischer-
weise müssen alle Services, die mit sensitiven
Daten arbeiten, zumindest Authentication
und Authorization beinhalten. Dies wird am
einfachsten sichergestellt, indem der Con-
tainer einen Security Realm implementiert,
der jeden Zugriff auf ein Objekt schützt und
bei einem zentralen Access-Manager die Be-
rechtigungen prüft.
So kann auch direkt
ein Container-über-
greifendes SSO im-
plementiert werden.
Hierzu stehen Stan-
dards wie SAML (Se-
curity Assertion Mar-
kup Language) und
WSS (Web Service
Security) zur Verfügung. Werden die Services
als Web Service aufgerufen, kommen für die
Zugriffskontrolle die Standards XACML (Ex-
tensible Access Control Markup Language)
und WS-Policy zum Einsatz.
Sicherheit der Daten
Wie erwähnt, ist auch die Sicherheit der Da-
ten, die beim Aufruf von Services ausge-
tauschtwerden,sehrwichtig.Dazugehörtdie
Integrity und Confidentiality der Daten, die
sichergestellt werden muss. Werden die Ser-
vices innerhalb des gleichen Containers auf-
gerufen, müssen die Daten nicht speziell ge-
schützt werden. Auch beim Aufruf innerhalb
des gleichen Netzwerkes via JMS ist eine Da-
tenverschlüsselung meist nicht gefordert.
Web Services aber definieren, dass die Ser-
vices typischerweise via SOAP aufgerufen
und die Daten darin in einem XML übertra-
gen werden. Auch bei JMS über eine WAN-
Verbindung werden die Daten oftmals als
XMLübertragen.IndiesemFallspielenXML-
Security-Standards eine immer grössere Rol-
le. Sie benutzen und erweitern bestehende
Standards, um die Sicherheitsanforderun-
gen für XML-Dokumente zu erfüllen. So wur-
de zum Beispiel das
Schema der XML-Si-
gnatur um einen Tag
‹KeyInfo› erweitert.
Dieser zusätzliche
Tag ermöglicht es,
Signature- und En-
cryption Information
zu übertragen. Auch
können die Identity-
Informationen der Benutzer in der Message
transportiert werden. Die XML-Security-
Standards verwenden meistens bestehende
Sicherheitskonzepte wie SSL/TLS, X.509 Zer-
tifikate und SHA-Algorithmen, die entspre-
chend erweitert oder angepasst wurden.
Die Core-Standards für XML-Security
sind:
• XML-Encryption ist eine W3C-Spezifika-
tion, die End-To-End Security für Applika-
tionen definiert, die einen sicheren Aus-
tausch von strukturierten Daten benöti-
gen. XML ist der verbreitetste Standard
zum Austausch von strukturierten Daten
und XML-basierte Encryption ist somit der
beste Weg, solche Applikationen und Ser-
vices zu schützen.
• XML-Signature Syntax and Processing
ist eine W3C-Empfehlung, die Integri-
tät, Authentication und Authorization der
Message definiert. XML-Signaturen wur-
den für die Verwendung in XML-Transak-
tionen entwickelt. Der Standard definiert
im Wesentlichen das Schema, um das Re-
sultat einer digitalen Signatur zu trans-
portieren und zu verarbeiten.
• Digitale Certificates sind übliche, allge-
mein bekannte Zertifikate, die von einer
Certificate Authority (CA) erstellt wer-
den.
• XML Key Management (XKMS) besteht
aus zwei Teilen, dem XML Key Informati-
on Service (X-KISS) und dem XML Key Re-
gistration Service (X-KRSS). XKMS verein-
facht die XML-basierte, sichere Transakti-
on über das Internet. Dies wird durch die
Verwendung einer normalen Public Key
Infrastructure (PKI) und durch digitale
Zertifikate gewährleistet.
Secure- and Trusted SOA Infrastructure
Um eine Secure- and Trusted SOA von A bis Z
zu erstellen, braucht es also recht viele Kom-
ponenten, die zusammenarbeiten müssen.
Es ist daher unumgänglich, auf allen Stu-
fen der Sicherheit offene Standards einzu-
setzen. Nur so kann eine Infrastruktur auf-
gebaut werden, die keine Lock-in-Situation
oder Inkompatibilitäten zwischen einzelnen
Services aufweist. Abbildung 2 zeigt eine Ar-
chitektur mit den benötigten Security-Kom-
ponenten. Im Rahmen einer SOA sollten na-
türlich auch diese Komponenten als Services
implementiert werden.
©Netzmedien AG 3
SOA
Abbildung 2: Security Infrastructure für eine SOA
«Ein Service ist irgend-
wie immer eine kleine
Applikation in Java
oder .NET, die innerhalb
eines Containers aus-
geführt wird.»