Dieses Dokument ist ein früher Entwurf (Early Draft) und wird aktiv überarbeitet. Es basiert auf der Referenzarchitektur Sicherheitsinfrastruktur (Version 0.82, Stand 28.03.2025) des BMI.
Erstellt am: 26. März 2026 | Zuletzt geändert: 26. März 2026
Fachanwendungen absichernfeedback
Dieses Dokument beschreibt den DA-Anwendungsfall „Fachanwendungen absichern", also die Anbindung und den Schutz von Basis- und Fachanwendungen der Bundesverwaltung an die zentrale Sicherheitsinfrastruktur unter Beachtung der Zero-Trust-Prinzipien.
info Einordnung als DA-Anwendungsfallfeedback
| Aspekt | Beschreibung |
|---|---|
| Anwendungsfall | Absicherung von Basis- und Fachanwendungen der Bundesverwaltung |
| Beteiligte Capabilities | Sicherheit, Identitätsmanagement, Plattformbetrieb, Netzinfrastruktur |
| Funktionsbausteine | Zero-Trust-Governance, IAM, PKI, Zero-Trust-Governance (SASEBund), Detektion und Reaktion (DaaS), SSO für Behörden, Machine Identity |
| Stakeholder | Domänenarchitekten, Lösungsarchitekten, ITZBund, BSI, BDBOS |
| Architekturmuster | App-Gateway → Zero-Trust-Architektur (ZTA) |
1. Ausgangssituation und Motivationfeedback
Die IT-Strategie Bund fordert die Hoheit und Kontrollfähigkeit über IT-Systeme, Informationen und Daten der Bundesverwaltung zu jeder Zeit. Im Rahmen der IT-Konsolidierung Bund und der Gemeinsamen IT des Bundes (GIB) werden zentrale IT-Systeme bereitgestellt und mit bestehenden IT-Landschaften verbunden. Zusätzlich soll die medienbruchfreie Zusammenarbeit mit Ländern und EU-Behörden ermöglicht werden.
Die daraus erwachsende Komplexität der IT-Landschaft erfordert einen Security-by-Design-Ansatz. Im Kern geht es um die Einführung von Zero Trust, einer Methode mit weitreichenden identitätszentrierten Sicherheitskontrollen, die über herkömmliche Netzwerkperimeter-Absicherungen hinausgehen und die Ausbreitung erfolgreicher Angriffe erheblich erschweren.
Die Referenzarchitektur Sicherheitsinfrastruktur konzentriert sich auf Aspekte zu Data-in-Transit inkl. Data Loss Prevention. Themen zu Data-in-Rest und Data-in-Compute (Enclave Computing) sind vorerst nicht betrachtet.
architecture 2. Architekturrahmenfeedback
2.1 Funktionale Grundstrukturfeedback
Die Sicherheitsinfrastruktur basiert auf dem Zusammenspiel folgender Dienste der Domäne Infrastruktur:
| Dienst | Funktion |
|---|---|
| Personaladministration (ERP) | Erfasst personenbezogene Informationen und stellt dem IAM die Daten zur Berechnung des Unique Identifiers (UID) zur Verfügung |
| PKI | Sichere Zertifikatsverwaltung; stellt dem Dienstausweis personenbezogene Zertifikate für qualifizierte digitale Identitäten bereit |
| Dienstausweis (meDA) | Speichermedium für personenbezogene Daten und signierte UID; dient als Authentifizierungsmittel |
| Identity-Access-Management (IAM) | Zentrale Verwaltung von Identitäten; prüft UID-Signatur über PKI; verwaltet Attribute für Autorisierung |
| Zero-Trust-Governance | Autorisiert Netz- und Anwendungszugriffe basierend auf Identität, Gerätezustand und Bedrohungsinformationen |
| Detektion und Reaktion (DaaS) | Einsammeln und Auswerten von Logging-Daten; Echtzeit-Bedrohungsanalyse |
2.2 Zero-Trust-Prinzipienfeedback
Die folgenden Prinzipien (nach NIST 800-207 und ISO 29149) bilden das Fundament:
- „Assume Breach": Entscheidungen werden unter der Annahme getroffen, dass Systeme wahrscheinlich kompromittiert sind
- „Never Trust, Always Verify": Vor allen Zugriffen auf Ressourcen wird die Identität bestätigt
- „Verify Explicitly and Continuously": Einmal erteilte Rechte werden nicht zeitlich unbegrenzt erteilt
- „Apply Least Privilege": Zugriffsrechte auf das notwendige Mindestmaß reduzieren
- „Probabilistic and Explainable Security Decisions": Zugriffsentscheidungen basieren auf messbaren Sicherheitsparametern
- „Transparency": Bereitschaft zur Transparenz zwischen Föderationspartnern
2.3 ZTA-Rollen der Dienstefeedback
Die Dienste werden den Zero-Trust-Bausteinen PEP (Policy Enforcement Point), PDP (Policy Decision Point) und PIP (Policy Information Point) zugeordnet:
| Rolle | Dienst | Aufgabe |
|---|---|---|
| PIP | Personaladministration | Personalstammdaten für Identitätsinitialisierung |
| PIP | IAMBund | Identitäts- und Attributdaten für Authentifizierung und Autorisierung |
| PIP | PKI | Digitale Zertifikate für Identitätsprüfung und sichere Kommunikation |
| PIP | Detektion & Reaktion | Echtzeitinformationen zu Anomalien und Bedrohungen |
| PDP | Zero-Trust-Governance | Kontextbezogene Zugriffsentscheidungen; dynamische Richtlinienanpassung |
| PEP | SASEBund / PEP-Gateway | Durchsetzung der Zugriffsentscheidungen |
3. IT-Lösungen der Sicherheitsinfrastrukturfeedback
3.1 IAMBundfeedback
Die IT-Lösung setzt die Funktionalitäten des Dienstes Identity-Access-Management für die GIB um:
- Identitätsverwaltung: Erzeugt eineindeutige Nutzerkennungen (UID) unter Nutzung der Personalverwaltungssysteme gemäß BSI TR-03107
- Authentifizierung: Erfolgt gemäß OpenID Connect (OIDC); nach Anmeldung werden ID-Token und Access-Token ausgestellt (zeitlich begrenzt, Zero-Trust-konform)
- Autorisierung: Kombination aus RBAC (initiale Zugriffsentscheidung) und ABAC (feingranulare, dynamische Autorisierung)
- Multi-Faktor-Authentifizierung (MFA): Durch Integration personenbezogener Zertifikate (Dienstausweis)
- Step-up Authentication: Bei besonders sensiblen Zugriffen kann eine zusätzliche Authentifizierungsebene eingeführt werden
3.2 Dienstausweis (meDA)feedback
Multifunktionaler elektronischer Dienstausweis mit Nachladefähigkeit:
- Träger von digitalen Zertifikaten und Schlüsseln als Authentifizierungsmittel
- Enthält die vom IAMBund generierte signierte UID
- Ermöglicht Identitätsnachweis und Multi-Faktor-Authentifizierung
3.3 Public Key Infrastructure (PKI)feedback
Die PKI stellt Zertifikate aus, verifiziert deren Gültigkeit und bindet kryptografische Schlüssel an geprüfte Identitäten:
| Anwendungsfall | Beschreibung |
|---|---|
| Benutzer-Authentisierung | Benutzer-Zertifikat gegenüber IAMBund |
| Geräte-Authentisierung | Geräte-Zertifikat gegenüber SASEBund |
| TLS / mTLS | Aufbau authentisierter und verschlüsselter Kommunikationsbeziehungen |
| S/MIME | Signatur und Verschlüsselung von E-Mails |
| E-Signatur | Siegel-Signatur-Zertifikat |
Zentral ist die Zertifikatsverwaltung (Certificate Lifecycle Management, CLM): sichere Schlüsselgenerierung, Zertifikatsausstellung, -verteilung, -widerruf und automatisierte Erneuerung.
Zusammenwirken mit eIDAS: Die Sicherheitsinfrastruktur kann eIDAS-konforme Prozesse bei der Identifizierung nachnutzen, sodass auf Anwendungsebene Vertrauensdienste (z. B. qualifizierte digitale Signaturen) bereitstehen.
3.4 Detection as a Service (DaaS)feedback
DaaS bezieht sich auf das Einsammeln und Auswerten von Logging-Daten sowie die zentrale Überwachung:
- Aggregierte Sicht auf Zugriffsprotokolle, Sicherheitswarnungen und Benutzerverhalten
- Bereitstellung eines Bedrohungslevels in Echtzeit
- Unterstützt dynamische Anpassung von Sicherheitsrichtlinien
- Kann durch Machine-Learning-Mechanismen verbessert werden
3.5 SASEBund (Secure Access Service Edge)feedback
SASEBund ist eine Netz-Infrastruktur mit integrierten Sicherheitsfunktionen:
| Funktion | Beschreibung |
|---|---|
| ZTNA / ZTAA | Identitäts-, kontext- und richtlinienbasierter sicherer Zugriff auf Anwendungen via PEP-Agent und PEP-Gateway |
| Administration Center (AC/PAP) | Zentrale Verwaltung feingranularer Sicherheitsrichtlinien; Federation Master für externe IDPs |
| CASB | Cloud Access Security Broker; analysiert und kontrolliert Datenverkehr zu SaaS-Diensten (auch ohne Föderation) |
| SWG / RBI | Secure Web Gateway und Remote Browser Infrastructure für gesicherten Internet-Zugang |
PEP-Agent: Auf Endgeräten installiert; signiert alle ausgehenden Kommunikationen; fügt kontextuelle Informationen hinzu (Standort, Gerätezustand). Kann als L4 TCP Proxy, L7 DNS/HTTP Proxy agieren; sammelt Geräteinformationen; unterstützt Split-Mode.
PEP-Gateway: Policy-Enforcement-Point für Netzsegmente (ZTNA) oder einzelne Anwendungen/API-Endpunkte (ZTAA). Baut Verbindungen von innen nach außen auf und bewertet Zugriffe kontinuierlich in Zusammenarbeit mit dem PDP.
4. Technischer Ablauf: Fachanwendung absichernfeedback
4.1 Variante ohne Zero-Trust (klassisches App-Gateway)feedback
In der klassischen Architektur vermittelt ein zentrales App-Gateway zwischen Clients und Backend-Diensten:
- Anfrage: Client-Anwendung sendet Anfrage an App-Gateway
- Authentisierung: SignaturApp liest UID-Zertifikat vom Dienstausweis; PIN-Eingabe; IAMBund prüft Zertifikat via PKI und stellt ID-Token aus
- Zugriffs-Autorisierung: Client beantragt mit ID-Token ein Access-Token beim IAMBund (statische Regeln)
- Zugriff: App-Gateway prüft Access-Token und erlaubt Zugriff (keine dynamische Überwachung)
- Anwendungsdaten: Anwendung prüft Token und liefert Daten direkt an Client
Einschränkungen: Statische Regeln, zentraler Flaschenhals, begrenzte feingranulare Zugriffskontrolle.
4.2 Variante mit Zero-Trust-Architektur (Zielbild)feedback
Die Transformation überführt das App-Gateway in spezialisierte, dynamische Komponenten:
| Schritt | Klassisch (App-Gateway) | Zero-Trust (Zielbild) |
|---|---|---|
| 1. Anfrage | Client sendet Anfrage direkt an Gateway | PEP-Agent signiert Anfrage, fügt Kontext hinzu (Standort, Gerätezustand) |
| 2. Authentisierung | IAMBund prüft Zertifikat, stellt ID-Token aus | Identisch; zusätzlich kann Step-up-MFA bei erhöhtem Risiko verlangt werden |
| 3. Autorisierung | IAMBund erstellt Access-Token anhand statischer Regeln | PDP erstellt Access-Token based auf kontextbezogenen Regeln; PEP-Gateway wird konfiguriert |
| 4. Zugriff | App-Gateway prüft Token einmalig | PEP-Gateway prüft kontinuierlich; Zugriff kann bei veränderten Bedingungen widerrufen werden |
| 5. Daten | Daten direkt an Client | Datenfluss durch PEP-Gateway kontrolliert und verschlüsselt |
4.3 Single Sign-On (SSO)feedback
SSO folgt dem Zero-Trust-Ablauf mit folgenden Erweiterungen:
- Initiale Authentifizierung beim IDP (IAMBund) → ID-Token → SASEBund stellt anwendungsspezifisches Access-Token aus
- Zugriff auf zweite Anwendung: SASEBund prüft ob ID-Token/Refresh-Token gültig ist, ob sich der Sicherheitskontext geändert hat, und stellt ggf. neues Access-Token aus
- Kontextüberprüfung: Bestehende Access-Tokens können ungültig werden bei geändertem Bedrohungslevel oder Compliance-Status
4.4 On-Behalf-of (Delegation)feedback
Wenn Dienste im Namen von Nutzern auf andere Dienste zugreifen:
- Nutzer authentisiert sich am IAMBund → Access Token für Dienst A
- Dienst A führt Token Exchange beim IAMBund durch (RFC 7521/7522 bzw. RFC 8693)
- IAMBund prüft Berechtigung und Kontext → kurzlebiges On-Behalf-of-Token für Dienst B
- Dienst B validiert Token über IAMBund/PDP und führt Anfrage mit Rechten der Person aus
- Token ist zeitlich beschränkt und kann bei Sicherheitsereignissen entwertet werden
public 5. Föderiertes IAMfeedback
In der Praxis liegen nicht alle Aspekte der Identitäts- und Zugriffsverwaltung in einer Hand. Das föderierte IAM adressiert:
- Externe Behörden/Partner mit eigenem IDP
- SaaS-Dienste mit eigenem User-Access-Management
- Externe Geräte ohne eigenes Gerätemanagement
5.1 Föderationsprinzipienfeedback
- Identitätsnachweis durch Heimat-IDP: Die Heimatorganisation prüft die Identität und stellt ein ID-Token aus
- Prüfung durch SASEBund (Federation Master): Validiert das ID-Token und vergibt ein Access-Token für die gewünschten Dienste
- Autorisierung in Fachanwendungen: Anwendungen vertrauen auf SASEBund; es werden generische Zugriffsrichtlinien oder konkrete Rollenzuordnungen für Föderations-Accounts konfiguriert
5.2 Nicht-föderierte Dienste absichernfeedback
Wenn eine direkte Identitätsföderation nicht möglich ist:
| Mechanismus | Beschreibung |
|---|---|
| CASB-Funktion | SASEBund analysiert und kontrolliert Datenverkehr zu SaaS-Diensten (DLP, Anomalie-Erkennung, Zugriffsbeschränkungen) |
| Remote Browser Isolation (RBI) | Browser-Sitzungen laufen in isolierter Serverumgebung; nur sichere Darstellungsinformationen gelangen zum Endgerät |
| Adaptive Zugriffssteuerung | Zusätzliche Step-up-Authentifizierungen bei weniger vertrauenswürdigen IDPs oder erhöhtem Risiko |
6. Kontinuierliche Überwachungfeedback
Alle sicherheitsrelevanten Informationen fließen kontinuierlich zu DaaS als zentralem PIP:
| Quelle | Datenfluss |
|---|---|
| SASEBund / PDP | Überwachungsrelevante Informationen aus Autorisierungsvorgängen |
| IAMBund | Fehlgeschlagene Anmeldeversuche, Identitätsanalysen |
| PKI | Zertifikatsausstellung, Sperrungen |
| Basis-/Fachanwendungen | Anwendungsspezifische Logdaten (jede angebundene Anwendung muss DaaS nutzen) |
| Gerätemanagement | Gerätezustand und Compliance-Status |
DaaS ermöglicht:
- Zentralisierte Sichtbarkeit aller Anwenderaktivitäten
- Echtzeit-Risikoanalyse bei allen Autorisierungsentscheidungen
- Integration von Analysen über mehrere Sensortypen mit automatisch konfigurierten Policies und Triggern
- Metadaten- und kontextbasierte Filterung des Netzverkehrs (Anomalie-Erkennung)
7. Integration in die Zonenarchitektur des Bundesfeedback
Die aktuelle Zonenarchitektur definiert verschiedene Schutzzonen:
- Internet, Schutzbedarf Hoch
- Intern, Schutzbedarf Normal
- Intern, Schutzbedarf Hoch
- Intern, Schutzbedarf Hoch + VS-NfD
- Intern, Schutzbedarf Sehr Hoch
SASEBund ermöglicht einen Cloud-Plattform-übergreifenden Zero-Trust-Ansatz. Implementierungspfade umfassen:
| Pfad | Beschreibung |
|---|---|
| Datenverkehr und SaaS absichern | Kontrolle des Datenverkehrs zu internen und externen SaaS-Angeboten |
| VPN ersetzen | PEP-Agent auf Endgeräten + PEP-Gateways in Zonen; Zonen in feingranulare Segmente aufteilen |
| Web-Zugriff absichern | Internet-Proxy / ReCoBS durch SWG und RBI ersetzen |
Zero Trust innerhalb der Zonenarchitektur ermöglicht die dynamische Anpassung von Sicherheitsmechanismen zur Laufzeit und stellt einen evolutionären Fortschritt gegenüber rein struktureller Zonenabsicherung dar.
shield 8. BSI ZT-Integrationsmodell: Abdeckungfeedback
Die Referenzarchitektur adressiert die fünf Säulen des BSI Zero-Trust-Integrationsmodells:
Identitätfeedback
| Funktion | Abdeckung |
|---|---|
| Authentisierung (ID-01) | MFA für Zugriffe separat auf allen Anwendungen; bei Vertrauensverlust wird ein weiterer Faktor eingefordert |
| Autorisierung (ID-02) | RBAC + ABAC; Identitätsattribute (Gerät, Netzzugang) als Quelle für dynamische ABAC-Entscheidungen |
| Identitätsprovider (ID-03) | Alle Anmeldungen über zentral verwaltete Identitäten im IAMBund |
| Identitätsverwaltung (ID-04) | Gesamter Identitätslebenszyklus; dynamische Gruppenzugehörigkeiten; Just-in-time-Prinzip |
| Detektion & Reaktion (ID-DET) | Zentralisierte Sichtbarkeit; Echtzeit-Analyse des Anwenderverhaltens |
Gerätfeedback
| Funktion | Abdeckung |
|---|---|
| Compliance Monitoring (GE-01) | Vollständige Übersicht über Compliance-Status aller Geräte |
| Compliance Durchsetzung (GE-02) | Automatisierte Mechanismen über Gerätemanagement, Monitoring, Autorisierung |
| Ressourcenzugriff (GE-03) | Aktueller Sicherheitszustand des Geräts wird bei jedem Zugriff berücksichtigt |
| Authentisierung (GE-04) | Eindeutiges, gegen Kopieren geschütztes Authentisierungsmerkmal (z. B. TPM 2.0) |
| Asset-Management (GE-05) | Automatisierte Integration aller Geräte/Systemkomponenten per Discovery |
Netzfeedback
| Funktion | Abdeckung |
|---|---|
| Netzsegmentierung (NET-01) | Mikrosegmentierung via SASEBund, PEP-Agent und PEP-Gateway |
| Perimeterschutz (NET-02) | Dynamische Paketfilterung basierend auf aktuellem Kommunikationsbedarf |
| IDS/IPS (NET-03) | DaaS-Anbindung zur Überwachung der Netzkomponenten inkl. PEP-Gateways |
| Verschlüsselung (NET-04) | Jeder externe und interne Netzverkehr wird verschlüsselt; auch Metadaten wenn möglich |
Anwendungfeedback
| Funktion | Abdeckung |
|---|---|
| Zugriffsautorisierung (AW-01) | Basierend auf Echtzeitrisikoanalysen; angefragte Berechtigungen als Teil der Analyse |
| Anwendungssicherheit (AW-06) | Erweiterte Anforderungen an selbst entwickelte und beschaffte Anwendungen (Logging, feingranulare Berechtigungen) |
| Detektion & Reaktion (AW-DET) | Auswertungen für alle anwendungsspezifischen Logdateien; automatische Trigger |
Datenfeedback
| Funktion | Abdeckung |
|---|---|
| Dateninventarisierung (DA-01) | Kontinuierliche Kategorisierung mit vertrauenswürdigem Tagging und Tracking |
| Zugriffs-Ermittlung (DA-02) | Dynamischer Zugriff nach Least-Privilege; Just-in-time-Berechtigungen |
| Verschlüsselung (DA-03) | Verschlüsselung von Daten „in use" und „at rest" |
9. Anforderungen an Fachanwendungenfeedback
Aus der Referenzarchitektur ergeben sich folgende konkrete Anforderungen an Basis- und Fachanwendungen, die an die Sicherheitsinfrastruktur angebunden werden:
| Nr. | Anforderung | Beschreibung |
|---|---|---|
| FA-01 | OIDC-Anbindung | Authentifizierung über OpenID Connect (OIDC) mit IAMBund als Identity Provider; SAML nur als Rückfall |
| FA-02 | Token-Validierung | Validierung von Access-Tokens (zeitlich begrenzt); Unterstützung von Token-Widerruf |
| FA-03 | ABAC-Fähigkeit | Anwendungen müssen attributbasierte Zugriffsentscheidungen unterstützen (über Rollen hinaus) |
| FA-04 | DaaS-Anbindung | Jede Fachanwendung muss sicherheitsrelevante Logdaten an DaaS bereitstellen |
| FA-05 | PEP-Gateway-Integration | Anbindung über SASEBund PEP-Gateways (ZTAA) für kontrollierten Zugriff |
| FA-06 | On-Behalf-of | Unterstützung von Delegation-Tokens (RFC 7521/7522, RFC 8693) für Service-zu-Service-Kommunikation |
| FA-07 | mTLS | Mutual TLS für Service-zu-Service-Kommunikation |
| FA-08 | Feingranulares Logging | Anwendungsspezifische Logging-Anforderungen für Detektion und forensische Analysen |
| FA-09 | Verschlüsselung | Verschlüsselung aller Kommunikation (Data-in-Transit); perspektivisch Data-at-Rest |
| FA-10 | Fachliche Autorisierung | Die endgültige Entscheidung über spezifische Daten-Zugriffsrechte liegt bei der Fachanwendung selbst |
description Quellenfeedback
- Referenzarchitektur Sicherheitsinfrastruktur, BMI, v0.82 ÄND (28.03.2025)
- NIST SP 800-207: Zero Trust Architecture
- ISO 29149: Information technology, Security techniques
- BSI TR-03107: Elektronische Identitäten und Vertrauensdienste im E-Government
- BSI TR-03145: Secure Certification Authority operation
- BSI Zero Trust Integrationsmodell / Reifegradmodell
- RFC 7521/7522: OAuth 2.0 Assertion Framework / SAML Assertion Profile
- RFC 8693: OAuth 2.0 Token Exchange
arrow_forward Siehe auchfeedback
- DA Anwendungsfälle
- Zero Trust Architektur
- Security & Compliance
- Übersicht D-Stack Funktionsbausteine
- Sicherer SDLC für Funktionsbausteine – Entwicklungs-Schwerpunkt (DevSecOps, Supply-Chain-Security)