Design und Entwicklung einer Audit Policy Language für Cloud ...

wolke.hs.furtwangen.de

Design und Entwicklung einer Audit Policy Language für Cloud ...

Bachelor-ThesisinComputer NetworkingDesign und Entwicklung einer Audit PolicyLanguage für Cloud ComputingUmgebungenReferent:Prof. Dr. Christoph ReichHochschule Furtwangen UniversityKorreferent:M.Sc. Frank DölitzscherHochschule Furtwangen Universityvorgelegt am: 28.02.2013vorgelegt von:Tina KarbeNeuenweg 2a42929 Wermelskirchen


AbbildungsverzeichnisVAbbildungsverzeichnis1.1. Beispiel VM mit Policy Modeller . . . . . . . . . . . . . . . . . . . . 24.1. Rei Übersicht [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2. CIM grobe Strukturübersicht . . . . . . . . . . . . . . . . . . . . . . 254.3. WBEM Komponenten [2] . . . . . . . . . . . . . . . . . . . . . . . . 284.4. Beispiel LaSCO [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1. Aufbau der Klassen CAPL . . . . . . . . . . . . . . . . . . . . . . . 425.2. Mögliche Integration - Selbstverwaltung . . . . . . . . . . . . . . . . 555.3. Ausgeführte Abfrage aller MachineImage-Objekte . . . . . . . . . . 59


TabellenverzeichnisVIITabellenverzeichnis3.1. SAaaS 3 Policy-Szenarien . . . . . . . . . . . . . . . . . . . . . . . . 104.1. Rei Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2. Rei Allgemeine Kriterien . . . . . . . . . . . . . . . . . . . . . . . . 234.3. Policy-Modell CIM Kriterien . . . . . . . . . . . . . . . . . . . . . . 304.4. Policy-Modell CIM 4 Allgemeine Kriterien . . . . . . . . . . . . . . . 315.1. Genutzte Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2. Aufbau Grundgerüst . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3. Aufbau Cloud Entry Point . . . . . . . . . . . . . . . . . . . . . . . 455.4. Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.5. Aufbau MachineTemplate . . . . . . . . . . . . . . . . . . . . . . . 485.6. Aufbau MachineImage . . . . . . . . . . . . . . . . . . . . . . . . . 495.7. Aufbau MachineConfiguration . . . . . . . . . . . . . . . . . . . . . 495.8. Aufbau MetricRule . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.12. Aufbau RuleType . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.9. Aufbau PolicyRule . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.10. Aufbau PolicySet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.11. Aufbau Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633 Security Audit as a Service4 Common Information Model


ListenverzeichnisIXListenverzeichnis4.1. Beispiel Rei Erlaubnis zum Drucken - DeonticObject [1] . . . . . . . 214.2. Beispiel Rei Erlaubnis zum Drucken - Policy [1] . . . . . . . . . . . . 214.3. Beispielhafte Definition einer Klasse Zug“ in MOF[2] . . . . . . . . ”264.4. Beispielhafte Definition einer Assoziation Zugfahrplan“ in MOF [2] . ”275.1. CIMI Beispiel Erstellung einer Ressource mittels POST [3] . . . . . . 375.2. CIMI Beispiel GET-Abfrage [3] . . . . . . . . . . . . . . . . . . . . 385.3. Beispiel Policy Config Freeze httpd.conf . . . . . . . . . . . . . . . . 515.4. Beispiel Jersey-Klasse MachineImage ................. 58


AbkürzungsverzeichnisXIAbkürzungsverzeichnisCADFCAPLCEPCIMCIMICIMOMDMTFDSLGUIHTMLIaaSIETFJSONMOFNISTOWLCloud Auditing Data FederationCloud Audit Policy LanguageCloud Entry PointCommon Information ModelCloud Infrastructure Management InterfaceCIM Object ManagerDistributed Management Task Force, IncDomain Description LanguageGraphical User InterfaceHyper Text Meta LanguageInfrastructure as a ServiceInternet Engineering Task ForceJavaScript Object NotationManaged Object FormatNational Institute of Standards and TechnologyWeb Ontology LanguagePAX PDL a non-procedural packet description languagePPLPacket Processing Language


XIIAbkürzungsverzeichnisRDFRDFSRESTSAaaSSQLUMLURIVMWBEMXMLResource Description FrameworkResource Description Framework SchemaRepresential State TransferSecurity Audit as a ServiceStructured Query LanguageUnified Modeling LanguageUniform Resource IdentifierVirtual MachineWeb-Based Enterprise ManagementExtensible Markup Language


1. Einführung 11. Einführung1.1. Motivation und ZielsetzungSAaaS ist ein in der Entwicklung befindliches System zur automatischen Auditierung,das speziell auf die Gegebenheiten von Cloud-Umgebungen, wie in Kapitel2.1 erläutert wird, ausgerichtet ist wie bspw. die Dynamik und Flexibilität der Infrastruktur.Es ermöglicht dem Benutzer der Cloud, seine Infrastruktur auf Anomalien zuüberprüfen und so rechtzeitig geeignete Maßnahmen treffen zu können. Durch einenverteilten Ansatz und die automatische Verteilung von autonomen Agenten 5 wird einehohe Flexibilität erreicht, die weiterhin auch ermöglicht, auf Änderungen der Infrastruktur,wie das Hinzufügen oder Verschieben von VMs 6 zu reagieren [5].Zur Auditierung werden die Agenten automatisch auf die einzelnen VMs verteilt,wobei zur eigentlichen Überwachung Agenten auf verfügbare Standardsoftware wieClamAV 7 oder Inotify 8 zurückgegriffen wird. Diese wird bei Bedarf vom Agentenmitgeliefert und konfiguriert. Die Resultate werden von den Agenten selbstständiganalysiert, bewertet und aggregiert. Dabei bringen diese eine gewisse Intelligenz mitund die Fähigkeit, untereinander zu kommunizieren, um so beispielsweise Events auszutauschen.[6] Die Konfiguration des Agentenverhaltens ist derzeit nur manuell undumständlich möglich.Die Entwicklungsumgebung von SAaaS ist die Studi-Cloud, ein IaaS 9 , der den Studentender Hochschule Furtwangen ermöglicht, vorkonfigurierte VMs in der Cloud zu5”. . . a software entity which functions continuously and autonomously . . . able to carry out activitiesin a flexible and intelligent manner . . . we excpect an agent that inhabits an environment with otheragents and processes to be able to communicate and cooporate with them. . .“[4]6 Virtual Machines7 http://www.clamav.net/8 http://inotify-tools.sourceforge.net/9 Infrastructure as a Service


2 1. Einführungerstellen und zu starten. Da es sich um ein IaaS handelt, wird die Administration derVMs durch den Studenten selbst vorgenommen.Ziel dieser Thesis ist, eine Policy-Sprache zu finden, mit der eben diese Richtlinien, sogenannteSecurity Policies, für die Auditierung mit SAaaS abgebildet werden können.Aus diesen Policies beziehen die Agenten automatisiert ihre Konfiguration, bevor sieauf die Zielsysteme ausgerollt werden.Die gesuchte Sprache muss die Möglichkeit bieten, unterschiedlichste Policies abzubildenund auf die jeweiligen Bedürfnisse zur Auditierung der einzelnen Benutzer einzugehen,die unterschiedlichste und flexible Infrastrukturen in der Cloud besitzen.Als Resultat daraus wird der Cloud Benutzer befähigt, selbstständig Richtlinien fürseine VM zu erstellen, um den sicheren und gewünschten Zustand der VM zu beschreiben.Eine Möglichkeit zur Umsetzung dieser Idee mit Hilfe eines graphischenPolicy-Modellers wird in Abbildung 1.1 dargestellt.Abbildung 1.1.: Beispiel VM mit Policy Modeller


1. Einführung 31.2. Aufbau der ThesisDie vorliegende Ausarbeitung ist wie folgt strukturiert:• Kapitel 1 - das aktuelle Kapitel dient der Einführung in die Thematik und derBeschreibung der Zielsetzung sowie des Aufbaus dieser Arbeit.• Kapitel 2 - erläutert Grundlagen, die für das Verständnis dieser Arbeit notwendigsind wie Cloud Computing oder Security Policies.• Kapitel 3 - beschreibt die Anforderungen an die gesuchte Policy-Sprache sowiedie Kriterien, die in der nachfolgenden Evaluation herangezogen werden.• Kapitel 4 - basierend auf den gesammelten Anforderungen werden bestehendePolicy-Sprachen betrachtet und bewertet. Im Anschluss erfolgt eine Gegenüberstellungund das Ergebnis.• Kapitel 5 - dieses Kapitel dient dem Entwurf einer eigenen Cloud Audit PolicyLanguage, die speziell für die Erfüllung der Anforderungen entwickelt wurde.Im Anschluss wird die Integration in SAaaS beschrieben und in groben Zügendie ersten Implementierungen des Prototypen vorgestellt, gefolgt von möglichenErweiterungen.• Kapitel 6 - schließt diese Arbeit ab und fasst die Ergebnisse zusammen.Jedes Kapitel beginnt mit einer kurzen Einführung in den folgenden Inhalt. Die beigelegteCD-ROM enthält weitere Daten, Dokumente und Ergebnisse dieser Thesis. Dazugehören u.a. diese Arbeit in digitaler Form als PDF sowie als L A TEX-Quellcode, derbisherige Implementierungsstand und referenzierte Online-Quellen.


6 2. GrundlagenProvider mit angeboten werden. Amazon betreibt mit seinem EC2 11 einen solchenService.Software as a ServiceDer Provider stellt dem Anwender Software bereit, die durch eine Cloud Infrastrukturbereitgestellt wird. Der Benutzer verwaltet weder die Infrastruktur noch die Anwendungselbst, außer Benutzerrelevante Einstellungen in der Anwendung selbst. EinBeispiel hierfür wären fremdgehostete Office-Anwendungen wie Googles Webdrive 12oder Microsofts Office 365 13 .2.2. Security PolicyDer Begriff Security Policy wird wie folgt definiert:A security policy is a description of the security goals for a system and how a system”should behave in order to meet these goals.“ [8].A set of rules and practices that specify or regulate how a system or organization”provides security services to protect sensitive and critical system resources.“ [9].Zusammengefasst: Eine Security Policy besteht aus mehreren Regeln oder Zielen, dieAussagen darüber treffen, wie das System sich verhalten soll, um eben diese Regelneinzuhalten und das System zu schützen.2.3. Security AuditNach der Definition von [10] ist ein Audit eineFormal inspection and verification to check whether a standard or set ofguidelines is being followed, records are accurate, or efficiency and effectivenesstargets are being met.11 http://aws.amazon.com/de/ec2/12 https://drive.google.com/13 http://office.microsoft.com/de-de/


8 2. GrundlagenBeispiele für DSLs sind u.a. HTML 18 , SQL 19 oder die in dieser Arbeit definierte SpracheCAPL.18 Hyper Text Meta Language19 Structured Query Language


3. Anforderungsanalyse 93. AnforderungsanalyseIn diesem Kapitel werden die Anforderungen an die gesuchte Policy-Sprache fürSAaaS beschrieben. Zuerst werden einige zu überwachende Szenarien für die SAaaS-Architektur aufgestellt, die als Grundlage für die Erstellung von Policies dienen. Anschließendwerden weitere Kriterien definiert, anhand derer die Sprachen in der Evaluationbetrachtet und bewertet werden.3.1. Definition von Policy-SzenarienZur möglichst problemspezifischen und praktischen Definition der Anforderung an diegesuchte Sprache, wurden für die SAaaS-Umgebung Szenarien definiert, die durchSAaaS auditiert werden sollen. Als Grundlage dienten die Szenarien aus der Master-Thesis [14]. Um diese in der gesuchten Sprache abbilden zu können, wurden kurzeund prägnante Policies abgeleitet. Sprachen, die diese nicht abbilden können, werdenfür SAaaS ausgeschlossen.Die Tabelle 3.1 beschreibt die Szenarien und zeigt die abgeleiteten Policies.x steht füreinen im Kontext sinnvollen Wert.


10 3. AnforderungsanalyseTabelle 3.1.: SAaaS Policy-SzenarienBeschreibung des SzenariosSchadsoftwareDer Befall mit Schadsoftware kann mitunter dieVerfügbarkeit und die Integrität der Maschine einschränken.Das Szenario umfasst die Überprüfungauf Rootkits 20 und Viren.Überwachung von Dateien / KonfigurationenDie ungewollte Veränderung von Konfigurationsdateienkann u.a. durch Angreifer oderandere Benutzer erfolgen und die Integritätgefährden. Es gibt zwei gewünschte Szenarien:Die Überwachung der ganzen Datei auf jeglicheÄnderungen durch einen Vorher/Nachher-Vergleich oder die Überprüfung, ob die Dateibei Speicherung noch einen bestimmten Inhaltenthält. Letzteres ist insbesondere bei Konfigurationenwichtig, die bestimmte sicherheitsrelevantenEinstellungen enthalten müssen.resultierende Policies1) Die VM ist frei von Malware.2) Datei x darf nicht verändertwerden.3) Konfiguration x enthält einenbestimmten Inhalt bzw. Einstellung.Fortsetzung nächste Seite. . .20 Ein Rootkit ist eine Sammlung von Programmen / Werkzeugen, die dem Angreifer ermöglicht, seineSoftware vor Antiviren-Programmen zu verstecken.


3. Anforderungsanalyse 11Fortsetzung der Tabelle 3.1 (SAaaS Policy-Szenarien)Beschreibung des SzenariosHochskalierung der VMCloud-Umgebungen stehen für Flexibilität und dieBereitstellung der tatsächlich benötigten Ressourcen.Je nach Höhe der Last werden weitere Ressourcenbereitgestellt oder entfernt.Vor der Skalierung soll überprüft werden, ob essich um eine rechtmäßige Skalierung handelt oderdiese beispielsweise durch einen Angreifer ausgelöstwurde. Dies kann bei einem Webserverdurch die Überprüfung der tatsächlichen Anfragenpro Sekunde am Server erfolgen. Sind dort keine,werden keine weiteren Ressourcen benötigt.Überwachung PortsBei der Überwachung von Ports wird überprüft,ob nur erlaubte Ports geöffnet sind, alle anderenmüssen geschlossen sein. Geöffnete Ports, die eigentlichnicht offen sein sollten, können Indikatorenfür einen unerwünschten und ggf. kritischenZustand sein.Überwachung ProtokolleDieses Szenario umfasst das Erlauben bzw. Verbietenvon Protokollen sowie die Überprüfung, ob eineVerbindung mit einem Protokoll möglich ist.resultierende Policies4) Die Hochskalierung der VM istnur erlaubt, wenn mehr als x Anfragenpro Sekunde vorliegen.5) Port x darf offen sein.6) Protokoll x darf (nicht) verwendetwerden.7) Eine Verbindung mit demProtokoll x ist (nicht) möglich.Installierte Software8) Software x darf (nicht) installiertDie Möglichkeit, bestimmte Software zu verbietenkann, beispielsweise bei illegaler Software, wiesein.Torrent, oder Software mit bekannten kritischenSicherheitslücken, relevant sein.Fortsetzung nächste Seite. . .


12 3. AnforderungsanalyseFortsetzung der Tabelle 3.1 (SAaaS Policy-Szenarien)Beschreibung des SzenariosRichtlinien von PasswörternUnsichere Passwörter vereinfachen das Eindringenin ein System. Hierfür soll es möglich sein, gewisseRichtlinien zu erstellen, die Passwörter erfüllenmüssen. Dabei soll überprüft werden, ob die entsprechendenPasswort-Richtlinien im System konfiguriertsind, die sich bei der Setzung eines Passwortsum die Einhaltung der Richtlinien kümmern.Es sollen keine bestehenden Passwörter auf dieRichtlinien überprüft werden.Privilegierte BenutzerDie standardmäßige Arbeit in einem System alsprivilegierter Benutzer kann ein Risiken bergenbspw. unbewusst Systemdateien zu überschreibenoder Angreifern bei der Ausnutzung von Sicherheitslückenoder gar bei physikalischem Zugriffdirekt vollen Systemzugriff geben. Aus diesemGrund soll überprüft werden, ob mindestens einnicht privilegierter Nutzer existiert und ob der AutomatischeLogin ausschließlich für diese Benutzererlaubt ist.resultierende Policies9) Passwörter entsprechen denRichtlinien. 2110) Die VM enthält mind. einennicht privilegierten Benutzer.11) Automatischer Login istnicht für priviligierte Benutzererlaubt.Fortsetzung nächste Seite. . .21 Es wird davon ausgegangen, dass die Passwörter den Richtlinien entsprechen, wenn die Richtlinienim für die Passwortvergabe zuständigen System gesetzt sind und dieses sich um die Einhaltung beiSetzung des Passwortes kümmert.


3. Anforderungsanalyse 13Fortsetzung der Tabelle 3.1 (SAaaS Policy-Szenarien)Beschreibung des SzenariosGelöschte DateienDieses Szenario resultiert aus der Idee, dass Benutzereigene VM-Images in der Cloud hochladenund anderen Benutzern zur Instanziierung freigebenkönnen. In diesem Fall sollten sich keine privatenDaten des bereitstellenden Benutzers auf demImage befinden. Dazu gehört u.a., dass gelöschteDateien nicht wiederherstellbar sowie Logs undVerläufe leer sind.resultierende Policies12) Die VM enthält keinepersönlichen Daten.Eine Übersicht der in Kapitel 3.1 definierten Policies, mit beispielhaft gesetzten Wertenfür x, ist in der folgenden Liste zu finden. Die ersten sieben Policies wurden ausgewählt,um als Kriterium der Umsetzbarkeit der Policies in der ausgewählten Sprachezu dienen, indem die Abbildung möglich sein muss.1. Die VM ist frei von Malware, Viren und Rootkits.2. Datei httpd.conf darf nicht verändert werden.3. Die Hochskalierung der VM ist nur erlaubt, wenn mehr als 10 Anfragen proSekunde vorliegen.4. Konfiguration httpd.conf des Apache enthält eine bestimmte Zeile.5. Port 80 darf offen sein.6. Protokoll HTTP darf verwendet werden.7. Eine Verbindung mit dem Protokoll FTP ist möglich.8. Software Transmission 22 darf nicht installiert sein.9. Passwörter entsprechen den Richtlinien.10. Die VM enthält mind. einen nicht priviligierten Benutzer.11. Automatischer Login ist nicht für priviligierte Benutzer erlaubt.12. Die VM enthält keine persönlichen Daten.22 Torrent-Client Transmission:http://www.transmissionbt.com/


14 3. Anforderungsanalyse3.2. AuswahlkriterienFolgende Kriterien werden zur Bewertung und Gegenüberstellung der Sprachen in Kapitel4 herangezogen.3.2.1. SprachbasisEs gibt textuelle und graphische Sprachen zur Darstellung von Policies. Für SAaaSwird eine textuelle Sprache gesucht. Die Sprachen werden danach bewertet, ob sie aufbestehende Technologien wie XML aufbauen oder ein eigenes Format definieren undnutzen.Eigene Formate für die Sprache können ihr mehr Flexibilität verleihen und damiteine gezieltere Abbildung der Problemstellung erlauben. Die Nutzung von weitverbreiteten Technologien wie XML oder JSON hat u.a. den Vorteil, dass die Verwendungvon bestehenden Interpretern zur Serialisierung 23 den Aufwand in der Implementierungerheblich verringern können, weiterhin wird der Einstieg in die Spracheerleichtert, da diese Technologien und deren Methodiken oftmals bekannt sind.Eine Vorgabe des SAaaS-Projektes ist, XML nach Möglichkeit zu bevorzugen.3.2.2. Abbildung der Policy-SzenarienDas wohl wichtigste Kriterium zur Auswahl der Sprache, ist die Umsetzung der inKapitel 3.1 definierten Policies. Diese Szenarien müssen in der Sprache abgebildetwerden können, wozu weitere Merkmale wichtig sind.zu Überwachende ObjekteIn der SAaaS-Umgebung werden hauptsächlich Hosts und VMs überwacht. Hierbeigilt eine Policy für die ganze Maschine oder für einen spezifischen Teil wie bspw. eineDatei. Eine weitere Anforderung an die Sprache ist die Zuordnung von Policies zuVMs sowie die Festlegung der zu überwachenden Objekte.23 Unter Serialisierung wird der Prozess der Umwandlung von in einer Sprache dargestellten Daten inObjekte bezeichnet.


3. Anforderungsanalyse 15Verbindung von PoliciesEs kann durchaus vorkommen, dass mehrere unterschiedliche Kriterien für dieErfüllung einer Policy entscheidend sind. Somit sollten UND-/ODER-Verknüpfungenzwischen Policies oder Kriterien umgesetzt werden können.Definition von GültigkeitsbereichenDie Zuordnung von Gültigkeitsbereichen zu Policies vereinfacht die Verwendung undErstellung der Policies. Dies kann beispielsweise durch Gruppen von VMs oder Policiesumgesetzt werden.Die Definition von Policies, die nur vom Provider verwendet werden können, wärezudem nützlich.3.2.3. AktualitätBeim Kriterium Aktualität wird u.a. das Alter, der Implementierungs- bzw. Entwicklungsstatus,die Existenz einer Community 24 sowie die Akzeptanz der Sprache betrachtet.Eine hohe Akzeptanz und Anwendung in der Wirtschaft können die Reife und dieUmsetzbarkeit der Sprache widerspiegeln, während eine häufige Erwähnung nicht ausreicht,sondern keine praktische Anwendung erfolgt.3.2.4. DokumentationDie Qualität der Dokumentation ist essentiell für das Verständnis und somit für dieBewertung der Sprache. Die Verständlichkeit der Dokumentation wird durch mehrereFaktoren beeinflusst: die logische Struktur, die Verteilung und Verfügbarkeit, die Tiefesowie die Konsistenz der Dokumentation.Inkonsistenzen können die Einarbeitung erschweren und sogar zu einer gänzlichfalschen Einschätzung der Sprache führen. Solche Inkonsistenzen treten besonders24 Als Community wird eine Kommunikationsplattform bezeichnet, die den Austausch zwischen denBenutzern und Entwicklern ermöglicht, um alle möglichen Themen zu diskutieren, Hilfe zu erhaltenund mögliche Erweiterungen mit anderen zu teilen.


16 3. Anforderungsanalysehäufig bei verteilten bzw. modularen Dokumentationen mit Redundanzen auf. Trotzdemkann die durchdachte und strukturierte Verteilung und Modularisierung von Informationendie Einarbeitung generell beschleunigen und vereinfachen, da der Leserdie Tiefe seiner Betrachtung selbst bestimmen kann.3.2.5. KomplexitätZur Bewertung der Komplexität sind mehrere Aspekte relevant, wie z.B. die Einarbeitungszeit,die für ein gewisses Grundverständnis der Sprache benötigt wird. Hiersteht die Komplexität mit der Qualität der Dokumentation im engen Zusammenhang.Eine gut verständliche Dokumentation kann eine hohe Komplexität der Sprache ausgleichen.Ferner wird der Aufbau der Policies bewertet, wozu die Schwierigkeit zurAbbildung eigener Policies sowie die Lesbarkeit und Selbsterklärung bestehender Policieszählt.Die Komplexität verhält sich in den meisten Fällen proportional zur Mächtigkeit derSprache. Je flexibler die Sprache und je größer das Spektrum, das sie abdeckt, destokomplizierter wird sie. Generell ist Flexibilität eine wünschenswerte Eigenschaft, dasie mögliche Erweiterungen und Anpassungen vereinfacht, allerdings sollte die Sprachenicht zu kompliziert werden.3.2.6. Sonstige KriterienTrennung von Cloud Provider und Cloud BenutzerDie Maschinen der Cloud Provider und der Benutzer haben einen unterschiedlichenSchutzbedarf. Der Cloud Provider betreibt die Infrastruktur, dazu gehören Ressourcen,die für den Betrieb zuständig sind, wie Firewalls und die Hosts, auf denen die VMsbetrieben werden. Diese haben einen anderen Schutzbedarf als eine reguläre VM. Ausdiesem Grund gibt es spezifische Policies, die nur für den Betrieb der Infrastrukturnötig sind, wie bspw. die Hochskalierung (Policy Nr. 4) aus der o.g. Liste.Dies ist ein wünschenswertes Kriterium der Sprache und keine zwingende Vorgabe,da dies wahrscheinlich in der Implementierung oder durch kleine Anpassungen derSprache umgesetzt werden könnte.


3. Anforderungsanalyse 17Implementierung und AdaptierungHier wird der nötige Aufwand für eine Implementierung, die mögliche Erweiterung sowiedie Integration in SAaaS bewertet. Sollte es bereits einen Interpreter geben, wirddie Aktualität, die Verfügbarkeit von Ressourcen, die Komplexität und Erweiterbarkeitbewertet. Weiterhin wird Java als Sprache bevorzugt, da die Implementierung derSAaaS-Architektur auf Java basiert.


4. Evaluation bestehender Sprachen 194. Evaluation bestehender SprachenDieses Kapitel bewertet und vergleicht bestehende Policy-Sprachen für die Verwendungals Security Policy-Sprache in SAaaS. Die näher betrachteten Sprachen sind Rei,CIM Policy-Modell und LaSCO.4.1. ReiRei 25 ist eine OWL 2627 basierte Sprache, die von Lalana Kagal entwickelt und 2005abgeschlossen wurde. Durch OWL lassen sich eigene Klassen definieren und Rei somiteinfach erweitern. Rei ermöglicht die Abbildung von verschiedenen Policies wie z.B.Management-, Security-, Privacy- und Conversation-Policies[16]. Sie beschreiben dasoptimale Verhalten in einer Domäne, die einen Kontext darstellt in dem die Policygültig ist. Eine Policy wird durch den Verbot, die Erlaubnis bzw. die Verpflichtungeiner Aktion einer Einheit auf ein Ziel (target) definiert.4.1.1. AufbauRei besteht aus mehreren Klassen, die zur Abbildung einer Policy benötigt werden.Die wichtigsten werden in der folgenden Liste erläutert, wobei die Abbildung 4.1 dasZusammenspiel der Klassen veranschaulicht.• Entity - Beschreibt eine Einheit in der Domäne, wie Benutzer, Hardware Ressourcenoder Agenten.25Rei pronounced ray, is a Japanese word that means universal”[15].” 26 Web Ontology Language27 OWL-ist eine Ontologie Sprache für das Semantische Web.


20 4. Evaluation bestehender SprachenAbbildung 4.1.: Rei Übersicht [16]• Constraint 28 - Dient der Gruppierung von Objekten, beispielsweise eine Gruppevon Studenten oder eine Gruppe von Aktionen mit dem selben Ziel. Es wird inmehreren Objekten als Bedingung verwendet.• DeonticObject - Eine der wichtigsten Klassen in Rei. Sie ist gleichzusetzen miteiner Regel, die bestimmte Aktionen für Akteure beschreibt. Diese können erlaubt(Permission), verboten (Prohibition) oder verpflichtend (Obligation) sein.Die Regeln werden einer Policy durch Granting hinzugefügt und sind wiederverwendbar.• Policy - Enthält eine Liste von Regeln (DeonticObject), die in einem bestimmtenKontext (Constraint) gelten, bspw. für alle Studenten der Informatik.• Action - Repräsentiert eine Aktion in der Domäne mit einem Ziel und einerGruppe von Akteuren, die diese ausführen. Die Aktion kann selbst Vorbedin-28 RDF 29 -typisch im Subjekt, Prädikat, Objekt Format angegeben.


4. Evaluation bestehender Sprachen 21gungen besitzen, die zur Ausführung erfüllt sein müssen, wie beispielsweise:Zum Drucken muss Papier im Drucker vorhanden sein“. [1]”4.1.1.1. BeispielDeonticObject / RegelListing 4.1: Beispiel Rei Erlaubnis zum Drucken - DeonticObject [1]1 2 3 4 5 Listing 4.2 erstellt eine wiederverwendbare Regel mit dem NamenPerm StudentPrinting, die Studenten das Drucken auf bestimmten Druckern erlaubt,solange sie Papier nachfüllen. Im Constraint sind die Akteure (Studenten) undZiele oder auch targets (Drucker) enthalten, für die diese Regel gültig ist. Das hiergenutzte Constraint besteht aus je einem Constraint für Drucker und Studenten,die außerhalb des Beispiels definiert werden. Die Variablen PersonVar und ObjVarrepräsentieren die Studenten bzw. Drucker im Constraint.Listing 4.2: Beispiel Rei Erlaubnis zum Drucken - Policy [1]1 2 3 4 5 6 7 8


22 4. Evaluation bestehender Sprachen9 10 Listing 4.1 zeigt die eigentliche Policy, die neben der oben definierten eine weitere Regel(DeonticOject)Granting StudentLaserPrinting enthält. Die Domain wird durchein Constraint angegeben und sagt aus, dass diese Policy für alle Entities gilt, dieIsMemberOfCS zugeordnet sind. Das Attribut defaultBehaviour definiert das Verhaltender Policy. ExplicitPermImplicitProh gibt hierbei an, dass alles nicht expliziterlaubte, automatisch verboten ist. Mit den Zeilen 7 bis 9 ist es möglich, Prioritätender einzelnen Regeln anzugeben, um Konfliktsituationen zu vermeiden. Dies geschiehtz.B. dann, wenn die eine Regel eine Aktion erzwingt, während die selbe Aktion voneiner anderen Regel verboten wird.4.1.2. SonstigesImplementierungenEs werden verschiedene Tools zur Verwendung von Rei erwähnt[16], die allerdingsweder auf der offiziellen Webseite 30 , noch auf der SourceForge-Projektseite 31 aufzufindenwaren.• Policy Engine - Verwaltet Anfragen über Policies, beispielsweise: Kann Akteur”x die Aktion y auf z ausführen?“• Interface mit Java API und GUI• Analysis tools - Analyse Software, um verschiedener Test-Szenarien zu erzeugenund deren Auswirkungen zu analysieren.4.1.3. BewertungIn der Tabelle 4.1 werden die Kriterien zur Definition von Policies für Rei bewertetund auch direkt erläutert. Obwohl Rei alle gestellten Anforderungen zur Abbilung vonPolicies erfüllt, wird im weiteren Verlauf des Kapitels gezeigt, dass es für SAaaS nichtgeeignet ist.30 http://ebiquity.umbc.edu/project/html/id/34/Rei-A-Policy-Specification-Language31 http://sourceforge.net/projects/rei/


4. Evaluation bestehender Sprachen 23Tabelle 4.1.: Rei KriterienKriterium Erfüllt BeschreibungSprachbasis O OWL Lite 32Zuordnung X durch das Attribut targets und / oder den BenutzerVerbindung X Es lassen sich Policies aus mehreren DeonticObjects(Erlaubnis/Verbot/Verpflichtung) erstellenGültigkeitsbereicheXPolicy-Domains”, werden durch Constraints, Gruppierungenvon Objekten, abgebildet. Die einzelne”Zuordnungscheint hingegen schwierigerKonfliktmanagement X basierend auf PrioritätenEs scheint in Rei möglich zu sein, einzelne der in den Anforderungen definierten Policiesumzusetzen, wie beispielsweise die Überwachung einer Datei auf Änderungen(Policy Nr. 2). Durch eine leichte Umformulierung dieser entsteht Aktion Schreiben“”ist verboten. Dieser Policy wird als target die geswünschte Datei zugeordnet. Ob dieDefinition von Audits bzw. das Auditieren von Policies möglich ist, ist unklar. Ebensoist ungewiss, ob und wie die Benutzerrollen Cloud User“ und Cloud Provider“ in Rei” ”abgebildet werden könnten.In Tabelle 4.2 sind die Allgemeinen Kriterien für Rei bewertet.Tabelle 4.2.: Rei Allgemeine KriterienKriteriumBeschreibungAktualitätEntwickelt seit 2001Stand abgeschlossen seit 2005Akzeptanz findet Erwähnung in einigen Papern wie [x, y] allerdings keinepraktische AnwendungFortsetzung nächste Seite. . .32 Die minimal-Version von OWL mit dem kleinsten Funktionsumfang. [17]


24 4. Evaluation bestehender SprachenFortsetzung der Tabelle 4.2 (Rei Allgemeine Kriterien)KriteriumCommunityBeschreibungSourceforge keine Aktivitäten vorhandenDokumentation eine grobe Beschreibung der Klassen ist in der Spezifikation [1]gegebenes gibt einige Paper und PräsentationenBeispiele sind vorhanden [18]KomplexitätSonstigeshoch - durch OWL sehr komplexlange Einarbeitungszeit ohne Vorkenntnisse.komplizierter, stark verschachtelter Aufbau.es werden Implementierungen erwähnt, allerdings kann weder derCode, noch eine auszuführende Version aufgefunden werdenNach erster Einschätzung scheint Rei sehr gut geeignet zu sein, um in verteilten Systemendie Kontrolle von Rechten vorzunehmen, die sich selten Ändern und für großenGültigkeitsbereiche (Policy-Domain) gelten. Ein mögliches Szenario, das gut mit Reiabgebildet werden könnte, wäre die Zugriffskontrolle. Für dieses Szenario scheint Reisehr flexibel und vielseitig zu sein, da es auch die Möglichkeit bietet, Vorbedingungenzu definieren und Konflikte zu lösen. Als Beispiel könnte somit der Zugang einesRaumes für bestimmte Mitarbeiter nur zu bestimmten Zeiten erlaubt werden.4.1.4. AbschlussbetrachtungDie Einarbeitung in Rei hat von allen anderen Sprachen am längsten gedauert, bisein gewisses Grundverständnis vorhanden war. Dies resultierte u.a. daher, dass wederVorkenntnisse in RDF noch RDFS 33 noch in OWL vorhanden waren. Auch wennfür SAaaS eine GUI vorgesehen ist, sollte sich die Komplexität der Sprache in einemgewissen Rahmen befinden. Obwohl Technologien wie OWL scheinbar eine hoheFlexibilität zur Erweiterung mit sich bringen, wurde entschieden, dass OWL-basierteSprachen für SAaaS in der weiteren Bewertung vernachlässigt werden können.33 Resource Description Framework Schema


4. Evaluation bestehender Sprachen 254.2. Common Information Model (CIM)CIM bietet nicht nur die Möglichkeit Policies abzubilden, sondern wurde dazu entwickelt,um unterschiedlichste Informationen abbilden zu können, wozu auch Policiesgehören. Es ist eine seit 1997 von der DMTF 34 entwickelte Spezifikation eines objektorientiertenModells. CIM unterscheidet dabei zwischen der CIM Specification unddem CIM Schema: The CIM Specification is the language and methodology for describingmanagement data. The CIM Schema includes models for Systems, Apllicati-”ons, Networks, Databases and Devices among other management areas”[19].Wie auch in der Analysephase wird zuerst das eigentliche CIM betrachtet und im Folgendenein grundlegender Einblick gegeben. Im Anschluss wird das eigentliche Policy-Modell in Kapitel 4.2.5 erläutert.4.2.1. AufbauAbbildung 4.2.: CIM grobe StrukturübersichtIn Abbildung 4.2 wird die grobe Struktur von CIM dargestellt. Die Spezifikation ist dieGrundlage für alle Schemas. Es definiert das Meta Schema, welches die Struktur und34 Distributed Management Task Force, Inc


26 4. Evaluation bestehender SprachenSyntax der Modelle vorgibt und ähnliche Methodiken definiert, die aus der Objektorientierungund Datenbanken bereits bekannt sind, darunter die Nutzung von Klassen,Vererbung sowie Schlüsselattribute.Die Schemas enthalten Sammlungen von Modellen und sind hierarchisch aufgebaut.Jedes Modell ist eine Sammlung von fertigen Klassen zur Abbildung von Daten, wobeijedes einem spezifischen Anwendungsbereich dient und seine eigenen Bedeutungund eigene Gültigkeitsbereiche definiert, beispielsweise Policies oder Netzwerke. DasExtension Schema ist für die Implementierung in einer Domäne und definiert die fürdie eigentliche Umsetzung technologie-spezifische Klassen.CIM umfasst derzeit über 1400 fertige Klassen inkl. Aggregationen und Assoziationenüber die Schemas verteilt, mit denen sich unterschiedlichste Daten darstellen lassen.4.2.1.1. Managed Object FormatDie Modelle werden in CIM in UML 35 dargestellt und in MOF 37 textuell und maschinenlesbarabgebildet. MOF ist nicht nur ein Format, sondern eine mächtige Sprache zurDefinition und Initialisierung von Klassen, Objekten, Assoziationen, Kardinalitäten,Methoden und vielem mehr. [19]Die Listings 4.3 sowie 4.4 zeigen Beispiele in MOF. Das erste Beispiel ist eine Definitioneiner Klasse ”Zug“ mit einem Attribut ”Nummer“ und zwei Methoden ”Abfahren“und ”Anhalten“. Zeile 2 enthält eine Beschreibung des Attributs ”Nummer“, wobei dasSchlüsselwort ”key“ hier ähnlich dem Schlüssel in Datenbanken ist und der eindeutigenIdentifizierung der Instanzen dient.1 class Zug {Listing 4.3: Beispielhafte Definition einer Klasse ”Zug“ in MOF[2]2 [Key, Description ("Das ist die Nummer des Zuglaufs") ]3 uint16 Nummer;4 uint32 Abfahren();5 uint32 Anhalten();35 UML 36 ist eine Modellierungs Sprache, die oftmals zur Darstellung des Designs von ObjektorientiertenSystemen genutzt wird.37 Managed Object Format


4. Evaluation bestehender Sprachen 276 };Das zweite Beispiel stellt eine Assoziation dar, also eine Verbindung mehrerer Klassen.In diesem Fall enthält sie jeweils eine Referenz zur Klasse Zug und eine zur KlassePlan inklusive deren Kardinalitäten 38 . Die Kardinalitäten sagen aus, dass ein Zug mindestenseinen Fahrplan besitzt.Listing 4.4: Beispielhafte Definition einer Assoziation Zugfahrplan“ in MOF [2]”1 [Association]2 class Zugfahrplan {3 [Key, Max (1), Min (1)]4 Zug REF Zug;5 [Key, Min (1), Weak]6 Fahrplan REF Plan;7 };4.2.2. Umsetzung mit WBEM 39CIM wurde durch WBEM erweitert, welches eine Framework zur Umsetzung von CIMist. Beispielsweise wird definiert, dass die Kommuniktion über HTTP erfolgen sollweiterhin wird CIM um XML zur Darstellung der Klassen und Instanzen erweitert.[2]4.2.3. AufbauDie Abbildung 4.3 zeigt den Aufbau von WBEM mit folgenden Komponenten:• externe Managementanwendung - Erfragt Informationen zu Objekten beimCIMOM 40 . Dies könnte in SAaaS ein Agent sein, der sich Informationen zuPolicies holt, um andere Agenten zu starten.• CIMOM - ist der eigentliche Server. Er nimmt Anfragen entgegen und leitetdiese weiter.38 Kardinalitäten geben .. here be magic citation39 Web-Based Enterprise Management


28 4. Evaluation bestehender SprachenAbbildung 4.3.: WBEM Komponenten [2]• CIM Repository - Enthält die Klasseninformationen und kompiliert die MOF.• CIM Model - Die eigentlichen CIM-Modelle im MOF-Format.• CIM Provider - Pro Klasse gibt es einen Provider, der die Objekte instanziiertund mit der eigentlichen Systemumgebung interagiert, auf Schnittstellen zugreiftund Informationen einholt. Dies könnten u.a. Policies aus einer Datenbank sein.4.2.4. Implementierungen WBEMEs gibt schon einige Implementierungen der Architektur, die von verschiedenen Unternehmenentwickelt wurden. Die meisten sind Open Source und lassen sich für eigeneZwecke verwenden und erweitern. Die Provider Komponenten müssen bei Verwendungselbst geschrieben werden, um die Interaktion mit dem eigentlichen Systemvorzunehmen. Es folgt eine Auswahl an Implementierungen mit einer kurzenEinschätzung aus der Analysephase.• OpenPegasus 41 - nahezu keine Dokumentation gefunden41 http://www.opengroup.org/subjectareas/management/openpegasus


4. Evaluation bestehender Sprachen 29• SNIA 42 - wird nicht mehr weiterentwickelt• WBEM Services 43 - wurde zuletzt 2004 aktualisiert• OpenWBEM 44 - 2006 letzte Aktualisierung, dennoch 36 Downloads im November2012. Letzter Kommentar in der Mailinglist 2010. Sources nicht kompilierbar.4.2.5. Policy-Modell / SchemaIm AnhangA.1 befindet sich das UML des Policy-Modells. Der Aufbau der Policieswürde textuell ”Wenn Bedingung(en) x erfüllt, dann Aktion(en) y ausführen“ lauten.Das Modell besteht aus folgenden, grundlegenden Klassen / Komponenten:• PolicyCondition - Enthält mehrere Unterklassen zur Abbildung von Bedingungenwie Benutzer Authentifizierungsdaten und Netzwerkpaketfilter. Weiterhinlassen sich Zeitperioden erstellen die ermöglichen Aktionen zu gewissen Zeitenauszuführen.• PolicyAction - Eine oder mehrere, wiederverwendbare, Aktionen, die einer odermehrerer PolicyRules zugeordnet werden. Sie werden ausgeführt, wenn die Bedingungender PolicyRule erfüllt sind.• PolicyRule - Die eigentliche Definition der Regel im Format ”wenn x, dann y“.Sie ermöglicht die Ausführung von Aktionen bei Erfüllung einer oder mehrerenBedingungen (PolicyCondition). Hierbei lassen sich die Bedingungen nach beliebenmit UND/ODER verknüpfen durch das Attribut ConditionType 45 . DurchExcecutionStrategy lassen sich Strategien zur Ausführung der Aktionen definieren,wie die Ausführung aller Aktionen oder nur bis eine der Aktionen einenFehler zurückliefert. Negierungen sind möglich. Weiterhin besitzt jede Policy-Rule einen lesbaren Namen und lässt sich aktivieren und deaktivieren.• PolicyGroup - Ermöglicht das Gruppieren von Policies.42 https://collaboration.opengroup.org/snia-cimom/43 http://wbemservices.sourceforge.net/44 http://openwbem.sourceforge.net/45 Konstrukt wurde vereinfacht für CAPL übernommen


30 4. Evaluation bestehender Sprachen• PolicySet - Eine Sammlung mehrerer Policies.• PolicyInSystem - Ist eine Assoziation zu einem System, welches bspw. ein Hostsein kann und ermöglicht so die Zuordnung einer Policy. Das System ist eineKlasse aus dem Core Schema des CIM Modells.4.2.6. BewertungIn der Tabelle 4.3 werden die Kriterien zur Definition von Policies für CIM bewertetund erläutert.Tabelle 4.3.: Policy-Modell CIM KriterienKriterium Erfüllt BeschreibungSprachbasis O Definition in MOF und UML. In Verbindung mitWBEM in XML möglich.Zuordnung X Durch Assoziation PolicyInSystem lässt sich eine Policyeiner Maschine zuordnen.Verbindung X Es lassen sich mehrere Conditions in einer PolicyRuleverbinden, weiterhin lassen sich mehrere Policies ineinem PolicySet aggregieren.Gültigkeitsbereiche O unklarKonfliktmanagement X PrioriätenDas Policy-Modell bringt viele Funktionalitäten zur Abbildung von Policies mit. Eslassen sich auch eigene Bedingungen definieren und sehr komplexe Strukturen vonBedingungen abbilden. Eine Möglichkeit der Nutzung der Aktionen für SAaaS wäredie Implementierung eines Agentenbusses, der alle Agenten enthält, die im Falle einerBedingung benachrichtigt werden, um evtl. selbst Audits auszuführen oder einfach umdem Cloud User Benachrichtigungen zukommen zu lassen.In Tabelle 4.4 sind die Allgemeinen Kriterien für das Policy-Modell von CIM bewertet.


4. Evaluation bestehender Sprachen 31Tabelle 4.4.: Policy-Modell CIM Allgemeine KriterienKriteriumBeschreibungAktualitätEntwickelt CIM 1998, Policy-Modell unklarStand wird gerade aktualisiert (2012)Akzeptanz CIM wird viel eingesetzt bspw.Windows Management Instrumentation 46 ,SBLIM Project 47 ,IBM 48für das Policy-Modell wurde leider keine Umsetzung gefundenCommunity keine für das Policy-Modell oder CIM selbst, allerdings für einzelneImplementierungen.Dokumentation UML-Diagramm[20]Schema Dokumentation[20]Policy Profile [21]Inkonsistenzen vorhanden, da es gerade aktualisiert wurde.Schema Dokumentation und UML-Diagramm geben, trotz UML,zusammen nur ein grobes Bild der FunktionsweiseKomplexitätdurch die Größe des ganzen CIM-Modells und den Inkonsistenzenbei einer tieferen Betrachtung hoch.SonstigesDas Modell scheint sich zum Zeitpunkt der Betrachtung in einem Wandel gefunden zuhaben, da sich mehrere Sachverhalte in der Schema-Dokumentation und dem UML-Diagramm unterschieden haben. Die Schema-Dokumentationen ist ausschließlich eineBeschreibungen der Klassen und Assoziationen in einer alphabetischen Reihenfolgeenthält. Dies ist als Nachschlagewerk sicherlich sehr hilfreich, zur Einarbeitung ist esjedoch nur bedingt geeignet. Es gibt eine richtige Dokumentation [21], die jedoch istseit 2007 nicht aktualisiert worden und somit nicht mehr aktuell ist.46 http://www.microsoft.com/germany/technet/datenbank/articles/600682.mspx47 http://sourceforge.net/apps/mediawiki/sblim/index.php?title=Main Page48 http://publib.boulder.ibm.com/infocenter/eserver/v1r2/index.jsp?topic=%2Fdiricinfo%2Ffqm0 c common info model.htm


32 4. Evaluation bestehender Sprachen4.2.7. AbschlussbetrachtungCIM wurde erst relativ spät entdeckt, als die Analyse schon abgeschlossen war und dieEntwicklung einer eigenen DSL zur Abbildung von Policies bereits begonnen wurde.Aufgrund der hohen Verbreitung des eigentlichen CIM-Modells wurde die Bewertungdennoch durchgeführt.Die Implementierung mit dem WBEM Framework scheint für ein einziges Modellziemlich kompliziert zu sein. Auch die Verwendung einer der o.g. Implementierungenwürde dies wahrscheinlich nur bedingt vereinfachen. Die Verwendung in größeren Anwendungen,oder für Infrastrukturen, die bereits andere CIM Modelle einsetzen wäredies sicher ein interessanter Ansatz.Durch die Größe des Modells, die Inkonsistenzen der Dokumentation, den andereno.g. Gründen und dem fortgeschrittenem Stand der Entwicklung von CAPL wurde dieEntscheidung gegen CIM getroffen. Trotzdem wurden einige Kleinigkeiten wie derConditionType oder einzelne Klassennamen übernommen.4.3. LaSCODiese Sprache wird vorgestellt, da sie einen anderen Weg einschlägt, auch wenn siefür SAaaS von vornherein nicht in Frage kommt.LaSCO folgt einen anderem Weg als die bisher genannten Sprachen und stellt diePolicies durch Graphen dar. We believe this visual form of policy formulation is”convenient, and show the relevant graph operations to policy manipulation.“ [8]. Sieermöglicht die Erstellung für Policies unterschiedlicher Systeme u.a. Programmiersprachenoder Betriebssysteme. Hierfür werden für Objekte erlaubte bzw. verboteneAktionen definiert, wobei Domains die Möglichkeit geben, Gültigkeitsbereiche zu definierenin denen die Policy greift. LaSCO liefert einen Java basierenden Interpreterzur Interpretation der Graphen mit. Ein Beispiel eines Graphen wird in Abbildung 4.4gezeigt. Objekte werden durch Knoten dargestellt und haben verschiedene Attribute,wobei die Art durch type bestimmt wird und bspw. einen User oder eine Datei darstellen.Des Weiteren wird ein Name vergeben und zuletzt die Sicherheitsfreigabe. Die


4. Evaluation bestehender Sprachen 33Kanten dienen der Darstellung von Events bzw. Aktionen. Ob die Aktionen zwischenden Events erlaubt sind, wird an anderer Stelle definiert. [8]Abbildung 4.4.: Beispiel LaSCO [8]4.3.1. AbschlussbetrachtungDa die Dateien für den Interpreter nicht auffindbar waren und eine textuelle Sprachebevorzugt wird, wurde die Analyse von LaSCO eingestellt.4.4. Sonstige SprachenIm Rahmen der Thesis sind noch weitere Policy-Sprachen aufgekommen, die allerdingsnicht tiefer analysiert und vorzeitig ausgeschlossen wurden. Diese Sprachen werdenin der folgenden Liste mit Begründungen für den frühen Ausschluss aufgelistet.• Traffic Flow Sprachen sind zu spezifisch und ermöglichen nur Richtlinien fürden Netzwerkfluss zu erstellen.49 50– PAX PDL49 a non-procedural packet description language50 Spezifikation PAX PDL: http://tools.ietf.org/html/draft-nossik-pax-pdl-00


34 4. Evaluation bestehender Sprachen51 52– PPL• CADF 53 54 - Cloud Standard zur Darstellung und zum Austausch von Eventsund Berichten zwischen verschiedenen Systemen. Keine Abbildung von SecurityPolicies möglich.• WS-Trust• OASIS SAML• KAos - basiert auf OWL. In der Analyse von Rei wurde entschieden, dass dieFlexibilität die durch OWL gewährleistet wird, eine im Verhältnis für die Anforderungenvon SAaaS zu hohe Komplexität mit sich bringt.4.5. ErgebnisDerzeitige Policy-Sprachen sind entweder übermäßig komplex, schlecht Dokumentiertoder nur sehr auf ein Teilproblem fixiert (bspw. Zugangsrichtlinien). Keine der Sprachenkam für die Auditierung mit SAaaS in Frage. Aus diesem Grund wird in Kapitel5 eine eigene DSL entwickelt um die Anforderungen von SAaaS zu erfüllen.51 Packet Processing Language52 Spezifikation PPL:http://www.ipfabrics.com/pdf/packet processing language.pdf53 Cloud Auditing Data Federation54 Spezifikation CADF: http://www.dmtf.org/sites/default/files/standards/documents/DSP0262 1.0.0a 0.pdf


5. Cloud Audit Policy Language (CAPL) 355. Cloud Audit Policy Language (CAPL)Dieses Kapitel beschreibt die Entwicklung von CAPL. Zunächst wird auf den StandardCIMI eingegangen, an dem sich CAPL orientiert. Anschließend wird die Grundstrukturerläutert und auf CAPL im Detail eingegangen, gefolgt von den Möglichkeiten derIntegration in die SAaaS-Architektur.5.1. Cloud Infrastructure Management Interface (CIMI)CIMI wurde von der DMTF entwickelt. This specification describes the model and”protocol for management interactions between a cloud Infrastructure as a Service(IaaS) Provider and the Consumers of an IaaS service.”[22]. CIMI wird in zwei Dokumentenbeschrieben: die Spezifikation[22] sowie dem Primer[3], welcher die Spezifkiationum Beispiele erweitert. CIMI enthält ein Modell inklusive Protokoll, um verschiedeneObjekte einer Infrastruktur darzustellen und definiert mögliche Aktionen.So ist es beispielsweise möglich, Maschinen in der Cloud zu verwalten. Dazu gehörenauch Funktionen wie das Starten und Stoppen dieser sowie das Verteilen der Zugriffsberechtigungen.Weiterhin besteht die Möglichkeit Metriken zur Überwachung bestimmterAspekte“ zu definieren, darunter CPU und Bandbreite. Über diese Metriken”hinaus bietet CIMI keine Möglichkeit zur Abbildung einer Policy.Die Identifizierung von Objekten oder Aktionen erfolgt über URIs 55 .Adressierung durch URIURIs dienen der eindeutigen und zeichenbasierten Identifizierung von Ressourcen. Siewerden in RFC3986 [23] definiert.In CIMI identifizieren sie Aktionen und Objekte. Eine mögliche URI für eine Maschinein CIMI mit der ID 1 wäre: http://example.org/cimi/machines/1.55 Uniform Resource Identifiers


36 5. Cloud Audit Policy Language (CAPL)5.1.1. Restful ServiceCIMI definiert ein Protokoll, welches auf REST 56 basiert. REST ist ein Architekturstil,der die Realisierung von Web Services ermöglicht [24]. Es besteht die Möglichkeit,über HTTP-Methoden Daten abzufragen oder zu verwalten.Zuordnung der HTTP-Methoden zu den Funktionen in CIMI:• GET - Abfragen von Ressourcen• POST - Erstellung von Ressourcen oder Ausführen von Aktionen• PUT - Bearbeitung von Ressourcen• DELETE -Löschen von RessourcenEs gibt die Möglichkeit, die Objekte in XML oder JSON darzustellen und zu serialisieren.Über die MIME-Typen application/xml und application/json wird dasFormat der Nutzdaten der Anfrage bzw. der Antwort des Servers identifiziert.Anhand der HTTP-Status Codes teilt der Server dem Client mit, ob die Aktion erfolgreichwar oder welche Fehler aufgetreten sind. Es folgt eine Auswahl relevanterHTTP-Codes basierend auf RFC2616 [25]:200 - OK - Die Anfrage wurde erfolgreich ausgeführt und die angefragten Informationenzurückgegeben.201 - Created - Die Anfrage wurde ausgeführt und es wurde eine neue Ressourceerstellt und die zugehörige URI zurückgegeben.202 - Accepted - Die Anfrage wurde akzeptiert, ist allerdings noch nicht vollständigausgeführt. Ein möglicher Grund kann sein, dass die Verarbeitung mehr Zeit in Anspruchnimmt. CIMI nutzt diesen Status Code u.a. für Aufgaben wie das Erstellenvon VMs.204 - No Content - Die Anfrage wurde erfolgreich ausgeführt. Es gibt keine Informationendie zurückgegeben werden müssen. Beispielsweise bei einer DELETEAnfrage.400 - Bad Request - Die Anfrage konnte vom Server nicht verstanden werden. Dieskann verschiedene Gründe haben.56 Represential State Transfer


5. Cloud Audit Policy Language (CAPL) 37404 - Not found - Die angefragte URI kann nicht gefunden werden oder wird ausanderen Gründen zurückgewiesen, welche i.d.R. nicht mit angegeben werden.405 - Method not allowed - Die Aktion ist nicht erlaubt für diese URI. Muss dieerlaubten Aktionen enthalten.415 - Unsupported Media Type - Der angegebene Media Type wird nicht unterstützt.500 - Internal Server Error - Es ist ein interner Fehler aufgetreten.501 - Not implemented - Die angefragte Funktion ist nicht implementiert.Das Beispiel in Listing 5.1 erläutert die Erstellung einer Machine nach CIMI. Dabeizeigen Zeile 1 und 2 die Client Anfrage des Users und Zeile 14 und 15 die Antwortdes Servers.Zeile 4-12 sind die Nutzdaten der Anfrage, welche die Daten der neu zu erstellendenRessource enthält. Durch application/json gibt der Client an, dass die Nutzdaten inJSON zu interpretieren sind. Sollte beispielsweise JSON vom Server nicht unterstütztwerden, würde er den Status Code 415 zurückgeben. Im Beispiel läuft alles reibungslosund der Server antwortet in Zeile 14-15 mit dem Code 201 und gibt an, dass dieRessource erstellt wurde und nun mittels der URI http://example.de/machines/843752referenzierbar ist.Listing 5.1: CIMI Beispiel Erstellung einer Ressource mittels POST [3]1 POST /machines HTTP/1.12 Content-Type: application/json4 { "resourceURI": "http://schemas.dmtf.org/cimi/1/MachineCreate",5 "name": "myMachine1",6 "description": "My very first machine",7 "machineTemplate": {8 "machineConfig": { "href": " http://example.com/configs/tiny"},9 "machineImage": { "href": "http://example.com/images/WinXP-SP2" },10 "credential": { "href": "http://example.com/creds/12345" }11 }


38 5. Cloud Audit Policy Language (CAPL)12 }14 HTTP/1.1 201 Created15 Location: http://example.com/machines/843752Das Beispiel in Listing 5.2 stellt eine weitere Anfrage an den Server dar, um die ebenerstellten Daten der Machine abzufragen und ggf. zu überprüfen.Listing 5.2: CIMI Beispiel GET-Abfrage [3]1 GET /machines/843752 HTTP/1.13 HTTP/1.1 200 OK4 Content-Type: application/json6 { "resourceURI": "http://schemas.dmtf.org/cimi/1/Machine",7 "id": "http://example.com/machines/843752",8 "name": "myMachine1",9 "description": "My very first machine",10 "created": "2012-08-15T12:15:00Z",11 "updated": "2012-08-15T12:15:00Z",12 "state": "STOPPED",13 "cpu": 1,14 "memory": 4000000,15 "disks" : { "href": "http://example.com/machines/843752/disks",16 "networkInterfaces": { "href":"http://example.com/machines/843752/NIs",17 "operations": [18 { "rel": "edit", "href": "http://example.com/machines/843752"},19 { "rel": "delete", "href":"http://example.com/machines/843752" },20 { "rel": "http://schemas.dmtf.org/cimi/1/action/start",21 "href": "http://example.com/machines/843752" }22 ]23 }


5. Cloud Audit Policy Language (CAPL) 395.1.2. Möglichkeit der FilterungBei der Abfrage von Objekten besteht die Möglichkeit, nach Objekten zu suchen oderdie Anzeige auf unterschiedlichste Art einzuschränken bzw. zu erweitern. Zwei Beispieleaus der CIMI-Definition [22].• GET http://example.org/machines?$filter=name=’mine’ HTTP/1.1-Gibt alle Maschinen, die ’mine’ im Namen enthalten.• GET http://example.org/machineImages?$last=2 HTTP/1.1 - Gibt nurdie letzten beiden Maschinen aus.• GET http://example.org/machineImages?$expand HTTP/1.1 - Gibt auchdie Daten der Objekte wieder, die als Attribut in dem angefragten Objekt enthaltensind. Normalerweise wird lediglich die Referenz als URI ausgegeben.5.2. Adaption von CIMIDie neue Policy-Audit Sprache braucht einen grundlegenden Aufbau der Objekte, einProtokoll und die Möglichkeit zur Abbildung von VMs, um diesen Policies zuzuordnen.Dies sind Gesichtspunkte, welche CIMI mitbringt und an denen sich die neueSprache orientieren kann.Die entwickelte Sprache orientiert sich in diesen Punkten an CIMI und wurde an dieAnforderungen von SAaaS angepasst. CAPL erbt von CIMI u.a. den grundlegendenAufbau der Objekte und des Protokolls sowie eine vereinfachte Form der Klassen zurVerwaltung der Maschinen (Machine, MachineTemplate, MachineConfigurationund MachineImage).Der Fokus von CIMI ist ein ganz anderer als der von CAPL. Er liegt in der Verwaltungvon Cloud-Infrastrukturen, sprich dem Starten und Stoppen von VMs, die Verteilungvon Zugriffsdaten und das Abbilden von Netzwerken. Es gibt keine Möglichkeit zurAbbildung einer Policy. Somit wurden gewisse Klassen nicht übernommen, bestehendefür die Policies und das SAaaS-Szenario angepasst und weitere entsprechende Klassenentworfen und angefügt.


40 5. Cloud Audit Policy Language (CAPL)Die weiteren Klassen von CIMI, z.B. die Credentials zur Verteilung von Zugangsdatenoder zum Abbilden eines Netzwerkes, werden für das SAaaS-Szenario nicht benötigt,da es bereits andere Instanzen für die Abwicklung gibt und somit kein Bedarf besteht,diese über die neue Sprache abzubilden. Einige Dinge wurden von CIMI für CAPLadaptiert und für die Anforderungen von SAaaS angepasst. CAPL erbt u.a. den grundlegendenAufbau der Objekte, Grundzüge des Protokolls sowie die Klassen zur Verwaltungvon Maschinen. Es wird nicht auf alle Gründe der Änderungen eingegangen,da CAPL sich nur an CIMI orientiert und es nicht vollständig übernimmt. Ein Beispielfür eine Anpassung sind die Snapshots der Maschinen. Die VMs der Cloud Umgebungvon SAaaS besitzen keine unterschiedlichen Snapshots und es ist auch nicht notwendig,die VMs durch CAPL zu verwalten. Die Verwaltung wird bereits durch ein anderesSystem abgedeckt, wodurch die Funktionalität zum Starten und Stoppen der VM nichtbenötigt wird.5.3. Benutzerrollen in CAPLÄhnlich wie CIMI gibt es die Benutzergruppen Cloud Provider und Cloud Consumer,allerdings wird unter CAPL eine vereinfachte Version der Definition verwendet. DerCloud Provider verwaltet und stellt den Service bzw. die Cloud dem Kunden bereit, erbesitzt grundsätzlich die vollen Rechte im System.Der Cloud Consumer wird als Benutzer der Cloud bzw. des Dienstes zur Auditierungseiner VMs defineirt. Er hat nur die minimalen Rechte, welche nötig sind, um vorgegebenePolicies für seine VMs zu erstellen und auszuführen.5.4. Sprachbasis von CAPLBei der Wahl der Darstellung der Daten wurde sich an CIMI orientiert, das dieweit verbreiteten Technologien JSON oder XML anbietet. Thomas Bayer [26] nenntJSON eine gute Alternative zu XML, welches besonders durch seine Schlankheit undÜbersichtlichkeit auffällt. XML punktet nach wie vor durch seine Vielseitigkeit, Toolunterstützungsowie durch die Vielzahl der Standards, die auf XML aufbauen oder mit”XML kombinierbar sind“. Ein weiterer Vorteil von XML ist die Verfügbarkeit von


5. Cloud Audit Policy Language (CAPL) 41Schema-Sprachen, welche u.a. zur Validierung der Daten verwendet werden können.Die Validierung mit dem Schema vereinfacht die Überprüfung der eingehenden Daten,wodurch beispielsweise festgestellt werden kann, ob ein eingehendes Objekt alleerforderlichen Attribute im erwarteten XML enthält. Auch für JSON gibt es seit2009 ein von der IETF 57 entwickeltes und von JSON Tools 58 für Java implementiertesJSON-Schema 59 , wodurch die Validierung ermöglicht werden würde. Aus Gründender Einheitlichkeit sollte die Darstellung der Sprache und die des Schemas identischsein. Aufgrund der längeren Existenz und weiten Verbreitung wurde XML für CAPLbevorzugt. Grundsätzlich ist es möglich, CAPL auch mit JSON zu betreiben und umzusetzen.Alle Beispiele für CAPL werden allerdings in XML dargestellt.5.5. Sprachdefinition CAPLCAPL basiert auf einer Art Objekt/Klassen Modell. Eine Übersicht der Klassen bietetAbbildung 5.1. Es gibt die Klasse Machine, welche die VMs und Hosts der Cloud darstelltund denen Policies zugeordnet werden können. Weiterhin ist es möglich, VMs inGruppen zusammenzufassen und dieser Gruppe Policies zuzuweisen. Policies könneneinzelne Regeln MetricRule oder PolicyRule sein oder aus zusammengesetzten RegelnPolicySet bestehen. Im Folgenden wird Policies“ als Synonym für die drei”Klassen genutzt: PolicyRule, PolicySet und MetricRule.5.5.1. NamespaceCAPL wurde ein eigener Namespace unter http://research.cloud.hsfurtwangen.de/capl/zugeordnet. Dieser ermöglicht die eindeutige Identifizierungder Klassen und verhindert Konflikte bei der Verwendung von unterschiedlichen Schemas.Jeder Klasse wird im folgenden unter resourceURI ihre URI des Namespaceszugeordnet.57 Internet Engineering Task Force58 http://jsontools.berlios.de/59 http://tools.ietf.org/html/draft-zyp-json-schema-03


Abbildung 5.1.: Aufbau der Klassen CAPL42 5. Cloud Audit Policy Language (CAPL)


5. Cloud Audit Policy Language (CAPL) 435.5.2. DatentypenEs gibt verschiedene Datentypen, die in CAPL verwendet werden. Einige sind bereitsaus diversen Programmiersprachen bekannt. Eine Auflistung der Datentypen ist in Tabelle5.1 zu finden.Tabelle 5.1.: Genutzte DatentypenDatentyp Bezeichnung Erläuterunginteger Ganzzahl Eine Zahl ohne Kommastellen.string Text Eine Zeichenkette, welche mehrere Buchstaben, Nummernund Sonderzeichen enthalten kann.date Datum Steht für einen Timestamp. Ein Datum mit Uhrzeit imFormat: .uri URI Enthält eine URI.ref Referenz Einen Verweis auf ein anderes Objekt durch eine URI.Wird im Objekt durch href= uri“ als ein XML Element”dargestellt.mapSchlüssel/Wert Eine Liste von selbst zu definierenden Attributen mit derPaare Möglichkeit die Schlüsselnamen und Werte zu bestimmen.Jede Liste sollte jeden Schlüssel nur ein mal enthalten.Datentyp[] Array Eine Liste von mehreren Daten eines Datentyps. Beispielref[].enabled Aktiviert Dieser Datentyp wird verwendet, um den Status derNutzbarkeit anzugeben. Mögliche Werte sind:• active - Es ist aktiv und nutzbar.• inactive - Es ist nicht aktiv und somit nicht nutzbar.• debug - Es ist ausschließlich für den Cloud Provideraktiv und sichtbar.Fortsetzung nächste Seite. . .


44 5. Cloud Audit Policy Language (CAPL)Fortsetzung der Tabelle 5.1 (Genutzte Datentypen)Datentyp Bezeichnung ErläuterungintervalTypeEinheitIntervallGibt die Einheit eines Intervalls an. Mögliche Wertesind:• no - Kein Intervall, einmalige Ausführung.• minutes - Angabe in Minuten.• hours - Angabe in Stunden.• days - Angabe in Tagen.• weeks - Angabe in Wochen.conditionType Verknüpfung Gibt die Art der Verknüpfung mehrerer Regeln an. Derzeitkann dies entweder den Wert ”D“ für eine Disjunktionoder ”C“ für eine Konjunktion annehmen.5.5.3. GrundgerüstBis auf wenige Ausnahmen hat jede Klasse ein Grundgerüst an Attributen. Diese Attributehaben die selbe Bedeutung für jede dieser Klassen und werden deshalb nichtfür jede Klasse gesondert erläutert. Eine Definition des Grundgerüsts ist in Tabelle 5.2zu finden.5.5.4. Cloud Entry PointIst über die BaseURI der Schnittstelle erreichbar. Dies könnte bspw. http://example.org/capl/ sein. Eine GET-Anfrage an diesem Punkt resultiert in der Ausgabealler verfügbaren Klassen und deren zugeordneten URIs über die der Client dieObjekte erreichen kann. Der CEP 60 besitzt nicht das Grundgerüst aus Kapitel 5.5.3 wiedie anderen Klassen.60 Cloud Entry Point


5. Cloud Audit Policy Language (CAPL) 45Tabelle 5.2.: Aufbau GrundgerüstAttributname Datentyp BeschreibungresourceURI uri Gibt für jede Klasse die URI zum Namespace an.id ref Enthält die ID des Objektes als URI.name string Gibt dem Objekt einen Namen.refName string Ein kurzer Name aus reinen Buchstaben, ohne Leerzeichen,zur möglichen Referenzierung.description string Ermöglicht das Anfügen einer Beschreibung.created date Wird automatisch auf die aktuelle Zeit gesetzt, wenndas Objekt erstellt wird.updated date Wird automatisch auf die aktuelle Zeit gesetzt, wenndas Objekt bearbeitet wird.Tabelle 5.3.: Aufbau Cloud Entry PointAttributname Datentyp Erläuterung mit BeispielresourceURI uri http://research.cloud.hs-furtwangen.de/capl/CEPid string ID des Cloud Entry Points. http://example.org/cepbaseURI uri Enthält die URI der Basis. http://example.org/machines ref Enthält eine Referenz auf die Liste der Objekte vonMachine. http://example.org/machinesmachineConfigurations ref Enthält eine Referenz auf die Liste derObjekte von Machine Configurationhttp://example.org/machineConfigurationsMachineTemplate ref Enthält eine Referenz auf die Listeder Objekte von MachineTemplate.http://example.org/MachineTemplatesmachineImage ref Enthält eine Referenz auf die Listeder Objekte von MachineImage.http://example.org/machineImagesFortsetzung nächste Seite. . .


46 5. Cloud Audit Policy Language (CAPL)Fortsetzung der Tabelle 5.3 (Aufbau Cloud Entry Point)Attributname Datentyp Erläuterung mit Beispielgroups ref Enthält eine Referenz auf die Liste der Objekte vonGroups. http://example.org/groupspolicies ref Enthält eine Referenz auf die Liste der Objekte vonPolicy. http://example.org/policiespolicySets ref Enthält eine Referenz auf die Liste der Objekte vonPolicySet. http://example.org/policySetspolicyRules ref Enthält eine Referenz auf die Liste der Objekte vonPolicyRule. http://example.org/policyRulesmetricRules ref Enthält eine Referenz auf die Liste der Objekte vonmetricRule. http://example.org/metricRulesruleTypes ref Enthält eine Referenz auf die Liste der Objekte vonRuleType. http://example.org/ruleTypes5.5.5. MachineEine Machine repräsentiert eine zu auditierende Maschine des Cloud Consumer oderdes Cloud Provider in der Cloud. In CIMI werden durch Machines nur VMs dargestellt,allerdings sollte dem CloudProvider auch möglich sein, die entsprechenden Hosts zuauditieren und somit wird der Begriff Maschine im Folgenden synonym zu VMs undHosts verwendet. Im Falle der Darstellung eines Hosts werden die VM spezifischen Attributewie MachineImage leer gelassen. Der Machine können im späteren Verlauf Policieszur Auditierung zugeordnet werden. Des Weiteren besteht die Möglichkeit, Maschinenmittels der Klasse Group zu gruppieren. Eine Definition der Klasse Machineist in Tabelle 5.4 zu finden.Tabelle 5.4.: MachineAttributname Datentyp ErläuterungresourceURI uri http://research.cloud.hs-furtwangen.de/capl/MachineFortsetzung nächste Seite. . .


5. Cloud Audit Policy Language (CAPL) 47Fortsetzung der Tabelle 5.4 (Machine)Attributname Datentyp Erläuterungpu integer Gibt die Anzahl der CPUs an.cpuArch string Gibt die Architektur der CPU an.memory integer Ermöglicht die Angabe der Größe des Arbeitsspeichers.machineImage ref Ein Verweis auf ein MachineImage, auf welchem die Maschinebasiert.ip string Gibt die IP der Maschine an.policies ref Eine Liste von Verweisen auf Policies, welchen der Benutzerfür die Maschine erstellt hat.groups ref Eine Liste von Verweisen auf die Gruppen, welche dieMaschine zugehörig ist.5.5.6. MachineTemplateDas MachineTemplate ermöglicht das Erstellen einer Instanz der Klasse Machine.Es ist eine Art Vorlage für die neue Maschine. Die Attribute eines MachineTemplatewerden in die zu erstellende Maschine kopiert. Für das MachineImage wird lediglichein Verweis auf das entsprechende Image erstellt. Hier hängt es von der Implementierungund der Infrastruktur ab, ob auf das selbe Image verwiesen wird oder dieseskopiert und auf das neue verwiesen wird. Für SAaaS bleibt das Image statisch und eswird lediglich ein Verweis erstellt. Eine Definition der Klasse MachineTemplate istin Tabelle 5.5 zu finden.5.5.7. MachineImageDas MachineImage repräsentiert eines der Images, das auf den Maschinen gestartetwird. Sie haben ein bestimmtes Betriebssystem als Basis und ggf. vorinstallierte Software.Eine Definition der Klasse MachineImage ist in Tabelle 5.6 zu finden.


48 5. Cloud Audit Policy Language (CAPL)Tabelle 5.5.: Aufbau MachineTemplateAttributname Datentyp BeschreibungresourceURI uri http://research.cloud.hsfurtwangen.de/capl/MachineTemplatemachineImage ref Ein Verweis auf ein MachineImage, welchesfür die zu erstellende Maschine übernommenwird.machineConfiguration uri Ein Verweis auf eine MachineConfiguration. Die Daten der MachineConfiguration werden in die neue Maschinekopiert.groups ref[] Eine Liste von Verweisen auf Gruppen. DieMaschinen des Templates werden automatischdiesen Gruppen angefügt.policies ref[] Eine Liste von Policies. Diese werden automatischbei Erstellung der VM für diese dubliziertund angefügt. Somit lassen sich Policiesfür neu zu erstellende VMs definieren.5.5.8. MachineConfigurationDie MachineConfiguration enthält die physikalischen Eigenschaften wie cpuund memory für eine zu erstellende Maschine. Eine Definition der KlasseMachineConfiguration ist in Tabelle 5.7 zu finden.5.5.9. PolicyRegelnEine PolicyRegel kann wie eine Policy verwendet werden und einer Maschine odereiner Gruppe zugeordnet werden. Sie entspricht einer einzigen Richtlinie bzw. Regel.Grundsätzlich gibt es zwei unterschiedlichen Regeln: MetricRule und PolicyRule.Jede Regel bekommt einen RuleType zugeordnet, der definiert um welche Art vonPolicy es sich handelt.


5. Cloud Audit Policy Language (CAPL) 49Tabelle 5.6.: Aufbau MachineImageAttributname Datentyp BeschreibungresourceURI uri http://research.cloud.hsfurtwangen.de/capl/MachineImageos string Enthält als String das zugrunde liegende Betriebssystem.imageLocation string Ermöglicht die Angabe des Ortes des Images.Tabelle 5.7.: Aufbau MachineConfigurationAttributname Datentyp BeschreibungresourceURI uri http://research.cloud.hsfurtwangen.de/capl/MachineConfigurationcpu integer Gibt die Anzahl der CPU’s an.cpuArch string Gibt die Architektur der CPU an.memory integer Ermöglicht die Angabe der Größe des Arbeitsspeichers.5.5.9.1. MetricRuleMetriken werden durch die Klasse MetricRule dargestellt und definieren eine obereund untere Grenze für einen zu überwachenden Wert. Solange diese nicht überbzw.unterschritten werden, ist die Regel erfüllt. Eine mögliche MetrikRule würdelauten ”Die Anzahl der fehlgeschlagenen Anmeldeversuche eines Users darf 3 nichtüberschreiten.“ Alle anderen Policies werden mit PolicyRule erstellt. Eine Definitionder Klasse MetricRule ist in Tabelle 5.8 zu finden.Tabelle 5.8.: Aufbau MetricRuleAttributname Datentyp ErläuterungresourceURI uri http://research.cloud.hsfurtwangen.de/capl/MetricRuleFortsetzung nächste Seite. . .


50 5. Cloud Audit Policy Language (CAPL)Fortsetzung der Tabelle 5.8 (Aufbau MetricRule)Attributname Datentyp Erläuterungenabled enabled Gibt an, ob die Policy aktiv ist und ausgelöstwerden kann, oder nicht.ruleType ref Gibt den Typ der Metrik an. Bspw. CPU, TemperaturdeploymentRessource ref Dieses Attribut wird nur benötigt, wenn einePolicy von einer anderen VM ausgeführt werdensoll. Beispielsweise bei der Überprüfung einesPorts macht dies Sinn, da je nach Netzwerkschnittstelleandere Ports offen sein dürfen.targetRessoure ref Kann eine Maschine, eine Gruppe oder ein MachineTemplate/ Image seinminValue integer Gibt die untere Grenze für die Metrik an. Wirddiese unterschritten ist die Policy nicht mehrerfüllt.maxValue integer Gibt die obere Grenze für die Metrik an. Wirddiese überschritten, ist die Policy nicht mehrerfüllt.intervalType intervalType Gibt den Typ bzw. die Einheit derAusführungszeit an. Siehe Tabelle 5.1interval integer Die Zahl definiert für die intervalTypes, dienicht no“ sind, den zur Einheit gehörigen Intervall.”5.5.9.2. PolicyRulePolicyRule wird zur Darstellung aller Regeln verwendet, die keine Metrik darstellen.Diese Regel hat einen grundlegenden Aufbau, der für alle Regeln gleich ist und inTabelle 5.9 erläutert wird. Eine mögliche Policy könnte lauten Die VM ist frei von”Viren“.


5. Cloud Audit Policy Language (CAPL) 51Durch das Attribut properties wird ermöglicht, kontextbasierte Eigenschaften zu definieren.Der Kontext wird durch den RuleType der Regel vorgegeben. Mehr dazuin Kapitel 5.5.12. Anhand der Beispiel in Listing 5.3 wird der Zweck dieser Eigenschaftendeutlich. Das Beispiel zeigt eine Regel, welche die Veränderung der Dateihttpd.conf verbietet. Zeile 2-10 sind Attribute, die jede PolicyRule besitzt, wohingegenZeile 11-15 die kontextbasierten Attribute enthält, die durch den RuleType inotify,in Zeile 8, vorgegeben werden. Die Policy ist durch enabled aktiv, und der VM mit demNamen www1 zugeordnet. Die kontextbasierten Werte beschreiben, dass nicht erlaubt(permission in Zeile 12) ist, die in Zeile 14 durch path angegebene Datei zu Bearbeiten(action in Zeile 13).Listing 5.3: Beispiel Policy Config Freeze httpd.conf1 2 Freeze httpd.conf3 freezehttpd4 httpd.conf ist final und darf nicht bearbeitetwerden.5 04.02.20136 04.02.20137 true8 inotify9 10 no11 12 denied13 change14 /etc/apache2/httpd.conf15 16 5.5.10. PolicySetDas PolicySet ist eine Policy, welche aus mehreren Regeln (MetricRule oder Policy-Rule) besteht. Sie ist erst erfüllt, wenn die Bedingungen der Regeln erfüllt sind. Ein


52 5. Cloud Audit Policy Language (CAPL)PolicySet kann wie eine Regel verwendet werden und einer Maschine oder Gruppezugeordnet werden.Über das Attribut ConditionType kann definiert werden, wie die Regeln verbundenwerden. Es gibt die Möglichkeit der Disjunktion (D) und Konjunktion (C).Bei der Konjunktion müssen alle Regel erfüllt sein, damit das PolicySet erfüllt ist.Dies entspricht einer UND“-Verknüpfung, während die Disjunktion eine ODER“-” ”Verknüpfung darstellt und es reicht, dass eine der angegebenen Regeln erfüllt ist. DiesesVorgehen wurde vom Policy-Modell von CIM adaptiert [27]. Das Modell gehtallerdings weiter und ermöglicht das Erstellen von Aussageblöcken, welche wiederumverknüpft werden können. Somit wäre es möglich, die Aussage (A und B) oder (C”und D)“ darzustellen. Für das Szenario des SAaaS reicht die einfache Verknüpfung.Eine Definition der Klasse PolicySet ist in Tabelle 5.10 zu finden.5.5.11. GroupWie gruppiert wird, ist dem User bzw. Cloud Provider überlassen. Die Groupermöglicht die Gruppierung von Policies und Instanzen der Machine. Alle Policiesgelten für alle Maschinen der Gruppe. Standardmäßig gelten die Einstellungen von intervalund intervalType der jeweiligen Policy, sofern diese definiert wurden. Die Einstellungender Gruppe gelten nur bei Policies, die keine eigenen definieren, oder dieGruppe in besonderen Fällen die Überschreibung der Werte mit overwriteInterval=trueerzwingt. Eine Definition der Klasse Group ist in Tabelle 5.11 zu finden.5.5.12. RuleTypeDer RuleType ist die Art einer Regel. Jede Regel, die erstellt wird, bekommt einen Typzugeordnet, der definiert, um was für eine Regel es sich handelt. Die RuleTypes werdenvom Cloud Provider, direkt über die Schnittstelle, verwaltet und die Klasse wurdemöglichst flexibel entworfen, um verschiedenste Regeln erstellen zu können, ohne dieSprache anpassen zu müssen. Da verschiedenste Regeln auch verschiedenste Eigenschaftenmit sich bringen und nicht jede Regel die selben davon benötigt, werden die


5. Cloud Audit Policy Language (CAPL) 53regelspezifischen Eigenschaften durch das Attribut properties“ definiert. Die definiertenEigenschaften müssen bei der Erstellung einer Policy mit angegeben werden. Sie”werden im weiteren Verlauf kontextbasierte“ Eigenschaften genannt.”Damit der User erfahren kann, welche RuleTypes es gibt, kann er die für ihn relevantenAttribute durch eine GET Abfrage in Erfahrung bringen.Eine Definition der Klasse RuleType ist in Tabelle 5.12 zu finden. Für SAaaS wurdenbereits folgende RuleTypes für die definierten Szenarien aus Kapitel 3.1 definiert.Tabelle 5.12.: Aufbau RuleTypeAttributname Datentyp ErläuterungresourceURI uri http://research.cloud.hs-furtwangen.de/capl/RuleTypecategory ref Ermöglicht die Kategorisierung von den Typen und somitdas einfachere Finden von bestimmten Typen.visibility integer Dient der Einschränkung der Nutzungsrechte. So kannsich der Cloud Provider Typen vorbehalten, welche nichtfür den Benutzer bestimmt sind oder sich noch in Entwicklungbefinden. Die Einschränkung erfolgt anhandvon Zahlen und wurde von der Rechtevergabe bei Unix-Systemen adaptiert.isLocal boolean Lokale Policies werden lokal und nicht von einem externenTestserver überprüft. Mögliche Beispiele wären füreine lokale die Auslastung der CPU und für eine nicht lokaledie Möglichkeit der Verbindung zu einem Protokoll.isMetric boolean Definiert, ob dieser Typ eine Metrik darstellt oder nicht.properties string [key][description] kontextbasierte Werte als Matrix.Einzelne PolicyEs kann durchaus sinnvoll sein, nur eine Policy auszuführen.


54 5. Cloud Audit Policy Language (CAPL)5.6. Technische Integration in SAaaS5.6.1. Verwaltung der VMsDie entwickelte Audit-Sprache wird sich nahtlos in die vorhandenen Komponenten derStudi-Cloud integrieren. Hierzu wird ein grafischer Policy-Modeller in die Weboberflächeintegriert. Nachdem VMs über die WebManagementoberfläche (GecMiGUI) erstelltwurden, werden die VM-Eigenschaften an CAPL-Server übergeben. Somit kannder Benutzer Policies für diese VM erstellen.5.6.2. Verwaltung der Policies und Ausrollen der AgentenEs gibt zwei Möglichkeiten, die Policies in SAaaS mit CAPL zu verwalten und dieAudits auszulösen, um anschließend die Agenten zu erstellen. In beiden Szenarienwerden zuerst die Policies erstellt und die Ausführung separat ausgelöst. Die Agentenwerden erst an die VMs verteilt, wenn ein Audit ausgelöst wird. Dies kann durch einenanderen Agenten, einen Benutzer oder eine andere Instanz geschehen.Die Grafik 5.2 zeigt den Ablauf der Erstellung der Policies für beide Szenarien. DesWeiteren wird das Ausrollen der Agenten, welche die Audits durchführen für dieSelbstverwaltung dargestellt, welche in Kapitel ?? näher beschrieben wird.Erstellung der Policies Die Erstellung der Policies erfolgt in beiden Szenariendurch den CAPL-Server. Die Schritte sind in der Grafik 5.2 in Blau dargestellt.Der User erstellt die Policies über den Policy Modeller oder direkt über die vonCAPL-Serverbereitgestellte REST-Schnittstelle. Der Policy-Modeller nutzt ebenfallsdie REST-Schnittstelle und erstellt die Policies mit der POST-Methode. Der Serverserialisiert die Daten und speichert diese in der Datenbank.5.6.3. Selbstverwaltung der Policies durch CAPLSelbstverwaltung bedeutet, dass CAPL als einzige Instanz für die Verwaltung der Policieszuständig ist und sich somit zusätzlich zum Abfragen, Erstellen und Löschen


5. Cloud Audit Policy Language (CAPL) 55Abbildung 5.2.: Mögliche Integration - Selbstverwaltungvon Objekten auch um die Ausführung der Policies kümmert. Das hat den Vorteil, dassdie Funktionen zentralisiert sind und nur eine Instanz für die Policies verantwortlichist. Da dieses Szenario das Management der Policies zentral hält und keine anderenInstanzenAusführung eines AuditsIn der Grafik 5.2 in grün dargestellt löst der User in Schritt1 selbst das Audit über den Policy-Modeller aus. Die GUI 61 ruft über die REST-Schnittstelle die run() 62 -Methode auf, welche die entsprechenden URIs der jeweiligenPolicies enthält. In diesem Szenario ist es nur eine Policy zur Überprüfung der Virenfreiheit.In Schritt 3 holt sich der Server anhand der URI die entsprechende Policyinklusive Konfiguration aus der Datenbank und überprüft, welcher Agent für diese Policyzuständig ist. Im Anschluss gibt er diese Daten an das Agent Management weiter,welches im Schritt 5 einen Audit-Agenten erstellt und auf die entsprechende Maschine61 Graphical User Interface62 Sollte in der Implementierung die Entscheidung auf die Selbstverwaltung fallen, muss diese Methodenoch den Klassen Group und Machine angefügt werden.


56 5. Cloud Audit Policy Language (CAPL)verteilt. Der Agent startet nun in Schritt 7 die Systemüberprüfung z.B. Ausführung vonClamAV und wertet die Rückgabe aus.5.6.4. Verwaltung der Policies durch andere InstanzenEine weitere Möglichkeit der Verwaltung wäre durch andere Instanzen. Der CAPL-Server würde lediglich die Daten der Policies verwalten und wäre nicht für dieAusführung verantwortlich. Die Ausführung würde durch andere Instanzen ausgelöstwie beispielsweise der GecMiGUI, welche die Policies am CAPL-Server anfrag,t dieDaten selbst verarbeitet und an das Agenten Management weiterreicht. Die Schritte5-7 aus Abbildung 5.2 wären die selben. Dies hätte den Nachteil, dass eine weitere InstanzPolicies oder die Konfigurationen interpretieren können müsste, bzw. in der Lagesein muss, die Policies bei CAPL-Server anzufragen und somit die Antwort verstehenkönnen muss.5.6.5. Erstellung und Verteilung der AgentenDer User konfiguriert die Maschinen und Policies. Wenn er eine Gruppe oder einePolicy ausführt, werden die Agenten erstellt und verteilt, solange die Policy mitenabled:true als aktiviert markiert ist. Andernfalls wird diese ignoriert.5.7. Entwicklung des PrototypenDer Prototyp veranschaulicht beispielhaft die Umsetzung von CAPL sowie die Verwendungder Schnittstelle. Der Code ist auf der beigelegten CD-ROM zu finden.5.7.1. Umgebung und verwendete TechnologienFür den Prototypen werden die Technologien verwendet, die bereits in der SAaaS-Umgebung Anwendung finden. Der Server wird in Java geschrieben und durch einenTomcat in Verbindung mit einem Apache-Server bereitgestellt. Als Datenbank wirdeine MySQL verwendet.


5. Cloud Audit Policy Language (CAPL) 57Zur Implementierung der eigentlichen Schnittstelle wird das Jersey 63 -Framework eingesetzt,welches die OpenSource-Referenz-Implementierung von JAX-RS 64 ist[28].Das Framework vereinfacht die Verwaltung der Server-Anfragen erheblich, wie imKapitel 5.7.4 zu sehen ist. Der Entwickler muss lediglich den aufzurufenden Methodendie erwartete HTTP-Methode sowie die URI angeben. Um die Verwaltung derAnfragen und die Serialisierung der Objekte kümmert sich Jersey alleine.5.7.2. DatenbankabbildungDie Abbildung von CAPL in der Datenbank ist dem eigentlichen Aufbau der Sprachesehr ähnlich. Die Kreise wurden entfernt und Zwischentabellen eingefügt.5.7.3. Grundlegender Aufbau der KlassenHauptaugenmerk dieser Thesis liegt in der Evaluation existierender Policy-Sprachenund im Entwurf von CAPL, deshalb wird auf die Klassen und deren Aufbau des Prototypennicht im Detail eingegangen, sondern die wichtigsten Gegebenheiten erläutert.Für jede CAPL-Klasse gibt es eine eigene Java Klasse mit den entsprechenden Attributenund Methoden zur Verwaltung der Daten in der Datenbank. Der Aufbau dieserKlassen ist nahezu identisch gehalten, beispielsweise besitzt jede dieser Klassen eineMethode getAll() zur Abfrage aller verfügbaren Instanzen. 65Weiterhin gibt es für jede dieser Klassen eine entsprechende Klasse für Jersey, um dieentsprechenden HTTP-Anfragen abzufangen, die bspw. die o.g. getAll()-Methodeaufruft. 665.7.4. Beispiel der Klasse MachineImageAnhand der Klasse MachineImage wird der Aufbau beispielhaft erläutert. Das Beispielumfasst die Abfrage aller vorhandenen MachineImages. Für die Client Anfragen wird63 http://jersey.java.net/64 Der Java Standard zur Implementierung von REST Web-Services.65 Im Java-Paket classes auf der CD-ROM zu finden.66 Im Java-Paket rest auf der CD-ROM zu finden.


58 5. Cloud Audit Policy Language (CAPL)die Chrome-Erweiterung Simple REST Client 67 und zur Formatierung von XML FreeFormatter 68 verwendet.Im Beispiel ist der Service unter http://localhost/CAPLPrototyp konfiguriert.ClientabfrageIn Abbildung 5.3 sieht man die beispielhafte Anfrage eines Clients unter Request unddie Antwort des Servers unter Response. Die HTTP-Methode GET teilt dem Servermit, dass es sich um eine Abfrage von Daten handelt. Über die URL wird spezifiziert,welche Daten abgefragt werden. Da keine weiteren Parameter in der URL angegebensind, werden alle vorhandenen MachineImages ausgegeben. Die Antwort des Serversenthält nun in XML serialisiert alle vorhanden MachineImages und liefert den StatusCode 200 zurück, um den Erfolg zu quittieren.Jersey KomponenteIn 5.4 ist die Implementierung der Jersey-Klasse des oben gezeigten Beispiels zu sehen.Listing 5.4: Beispiel Jersey-Klasse MachineImage1 //Auszug aus der Datei: de\hfu\wolke\policy\rest\MachineImage.java2 @Path("machineImages")3 public class MachineImage {4 /**5 * GET Anfrage - Erfragt die Daten aller MachineImages.6 * @return 200 - OK - Gibt eine Liste von Objekten als XMLzurü ck.7 */8 @GET9 @Produces(MediaType.TEXT_XML)10 public ArrayList getMachineImages(){67 https://chrome.google.com/webstore/detail/simple-rest-client/fhjcajmcbmldlhcimfajhfbgofnpcjmb68 http://www.freeformatter.com


5. Cloud Audit Policy Language (CAPL) 59Abbildung 5.3.: Ausgeführte Abfrage aller MachineImage-Objekte11 ArrayList list =PolicyMachineImage.getAll();13 if (list.isEmpty())14 throw newNotFoundException(String.format(Globals.MESSAGE_EMPTY,"MachineImages "));15 return (list);16 }17 }Die Jersey-Komponenten kennzeichnen sich durch ein vorangestelltes” @“.@Path("machineImages") gibt an, dass diese Klasse für Anfragen an


60 5. Cloud Audit Policy Language (CAPL)http://localhost/CAPLPrototyp/machineImage zuständig ist. Die Klassedefiniert nur eine Methode in Zeile 7-15, wobei Zeile 7 definiert, dass der Client zumAufrufen dieser Methode eine HTTP-GET Anfrage stellen muss, und Zeile 9 gibt daszur Serialisierung verwendete Format XML an. Die Objekte werden von Jersey durchdie Methode getAll() in Zeile 10 aus der Datenbank geholt. Sollte die Datenbankkeine MachineImages enthalten, wird eine Fehlermeldung mit dem Status Code 404und einem in Globals definierten Fehlertext zurückgegeben. Dies ist in Zeile 12-13nachzuvollziehen. Andernfalls serialisiert Jersey die Objekte automatisch und gibtdiese dem Client in Zeile 14 zurück.5.7.5. Weiterführung der ImplementierungDer Fokus dieser Arbeit lag auf der Evaluation existierender Policy-Sprachen sowiedem Design und der Entwicklung von CAPL. Diese haben mehr Aufwand und Zeitin Anspruch genommen als ursprünglich vermutet 69 . Die derzeitige Implementierungdient der Veranschaulichung der REST-Schnittstelle und des Protokolls zum Abfragen,Erstellen und Löschen von Objekten. Die weitere Entwicklung sowie die Integrationdes Policy-Modellers in das vorhandene Cloud Management Interface wird an die Implementierungweitergegeben, die im Anschluss an diese Thesis erfolgt.Der derzeitige Funktionsumfang umfasst:• Datenbankanbindung mit Connection-Pools• Abfrage aller vorhandenen MachineConfigurations und MachineImages• Abfrage einzelner MachineConfigurations und MachineImages• Erstellen, Löschen, Verarbeiten von MachineConfigurations undMachineImages• Interne Fehlerbehandlung durch Exceptions, die in den entsprechenden HTTP-Status Codes resultieren– Internal Server Error(500), Bad Request (400), Not Found (404)69 Siehe Projektplan: Version 1 und 5 auf der CD-ROM.


5. Cloud Audit Policy Language (CAPL) 61Tabelle 5.9.: Aufbau PolicyRuleAttributname Datentyp BeschreibungresourceURI uri http://research.cloud.hsfurtwangen.de/capl/PolicyRuleenabled boolean Gibt an, ob die Policy aktiv ist und ausgelöstwerden kann oder nicht.ruleType string Gibt den Typ der Policy an. Bspw. ClamAV,portscan . . .deploymentRessource ref Dieses Attribut wird nur benötigt, wenneine Policy von einer anderen VM ausgeführtwerden soll. Dies ist beispielsweisebei der Überprüfung eines Ports sinnvoll, daje nach Netzwerkschnittstelle andere Portsoffen sein dürfen.targetRessoure ref Kann eine Maschine, eine Gruppe oder einMachineTemplate / Image sein, der die PolicyRulezugeordnet wird.properties map Dies ist ein assoziatives Array, mit den kontextbasierten Attributen und Werten der Policy.Der Kontext wird durch den ruleTypeangegeben.intervalType intervalType Gibt den Typ bzw. die Einheit derAusführungszeit an. Siehe Kapitel 5.1interval integer Die Zahl definiert für die intervalTypes, dienicht no“ sind, den zur Einheit gehörigen”Intervall.


62 5. Cloud Audit Policy Language (CAPL)Tabelle 5.10.: Aufbau PolicySetAttributname Datentyp BeschreibungresourceURI uri http://research.cloud.hsfurtwangen.de/capl/PolicySetenabled enabled Gibt an, ob das PolicySet aktiv ist und ausgelöstwerden kann oder nicht.conditionType conditionType Gibt den Typ der Condition an. Derzeit kann diesentweder den Wert D“ für eine Disjunktion oder”C“ für eine Konjunktion annehmen.”targetResource ref Gibt an, welchem Objekt das PolicySet zugeordnetist. Dies kann eine Machine, Group oder MachineTemplatesein.rules ref[] Eine Sammlung von URIs zu PolicyRule oderMetricRule.intervalType intervalType Gibt den Typ bzw. die Einheit derAusführungszeit an. Siehe Tabelle 5.1interval integer Die Zahl definiert für die intervalTypes, die nichtno“ sind, den zur Einheit gehörigen Intervall.”


5. Cloud Audit Policy Language (CAPL) 63Tabelle 5.11.: Aufbau GroupAttributname Datentyp BeschreibungresourceURI uri http://research.cloud.hsfurtwangen.de/capl/Groupenabled boolean Gibt an, ob die Gruppe aktiv ist und ausgelöstwerden kann oder nicht.intervalType intervalType Gibt den Typ bzw. die Einheit derAusführungszeit an. Siehe Tabelle 5.1interval integer Die Zahl definiert für die intervalTypes, die nichtno“ sind, den zur Einheit gehörigen Intervall.”overwriteInterval boolean Standardmäßig false. Wenn es true ist, erzwingtes das Überschreiben der Werte der AttributeintervalType und interval der einzelnen Policiesmit denen der Gruppe.policies ref[] Eine Liste von Verweisen zu PolicySets, PolicyRulesund MetricRules, welche den Machinesder Gruppe zugeordnet werden.machines ref[] Enthält eine Liste von Machines, welche derGruppe zugeordnet sind und die Policies erben.


6. Schlussbetrachtung 656. SchlussbetrachtungDieses Kapitel fasst die gesammelten Ergebnisse der Thesis zusammen und gibt einenÜberblick über mögliche Erweiterungen für CAPL.6.1. ZusammenfassungZiel dieser Thesis war es, eine Policy-Sprache zu finden, mit der sogenannte SecurityPolicies“ für Cloud Infrastrukturen definiert werden können. Anhand der definier-”ten Policies soll die Agentenkonfiguration von SAaaS, einem Auditierungssystem fürCloud-Infrastrukturen, automatisiert werden.Hierzu wurden anhand definierter Anforderungen mehrere bestehende Policy-Sprachen evaluiert und bewertet. Die meisten Sprachen dienen einem anderen Anwendungsszenariowie bspw. der Netzwerkanalyse oder Zugangsrichtlinien, sind zukomplex oder zu umfangreich und bringen eine eigene Runtime zur Interpretation mit.Keine dieser Sprachen kam für SAaaS in Frage, weshalb entschieden wurde, eine eigeneSprache zu definieren, die speziell auf die Bedürfnisse von SAaaS ausgelegt wurde.Resultat dieser Entscheidung war die Cloud Audit Policy Language“, kurz CAPL.”Diese Sprache orientiert sich am Standard CIMI und basiert auf XML. Sie ermöglichtsowohl dem Cloud Benutzer als auch dem Cloud Provider, Policies für VMs zu erstellen.Es ist außerdem möglich, bestimmte Policies bei der Erzeugung einer VMautomatisch zu erstellen.


66 6. Schlussbetrachtung6.2. AusblickDas während dieser Arbeit entwickelte CAPL kann durch verschiedene Erweiterungenoder Anpassungen noch mehr Funktionen gewinnen und weiter optimiert werden.6.2.1. SchemaDerzeit sieht CAPL nur ein XML-Schema zur Validierung und Identifizierung derKlassen vor. Der erste Schritt in der Implementierung im Anschluss an die Thesissollte die Entwicklung eines Schemas sein.6.2.2. run-MethodeDerzeit ist CAPL nur in der Lage Policies zu verwalten. Das starten von Audits gehörtnoch nicht dazu. Sollte in der Implementierung entschieden werden, dass CAPL dasStarten von Audits durchführen, wie in Kapitel 5.6.3 beschrieben, dann ist es nötig einerun-Methode zu definieren, die es ermöglicht Audits zu starten. Diese Methode wirdam besten an Machine sowie an Group angefügt und enthält Parameter, um einzelnePolicies, ganze Gruppen, oder nur einzelne Maschinen zu auditieren.6.2.3. MetaResourceCIMI definiert eine Klasse MetaResource, die den Aufbau für einen Funktionskatalogbietet. Der User kann Anfragen über die Struktur von Klassen stellen und erhältden Aufbau und weitere Informationen wie Wertebereiche direkt über die Schnittstelle.Ferner werden hier mögliche Methoden angezeigt, die an verschiedenen Klassen ausgeführtwerden können. Die Einbindung in CAPL wäre nicht zwangsläufig notwendig,da eine GUI entwickelt werden soll. Allerdings können so eventuell auch Informationenan die GUI weitergeleitet werden. Dies wäre zu evaluieren.


6. Schlussbetrachtung 676.2.4. AktionenEine weitere Erweiterung für CAPL wäre die Definition von Aktionen, die im Falleeiner Erfüllung / Nicht-Erfüllung einer Policy ausgeführt werden sollen. Dieses Szenarioist recht einfach, solange es sich um einfache PolicyRules handelt und die Aktionnur von dieser einen Regel abhängt. Sobald es ein PolicySet mit mehreren PolicyRulesgibt, die alle Aktionen enthalten und das PolicySet evtl. auch Aktionen definiert,wird die Umsetzung komplizierter. Hier muss ein passendes Vorgehen gefunden werden.Eine Möglichkeit wäre die Orientierung an CIM, das eine solche Funktionalitätbietet.


7. Literatur 697. Literatur[1] Lalana Kagal: Rei Ontology Specifications. Version 2.0. 2004. URL: http://www.csee.umbc.edu/~lkagal1/rei/.[2] Klaus Jähne: Management verteilter Systeme und Anwendungen mit dem CommonInformation Model. Diplomarbeit. Germany, 2003.[3] DMTF Cloud Management Working Group: Cloud Infrastructure ManagementInterface (CIMI) Primer. 2012. URL: http://dmtf.org/sites/default/files/standards/documents/DSP2027_1.0.0.pdf.[4] Jeffrey M. Bradshaw: Software Agents. 1997.[5] Frank Dölitzscher et al.: Validating Cloud Infrastructure Changes by CloudAudits“. In: SERVICES. IEEE, 2012, S. 377–384. ISBN: 978-1-4673-3053-4.[6] Frank Dölitzscher et al.: An Autonomous Agent Based Incident Detection Systemfor Cloud Environments“. In: CloudCom. Hrsg. von Costas Lambrinou-”dakis, Panagiotis Rizomiliotis und Tomasz Wiktor Wlodarczyk. IEEE, 2011,S. 197–204. ISBN: 978-1-4673-0090-2.[7] Timothy Grance Peter Mell: The NIST Definition of Cloud Computing. Apr.2012. URL: http : / / csrc . nist . gov / publications / nistpubs / 800 -145/SP800-145.pdf.[8] James A. Hoagland et al.: A Graph-based Language for Specifying SecurityPolicies. unbekannt.[9] R. Shirey: RFC 2828 - Internet Security Glossary“. Mai 2000.”[10] Great Britain. Office of Government Commerce: Service operation. The StationeryOffic Series. Stationery Office, 2007. ISBN: 9780113310463. URL: http://books.google.de/books?id=ZayAKN3hyUoC.


70 7. Literatur[11] Frank Doelitzscher et al.: Understanding Cloud Audits“. English. In: Privacy”and Security for Cloud Computing. Hrsg. von Siani Pearson und George Yee.Computer Communications and Networks. Springer London, 2013, S. 125–163.ISBN: 978-1-4471-4188-4. DOI: 10.1007/978- 1- 4471- 4189- 1_4. URL:http://dx.doi.org/10.1007/978-1-4471-4189-1_4.[12] Marjan Mernik, Jan Heering und Anthony M. Sloane: When and how to developdomain-specific languages“. In: ACM Comput. Surv. 37.4 (Dez. 2005),”S. 316–344. ISSN: 0360-0300. DOI: 10.1145/1118890.1118892. URL: http://doi.acm.org/10.1145/1118890.1118892.[13] David S. Wile: Supporting the DSL Spectrum“. In: Journal of Computing”and Information Technology 9.4 (2001), S. 263–287. URL: http : / / mr .teknowledge.com/wile/Abstracts/DSL_Spectrum.htm.[14] Gerald Bischof: Automatisierte Technische Auditierung von VM-Images.Master-Thesis. Germany, 2012.[15] Lalana Kagal: Rei: A Policy Language for the Me-Centric Project. 2002. URL:http://ebiquity.umbc.edu/_file_directory_/papers/57.pdf.[16] Lalana Kagal: A Policy Specification Language for Governing Open, Dynamic,Distributed Environments. 2004. URL: http://ebiquity.umbc.edu/resource / html / id / 39 / Modeling - Conversation - Policies - as -Policies.[17] Dean Allemang und Jim Hendler: Semantic Web for the Working Ontologist:Effective Modeling in RDFS and OWL. Morgan Kaufmann, 2008. ISBN: 978-0-12-373556-0.[18] Lalana Kagal: Rei Examples. Version 2.0. 2004. URL: http : / / www . csee .umbc.edu/~lkagal1/rei/examples/univ/.[19] Inc. Distributed Management Task Force und Inc. WBEM Solutions: DistributedManagement Task Force (DMTF) Tutorial. 2006. URL: http://www.wbemsolutions.com/tutorials/DMTF/dmtftutorial.pdf.[20] DMTF Policy Working Group: CIM Schema Final Documentation. Version2.34.0. URL: http : / / dmtf . org / sites / default / files / cim / cim _schema_v2340/cim_schema_2.34.0Final-Doc.zip.


7. Literatur 71[21] DMTF: Policy Profile. Version 1.0.0a. Feb. 2007. URL: http://www.dmtf.org/sites/default/files/standards/documents/DSP1003.pdf.[22] DMTF Cloud Management Working Group: Cloud Infrastructure ManagementInterface (CIMI) Model and RESTful HTTP-based Protocol. Version 1.0.1.2012. URL: http : / / dmtf . org / sites / default / files / standards /documents/DSP0263_1.0.1.pdf.[23] T. Berners-Lee, R. Fielding und L. Masinter: Uniform Resource Identifier (URI):Generic Syntax. RFC 3986 (INTERNET STANDARD). Internet EngineeringTask Force, Jan. 2005. URL: http://www.ietf.org/rfc/rfc3986.txt.[24] Thomas Bayer: REST Web Services. Nov. 2002. URL: http://www.oio.de/public/xml/rest-webservices.pdf.[25] R. Fielding et al.: Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (DraftStandard). Updated by RFCs 2817, 5785, 6266, 6585. Internet Engineering TaskForce, Juni 1999. URL: http://www.ietf.org/rfc/rfc2616.txt.[26] Kaveh Keshavarzi und Thomas Bayer: JSON, XML und YAML im Vergleich. Juli2011. URL: http://predic8.de/xml-json-yaml.htm.[27] DMTF Policy Working Group: CIM Policy.vsd - CIM Policy Schema v2.34.0.Version 2.34.0. Juli 2012. URL: http://dmtf.org/sites/default/files/cim/cim_schema_v2340/Visio-CIM_Policy.pdf.[28] Christian Ullenboom: Java 7 - Mehr als eine Insel. Galileo Computing, 2012.ISBN: 978-3-8362-1507-7.


Eidesstattliche Erklärung 73Eidesstattliche ErklärungIch versichere, dass ich die vorstehende Arbeit selbstständig verfasst und hierzu keineanderen als die angegebenen Hilfsmittel verwendet habe. Alle Stellen der Arbeit, diewörtlich oder sinngemäß aus fremden Quellen entnommen wurden, sind als solchekenntlich gemacht.Die Arbeit wurde bisher in gleicher oder ähnlicher Form in keinem anderen Studiengangals Prüfungsleistung vorgelegt oder an anderer Stelle veröffentlicht.Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben kann.Furtwangen, 28. Februar 2013


A. Anhang A-1A. AnhangA.1. CIM Policy-Modell[27]


Page 1 of 13: Policy CIM_Policy.vsd:Title : Policy Schema v2.34.0w*InheritanceAssociationAssociation with WEAK referenceAggregationCompositionequivalent to: 0 .. n*ManagedElement (Abstract)(from Core)**DependencyTable of Contents:Page 1: PolicyPage 2: Policy SetsPage 3: Policy RulesPage 4: AuthorizationRulePage 5: Policy ConditionsPage 6: Authentication ConditionsPage 7: Policy ActionsPage 8: System ClassesPage 9: PolicyRoleCollectionPage 10: PolicyServicePage 11: Dependencies + Other AssocsPage 12: Component AggregationsAuthor : DMTF Policy WGDate : 27 July 2012Page 13: Sys Component + Other AggregationsPage 14: Version 2.10PolicySetAppliesToElementPolicyComponent**Policy (Abstract)CommonName: stringPolicyKeywords: string[ ]**PolicyCondition (Abstract)PolicyConditionStructureGroupNumber: uint16ConditionNegated: booleanPolicyActionStructureActionOrder: uint16*PolicySet (Abstract)See Policy Sets**PolicySetComponentPriority: uint16See Policy ConditionsPolicyAction (Abstract)See Policy Actions**


Page 2 of 13: Policy Sets CIM_Policy.vsd:Title : Policy Schema v2.34.0Author : DMTF Policy WGDate : 27 July 2012*ManagedElement (Abstract)(form Core)PolicyRoleCollectionPolicy (Abstract)CommonName: stringPolicyKeywords: string[ ]PolicyRole: string {Req’d}ActivatePolicySet ( [IN] Element: ref ManagedElement) : uint32DeactivatePolicySet ( [IN] Element: ref ManagedElement) : uint32*PolicySetAppliesToElementSystem(Abstract, from Core)PolicySetInRoleCollection1PolicySetInSystemPriority: uint16***PolicySet (Abstract)PolicyDecisionStrategy: uint16 {Enum}PolicyRoles: string[ ] {D}Enabled: uint16 {Enum} = 1***PolicySetComponentPriority: uint16PolicySetValidityPeriod*PolicyTimePeriodConditionPolicyRuleSee Policy Rules See Policy RulesPolicyGroupSee Policy Conditions


Page 3 of 13: Policy Rules CIM_Policy.vsd:Title : Policy Schema v2.34.0Author : DMTF Policy WGSystem(Abstract, from Core) 1Date : 27 July 20121PolicySet (Abstract)See Policy SetsPolicyGroupInSystemPolicyRuleInSystemPolicyRuleInPolicyGroup {D}*PolicyGroupCreationClassName: string[key]PolicyGroupName: string[key]w**PolicyGroupInPolicyGroup {D}PolicyRule**w*CreationClassName: string[key]PolicyRuleName: string[key]ConditionListType: uint16 {Enum} = 1RuleUsage: stringPriority: uint16 {D}Mandatory: boolean {D}SequencedActions: uint16 {Enum} = 3ExecutionStrategy: uint16 {Enum}***PolicyConditionInPolicyRuleGroupNumber: uint16ConditionNegated: booleanPolicyActionInPolicyRule*PolicyAction (Abstract)See Policy ActionsAuthenticationRulePolicyRuleValidityPeriod {D}AuthorizationRule {E}*PolicyCondition (Abstract)TierPolicyRule{E}See Policy ConditionsPrivilegePropagationRule {E}TimePeriodCondition: uint16PrivilegePropagationRule {E}Activity : uint16 {enum}ProvisioningType : uint16 {enum}DataMovementRate : uint16 {enum}RuleDiscriminator : string[]*PolicyTimePeriodConditionSee Policy Conditions


Page 4 of 13: AuthorizationRule CIM_Policy.vsd:Title : Policy Schema v2.34.0Author : DMTF Policy WGDate : 27 July 2012AuthorizationRule {E}*AuthorizationRuleAppliesToTarget {E}*ManagedElement (Abstract)(form Core)AuthorizationRuleAppliesToPrivilege {E} *Privilege(from User)AuthorizationRuleAppliesToIdentity {E} *Identity(from User)AuthorizationRuleAppliesToRole {E} *Role(from User)


Page 5 of 13: Policy Conditions CIM_Policy.vsd:Title : Policy Schema v2.34.0Author : DMTF Policy WGDate : 27 July 2012PolicyConditionStructureGroupNumber: uint16ConditionNegated: boolean*Policy (Abstract)See Policy Sets**PolicyComponentPolicyCondition (Abstract)SystemCreationClassName: string[key]SystemName: string[key]PolicyRuleCreationClassName: string[key]PolicyRuleName: string[key]CreationClassName: string[key]PolicyConditionName: string[key]**PolicyConditionInPolicyRule*See Policy SetsPolicySet (Abstract)See Policy SetsPolicyRule*PolicySetValidityPeriodPolicyConditionInPolicyCondition*CompoundPolicyConditionConditionListType: uint16 {Enum}PolicyTimePeriodConditionTimePeriod: stringMonthOfYearMask: uint8[ ][Octetstring]DayOfMonthMask: uint8[ ][Octetstring]DayOfWeekMask: uint8[ ][Octetstring]TimeOfDayMask: stringLocalOrUtcTime: uint16*FilterList (from Network)1FilterOfPacketConditionQueryCondition {E}QueryResultName: string {Req’d}Query: String {Req’d}QueryLanguage: uint16 = 2 {Enum, Req’d}Trigger: boolean = False {Req’d}AuthenticationCondition {Abstract}(See Policy(AuthenticationConditions))VendorPolicyConditionConstraint: Octetstring[ ]ConstraintEncoding: string[OID]PacketFilterCondition*AcceptCredentialFromCredentialManagementService (from User/Security)**


Page 6 of 13: AuthenticationConditions CIM_Policy.vsd:Title : Policy Schema v2.34.0Author : DMTF Policy WGDate : 27 July 2012AuthenticationCondition{Abstract}SharedSecretAuthenticationPublicPrivateKeyAuthenticationIDOfPrincipal: stringContextOfSecret: stringSelfIssuedKey: booleanDistinguishedName: stringPublicKey: stringAccountAuthenticationKerberosAuthenticationAccountID: stringAccountContext: stringUserName: stringBiometricAuthenticationDocumentAuthenticationTypeOfBiometric: uint16 {Enum}OtherBiometric: stringPersonalIdentifier: stringTypeOfDocument: uint16 {Enum}OtherDocument: stringDocumentIdentifier: stringNetworkingIDAuthenticationPhysicalCredentialAuthenticationNetworkingIdentityClassName: stringTypeOfCredential: uint16 {Enum}OtherCredential: stringPhysicalIdentifier: string


Page 7 of 13: Policy Actions CIM_Policy.vsd:Title : Policy Schema v2.34.0Author : DMTF Policy WGDate : 27 July 2012PolicyComponent**Policy (Abstract)See Policy Sets*PolicyActionStructureActionOrder: uint16PolicySet (Abstract)See Policy SetsPolicyAction (Abstract)*See Policy SetsPolicyRule*PolicyActionInPolicyRule*SystemCreationClassName: string[key]SystemName: string[key]PolicyRuleCreationClassName: string[key]PolicyRuleName: string[key]CreationClassName: string[key]PolicyActionName: string[key]DoActionLogging: boolean*PolicyActionInPolicyActionMethodAction {E}InstgMethodCallName: string {Req’d}Query: String {Req’d}QueryLanguage: uint16 = 2 {Enum, Req’d}CompoundPolicyActionSequencedActions: uint16 {Enum}ExecutionStrategy: uint16 {Enum}*VendorPolicyActionActionData: Octetstring[ ]ActionEncoding: string[OID]RejectConnectionActionNetworkPacketActionPacketAction: uint16 {Enum}OtherAction: string


Page 8 of 13: System Classes CIM_Policy.vsd:Title : Policy Schema v2.34.0Author : DMTF Policy WGDate : 27 July 20120..1System(Abstract, from Core)*Policy (Abstract)See Policy Sets*PolicyInSystem1PolicyRoleCollectionSee PolicyRoleCollection*PolicyRoleCollectionInSystemPolicySet (Abstract)See Policy Sets*PolicySetInSystemPriority: uint16PolicyActionReusablePolicyPolicyGroupSee Policy Setsw*PolicyGroupInSystemAdminDomain(form Core)*ContainedDomain**PolicyActionInPolicyRepository {D}PolicyRuleSee Policy Setsw*PolicyRuleInSystemPolicyConditionReusablePolicyContainer0..1**0..1PolicyRepository {D}PolicyContainerInPolicyContainer*0..1*PolicyConditionInPolicyRepository {D}PolicyRepositoryInPolicyRepository {D}*


Page 9 of 13: PolicyRoleCollection CIM_Policy.vsd:Title : Policy Schema v2.34.0Author : DMTF Policy WGDate : 27 July 2012ManagedElement (Abstract)(form Core)**MemberOfCollection *Collection(from Core)ElementInPolicyRoleCollectionSystemSpecificCollection(from Core)InstanceID : string {key}*HostedCollection1System(from Core)1PolicyRoleCollectionInSystemPolicySet (Abstract)[See Policy Sets]**PolicySetInRoleCollectionPolicyRoleCollectionPolicyRole: string {Req’d}ActivatePolicySet ( [IN] Element: ref ManagedElement) : uint32DeactivatePolicySet ( [IN] Element: ref ManagedElement) : uint32**


B. CD-ROM B-1B. CD-ROM• Projektplan/• Proposal/• Literatur/• Programmcode/• L A TEXcode/• Sonstiges/

Weitere Magazine dieses Users
Ähnliche Magazine