5 research outputs found
Enforcing Security and Assurance Properties in Cloud Environment
International audienceBefore deploying their infrastructure (resources, data, communications, ...) on a Cloud computing platform, companies want to be sure that it will be properly secured. At deployment time, the company provides a security policy describing its security requirements through a set of properties. Once its infrastructure deployed, the company want to be assured that this policy is applied and enforced. But describing and enforcing security properties and getting strong evidences of it is a complex task. To address this issue, in [1], we have proposed a language that can be used to express both security and assurance properties on distributed resources. Then, we have shown how these global properties can be cut into a set of properties to be enforced locally. In this paper, we show how these local properties can be used to automatically configure security mechanisms. Our language is context-based which allows it to be easily adapted to any resource naming systems e.g., Linux and Android (with SELinux) or PostgreSQL. Moreover, by abstracting low-level functionalities (e.g., deny write to a file) through capabilities, our language remains independent from the security mechanisms. These capabilities can then be combined into security and assurance properties in order to provide high-level functionalities, such as confidentiality or integrity. Furthermore, we propose a global architecture that receives these properties and automatically configures the security and assurance mechanisms accordingly. Finally, we express the security and assurance policies of an industrial environment for a commercialized product and show how its security is enforced
Beschreibung, Verarbeitung und ĂśberprĂĽfung clientseitiger Policies fĂĽr vertrauenswĂĽrdige Cloud-Anwendungen
Für Geschäftsbereiche mit hohen Anforderungen an Vertraulichkeit und Datenschutz zur Verarbeitung ihrer sensitiven Informationen kann für die Nutzung von Public-Cloud-Technologien keine Benutzerakzeptanz ausgewiesen werden. Die Ursachen dafür erwachsen aus dem inhärenten Strukturkonzept verteilter, begrenzter Verantwortlichkeiten und einem fehlenden Cloud-Anwender-Vertrauen. Die vorliegende Arbeit verfolgt ein Cloud-Anwender orientiertes Vorgehen zur Durchsetzung regelnder Policy-Konzepte, kombiniert mit einem holistischen Ansatz zur Herstellung einer durchgehenden Vertrauensbasis.
Der Aspekt Vertrauen erhält eine eigenständige Konzeptualisierung und wird zu einem Cloud-Anwender-Instrument für die Gestaltung vertrauenswürdiger infrastruktureller Eigenschaften entwickelt. Jede weitere Form einer Policy entwickelt ihren verbindlichen regulierenden Wert erst durch eine unlösliche Verbindung mit den hier vorgelegten Konzepten vertrauenswürdiger Entitäten.
Ein ontologisch formalisierter Beschreibungsansatz vollzieht die für eine Regulierung notwendige Konzeptualisierung einer domänenspezifischen IT-Architektur und qualifizierender Sicherheitseigenschaften. Eigenständige Konzeptklassen für die Regulierung liefern den Beschreibungsrahmen zur Ableitung integrierter Trust-Policies. Darauf aufbauende Domänenmodelle repräsentieren eine vom Cloud-Anwender definierte Erwartung in Bezug auf ein reguliertes Cloud-Architektur-Design und reflektieren die reale Welt auf Grundlage vertrauenswürdiger Fakten. Vertrauen quantifiziert sich im Ergebnis logischer Schlussfolgerungen und ist Ausdruck zugesicherter Cloud-Sicherheitseigenschaften und geregelter Verhaltensformen.:1 Einleitung
1.1 Motivation
1.2 Forschungsfragen
1.3 Zielstellung
1.4 Vorgehensweise
2 Problembeschreibung
2.1 Public Cloud, Strukturerweiterung einer Organisation
2.1.1 Kopplung im sozialen Kontext
2.1.2 Strukturelle Kopplung im Cloud-Kontext
2.2 Regelungen: strukturbildende Elemente von Organisationen
2.2.1 Regelungen im sozialenKontext
2.2.1.1 Rechtliche Regelungen
2.2.1.2 Nichtrechtliche Regelungen
2.2.1.3 Regelungen in Organisationen
2.2.2 Regelungen im Cloud-Kontext
2.3 Erwartungen und Unbestimmtheit von Handlungen
2.3.1 Erwartungen im sozialenKontext
2.3.2 Erwartungen im Cloud-Kontext
2.4 Konformität, Abbildung von Regelungen
2.4.1 Konformität im sozialenKontext
2.4.2 Konformität im Cloud-Kontext
2.5 Thesen
3 Analyse
3.1 Anforderungen
3.1.1 Infrastrukturschicht
3.1.1.1 Hardwarebasierte Geo-Lokalisierung
3.1.1.2 Virtual Machine Monitor
3.1.1.3 Netzwerksicherheit
3.1.2 Plattform-/Laufzeitschicht
3.1.2.1 Virtualisierungstechnologie
3.1.2.2 OS-Sicherheitsmodell
3.1.2.3 Datensicherheit der Laufzeitschicht
3.1.3 Anwendungs-/Serviceschicht
3.1.3.1 Anwendungssicherheit
3.1.3.2 Prozesssicherheit
3.1.3.3 Datensicherheit der Anwendungsschicht
3.1.4 Verwaltung/Betrieb
3.1.5 Compliance
3.1.5.1 Governance
3.1.5.2 Klassifizierte Informationen
3.1.5.3 Datenschutz
3.1.6 Zusammenfassung der Regulierungsziele
3.2 Anwendungsfälle einer Multi-User-Cloud-Umgebung
3.2.1 TCG-Konzepte und Definitionen
3.2.2 UC-Aufbau einer Vertrauensbasis
3.2.3 UC-Aufbau einer vertrauenswĂĽrdigen Kooperationsbasis
3.2.4 UC-kooperative Provisionierung
3.2.5 UC-Änderungen von Regeln innerhalb einer kooperativen Domäne
3.2.6 Abgeleitete Anwendungsfälle aus TCG-Richtlinien
3.3 State-of-the-Art-Betrachtung
3.3.1 Thema:Regulierungsziele
3.3.1.1 Pattern-based Runtime Management of Composite Cloud Applications
3.3.1.2 Unifying Compliance Requirements across Business and IT
3.3.2 Thema:Digitale Regelkonzepte
3.3.2.1 Policy-Aware Provisioning of Cloud Applications
3.3.2.2 Policy-Aware Provisioning and Management of Cloud Applications
3.3.3 Thema:Vertrauenskonzepte
3.3.3.1 Secure Enclaves for REactive Cloud Applications
3.3.3.2 Enforcing-Security-and-Assurance-Properties-in-Cloud-Environment
3.3.4 Thema:Technische Standards
3.3.4.1 WebServicesPolicy1.5 – Framework-Current
3.3.4.2 WS-SecurityPolicy1.3
3.3.4.3 WS-Trust
3.3.4.4 Web Services Security: SOAP Message Security 1.1
3.3.5 Thema:Sprachkonzepte
3.3.5.1 Using Ontologies to Analyze Compliance Requirements of Cloud-BasedProcesses
3.3.5.2 Policy Language for a Pervasive Computing Environment
3.4 Zusammenfassung und Abgrenzungsbeschreibung
4 Konzeption
4.1 Ontologie-Konzept
4.1.1 Strukturentwurf Ontologie
4.1.2 Ziele der ontologischen Konzeptualisierung
4.1.3 Ontologie Regulierung
4.1.3.1 Haupthierachie Regulation-Ontology
4.1.3.2 Konzeptklasse Action
4.1.3.3 Konzeptklasse Constraint
4.1.3.4 Konzeptklasse Rule
4.1.3.5 Konzeptklasse Policy
4.1.3.6 Konzeptklasse State
4.1.3.7 Konzeptklasse Transformation
4.1.4 Ontologie Cloud-Domain
4.1.4.1 Konzeptklasse CloudDomain
4.1.4.2 Konzeptklasse Entity
4.1.4.3 Konzeptklasse Subject
4.1.4.4 Konzeptklasse ArchitecturalLayer
4.1.4.5 Konzeptklasse Object
4.1.4.6 Konzeptklasse Part
4.1.4.7 Konzeptklasse Connection
4.1.4.8 Konzeptklasse CloudService
4.1.5 Ontologie Security
4.1.5.1 Konzept einer vertrauensbildenden Sicherheitsstrategie
4.1.5.2 Konzeptklasse Asset
4.1.5.3 Konzeptklasse PropertySecurity
4.1.5.4 Konzeptklasse SecurityFunction
4.1.5.5 Konzeptklasse SecurityRequirement
4.1.5.6 Konzeptklasse Identity
4.1.5.7 Konzeptklasse Credential
4.1.5.8 Konzeptklasse SecurityModel (Sicherheitsmodell)
4.2 Konzept zur Herausbildung von Vertrauen (Trust)
4.2.1 Konzept einer vertrauenswürdigen Entität
4.2.2 Konzept einer Authority
4.2.2.1 Zusicherung von Entity-Eigenschaften
4.2.2.2 Entitäten innerhalb einer Authority-Hierarchie
4.2.2.3 Entitäten und externe Authority
4.2.3 Konzept einer Policy zur Entwicklung von Vertrauen
4.2.3.1 Spezialisierung der Trust-Policy
4.2.3.2 QualityProperty – Gegenstand der Vertrauenspolitik
4.3 Trust-Establishment-Protokoll
4.3.1 Datenmodell
4.3.1.1 Verhaltensorientierte Artefakte
4.3.1.2 Kryptographische Artefakte
4.3.1.3 Protokollspezifische Artefakte
4.3.2 Horizontale Etablierung von Vertrauen (Establishment of Trust)
4.3.2.1 Phase1: Auswahl einer Cloud-Plattform
4.3.2.2 Phase2: Erweiterung der Vertrauensgrundlage auf Cloud-Anbieter-Seite
4.3.3 Vertikale Etablierung von Vertrauen (Delegation of Trust)
4.3.3.1 Registrierung von Policy-Entitäten
4.3.3.2 Registrierung von Domänen-Entitäten
4.3.3.3 Ableitung vertrauenswürdiger Entitäten
4.3.3.4 Ableitung vertrauenswürdiger Eigenschaften und Aktivitäten
4.4 Zusammenfassung
5 Validierung
5.1 Referenzarchitektur – TrustedCloud
5.1.1 Komponentenbeschreibung – IT-Plattform
5.1.2 Komponentenbeschreibung – Laufzeitumgebung
5.1.3 Komponentenbeschreibung – Integrierte Systeme
5.1.4 ExterneSysteme – Key & CA Service
5.1.4.1 Bezeichnungen und Namespaces
5.1.4.2 TE-Zustandsmodell
5.1.4.3 Policy-Zonen und Policy-Anwendungsraum
5.2 Trust-Policies und Transformation
5.2.1 Szenario (1) – Bereitstellung Virtual Machine Monitor KVM
5.2.1.1 Domain-Spezifikation–KVM-Komponente
5.2.1.2 Regulation-Spezifikation – KVM-Deployment-Policy
5.2.1.3 Prüfung der KVM-Authentizität
5.2.1.4 Zusicherung von KVM-Identitätseigenschaften
5.2.1.5 Transformation – KVM-Trust-Rule
5.2.1.6 Transformation – KVM-Deployment-Rule
5.2.2 Szenario (2) – Bereitstellung Virtualisiertes Betriebssystem
5.2.2.1 Domain-Spezifikation–Virtual-OS
5.2.2.2 Regulation-Spezifikation – Virtual-OS-Deployment-Policy
5.2.2.3 Prüfung der TE-Authentizität
5.2.2.4 Policy-Zone einrichten – Z_RUNTIME.DB
5.2.2.5 Vertrauenskette prüfen – ChainofTrust
5.2.3 Szenario (3) – Bereitstellung Datenbanksystem (DBS)
5.2.3.1 Domain-Spezifikation – Datenbanksystem
5.2.3.2 Regulation-Spezifikation – DBS-Deployment-Policy
5.2.3.3 Prüfung der DBS-Authentizität
5.2.3.4 Transformation – DBS-Trust-Rule
5.2.3.5 Transformation – DBS-Deployment-Rule
5.2.4 Szenario(4) – ExterneDBS-Zugangssteuerung
5.2.4.1 Domain-Spezifikation – User-to-DB Connection
5.2.4.2 Regulation-Spezifikation – DBS-Connection-Policy
5.2.4.3 Prüfung der DBS-Endpunkt-Authentizität
5.2.4.4 Absicherung der DBS-Verbindung – Verschlüsselung
5.2.4.5 Transformation
5.3 Attestierung – Vertrauenswürdigkeit
5.3.1 Dynamische Methoden der Konzeptklasse State
5.3.2 Kategorien fĂĽr Niveaubestimmung von VertrauenswĂĽrdigkeit
5.3.3 Semantische Rules fĂĽr Niveaubestimmung
5.3.3.1 Ableitungsregel – Vertrauenswürdigkeit HOCH
5.3.3.2 Ableitungsregel – Vertrauenswürdigkeit MITTEL
5.3.3.3 Ableitungsregel – Vertrauenswürdigkeit GERING
5.3.3.4 Ableitungsregel – Vertrauenswürdigkeit UNBESTIMMT
5.4 GegenĂĽberstellung der Szenarien mit den Zielstellungen
5.5 GegenĂĽberstellung der Ergebnisse mit den Kernfragen
5.6 Zusammenfassung der Validieren
6 Zusammenfassung – Ausblick
6.1 Zusammenfassung der Arbeit
6.2 Ausblick und abgeleitete Themen
AbkĂĽrzungsverzeichnis
I State-of-the-Art – Kategorien
II HardwareunterstĂĽtzte Sicherheit fĂĽr eine IT-Plattform
II.1 TrustedPlatformModule
II.2 TechnologiefĂĽrIT-Plattformsicherheit
II.3 Konzept einer hardwarebasierten Vertrauenspolitik
II.3.1 Sichere Mikroarchitektur
II.3.2 Messung statischer Systemeigenschaften
II.4 Kontrollierter Systemstart
II.4.1 Identifizierbarer Plattform-EigentĂĽmer
II.4.2 Versiegeln von Systemwerten(Sealing)
II.5 Konzept der Attestierung
II.5.1 Attestierungs-SchlĂĽssel
II.5.2 Zertifizierung des Attestierungs-IdentifikationsschlĂĽssels
II.5.3 Attestierungs-Modul
II.5.4 Attestierungs-Service
II.5.5 HardwarebasierteGeo-Lokalisierung
III Ăśbersicht der Anforderungen
III.1 Anforderungen an die Cloud-Infrastruktur-Plattform-Ebene
III.2 Anforderungen an die Cloud-Laufzeitebene
III.3 Anforderungen an die Cloud-Service-Ebene
III.4 Anforderungen an operatives Management
III.5 Anforderungen an Cloud-Anwender-Nutzungsebene
IV Spezifikation Ontologi
Enforcing Security and Assurance Properties in Cloud Environment
International audienceBefore deploying their infrastructure (resources, data, communications, ...) on a Cloud computing platform, companies want to be sure that it will be properly secured. At deployment time, the company provides a security policy describing its security requirements through a set of properties. Once its infrastructure deployed, the company want to be assured that this policy is applied and enforced. But describing and enforcing security properties and getting strong evidences of it is a complex task. To address this issue, in [1], we have proposed a language that can be used to express both security and assurance properties on distributed resources. Then, we have shown how these global properties can be cut into a set of properties to be enforced locally. In this paper, we show how these local properties can be used to automatically configure security mechanisms. Our language is context-based which allows it to be easily adapted to any resource naming systems e.g., Linux and Android (with SELinux) or PostgreSQL. Moreover, by abstracting low-level functionalities (e.g., deny write to a file) through capabilities, our language remains independent from the security mechanisms. These capabilities can then be combined into security and assurance properties in order to provide high-level functionalities, such as confidentiality or integrity. Furthermore, we propose a global architecture that receives these properties and automatically configures the security and assurance mechanisms accordingly. Finally, we express the security and assurance policies of an industrial environment for a commercialized product and show how its security is enforced
Beschreibung, Verarbeitung und ĂśberprĂĽfung clientseitiger Policies fĂĽr vertrauenswĂĽrdige Cloud-Anwendungen
Für Geschäftsbereiche mit hohen Anforderungen an Vertraulichkeit und Datenschutz zur Verarbeitung ihrer sensitiven Informationen kann für die Nutzung von Public-Cloud-Technologien keine Benutzerakzeptanz ausgewiesen werden. Die Ursachen dafür erwachsen aus dem inhärenten Strukturkonzept verteilter, begrenzter Verantwortlichkeiten und einem fehlenden Cloud-Anwender-Vertrauen. Die vorliegende Arbeit verfolgt ein Cloud-Anwender orientiertes Vorgehen zur Durchsetzung regelnder Policy-Konzepte, kombiniert mit einem holistischen Ansatz zur Herstellung einer durchgehenden Vertrauensbasis.
Der Aspekt Vertrauen erhält eine eigenständige Konzeptualisierung und wird zu einem Cloud-Anwender-Instrument für die Gestaltung vertrauenswürdiger infrastruktureller Eigenschaften entwickelt. Jede weitere Form einer Policy entwickelt ihren verbindlichen regulierenden Wert erst durch eine unlösliche Verbindung mit den hier vorgelegten Konzepten vertrauenswürdiger Entitäten.
Ein ontologisch formalisierter Beschreibungsansatz vollzieht die für eine Regulierung notwendige Konzeptualisierung einer domänenspezifischen IT-Architektur und qualifizierender Sicherheitseigenschaften. Eigenständige Konzeptklassen für die Regulierung liefern den Beschreibungsrahmen zur Ableitung integrierter Trust-Policies. Darauf aufbauende Domänenmodelle repräsentieren eine vom Cloud-Anwender definierte Erwartung in Bezug auf ein reguliertes Cloud-Architektur-Design und reflektieren die reale Welt auf Grundlage vertrauenswürdiger Fakten. Vertrauen quantifiziert sich im Ergebnis logischer Schlussfolgerungen und ist Ausdruck zugesicherter Cloud-Sicherheitseigenschaften und geregelter Verhaltensformen.:1 Einleitung
1.1 Motivation
1.2 Forschungsfragen
1.3 Zielstellung
1.4 Vorgehensweise
2 Problembeschreibung
2.1 Public Cloud, Strukturerweiterung einer Organisation
2.1.1 Kopplung im sozialen Kontext
2.1.2 Strukturelle Kopplung im Cloud-Kontext
2.2 Regelungen: strukturbildende Elemente von Organisationen
2.2.1 Regelungen im sozialenKontext
2.2.1.1 Rechtliche Regelungen
2.2.1.2 Nichtrechtliche Regelungen
2.2.1.3 Regelungen in Organisationen
2.2.2 Regelungen im Cloud-Kontext
2.3 Erwartungen und Unbestimmtheit von Handlungen
2.3.1 Erwartungen im sozialenKontext
2.3.2 Erwartungen im Cloud-Kontext
2.4 Konformität, Abbildung von Regelungen
2.4.1 Konformität im sozialenKontext
2.4.2 Konformität im Cloud-Kontext
2.5 Thesen
3 Analyse
3.1 Anforderungen
3.1.1 Infrastrukturschicht
3.1.1.1 Hardwarebasierte Geo-Lokalisierung
3.1.1.2 Virtual Machine Monitor
3.1.1.3 Netzwerksicherheit
3.1.2 Plattform-/Laufzeitschicht
3.1.2.1 Virtualisierungstechnologie
3.1.2.2 OS-Sicherheitsmodell
3.1.2.3 Datensicherheit der Laufzeitschicht
3.1.3 Anwendungs-/Serviceschicht
3.1.3.1 Anwendungssicherheit
3.1.3.2 Prozesssicherheit
3.1.3.3 Datensicherheit der Anwendungsschicht
3.1.4 Verwaltung/Betrieb
3.1.5 Compliance
3.1.5.1 Governance
3.1.5.2 Klassifizierte Informationen
3.1.5.3 Datenschutz
3.1.6 Zusammenfassung der Regulierungsziele
3.2 Anwendungsfälle einer Multi-User-Cloud-Umgebung
3.2.1 TCG-Konzepte und Definitionen
3.2.2 UC-Aufbau einer Vertrauensbasis
3.2.3 UC-Aufbau einer vertrauenswĂĽrdigen Kooperationsbasis
3.2.4 UC-kooperative Provisionierung
3.2.5 UC-Änderungen von Regeln innerhalb einer kooperativen Domäne
3.2.6 Abgeleitete Anwendungsfälle aus TCG-Richtlinien
3.3 State-of-the-Art-Betrachtung
3.3.1 Thema:Regulierungsziele
3.3.1.1 Pattern-based Runtime Management of Composite Cloud Applications
3.3.1.2 Unifying Compliance Requirements across Business and IT
3.3.2 Thema:Digitale Regelkonzepte
3.3.2.1 Policy-Aware Provisioning of Cloud Applications
3.3.2.2 Policy-Aware Provisioning and Management of Cloud Applications
3.3.3 Thema:Vertrauenskonzepte
3.3.3.1 Secure Enclaves for REactive Cloud Applications
3.3.3.2 Enforcing-Security-and-Assurance-Properties-in-Cloud-Environment
3.3.4 Thema:Technische Standards
3.3.4.1 WebServicesPolicy1.5 – Framework-Current
3.3.4.2 WS-SecurityPolicy1.3
3.3.4.3 WS-Trust
3.3.4.4 Web Services Security: SOAP Message Security 1.1
3.3.5 Thema:Sprachkonzepte
3.3.5.1 Using Ontologies to Analyze Compliance Requirements of Cloud-BasedProcesses
3.3.5.2 Policy Language for a Pervasive Computing Environment
3.4 Zusammenfassung und Abgrenzungsbeschreibung
4 Konzeption
4.1 Ontologie-Konzept
4.1.1 Strukturentwurf Ontologie
4.1.2 Ziele der ontologischen Konzeptualisierung
4.1.3 Ontologie Regulierung
4.1.3.1 Haupthierachie Regulation-Ontology
4.1.3.2 Konzeptklasse Action
4.1.3.3 Konzeptklasse Constraint
4.1.3.4 Konzeptklasse Rule
4.1.3.5 Konzeptklasse Policy
4.1.3.6 Konzeptklasse State
4.1.3.7 Konzeptklasse Transformation
4.1.4 Ontologie Cloud-Domain
4.1.4.1 Konzeptklasse CloudDomain
4.1.4.2 Konzeptklasse Entity
4.1.4.3 Konzeptklasse Subject
4.1.4.4 Konzeptklasse ArchitecturalLayer
4.1.4.5 Konzeptklasse Object
4.1.4.6 Konzeptklasse Part
4.1.4.7 Konzeptklasse Connection
4.1.4.8 Konzeptklasse CloudService
4.1.5 Ontologie Security
4.1.5.1 Konzept einer vertrauensbildenden Sicherheitsstrategie
4.1.5.2 Konzeptklasse Asset
4.1.5.3 Konzeptklasse PropertySecurity
4.1.5.4 Konzeptklasse SecurityFunction
4.1.5.5 Konzeptklasse SecurityRequirement
4.1.5.6 Konzeptklasse Identity
4.1.5.7 Konzeptklasse Credential
4.1.5.8 Konzeptklasse SecurityModel (Sicherheitsmodell)
4.2 Konzept zur Herausbildung von Vertrauen (Trust)
4.2.1 Konzept einer vertrauenswürdigen Entität
4.2.2 Konzept einer Authority
4.2.2.1 Zusicherung von Entity-Eigenschaften
4.2.2.2 Entitäten innerhalb einer Authority-Hierarchie
4.2.2.3 Entitäten und externe Authority
4.2.3 Konzept einer Policy zur Entwicklung von Vertrauen
4.2.3.1 Spezialisierung der Trust-Policy
4.2.3.2 QualityProperty – Gegenstand der Vertrauenspolitik
4.3 Trust-Establishment-Protokoll
4.3.1 Datenmodell
4.3.1.1 Verhaltensorientierte Artefakte
4.3.1.2 Kryptographische Artefakte
4.3.1.3 Protokollspezifische Artefakte
4.3.2 Horizontale Etablierung von Vertrauen (Establishment of Trust)
4.3.2.1 Phase1: Auswahl einer Cloud-Plattform
4.3.2.2 Phase2: Erweiterung der Vertrauensgrundlage auf Cloud-Anbieter-Seite
4.3.3 Vertikale Etablierung von Vertrauen (Delegation of Trust)
4.3.3.1 Registrierung von Policy-Entitäten
4.3.3.2 Registrierung von Domänen-Entitäten
4.3.3.3 Ableitung vertrauenswürdiger Entitäten
4.3.3.4 Ableitung vertrauenswürdiger Eigenschaften und Aktivitäten
4.4 Zusammenfassung
5 Validierung
5.1 Referenzarchitektur – TrustedCloud
5.1.1 Komponentenbeschreibung – IT-Plattform
5.1.2 Komponentenbeschreibung – Laufzeitumgebung
5.1.3 Komponentenbeschreibung – Integrierte Systeme
5.1.4 ExterneSysteme – Key & CA Service
5.1.4.1 Bezeichnungen und Namespaces
5.1.4.2 TE-Zustandsmodell
5.1.4.3 Policy-Zonen und Policy-Anwendungsraum
5.2 Trust-Policies und Transformation
5.2.1 Szenario (1) – Bereitstellung Virtual Machine Monitor KVM
5.2.1.1 Domain-Spezifikation–KVM-Komponente
5.2.1.2 Regulation-Spezifikation – KVM-Deployment-Policy
5.2.1.3 Prüfung der KVM-Authentizität
5.2.1.4 Zusicherung von KVM-Identitätseigenschaften
5.2.1.5 Transformation – KVM-Trust-Rule
5.2.1.6 Transformation – KVM-Deployment-Rule
5.2.2 Szenario (2) – Bereitstellung Virtualisiertes Betriebssystem
5.2.2.1 Domain-Spezifikation–Virtual-OS
5.2.2.2 Regulation-Spezifikation – Virtual-OS-Deployment-Policy
5.2.2.3 Prüfung der TE-Authentizität
5.2.2.4 Policy-Zone einrichten – Z_RUNTIME.DB
5.2.2.5 Vertrauenskette prüfen – ChainofTrust
5.2.3 Szenario (3) – Bereitstellung Datenbanksystem (DBS)
5.2.3.1 Domain-Spezifikation – Datenbanksystem
5.2.3.2 Regulation-Spezifikation – DBS-Deployment-Policy
5.2.3.3 Prüfung der DBS-Authentizität
5.2.3.4 Transformation – DBS-Trust-Rule
5.2.3.5 Transformation – DBS-Deployment-Rule
5.2.4 Szenario(4) – ExterneDBS-Zugangssteuerung
5.2.4.1 Domain-Spezifikation – User-to-DB Connection
5.2.4.2 Regulation-Spezifikation – DBS-Connection-Policy
5.2.4.3 Prüfung der DBS-Endpunkt-Authentizität
5.2.4.4 Absicherung der DBS-Verbindung – Verschlüsselung
5.2.4.5 Transformation
5.3 Attestierung – Vertrauenswürdigkeit
5.3.1 Dynamische Methoden der Konzeptklasse State
5.3.2 Kategorien fĂĽr Niveaubestimmung von VertrauenswĂĽrdigkeit
5.3.3 Semantische Rules fĂĽr Niveaubestimmung
5.3.3.1 Ableitungsregel – Vertrauenswürdigkeit HOCH
5.3.3.2 Ableitungsregel – Vertrauenswürdigkeit MITTEL
5.3.3.3 Ableitungsregel – Vertrauenswürdigkeit GERING
5.3.3.4 Ableitungsregel – Vertrauenswürdigkeit UNBESTIMMT
5.4 GegenĂĽberstellung der Szenarien mit den Zielstellungen
5.5 GegenĂĽberstellung der Ergebnisse mit den Kernfragen
5.6 Zusammenfassung der Validieren
6 Zusammenfassung – Ausblick
6.1 Zusammenfassung der Arbeit
6.2 Ausblick und abgeleitete Themen
AbkĂĽrzungsverzeichnis
I State-of-the-Art – Kategorien
II HardwareunterstĂĽtzte Sicherheit fĂĽr eine IT-Plattform
II.1 TrustedPlatformModule
II.2 TechnologiefĂĽrIT-Plattformsicherheit
II.3 Konzept einer hardwarebasierten Vertrauenspolitik
II.3.1 Sichere Mikroarchitektur
II.3.2 Messung statischer Systemeigenschaften
II.4 Kontrollierter Systemstart
II.4.1 Identifizierbarer Plattform-EigentĂĽmer
II.4.2 Versiegeln von Systemwerten(Sealing)
II.5 Konzept der Attestierung
II.5.1 Attestierungs-SchlĂĽssel
II.5.2 Zertifizierung des Attestierungs-IdentifikationsschlĂĽssels
II.5.3 Attestierungs-Modul
II.5.4 Attestierungs-Service
II.5.5 HardwarebasierteGeo-Lokalisierung
III Ăśbersicht der Anforderungen
III.1 Anforderungen an die Cloud-Infrastruktur-Plattform-Ebene
III.2 Anforderungen an die Cloud-Laufzeitebene
III.3 Anforderungen an die Cloud-Service-Ebene
III.4 Anforderungen an operatives Management
III.5 Anforderungen an Cloud-Anwender-Nutzungsebene
IV Spezifikation Ontologi
Beschreibung, Verarbeitung und ĂśberprĂĽfung clientseitiger Policies fĂĽr vertrauenswĂĽrdige Cloud-Anwendungen
Für Geschäftsbereiche mit hohen Anforderungen an Vertraulichkeit und Datenschutz zur Verarbeitung ihrer sensitiven Informationen kann für die Nutzung von Public-Cloud-Technologien keine Benutzerakzeptanz ausgewiesen werden. Die Ursachen dafür erwachsen aus dem inhärenten Strukturkonzept verteilter, begrenzter Verantwortlichkeiten und einem fehlenden Cloud-Anwender-Vertrauen. Die vorliegende Arbeit verfolgt ein Cloud-Anwender orientiertes Vorgehen zur Durchsetzung regelnder Policy-Konzepte, kombiniert mit einem holistischen Ansatz zur Herstellung einer durchgehenden Vertrauensbasis.
Der Aspekt Vertrauen erhält eine eigenständige Konzeptualisierung und wird zu einem Cloud-Anwender-Instrument für die Gestaltung vertrauenswürdiger infrastruktureller Eigenschaften entwickelt. Jede weitere Form einer Policy entwickelt ihren verbindlichen regulierenden Wert erst durch eine unlösliche Verbindung mit den hier vorgelegten Konzepten vertrauenswürdiger Entitäten.
Ein ontologisch formalisierter Beschreibungsansatz vollzieht die für eine Regulierung notwendige Konzeptualisierung einer domänenspezifischen IT-Architektur und qualifizierender Sicherheitseigenschaften. Eigenständige Konzeptklassen für die Regulierung liefern den Beschreibungsrahmen zur Ableitung integrierter Trust-Policies. Darauf aufbauende Domänenmodelle repräsentieren eine vom Cloud-Anwender definierte Erwartung in Bezug auf ein reguliertes Cloud-Architektur-Design und reflektieren die reale Welt auf Grundlage vertrauenswürdiger Fakten. Vertrauen quantifiziert sich im Ergebnis logischer Schlussfolgerungen und ist Ausdruck zugesicherter Cloud-Sicherheitseigenschaften und geregelter Verhaltensformen.:1 Einleitung
1.1 Motivation
1.2 Forschungsfragen
1.3 Zielstellung
1.4 Vorgehensweise
2 Problembeschreibung
2.1 Public Cloud, Strukturerweiterung einer Organisation
2.1.1 Kopplung im sozialen Kontext
2.1.2 Strukturelle Kopplung im Cloud-Kontext
2.2 Regelungen: strukturbildende Elemente von Organisationen
2.2.1 Regelungen im sozialenKontext
2.2.1.1 Rechtliche Regelungen
2.2.1.2 Nichtrechtliche Regelungen
2.2.1.3 Regelungen in Organisationen
2.2.2 Regelungen im Cloud-Kontext
2.3 Erwartungen und Unbestimmtheit von Handlungen
2.3.1 Erwartungen im sozialenKontext
2.3.2 Erwartungen im Cloud-Kontext
2.4 Konformität, Abbildung von Regelungen
2.4.1 Konformität im sozialenKontext
2.4.2 Konformität im Cloud-Kontext
2.5 Thesen
3 Analyse
3.1 Anforderungen
3.1.1 Infrastrukturschicht
3.1.1.1 Hardwarebasierte Geo-Lokalisierung
3.1.1.2 Virtual Machine Monitor
3.1.1.3 Netzwerksicherheit
3.1.2 Plattform-/Laufzeitschicht
3.1.2.1 Virtualisierungstechnologie
3.1.2.2 OS-Sicherheitsmodell
3.1.2.3 Datensicherheit der Laufzeitschicht
3.1.3 Anwendungs-/Serviceschicht
3.1.3.1 Anwendungssicherheit
3.1.3.2 Prozesssicherheit
3.1.3.3 Datensicherheit der Anwendungsschicht
3.1.4 Verwaltung/Betrieb
3.1.5 Compliance
3.1.5.1 Governance
3.1.5.2 Klassifizierte Informationen
3.1.5.3 Datenschutz
3.1.6 Zusammenfassung der Regulierungsziele
3.2 Anwendungsfälle einer Multi-User-Cloud-Umgebung
3.2.1 TCG-Konzepte und Definitionen
3.2.2 UC-Aufbau einer Vertrauensbasis
3.2.3 UC-Aufbau einer vertrauenswĂĽrdigen Kooperationsbasis
3.2.4 UC-kooperative Provisionierung
3.2.5 UC-Änderungen von Regeln innerhalb einer kooperativen Domäne
3.2.6 Abgeleitete Anwendungsfälle aus TCG-Richtlinien
3.3 State-of-the-Art-Betrachtung
3.3.1 Thema:Regulierungsziele
3.3.1.1 Pattern-based Runtime Management of Composite Cloud Applications
3.3.1.2 Unifying Compliance Requirements across Business and IT
3.3.2 Thema:Digitale Regelkonzepte
3.3.2.1 Policy-Aware Provisioning of Cloud Applications
3.3.2.2 Policy-Aware Provisioning and Management of Cloud Applications
3.3.3 Thema:Vertrauenskonzepte
3.3.3.1 Secure Enclaves for REactive Cloud Applications
3.3.3.2 Enforcing-Security-and-Assurance-Properties-in-Cloud-Environment
3.3.4 Thema:Technische Standards
3.3.4.1 WebServicesPolicy1.5 – Framework-Current
3.3.4.2 WS-SecurityPolicy1.3
3.3.4.3 WS-Trust
3.3.4.4 Web Services Security: SOAP Message Security 1.1
3.3.5 Thema:Sprachkonzepte
3.3.5.1 Using Ontologies to Analyze Compliance Requirements of Cloud-BasedProcesses
3.3.5.2 Policy Language for a Pervasive Computing Environment
3.4 Zusammenfassung und Abgrenzungsbeschreibung
4 Konzeption
4.1 Ontologie-Konzept
4.1.1 Strukturentwurf Ontologie
4.1.2 Ziele der ontologischen Konzeptualisierung
4.1.3 Ontologie Regulierung
4.1.3.1 Haupthierachie Regulation-Ontology
4.1.3.2 Konzeptklasse Action
4.1.3.3 Konzeptklasse Constraint
4.1.3.4 Konzeptklasse Rule
4.1.3.5 Konzeptklasse Policy
4.1.3.6 Konzeptklasse State
4.1.3.7 Konzeptklasse Transformation
4.1.4 Ontologie Cloud-Domain
4.1.4.1 Konzeptklasse CloudDomain
4.1.4.2 Konzeptklasse Entity
4.1.4.3 Konzeptklasse Subject
4.1.4.4 Konzeptklasse ArchitecturalLayer
4.1.4.5 Konzeptklasse Object
4.1.4.6 Konzeptklasse Part
4.1.4.7 Konzeptklasse Connection
4.1.4.8 Konzeptklasse CloudService
4.1.5 Ontologie Security
4.1.5.1 Konzept einer vertrauensbildenden Sicherheitsstrategie
4.1.5.2 Konzeptklasse Asset
4.1.5.3 Konzeptklasse PropertySecurity
4.1.5.4 Konzeptklasse SecurityFunction
4.1.5.5 Konzeptklasse SecurityRequirement
4.1.5.6 Konzeptklasse Identity
4.1.5.7 Konzeptklasse Credential
4.1.5.8 Konzeptklasse SecurityModel (Sicherheitsmodell)
4.2 Konzept zur Herausbildung von Vertrauen (Trust)
4.2.1 Konzept einer vertrauenswürdigen Entität
4.2.2 Konzept einer Authority
4.2.2.1 Zusicherung von Entity-Eigenschaften
4.2.2.2 Entitäten innerhalb einer Authority-Hierarchie
4.2.2.3 Entitäten und externe Authority
4.2.3 Konzept einer Policy zur Entwicklung von Vertrauen
4.2.3.1 Spezialisierung der Trust-Policy
4.2.3.2 QualityProperty – Gegenstand der Vertrauenspolitik
4.3 Trust-Establishment-Protokoll
4.3.1 Datenmodell
4.3.1.1 Verhaltensorientierte Artefakte
4.3.1.2 Kryptographische Artefakte
4.3.1.3 Protokollspezifische Artefakte
4.3.2 Horizontale Etablierung von Vertrauen (Establishment of Trust)
4.3.2.1 Phase1: Auswahl einer Cloud-Plattform
4.3.2.2 Phase2: Erweiterung der Vertrauensgrundlage auf Cloud-Anbieter-Seite
4.3.3 Vertikale Etablierung von Vertrauen (Delegation of Trust)
4.3.3.1 Registrierung von Policy-Entitäten
4.3.3.2 Registrierung von Domänen-Entitäten
4.3.3.3 Ableitung vertrauenswürdiger Entitäten
4.3.3.4 Ableitung vertrauenswürdiger Eigenschaften und Aktivitäten
4.4 Zusammenfassung
5 Validierung
5.1 Referenzarchitektur – TrustedCloud
5.1.1 Komponentenbeschreibung – IT-Plattform
5.1.2 Komponentenbeschreibung – Laufzeitumgebung
5.1.3 Komponentenbeschreibung – Integrierte Systeme
5.1.4 ExterneSysteme – Key & CA Service
5.1.4.1 Bezeichnungen und Namespaces
5.1.4.2 TE-Zustandsmodell
5.1.4.3 Policy-Zonen und Policy-Anwendungsraum
5.2 Trust-Policies und Transformation
5.2.1 Szenario (1) – Bereitstellung Virtual Machine Monitor KVM
5.2.1.1 Domain-Spezifikation–KVM-Komponente
5.2.1.2 Regulation-Spezifikation – KVM-Deployment-Policy
5.2.1.3 Prüfung der KVM-Authentizität
5.2.1.4 Zusicherung von KVM-Identitätseigenschaften
5.2.1.5 Transformation – KVM-Trust-Rule
5.2.1.6 Transformation – KVM-Deployment-Rule
5.2.2 Szenario (2) – Bereitstellung Virtualisiertes Betriebssystem
5.2.2.1 Domain-Spezifikation–Virtual-OS
5.2.2.2 Regulation-Spezifikation – Virtual-OS-Deployment-Policy
5.2.2.3 Prüfung der TE-Authentizität
5.2.2.4 Policy-Zone einrichten – Z_RUNTIME.DB
5.2.2.5 Vertrauenskette prüfen – ChainofTrust
5.2.3 Szenario (3) – Bereitstellung Datenbanksystem (DBS)
5.2.3.1 Domain-Spezifikation – Datenbanksystem
5.2.3.2 Regulation-Spezifikation – DBS-Deployment-Policy
5.2.3.3 Prüfung der DBS-Authentizität
5.2.3.4 Transformation – DBS-Trust-Rule
5.2.3.5 Transformation – DBS-Deployment-Rule
5.2.4 Szenario(4) – ExterneDBS-Zugangssteuerung
5.2.4.1 Domain-Spezifikation – User-to-DB Connection
5.2.4.2 Regulation-Spezifikation – DBS-Connection-Policy
5.2.4.3 Prüfung der DBS-Endpunkt-Authentizität
5.2.4.4 Absicherung der DBS-Verbindung – Verschlüsselung
5.2.4.5 Transformation
5.3 Attestierung – Vertrauenswürdigkeit
5.3.1 Dynamische Methoden der Konzeptklasse State
5.3.2 Kategorien fĂĽr Niveaubestimmung von VertrauenswĂĽrdigkeit
5.3.3 Semantische Rules fĂĽr Niveaubestimmung
5.3.3.1 Ableitungsregel – Vertrauenswürdigkeit HOCH
5.3.3.2 Ableitungsregel – Vertrauenswürdigkeit MITTEL
5.3.3.3 Ableitungsregel – Vertrauenswürdigkeit GERING
5.3.3.4 Ableitungsregel – Vertrauenswürdigkeit UNBESTIMMT
5.4 GegenĂĽberstellung der Szenarien mit den Zielstellungen
5.5 GegenĂĽberstellung der Ergebnisse mit den Kernfragen
5.6 Zusammenfassung der Validieren
6 Zusammenfassung – Ausblick
6.1 Zusammenfassung der Arbeit
6.2 Ausblick und abgeleitete Themen
AbkĂĽrzungsverzeichnis
I State-of-the-Art – Kategorien
II HardwareunterstĂĽtzte Sicherheit fĂĽr eine IT-Plattform
II.1 TrustedPlatformModule
II.2 TechnologiefĂĽrIT-Plattformsicherheit
II.3 Konzept einer hardwarebasierten Vertrauenspolitik
II.3.1 Sichere Mikroarchitektur
II.3.2 Messung statischer Systemeigenschaften
II.4 Kontrollierter Systemstart
II.4.1 Identifizierbarer Plattform-EigentĂĽmer
II.4.2 Versiegeln von Systemwerten(Sealing)
II.5 Konzept der Attestierung
II.5.1 Attestierungs-SchlĂĽssel
II.5.2 Zertifizierung des Attestierungs-IdentifikationsschlĂĽssels
II.5.3 Attestierungs-Modul
II.5.4 Attestierungs-Service
II.5.5 HardwarebasierteGeo-Lokalisierung
III Ăśbersicht der Anforderungen
III.1 Anforderungen an die Cloud-Infrastruktur-Plattform-Ebene
III.2 Anforderungen an die Cloud-Laufzeitebene
III.3 Anforderungen an die Cloud-Service-Ebene
III.4 Anforderungen an operatives Management
III.5 Anforderungen an Cloud-Anwender-Nutzungsebene
IV Spezifikation Ontologi