Enterprise Wide Integration Security

Sicherheit als Türöffner

Sicherheit sorgt erst einmal für die Errichtung gewollter Barrieren. Diese können sich jedoch bei inkonsistenter Anwendung als Interoperabilitätshürden erweisen. Sie kann aber auch ein Türöffner sein, sofern Integrationsarchitektur mit einer geeigneten Sicherheitsstrategie ergänzt wird. Das Sicherheitsniveau soll in einer globalen IT-Landschaft transparent und konsistent sein. Die Sicherheitsinformationen, die dabei über die ganze Aufrufkette vom Benutzer über alle Komponenten zum Service-Provider propagiert werden, sollen dabei einen klaren Zweck erfüllen. Es werden mindestens benötigt:

  • Ein Grundschutz für alle teilnehmenden Endpunkte basierend auf ihrem Schutzbedarf.
  • Ein Trustkonzept mit geeigneter Topologie zur Abbildung unterschiedlichster lokaler Anforderungen des Regulators bzw. des Gesetzgebers an die IT.
  • Standardisierung der Sicherheitsinformationen, die zwischen Endpunkten übermittelt werden sollen.
  • Standardisierung der Sicherheitspatterns, um die Sicherheitsinformationen sicher zu übermitteln
  • Berücksichtigung von Kommunikationsszenarien über unterschiedliche Sicherheitsniveaus, Umgebungen, Technologien, Cross-Border-Szenarien und Use Cases.
  • Eine Regelung der Arbeitsteilung zwischen Infrastruktur und Endpunkten. Insbesondere die Regelung der Grundmechanismen für die Authentisierung und Autorisierung bei grenzüberschreitenden Servicezugriffen und ihre Implementierung in Middleware und Plattformen.
Endpunkte

Beim SOA-Ansatz existieren die üblichen Sicherheitsanforderungen für Applikationen auch für Serviceendpunkte. So sollten z. B. alle Endpunkte identifizierbar sein, bei wichtigen oder kritischen Systemen vorzugsweise mit starken Authentisierungsmethoden wie z. B. mit PKI oder Kerberos. Ein wichtiges Prinzip könnte lauten, dass jeder Endpunkt in erster Linie seine eigenen Daten schützen soll. Die Spielregel wäre somit, dass es keine direkten Datenbankzugriffe anderer User geben darf, sondern dass die Daten immer über den zuständigen Endpunkt gekapselt sein müssen. Alle User- und System-Datenzugriffe werden somit über Endpunkte mit ihren Autorisierungschecks geführt.

Die Autorisierung basiert auf der technischen Repräsentation der Identität des Benutzers. Bei einem Serviceaufruf müssen dem Service-Provider diese Sicherheitsinformation zur Verfügung stehen. In einer heterogenen IT mit vielen Identitätsrepräsentationen kann die Konsolidierung der Identifier ein wichtiger Ansatz zur Komplexitätsreduktion sein. Man kann diesem Problem aber auch mit einem föderativen Einsatz von Identitätsbrokern begegnen. In diesem Fall wird die Varietät des Kontrollsystems erhöht, damit das System einen größeren Handlungsspielraum hat, um mit der hohen Komplexität im Identitätsraum besser umgehen zu können.

Zusätzliche Sicherheitsmaßnahmen und Kontrollpunkte müssen dafür sorgen, dass die negativen Nebenwirkungen aufgefangen werden, die sich aus der erweiterten Konnektivität einer SOA ergeben, damit nicht die ursprünglichen Sicherheitsanforderungen unterlaufen werden. Ein Stichwort dazu sind so genannte „Firewall-friendly“-Protokolle wie HTTP. Diese sind leider nicht „Security friendly“ wenn bestimmte Endpunkte gar nicht erst global aufrufbar sein sollen. Andere Endpunkte sind nicht in der Lage zu kommunizieren, weil die Sicherheitsinformationen anders sind, im falschen Format daherkommen oder ganz einfach auf einem anderen Technologieansatz beruhen. Deswegen werden Kontrollpunkte benötigt, die je nach Zweck unterschiedliche Funktionen abdecken, wie z. B. Security Gates zur Förderung der Interoperabilität oder als Zugriffskontrolle auf den Service Access Layer.

Standardisierung der Kommunikation

Ein wichtiger Hebel ist, dafür zu sorgen, dass die Sicherheitsinformationen und Patterns standardisiert werden, die in einer Kommunikation zur Verfügung stehen. Damit nicht alle Technologien und Kombinationen simuliert werden müssen, wird ein fiktiver Enterprise Bus eingeführt, der alle möglichen Kommunikationsvariationen abbilden kann. Applikationen kommunizieren miteinander über synchrone oder asynchrone Schnittstellen. Dabei wird auf beliebiger Protokollebene irgendein Payload als Message hin und her geschickt, mit oder ohne Involvierung des Enterprise Bus. Auf diese Weise kann eine Matrix abstrakter Kommunikationsszenarien entwickelt werden, die dann immer wieder konsistent auf konkrete Szenarien und Technologie-Use-Cases angewendet werden kann.

Solche Software existiert. So ist es z. B. möglich, über Message Queues sowohl Messages als auch Files zu versenden. Selbst synchrone Kommunikationspattern lassen sich auf diese Weise implementieren. Ein Message Broker kann zusätzlich Transformationen durchführen. Prinzipiell lässt sich auf diese Weise jedes Format beliebig in ein anderes umwandeln, dabei können selbst synchrone Aufrufe über asynchrone Kanäle laufen und umgekehrt. Man benötigt also nur generische Sicherheitspattern, mit oder ohne fiktiven Enterprise Bus, die in konkreten Technologie-Use-Cases wiederverwendet werden.

Die Menge der Variationen (und damit die Komplexität) sollte sich auf diese Weise stark reduzieren lassen. Applikationen bzw. Applikationsplattformen können direkt miteinander kommunizieren oder mit Middleware-Infrastrukturen indirekt. Bei beiden Varianten kann prinzipiell Punkt-zu-Punkt oder End-to-End Message-Sicherheit eingesetzt werden. Welches Pattern angewendet werden soll, hängt vom Sicherheitslevel einer konkreten Umgebung und dem Schutzbedarf des Endpunkts ab. Interessant wird es dann, wenn die Kommunikation aus einer ungeschützten Umgebung in eine geschützte erfolgen soll. Wenn eine Middleware dazwischen geschaltet ist, stellt sich die Frage, ob dabei die Authentizität und Integrität von Security Assertions bzw. die Vertraulichkeit des Payloads garantiert wird. Eventuell existieren weitere Security Services zur Interoperabilität wie Authentisierungs-Gateways, User Mapping oder zur Erfüllung von Policy-Anforderungen in verschiedenen Jurisdiktionen.

Wird diese Abstraktion nicht gemacht, dann muss für jede Technologie eine Einzelbetrachtung angewendet werden, wobei sich Inkonsistenzen in der globalen IT-Sicherheit einschleichen können. Es geht um folgende Gemeinsamkeiten: Welche Sicherheitsinformationen müssen von System A nach System B propagiert werden? Für welchen Zweck werden diese Informationen überall benötigt? Welche Sicherheitsinformationen muss jeder SOA-Teilnehmer im Minimum verstehen? Wie flexibel lässt sich das System erweitern? Gibt es gemeinsame Assertion-Formate? Wie werden fehlende Informationen ergänzt? Welche Assurance-Levels benötigt der Service-Provider und wie ist er überprüfbar? Strenge Anforderungen an die Nachvollziehbarkeit könnten dazu führen, dass alle über die Aufrufkette hinweg verwendeten Security Tokens dem Payload angehängt und jeweils signiert werden. Das ergäbe eine überprüfbare Trustkette – aber soll dieses Pattern bei allen Teilnehmern vorausgesetzt werden?

Eventuell unterscheidet sich das erreichbare Assurance-Level nur aufgrund des unterschiedlichen Setups der beiden Endpunkte. Einige Patterns fokussieren auf Punkt-zu-Punkt Transportsicherheit mit SSL, andere werden die Sicherheit End-to-End über Signaturen und Verschlüsselungsmechanismen an den Payload knüpfen. Hier ist eine große Varietät möglich und die Strategie muss klären, auf welchem Layer welche generischen Sicherheitsinformationen benötigt werden. Außerdem muss geregelt werden, wie diese Informationen zu schützen sind, damit sie integer von A nach B nach C und D etc. transportiert werden. Sicherheit und Sicherheitserwartungen sollen dabei transparent abgebildet und prozessierbar gemacht werden. Grob vereinfacht könnte man dies als SSO (Single Sign-On) für Backend Services bezeichnen, der über den ganzen Kommunikationspfad von der ersten Serverkomponente über die ganze Aufrufkette bis zum letzten Service-Provider im System hinweg erfolgt.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.