Zusammenfassung Prozesse in Serviceorientierten Architekturen lassen sich durch Komposition von Services realisieren. Die dabei verwendeten Services sind jedoch nicht notwendigerweise allesamt innerhalb der eigenen Unternehmung vorhanden, sondern über Organisationsgrenzen hinweg verteilt. Im Fall von fehlendem Einsatz entsprechender Sicherheitstechnologien sind die Nachrichten, die für die Invokation externer Services mit dem Service Provider ausgetauscht werden, möglicherweise das Ziel von Angreifern, die die Nachrichten manipulieren oder den Nachrichtenaustausch gänzlich verhindern können. Insofern sind Mechanismen erforderlich, die eine sichere und zuverlässige Serviceausführung ermöglichen. Der in dieser Arbeit vorgestellte Serviceüberwachungs- und Steuerungsansatz soll den Ausfall des gesamten Prozesses aufgrund von manipulierten, fehlerhaften oder ausgefallenen Services verhindern.
Daher wird in Abschnitt 2 der in unserer Arbeit in [6] vorgestellte Ansatz zur Gewährleistung einer zuverlässigen Prozessausführung um Sicherheitsaspekte mit dem Ziel erweitert, eine sichere und zuverlässige Prozessausführung zu erreichen. Diesbezüglich wird einen Ansatz beschrieben, um Sicherheit für die Entscheidung zu quantifizieren, welcher Service für die Realisation eines bestimmten Prozessschrittes selektiert werden soll. Das entsprechende Optimierungsproblem wird in Abschnitt 3 formuliert und gelöst. Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick. 2
Um einen Prozessausfall aufgrund von Servicefehlern zu verhindern, wurde ein dreistufiger Überwachungs- und Steuerungsansatz realisiert, der in Abbildung 1 dargestellt ist.
ID Service x
ID Service x Alternative Services Monitor Service x Status
ID Service x’ ID Service x
Service 1 Service 2 Service x Service n
Der Service Monitor misst die Ausführungszeit des invokierten Services. Überschreitet dieser den in den Service Level Agreements (vgl. [7]) angegeben Wert, wird die Replanning-Komponente aufgerufen. Diese identifiziert unter Zuhilfenahme einer Semantic Matchmaking Komponente alternative Services (anhand von semantischen Annotationen), die im Web Service Repository gelistet sind. Um eine Auswahl zu treffen, welcher der alternativen Services den ausgefallenen ersetzen soll, stellt die Replanning-Komponente im Rahmen des Service-SelektionsProblems (vgl. [8–10]) das in Abschnitt 3 beschriebene Optimierungsproblem auf und löst es optimal hinsichtlich der nicht-funktionalen Service-Eigenschaften (Quality of Service – QoS). Dabei werden sowohl der bisher noch nicht erfolgreich ausgeführte Prozessschritt sowie alle nachfolgenden Prozessschritte des ursprünglichen Ausführungsplans für die Optimierung berücksichtigt.
Auf diese Weise ist jedoch noch nicht sichergestellt, dass die eingebundenen Services nicht von Angreifern manipuliert wurden. Insofern sind Sicherheitsmechanismen wie Verschlüsselung, Digitale Signaturen und Checksummen erforderlich, die eine solche Manipulation erkennen, um den manipulierten Service durch einen alternativen Service (wie beschrieben) auszutauschen. Um im Rahmen des Service-Selektions-Problems diese qualitativen Sicherheitseigenschaften von Services als QoS-Parameter berücksichtigen zu können, ist eine Quantifizierung dieser Eigenschaften notwendig. Eine Voraussetzung stellt dabei ihre Erfassbarkeit dar. Andernfalls lässt sich keine nachvollziehbare, konsistente Zuordnung der qualitativen Eigenschaft auf einen numerischen Wert finden. Konsistent bedeutet dabei, dass einer erfassten Eigenschaft immer der gleiche, numerische Wert zugewiesen wird. Im Kontext von Sicherheitsmetriken definiert Jaquith in seiner Arbeit [11] eine gute Metrik als einen „konsistenten Standard für die Messung“. Er fordert von einer guten Metrik, dass ihre Messung konsistent möglich sein sollte und dass sie günstig (vorzugsweise automatisiert) erfassbar ist. Zudem sollte sie durch eine numerische Zahl ausgedrückt werden können und nicht durch qualitative Kennzeichnungen wie „high“, „medium“ oder „low“.
Die vorliegende Arbeit verfolgt das Ziel, einen nachvollziehbaren und konsistenten Ansatz zur Zuordnung von Sicherheitseigenschaften auf numerische Werte zu finden. Hierfür wird in Anlehnung an die in [12] definierten Schutzziele (Daten-) Integrität, (Informations-) Vertraulichkeit, Verfügbarkeit, Verbindlichkeit, Authentizität und Privatheit entsprechende Sicherheits-Level als QoS-Parameter definiert. Sind die mit externen Serviceanbiertern ausgetauschten Nachrichten bspw. verschlüsselt und/oder digital signiert, sind die Schutzziele Authentizität und Vertraulichkeit erfüllt. Zudem kann mithilfe von Checksummen die Integrität der erhaltenen Nachrichten überprüft werden. Je nachdem, welche Schutzziele von einem Service bzw. von einem Service Provider erfüllt werden, wird für den betreffenden Service ein gewisser Level gesetzt. D. h., dass bestimmte SicherheitsEigenschaften bestimmten Levels zugeordnet werden. Dies kann jedoch nicht generisch vorgenommen werden, sondern muss spezifisch für eine bestimmte Situation bzw. für ein bestimmtes Szenario durchgeführt werden. Bspw. könnte es in einem Business-Kontext wichtiger sein, dass zur Wahrung von Betriebsgeheimnissen die Informationen verschlüsselt sind, die zur Invokation eines externen Services als Eingabeparameter die Unternehmensgrenzen verlassen, als dass die zurück gelieferten Ergebnisse integer sind. Handelt es sich jedoch um erfolgskritische Prozesse (wie bspw. in einem Katastrophenszenario), sind Integrität und Autorisierung von essentieller Bedeutung. Allerdings ist die alleinige Zuordnung einer Sicherheits-Eigenschaft zu einem Sicherheitslevel nicht immer ausreichend. Bspw. könnte ein Angreifer das Ergebnis einer externen Service-Invokation abfangen und stattdessen andere Ergebnisse an den ursprünglichen Service-Aufrufer weiterleiten. Diese Ergebnisse sind zwar auch integer, sie stammen aber nicht von der Instanz, von der die Funktionalität des aufgerufenen Services erwartet wurde. Um hier ein Beispiel zu nennen, könnte ein Angreifer in einem Katastrophenszenario mit Hochwasser falsche Informationen über Pegelstände weiterleiten, sodass notwendige Maßnahmen nicht angemessen geplant werden können. In diesem Kontext muss also eine Kombination von Sicherheits-Eigenschaften vorliegen, um eine Zuordnung zu bestimmten Sicherheits-Levels vornehmen zu können. Als mögliche Kombinationen werden im Rahmen dieser Arbeit zunächst die in Abbildung 2a und Abbildung 2b angegebenen Level vorgeschlagen. Die Level haben per Definition h ganzzahlige numerische Werte s ∈ S = {1, ..., h}. Dabei wird dieser Parameter als positiver QoS-Parameter definiert, sodass ein höherer Wert besser ist. Sind auf diese Weise Sicherheits-Level für die verwendeten Services erstellt worden, lässt sich dieser nun quantifizierte Parameter als QoS-Parameter für die Formulierung des Optimierungsproblems in Abschnitt 3 verwenden.
Level 1 Level 2 Level 3 Level 4
Verbindlichkeit
Integrität Vertraulichkeit Authentifikation
Level 1 Level 2 Level 3 Level 4
Authentifikation Verbindlichkeit
Integrität
Vertraulichkeit (a) Kombination 1
(b) Kombination 2
3
Die in Abschnitt 2 angesprochene Replanning-Komponente befasst sich mit dem
Service-Selektions-Problem. D. h., sie erstellt einen optimalen Ausführungsplan,
indem sie entscheidet, welcher Prozessschritt von welchem dafür infrage
kommenden Service realisiert werden soll. Optimal bedeutet in diesem Zusammenhang,
dass diejenigen Services selektiert werden, die vorgegebene Restriktionen
einhalten und hinsichtlich ihrer QoS Eigenschaften am besten sind. In anderen Worten
ist bei der Auswahl der Services zu beachten, dass die gebildete
Servicekomposition einerseits bestimmte Restriktionen in Bezug auf ihre QoS-Parameter
einhält, die in Modell 1 als Nebendingungen formuliert sind. Andererseits soll
sie die in (
Um das Systemmodell zu erstellen und das Optimierungsproblem zu
formulieren, wird unser in [6] vorgestellte, generische Ansatz für die fünf
QoSParameter Zuverlässigkeit r, Sicherheit s, Verfügbarkeit a, Ausführungszeit t
und Kosten c, die in dieser Reihenfolge mit k ∈ K = {1, 2, 3, 4, 5} nummeriert
werden, erweitert. Dabei wird zunächst von einer sequenziellen Anordnung von
n Prozessschritten ausgegangen. Prozessschritt i ∈ I = {1, ..., n} wird vor
Prozessschritt i + 1 ausgeführt. Für jeden Prozessschritt i gibt es mi alternative
Services ji ∈ Ji = {1, ..., mi}, wobei Prozessschritt i durch genau einen Service
ji realisiert wird. Diese Services ji unterscheiden sich hinsichtlich ihrer fünf
QoS-Parameter qijk. Ist ein höherer (geringerer) QoS-Wert besser, handelt es
sich um einen positiven (negativen) QoS-Parameter. Die Restriktionen für die
QoS werden mit bk bezeichnet. Die Entscheidungsvariablen xij ∈ {0, 1} geben
Auskunft darüber, ob Prozessschritt i durch Service j realisiert wird. Um die
(unterschiedlichen) QoS-Parameter für die Zielfunktion aggregieren zu können,
ist eine Normalisierung für alle Werte qijk erforderlich, die in Gleichung (
qinjokrm := (1 −qimjka−xm{qiinjk{}qi−jkm}in{qijk}
max{qijk}−qijk max{qijk}−min{qijk} , falls k negativer QoS , sonst Modell 1 Nicht-lineares Optimierungsproblem Zielfunktion maximiere F (x) = Xn Xmi X3 31 qinjokrmxij
Die zu maximierende Zielfunktion ist in (
Da es sich bei (
n mi Y X zij xij ≈ 1 − i=1 j=1 n X(1 − i=1 mi X zij xij ) j=1 mi X sij xij ≥ b2 j=1
Das hierdurch erhaltene lineare Optimierungsproblem lässt sich mit Methoden des Operations Research optimal lösen, sofern eine Lösung existiert (vgl. [14]). Hierbei ist jedoch zu berücksichtigen, dass es sich bei dem beschriebenen Optimierungsproblem um ein NP-schweres Problem handelt [9, 15, 16]. Bei steigender Problemgröße lässt sich die Heuristik H1_RELAX_IP [17] verwenden, die bei großen Problemgrößen nicht signifikant schlechter abschneidet als das exakte Lösungsverfahren [18]. Hier wird die Ganzzahligkeitsbedingung relaxiert und das so entstandene gemischt-ganzzahlige lineare Optimierungsproblem optimal gelöst. Anschließend werden diejenigen Services ausgewählt, deren Werte in den Entscheidungsvariablen xij am größten sind.
Computation Time m = 10 5 10 15
Um einen Einblick in die Laufzeitkomplexität zu geben, wird die Laufzeit für die Berechnung der optimalen Lösung (durch Einsatz von Branch-and-Bound 100000 10000 iiittsaTenupom 1000 m n m o C 100 10 1 LP‐Solve Heuristik 100000 10000 sn m iiittaTeupnom 1000 m o C 100 10 1 LP‐Solve Heuristik Verfahren) für das formulierte Optimierungsproblem in Abbildung 3 und Abbildung 4 mit der Laufzeit der Heuristik H1_RELAX_IP verglichen. Dabei erreicht die Heuristik zumeist eine Lösungsgüte von mehr als 95% der optimalen Lösung. In Abbildung 3 wird die Anzahl alternativer Services pro Prozessschritt mi auf mi = 10 fixiert und die Anzahl an Prozessschritten n variiert. In Abbildung 4 wird die Anzahl an Prozessschritten n auf n = 10 fixiert und die Anzahl alternativer Services pro Prozessschritt mi variiert.
Computation Time n = 10 5 10 15 30 35
40 20 25
Category Size m Abbildung 4: Berechnungszeit bei Variation der Anzahl alternativer Services pro Prozessschritt 4
In der vorliegenden Arbeit wurde ein Serviceüberwachungs- und Steuerungsansatz vorgestellt, der durch eine optimale Lösung des Service-Selektions-Problems aufgrund der Gewichtung der QoS-Parameter Sicherheit, Zuverlässigkeit und Verfügbarkeit eine sichere und zuverlässige Prozessausführung gewährleisten soll.
Der Fokus für die zukünftige Arbeit wird einerseits auf die Formulierung von linearen Optimierungsproblemen für komplexe Prozesse gelegt, um den vorgestellten Ansatz auch für komplexe Prozessstrukturen verwenden zu können. Andererseits sollen Kombinationen der betrachteten Sicherheits-Eigenschaften hinsichtlich des erreichten Sicherheitsniveaus (Quality of Protection) analysiert werden, um ein Konzept für die Definition von sinnvollen Sicherheits-Levels zu entwickeln. Zudem wird die Evaluation des vorgestellten Ansatzes angestrebt. Acknowledgements. Diese Arbeit wurde in Teilen durch das BMBF-finanzierte Projekt SoKNOS (http://www.soknos.de) und durch das E-Finance Lab e. V., Frankfurt am Main, Deutschland, (http://www.efinancelab.de) unterstützt.