INFORMATION SECURITY

Public / Hybrid Cloud Security

Im Gegensatz zu Vorläufern wie SBC/Thin Clients oder SOA lassen sich Public Clouds durch folgende Attribute definieren:

Cloud Dienste werden in diverse Service Delivery Modelle unterteilt (SPI):

Als Cloud Deployment Modelle kommen Public Clouds, Private Clouds sowie Hybrid Clouds zum Einsatz: Public Clouds sind im Internet angesiedelt, Private Clouds innerhalb von Corporate Networks und Hybrid Clouds bestehen aus einer Virtual Private Cloud (VPC, bei einem Cloud Provider) und einem VPN-Tunnel zwischen Corporate Network und VPC.

Verteilte Governance in der Cloud

Innerhalb ihres Corporate Network (on-premises) kontrolliert eine Firma alle Technologieebenen, siehe folgende Tabelle. In Abhängigkeit vom Service Delivery Modell werden allerdings beim Cloud Computing bestimmte Ebenen vom Cloud Service Provider (IaaS, PaaS, BaaS, SaaS) kontrolliert:

Obwohl die CSP Kontrolle beim Übergang von IaaS bis zu SaaS wächst, verbleibt die Verantwortung bei der Cloud nutzenden Firma. Daher ist es für die Firma erforderlich, das gewählte Cloud Service Delivery Modell bzgl. SLA und Contract zu überwachen.

Infrastructure Security: Network Level

In Public Clouds verlagert sich die Verantwortung für die Sicherheit der Network Infrastructure auf den CSP, daher ist ein Assessment der CSP Network Security Massnahmen unabdingbar. Ferner ist ein Security Design der Netzkommunikation zwischen dem firmeneigenen CN und der CSP Netzwerk Topologie erforderlich. Primäre Security Massnahmen sind:

Infrastructure Security: Host Level

Aus Sicht des Security Managements führt die on-demand Charakteristik einer Public Cloud zu neuen operativen Herausforderungen und damit zu neuen Risiken. Das Operationsmodell fördert Rapid Provisioning und VM Instanzierung hoher Fluktuation; Damit wird ein adäquates Patch Management erheblich komplexer und sicherheitsanfälliger als in einem klassischen Data Center.

Es obliegt dem Kunden, die Abgrenzung (Trust Boundary) zwischen seinem Verantwortungsbereich und dem des CSP zu erkennen, um die Host Infrastruktur zu sichern. Diese Trust Boundary wird durch das Service Delivery Modell bestimmt.

SaaS und PaaS Host Security

In der Regel veröffentlichen CSPs Informationen über Host Plattform, Betriebssystem und Host Security Prozesse nicht. Beim SaaS Modell ist damit die Host Security für den Kunden nicht analysierbar und sollte entweder via NDA offengelegt oder über ein Control Framework wie ISO 27002 bewertet werden. Der CSP muss sicherstellen, dass adäquate Preventive- und Forensic Controls für die Host Security installiert sind und betrieben werden.

Während bei SaaS der Host Abstraction Layer für den Kunden nicht sichtbar ist, erhalten PaaS User mittel PaaS Application Programming Interface (API) indirekten Zugang.

SaaS und PaaS Kunden verbleiben in der Verantwortung für das Risiko, dem das Information Management in der Cloud unterliegt. Da der CSP die SaaS/PaaS Host Security handelt, ist der Kunde gefordert, den notwendigen Host Security Assurance Level vom CSP einzufordern.

IaaS Host Security

IaaS Kunden sind für die Host Security primär selbst zuständig. Diese Host Security umfasst zwei Komponenten:

Infrastructure Security: Application Level

Folgende Application Level Angriffsvektoren bringen es regelmä.ssig auf die OWASP Top 10 Application Vulnerabilities Liste: Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Security Misconfiguration, Failure to Restrict URL Access, Unvalidated Redirects & Forwards sowie Broken Session Management.

In einem streng kontrollierten CN besteht ein best-practice Web Application Security Approach in einer Kombination aus DMZ Separation und Network- sowie Host basiertem Access Control. Web Applications für ein SPI Cloud Delivery Modell hingegen benötigen ein Anwendungsdesign für einen Internet Threat Background, d.h., Security muss integraler Teil des Software Development Life Cycle (SDLC) sein.

Geringe Cloud Computing Eintrittshürden für KMUs dürften von Hackern missbraucht werden. Über kompromittierte Cloud Accounts werden maliziöse Nutzer massive Computing Resourcen allokieren und damit aus IaaS oder PaaS Clouds heraus Angriffe gegen andere Cloud Applications starten.

SaaS Application Security

Ein SaaS CSP ist für die Security des gesamten Application Stack verantwortlich. Der Kunde übernimmt die Verantwortung nur für vom CSP bereitgestellten operativen Security Funktionen wie User- und Access Management. Allerdings sollte der Kunde -schon wegen regulatorischer Compliance- mittels NDA vom CSP Informationen über die verwendeten Security Practices des Providers (Architecture, Design, Security Patchmanagement, Monitoring, Incident Handling, etc.) einfordern. Da bei PaaS dem Kunden nur Authentication und Privilege Management zum Schutz seiner Daten zur verfügung stehen, sollten diese Controls intensiv genutzt und überwacht werden.

SaaS CSPs speichern die Daten ihrer Kunden in der Regel in einem shared Virtual Datastore und verwenden lediglich Data Tagging für die Isolation der Daten verschiedener Kunden. Damit beruht die Sicherheit der SaaS Daten einer Firma auf der Sicherheit der SaaS Application Software, die das Firmen Tag interpretiert. Deshalb sollte der Kunde vom CSP Informationen über die Sicherheit des Virtual Datastore und die präventiven Massnahmen zum Schutz des Taggings einfordern.

PaaS Application Security

Eine PaaS Cloud bietet ein integriertes Environment für Design, Entwicklung, Test und Deployment von Applications für bestimmte Programmiersprachen. Der PaaS CSP ist für die Sicherheit des Platform Software Stack verantwortlich, der auch die Runtime Engine umfasst, auf dem Kunden Applications laufen. Die zentrale Security Anforderung des Kunden besteht in der Abschirmung seiner Anwendungen von denen andere Kunden. Dies muss die Runtime Engine über eine Kunden "Sandbox" sicherstellen.

Ein PaaS Application Developer ist mit einer Provider-spezifischen API für Deployment und Maintenance von Software Modulen konfrontiert. Diese API umfasst auch Platform-spezifische Security Funktionen für die Konfiguration von Authentication- und Authorization Controls, SSO Federation, SSL/TLS Support, etc. der Application. Da es aber keinen Standard für PaaS APIs gibt, ist jede CSP API proprietär und das macht sowohl ein Provider Lock-in als auch nicht entdeckte Security Vulnerabilities wahrscheinlich.

IaaS Application Security

Aus IaaS CSP Sicht stellen sich Applications auf Kunden VMs als Black-Box dar. Der gesamte Software Stack -Applications, Runtime (J2EE, .NET, Ruby on Rails, PHP, etc.), Middleware- läuft auf Kunden VMs und untersteht der alleinigen Verantwortung des Kunden. Eine IaaS Application ähnelt einer herkömmlichen Corporate Web Application mit n-Tier verteilter Architektur. Es gibt aber einen entscheidenden Unterschied: Während im CN viele Security Controls zur Sicherung der verteilten Hosts und ihrer Kommunikationsverbindungen installiert sind, existieren solche Controls a priori in einer IaaS Cloud nicht. Das heisst, der Kunde muss solche Controls mittels Network Separation, User Access und Application Level Controls in der IaaS Cloud selbst implementieren - das kann bis zur Installation von kundeneigener Virtual Firewall Software gehen.

Data Security

Verglichen mit einer Corporate Network Infrastruktur erhält die Data Security in SaaS, PaaS und IaaS Umgebungen eine erheblich grössere Bedeutung. Die Datensicherheit tangieren:

Beim Netztransit besteht das grösste Risiko für Daten im Verzicht auf Verschlüsselung und Integritätsschutz.

IaaS CSPs bieten üblicherweise mit ihren Storage Optionen auch Verschlüsselung an, z.B. Amazon S3. PaaS und SaaS CSPs hingegen bieten in der Regel keine Verschlüsselung von Data-at-Rest, da eine Verschüsselung Services wie Indexing und Searching behindern würde, diese Dienste aber infolge der gemeinsamen Speicherung in massiven Datastores des Providers notwendig sind.

Bei dem Processing der Daten müssen die Daten bis heute unverschlüsselt vorliegen. Gegenwärtig gibt es noch keine marktreife Lösung des Data Processings ohne vorheriges Entschlüsseln.

Für bestimmte Audit- bzw. Compliance Anforderungen ist es notwendig zu registrieren, auf welchem Server bzw. Store und zu welcher Zeit sich die Daten befunden haben. Dieses Data Lineage (Data Flow Monitoring) ist in einem Corporate Network bereits sehr aufwendig, in einer Public Cloud aber nicht mehr möglich.

Für manche Kunden wie z.B. Financial Markets ist der Nachweis der Datenintegrität allein nicht hinreichend. Diese Kunden benötigen zusätzlich die Sicherheit, dass die Berechnung der Daten selbst korrekt verlief. In einer Public Cloud erlangt der Kunde aber keine physische oder logische Kontrolle über die Systeme oder die Option eines Status Trackings der Systeme. Damit ist in einer Cloud der Nachweis der Computational Accuracy nicht möglich.

Werden Daten formell gelöscht bleiben in der Regel Spuren der Daten erhalten. Das kann an dem Betriebssystem liegen, das Daten nicht wirklich löscht sondern lediglich 'freigibt' oder auch an physischen Eigenschaften der Speichermedien. Diese Datenrelikte können dann zu potentiellen Information Leaks sensitiver Kundendaten führen. Deshalb sollten Kunden ihre CSPs per SLA auf Media Sanitization Standards verpflichten.

Betrachtet man die ungelösten Data Security Fragen stellt sich für prospektive Cloud Kunden die Frage, welche Firmendaten einer Public Cloud anvertraut werden können. Um Audit- bzw. Compliance Findings vorzubeugen, ist eine systematische Datenklassifizierung -vor der Nutzung von Public Clouds- ratsam.

Datenschutz (Data Privacy)

Ein geringfügiger Bruch des Datenschutzes kann beträchtliche finanzielle Schäden nach sich ziehen (Kosten der forensischen Analyse, Strafgelder, etc.), von den immateriellen Kosten wie negativer Publicity gar nicht zu reden. Zentrale Datenschutz Fragestellungen in einer Public Cloud betreffen: