Policy Definition und Policy Enforcement

Das Policy Management untergliedert sich in die drei wichtigen Handlungsebenen Policy Definition, Policy Enforcement und Policy Monitoring. Die Policy Definition umfasst die Erstellung der Richtlinien entsprechend den geschäftlichen Anforderungen sowie deren Aufberei-tung für die Übergabe an die Handlungsebene des Policy Enforcements. Das Policy Enforcement ist dagegen eine reine IT-getriebene Phase, in der die Richtlinien in den Applikationen, Zwischenstationen oder Diensten durchge-setzt werden. Damit liegen die entscheidenden Mecha-nismen für einen Brückenschlag zwischen den geschäft-lichen Anforderungen und einer flexiblen Umsetzung in

Authentication

Policies Message Protection

Policies Access Control

Policies

Requestor Initiator

Login Request

Recipient

Action Resource Message

Abbildung 39: Policy-Szenario

der IT überwiegend in diesen zwei Handlungsebenen. Das Policy Monitoring liefert zusätzlich die Möglichkeit, die Durchsetzung und die Wirksamkeit der Schutzmaßnah-men auf Basis der Richtlinien zu überprüfen. Die Ergeb-nisse dieser Phase können und sollten in der Erstellung bzw. Anpassung der Richtlinien einfließen.

Für eine erfolgreiche Unternehmensführung ist ein inte-grierter Ansatz bzgl. Governance, Risk und Compliance (GRC) notwendig. Governance beinhaltet u. a. die Vorgabe unternehmensweiter strategischer Richtlinien. Im Risi-komanagement können auf Basis spezieller Methoden frühzeitig Bedrohungsszenarien identifiziert und entspre-chende Maßnahmen in Form von Richtlinien abgeleitet werden. Compliance umfasst die Überwachung der Richt-linien in Bezug auf ihre Einhaltung im operativen Betrieb.

Das Policy Management entspricht den Grundsätzen des GRC-Modells. Dabei werden die Themen Governance und Risikomanagement vorwiegend in der Handlungsebene der Policy Definition behandelt, das Thema Compliance dagegen in den Ebenen von Policy Enforcement und Policy Monitoring.

Policy Definition

Die Erstellung von Richtlinien basiert auf einem inkre-mentellen Ansatz, der üblicherweise mit der Definition von allgemeinen unternehmensrelevanten Richtlinien (Corporate Policies) startet. Von diesen werden nach einem geeigneten Klassifizierungsschema weitere Richt-linien (z. B. RichtRicht-linien untergliedert nach Prozessklassen) abgeleitet und mit zusätzlichen Informationen verfeinert.

Im Rahmen der Verfeinerung in einzelnen Schritten soll-ten die Richtlinien dann in Gruppen gegliedert werden, die den Sicherheitsverfahren Nachrichtenschutz (Message Protection), Authentifizierung und Autorisierung (Access Control) zuzuordnen sind. Diese Gruppierungen sind in den unterschiedlichen Technologien und Standards begründet, die für die jeweiligen Sicherheitsverfahren bezüglich Policy Management anwendbar sind: WS-Security Policy für den Nachrichtenschutz, SAML für die Authentifizierung und XACML für die Autorisierung. Am Ende der Hierarchie (siehe Abbildung 9) müssen Richt-linien zur Verfügung stehen, die von den jeweiligen IT-Systemen interpretiert und angewendet werden können.

Policy Definition Governance & Risk

Policy Enforcement Policy Monitoring Compliance

Abbildung 40: Handlungsebenen Policy Management

Human readable

Machine readable Business

Aspects

IT Aspects

Governance & Risk

Prozess-specific Policy

Security-specific Policy

Service-specific Policy

Abbildung 41: Policy-Hierarchie

Abgesehen von der inkrementellen Verfeinerung durch-laufen die Richtlinien in der Hierarchie von Ebene zu Ebene einen Transformationsprozess. Liegen die Richtlinien auf der oberen Ebene noch in einer frei gestalteten, allgemei-nen und menschenlesbaren Form vor (z. B. Richtlinien-Dokument), so müssen die Richtlinien spätestens auf der untersten Ebene in einer standardisierten, konkreten und maschinenlesbaren Form (z. B. XML) den IT-Systemen über-geben werden. Die Kernfrage hierbei ist, ob und in welcher

Ebene man den Transformationsprozess automatisieren kann. Wurden in den Zwischenebenen bereits (standardi-sierte) Modelle wie BPMN oder UML verwendet, ist eine automatische Transformation in die nachfolgende Ebene technologisch realisierbar. Die Kluft zwischen der geschäft-lichen und der IT-Sicht wird an den Stellen besonders spür-bar, wo noch manuelle Übersetzungen notwendig sind. Je größer der Automatisierungsgrad ist, desto geringer wird diese Kluft in der Praxis ausfallen.

Service-specific Policies

Security-specific Policies

Process-specific Policies Corporate Policies

Message Protection Policies Authentication Policies

Access Control Policies

Degree of Details

…

Transformation & Refinement

Abbildung 42: Policy Transformation und Refinement

Policy Administration

Die Policy Administration setzt innerhalb der Policy-Hierarchie in der Ebene auf, ab der eine automatische Transformation bis zu den IT-interpretierbaren Richtlinien gegeben ist. Da durch die Veränderung von Richtlinien die Möglichkeit einer direkten Beeinflussung der IT-Systeme besteht, müssen die Administrationsaktivitäten mit gesonderten Maßnahmen vor unerlaubter Benutzung geschützt werden. Insbesondere ist festzulegen und durchzusetzen, wer welche Richtlinien ändern darf. Die Verteilung der Administrationsaufgaben auf verschie-dene Personen erscheint hier sinnvoll. Zudem sollten über

geeignete Auditing-Mittel alle Aktivitäten protokolliert werden. Es ist ratsam, neue bzw. geänderte Richtlini-enbestände nur durch gesonderte Freigabeprozesse mit qualitätssichernden Maßnahmen freizugeben, da die Richtlinien einen Einfluss auf die Verfügbarkeit der IT-Systeme haben werden. Zudem kann eine Versionie-rung von Richtlinien die Wiederherstellung im Fehlerfall unterstützen.

Top-down vs. Bottom-up

Der Top-down-Ansatz ist die bevorzugte Art und Weise Richtlinien zu entwickeln, um diese entsprechend den

geschäftlichen Anforderungen auszurichten. Um aber die Fähigkeiten der jeweiligen IT-Systeme in Bezug auf die Sicherheitsverfahren berücksichtigen zu können, wird man um eine Bottom-up-Betrachtung nicht herum-kommen. Schließlich gilt auch für die Policy Definition der Grundsatz, dass sich die Richtlinien an den Fähig-keiten der IT-Systeme orientieren müssen. Dabei sollte die Realisierung mit vertretbarem Aufwand erfolgen.

Entsprechend ist eine Lösung von Konflikten zwischen den geschäftlichen Anforderungen und der möglichen Umsetzung in der IT ein wichtiger Bestandteil des Defini-tionsprozesses. Zudem berücksichtigt erst die Bottom-up-orientierte Entwicklung von Richtlinien deren mögliche Wiederverwendung. Wird innerhalb einer SOA beispiels-weise ein Service mehrfach, aber in verschiedenen Sicher-heitskontexten (z. B. Internet oder Intranet) verwendet, sind die folgenden Lösungsstrategien anwendbar:

Der Service ist in Abhängigkeit vom aufrufenden Konsu-menten in der Lage, verschiedene Sicherheitseinstellun-gen zu verwenden. In diesem Fall können die Richtlinien unabhängig voneinander entwickelt werden. Die Auswahl der anzuwendenden Richtlinien ist zur Laufzeit vom aktu-ellen Kontext abhängig.

Der Service kann aufgrund von technischen Restriktionen nur einen Satz von Sicherheitseinstellungen verwenden.

Entweder werden die stärksten Richtlinienanforderungen verwendet oder es müssen entsprechende Kompromiss-lösungen gefunden werden. In jedem Fall ist dies aber nur mit einer Bottom-up-Betrachtung realisierbar.

Die Diskussion Top-down vs. Bottom-up in der Ent-wicklung von Richtlinien zeigt Parallelen zum Thema Entwicklung von Webservices. Hier stehen die Services mit geschäftlicher Orientierung, die nach dem Top-down-Ansatz entwickelt wurden, den Services mit applikations-spezifischer Sicht gegenüber, die nach dem Bottom-up-Ansatz entwickelt wurden. Als ein akzeptabeler Weg hat sich auch in dieser Hinsicht die Kombination der beiden Ansätze erwiesen.

Policy Enforcement

Das Policy Enforcement ist für die Durchsetzung der Richt-linien auf der Service-Seite verantwortlich. Das bedeutet, dass die Request-Nachrichten oder die eigentlichen Akti-onen abgewiesen werden, wenn diese nicht den Regeln entsprechen. Dazu benötigt der PEP die vollständige Nachricht oder mindestens Informationen über die Iden-tifikation des Nachrichtensenders sowie die Aktions- und Ressource-Kennung. Diese Daten bilden die Grundlage für die Auswahl der relevanten Richtlinien sowie deren Analyse bezüglich ihrer Auswirkung. Dazu ist grundsätz-lich der Zugriff auf ein Policy Repository notwendig. Die Auswertung der Richtlinien kann hinsichtlich des PEP auf zwei verschiedenen Varianten beruhen:

Der PEP hat einen direkten Zugriff auf die gespeicher-ten Richtlinien. Die Auswertung dieser Richtlinien bzgl.

Relevanz und deren Auswirkung erfolgt innerhalb des PEP.

Diese Variante eignet sich für Richtlinien, deren Informa-tionen direkt für die Durchsetzung verwendet werden können, ohne dass sie eine komplexe Analysemethodik erfordern. Ein Beispiel hierfür sind Richtlinien für den Nachrichtenschutz. Diese geben Anforderungen (Algorith-mus, Reihenfolge, Schlüsseltyp, …) bzgl. der Verschlüsse-lung und Signierung vor, die dann direkt mit der Nach-richt verglichen werden. EntspNach-richt die NachNach-richt diesen Anforderungen, wird sie weitergeleitet. Anderenfalls wird die Nachricht abgelehnt.

Alternativ kann die Entscheidungsfindung, ob die Request-Nachricht bzw. die auszuführende Aktion auf-grund der vorgegebenen Richtlinien bewilligt oder abge-lehnt werden muss, in eine externe Komponente/einen Service (PDP) ausgelagert werden. Bei dieser Variante übergibt der PEP spezielle Informationen an den PDP. Dies entspricht dem Architekturprinzip „Security as a Service“

und bietet die Möglichkeit der Entkopplung der Policy-Validierung von dem eigentlichen Service. Damit erfordert nur der PDP einen Zugriff auf die Richtlinien. Allerdings liefert der PDP als Ergebnis der Entscheidungsfindung nur ein „Urteil“. Für die Ausführung des Urteils ist dagegen der PEP verantwortlich.

In einigen Anwendungsfällen ist ein Policy Enforcement auch auf der Client-Seite zu realisieren. Beispielsweise könnte es aus Sicherheitsgründen erforderlich sein, dass

der Client die empfangenen Response-Nachrichten in Bezug auf die Einhaltung der vereinbarten Richtlinien überprüft.

Abbildung 43: Policy Enforcement