zurück zur Übersicht

Anwendungen entwickeln in der Cloud: schneller und trotzdem sicher

Einführung

Immer mehr Anwendungen werden in der Cloud betrieben. In der Regel bedeutet das, dass der ganze Lebenszyklus einer Anwendung in der Cloud erfolgt – die Anwendung wird schon in der Cloud entwickelt, getestet, deployed und betrieben.

Die minimale technische Anforderung, um dies zu realisieren ist, einen IaaS (Infrastructure as a Service) Cloud-Anbieter wie Amazon oder Microsoft auszuwählen.

Dann muss noch die Entscheidung getroffen werden, welche Hardware Resourcen für die Anwendung ausreichend sind. Eine IaaS Plattform hat in der Regel wenig Einsicht in den Applikationskontext und kann unerwarteten Events wie Runtime-Probleme nur begrenzt entgegenwirken und auf Anomalien in den Anwendungslogs meist nicht entsprechend reagieren.

Die PaaS (Platform as a Service) Lösungen für Cloud Anwendungen helfen dabei, den SDLC (Software Development Lifecycle) zu vereinfachen und zu beschleunigen, indem sie Support für Container, diverse Frameworks, Datenbanken, Programmiersprachen und den Anwendungsbetrieb anbieten. Beispiele wären die Pivotal Cloud Foundry oder RedHat OpenShift Container Platform. Obwohl die PaaS mittlerweile über gute Sicherheitsmaßnahmen wie Segmentierung oder Credential Vaults verfügen, wird in der Praxis manchmal eine übergreifende und flexible Lösung benötigt, die auch weitere vorgegebene, zentrale Sicherheitsrichtlinien erfüllt.

Umgebungscharakteristik

In den nächsten Absätzen werden wir uns mit gängigen Herausforderungen und Lösungen bei dem Design der Cloud-Anwendungen befassen. Zuerst also einige der wichtigsten Eigenschaften einer Cloud-Architektur:

  • Service-Oriented-Architecture (SOA)
    Die Komponenten werden nicht mehr monolithisch auf einem Host deployed, sondern agieren als unabhängige, heterogene Anwendungseinheiten, die über das Netzwerk meistens mittels REST API oder SOAP Web Services kommunizieren. Dies ermöglicht Flexibilität und Entkoppelung, führt aber auch zu Abhängigkeit von der Konnektivität.
  • Komponenten mit unterschiedlichem Schutzbedarf
    In der Cloud könnten theoretisch ein Service für GUI und ein Service, der personenbezogene Daten verarbeiten, nebeneinander verortet werden und direkt kommunizieren. Aus Perspektive der Sicherheit wäre das eher suboptimal (besonders auch im Hinblick auf die demnächst geltenden europäischen Regeln für Datenschutz, Stichwort GDPR) . Ein weiterer Aspekt ist, dass manche Services eigentlich überhaupt nicht nach außen exponiert werden sollten.
  • Automatisierung ist Trumpf
    Die Entwickler und Operatoren streben danach, Testing, Deployment und Betrieb der Anwendungen zu automatisieren. Die Tools wie der Build-Server, diverse Plugins, Testing- und Kommunikationstools helfen riesig dabei, den Anwendungsprozess bis zum Deployment zu beschleunigen.

Lösungsansätze

Bei dieser Charakteristik stellen sich aus dem Aspekt der Informationssicherheit die folgenden Fragen:

  • Vertraulichkeit: Wie schützen wir die vertraulichen Daten auf dem Transportweg und am Speicherort?
  • Integrität: Wie können wir Datenintegrität gewährleisten?
  • Verfügbarkeit: Was hilft uns, die Verfügbarkeit der Anwendung sicherzustellen?
  • Authentifizierung: Wie erkennen wir einen Benutzer, eine Anwendung und deren Komponenten?
  • Autorisierung: Wie und anhand welcher Kriterien wird die Berechtigung zum Zugriff auf Ressourcen geprüft?

1. Vertraulichkeit

Vertraulichkeit der sensitiven Daten in der Public Cloud hat eine enorme Priorität. Es müssen vor allem personenbezogene, §203-relevante und andere firmenbezogene Daten geschützt werden. Verschlüsselung bei Datenübertragung mittels TLS oder IPSec ist hier Pflicht.

Eine grundlegende Entscheidung mit vielen Auswirkungen: Dürfen die sensitiven Daten in der Cloud permanent vorrätig gehalten werden? Falls ja, dann wahrscheinlich nur in der verschlüsselten Form. Das zeiht weitere die Herausforderungen mit dem Schlüssel-Management nach sich. Wird dabei jedes Anwendungsteam seine eigene Lösung betreiben? Und wo werden die Schlüssel gespeichert? Eine Möglichkeit wäre, die Schlüssel, Keystores und Passwörter an einem zentralisierten Ort zu halten. Dabei ist gleichzeitig die Latenz, Komplexität und das Risiko von Single-Point-Of-Failure zu beachten.

2. Integrität

In diesem Bereich muss gewährleistet werden, dass die gesendeten Daten von dem Aufrufer und die empfangenen Daten bei dem Aufrufenden identisch sind. TLS, IPsec oder eigenes Signieren von z.B. Tokens kann hier eine Lösung sein.

3. Verfügbarkeit

Dass die Infrastruktur in der Cloud und die Plattform skalierbar ist und über Hochverfügbarkeitsmechanismen verfügt, bedeutet noch nicht, dass die Anwendung nicht gegen Massenangriffe (wie DDoS, z.B durch Botnetze) geschützt werden muss. Je früher in der Aufrufkette die Maßnahmen zur Verfügung stehen, desto besser. Drosselung der Requests durch die Frontend API und/oder Umsetzung von Captcha sind die Ansätze auf Layer 6-7. Auf dem Netzwerklayer gibt es auch gute Ansätze, ungewöhnlich erhöhten Verkehr zu drosseln.

4. Authentifizierung

Unter Authentifizierung verstehen wir, dass nach der erfolgreichen Benutzeranmeldung jeder Service versteht, in welchem Benutzerkontext er aufgerufen wurde. Diese Information kann bei dem Autorisierungscheck zur Identifikation des Benutzers verwendet werden. Diese und weitere anwendungsspezifische Informationen werden in der Regel in einem JWT (JSON Web Token) Token gespeichert. Der Token wird von dem Aussteller (Authenticator oder ein dedizierter Service) signiert und wird unverändert vom Anfang der Aufrufkette bis zu dem letzten aufgerufenen Service (z.B. Backend) zur Validierung präsentiert.

Auf Service-Ebene sollten nicht beliebige externe Services kommunizieren. Jeder Aufrufer sollte prinzipiell als nicht vertrauenswürdig angesehen werden. Sonst könnte eine von außen kompromittierte Komponente ganz einfach lateral weitere Schäden anrichten. Problematisch ist, wenn auf dem Netzwerklayer eine Freischaltung nicht granular genug möglich ist  –  wenn z.B. zwei Pods kommunizieren dürfen, nicht aber jeder Container des Pods. Da die Kommunikation in der Regel auf TLS basiert, eignen sich TLS Zertifikate hervorragend. Jeder Service kann sich mit eigenem Client-TLS Zertifikat ausweisen, der in einer Access Control List von dem Empfänger geprüft werden muss. Selbstverständlich prüft der Client auch das Server-TLS Zertifikat. Erst dann kann die Kommunikation anfangen.

5. Autorisierung

Autorisierung ist ein weiteres wichtiges Merkmal der Benutzersteuerung und basiert auf den Informationen der Identifizierungs-/Authentifizierungsphase.

Bei jedem Aufruf der Ressource können die Berechtigungen anhand des JWT Tokens geprüft werden. Ein anderer Ansatz wäre, den Berechtigungscheck am Anfang der Session durchzuführen und den Zugang zu der Ressource mittels JWT Access Tokens kurzfristig zu erlauben. Im Vergleich zu der Authentifizierung kann sich die Berechtigung während der Session verändern. Deswegen wird ein Mechanismus gebraucht, der den aktuellen Token invalidiert und die neuen Änderungen in einem neuen Token darstellt.

Fazit

Bevor angefangen wird, in der Cloud neue Anwendungen zu entwickeln, sollten die grundlegenden Sicherheitsprinzipien geklärt werden. Eine Strategie muss festegelegt und an alle Teams kommuniziert werden. Dass diese sich mit der Zeit entwickelt und granularer wird, ist zu erwarten, denn die technischen, rechtlichen und organisatorischen Umstände entwickeln sich auch.

Die Umsetzung der Sicherheitsstrategie sollte auf den konzeptuellen Maßnahmen basieren. Erst dann kann man wirklich evaluieren, ob die Implementierung durch eigene Technologienressourcen oder externe Mittel erfolgt.

 


Weitere Links:

https://www.darkreading.com/endpoint/rethinking-application-security-with-microservices-architectures-/a/d-id/1325155?

http://www.techrepublic.com/article/10-tips-for-securing-microservice-architecture/

https://medium.facilelogin.com/securing-microservices-with-oauth-2-0-jwt-and-xacml-d03770a9a838

 

 

Schreibe einen Kommentar