Suche

Enterprise Wide Integration Security

Topologie und Trust

Es wird ein konkreter Aufhänger benötigt, um die Topologie globaler Kommunikation abzubilden, egal, ob es sich dabei um SOA oder um klassische Technologien handelt. Der Hintergrund dafür sollten jene Businessanforderungen an die IT sein, die als Compliance-Anforderungen für ein Business entscheidend sind. Im Finanzsektor sind Systemgrenzen zwischen Jurisdiktionen zu erwarten. In diesem Zusammenhang interessant sind technologische Trust- oder Domänenkonzepte, die solche Abgrenzungen abbilden können, wie bspw. Cells (DCE: Distributed Computing Environment), Protection Domains (WLS/J2EE), Realms (AD bzw. Kerberos), PKI-Domänen, Netzwerkdomänen (DNS), Netzwerkzonen oder sonstige interne Implementierungen.

Viele dieser technologisch fokussierten Trustkonzepte werden mit unterschiedlichen Zielen eingesetzt, was völlig in Ordnung ist. Wenn sie jedoch identische Ziele verfolgen, dann müssen sie aufeinander abgestimmt sein. Wenn damit Sicherheitsziele verfolgt werden, dann bilden diese Konzepte Bereiche mit gemeinsamen Schutzmaßnahmen ab. Es empfiehlt sich die Entwicklung eines technologisch unabhängigen abstrakten Trustkonzepts. Auf diese Weise bleibt die Konsistenz gewahrt, selbst wenn sich die eingesetzten Technologien im Laufe der Zeit ändern. Solche logischen Schutzbereiche (Protection Areas) müssen auf jene konkreten Technologien abgebildet werden, die man für bestimmte Policies einzusetzen gedenkt. IT-Komponenten und Endpunkte mit dem gleichen Set an Policy-Anforderungen können so z. B. in Clouds markiert bzw. in gemeinsamen Protection Areas gruppiert werden.

Ein naheliegender Gedanke ist, die Topologie an Netzwerkzonen aufzuhängen. Auf diese Weise wird als praktischer Nebeneffekt zusätzlich ein Grundschutz implementiert. Wird eine sichere Serverzone pro Jurisdiktion gebaut, erhält man eine auf Jurisdiktionen basierende Topologie. Der Vorteil ist eine Struktur, unter der man sich etwas vorstellen kann. Andere existierende Trustkonzepte müssen gegebenenfalls an die Netzwerkzonen angepasst werden. Das betrifft z. B. Service-Layer-Zugriffskontrolle als Kontrollpunkt für Inbound-Kommunikation innerhalb einer solchen Netzwerkzone. Ein solcher Ansatz geht in Richtung Application Level Firewall.

Komplexere Topologien lassen sich durch eine Verfeinerung des Modells erzielen. Möglicherweise gibt es ja weitergehende Separationsanforderungen in derselben Jurisdiktion (Hosting für andere Firmen, interne Chinese Walls, etc.). Diese können parallel oder hierarchisch realisiert werden. An dieser Stelle muss man sich gut überlegen, ob man mit Netzwerkzonen weiterarbeiten will oder ob innerhalb einer Netzwerkzone auf einer logisch anderen Ebene die Topologie weitergezogen werden soll. Hier sollte man bereits über ein abstraktes Trustmodell mit hierarchischen Protection Areas verfügen.

Regelung der Arbeitsteilung

Die Regelung der Arbeitsteilung zwischen Infrastruktur und Endpunkten ist ein nicht zu unterschätzender Faktor. Hier geht es im Wesentlichen um Erwartungshaltungen. Welche Erwartung hegen die Teilnehmer einer globalen SOA an ihre Peers und die darunterliegende Infrastruktur bzw. welche Erwartungen werden realisiert? Erwartet der Endpunktprogrammierer fälschlicherweise, dass die Middleware-Infrastruktur den Transport über das Netzwerk verschlüsselt? Wird der Transport eventuell über ein offenes Netzwerk über eine andere Jurisdiktion geführt? Oder erwartet der Endpunkt-Service-Provider eine Infrastruktur ohne Security Features und verschlüsselt deshalb selber den Payload End-to-End, wenn er die Antwort zurückschickt? Kennt der Consumer den Verschlüsselungsalgorithmus und den Schlüssel? Erwartet ein lokaler Endpunkt-Provider, der nicht aus einer anderen Jurisdiktion aufgerufen werden darf, dass die Firewall den globalen Zugriff blockiert? Oder dass die Middelware einen Zugriffschutz auf Serviceebene als Kontrollpunkt implementiert hat? Erwartet die Infrastruktur, dass alle Endpunkte ihre Autorisierung im Griff haben und dass deshalb die Infrastruktur den Zugriff auf alle Endpunkte erlauben darf?

Problematisch wird es für die Sicherheit, wenn Erwartungshaltungen und Realitäten auseinanderdriften. Dies kann dann gefährlich werden, wenn Komponenten und Endpunkte in eine Umgebung mit ganz anderer Erwartungshaltung verschoben werden. Mit Virtualisierung und Clouds erhöht sich diese Gefahr. Sicherheit ist immer an Voraussetzungen gebunden, im schlimmsten Fall verliert man sie, im besten Fall ist es redundant und deshalb zu teuer. Ganz offensichtlich braucht es detaillierte Spielregeln, um Transparenz in der Erwartungshaltung zu erreichen und Effizienz zu erzielen. Diese Spielregeln müssen außerdem flexibel auf Umgebungsszenarien ausgerichtet sein, um großen heterogenen IT-Landschaften gerecht zu werden.

Integration Security ist interdisziplinär

Das Ziel ist ein konsistentes Sicherheitsniveau für die ganze Unternehmung. Das kann in großen heterogenen IT-Landschaften multinationaler Unternehmen aufgrund der Komplexität mit großem Aufwand verbunden sein und benötigt eine integrative horizontale Perspektive. Die im Sicherheitsbereich strukturierenden Regeln und Grundmechanismen müssen über die ganze IT-Landschaft hinweg konsistent angewendet werden. Man kann damit einen großen Bogen von regulativen Compliance-Anforderungen über Identity Management, Zugriffskontrolle, Datensicherheit und die Trustkonzepte in den unterschiedlichsten IT- und SOA-Technologien spannen. Ein gemeinsamer Nenner an Sicherheitsinformationen und Security Patterns kann dabei behilflich sein, Interoperabilität zu ermöglichen und gleichzeitig die Komplexität in einen linearen Bereich zu bringen, damit sie beherrschbar wird.

Roberto Di Paolo arbeitet seit 1998 bei der Credit Suisse, seit 2002 in der IT-Sicherheitsarchitektur. Der Fokus liegt auf Internetsicherheit, Integrationssicherheit und Accountability.
Kommentare

Schreibe einen Kommentar

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