VERTRAULICH ≠ nur starke Authentifizierung

Ziel dieses Artikels

Er klärt systematisch:

• wodurch die Klassifikation VERTRAULICH tatsächlich ausgelöst wird,
  
• welche Rolle eIAM (QoA50 / LoA 3) dabei spielt,
  
• warum Authentifizierung allein zum Schutz von VERTRAULICHEN Daten nicht genügt,
  
• und wie Massnahmen, Gesamtkonstrukt und Risiken im ISDS-Konzept abzubilden sind.
  

Ausgangslage: eIAM und VERTRAULICH

Für Zugriffe auf VERTRAULICH klassifizierte Informationen gilt in der Bundesverwaltung:
Der Zugriff muss über ein angemessenes Level of Assurance erfolgen (In der eIAM-Taxonomie entspricht dies LoA 3, resp. QoA50) UND die Informationen müssen gemäss den Bearbeitungsvorschriften des SEPOS geschützt werden.

eIAM ist damit die korrekte IAM-Lösung für solche Zugriffe.

Aber: Starke Authentifizierung ist nur ein Baustein. Sie ersetzt nicht die Pflicht, die Daten im Zielsystem selbst VERTRAULICH-konform zu schützen (insb. durch geeignete kryptographische Massnahmen).


Wodurch entsteht VERTRAULICH wirklich?

Die Klassifikation VERTRAULICH resultiert ausschliesslich aus den rechtlichen Triggern des ISG (Schutz staatlicher Interessen und Aufgaben)(SR 128.1)
Keine ausreichenden Trigger für VERTRAULICH sind fachliche Bewertungen wie «geschäftskritisch», «betrieblich sehr wichtig», «politisch heikel» oder «unangenehm bei Medienberichten». Solche Aspekte können in der Risikobetrachtung relevant sein – sind aber keine Klassifikationstrigger. Entscheidend sind die Kriterien nach Art 19 ISV.




SCHUBAN (Schutzbedarfsanalyse) – und ein häufiger Fehler

In der Praxis wird die Klassifikation häufig über die SCHUBAN (Schutzbedarfsanalyse) abgeleitet. Dabei kommt es regelmässig zu Übersteuerungen, denn die SchuBAn ermittelt "nur" die Höhe des Schutzbedarfs aber nicht die korrekte Klassifikation. Liefert die SchuBAn einen "hohen" oder "sehr hohen" Schutzbedarf besteht eine reelle Möglichkeit, aber eben kein Zwang, für das Vorliegen vertraulicher Informationen. Artikel 19 der ISV ist zwingend zu prüfen!

Typischer Fehler

Beurteilungsgrössen werden irrtümlich zu kritisch gesetzt, z. B.:

• Worst-Case-Szenarien ohne reale Eintrittswahrscheinlichkeit; Über- oder Unterschätzen der Wahrscheinlichkeit eines Eintritts der Szenarien,
  
• subjektiv empfundene Wichtigkeit statt rechtlich vorgeschriebener Trigger,
  
• übertriebene Reputationsschäden ohne ISG-Bezug.
  
Wichtig: Ausschlaggebend sind allein die Trigger aus ISG Art 19 – nicht die allgemeine «Geschäftskritikalität».
ABER: auch wenn keine VERTRAULICHkeit klassifiziert wurde, kann über das ISDS die Notwendigkeit der Anwendung informationsschützender Massnahmen angemessen sein -- es gibt nur keinen formalrechtlichen Zwang dafür.


Was eIAM leistet – und was nicht

✅ Was eIAM (QoA50) korrekt abdeckt

• starke (meist hardwarebasierte) Authentifizierung (LoA 3 / QoA50)
  
• substantielle Identitätsprüfung durch Prüfung amtlicher Reisedokumente
  
• kontrollierter Zugriff auf Applikationen gemäss IAM-Vorgaben
  

❌ Was eIAM nicht abdeckt

• Verschlüsselung und Schutz der Daten im Zielsystem (insb. «data at rest»)
  
• Schutz der Daten während Weiterverarbeitung (z. B. Exporte, Reports, Schnittstellen)
  
• fachliche oder rechtliche Beurteilung, ob eine Information VERTRAULICH ist
  
• Bewertung, ob die Handhabe im Zielsystem VERTRAULICH-konform ist
  
• verbindliche Beratung zur Schutzbedarfsklassifikation im Kundenkontext
  


Merksatz: eIAM liefert die korrekte Authentifizierung und Zugriffskontrolltechniken. Die korrekte Handhabung von VERTRAULICH im Zielsystem wie auch die korrekte Vergabe der Zugriffsberechtigungen bleibt Verantwortung der Verwaltungseinheit.




VERTRAULICH bedeutet: zusätzliche Massnahmen im Zielsystem

Wenn VERTRAULICH aufgrund der Trigger des ISG korrekt klassifiziert wurde, ist QoA50 allein nicht hinreichend.

Es braucht ergänzende Massnahmen im Zielsystem, insbesondere:


• kryptographische Sicherung der Daten im Zielsystem (mindestens für relevante Speicherorte),
  
• geeignete Schlüsselverwaltung und Zugriffskontrollen auf Schlüsselmaterial (eIAM kann hier nicht mehr unterstützen!),
  
• Schutz vor unberechtigtem Zugriff (auch intern) und angemessene Rollentrennung,
  
• Nachvollziehbarkeit und Logging gemäss Schutzbedarf.
  


Verantwortung: Diese Massnahmen liegen ausschliesslich in der Verantwortung der Applikation bzw. der Verwaltungseinheit.


Wenn keine ISG-Trigger vorliegen

Es gibt Konstellationen, in denen Daten zwar fachlich oder betrieblich kritisch oder wichtig sind, aber nicht VERTRAULICH im Sinne des ISG.

Klarstellung: Eine fachlich oder betrieblich als kritisch eingestufte Information ist nicht automatisch VERTRAULICH. Aber auch wenn keine Trigger aus ISG vorliegen, dürfen dennoch Schutzmassnahmen des VERTRAULICH-Niveaus umgesetzt werden; die SchuBAn und das ISDS-Konzept bestimmen dann über deren Anwendung.

In solchen Fällen kann gelten:


• QoA50 kann unabhängig von einer VERTRAULICH-Klassifikation weiterhin korrekt sein (z. B. wegen Missbrauchsrisiken beim Zugriff),
  
• eine nachgelagerte kryptographische Sicherung kann aus Schutzbedarfssicht nicht zwingend sein,
  
• die verbleibenden Risiken sind transparent zu dokumentieren.
  


Auch hier gilt: Die Verantwortung für die Entscheidung – und die Risikoakzeptanz – liegt bei der Verwaltungseinheit, nicht beim eIAM-Team.


ISDS-Konzept: Gesamtkonstrukt und Risiken sauber abbilden

Das ISDS-Konzept bildet die Gesamtsicht ab und ist der Ort, an dem zusammengeführt wird:

• der IAM-Einsatz (z. B. eIAM QoA50),
  
• die Massnahmen im Zielsystem (inkl. Kryptographie),
  
• die verbleibenden Risiken aus der Konstellation.
  

Risikoträgerschaft: Die Direktion der Verwaltungseinheit übernimmt die Verantwortung und akzeptiert die verbleibenden Risiken über das ISDS-Konzept. Das ISDS-Konzept dient dabei nicht nur der Dokumentation, sondern der bewussten und verantworteten Entscheidung über angemessene Schutzmassnahmen.
Damit wird auch klar: Es ist nicht Aufgabe des eIAM-Teams (BIT), die Korrektheit der Handhabe von VERTRAULICH im Kundensystem zu beurteilen oder verbindlich zu beraten.




Rollenverteilung auf einen Blick




Rolle	Verantwortung
eIAM / BIT	Bereitstellung der IAM-Leistung gemäss Taxonomie (z. B. QoA50 / LoA 3), Betrieb und Schnittstellen.
Verwaltungseinheit (Kunde)	Klassifikation/Schutzbedarf, Festlegung von Massnahmen, Beurteilung der Konstellation und Risiken.
Zielsystem / Applikation	Technischer Schutz der Daten (u. a. kryptographische Sicherung), Rollen-/Rechtekonzept, sichere Verarbeitung.
ISDS-Konzept	Gesamtsicht: IAM + Zielsystemmassnahmen + Risiken inkl. Begründungen und getroffenen Entscheiden.
Direktion	Übernahme/Tragung der verbleibenden Risiken via ISDS (Risikoträgerschaft).

Fazit

• VERTRAULICH ist eine rechtlich getriggerte Klassifikation (DSG/ISG), keine allgemeine «Kritikalität».
  
• QoA50 ist oft notwendig, aber bei VERTRAULICH nicht hinreichend.
  
• IAM ersetzt keine (kryptographische) Datentransport- und/oder -lagerungsabsicherung – die Schutzmassnahmen müssen im Zielsystem umgesetzt werden.
  
• Überkritische SCHUBAN-Einstellungen führen häufig zu unnötigem VERTRAULICH.
  
• Das ISDS-Konzept bildet das Gesamtkonstrukt ab und verankert Verantwortlichkeiten.
  
• Die Direktion der Verwaltungseinheit trägt die Verantwortung für die akzeptierten Risiken.
  

Anhang 1 – Bedeutet «VERTRAULICH» automatisch SZ+?

Ausgangsfrage

Muss eine Applikation oder ein Zielsystem, das VERTRAULICH klassifizierte Informationen verarbeitet, zwingend in der Serverzone Plus (SZ+) betrieben werden?

Systematik der Entscheidungslogik

Die Zuweisung zu einer technischen Zone (z. B. SZ+) erfolgt nicht direkt aufgrund der Klassifikation, sondern auf Basis der Schutzbedarfsanalyse (SCHUBAN).

Wichtig: Die rechtliche Klassifikation VERTRAULICH ist kein automatischer Zonen-Trigger.

Entscheidungsrelevanter Mechanismus

• VERTRAULICH resultiert ausschliesslich aus rechtlichen Triggern (DSG und/oder ISG).
  
• Die SCHUBAN beurteilt daraus abgeleitet den konkreten technischen und organisatorischen Schutzbedarf.
  
• Ergibt die SCHUBAN einen erhöhten Schutzbedarf, ist eine Platzierung in der SZ+ regelmässig sachgerecht.
  
• Ergibt sie keinen erhöhten Schutzbedarf, besteht keine automatische Pflicht zum Betrieb in der SZ+.
  



Präzisierung

In der Praxis führt eine korrekt hergeleitete VERTRAULICH-Klassifikation häufig zu erhöhtem Schutzbedarf — insbesondere bei sensiblen Personendaten oder staatlich schützenswerten Informationen.

Dennoch bleibt die Zonenentscheidung eine architektonische Ableitung aus der Schutzbedarfsanalyse und ist im ISDS-Konzept nachvollziehbar zu dokumentieren.

Merksatz: VERTRAULICH kann SZ+ erforderlich machen — löst sie aber nicht automatisch aus.

Anhang 2 – Freiwillige Erhöhung von Schutzmassnahmen

Ausgangspunkt

Die Schutzbedarfsanalyse (SCHUBAN) definiert das erforderliche Mindestniveau an Sicherheitsmassnahmen gemäss IT-Grundschutz.

Sie begrenzt jedoch nicht die Möglichkeit einer Verwaltungseinheit, Schutzmassnahmen über dieses Mindestniveau hinaus festzulegen.

Grundsatz: Der IT-Grundschutz ist ein Mindeststandard. Zusätzliche oder strengere Massnahmen sind jederzeit zulässig.

Mögliche freiwillige Erhöhungen

Auch wenn die SCHUBAN keinen erhöhten Schutzbedarf ausweist, kann das Business beispielsweise:

• eine höhere Authentifizierungsqualität (z. B. QoA50) wählen,
  
• eine restriktivere Zonenplatzierung (z. B. SZ+) vorsehen,
  
• zusätzliche kryptographische Massnahmen implementieren,
  
• Logging-, Monitoring- oder Rollentrennungsanforderungen verschärfen.
  

Solche Entscheidungen können sachlich begründet sein, etwa durch:

• Missbrauchs- oder Reputationsrisiken,
  
• politische Sensitivität,
  
• strategische Vorgaben,
  
• Harmonisierung mit anderen Systemen,
  
• präventive Sicherheitsüberlegungen.
  



Dokumentation und Begründung

Werden Schutzmassnahmen freiwillig über das durch die SCHUBAN abgeleitete Niveau hinaus erhöht, ist es fachlich angezeigt, diese Entscheidung transparent zu dokumentieren.

Idealerweise erfolgt dies im ISDS-Konzept, indem:


• die zugrunde liegenden Risiken beschrieben werden,
  
• die zusätzlichen Massnahmen begründet werden,
  
• die erwartete Risikoreduktion nachvollziehbar dargestellt wird.
  


Wichtig: Eine freiwillige Erhöhung von Massnahmen ersetzt nicht die Pflicht, erhöhte Schutzanforderungen umzusetzen, wenn diese durch die SCHUBAN verbindlich festgestellt wurden.




Verantwortung

Die Entscheidung, Schutzmassnahmen freiwillig zu verschärfen, liegt bei der Verwaltungseinheit.

Die daraus resultierenden Aufwände, Architekturentscheidungen und verbleibenden Risiken sind im Rahmen der Governance transparent auszuweisen und durch die zuständigen Entscheidungsträger zu tragen.

Merksatz: Mehr Sicherheit ist jederzeit möglich — sie muss jedoch bewusst entschieden, begründet und dokumentiert werden.