SlideShare ist ein Scribd-Unternehmen logo
1 von 46
Downloaden Sie, um offline zu lesen
heise devSec 2020
Andreas Zitzelsberger
andreas.zitzelsberger@qaware.de
@andreasz82
Sichere Speicherung kritischer
Daten in der Cloud
1. Einführung
2. Grundlegende Prinzipien
3. Bausteine
4. Architektur
5. Fazit
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
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
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)
Was ist in der Cloud anders?
Quellle: https://www.gettyimages.de/detail/illustration/antique-illustration-of-angel-playing-trumpets-lizenfreie-illustration/499747058
Quelle: https://devrant.com/rants/898940/someday-i-will-answer-this-question-to-my-kids
Cloud Native Landscape 2016
Cloud Native Landscape 2020
Der Verantwortungsschnitt
IaaS
CaaS
SaaS
PaaS
Anwendungen
Verantwortung: ProviderVerantwortung: Consumer
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
Grundlegende Prinzipien
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.
Least Privileges
Quelle: https://xkcd.com/149/
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?
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
Defense-in-Depth
Bildquelle: https://www.gettyimages.de/detail/foto/walls-of-istanbul-lizenzfreies-bild/155258807
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
Qualität als Grundhaltung
Bausteine
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).
Service Meshes
Quelle: https://istio.io/latest/docs/ops/deployment/architecture/
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)
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
}
Delegationsmuster: Token Re-Use
API 1 API 2
● Einfach
● OK wenn API 1 keine Sicherheitswirkung hat
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
● 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
GitOps vermeidet administrative Zugriffe
Build
Image
Registry
Application
Repositories
Deploy
Push
PR w. 4
eyes
Configuration
Repository Admission
Control
https://www.openpolicyagent.org/
Architektur
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.
🤨
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
Problem: Wie kann ich die Daten meiner Mandanten in der Public Cloud trennen?
Lösung: Muss individuell entschieden werden.
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
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
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
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
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);
}
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
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
Problem: Wie kann ich Produzenten / Konsumenten in der Datenlogistik trennen?
Wie kann ich nachhaltig Verwendungszwecke durchsetzen?
Lösung: Kryptographische Trennung auf Anwendungsebene
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, ...
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
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
Fazit
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.
Vielen Dank!
andreas.zitzelsberger@qaware.de
@andreasz82

Weitere ähnliche Inhalte

Mehr von QAware GmbH

Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo QAware GmbH
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...QAware GmbH
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster QAware GmbH
 
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.QAware GmbH
 
Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!QAware GmbH
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s AutoscalingQAware GmbH
 
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAPKontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAPQAware GmbH
 
Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.QAware GmbH
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s AutoscalingQAware GmbH
 
Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.QAware GmbH
 
Per Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysPer Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysQAware GmbH
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster QAware GmbH
 
How to speed up Spring Integration Tests
How to speed up Spring Integration TestsHow to speed up Spring Integration Tests
How to speed up Spring Integration TestsQAware GmbH
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-ClusterAus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-ClusterQAware GmbH
 
Cloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniertCloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniertQAware GmbH
 
Policy Driven Microservices mit Open Policy Agent
Policy Driven Microservices mit Open Policy AgentPolicy Driven Microservices mit Open Policy Agent
Policy Driven Microservices mit Open Policy AgentQAware GmbH
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringQAware GmbH
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisQAware GmbH
 
Die nächsten 100 Microservices
Die nächsten 100 MicroservicesDie nächsten 100 Microservices
Die nächsten 100 MicroservicesQAware GmbH
 
Enterprise-level Kubernetes Security mit Open Source Tools - geht das?
Enterprise-level Kubernetes Security mit Open Source Tools - geht das?Enterprise-level Kubernetes Security mit Open Source Tools - geht das?
Enterprise-level Kubernetes Security mit Open Source Tools - geht das?QAware GmbH
 

Mehr von QAware GmbH (20)

Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
 
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
 
Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
 
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAPKontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
 
Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
 
Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.
 
Per Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysPer Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API Gateways
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
 
How to speed up Spring Integration Tests
How to speed up Spring Integration TestsHow to speed up Spring Integration Tests
How to speed up Spring Integration Tests
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-ClusterAus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
 
Cloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniertCloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniert
 
Policy Driven Microservices mit Open Policy Agent
Policy Driven Microservices mit Open Policy AgentPolicy Driven Microservices mit Open Policy Agent
Policy Driven Microservices mit Open Policy Agent
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der Praxis
 
Die nächsten 100 Microservices
Die nächsten 100 MicroservicesDie nächsten 100 Microservices
Die nächsten 100 Microservices
 
Enterprise-level Kubernetes Security mit Open Source Tools - geht das?
Enterprise-level Kubernetes Security mit Open Source Tools - geht das?Enterprise-level Kubernetes Security mit Open Source Tools - geht das?
Enterprise-level Kubernetes Security mit Open Source Tools - geht das?
 

Sichere Speicherung kritischer Daten in der Cloud

  • 1. heise devSec 2020 Andreas Zitzelsberger andreas.zitzelsberger@qaware.de @andreasz82 Sichere Speicherung kritischer Daten in der Cloud
  • 2. 1. Einführung 2. Grundlegende Prinzipien 3. Bausteine 4. Architektur 5. Fazit
  • 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. 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. 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. Was ist in der Cloud anders? Quellle: https://www.gettyimages.de/detail/illustration/antique-illustration-of-angel-playing-trumpets-lizenfreie-illustration/499747058
  • 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
  • 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.
  • 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. 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
  • 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
  • 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).
  • 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. 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. Delegationsmuster: Token Re-Use API 1 API 2 ● Einfach ● OK wenn API 1 keine Sicherheitswirkung hat
  • 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. ● 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. GitOps vermeidet administrative Zugriffe Build Image Registry Application Repositories Deploy Push PR w. 4 eyes Configuration Repository Admission Control https://www.openpolicyagent.org/
  • 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. 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. Problem: Wie kann ich die Daten meiner Mandanten in der Public Cloud trennen? Lösung: Muss individuell entschieden werden.
  • 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. 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. 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. 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. 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. 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. 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. Problem: Wie kann ich Produzenten / Konsumenten in der Datenlogistik trennen? Wie kann ich nachhaltig Verwendungszwecke durchsetzen? Lösung: Kryptographische Trennung auf Anwendungsebene
  • 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. 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. 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. Fazit
  • 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.