Illustration Absmeier foto ki designer

Welche Anwendung darf wer unter welchen Bedingungen nutzen? Diese Frage rückt beim Zero Trust Application Access in den Mittelpunkt. Identität, Endgerät und Berechtigung zählen mehr als die Zugehörigkeit zu einem Netzwerk. Für CIOs und IT-Verantwortliche kommt es dabei weniger auf das Kürzel als auf die Umsetzung an: granulare Regeln, integrierte Identitätsprozesse und ein tragfähiger Betrieb. ZTAA ist hier ein anwendungsbezogener Baustein von Zero Trust – kein pauschaler Ersatz für ZTNA oder die gesamte Sicherheitsarchitektur. [1, 2, 4, 6]

Management Summary

Die Ressource ist der Maßstab. Zero Trust richtet den Schutz auf Anwendungen, Dienste und Daten aus. Netzwerkstandort und Geräteeigentum allein begründen kein Vertrauen; Authentifizierung und Autorisierung bleiben getrennte Aufgaben. [1]
Architektur vor Etikett. Auch ZTNA kann anwendungsbezogene Regeln durchsetzen. Ausschreibungen sollten deshalb konkrete Zugriffs- und Integrationsanforderungen beschreiben statt eine Überlegenheit von ZTAA vorauszusetzen. [6]
Identitäten brauchen einen Lebenszyklus. Benutzer, externe Partner und technische Identitäten benötigen nachvollziehbare Berechtigungen. Governance, starke Authentifizierung und Überwachung gehören zusammen. [4, 12]
Schrittweise umsetzen, gezielt prüfen. NIST dokumentiert 19 Zero-Trust-Beispielimplementierungen. Sie bieten technische Orientierung, aber keine universelle Lösung oder Produktempfehlung für jede Unternehmensumgebung. [11]
Den Betrieb mitfinanzieren. Das BSI beschreibt Zero Trust als langfristiges Vorhaben mit dauerhaftem Ressourcenbedarf. Verfügbarkeit und Wiederanlauf benötigen zusätzliche Vorkehrungen; Einsparungen sind gesondert nachzuweisen. [2]

ZTAA: Anwendungszugriff statt Netzwerkzugriff

Mit hybriden Arbeitsmodellen, Cloud-Anwendungen und externen Partnern verändert sich eine grundlegende Anforderung an Unternehmensnetze: Nicht mehr jedes Endgerät und jeder Benutzer benötigt Zugang zu einem ganzen Netzwerksegment. Häufig reicht der Zugriff auf einzelne Anwendungen oder Dienste. Genau an diesem Punkt setzt Zero Trust Application Access (ZTAA) an. [1, 7]

Zero Trust Application Access (ZTAA) bezeichnet hier die Anwendung von Zero-Trust-Prinzipien auf den Zugriff auf einzelne Anwendungen und Dienste. Im Mittelpunkt steht nicht die Zugehörigkeit zu einem vermeintlich vertrauenswürdigen Netzwerk, sondern die Prüfung von Identität, Endgerät und Berechtigung für die jeweilige Ressource. Dieses Prinzip ist bereits Teil des übergeordneten Zero-Trust-Konzepts und findet sich auch in ZTNA-Architekturen. ZTAA wird deshalb in diesem Beitrag nicht als grundsätzlich überlegener Nachfolger von Zero Trust Network Access (ZTNA) verstanden. [1, 6]

Vom Netzwerkzugriff zum Anwendungszugriff

Ein klassisches VPN stellt zunächst eine Verbindung zwischen einem externen Gerät und einem Unternehmensnetz her. Welche Ressourcen anschließend erreichbar sind, hängt unter anderem von Netzsegmentierung, Firewall-Regeln und weiteren Zugriffskontrollen ab. Auch VPN-Fernzugriffe erfordern daher eine gezielte Absicherung und starke Authentifizierung. [7, 9]

Bei einem anwendungsbezogenen Zero-Trust-Zugriffsmodell wird dagegen für die angeforderte Ressource entschieden, ob eine Verbindung zulässig ist. Ein Software-Defined Perimeter (SDP), Mikrosegmentierung oder identitätsbezogene Zugriffskontrollen sind mögliche Umsetzungsbausteine. NIST beschreibt diese als unterschiedliche Ansätze innerhalb einer gemeinsamen Zero-Trust-Referenzarchitektur, nicht als zwingende Kombination für jede Implementierung. [5]

Damit lautet das Grundprinzip vereinfacht:

Nicht: Wer darf in welches Netzwerk?
Sondern: Wer darf unter welchen Bedingungen auf welche Anwendung zugreifen?

Dieser Perspektivwechsel ist insbesondere für Unternehmen relevant, die Anwendungen für Beschäftigte im Homeoffice sowie für Dienstleister, Lieferanten, Partner, Freelancer oder andere externe Benutzergruppen bereitstellen müssen. [1, 7]

Identität und Ressource statt Netzwerkstandort

Nach NIST entsteht Vertrauen weder allein durch den Netzwerkstandort noch durch den Besitz eines firmeneigenen Geräts. Authentifizierung und Autorisierung von Benutzer und Endgerät gehen dem Aufbau einer Sitzung zu einer Unternehmensressource voraus. ZTAA greift diese ressourcenbezogene Sicht auf und stellt den konkreten Anwendungszugriff in den Vordergrund. [1]

Die Identitätsprüfung kann mit Multi-Faktor-Authentifizierung und Informationen über das zugreifende Endgerät verbunden werden. Dabei ist zwischen der Feststellung einer Identität und der Entscheidung über ihre Zugriffsrechte zu unterscheiden: Eine erfolgreiche Anmeldung allein begründet noch keine Berechtigung für sämtliche Anwendungen. [1, 6, 9]

Für die Umsetzung sind nachvollziehbare Identitäten und gepflegte Berechtigungen wesentlich. Verzeichnis- und Identitätsdienste können dafür als Grundlage dienen. NIST stellt identitätsbezogene Kontrollen als Fundament seiner schrittweise aufgebauten Beispielarchitekturen heraus. Eine bestimmte Verzeichnisschnittstelle oder clientseitige Software ist damit jedoch nicht als allgemeine ZTAA-Voraussetzung festgelegt. [5]

Ausgehende Verbindungen als mögliche Architekturvariante

Einige Zugriffsarchitekturen nutzen ausgehende Verbindungen aus der geschützten Umgebung zu einem vermittelnden Dienst. Die fachliche Zugriffsentscheidung und der technische Verbindungsweg sind dabei getrennt zu betrachten. Ausschließlich ausgehende Verbindungen sind eine mögliche Ausgestaltung, nicht die Definition von ZTAA. [5, 6]

Bei der hier belegten Variante übernimmt ein SDP-Broker beziehungsweise Proxy die Vermittlung des Anwendungszugriffs. Die Herstellerbeschreibung nennt dafür ausschließlich ausgehende Verbindungen sowie einen als Appliance oder Cloud-Dienst betriebenen Broker. Sie belegt diese Architekturvariante, legt aber nicht für jede Implementierung fest, welche interne Komponente die Verbindung initiiert, und beschreibt keine allgemeine Eigenschaft sämtlicher ZTAA-Lösungen. [6]

Ziel dieser Variante ist, interne Anwendungen für nicht autorisierte Benutzer nicht unmittelbar auffindbar zu machen. Daraus sollte keine pauschale Aussage über die Unsichtbarkeit oder Sicherheit der gesamten Infrastruktur abgeleitet werden. Für die Bewertung bleibt entscheidend, wie Identitätsprüfung, Richtlinien und Ressourcenzugriff tatsächlich umgesetzt sind. [5, 6]

Bei Fernzugriffen auf administrative Dienste wie Remote Desktop Protocol (RDP) sollte die Prüfung daher über den Verbindungsweg hinausgehen: Welche Identitäten dürfen zugreifen, welche Geräte werden zugelassen und welche zusätzlichen Authentifizierungsschritte sind erforderlich? NIST behandelt die Absicherung von Fernzugriffskomponenten und Endgeräten; CISA empfiehlt zudem, eingesetzte Fernzugriffswerkzeuge einschließlich RDP zu erfassen und ihre Nutzung zu protokollieren und zu überwachen. [7, 8] Die Unterstützung eines bestimmten Protokolls muss für die jeweilige Implementierung geprüft werden.

Zugriffsrechte werden dynamischer

ZTAA betrifft nicht nur die technische Verbindung zwischen Benutzer und Anwendung. Zum Zero-Trust-Ansatz gehört auch eine Zugriffsentscheidung, die Identität und Kontext berücksichtigt und Berechtigungen auf das erforderliche Maß begrenzt. CISA beschreibt diese Ausrichtung als Übergang von einem standortbezogenen zu einem stärker datenzentrischen Modell mit granularen Sicherheitskontrollen. [3]

Je nach Umsetzung können Zugriffsregeln neben dem Benutzerkonto auch den Gerätezustand und weitere Kontextinformationen berücksichtigen. [6] Zeitliche Freigaben oder zusätzliche Authentifizierungsschritte für sensible Anwendungen sind hier Auswahlkriterien, keine zugesicherten ZTAA-Funktionen. Sie müssen für die konkrete Implementierung geprüft werden. Für eingesetzte Fernzugriffswerkzeuge nennt CISA unter anderem Leerlauf-Zeitüberschreitungen als Maßnahme zur Sitzungsbegrenzung. [8]

Die zentrale Frage lautet damit nicht nur, wer zugreifen darf, sondern auch, auf welche Ressource, mit welchen Rechten und unter welchen Bedingungen. Eine solche Steuerung setzt definierte Richtlinien und deren technische Durchsetzung voraus. Der Produktname allein sagt nichts darüber aus, wie vollständig diese Anforderungen erfüllt werden. [1, 3]

Relevanz für BYOD und externe Partner

Bring-your-own-Device- und Partner-Szenarien gehören zu den von NIST ausdrücklich behandelten Einsatzfällen für Fernzugriff und Zero Trust. [1, 7]

Beschäftigten im Homeoffice sowie Dienstleistern, Lieferanten und Partnern lassen sich gezielt die Anwendungen zuweisen, die sie für ihre Aufgaben benötigen. Die Ressource und die dafür erforderliche Berechtigung sind dabei maßgeblich, nicht allein der Standort des Benutzers. NIST berücksichtigt sowohl Fernzugriffe als auch private Endgeräte ausdrücklich in seinen Zero-Trust-Grundlagen. [1]

Auch Anwendungen in lokalen und verschiedenen Cloud-Umgebungen können Gegenstand einheitlicher Zugriffsrichtlinien sein. NIST SP 800-207A beschreibt hierfür granulare Regeln auf Anwendungsebene und bezieht neben Benutzeridentitäten auch Anwendungs- und Dienstidentitäten ein. Die Unterstützung konkreter Betriebssysteme, Protokolle und Altanwendungen bleibt hingegen eine Eigenschaft der gewählten Lösung und muss gesondert geprüft werden. [4]

ZTAA kann auch den Betrieb verändern

Die Abkehr vom breit angelegten Netzwerkzugriff betrifft nicht nur die Sicherheit, sondern auch die Weiterentwicklung von Zugriffsprozessen und Richtlinien im IT-Betrieb. [5]

Eine anwendungsbezogene Zugriffskontrolle verändert die Aufgaben im Betrieb: Identitäten, Ressourcen und Berechtigungen müssen erfasst sowie die zugehörigen Richtlinien umgesetzt und überprüft werden. NIST beschreibt seine Beispielarchitekturen als schrittweise Weiterentwicklung vorhandener Umgebungen. Eine einheitliche technische Lösung für sämtliche Unternehmen ergibt sich daraus nicht. [5]

Pauschale Aussagen über geringere Kosten oder weniger Administrationsaufwand sind deshalb nicht angebracht. Das BSI betont, dass eine ganzheitliche Zero-Trust-Umsetzung ein langfristiges Vorhaben mit dauerhaftem finanziellem und personellem Ressourcenbedarf ist. Bei organisationsübergreifenden Zugriffen kommen Anforderungen an Abstimmung und Interoperabilität hinzu. [2]

Für eine Wirtschaftlichkeitsbewertung sollten Unternehmen daher den gesamten Lebenszyklus betrachten: Integration, Lizenzierung, Betrieb, Pflege der Zugriffsregeln und Zusammenarbeit mit externen Organisationen. Diese Prüfpunkte sind eine redaktionelle Ableitung aus dem vom BSI beschriebenen dauerhaften Ressourcenbedarf und den bei NIST behandelten Aufgaben zur Weiterentwicklung von Zugriffsprozessen; sie sind kein Nachweis konkreter Einsparungen. [2, 5] Lizenzmodell und Hardwarebedarf müssen anhand des jeweiligen Angebots geprüft werden.

ZTAA als Baustein einer umfassenderen Sicherheitsarchitektur

Der wesentliche Unterschied zum breit angelegten Fernzugriff liegt in der gezielten Freigabe von Ressourcen. Daraus folgt jedoch keine scharfe Trennlinie zwischen ZTAA und sämtlichen ZTNA-Angeboten: Auch ZTNA kann den Zugriff auf einzelne Anwendungen nach Identität und Kontext begrenzen. Für die Auswahl ist daher die tatsächliche Architektur aussagekräftiger als die Abkürzung. [6]

Anwendungszugriff ist zudem nur ein Teil von Zero Trust. Das CISA-Reifegradmodell berücksichtigt Identitäten, Geräte, Netzwerke, Anwendungen und Workloads sowie Daten. Das BSI ordnet Zero Trust als ganzheitlichen Ansatz ein und weist darauf hin, dass sich die Schutzwirkung vorrangig auf Integrität und Vertraulichkeit bezieht, nicht auf Verfügbarkeit. Anwendungsbezogene Zugriffskontrollen sollten deshalb in ein umfassenderes Sicherheits- und Betriebskonzept eingebettet werden. [2, 3]

Fazit

ZTAA stellt den kontrollierten Zugriff auf einzelne Anwendungen in den Mittelpunkt. Die zugrunde liegenden Prinzipien – kein implizites Vertrauen aufgrund des Netzwerkstandorts sowie die Prüfung von Identität und Berechtigung für eine Ressource – gehören bereits zum allgemeinen Zero-Trust-Konzept. [1]

Für Unternehmen ist deshalb weniger die Produktkategorie entscheidend als die Frage, ob eine Architektur die benötigten Anwendungen, Benutzergruppen und Endgeräte mit nachvollziehbaren Regeln abdeckt. NIST zeigt dafür unterschiedliche technische Umsetzungswege; keine einzelne Variante ist für alle Umgebungen gleichermaßen geeignet. [5]

Eine belastbare Bewertung sollte die Granularität der Zugriffskontrolle, die Integration in Identitäts- und Betriebsprozesse sowie den langfristigen Ressourcenbedarf berücksichtigen. Allgemeine Schutz-, Skalierungs- oder Einsparversprechen ersetzen diese Prüfung nicht. Die ergänzten Quellen dienen der Einordnung des Architekturkonzepts, nicht der Bestätigung eines konkreten Produkts. [2, 5]

Albert Absmeier & KI

Praxistipps für IT-Verantwortliche

Die folgenden Tipps sind redaktionelle Handlungsempfehlungen auf Basis der angegebenen Leitfäden, keine Zusicherung bestimmter Produkteigenschaften oder wirtschaftlicher Ergebnisse.

Mit einem abgegrenzten Anwendungsfall beginnen. Wählen Sie beispielsweise den Partnerzugriff auf eine interne Anwendung. Dokumentieren Sie Benutzergruppen, Endgeräte, Datenbedarf und bestehende Abhängigkeiten, bevor Sie einen Pilot starten. Die NIST-Beispielimplementierungen dienen als Orientierung für die Integration. [1, 11, 12]
Berechtigungen fachlich begründen. Halten Sie fest, wer welche Ressource für welche Aufgabe benötigt. Legen Sie Zuständigkeiten für Freigabe, regelmäßige Überprüfung und Entzug fest – auch für externe Konten und Dienstidentitäten. [1, 4, 12]
Die Qualität der Anmeldung prüfen. Bewerten Sie phishing-resistente MFA statt nur die Zahl aktivierter Faktoren. Das LSI empfiehlt insbesondere hardwarebasierte PKI-Zertifikate und FIDO2-Verfahren; berücksichtigen Sie dabei auch Registrierung und Wiederherstellung. [10, 12]
Kompatibilität im Pilot nachweisen. Testen Sie die tatsächlich benötigten Anwendungen, Protokolle, Endgeräte und Identitätsdienste. Prüfen Sie reguläre Nutzung und berechtigt verweigerte Zugriffe. Ein Architekturleitfaden ersetzt keinen Test Ihrer konkreten Umgebung. [4, 11]
Überwachung und Reaktion zusammen planen. Legen Sie fest, welche Anmeldungen, Freigaben und Ablehnungen ausgewertet werden und wer auf Auffälligkeiten reagiert. IAM-Auditing und Monitoring sind eigene Betriebsaufgaben, nicht bloß eine Zusatzfunktion des Zugriffsprodukts. [12]
Ausfälle und Kosten mitbewerten. Prüfen Sie im Pilot auch den Ausfall zentraler Zugriffs- und Identitätskomponenten sowie kontrollierte Notfallverfahren. Kalkulieren Sie Integration, Pflege und Betrieb über den Lebenszyklus. Das BSI weist auf den dauerhaften Ressourcenbedarf und die gesonderte Betrachtung der Verfügbarkeit hin. [2, 11]

Ausführliche Praxistipps mit Beispielen

Die folgenden Ausführungen vertiefen die sechs vorhandenen Tipps. Alle Praxisbeispiele sind fiktive, illustrative Szenarien, keine überprüften Unternehmensfälle. Maßnahmen und Prüfpunkte sind redaktionelle Vorschläge auf Grundlage der bereits angeführten Quellen; ihre technische Umsetzbarkeit muss in der jeweiligen Umgebung geprüft werden.

1. Mit einem abgegrenzten Anwendungsfall beginnen

Vorgehen. Beschreiben Sie zunächst die fachliche Aufgabe und die dafür benötigte Anwendung. Erfassen Sie beteiligte Benutzergruppen, Geräte, Daten und technische Abhängigkeiten – etwa Anmeldung, Dateiaustausch und Schnittstellen. Bestimmen Sie einen fachlichen und einen technischen Verantwortlichen. Vereinbaren Sie vor Beginn, welche erlaubten und unerlaubten Zugriffe geprüft werden und unter welchen Bedingungen der Pilot beendet oder zurückgesetzt wird. Damit wird der Pilot zu einem überprüfbaren Integrationsvorhaben statt zu einer bloßen Produktvorführung. Die NIST-Architekturen und der IAM-Leitfaden liefern dafür Grundlagen, aber keinen fertigen Plan für die eigene Umgebung. [1, 11, 12]

[Speculation] Fiktives Praxisbeispiel. Ein Unternehmen möchte einem externen Projektpartner Zugriff auf eine interne Dokumentenanwendung geben. Im vorgeschlagenen Pilot darf das Partnerkonto nur den zugeordneten Projektbereich nutzen; weitere Fachanwendungen bleiben außerhalb der Freigabe. Vor dem Start dokumentiert das Team, ob Anmeldung und Dateiübertragung zusätzliche Dienste benötigen. Es prüft anschließend mit Testkonten sowohl den vorgesehenen Zugriff als auch die Ablehnung eines nicht berechtigten Kontos. Prüfbares Ergebnis: ein abgestimmter Anwendungssteckbrief und ein Testprotokoll mit erlaubten Zugriffen, Ablehnungen und offenen Abhängigkeiten.

2. Berechtigungen fachlich begründen

Vorgehen. Übersetzen Sie Aufgaben in konkrete Zugriffsrechte: Anwendung, Datenbereich und erlaubte Aktion. Die Freigabe einer Anwendung ist nicht automatisch eine Freigabe aller darin verfügbaren Funktionen oder Daten. Prüfen Sie deshalb zusätzlich die Berechtigungen innerhalb der Anwendung. Dokumentieren Sie Anlass, Genehmigung und Überprüfungstermin einer Freigabe. Berücksichtigen Sie Wechsel von Aufgaben, Projektende und Ausscheiden sowie technische Dienstidentitäten. Befristungen und automatisierter Entzug sind als Anforderungen zu testen, nicht als allgemeine ZTAA-Eigenschaften vorauszusetzen. Identitätsverwaltung und anwendungsbezogene Autorisierung bilden die fachliche Grundlage. [1, 4, 12]

[Speculation] Fiktives Praxisbeispiel. In einem Partnerportal benötigt ein Lieferant Einsicht in seine eigenen Bestellungen, aber keine Einsicht in Bestellungen anderer Lieferanten. Das vorgeschlagene Konzept trennt die Zulassung zum Portal von der mandantenbezogenen Datenberechtigung im Portal. Der Einkauf genehmigt den fachlichen Bedarf; die IT dokumentiert die technische Umsetzung. Nach Projektende wird mit einem Testkonto geprüft, ob neue Anmeldungen und gegebenenfalls vorhandene Sitzungen entsprechend der festgelegten Regel behandelt werden. Prüfbares Ergebnis: eine Berechtigungsmatrix mit Verantwortlichen und dokumentierten Entzugstests.

3. Die Qualität der Anmeldung prüfen

Vorgehen. Bewerten Sie das eingesetzte Authentifizierungsverfahren, nicht nur das Vorhandensein mehrerer Faktoren. Der LSI-Leitfaden empfiehlt phishing-resistente Verfahren, darunter FIDO2 und hardwarebasierte PKI-Zertifikate. Prüfen Sie die Unterstützung durch Identitätsdienst, Anwendungen und Endgeräte. Planen Sie außerdem sichere Erstregistrierung, Verlustmeldung, Sperrung und Wiederherstellung. Ein Wiederherstellungsprozess sollte nicht durch eine ungeprüfte Ausnahme die festgelegten Anmeldeanforderungen umgehen. Dokumentieren Sie, wer Ersatzmittel freigeben darf und welche Identitätsprüfung dafür vorgesehen ist. [10, 12]

[Speculation] Fiktives Praxisbeispiel. Ein Unternehmen plant FIDO2-Sicherheitsschlüssel für den Zugriff auf eine sensible Verwaltungsanwendung. Im Pilot werden Anmeldung und Registrierung auf den tatsächlich verwendeten Geräten getestet. Für einen verlorenen Schlüssel sieht das vorgeschlagene Verfahren die dokumentierte Identitätsprüfung, Sperrung des alten Mittels und kontrollierte Registrierung eines Ersatzes vor. Der Helpdesk erhält dafür einen abgestimmten Ablauf statt einer spontanen Ausnahmeentscheidung. Prüfbares Ergebnis: erfolgreiche Anmeldetests sowie ein vollständig protokollierter Wiederherstellungstest ohne informelle Umgehung der Vorgaben.

4. Kompatibilität im Pilot nachweisen

Vorgehen. Erstellen Sie eine Testmatrix aus Anwendungen, Protokollen, Gerätekategorien und Identitätsdiensten. Berücksichtigen Sie nicht nur die Anmeldung, sondern den gesamten Arbeitsablauf: Navigation, Dateiübertragung, Schnittstellen und gegebenenfalls länger laufende Sitzungen. Legen Sie fest, wie fehlende oder veraltete Gerätesignale behandelt werden sollen. Testen Sie bewusst auch nicht berechtigte Zugriffe. Prüfen Sie für jede Anforderung, welche Komponente sie durchsetzt und wo Grenzen bestehen. Die NIST-Beispiele zeigen Integrationswege und Anwendungsidentitäten, belegen aber nicht die Kompatibilität einer beliebigen Altanwendung. [4, 11]

[Speculation] Fiktives Praxisbeispiel. Eine ältere Warenwirtschaft besteht aus einer Browseroberfläche und einem zusätzlichen Dienst für den Dokumentenexport. Der vorgeschlagene Pilot prüft beide Teile getrennt. Ein erfolgreicher Login gilt erst dann als ausreichender Funktionsnachweis, wenn auch der benötigte Export mit den vorgesehenen Rechten funktioniert. Zusätzlich wird getestet, ob ein nicht freigegebenes Konto abgewiesen wird. Prüfbares Ergebnis: eine dokumentierte Entscheidung je Funktion: unterstützt, nur mit Anpassung unterstützt oder derzeit nicht abgedeckt. Nicht abgedeckte Anforderungen bleiben als offene Punkte sichtbar.

5. Überwachung und Reaktion zusammen planen

Vorgehen. Bestimmen Sie, welche Ereignisse für Betrieb und Zugriffsprüfung benötigt werden: etwa erfolgreiche und abgewiesene Anmeldungen, Richtlinienänderungen und Berechtigungsentzug. Prüfen Sie, ob die zuständigen Systeme diese Ereignisse mit nachvollziehbaren Identitäts- und Ressourcenangaben bereitstellen. Vereinbaren Sie Zuständigkeit, Bewertung und Eskalation; ein Alarm allein ist noch keine bearbeitete Störung. Regeln Sie außerdem den Zugriff auf Protokolle und die Aufbewahrung entsprechend den betrieblichen und rechtlichen Anforderungen. Der NSA/CISA-Leitfaden behandelt IAM-Auditing und Monitoring als eigenständige Aufgaben. [12]

[Speculation] Fiktives Praxisbeispiel. Ein Partnerkonto erzeugt in einem Test mehrere Zugriffsablehnungen auf eine nicht freigegebene Anwendung. Das vorgeschlagene Betriebskonzept sieht vor, zunächst Richtlinie, Kontozuordnung und mögliche Bedienfehler zu prüfen, statt die Ereignisse automatisch als Angriff zu bewerten. Ein benannter Verantwortlicher dokumentiert die Prüfung und entscheidet anhand des vereinbarten Verfahrens über weitere Maßnahmen. Prüfbares Ergebnis: ein durchgespielter Ereignisablauf vom Protokolleintrag über die Zustellung an die zuständige Stelle bis zum nachvollziehbaren Abschluss.

6. Ausfälle und Kosten mitbewerten

Vorgehen. Erfassen Sie Abhängigkeiten von Identitätsdienst, Zugriffsvermittlung, Netzverbindung und Anwendung. Vereinbaren Sie für kritische Arbeitsabläufe, wie bei Ausfällen vorzugehen ist, wer Notfallentscheidungen genehmigt und wie die reguläre Zugriffspolitik wiederhergestellt wird. Prüfen Sie mögliche Notfallverfahren in einer kontrollierten Testumgebung. Stellen Sie den Investitionskosten die laufenden Aufwände für Integration, Richtlinienpflege, Support, Überwachung und Tests gegenüber. Eine Aussage über Wirtschaftlichkeit benötigt einen nachvollziehbaren Vergleich mit dem bisherigen Betrieb; pauschale Einsparungen lassen sich daraus nicht ableiten. Das BSI betont dauerhaften Ressourcenbedarf und die gesonderte Betrachtung der Verfügbarkeit. [2, 11]

[Speculation] Fiktives Praxisbeispiel. Für eine kritische Auftragsanwendung wird im Test ein Ausfall des zentralen Identitätsdienstes simuliert. Das Team dokumentiert, ob neue Anmeldungen und bestehende Sitzungen entsprechend dem gewählten Betriebsmodell reagieren. Ein gegebenenfalls vorgesehenes Notfallverfahren wird auf Genehmigung, zeitliche Begrenzung, Protokollierung und Rückkehr zum Normalbetrieb geprüft. Parallel werden Einführungsaufwand und laufende Betriebsaufgaben erfasst. Prüfbares Ergebnis: ein abgestimmter Wiederanlaufplan und eine Kostenübersicht mit offengelegten Annahmen statt eines unbelegten Einsparversprechens.

FAQ: Zehn Fragen zu ZTAA

1. Was bedeutet ZTAA in diesem Beitrag?

ZTAA steht hier für Zero Trust Application Access: den anwendungsbezogenen Einsatz von Zero-Trust-Prinzipien. Gegenstand der Zugriffsentscheidung ist eine konkrete Anwendung oder ein Dienst, nicht allein ein Netzwerksegment. NIST SP 800-207 liefert die übergeordneten Grundlagen zu Identität, Endgerät und Ressourcenschutz. Diese Referenz wird hier nicht als Nachweis einer eigenständigen standardisierten ZTAA-Produktklasse verwendet. [1]

2. Worin unterscheidet sich ZTAA von ZTNA?

Eine pauschale Trennung nach »Anwendung« und »Netzwerk« wäre irreführend: Auch ZTNA kann Zugriffe auf einzelne Anwendungen nach Identität und Kontext begrenzen. Die im Artikel gekennzeichnete Herstellerquelle beschreibt genau einen solchen Ansatz. Für einen Vergleich sollten Unternehmen deshalb Richtliniendurchsetzung, Gerätesignale, Protokollunterstützung und Betriebsmodell untersuchen. Aus den Kürzeln allein lässt sich keine technische Überlegenheit ableiten. [6, 11]

3. Muss ein Unternehmen sein VPN sofort ablösen?

Ein sofortiger Komplettaustausch ist keine Empfehlung dieses Beitrags. Die Entscheidung sollte je Anwendungsfall erfolgen: Welche Zugriffe werden benötigt, welche Abhängigkeiten bestehen und welche Kontrollen lassen sich durchsetzen? Die NIST-Leitfäden behandeln unterschiedliche Fernzugriffs- und Zero-Trust-Architekturen. Für weiterhin eingesetzte VPN-Zugänge bleiben Absicherung, Aktualisierung und starke Authentifizierung relevant. Ein stufenweiser Pilot ist hier eine redaktionelle Umsetzungsempfehlung. [7, 9, 11]

4. Reicht Multi-Faktor-Authentifizierung für Zero Trust aus?

Nein. MFA unterstützt die Identitätsprüfung, entscheidet aber nicht allein über die Berechtigung für eine Anwendung. NIST unterscheidet Authentifizierung und Autorisierung; das CISA-Modell betrachtet zusätzlich Geräte, Netzwerke, Anwendungen und Daten. Zudem sind MFA-Verfahren nicht gleichwertig. Das LSI empfiehlt vorzugsweise standardbasierte, hardwarebasierte und phishing-resistente Verfahren, insbesondere hardwarebasierte PKI-Zertifikate und FIDO2. [1, 3, 10]

5. Wie lassen sich private Geräte und externe Partner einbinden?

BYOD und externe Zugriffe gehören zu den ausdrücklich behandelten Zero-Trust- und Fernzugriffsszenarien bei NIST. Entscheidend sind nachvollziehbare Identitäten, passende Berechtigungen und Anforderungen an die eingesetzten Geräte. Dafür sollten Unternehmen festlegen, welche Anwendungen mit welchen Endgeräten genutzt werden dürfen und wie externe Konten gepflegt werden. Bei organisationsübergreifender Vernetzung fordert das BSI eine verbindliche Abstimmung der Zero-Trust-Konzepte und hebt Interoperabilität hervor. [1, 2, 7, 12]

6. Gilt anwendungsbezogenes Zero Trust auch für APIs und Dienste?

Ja, der Ressourcenschutz beschränkt sich nicht auf die interaktive Anmeldung von Menschen. NIST SP 800-207A beschreibt Authentifizierungs- und Autorisierungsregeln auf Basis von Anwendungs- und Dienstidentitäten. Als Architekturbausteine nennt die Veröffentlichung unter anderem API-Gateways, Sidecar-Proxys und Anwendungsidentitätsinfrastrukturen. Sie behandelt granulare Regeln für lokale, hybride und Multi-Cloud-Umgebungen; daraus folgt keine Pflicht, sämtliche genannten Bausteine in jeder Umgebung einzusetzen. [4]

7. Sind ausschließlich ausgehende Verbindungen zwingend?

Sie sind im Artikel eine belegte Architekturvariante, keine allgemeine Definition von ZTAA. Die Herstellerquelle beschreibt ausgehende Verbindungen eines SDP-Brokers beziehungsweise Proxys. NIST dokumentiert unterschiedliche Zero-Trust-Umsetzungen. Bei der Auswahl sollten Unternehmen den tatsächlichen Verbindungsweg, freigegebene Schnittstellen und die Durchsetzung der Zugriffspolitik prüfen. Die Richtung des Verbindungsaufbaus allein ist kein Nachweis für die Sicherheit der gesamten Infrastruktur. [6, 11]

8. Welche organisatorischen Voraussetzungen sind wichtig?

Ressourcen und Benutzergruppen müssen bekannt sein; Berechtigungen benötigen fachliche Verantwortliche. Hinzu kommen Prozesse für Identitätsverwaltung, Freigaben und Überwachung. Der gemeinsame NSA/CISA-IAM-Leitfaden behandelt Identity Governance, Federation und Single Sign-on, MFA sowie Auditing und Monitoring als zusammenhängende Aufgaben. Das CISA-Reifegradmodell bietet eine übergreifende Orientierung. Diese Grundlagen sollten vor einer breiten technischen Einführung geklärt werden. [3, 12]

9. Wie kann das Management Fortschritte bewerten?

Als redaktionelle Vorschläge eignen sich die Abdeckung kritischer Anwendungen durch definierte Zugriffsregeln, der Anteil regelmäßig überprüfter Berechtigungen, die Nutzung phishing-resistenter MFA und die Zeit bis zum Entzug nicht mehr benötigter Zugänge. Ergänzend sollten Fehlablehnungen, Betriebsstörungen und Supportaufwand erfasst werden. Diese Kennzahlen sind keine vorgeschriebenen ZTAA-Standards; sie übersetzen die Governance-, Authentifizierungs- und Monitoring-Aufgaben der Quellen in überprüfbare Projektziele. [3, 10, 12]

10. Welche Kosten und Grenzen müssen berücksichtigt werden?

Zero Trust ist laut BSI keine Einmalinvestition, sondern benötigt dauerhaft finanzielle und personelle Ressourcen. Zu bewerten sind deshalb nicht nur Lizenzen, sondern auch Integration, Richtlinienpflege, Identitätsprozesse und Betriebsaufgaben. Die BSI-Einordnung richtet die Schutzwirkung vorrangig auf Vertraulichkeit und Integrität, nicht auf Verfügbarkeit. Ausfallsicherheit und Wiederanlauf sind folglich gesondert zu planen. Konkrete Einsparungen oder Schutzwirkungen einer Lösung müssen in der jeweiligen Umgebung nachgewiesen werden. [2, 11]

Quellen und weiterführende Informationen

[1] NIST: SP 800-207 – Zero Trust Architecture, finale Veröffentlichung, August 2020. Belegstellen: Abstract zu ressourcenbezogenem Schutz, getrennter Authentifizierung und Autorisierung sowie Fernzugriff, BYOD und Cloud. URL: https://csrc.nist.gov/pubs/sp/800/207/final. Quellenprüfung: 6. November 2026.

[2] BSI: Zero Trust, Themenseite mit Verweis auf das Positionspapier Zero Trust 2023. Belegstellen: minimale Rechte, Integrität und Vertraulichkeit, dauerhafter finanzieller und personeller Ressourcenbedarf sowie organisationsübergreifende Abstimmung und Interoperabilität. URL: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Zero-Trust/zero-trust.html. Quellenprüfung: 6. November 2026.

[3] CISA: Zero Trust Maturity Model, Version 2.0, 11. April 2023. Belegstellen: anfragebezogene Zugriffsentscheidungen mit minimalen Rechten, datenzentrische Kontrollen sowie fünf Säulen und drei Querschnittsfähigkeiten. URL: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model. Quellenprüfung: 6. November 2026.

[4] NIST: SP 800-207A – A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments, finale Veröffentlichung, September 2023. Der Titel folgt dem veröffentlichten PDF; die CSRC-Webseite verwendet abweichend »Multi-Cloud Environments«. Belegstelle: Abstract zu granularen Anwendungsrichtlinien und Anwendungs- und Dienstidentitäten in lokalen und Multi-Cloud-Umgebungen. URL: https://csrc.nist.gov/pubs/sp/800/207/a/final. Quellenprüfung: 6. November 2026.

[5] NIST: SP 1800-35 – Implementing a Zero Trust Architecture: Architecture and Builds, ergänzende Webdokumentation zum finalen Leitfaden, Juni 2025. Belegstellen: Einleitung zum schrittweisen Aufbau, identitätsbezogenen Kontrollen, Mikrosegmentierung, SDP und SASE sowie Abschnitt »General ZTA Reference Architecture«. Die Dokumentation beschreibt Beispiele, keine universell beste Lösung oder Produktempfehlung. URL: https://pages.nist.gov/zero-trust-architecture/VolumeB/architecture.html. Quellenprüfung: 6. November 2026.

[6] Versa Networks: What is Zero Trust Network Access (ZTNA)?, undatierte Hersteller-Webseite. Belegstelle: »How Does ZTNA Work?« zu anwendungsbezogenem Zugriff nach Identität und Kontext sowie der Komponentenliste mit ausgehenden SDP-Broker-/Proxy-Verbindungen. Die Quelle belegt Herstellerangaben zu einer Architekturvariante, keine unabhängige Sicherheitsbewertung und keine allgemeine ZTAA-Definition. URL: https://versa-networks.com/sase/ztna/. Quellenprüfung: 6. November 2026.

[7] NIST: SP 800-46 Rev. 2 – Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security, finale Veröffentlichung, Juli 2016. Grundlagen zu Fernzugriffsarchitekturen, der Absicherung ihrer Komponenten und Endgeräte sowie Sicherheitsrichtlinien für Beschäftigte und externe Beteiligte. Die Publikationsseite führt zusätzlich eine Revision 3 als Entwurf auf. URL: https://csrc.nist.gov/pubs/sp/800/46/r2/final. Quellenprüfung: 6. November 2026.

[8] CISA: Identify and Monitor Remote Access Tools (CM0036), Version 1.0, März 2025. Belegstellen: »Introduction« und »Guidance« zur Erfassung von Fernzugriffswerkzeugen einschließlich RDP, Protokollierung und Überwachung sowie Leerlauf-Zeitüberschreitungen. URL: https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0036. Quellenprüfung: 6. November 2026.

[9] NSA/CISA: NSA, CISA Release Guidance on Selecting and Hardening Remote Access VPNs, 28. September 2021. Offizielle Veröffentlichungsmitteilung zum gemeinsamen Leitfaden »Selecting and Hardening Remote Access VPN Solutions«; Belege für VPN-Absicherung, starke Authentifizierung einschließlich MFA und zeitnahe Aktualisierungen. URL: https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/2791320/nsa-cisa-release-guidance-on-selecting-and-hardening-remote-access-vpns/. Quellenprüfung: 6. November 2026.

[10] LSI: Leitfaden »Phishing-resistente Multifaktor-Authentifizierung«, Version 1.1, Stand 7. Juni 2024. Belegstellen: Management Summary und Verfahrensempfehlungen. URL: https://www.lsi.bayern.de/mam/aktuelles/leitfaden_phishing-resistente-mfa_v1-1.pdf. Quellenprüfung: 6. November 2026.

[11] NIST: SP 1800-35 – Implementing a Zero Trust Architecture: High-Level Document, finale Veröffentlichung, Juni 2025. Belegstellen: Abstract zu 19 Beispielimplementierungen mit 24 Kooperationspartnern sowie technischen Integrationen und Erkenntnissen. URL: https://csrc.nist.gov/pubs/sp/1800/35/final. Quellenprüfung: 6. November 2026.

[12] NSA/CISA: Identity and Access Management: Recommended Best Practices for Administrators, März 2023. Belegstellen: Identity Governance; Identity Federation and Single Sign-On; Multi-Factor Authentication; IAM Auditing and Monitoring. URL: https://media.defense.gov/2023/Mar/21/2003183448/-1/-1/0/CSI_IDENTITY_AND_ACCESS_MANAGEMENT.PDF. Quellenprüfung: 6. November 2026.

Management Summary, Tipps, FAQ und Bilder wurden mit Hilfe von KI erstellt

1518 Artikel zu „Zero Trust“

Healthcare IT | Infrastruktur | IT-Security | Kommunikation | News

TI 2.0 und Cybersicherheit: Was VSDM 2.0, PoPP und Zero Trust für Primärsysteme bedeuten

18. Juli 2026

Die Telematikinfrastruktur (TI) vernetzt Praxen, Apotheken, Kliniken und Krankenkassen im deutschen Gesundheitswesen. Die nächste Ausbaustufe TI 2.0 bringt neue Verfahren wie VSDM 2.0, die elektronische Prüfung und Aktualisierung der Versichertenstammdaten, PoPP, den Nachweis, dass ein Patient vor Ort ist, und ZETA – Zero Trust Access, ein Sicherheitsmodell, das jeden Zugriff einzeln prüft. Für Hersteller von…