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

7.
Quelle: https://devrant.com/rants/898940/someday-i-will-answer-this-question-to-my-kids

8.
Cloud Native Landscape 2016

9.
Cloud Native Landscape 2020

10.
Der Verantwortungsschnitt
IaaS
CaaS
SaaS
PaaS
Anwendungen
Verantwortung: ProviderVerantwortung: Consumer

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.
Grundlegende Prinzipien

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.
Least Privileges
Quelle: https://xkcd.com/149/

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

17.
Defense-in-Depth
Bildquelle: https://www.gettyimages.de/detail/foto/walls-of-istanbul-lizenzfreies-bild/155258807

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.
Qualität als Grundhaltung

20.
Bausteine

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.
Service Meshes
Quelle: https://istio.io/latest/docs/ops/deployment/architecture/

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/

29.
Architektur

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.

46.
Vielen Dank!
andreas.zitzelsberger@qaware.de
@andreasz82