Zero Trust

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?

Sicherheit

Wie baue ich Sicherheit?

Broken access Control

An den Eingängen wird nicht gut kontrolliert.

Cryptographic Failures

Es wird Leuten und Dokumenten vertraut, die gar nicht vertrauenswürdig sind.

Injection

Ich habe jemanden im Inneren, der absichtlich oder unabsichtlich etwas für den Angreifer macht.

Insecure DEsign

Man konnte über den Brunnen in die Burg.

Security Missconfiguration

3/4 der Türen waren super bewacht.

Outdated & Vulnerable Components

Die Tür war morsch. Die andere nicht
für den neuen Typ Kanonenkugeln gebaut.

Deshalb machen wir keine Burgen mehr.

Oder?

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

Broken

BY DESIGN

Wer ist 47 und älter?

 11PRINCIPLES

Open Design

Ich verlasse mich nicht darauf,
dass Dinge geheim sein müssen.

economy of mechanism

Keep It Simple & Stupid in Code & Design

Ich brauche keine komplexe Konfiguration

least common mechanism

Keine pauschalen Zugriffe und Rechte.
"Damit hast Du dann auch
gleich auf alle Tabellen Zugriff."

separation of privilege

Keine pauschalen Rechte für Nutzer, Accounts, Entities, Bereiche, Gruppen etc.

 

"Mit dem Admin-Account kannst Du im Prinzip überall alles machen."

LEast Privilege

Enforce "need to know" and "need to access".

Explizites, temporäres
Whitelisting der Zugriffe.

complete mediation

Check authorization for every access request.

Alle Zugriffe werden geprüft bevor sie passieren.

Wenn Rechte entzogen werden ist es sofort überall wirksam.

Fail-safe DEfaultS

Was nicht explizit erlaubt wird ist verboten.

psychological acceptability

Sicherheit ist nicht umständlich und störend

PerimeteR Security VS
11 Principles

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."

In guter Gesellschaft Scheitern

Zero TRUST

Was würde passieren, wenn wir den Kram von 1975
2020 mal ernst nehmen würden?

Verify explicitly

Always authenticate and authorize based on all available data points.

Use least privilege access

Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data protection.

Assume Breach

Minimize blast radius and segment access. Verify end-to-end encryption and use analytics to get visibility, drive threat detection, and improve defenses.

Hmmm...

Klingt ja erst gar nicht

mal so schwer.

  • Verify explicitly
  • Use least privilege access
  • Assume breach

Ich brauche:
Sichere identität

  • Identitäten gesichert für:
    • Personen
    • Devices
    • Services
    • externe Systeme
  • Starke Authentifizierung
  • Erkennen von Anomalien
  • IoT-Devices
  • Smartphones 
  • BYOD
  • On-Premise-Workloads
  • Cloud 

Ich brauche:
Sichere Endpunkte

Ich brauche:
Sichere Applikationen

  • Legacy on Premises & Schatten-IT
  • Lift & Shifted Cloud Workloads
  • Moderne SAAS & Service Applikationen
  • Mobile Applikationen
     
  • Klassische App-Security von Konfiguration und Permissions bis Anomalieerkennung

Ich brauche:
Sichere Daten

  • In Transit 
  • In Rest
  • Backup
  • Access nach least Privilege
    • Apps
    • Infrastruktur
    • Storage

Ich brauche:
Sichere Netze

  • Segmentierung 
  • Micro-Segmentierung
  • End-2-End-Encryption
  • Monitoring und Analytics

OK.

Das ist wohl doch ein wenig anders.

zero Trust
in der Praxis

Case Study: Fintech.

Fallbeispiel

Das problem

Kritische personenbezogene Daten

Hohes Image-Risiko

Sicherheitsbedürfnis der Kunden

Misstrauen in der Branche 

Fallbeispiel

Sichere
Architektur

  • Modifizierte agile Variante des SDLC Security Push
  • Identification der kritischen Assets
  • Attacker Klassifizierung
  • Process Flow Diagram
  • Threat Modelling
  • Risk Rating
  • Risk Boundaries & Mitigations
  • Architekturtreiber

Fallbeispiel

IdentitäT im CLIENT

  • Biometrische Freigabe
  • Hardware-Store für Auth-Token
  • Verschlüsselter lokaler Storage
  • Device-Binding
     

Nicht dabei: 

  • Strong Auth (IdNow etc)

Architektur

Fallbeispiel

Identity im Server

  •  Authentifizierung über Device-ID und Passwort in Keycloak, asymmetrisch
  • temporärer JWT mit Refresh aus Keycloak
  • Token für jeden Service und Datenzugriff erforderlich

Architektur

Fallbeispiel

Kommunikation im Server

  • ISTIO als ServiceMesh
  • Traffic Encryption für MITM
  • MTLS und Access Policies
  • Auditing & Observability

Architektur

Fallbeispiel

Security als Teil der Infrastruktur

Fallbeispiel

HANDSHAKES in ISTIO

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"]

FINE GRAINED AUTHORISATION

Architektur

Fallbeispiel

Case Study

ISTIO OBSERVABILITY

Architektur

Zero Trust at REST

  • Alle PII-Daten per-user-verschlüsselt
  • Zum Entschlüsseln braucht es API-Auth + User-Secret aus Device
  • Data-Tagging: PII-Relevante Datensätze in Transit markieren
  • Impliziter Audit-Log

Architektur

Fallbeispiel

DSGVO for FREE

  • Crypto Shredding: löschen auch in allen Backups
     
  • Data Tagging:
    • Welche Daten haben wir  gespeichert?
    • Wohin wurden sie transferiert?
    • Wo wurden sie geändert?

Architektur

Fallbeispiel

Zero trust CODE

  • "Shift Left"
  • DevSecOps

Konkret:

  • Security als Architekturtreiber mit Fitness-Funktionen
  • Github Dependency Security
  • Sonarcloud SAST
  • TRIVY Container & Image Security 

Was fehlte?

  • Infrastruktur: tfsec, awssec, kubesec
  • Blackbox-Scanning
  • API-Fuzzing

 

 

Case Study

Update 2022
Supply Chain Risk

Distroless oder Containerless?

  • Wer nutzt Syft für die Software Bill of Materials in den Containern?
     
  • Distroless: Containers nur mit den Files, die wir wirklich brauchen
     
  • Von Google, aber mühsam - https://github.com/GoogleContainerTools/distroless
     
  • Containerless: WASM statt ContainerD

Cosign & SigStore

sigstore.dev

Supply Chain Security:

  • Signieren
  • Verifizieren
  • Key Management mit
    OpenIDConnect/Keyless
  • Monitoring

Rahmen:

  • Who is who der relevanten Firmen
  • Starke OpenSource-Community
  • Für Opensource schon oft im Einsatz

Cosign & SigStore

  • Cosign: Container signing, verification and storage - mit Hardware, KMS und PKI-Support
  • Gitsign: Keyless signing für Commits
  • Fulcio: root certificate authority für Code Signing, keyless mit OpenID Connect
  • Rekor: transparency & timestamping service
  • Policy Controller: was ist in Kubernetes erlaubt, was nicht?

sigstore.dev

Signing

  • Container
  • Registries
    • Github, Google, Microsoft, AWS ...
  • Signing
    • Gitlab und Github
  • Blobs und Files
  • Software Bill of Materials
  • CUE in-toto Validations​​​​​​​​​​​​​​

sigstore.dev

Verification

  • Kyverno
  • Policy Controller
  • CLI, Webhooks

sigstore.dev

sigstore.dev

SPIFFE & SPIRE

SPIFFE - "Secure Production Identity Framework For Everyone"

  • "HTTPS für Dienste, mit Rechten dran" auf X.509
  • Node Attestation: Authentifizierung, Vertraulichkeit, Integrität, Autorisierung
  • SPIRE als Implementierung
  • Server: Attestion, Storage, Key Management, Workload Registration
  • Agent: Authentication, lokale Attestation

spiffe.io

Node Attestation

spiffe.io

Support

  • Support für Istio und CodeSign
  • "Secretless" bzw. "Keyless Deployments"
    • Keine Secrets, API-Keys, Token, Passwörter mehr.
  • Workload Attestation für Unix, Kubernetes und Docker Workloads.

spiffe.io

Dapr.IO

"APIs for building portable and reliable MicroServices"

  •  

dapr.io

Dapr.IO

One Sidecar to rule them all.

 

dapr.io

Dapr.IO

Kein Zero Trust, aber ein paar Features:

  • mTLS mit Zertifikaten
  • OAuth Endpoint authorization
  • Scoping für APIs and PubSub
  • Security Policies im Sidecar
  • State Store Encryption
  • Observability mit impliziten Tracing zu Prometheus, Zipkin, FluentD etc., inkl. Metrics, Logs, Health Checks etc

dapr.io

Dapr.IO

  • Default auf Deny in Public
  • App1 Default auf Deny
  • Aber: 
    • von public im namespace Default darf für diesen Service /op1 mit POST & PUT
    • von myDomain im NameSpace "n1" auf /op2 generell zugreifen

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

Things to come

WebAssembly Capabilities:
Wasm Interface Type (WIT)  Worlds:

Runtime-Level
Access-Control in beide Richtungen

Ok, cool

Aber kommt man dahin? Und will ich das überhaupt?

Links

  • Microsoft Zero Trust
    https://www.microsoft.com/de/security/business/zero-trust
  • Google BeyondProd
    https://cloud.google.com/docs/security/beyondprod
  • Istio
    https://istio.io/latest/
  • SPIFFE & SPIRE
    https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf
  • Cosign, Sigstore, Rekor, Fulcio
    https://sigstore.dev/

Machen!

  • ISTIO, Dapr & Co zum selbstprobieren
    https://microk8s.io/
    https://github.com/mayflower/microk8s-addons

     
  • Mal reden
    https://calendly.com/johann-peter-hartmann

 

Oder hier :-) 

Was ändert sich?

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

Was ändert sich?

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

Was ändert sich?

Herkömmliche Sicherheit Cloud Native / Zero Trust
IP-Adressen-basierte Identität Dienstbasierte Identität

Was ändert sich?

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

Was ändert sich?

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

Was ändert sich?

Herkömmliche Sicherheit Cloud Native / Zero Trust
Humanoide und dokumentationsgetriebene Überwachung von Sicherheitskomponenten Kontinuierliche und zentrale Ansicht der Sicherheitsrichtlinien und Einhaltung der Richtlinien

Was ändert sich?

Herkömmliche Sicherheit Cloud Native / Zero Trust
Spezialisierte und seltene Rollouts Standardisierter Erstellungs- und Rollout-Prozess mit häufigen, unkoordinierten Rollouts vieler Services.

Was ändert sich?

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

Zero Trust

By Johann-Peter Hartmann

Zero Trust

In Deutschland haben Cloud-Technologien immer noch ein Vertrauensproblem. Die gefühlte Sicherheit ist kleiner, wenn der Server nicht im eigenen Rechenzentrum steht, und behält die kritischen Daten lieber bei sich. Dabei bietet moderne Cloud-Technologien wie ZeroTrust, CryptoShredding, Data Tagging und der Shift Left viel mehr Sicherheit, Auditfähigkeit und Vertrauenswürdigkeit als es altbackene Firewall-Zonen, Serverschränke und Penetration-Tests bieten könnten.

  • 328

More from Johann-Peter Hartmann