Zero Trust – Was es bedeutet und warum Developer es kennen sollten

Zero Trust ist nicht nur ein Sicherheitskonzept, es ist eine Antwort auf eine Realität, in der Angriffe nicht mehr nur von aussen kommen. Wer moderne Systeme entwickelt, muss davon ausgehen, dass Vertrauen ein Risiko ist, selbst gegenüber internen Komponenten. Für Entwickler:innen bedeutet das: Sicherheit beginnt nicht am Perimeter, sondern im Code.

Was genau steckt hinter Zero Trust?

Das Prinzip Zero Trust basiert auf dem Ansatz „never trust, always verify“. Das bedeutet: Jeder Zugriff egal ob von innen oder aussen muss überprüft und autorisiert werden. Auch ein Gerät oder ein Benutzer im internen Netzwerk gilt nicht automatisch als vertrauenswürdig, nur weil er angemeldet ist.

Die Grundpfeiler von Zero Trust:

• Identitätsbasierte Zugriffe – etwa über OAuth oder OpenID Connect
• Feingranulare Rechtevergabe – nicht „alles oder nichts“, sondern genau, was nötig ist
• Segmentierung von Systemen – keine unnötigen Querverbindungen zwischen Diensten
• Kontinuierliche Verifikation – nicht nur beim Login, sondern auch danach

Ziel ist es, Angriffe frühzeitig zu erkennen und abzuwehren, gerade wenn interne Systeme kompromittiert wurden oder Zugangsdaten in falsche Hände geraten sind.

Was bedeutet Zero Trust für die Softwareentwicklung?

Wer Software entwickelt, entscheidet oft schon mit dem ersten Code, wie sicher ein System später ist. Zero Trust bedeutet in diesem Kontext: Sicherheit ist kein Zusatzfeature, sie ist Teil der Architektur.

Fünf wichtige Prinzipien für Entwickler:innen:

1. APIs absichern

Ein häufiger Irrtum: Interne APIs bräuchten keinen Schutz, gerade dort entstehen aber oft Einfallstore. Jeder Endpunkt sollte authentifizieren, etwa via JWT mit Ablaufzeit und Rollenprüfung. So bleibt in verteilten Architekturen wie bei Microservices, CI/CD oder Frontend-Backend-Sicherheit das Prinzip „never trust“gewahrt.

2. Rechte exakt vergeben

Sammelrollen wie „Admin“ öffnen zu viele Wege, besser sind Rollen mit minimalen, zweckgebundenen Rechten (Least Privilege). Schon im Code lässt sich definieren: Darf nur diese API aufgerufen werden? Nur dieser Service diese Operation durchführen?

3. Sichere Defaults verwenden

Per default sollte der Zugriff gesperrt sein, und nur explizit erlaubte Aktionen dürfen passieren. In Zero Trust-Systemen bedeutet das:

• Strikte Firewall-Regeln
• Default-deny-ACLs
• Isolierte Netzwerke – auch im Entwickler-Setup.

4. Sessions im Blick behalten

Lang laufende Tokens sind riskant, im Zero Trust gilt: kurze Lebensdauer + automatische Timeouts + Scope-Checks bei jeder Anfrage. So lassen sich Leak- und Replay-Risiken aktiv reduzieren.

5. Protokollieren und überwachen

Jede sicherheitsrelevante Aktion muss geloggt werden: Logins, Rollenänderungen, Zugriffsversuche, auch in internen Systemen. Nur so lassen sich Angriffe oder Fehlverhalten früh erkennen und automatisiert reagieren.

Weitere Anwendungsfelder aus der Praxis:

Zero Trust im Frontend – Sicherheit endet nicht beim Login

In modernen Single-Page-Apps (SPAs) wie Vue, React oder Angular ist der Umgang mit Tokens besonders sicherheitskritisch. Tokens dürfen nur mit klar definierten Scopes verwendet werden, sollten auf eine vertrauenswürdige Herkunft (Origin) geprüft und nie dauerhaft im lokalen Speicher hinterlegt werden. Auch intern erreichbare APIs benötigen Schutz, es gibt keine „versteckten“ Endpunkte mehr. So lässt sich verhindern, dass Unbefugte sensible Benutzerdaten abgreifen, ein wichtiger Aspekt für moderne Webanwendungen mit Login-Funktion, Kundenportalen oder geschäftskritischen Transaktionen.

Zero Trust in CI/CD-Pipelines – Vertrauen beginnt beim Build

Auch in der Softwarebereitstellung gilt Zero Trust. Nur signierte Artefakte sollten in produktive Umgebungen gelangen. CI/CD-Systeme wie GitHub Actions, GitLab CI oder Jenkins sollten so konfiguriert sein, dass jede Pipeline über eigene, zeitlich begrenzte Zugriffstokens agiert mit genau den Rechten, die für den jeweiligen Schritt nötig sind.
Das Ergebnis: Eine deutlich höhere Sicherheit in der Auslieferung, manipulative Eingriffe in Build-Prozesse lassen sich vermeiden, was insbesondere für Auditierbarkeit und Compliance zentral ist.

Zero Trust zwischen Microservices – mTLS und Identität

In Microservice-Architekturen sollten sich Services gegenseitig nicht einfach „vertrauen“. Die Kommunikation erfolgt über mTLS, ergänzt durch Identitätsprüfung und strikte Autorisierung. Jeder Dienst prüft: Wer bist du und darfst du das überhaupt?
So entstehen geschützte Kommunikationspfade, selbst im internen Cluster, ein zentraler Beitrag zu Datenschutz, Systemintegrität und Nachvollziehbarkeit, etwa für Sicherheits-Audits.

Praxisbeispiel: Zero Trust bei einer API

Ein Endpunkt wie /user/settings sollte nur dann antworten, wenn:

• ein gültiges Token mitgeliefert wird
• dieses Token zur passenden Benutzerrolle gehört,
• und ggf. zusätzliche Faktoren erfüllt sind (z. B. IP-Whitelist oder Zwei-Faktor-Authentifizierung).

Gerade bei sensiblen Bereichen etwa Admin-Zugängen oder Zahlungsfunktionen lohnt sich ein zusätzlicher Sicherheitslayer.

Fazit: Zero Trust ist ein Denkmodell – kein Tool

Zero Trust lässt sich nicht „installieren“. Es ist ein Prinzip, das Entwickler:innen, Admins und Architekt:innen gemeinsam umsetzen müssen. Wer heute Anwendungen entwickelt, sollte deshalb frühzeitig darauf achten, möglichst wenig blindes Vertrauen zuzulassen, weder gegenüber Benutzern noch gegenüber internen Systemen.

Das Ergebnis: robustere, sicherere Software, die Angriffen besser standhält und gleichzeitig moderne Anforderungen an Datenschutz und Compliance erfüllt.

Zero Trust in der Backup ONE Swiss Cloud

Auch in unserer Infrastruktur setzen wir auf Zero Trust-Prinzipien, nicht als Schlagwort, sondern als gelebte Praxis:

• Mit dem S3 IAM Policy Generator lassen sich in wenigen Klicks fein granulierte Zugriffsregeln erstellen, ideal für sichere Backup-Szenarien, Object Lock oder zeitlich limitierte API-Zugriffe.
• Unser Swiss S3 Storage bietet unveränderbare Speicherung mit Object Lock, eine zuverlässige Grundlage für auditable Datenhaltung im Sinne von Zero Trust.
• Die gesamte Umgebung basiert auf unserer eigenen Schweizer Cloud-Infrastruktur mit Standorten in Zürich und Genf. Unsere Rechenzentren sind ISO- und SOC-zertifiziert und garantieren technische wie organisatorische Sicherheit auf höchstem Niveau.

Zero Trust endet nicht im Code, bei Backup ONE ist es auch Teil der Betriebsrealität. Möchten Sie mehr zum Thema Datensicherheit bei Backup ONE erfahren, dann kontaktieren Sie uns gerne, wir freuen uns auf Ihre Kontaktanfrage.