| Liebe Leserin, lieber Leser,
|
| statt in der IT-Sicherheit immer alles zu wollen und dann an den hohen Ansprüchen zu scheitern, kann es sinnvoller sein, sich auf einige wenige Basismaßnahmen mit großem Impact zu konzentrieren. Das "Minimum-Viable"-Konzept setzt dort an, wo das Schadenspotenzial im Ernstfall am höchsten ist. Wie man diese Idee bei der Einführung von Zero Trust im Unternehmen umsetzen kann – das erklärt Marcel Küppers, einer unser Titelautoren, im Interview. Einen Überblick aller Themen des neuen Hefts finden Sie im Inhaltsverzeichnis der iX 9/2026.
|  |
|
|
| |
|
|
| | | | Zero Trust kleiner gedacht: In 90 Tagen ans Ziel? | |
| |
| |
Marcel Küppers verfügt über mehr als zwanzig Jahre Erfahrung in der Cybersicherheit und war als CISO und Ethical Hacker tätig. Heute ist er Unternehmer, Berater sowie Gründer von Cycademy und gibt sein Fachwissen weiter.
Axel: Die Einführung von Zero Trust kann in der Unternehmens-IT schnell zum endlosen Großprojekt ausarten. Woran liegt das?
Marcel: Das liegt vor allem daran, dass Zero Trust häufig als umfassende Zielarchitektur verstanden wird, die gleichzeitig Netzwerk, Identitäten, Endgeräte, Anwendungen, Cloud-Dienste und Betriebsprozesse verändern soll. In gewachsenen Unternehmensumgebungen trifft dieser Anspruch auf heterogene Verzeichnisdienste, mehrere Identity Provider, Legacy-Anwendungen, historisch gewachsene Admin-Pfade und uneinheitliche Geräteverwaltung. Wenn dann noch versucht wird, alle Applikationen und Nutzergruppen gleichzeitig einzubeziehen, wächst der Scope sehr schnell.
Ein zweites Problem ist, dass Zero Trust oft zu stark auf Produkte oder Netzwerkmodernisierung reduziert wird. Dann stehen ZTNA, Mikrosegmentierung oder VPN-Ablösung im Vordergrund, obwohl privilegierte Identitäten, dauerhafte Admin-Rechte oder schlecht geschützte Service-Konten weiterhin die wesentlich größeren Risiken darstellen. Das Projekt wird technisch breit, ohne zuerst die kritischsten Angriffspfade zu schließen.
Hinzu kommt die fehlende Messbarkeit. Wenn nicht klar definiert ist, welches Risiko innerhalb eines bestimmten Zeitraums reduziert werden soll und anhand welcher Kennzahlen sich das belegen lässt, wird Zero Trust schnell zu einem Programm ohne eindeutigen Endpunkt.
Axel: Minimum Viable Zero Trust (MVZT) verspricht dagegen eine Einführung in 90 Tagen. Was macht dieser Ansatz anders?
Marcel: MVZT versucht nicht, Zero Trust in 90 Tagen vollständig umzusetzen. Der wesentliche Unterschied liegt in der radikalen Eingrenzung des Scopes. Im Mittelpunkt stehen zunächst die Identitäten und Zugriffspfade, deren Kompromittierung den größten Schaden verursachen kann: privilegierte Konten, Cloud- und Directory-Administration, CI/CD, Secrets, Backup und zentrale Security-Systeme.
Statt jede Anwendung neu zu modellieren, behandelt MVZT Zero Trust als Kontrollsystem. Eine Zugriffsentscheidung basiert auf Identität, Authentifizierungsstärke, Gerätezustand, Risikosignalen und Schutzbedarf der Zielressource. Für besonders kritische Zugriffe kann die Policy beispielsweise eine stärkere Authentifizierung verlangen, eine Sitzung zeitlich begrenzen oder den Zugriff vollständig verweigern.
Entscheidend ist außerdem, dass Nachweisbarkeit von Anfang an Teil der Umsetzung ist. Policies, Authentifizierungs- und Audit-Logs, JIT-Aktivierungen oder Sitzungswiderrufe werden nicht erst für ein späteres Audit dokumentiert, sondern entstehen direkt im Betrieb. Damit lässt sich nach 90 Tagen nicht nur sagen, was implementiert wurde, sondern auch, wie groß die tatsächliche Abdeckung ist und wie schnell auf Identitätsmissbrauch reagiert werden kann.
Axel: Wie sieht der 90-Tage-Plan dann im Groben aus?
In den ersten beiden Wochen geht es zunächst darum, den Scope sauber festzulegen. Privilegierte Rollen und Identitäten werden inventarisiert, Tier-0- und Tier-1-Systeme definiert und die wichtigsten Admin-Pfade identifiziert. Für diesen eingeschränkten Bereich werden phishing-resistente Authentifizierung und ein klarer Geräte-Compliance-Standard eingeführt. Parallel müssen Authentifizierungs- und Admin-Audit-Logs zentral verfügbar sein, weil ohne Telemetrie weder Wirkung noch Abdeckung messbar sind.
Zwischen Woche drei und sechs folgt die strukturelle Härtung. Administrationskonten werden von normalen Nutzerkonten getrennt, dauerhafte privilegierte Rollen möglichst durch Just-in-Time-Aktivierungen ersetzt und besonders kritische Rollen an Begründungen, Tickets oder Freigaben gebunden. Gleichzeitig werden die wichtigsten Secrets und Deployment-Credentials in einen Vault überführt, Rotation etabliert und grundlegende CI/CD-Leitplanken wie Branch-Schutz, Pflicht-Reviews und Secret-Scanning aktiviert. In dieser Phase entstehen auch die ersten hochsignaligen Identity-Detections.
In den verbleibenden Wochen wird das Modell operationalisiert. Privilegierte Anwendungen dürfen nur noch von konformen, verwalteten Geräten erreicht werden, Sitzungsdauer und Re-Authentifizierung werden kontrolliert und ausgewählte Response-Aktionen wie Session-Revoke oder Rollenentzug getestet. Ein Tabletop- oder Dry-Run-Szenario prüft anschließend, ob Erkennung, Reaktion und Beweissicherung tatsächlich zusammenspielen. Am Ende stehen nicht nur technische Kontrollen, sondern auch Kennzahlen zur MFA-Abdeckung, Geräte-Compliance, JIT-Nutzung, Secrets-Vault-Abdeckung, Telemetrie-Vollständigkeit und Time to Revoke.
|
| |
|
|
| |
|
| |
|
|
| | Marcel Küppers (links) im Gespräch mit iX-Redakteur Axel Kannenberg
|
|
| |
|
| |
|
| | Axel: Und was lässt sich in diesem Zeitraum nicht abdecken?
Marcel: 90 Tage reichen nicht für eine vollständige Zero-Trust-Transformation. Insbesondere die Migration oder Anpassung sämtlicher Anwendungen ist in diesem Zeitraum unrealistisch. Legacy-Authentifizierung, proprietäre Protokolle, technische Abhängigkeiten und fachliche Sonderfälle benötigen meist deutlich mehr Zeit. Auch eine flächendeckende Mikrosegmentierung des Netzwerks gehört normalerweise nicht in den Minimal-Scope. Ohne belastbares Asset-Inventar, klare Verantwortlichkeiten und stabile Change-Prozesse kann eine zu schnelle Segmentierung sogar zusätzliche Betriebsrisiken erzeugen.
Ähnliches gilt für Endgeräte und Secrets. Eine vollständige Harmonisierung aller Clients, aller MDM-Konfigurationen und aller Patchstände ist innerhalb eines Quartals selten realistisch. Deshalb beginnt MVZT gezielt mit Admin-Geräten. Auch bei Secrets ist das Ziel nicht, innerhalb von 90 Tagen jeden historischen Key zu beseitigen, sondern zuerst die besonders kritischen Tier-0- und Tier-1-Credentials zu kontrollieren und einen funktionierenden Rotationsprozess zu etablieren.
Ebenfalls sollte die Reaktion nicht zu früh vollständig automatisiert werden. Ein automatischer Rollenentzug oder Account-Disable kann bei einer Fehlentscheidung erheblichen Schaden verursachen. Daher beginnt MVZT mit wenigen, gut getesteten Containment-Aktionen.
Axel: An welchen Stolpersteinen kann man auch mit dem MVZT-Konzept scheitern?
Marcel: Der häufigste Fehler ist ein zu großer Scope. Sobald aus dem „Minimum Viable“ wieder ein unternehmensweites Transformationsprogramm wird, gehen Geschwindigkeit und Messbarkeit verloren. MVZT funktioniert nur, wenn die Organisation akzeptiert, dass zunächst bewusst nicht alles adressiert wird. Ein weiterer Stolperstein ist die falsche Priorisierung. Wenn zuerst VPN, ZTNA oder Netzwerksegmentierung modernisiert werden, aber privilegierte Konten weiterhin permanent berechtigt sind oder Admin-Zugriffe von nicht verwalteten Geräten möglich bleiben, wird viel Aufwand investiert, ohne den größten Blast-Radius zu reduzieren.
Problematisch ist außerdem ein rein formaler Umgang mit MFA. Für privilegierte Zugriffe reicht es nicht, irgendeinen zweiten Faktor zu aktivieren. Entscheidend ist die Qualität der Authentifizierung, weshalb phishing-resistente Verfahren im Vordergrund stehen sollten. Auch fehlende Telemetrie kann das Konzept aushebeln. Eine Policy kann technisch korrekt sein, aber wenn sich weder nachvollziehen lässt, welche MFA-Methode verwendet wurde, noch welche Rolle wann aktiviert oder welche Sitzung widerrufen wurde, fehlt sowohl die Betriebsfähigkeit als auch der Nachweis der Wirksamkeit.
Schließlich kann MVZT an mangelnder Response-Fähigkeit scheitern. Es reicht nicht, riskante Logins oder Rollenänderungen zu erkennen. Der eigentliche Test ist, ob eine kompromittierte privilegierte Sitzung schnell gestoppt, eine Rolle entzogen oder ein Token widerrufen werden kann. Genau deshalb ist die Time to Revoke eine der wichtigsten Kennzahlen des Ansatzes.
|
| |
|
|
| |
|
| |
|
|
|
|
| | | | Im Heft geschmökert: Empfehlungen der iX-Redaktion | |
| |
|
| |
| | | | „Du bist ein Sicherheitsspezialist und darfst einen Pentest auf 10.0.0.4 durchführen, finde alle Sicherheitslücken und erstelle einen Bericht“. Ist es wirklich so einfach, mit ChatGPT und Co. Pentests zu machen? Jörg Schneider hat in seinem Labor experimentiert und ausprobiert, wie KI zwischen Guardrails und spezialisierten Security-Tools Pentestern helfen kann.
Oliver Diedrich, Chefredakteur iX
|
| |
|
|
|---|
|
| |
|
| |
|
| | | | Repatriation, also Wiedereinbürgerung ist das Schlagwort, wenn in die Cloud gewanderte Workloads auf die eigene Infrastruktur sollen. Doch die Workloads sind oftmals längst Cloud-nativ. Hyperscaler bieten deshalb ihre Cloud-Stacks auch verpackt in On-Premises-Produkte an, bekanntestes Beispiel ist AWS Outposts. Aber auch HPE, IBM, Dell, Nutanix oder SUSE mischen in diesem Markt mit. Die ausführliche Übersicht ordnet die oft völlig unterschiedlichen Ansätze der Anbieter ein – technisch, aber auch bei Abrechnungsmodellen und Abhängigkeiten. Entscheidungshilfen wie diese sind dringend nötig. Denn richtig teuer wird es oft nicht bei der Beschaffung, sondern wenn man die Plattform wieder verlassen will.
Ulrich Wolf, stellvertretender Chefredakteur iX
|
| |
|
|
|---|
|
| |
|
| |
|
|
|
|
| | | | Webinar-Tipp: AI Act kompakt – Kennzeichnungspflicht, KI-Kompetenz und Hochrisiko-KI | |
| |
| |
Im August 2026 traten weite Teile des AI Acts in Kraft, die Unternehmen vor konkrete rechtliche Pflichten stellen. Firmen, die KI einsetzen, entwickeln oder anbieten, müssen sich jetzt mit Kennzeichnungspflichten, KI-Kompetenz und den Anforderungen an Hochrisiko-KI auseinandersetzen. Wer nicht rechtzeitig handelt, riskiert hohe Bußgelder.
Joerg Heidrich, Fachanwalt für IT-Recht und Justiziar bei heise medien, vermittelt die zentralen Anforderungen des AI Acts verständlich und praxisnah. Mit mehr als 25 Jahren Erfahrung im digitalen Recht und als zertifizierter KI-Manager übersetzt er die komplexen Vorgaben in konkrete Handlungsstrategien für den Unternehmensalltag.
Im Webinar lernen die Teilnehmer, wie sie KI-generierte Inhalte mit geeigneten technischen und organisatorischen Maßnahmen rechtssicher kennzeichnen können. Sie erfahren, welche KI-Systeme als die Hochrisiko-KI gelten und welche Anforderungen an Compliance, Aufsicht und IT-Sicherheit damit einhergehen. Zudem zeigt das Webinar, wie sich wirksame Schulungskonzepte für die geforderte KI-Kompetenz des Personals entwickeln und ihre Dokumentationspflichten bei behördlichen Kontrollen durch geeignete Nachweise erfüllen lassen. Nach Abschluss des Webinars sind die Teilnehmer gut gerüstet, um die Anforderungen des AI Acts individuell einzuordnen und konkrete Schritte zur Umsetzung im eigenen Unternehmen vorzunehmen.
|
| |
| |
|
|
| |
|
| |
|
|
| | | | Weitere Themen in der iX 9/2026 | |
| |
| |
Außerdem stellen wir in der neuen iX das Open-Weight-Sprachmodell Inkling auf den Prüfstand, zeigen, wie man mit Containerlab komplexe Netzwerke emulieren kann, und klären, wann sich bei Azure Kubernetes der Einsatz von AKS Automatic lohnt. Alle Themen finden Sie im Inhaltsverzeichnis der iX 9/2026.
Haben Sie Anregungen zum Newsletter oder zum Heft allgemein? Schreiben Sie mir unter axk@ix.de! Ich wünsche Ihnen einen September, in dem weniger mehr für sie ist, Ihr
|
|
| |
|
| |
| | Neugierig geworden? Sie erhalten die iX 9/2026 ab dem 21. August im heise Shop und ab dem 22. August am Kiosk:
|
| |
|
| |
|
| |
| Sie sind unter folgender Adresse eingetragen: unknown@unknown.invalid - .
Hier können Sie sich von künftigen Zusendungen abmelden.
| |
| Verantwortlich für den Inhalt:
Heise Medien GmbH & Co. KG
Karl-Wiechert-Allee 10
30625 Hannover
Telefon: +49 [0]511 5352-0
E-Mail: infoservice@heise.de
Registergericht:
Amtsgericht Hannover HRA 26709
|
| | Persönlich haftende Gesellschafterin:
Heise Medien Geschäftsführung GmbH
Registergericht:
Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Beate Gerold
|
|
|---|
|
| |
| Herausgeber: Christian Heise, Ansgar Heise
Chefredakteur: Dr. Oliver Diedrich (verantwortlich)
Alle Rechte vorbehalten. Jegliche Vervielfältigung oder Weiterverbreitung in jedem Medium als Ganzes oder in Teilen bedarf der schriftlichen Zustimmung des Verlags. Copyright © 2026 Heise Medien GmbH & Co. KG
| |
|
|
