2011_6 IBM Sicherheitsrichtlinien

»manage it« als

E-Paper 11-12 2011
E-Paper 9-10 2011
E-Paper 5-6 2011
E-Paper 3-4 2011
E-Paper 1-2 2011
E-Paper 11-12 2010
E-Paper 9-10 2010
E-Paper 7-8 2010
E-Paper 5-6 2010

Sicherheitsrichtlinien im verteilten Anwendungsumfeld

Vereint administrieren, getrennt durchsetzen

Man stelle sich vor, der DFB würde ein Fußballländerspiel planen. Alles wäre organisiert, vom Kartenverkauf bis zur Übernachtung für die Gastmannschaft. Nur die Sicherheitskräfte wären nicht von Anfang an beteiligt. Großer Ärger wäre den Verantwortlichen sicher, eventuell würde das Spiel sogar abgesagt. In der IT dagegen ist genau das die übliche Vorgehensweise: IT-Security wird als ein rein technisches Thema verstanden und in Projekten oft erst spät oder im Nachhinein berücksichtigt.

atsächlich sollten aber die Anforderungen an die IT-Security aus konkreten geschäftlichen Vorgaben abgeleitet werden. Dies ist mit drei Herausforderungen verbunden: Erstens muss der Beitrag der Security zur Umsetzung von geschäftlichen Erfordernissen von Anfang an mit betrachtet werden. Zweitens muss die IT – und damit auch die IT-Security – so flexibel bleiben, dass sie auf Veränderungen im Markt oder in den Regularien schnell und wirtschaftlich reagieren kann. Und drittens sind statt Punktlösungen übergreifende Ansätze für das Gesamtsystem gefragt.

Das Ziel ist, Sicherheitsvorgaben konsistent und kosteneffizient umzusetzen. Sicherheitsrichtlinien auf der Basis von Standards können dies leisten.

Regeln formulieren

Der Prozess beginnt mit der Formulierung von allgemein gefassten Anforderungen in natürlicher Sprache. Beispiele sind:

· Alle Daten müssen gemäß ihrer Klassifizierung vor unberechtigter Einsichtnahme durch geeignete Maßnahmen geschützt werden.

· Jeder Zugriff auf die zentrale Personaldatenbank muss protokolliert werden.

· Was nicht ausdrücklich erlaubt ist, ist verboten. Oder auch: Was nicht explizit verboten wird, ist erlaubt.

Der nächste Schritt besteht darin, dies in eine formale Syntax zu bringen, eventuell unterstützt durch einen Policy Editor. Dieser Schritt stellt bereits den Übergang in die Technik dar. An dieser Stelle wird die Verwendung von Standards wichtig.

Anschließend werden die Sicherheitsrichtlinien in ausführbare Regeln übersetzt. Wichtig ist es hier, auf die Auditierbarkeit zu achten. Staatliche und anderen Kontrollstellen verlangen einen Nachweis über die Umsetzung der Sicherheitsrichtlinien und häufig auch eine zeitliche und personelle Zuordnung. Dafür müssen auch Transaktionen dokumentiert werden.

Sicherheitsrichtlinien nach Bedarf wählen

Die konkreten Sicherheitsrichtlinien müssen sich immer nach den Anforderungen des Unternehmens oder der speziellen Anwendung richten. Hier lassen sich drei unterschiedliche Typen unterscheiden:

Die Autorisierung ist die einfachste Form einer anwendungsbezogenen Sicherheitsrichtlinie. Sie bestimmt per ja/nein-Entscheidung wer was aufrufen darf und lässt sich außerhalb der Applikation gut zentralisieren. So dürfen zum Beispiel in einer Versicherung nur Sachbearbeiter und Kundenbetreuer die Schadensbearbeitung aufrufen.

Berechtigungen erweitern die ja/nein-Entscheidung durch zusätzliche Bedingungen. Grundlagen können entweder Attribute sein, etwa ein Betreuerkennzeichen im Vertrag, das bestimmt welche Kunden welchem Kundenbetreuer zugewiesenen sind. Oder es greifen regelbasierte Berechtigungen, beispielsweise für eine maximale Schadenssumme, die der Betreuer alleine bearbeiten darf. Ein letzter Typ von Sicherheitsrichtlinien befasst sich mit der Geheimhaltung und Integrität von Daten. Technisch umgesetzt wird diese Datensicherheit durch kryptografische Methoden.

Auf Standards setzen

Es haben sich folgende Industriestandards als zweckmäßige technische Basis herausgestellt:

· XACML (eXtensible Access Control Markup Language) von OASIS, einer herstellerunabhängigen Standardisierungsgruppe steht für ein Modell zur Unterstützung von Autorisierungsentscheidungen sowie eine XML-basierte Sprache, in der Policies formuliert werden und Autorisierungsentscheidungen abgefragt werden können. Das zugehörige abstrakte Szenario (Entscheidungskontext) zeigt die folgende Grafik.

· WS-SecurityPolicy und WS-Policy (ebenfalls von OASIS) beschreiben die kryptografischen Anforderungen an eine Web Services Services-Nachricht, welche mit WS-Security umgesetzt werden.

Aufgaben auf Funktionsblöcke aufteilen

Das Beispiel des XACML-Modells zeigt die wichtigsten Eigenschaften eines Policy-Systems. Dabei bildet die Administrationskomponente (PAP) gemeinsam mit dem Policy Decision Point (PDP) das Bindeglied zwischen Abstraktion und Umsetzung.

Erstellung und Modifikation von Policies in abstrakter Form passieren im Policy Administration Point (PAP). Vorgegeben werden müssen der Entscheidungskontext (Subjekt, Ressource, Aktion, Environment) sowie der Typ der Policy (etwa Autorisierung, Message Protection, Auditing). Die Autorisierungs-Policy erlaubt (permit) oder untersagt (deny) Zugriffe, in Abhängigkeit von Bedingungen wie der Gruppen- beziehungsweise Rollenzugehörigkeit des Subjekts, Regeln oder Attributen. Die Bedingungen werden abstrakt definiert und mittels logischer Operatoren miteinander verknüpft.

Um daraus eine konkrete Policy zu machen, müssen die Größen aus dem Kontext mit realen Entitäten verknüpft (gebunden) werden, etwa wird angegeben, dass man die Attribute des Subjekts in einem bestimmten LDAP-Verzeichnis findet. Schließlich gehört es zu den Aufgaben des PAP, die erstellten Policies an die PDPs zu verteilen und wenn nötig in ein anderes Format umzuwandeln.

Die zentrale Aufgabe des Policy Decision Point (PDP) besteht darin, zum Zeitpunkt eines Zugriffes die relevanten Daten zusammenzutragen und die Policy zu evaluieren. Der PDP wird durch eine Anfrage vom Policy Enforcement Point (PEP) angestoßen und gibt die Entscheidung in einer Antwort zurück. Werden zusätzliche Attribute benötigt, müssen diese mit Hilfe des PIP ermittelt werden. In Abhängigkeit von der jeweiligen Umgebung kann ein PDP mit einem PEP zusammenfallen. Dennoch handelt es sich stets um zwei logisch voneinander getrennte Funktionen.

Der Policy Information Point (PIP) ist ein Attributservice, der sowohl vom PDP als auch vom PEP befragt werden kann. Attribute können sich auf das Subjekt, die Ressource oder das Environment beziehen, also auf den gesamten Entscheidungskontext.

Die Aufgabe des Policy Enforcement Point (PEP) besteht darin, für jeden Zugriff mit Hilfe des PDP eine Autorisierungsentscheidung herbeizuführen und umzusetzen. Abhängig von der jeweiligen Laufzeitumgebung kann der PEP in vielfältigen Ausprägungen und Platzierungen vorkommen. Um einen Zugriff über einen externen PEP zu erzwingen, müssen im Netz eventuell Firewalls oder Screening Router eingerichtet werden, die eine Umgehung des PEP verhindern.

Policies externalisieren

Security Policies als Bindeglied zwischen Geschäftszielen und IT sollten nicht davon abhängen, wie sich die IT-Umsetzung auf verschiedene Anwendungsprogramme aufteilt. Somit bietet es sich an, die Umsetzung der Policies zu externalisieren. Man kann vier Ansätze (Patterns) unterscheiden, wie sich dies erreichen lässt, wie also der PEP in der Architektur platziert wird. Die Patterns schließen sich nicht gegenseitig aus, es kann also eine Kombination mehrerer geben.

Im ersten Szenario hat ein Vermittler (Intermediary) Kontrolle über die Zugriffe und deren Kontext, bevor sie zur Ausführung an die jeweilige Anwendung geleitet werden. Der Vermittler kann eine eigens eingeführte Komponente sein oder eine ohnehin vorhandene Gateway- beziehungsweise Firewallinstanz, ein Enterprise Service Bus (ESB) oder ein Reverse Proxy. Ein etwas speziellerer Fall ist die Laufzeitumgebung (Container), oftmals eng verknüpft mit einer Entwicklungsumgebung für Anwendungen. Beispiele hierfür sind Java Anwendungsserver oder Portale. Hier gibt es meist eine Architektur mit geeigneten Anknüpfungspunkten (beispielsweise Exits), wo sich ein PEP integrieren läßt.

In einer dritten Variante kann es genügen, das Datenbanksystem (sofern dieses ein eigenes Security-Modell hat), mit Policies zu versorgen, die dann eigenständig von einem PDP/PEP der Datenbankumgebung ausgeführt werden. Wenn verschiedene Anwendungen auf den gleichen Daten operieren, lassen sich mit diesem Ansatz Policies konsistent umsetzen. Für alle Szenarien, die in keines der drei Schemata passen, bleibt als letzte Möglichkeit die Policy-Unterstützung in der Anwendung selbst. Auch dies ist eine Externalisierung, denn es wird nur der PEP in der Anwendung implementiert. PDP und PAP verbleiben im zentralen Policy Management.

Regeln überwachen und verfeinern

Auf dem Weg von einer in natürlicher Sprache formulierten Richtlinie bis zur IT-technisch umgesetzten nachvollziehbaren Policy gilt es, eine Reihe von Schritten zu durchlaufen. Die Policies werden zunächst in abstrakter formaler Syntax erstellt. Die Konfiguration verknüpft dann die abstrakten Elemente mit ihrer realen Entsprechung. Schließlich werden die Policies an die PDPs verteilt und wie oben beschrieben umgesetzt. Durch die kontinuierliche Überwachung ergeben sich stets Ansätze für eine Verbesserung beziehungsweise Verfeinerung, es handelt sich also um einen iterativen Zyklus. Die dabei gewonnenen Erkenntnisse dienen einerseits der Einhaltung von Regularien (Compliance), andererseits der Dokumentation von Geschäftsvorfällen sowie nicht zuletzt der Gewinnung von Erkenntnissen für die Weiterentwicklung des Policy Management Systems selbst.

Die beschriebene Vorgehensweise sorgt dafür, dass Sicherheit ein zentrales Element von IT-Projekten wird. Wie beim Fußballländerspiel wird die Sicherheit von Anfang an und mit klarer Zielsetzung durchgeplant. Beim Fußball soll das sportliche Geschehen ungetrübt ablaufen können, die Besucher sollen sich sicher fühlen und nichts von der straffen Organisation bemerken. Ähnlich im Unternehmen: Wenn Security von Anfang an mit eingeplant wird, der Gesamtstrategie entspricht und die Einzelmaßnahmen und Notfallpläne funktionieren, dann läuft alles reibungslos in die richtige Richtung.

Günter Waller

__________________________________________

Günter Waller, Client Technical Professional, IBM Deutschland

Bild 1: Referenzmodell einer Autorisierung

Bild 2: Funktionsblöcke eines Policy Management Systems

Folgen Sie »manage it« auf Google+