Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 46

Sichere Speicherung kritischer Daten in der Cloud

0

Share

Download to read offline

heise devSec(), Oktober 2020, online: Vortrag von Andreas Zitzelsberger (@andreasz82, Chief Software Architect bei QAware)

== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==

Abstract: Sichere Speicherung kritischer Daten in der Cloud
Die Speicherung und Verarbeitung kritischer Daten wie Gesundheitsdaten in der Cloud ist komplex. Nicht nur regulatorische Anforderungen, auch die geänderte Bedrohungslage in der Cloud sind Herausforderungen für Architektur und Technik.

Sichere Speicherung kritischer Daten in der Cloud

  1. 1. heise devSec 2020 Andreas Zitzelsberger andreas.zitzelsberger@qaware.de @andreasz82 Sichere Speicherung kritischer Daten in der Cloud
  2. 2. 1. Einführung 2. Grundlegende Prinzipien 3. Bausteine 4. Architektur 5. Fazit
  3. 3. Ziele ● Rechtlichen Rahmen einhalten ● Risiken vermeiden ○ Finanzielle Schäden ○ Reputationsschäden ○ Schäden für Kunden und Nutzer ● Berufsethik & Handwerksstolz Vertraulichkeit Integrität Verfügbarkeit
  4. 4. Der gesetzliche Rahmen ● GDPR / DSGVO: Schutz personenbezogener Daten ● § 203 StGB: Verletzung von Privatgeheimnissen ● BaFin VAIT: Versicherungsaufsichtliche Anforderungen an die IT ● KRITIS (§8a BSIG): "Kritische Infrastrukturen" ● § 147 AO: Ordnungsvorschriften für die Aufbewahrung von Unterlagen Quelle: https://www.gettyimages.de/detail/foto/gavel-with-paragraph-symbol-lizenzfreies-bild/594484392
  5. 5. Wichtige Regelwerke Kataloge: ● BSI IT-Grundschutz ● BSI Cloud Computing C5 (Cloud Computing Compliance Criteria Catalogue) ● BSI TR-03161 (Sicherheitsanforderungen an digitale Gesundheitsanwendungen) Normen: ● ISO 27001 (Informationssicherheits-Managementsystem ISMS) ● SOC 2 (System and Organization Controls) ● PCI DSS (Payment Card Industry Data Security Standard)
  6. 6. Was ist in der Cloud anders? Quellle: https://www.gettyimages.de/detail/illustration/antique-illustration-of-angel-playing-trumpets-lizenfreie-illustration/499747058
  7. 7. Quelle: https://devrant.com/rants/898940/someday-i-will-answer-this-question-to-my-kids
  8. 8. Cloud Native Landscape 2016
  9. 9. Cloud Native Landscape 2020
  10. 10. Der Verantwortungsschnitt IaaS CaaS SaaS PaaS Anwendungen Verantwortung: ProviderVerantwortung: Consumer
  11. 11. Was ist in der Cloud anders? ● "Intern" ist nicht wirklich intern ● Geteilte Verantwortung ● Weniger Kontrolle über die Implementierung ● Mehr Komplexität, mehr bewegliche Teile ● Neue Möglichkeiten Fehler zu machen ● Rechtliche Lage
  12. 12. Grundlegende Prinzipien
  13. 13. 0-Trust als datenzentrierter Sicherheitsansatz ● Vertraue niemandem, verifiziere jeden: Keinem Nutzer, Gerät oder Dienst ● 0-Trust ist der Gegensatz zu klassischen "Trusted Network" - Ansätzen ● Verhindert effektiv Lateralbewegungen von Angreifern und erschwert Innentaten ● Cloud Native Computing ist ein Enabler für 0-Trust 0-Trust als datenzentrierter Sicherheitsansatz passt sehr gut auf die Bedrohungslage in Cloud-Umgebungen und datenschutzgetriebene Anforderungen.
  14. 14. Least Privileges Quelle: https://xkcd.com/149/
  15. 15. Minimale Kritikalität Reduktion der Kritikalität der Daten durch: ● Aggregation ● Filterung ● Redaktion ● Anonymisierung Beispiel k-Anonymity: Daten eines Individuums sind von mindestens k-1 anderen Individuen ununterscheidbar. Quellle: https://www.gettyimages.de/detail/foto/bomb-disposal-concept-3d-rendering-isolated-on-white-lizenzfreies-bild/1266169565?
  16. 16. Minimale Kritikalität Bei Verfügbarkeit lohnt es sich zu fragen: ● Inwieweit ist das System datenführend? ● Wie gut muss die Verfügbarkeit sein? ● Wie viel bin ich bereit auszugeben um welche Art von Katastrophe abzuwehren? Quelle: https://commons.wikimedia.org/wiki/File:Lord_White_Elephant.jpg Die Multi-hybrid-Cloud
  17. 17. Defense-in-Depth Bildquelle: https://www.gettyimages.de/detail/foto/walls-of-istanbul-lizenzfreies-bild/155258807
  18. 18. Defense-in-Depth ist die Reaktion auf das Swiss Cheese Model Quelle: https://commons.wikimedia.org/wiki/File:Swiss_cheese_model_of_accident_causation.png
  19. 19. Qualität als Grundhaltung
  20. 20. Bausteine
  21. 21. Verschlüsselung ● AWS, Azure, GCP bieten Verschlüsselung at-Rest und in-Transit für Block Storage und vom Provider betriebene SaaS-Datenbanken an. ● Bei Services von Dritten ist besondere Vorsicht bei Storage und interner Kommunikation notwendig. ● Ingresse unterstützen TLS (Nginx oder Plattform-Ingress), optional mit ACME/RFC 8555. ● Die Kommunikation in Anwendungs-Clustern ist nicht automatisch verschlüsselt ( → Service Mesh).
  22. 22. Service Meshes Quelle: https://istio.io/latest/docs/ops/deployment/architecture/
  23. 23. Service Meshes lösen querschnittliche Probleme ● Service-Identität, Authentifizierung und Autorisierung ● Microzoning mit Policies: Nur erlaubte Kommunikationspfade sind möglich ● Verschlüsselung in-transit ● Monitoring & Logging Shortlist: ● Istio ● Consul ● Linkerd (Eingeschränktes Feature Set, dafür sehr einfach)
  24. 24. OpenId Connect ● Idenditätsschicht auf Basis OAuth2 ● Eignet sich für Nutzer- und Service-Authentifizierung ● Autorisierung nicht im Scope des Standards, aber möglich mit ○ Scopes ○ Claims, z.B. roles-Claim ○ Lösung von außen (z.B. Open Policy Agent) { "sub" : "some-user", "iss" : "https://some-iam" , "aud" : "some-client", "nonce" : "123", "iat" : 1602171028, "exp" : 1602171088 }
  25. 25. Delegationsmuster: Token Re-Use API 1 API 2 ● Einfach ● OK wenn API 1 keine Sicherheitswirkung hat
  26. 26. Lorem ipsum dolor sit amet, consetetur sadipscing Delegationsmuster: M2M-Authentifizierung API 1 API 2 ● M2M-Token sichert Kommunikation ab ● Typisch mit dem Client Credentials Flow ● Nutzerauthentifizierung und on-behalf-Erlaubnis von API 1 ist für API 2 nicht nachvollziehbar. X-User-Id: Erika Mustermann Token Service
  27. 27. ● M2M-Token attestiert Nutzer-Identität und on-behalf-Erlaubnis von API 1 ● 🚧 RFC 8693 ist noch nicht breit unterstützt Lorem ipsum dolor sit amet, consetetur sadipscing Delegationsmuster: Token Exchange (RFC 8693) API 1 API 2 Token Service
  28. 28. GitOps vermeidet administrative Zugriffe Build Image Registry Application Repositories Deploy Push PR w. 4 eyes Configuration Repository Admission Control https://www.openpolicyagent.org/
  29. 29. Architektur
  30. 30. Problem: Security oder Legal lassen mich meine Daten nicht in der Public Cloud halten. Lösung: Daten bleiben on-premise, Compute geht in die Cloud. 🤨
  31. 31. Datenhaltung on-premise, Compute in der Cloud ⚠ Latenz ⚠ Komplexität ⚠ Kosten Aber: Kann eine legitime Abkürzung für den ersten Schritt sein, um Vertrauen aufzubauen! Quelle: https://commons.wikimedia.org/wiki/File:Royal_Ontario_Museum_(9674325453).jpg
  32. 32. Problem: Wie kann ich die Daten meiner Mandanten in der Public Cloud trennen? Lösung: Muss individuell entschieden werden.
  33. 33. Mandantentrennung in der Public Cloud ● Provider-Accounts ● Netzwerk: ○ Service Meshes mit Policy ○ Kubernetes Namespaces / Network Policies ○ VPCs & Security Groups ● Storage: ○ Dedizierter Storage pro Mandat ist mit Infrastructure-as-Code handhabbar ● Compute: ○ Anwendung ○ Container ○ VMs ○ Hardware Anwendung Infrastruktur Kriterien: ● Elastizität ● Flexibilität ● Komplexität ● Bestehende Infrastruktur und Prozesse ● User Experience ● Sonstige Maßnahmen
  34. 34. Problem: Was tun mit überbreiten Schnittstellen? DBs mit Service-Authentifizierung erlauben Zugriff auf die Daten aller Nutzer. Lösung: Data Clearing House ● Einführung einer zusätzlichen Komponente, die die Filterung übernimmt ● Benötigt Nutzer/Service-Authentifizierung
  35. 35. Data Clearing House Beispiel: Sachbearbeiter in einer Versicherung Clearing HouseAgent Service getManagedClaims(agentId) getInsurees(agentId) ... DB [ insureeId, idc10Code, claimAmount,... ] Policy-gesteuerte Freigabe von Daten: Filterung, Redaktion, Anonymisierung, Aggregation
  36. 36. Problem: Wie kann die Aufbewahrung von Daten nachvollziehbar gesteuert werden? Wie können auch komplexere Policies umgesetzt werden? Lösung: Retention Controller ● Kann Retention an mehreren Orten kontrollieren ● Trennung von Daten und Policy mit dem Open Policy Agent
  37. 37. Retention Controller Data Service Retention Controller getMetadata delete Retention PolicyDB Scheduler startet Notification Service Stellt Löschbescheinigungen aus Audit Log liest isExpired { dataSet.expirationDate < today(); allClaimsSettled(dataSet); isReportedOn(dataSet); }
  38. 38. Problem: Event Sourcing mit kritischen Daten ● Event Store müsste bei einer Löschanfrage bearbeitet werden ● Zugriffskontrolle auf Messages ist schwierig ● Notwendige synchrone Garantien widersprechen den Charakter von Messages / Events Lösung: Lightweight Forgetful Event Sourcing
  39. 39. Lightweight Forgetful Event Sourcing Dataset ID User ID Processing Purpose Other Metadata ... Event Lightweight: Events enthalten nur Metadaten und einen Pointer zu den unveränderlichen Nutzdaten Forgetful: Die Nutzdaten können gelöscht werden, z.B. wenn der Grund für die Verarbeitung entfallen ist Konsumenten müssen damit umgehen können, dass Daten möglicherweise nicht mehr da sind Storage
  40. 40. Problem: Wie kann ich Produzenten / Konsumenten in der Datenlogistik trennen? Wie kann ich nachhaltig Verwendungszwecke durchsetzen? Lösung: Kryptographische Trennung auf Anwendungsebene
  41. 41. Asymmetrische Verschlüsselung Producer {1} Consumer {*} Orchestrator Public Keys Private Keys (1) Verschlüssele Daten mit öffentlichen Schlüsseln (2) Schreibe verschlüsselte Daten, Metadaten, Signatur (3) Lese und entschlüssle Daten mit dem privaten Schlüssel Medium DB, Storage, Message Broker, ...
  42. 42. Kryptographische Löschung Producer {1} Consumer {*} Orchestrator Public Keys Private Keys (1) Erzeuge Sitzungsschlüssel und verschlüssele mit öffentlichen Schlüsseln (4) Entschlüssele Sitzungsschlüssel mit dem Private Key (5) Lese und entschlüssle Daten (6) Vergesse Sitzungsschlüssel (2) Schreibe verschlüsselte Daten, Metadaten, Signatur, geschützten Sitzungsschlüssel (3) Vergesse Sitzungsschlüssel Medium DB, Storage, Message Broker, ... Verwendungszweck → Schlüsselpaar Forderung: Datensätze sind immutable
  43. 43. Kryptographische Trennung Producer {1} Consumer {*} Orchestrator Key Escrow Public Keys Private Keys (1) Erzeuge Sitzungsschlüssel und verschlüssele mit öffentlichen Schlüsseln (2) Upload des geschützten Sitzungsschlüssels in den Key Escrow (5) Hole den geschützte Sitzungsschlüssel aus dem Key Escrow (6) Entschlüssele Sitzungsschlüssel mit dem Private Key (3) Schreibe verschlüsselte Daten, Metadaten, Signatur (4) Vergesse Sitzungsschlüssel Medium DB, Storage, Message Broker, ... (7) Lese und entschlüssle Daten Zugriffsschutz nach Services
  44. 44. Fazit
  45. 45. Fazit ● Der hohe Grad an Automatisierung und moderne Komponenten machen es einfach in der Public Cloud ein gutes Sicherheitsniveau für kritische Daten zu erreichen. ● Die geteilte Verantwortung und rechtlichen Aspekte muss man angstfrei beachten. ● Die Schnittstellen Recht - Security - Technik und Erfahrung mit und Vertrauen in moderne Technik und Konzepte sind erfolgskritisch.
  46. 46. Vielen Dank! andreas.zitzelsberger@qaware.de @andreasz82

×