Der Einsatz Service-orientierter Architekturen (SOA) zur Öffnung und Kopplung von IT- und Informations­systemen birgt Sicherheitsrisiken, die oft nicht durch die klassischen Sicherheitsrichtlinien abgedeckt sind. Zwar bietet der Einsatz von SOA-Firewalls gewisse Hilfen, aber damit lassen sich nicht alle Risiken zufrie­denstellend beseitigen. Die Unternehmen müssen da­her schon in der Architektur für Sicherheit sorgen. Mit „nachgeschobenen” Lösungen zur Erkennung und Be­hebung von Sicherheitsrisiken kann oft nur ein sehr unzureichendes Sicherheitsniveau erreicht werden.

Neben Sicherheitsaspekten bei der Aktivierung einzel­ner Services, wie z.B. Vertraulichkeit, Authentizität und Integrität, sind auch Aspekte wie Transaktionssicher­heit für das Zusammenspiel von Services von Bedeu­tung. Hinzu kommen noch spezielle Sicherheitsanfor­derungen, wenn eine SOA nicht nur in einer Institution eingesetzt sondern auch nach außen geöffnet wird. Als Beispiele dafür seien der Schutz gegen Denial-of-Service-Angriffe und die Nachweisbarkeit von Trans­aktionen gegenüber Dritten genannt.

Da SOAs in den Unternehmen vorrangig unter funk­tionalen Gesichtspunkten entwickelt werden, werden Sicherheitsherausforderungen und -lösungen häufig „nachgeschoben”. Dadurch werden einerseits meist nur einzelne Komponenten gesichert und andererseits auch keine Domänen-übergreifenden Sicherheitsricht­linien definiert und harmonisiert. Dadurch können Kon­fliktsituationen bzw. Sicherheitsrisiken entstehen, die sich in der ganzen Architektur fortpflanzen können. Es fehlen dann auch meist ganzheitliche Sicherheits­konzepte und viele SOA-spezifische Sicherheitsanfor­derungen bleiben unerfüllt.

Die für die Entwicklung von SOAs verantwortlichen Fach- und Führungskräfte müssen deshalb einerseits ein grundsätzliches Sicherheitsbewusstsein haben und andererseits die technischen Lösungsmög­lichkeiten beherrschen, die geeignet sind, um die Sicherheit kritischer Geschäftsprozesse zu gewähr­leisten.