Wie die Cloud sicherer als der Rechner hinter der Firewall im eigenen Keller wurde.
Wir hören alle Online-Kurse, Podcasts und Tutorials auf 1.5-facher Geschwindigkeit, oder?
Wie baue ich Sicherheit?
An den Eingängen wird nicht gut kontrolliert.
Es wird Leuten und Dokumenten vertraut, die gar nicht vertrauenswürdig sind.
Ich habe jemanden im Inneren, der absichtlich oder unabsichtlich etwas für den Angreifer macht.
Man konnte über den Brunnen in die Burg.
3/4 der Türen waren super bewacht.
Die Tür war morsch. Die andere nicht
für den neuen Typ Kanonenkugeln gebaut.
Gibt es ernsthaft noch jemanden,
der diese Strategien einsetzt?
Text
Text
https://docs.oracle.com/en/operating-systems/oracle-linux/6/security/ol_recdepcfg_sec.html
BY DESIGN
Wer ist 47 und älter?
Ich verlasse mich nicht darauf,
dass Dinge geheim sein müssen.
Keep It Simple & Stupid in Code & Design
Ich brauche keine komplexe Konfiguration
Keine pauschalen Zugriffe und Rechte.
"Damit hast Du dann auch
gleich auf alle Tabellen Zugriff."
Keine pauschalen Rechte für Nutzer, Accounts, Entities, Bereiche, Gruppen etc.
"Mit dem Admin-Account kannst Du im Prinzip überall alles machen."
Enforce "need to know" and "need to access".
Explizites, temporäres
Whitelisting der Zugriffe.
Check authorization for every access request.
Alle Zugriffe werden geprüft bevor sie passieren.
Wenn Rechte entzogen werden ist es sofort überall wirksam.
Was nicht explizit erlaubt wird ist verboten.
Sicherheit ist nicht umständlich und störend
Im Intranet kann man jedem immer trauen!
Einmal authentifiziert ist immer echt.
Und wenn man dem Menschen trauen kann, kann auch seiner IP trauen. Und dem Rechner. Und aller Software darauf.
Besonders dem Admin und seinem Rechner. Der darf an alle Netze. Und auf alle Systeme. Und an alle Daten.
Deshalb sind auch intern
alle Services für alle erreichbar.
Wir vertrauen uns. Und jeder Software, die bei uns läuft.
Meanwhile, in our Universe ...
20% aller Data Breaches sind Insider Threats
Meanwhile, in our Universe ...
Davor liegen nur Ransomware & Trojaner
"Der Nutzer ist ja authentifiziert und hat McAfee."
Meanwhile, in our Universe ...
Auch wenn sie mit jeder ihrer privaten Devices auf Firmendienste zugreifen dürfen, findet inzwischen vieles im Homeoffice statt.
Oder auf Workation im Hostelwifi auf Zypern.
Warum nur das eigene Passwort verlieren,
wenn man auch die von allen anderen verlieren kann?
Meanwhile, in our Universe ...
Und unsere Software läuft auf fremden Servern. Mit fremder Administration. Und fremder Konfiguration. Die auf fremde Software zugreift. Auf die wir auch zugreifen.
Meanwhile, in our Universe ...
Mit 300 NPM-Packages. 200 Container-Images von Docker-Hub. 10 Helm-Charts von Github. 400 externe Libraries, davon 20 Versionen von log4j und 50 von OpenSSL.
Meanwhile, in our Universe ...
Greifen nur die berechtigten Services
auf meinen Service zu? Sind sie alle vertrauenswürdig?
In allen Bestandteilen?
Meanwhile, in our Universe ...
"PubSub is used to communicate messages between different system components without these components having to know each other's identity."
Was würde passieren, wenn wir den Kram von 1975
2020 mal ernst nehmen würden?
Always authenticate and authorize based on all available data points.
Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data protection.
Minimize blast radius and segment access. Verify end-to-end encryption and use analytics to get visibility, drive threat detection, and improve defenses.
Klingt ja erst gar nicht
mal so schwer.
Das ist wohl doch ein wenig anders.
Case Study: Fintech.
Fallbeispiel
Fallbeispiel
Fallbeispiel
Nicht dabei:
Architektur
Fallbeispiel
Architektur
Fallbeispiel
Architektur
Fallbeispiel
Fallbeispiel
Architektur
Fallbeispiel
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
version: v1
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces: ["dev"]
to:
- operation:
methods: ["GET"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
Architektur
Fallbeispiel
Case Study
Architektur
Architektur
Fallbeispiel
Architektur
Fallbeispiel
Konkret:
Was fehlte?
Case Study
sigstore.dev
Supply Chain Security:
Rahmen:
sigstore.dev
sigstore.dev
sigstore.dev
sigstore.dev
SPIFFE - "Secure Production Identity Framework For Everyone"
spiffe.io
spiffe.io
spiffe.io
"APIs for building portable and reliable MicroServices"
dapr.io
One Sidecar to rule them all.
dapr.io
Kein Zero Trust, aber ein paar Features:
dapr.io
dapr.io
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
accessControl:
defaultAction: deny
trustDomain: "public"
policies:
- appId: app1
defaultAction: deny
trustDomain: 'public'
namespace: "default"
operations:
- name: /op1
httpVerb: ['POST', 'PUT']
action: allow
- appId: app2
defaultAction: deny
trustDomain: 'myDomain'
namespace: "ns1"
operations:
- name: /op2
action: allow
WebAssembly Capabilities:
Wasm Interface Type (WIT) Worlds:
Runtime-Level
Access-Control in beide Richtungen
Aber kommt man dahin? Und will ich das überhaupt?
Oder hier :-)
Herkömmliche Sicherheit | Cloud Native / Zero Trust |
---|---|
Perimeterbasierte Sicherheit (d. h. Firewall), wobei die interne Kommunikation als vertrauenswürdig eingestuft wird | Zero-Trust-Sicherheit mit verifizierter Dienst-zu-Dienst-Kommunikation und ohne implizites Vertrauen für Dienste in der Umgebung |
Herkömmliche Sicherheit | Cloud Native / Zero Trust |
---|---|
Feste IP-Adressen und Hardware für bestimmte Anwendungen | Umfassendere Auslastung, Wiederverwendung und gemeinsame Nutzung von Ressourcen, einschließlich IP-Adressen und Hardware |
Herkömmliche Sicherheit | Cloud Native / Zero Trust |
---|---|
IP-Adressen-basierte Identität | Dienstbasierte Identität |
Herkömmliche Sicherheit | Cloud Native / Zero Trust |
---|---|
An einem bekannten, erwarteten Ort ausgeführte Dienste | Dienste können überall in der Umgebung ausgeführt werden, auch in hybriden Bereitstellungen in der öffentlichen Cloud und privaten Rechenzentren |
Herkömmliche Sicherheit | Cloud Native / Zero Trust |
---|---|
Sicherheitsspezifische Anforderungen, die in jede Anwendung integriert sind und separat erzwungen werden | Gemeinsame Sicherheitsanforderungen, die in Dienststacks gemäß einer zentralisierten Erzwingungsrichtlinie eingebunden sind |
Herkömmliche Sicherheit | Cloud Native / Zero Trust |
---|---|
Humanoide und dokumentationsgetriebene Überwachung von Sicherheitskomponenten | Kontinuierliche und zentrale Ansicht der Sicherheitsrichtlinien und Einhaltung der Richtlinien |
Herkömmliche Sicherheit | Cloud Native / Zero Trust |
---|---|
Spezialisierte und seltene Rollouts | Standardisierter Erstellungs- und Rollout-Prozess mit häufigen, unkoordinierten Rollouts vieler Services. |
Herkömmliche Sicherheit | Cloud Native / Zero Trust |
---|---|
Arbeitslasten werden in der Regel als VMs oder auf physischen Hosts bereitgestellt und verwenden für die Isolation physische Maschinen oder Hypervisoren. | Arbeitslasten aus Containern und ihre Prozesse werden in einem gemeinsam genutzten Betriebssystem ausgeführt, das einen Mechanismus zum Isolieren der Workloads erfordert |