Bezugspflicht

Die Bezugspflicht legt fest, dass Applikationen gemäss den in der Weisung W008 definierten Rahmenbedingungen digitale Identitäten, genauer die darauf basierende Authentifizierungsleistung, zwingend vom Standarddienst IAM-Bund beziehen müssen, dies beim Service eIAM der BK DTI, in dedizierten Anwendungsfällen beim Service SSO-Portal des EJPD.

Für Applikationen, deren Authentifizierungsleistung über eIAM zu beziehen ist, bildet eIAM den vorgesehenen Zugang zu den zugelassenen Identitätsprovidern. Dies gilt unabhängig davon, ob eIAM direkt durch die Zielapplikation oder zulässig indirekt über ein Portal, ein intermediäres IAM-System oder eine andere vermittelnde Komponente angebunden wird.

Soll die staatliche Schweizer e-ID in einem Loginprozess verwendet werden, wird sie als Faktor innerhalb von AGOV eingesetzt; die e-ID selbst ist kein Loginverfahren. Eine von der Bezugspflicht erfasste Zielapplikation darf die e-ID deshalb nicht unter Umgehung von AGOV unmittelbar zur Begründung der Benutzerauthentifizierung integrieren. Für die zentrale Bundesverwaltung wird AGOV grundsätzlich über eIAM bezogen; AGOV «direct only» ist nur im Rahmen einer dafür erteilten Ausnahmebewilligung zulässig.

In der Folge bedürfen andere Bezugswege für die vorgeschriebene Authentifizierungsleistung, beispielsweise der direkte Anschluss von Identitätsprovidern (IdPs) an Applikationen, Middlewares, SaaS oder andere Zielsysteme sowie anwendungseigene Loginverfahren, einer Ausnahmebewilligung der BK DTI, soweit die Bezugspflicht gilt und von der Weisung W008 nicht anders vorgesehen.

Im Rahmen des Standarddienstes IAM-Bund kann auch Berechtigungsmanagement (Access Management) bezogen werden. Davon zu unterscheiden ist die applikationsinterne Fein-Autorisierung, insbesondere die Verwaltung von Berechtigungen für Funktionen und Daten innerhalb einer Anwendung. Diese ist gemäss Weisung W008 nicht Bestandteil des Standarddienstes IAM-Bund und darf in der Zielapplikation, einer Middleware, einem SaaS oder einem anderen dafür vorgesehenen System verortet sein.

Diese Regelung verfolgt die Ziele optimierter Wirtschaftlichkeit, definierter Sicherheit und der Förderung der Digitalisierung der Verwaltungsprozesse durch Interoperabilität der elektronischen Identitäten nach dem Once-Only-Prinzip.

Die nachfolgenden Ausführungen gelten für IAM-Leistungen, die gemäss Weisung W008 vom Leistungsumfang des Standarddienstes IAM-Bund erfasst sind und der Bezugspflicht unterliegen. Die in der Weisung W008 ausdrücklich vorgesehenen Abgrenzungen sowie rechtsgültig erteilte Ausnahmebewilligungen bleiben vorbehalten.

Die Bezugspflicht stützt sich auf die Digitalisierungsverordnung (DigiV) und die Weisung W008. Für die von der Bezugspflicht erfassten IAM-Leistungen der zentralen Bundesverwaltung ist der Standarddienst der vorgeschriebene Bezugsweg. Auf eine Verwaltungseinheit oder eine Anwendung begrenzte Ausnahmen werden durch die BK DTI gemäss W008 und dem Prozess P035 entschieden und zeitlich beschränkt.

Für von der Bezugspflicht erfasste Webapplikationen und native Mobile-Apps ist die Authentifizierungsleistung grundsätzlich über eIAM zu beziehen. Dies gilt auch bei SaaS und anderen Cloudbetriebsformen und unabhängig davon, ob eine Lösung intern, extern, in Microsoft Azure, bei einem anderen Hyperscaler oder auf einem durch die Bundesverwaltung verwalteten Mobilgerät betrieben beziehungsweise genutzt wird.

Microsoft Entra ID ist für die Benutzer-Authentifizierung einer eIAM-bezugspflichtigen Fachapplikation, Webapplikation, SaaS-Lösung oder nativen Mobile-App kein alternativer Bezugsweg zu eIAM. Eine direkte Föderation einer solchen Zielapplikation mit Entra ID oder die Verwendung von Entra ID als deren Login- beziehungsweise Authentifizierungsdienst ist deshalb ohne anwendbare Abgrenzung oder Ausnahmebewilligung nicht zulässig.

Davon zu unterscheiden sind die im Standarddienst Büroautomation bereitgestellten und gemäss den hierfür geltenden Vorgaben, insbesondere AR009 und E031, freigegebenen Microsoft-365-Services und Microsoft-365-Apps. Deren IAM-Versorgung richtet sich nach den spezifischen Vorgaben des Standarddienstes Büroautomation. Diese M365-spezifische Konstellation stellt keine generelle Freigabe von Entra ID als Authentifizierungsdienst für andere Anwendungen dar.

Insbesondere wird eine Fachapplikation oder native Mobile-App nicht dadurch zu einer Microsoft-365-Anwendung oder von der eIAM-Bezugspflicht ausgenommen, dass sie auf einem verwalteten Gerät installiert ist, mittels Microsoft Intune verteilt, konfiguriert, geschützt oder verwaltet wird, in einem Entra-ID-Tenant registriert ist, Microsoft-Bibliotheken verwendet oder in Microsoft Azure betrieben wird. Soweit die Anwendung der eIAM-Bezugspflicht unterliegt, muss ihre Benutzer-Authentifizierung über eIAM erfolgen.

Unzulässig sind, soweit keine anwendbare Abgrenzung gemäss W008 oder eine erforderliche und vorgängig erteilte Ausnahmebewilligung vorliegt, insbesondere:

• anwendungseigene Verfahren zur erstmaligen oder erneut erforderlichen Feststellung der Identität eines Benutzenden, beispielsweise mittels in der Anwendung geführter Benutzername-/Passwort-Konten oder anderer anwendungseigener Credentials, wenn diese anstelle der vorgeschriebenen Authentifizierung über eIAM verwendet werden;
• der direkte Anschluss eines internen oder externen Identitätsproviders an eine von der Bezugspflicht erfasste Zielapplikation, native Mobile-App, Middleware, Portalschicht, SaaS-Lösung oder ein anderes Zielsystem unter Umgehung von eIAM;
• die direkte Föderation einer von der Bezugspflicht erfassten Fachapplikation, Webapplikation, SaaS-Lösung oder nativen Mobile-App mit Microsoft Entra ID beziehungsweise die Verwendung von Entra ID als Login- oder Authentifizierungsdienst dieser Anwendung ausserhalb der dafür vorgesehenen M365-Konstellation des Standarddienstes Büroautomation;
• die Verwendung von Microsoft Entra ID als Login- oder Authentifizierungsdienst einer nativen Mobile-App allein deshalb, weil diese App mittels Microsoft Intune installiert, verteilt, konfiguriert, geschützt oder verwaltet wird;
• die Verwendung von Microsoft Entra ID als Login- oder Authentifizierungsdienst einer Fachapplikation allein deshalb, weil diese in Microsoft Azure betrieben wird, in einem Entra-ID-Tenant registriert ist oder andere Dienste des Microsoft-Cloud-Ökosystems nutzt;
• die direkte Authentifizierung von Benutzenden einer von der Bezugspflicht erfassten Webapplikation oder nativen Mobile-App gegenüber Active Directory, LDAP, Kerberos oder vergleichbaren Verzeichnis- oder Authentifizierungsdiensten unter Umgehung von eIAM; der direkte Bezug von Kerberos durch Webapplikationen und native Mobile-Apps bedarf gemäss den eIAM-Vorgaben einer Ausnahmebewilligung;
• der direkte Anschluss von Sektor-IdPs oder anderen für den Bezug über eIAM vorgesehenen Identitätsprovidern an von der Bezugspflicht erfasste Zielsysteme oder intermediäre IAM-Systeme anstelle des Bezugs über eIAM;
• portalproprietäre Loginverfahren oder direkte Anschlüsse von Identitätsprovidern auf einer von der Bezugspflicht erfassten Portalschicht; die zulässige Abstraktion des eIAM-Anschlusses durch eine Portalschicht hebt die Bezugspflicht nicht auf;
• der Bezug von AGOV «direct only», also der direkte Anschluss von AGOV an eine Zielapplikation oder ein intermediäres IAM-System ohne Zwischenschaltung von eIAM, sofern für die zentrale Bundesverwaltung hierfür keine vorgängige Ausnahmebewilligung erteilt wurde; dies gilt auch für native Mobile-Apps;
• die direkte Verwendung der staatlichen Schweizer e-ID als anwendungseigenes Login- oder Authentifizierungsmittel einer von der Bezugspflicht erfassten Zielapplikation oder nativen Mobile-App unter Umgehung von AGOV beziehungsweise des für die betreffende Anwendung vorgeschriebenen IAM-Bezugswegs;
• das Vorschalten oder Zwischenschalten eines IAM-, Identity-Broker-, Federation- oder Single-Sign-on-Systems, wenn dadurch eIAM als vorgeschriebene Quelle der Authentifizierungsleistung ersetzt oder umgangen wird;
• die Einführung separater Login-Inseln für einzelne Fachapplikationen, native Mobile-Apps, SaaS-Lösungen, Projekte, Organisationseinheiten oder Benutzergruppen, soweit deren Authentifizierungsleistung der Bezugspflicht des Standarddienstes IAM-Bund unterliegt.

Nicht betroffen ist die applikationsinterne Fein-Autorisierung, insbesondere die Verwaltung von Berechtigungen für Funktionen und Daten innerhalb der Anwendung. Rollen, Berechtigungen, fachliche Autorisierungsattribute und andere ausschliesslich für diese Fein-Autorisierung erforderliche Informationen dürfen entsprechend den geltenden Vorgaben in der Zielapplikation, einer Middleware, einem SaaS oder einem anderen dafür vorgesehenen System geführt werden. Dies darf jedoch nicht dazu führen, dass die vorgeschriebene Authentifizierungsleistung durch eine eigene oder andere IAM-Versorgung ersetzt wird.

Bei nativen Mobile-Apps ist zudem zwischen der Authentifizierung gegenüber eIAM und der lokalen Freigabe eines bereits über eIAM begründeten und persistierten Loginzustands zu unterscheiden. Die Login-Persistierung ist gemäss den eIAM-Vorgaben zulässig. Der erneute Zugriff auf einen solchen persistierten Loginzustand darf mittels lokalem Geräteschutz, insbesondere Biometrie oder Geräte-PIN, freigegeben werden. Eine solche lokale Freigabe des persistierten Loginzustands stellt weder einen alternativen Identitätsprovider noch eine Umgehung der eIAM-Bezugspflicht dar. Ist eine erneute Authentifizierung gegenüber dem IAM-System erforderlich, erfolgt diese wiederum über eIAM.

Zulässig sind ebenfalls indirekte eIAM-Anschlüsse über Portale, intermediäre IAM-Systeme oder vergleichbare vermittelnde Komponenten, sofern diese die von eIAM bezogene Authentifizierungsleistung zur Zielanwendung vermitteln und eIAM nicht als vorgeschriebene Authentifizierungsinstanz ersetzen oder umgehen. Gleiches gilt für Authentication Bridges, die eine ansonsten nicht kompatible Zielanwendung an eIAM anbinden.

Von der unzulässigen Verwendung von Entra ID als alternativem Benutzer-Authentifizierungsdienst ist die nach den hierfür geltenden Vorgaben zulässige technische Nutzung des Microsoft-Cloud-Ökosystems zu unterscheiden. AR015 regelt insbesondere Entra-ID-Accounts, Applikationsregistrierungen, Service Principals, Tenants und weitere für den Betrieb von Cloudlösungen erforderliche Komponenten. Deren technische Verwendung stellt für sich allein keine alternative Benutzer-Authentifizierung dar. Sie begründet jedoch keine Berechtigung, Entra ID anstelle von eIAM als Identitätsprovider oder Authentifizierungsdienst einer eIAM-bezugspflichtigen Zielapplikation einzusetzen. Die in AR015 geregelten Vorgaben zur Identitätsvermittlung und Föderation über den Standarddienst IAM bleiben einzuhalten.

Massgebend ist somit die Funktion und nicht das Produkt, die Betriebsplattform oder der Betriebsort: Soweit die Benutzer-Authentifizierung der Bezugspflicht des Standarddienstes IAM-Bund unterliegt, muss sie über den dafür vorgesehenen Service des Standarddienstes erfolgen. Ein anderer Authentifizierungsweg ist nur zulässig, wenn die betreffende IAM-Leistung gemäss W008 nicht der Bezugspflicht unterliegt oder die erforderliche Ausnahmebewilligung vorgängig erteilt wurde.

Ausnahmebewilligungen richten sich nach der Weisung W008 und dem Prozess P035. Auf eine Verwaltungseinheit oder eine Anwendung begrenzte Ausnahmen werden durch die BK DTI entschieden und zeitlich beschränkt.

Ausnahmebewilligungen für die IAM-Versorgung von Webapplikationen und native Mobile-Apps ausserhalb des entsprechenden Standarddienstes der Bundesverwaltung können für Pilotbetriebe eng befristet erteilt werden.

Für die IAM-Versorgung von Webapplikationen und native Mobile-Apps im Produktivbetrieb werden gemäss den publizierten eIAM-Vorgaben grundsätzlich keine Ausnahmebewilligungen erteilt, auch bei geringer Benutzerzahl oder geringem Schutzbedarf, ausser bei absoluter technischer Unmöglichkeit oder in einer dringlichen Situation. Die blosse Tatsache, dass ein Produkt bereits über ein eigenes Login verfügt oder vom Hersteller nur eine andere IAM-Lösung unterstützt wird, begründet für sich allein keine Ausnahme.

AGOV «direct only» ist für die zentrale Bundesverwaltung als sehr seltener bewilligungspflichtiger Ausnahmefall vorgesehen. Ohne eine entsprechende vorgängige Bewilligung wird AGOV über «full» eIAM bezogen.

Beschaffungen von Software, SaaS und anderen Cloudlösungen etc. müssen gemäss Beschaffungsmerkblatt vollständig auf die Anschliessbarkeit an eIAM ausgerichtet sein. Die Anschlussfähigkeit an den vorgeschriebenen Standarddienst ist bei von der Bezugspflicht erfassten Lösungen ein Musskriterium.

Werden IKT-Lösungen beschafft, dies gilt auch für Cloud-Lösungen inkl. SaaS, welche nicht an eIAM innerhalb des eIAM-Standards angeschlossen werden können, ist der Applikationseigner verpflichtet, eine Authentication Bridge im Sinne eines Adapters entwickeln zu lassen und zu betreiben. Vgl. Authentication Bridges.

Eine erteilte Ausnahmebewilligung gilt ausschliesslich für den darin bezeichneten Geltungsbereich und die festgelegte Dauer. Sie begründet keine generelle Freigabe des verwendeten IAM-Versorgungsmusters für andere Anwendungen, Organisationseinheiten oder Folgevorhaben.

Die einheitliche IAM-Versorgung der Applikationslandschaft der Bundesverwaltung ist die Grundlage für eine erfolgreiche Digitalisierung der Prozesse. Eine Ansammlung von Kleinanwendungen mit proprietärer IAM-Versorgung muss in diesem Rahmen unbedingt vermieden beziehungsweise konsolidiert werden.