Si003 - Netzwerksicherheit in der Bundesverwaltung
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Eidgenössisches Finanzdepartement EFD
Nationales Zentrum für Cybersicherheit NCSC
Informatiksicherheit Bund SEC
Version 3.1
Si003 -
Netzwerksicherheit in der Bundesverwaltung
vom 19. Dezember 2013 (Stand 1. April 2021)
Der Delegierte für Cybersicherheit erlässt gestützt auf Artikel 11, Absatz 1, Buchstabe e der
Verordnung über den Schutz vor Cyberrisiken in der Bundesverwaltung (CyRV) vom 27. Mai
2020 [1] nachfolgende Vorgaben zur Netzwerksicherheit. Diese stellt eine Vorgabe für den
Grundschutz gemäss Artikel 14c CyRV dar.
Die Si002 - Zugriffsmatrix, Version 5.1 vom 19. Dezember 2013 (Stand 22. Mai 2019) [2] ist
in diese Vorgaben integriert und mit dem Inkrafttreten der Version 3.0 dieser Vorgaben aus
ser Kraft gesetzt.Si003 - Netzwerksicherheit in der Bundesverwaltung
Inhaltsverzeichnis
Inhaltsverzeichnis ..................................................................................................... 2
1 Allgemeine Bestimmungen .......................................................................... 3
1.1 Gegenstand ............................................................................................................ 3
1.2 Geltungsbereich ..................................................................................................... 3
1.3 Begriffe ................................................................................................................... 3
2 Zonenmodell Bund ....................................................................................... 4
3 Grundsätze .................................................................................................... 5
4 Zugriffsmatrix................................................................................................ 7
5 Weitere Anforderungen .............................................................................. 10
6 Finanzierung ............................................................................................... 10
7 Inkraftsetzung und Übergangsbestimmungen ........................................ 11
Abkürzungen ........................................................................................................... 12
Referenzen ............................................................................................................... 13
Anhang A: Zonenpolicy «Netzdomäne blau»........................................................ 14
A.1 Anforderungen und Vorgaben an die IKT-Systeme ........................................... 14
A.2 Anforderungen und Vorgaben an die Netzdomäne blau ................................... 14
A.3 Anforderungen und Vorgaben an die zulässige Kommunikation ..................... 14
A.3.1 Interne Kommunikation ....................................................................................... 14
A.3.2 Externe Kommunikation ...................................................................................... 14
Anhang B: Zugriffsmatrix blaue Netzdomäne und SSZ ....................................... 15
2/15Si003 - Netzwerksicherheit in der Bundesverwaltung
1 Allgemeine Bestimmungen
1.1 Gegenstand
1
Diese Vorgaben sind als netzwerksicherheitsspezifischen Teil des IKT-Grundschutzes in
der Bundesverwaltung [3] zu verstehen.
1.2 Geltungsbereich
1
Der Geltungsbereich richtet sich nach Artikel 2 der Verordnung über den Schutz vor Cyber
risiken in der Bundesverwaltung (CyRV) vom 27. Mai 2020 [1].
1.3 Begriffe
1
In diesen Vorgaben bedeuten:
a) IKT-System (System): Ein informations- und kommunikationstechnisches System,
welches als Software auf einer dedizierten Hardware oder auf einer virtualisierten
Hardware bzw. virtuellen Maschine betrieben wird1. Im zweiten Fall kann das IKT-
System als virtualisiert bezeichnet werden.
b) Ein IKT-System gilt als2
• Server-System, wenn es mehrheitlich IKT-Leistungen erbringt;
• Client-System, wenn es mehrheitlich IKT-Leistungen bezieht;
• Netzwerkkomponente, wenn es primär dem Datentransport zwischen ande
ren IKT-Systemen dient, wie z.B. Switches, Router und einfache statische Pa
ketfiler (IP-Firewalls). Im OSI-Referenzmodell arbeiten Netzwerkkomponenten
bis und mit Schicht 4 (Transportschicht).
• Policy Enforcement Point (PEP), wenn es primär der Durchsetzung von Re
geln (von Policies) dient, wie z.B. dynamische Paketfilter, Applikationsproto
koll-Gateways, Proxy Server und Reverse Proxy Server3. Im OSI-Referenz
modell arbeiten PEP bis und mit Schicht 7 (Anwendungsschicht).
c) Zone: Logischer Verbund von IKT-Systemen, die sich durch ähnliche Sicherheitsan
forderungen auszeichnen und der gleichen Zonenpolicy unterliegen. Damit ist eine
Zone nicht auf einen bestimmten Ort (z.B. Rechenzentrum) beschränkt. Die netz
werkmässige Erschliessung einer Zone erfolgt über Netzwerkkomponenten, während
die Durchsetzung der Regeln der Zonenpolicy über PEPs erfolgt, die idealerweise in
einer speziellen Zone (PEZ) betrieben werden.
d) Unterzone: Eine Zone kann in Unterzonen unterteilt sein, wenn die entsprechende
Policy dies vorsieht. Jede Unterzone stellt selbst wiederum eine Zone dar. Insbeson
dere muss jede Unterzone über eine Policy verfügen, die die Policy der übergeordne
ten Zone nur verschärfen darf, d.h. sie darf nur zusätzliche Anforderungen und Vor
gaben enthalten (Abschwächungen sind unzulässig). Die Unterzonierung einer Unter
zone ist grundsätzlich erlaubt, sollte aber nur in zwingenden Ausnahmefällen ange
wendet werden.
1
Das IKT-System, das die virtualisierte Hardware bzw. die virtuelle Maschine zur Verfügung stellt (Hypervisor), ist
selbst wiederum eine Software und stellt daher ein eigenständiges IKT-System dar.
2
Diese Unterscheidung ist nicht präzis, weil ein IKT-System gleichzeitig in mehreren Funktionen auftreten und
deshalb sowohl als Client- als auch als Server-System betrachtet werden kann.
3
Die charakteristische Eigenschaft eines PEP ist die Tatsache, dass er auf der Anwendungsschicht arbeitet und
das (die) vermittelte(n) Protokoll(e) kontrolliert.
3/15Si003 - Netzwerksicherheit in der Bundesverwaltung
e) Segment: Teil eines Netzwerkes (innerhalb einer Zone), das – aus Lastausgleichs-
und/oder Sicherheitsgründen – mit Hilfe von Netzwerkkomponenten gemäss den Vor
gaben der Zonenpolicy vom Rest des Netzwerkes getrennt ist. Alle Segmente eines
Netzwerkes (innerhalb einer Zone) unterliegen grundsätzlich der gleichen Zonenpo
licy, wobei punktuelle Verschärfungen möglich sind.
2 Zonenmodell Bund
1
Das Zonenmodell Bund ist ein generisches Modell für die Zonenbildung in der Bundesver
waltung, das für alle Verwaltungseinheiten (LB und LE) verbindlich ist. Insbesondere legt das
Modell fest, wie die IKT-Systeme bzw. Netzwerke der Bundesverwaltung in Zonen und Un
terzonen organisiert und betrieben werden müssen.
2
Jede (Unter-)Zone (ausser dem Internet) muss über einen Inhaber und einen Betreiber ver
fügen (vgl. Ziffer 3). Der Inhaber ist für die Zonenpolicy und der Betreiber für die Umsetzung
der Policy verantwortlich. Falls der Inhaber einer (Unter-)Zone die Policy ändert, muss dem
Betreiber eine angemessene Frist für die Umsetzung eingeräumt werden.
Internet
Policy Enforcement Zone (PEZ)
Schutzbedarf (SZ+)
SZ mit erhöhtem
Client Zone (CZ)
Server Zone (SZ)
Technik Zone
Service Zone
Gäste Zone
Spezialzone
APS Zone
Management Zone
Abbildung 1: (Generisches) Zonenmodell Bund
3
Das Zonenmodell Bund ist in Abbildung 1 schematisch dargestellt. Es werden die folgen
den Zonen und Unterzonen unterschieden:
a) Internet: Zone, welche keine der Kriterien für die übrigen Zonen entspricht und an
welche keine (Sicherheits-) Anforderungen gestellt werden können.
b) Policy Enforcement Zone (PEZ): Zone für PEPs, die zur Durchsetzung der Regeln
für die externe Kommunikation anderer Zonen erforderlich sind.
4/15Si003 - Netzwerksicherheit in der Bundesverwaltung
c) Service Zone: Zone für Server-Systeme, die für die Erbringung von Infrastruktur
diensten erforderlich sind (z.B. DNS- und Zeitserver).
d) Server Zone (SZ): Zone für Server-Systeme, auf denen Fachanwendungen mit nicht
erhöhtem Schutzbedarf gemäss Schutzbedarfsanalyse (Schuban) betrieben werden.
e) Server Zone mit erhöhtem Schutzbedarf (SZ+): Unterzone der SZ für Server-Sys
teme, auf denen Fachanwendungen mit erhöhtem Schutzbedarf gemäss Schutzbe
darfsanalyse (Schuban) betrieben werden.
f) Client Zone (CZ): Zone für Client-Systeme. Der Betrieb von Server-Systemen in der
CZ oder einer Unterzone ist zulässig, wenn dies in der Policy vorgesehen ist und die
Server-Systeme primär von Client-Systemen der gleichen (Unter-) Zone benutzt wer
den (z.B. lokale Büroautomations- oder Printserver).
g) APS Zone: Unterzone der CZ für Client-Systeme, die als Arbeitsplatzsysteme (APS)
ausgelegt sind und ausschliesslich für den IKT-Standarddienst BA / UCC eingesetzt
werden.
h) Gäste Zone: Unterzone der CZ für Client-Systeme, die nicht von einer Verwaltungs
einheit des Bundes betrieben werden, wie z.B. Geräte, die von externen Mitarbeite
rinnen und Mitarbeitern oder Angestellten der Bundesverwaltung im Rahmen von
„Bring Your Own Device“ (BYOD) genutzt werden.
i) Spezialzone: Zone für IKT-Systeme der Bundesverwaltung, die sich durch spezielle
Eigenschaften und entsprechende Anforderungen auszeichnet, wie z.B. autarke Be
treibbarkeit oder schmalbandige Netzwerkanbindung, und die aus der Management
Zone heraus verwaltet und administriert werden kann (z.B. Transportnetz mit spezifi
schen Anforderungen).
j) Technik Zone: Spezielle Zone für IKT- und IoT-Systeme, wie z.B. Systeme für die
Gebäudetechnik bzw. Facility Management, Zeiterfassungssysteme, Messsysteme
und Systeme zur Ferndiagnose.
k) Management Zone: Spezielle Zone für IKT-Systeme, die ausschliesslich für die Ver
waltung und Administration von IKT-Systemen in anderen Zonen verwendet werden.
Neben diesen Zonen gibt es verschiedene Netzdomänen, die im Rahmen der Übergangsbe
stimmungen aus Ziffer 7 Absatz 2 weiter betrieben werden können. Diese Domänen sind
nicht Gegenstand des Zonenmodells und in Abbildung 1 nicht dargestellt.
4
Grundsätzlich kann jede (Unter-)Zone des Zonenmodells in der Bundesverwaltung mehr
fach umgesetzt werden.
5
Wird eine Fachanwendung nicht in einer Zone der Bundesverwaltung betrieben (z.B. in ei
ner Public Cloud), muss in der entsprechenden Sicherheitsdokumentation (d.h. Massnah
menumsetzung zum IKT-Grundschutz bzw. erweitertes ISDS-Konzept) beschrieben sein, wie
in dieser Umgebung ein adäquates und mit der Bundesverwaltung vergleichbares Sicher
heitsniveau erreicht und gewährleistet werden kann. Diese Dokumentation muss vom ISBO
geprüft und vom Geschäftsprozessverantwortlichen genehmigt sein.
Die nachfolgenden Ausführungen gelten sowohl für Zonen als auch für Unterzonen. Der Ein
fachheit wegen wird dabei nur noch von Zonen gesprochen.
3 Grundsätze
1
In der Bundesverwaltung dürfen nur Zonen aufgebaut und betrieben werden, die konform
zum Zonenmodell Bund sind, die Vorgaben aus Ziffern 4 (Zugriffsmatrix) und 5 (Sicherheits
anforderungen) erfüllen und über einen Inhaber, einen eindeutigen Namen, eine vom Inha
ber festgelegte Zonenpolicy und einen Betreiber verfügen.
5/15Si003 - Netzwerksicherheit in der Bundesverwaltung
a) Inhaber: Name der Verwaltungseinheit des Bundes, die für die Zone verantwortlich
ist. Der Inhaber der Zone muss die Finanzierung sicherstellen (vgl. Ziffer 6) und ent
scheiden, welche IKT-Systeme in der Zone betrieben werden dürfen.
b) Name: Eindeutiger Name der Zone. Das kann z.B. dadurch erreicht werden, dass der
Inhaber als Suffix dem Namen angehängt wird (z.B. SZ-FUB für eine von der FUB
betriebene Server Zone). Falls ein Inhaber eine Zone mehrfach umsetzen lässt, müs
sen die entsprechenden Namen unterscheidbar sein.
c) Zonenpolicy: Nach den Vorgaben des NCSC vom Inhaber erstellte strukturierte Be
schreibung von Anforderungen und Vorgaben an
• die IKT-Systeme der Zone,
• die Zone selbst, wie z.B. ob und wenn ja wie die Zone netzwerkmässig segmen
tiert werden kann,
• die Authentifikation der Personen und automatisierten Prozesse, die auf in der
Zone betriebenen IKT-Systeme und Anwendungen zugreifen können dürfen (ge
mäss der Zugriffsmatrix aus Ziffer 4), sowie
• die für die Zone zulässige interne (auch Segment-übergreifende) und externe
(auch PEZ-übergreifende) Kommunikation, d.h. die zulässigen aus- und einge
henden Kommunikationsbeziehungen4. Eine Kommunikation zwischen zwei oder
mehr gleichen Zonen5 gilt als intern, wenn die Konformität der Zonenübergänge
mit den Policies in der gleichen PEZ sichergestellt wird. Die externe Kommunika
tion umfasst auch die Kommunikationsbeziehungen mit den Netzdomänen, die im
Sinne der Übergangsbestimmungen gemäss Ziffer 7 Absatz 2 weiter betrieben
werden.
d) Betreiber: Name der Verwaltungseinheit des Bundes, die als LE die Zone im Auftrag
des Inhabers netzwerktechnisch betreibt6. Insbesondere muss der Betreiber sicher
stellen, dass nur gemäss Zonenpolicy zulässige Kommunikation von und zu der Zone
stattfinden kann, und dass mit Hilfe geeigneter komplementärer Sicherheitsmassnah
men von dieser Kommunikation keine zusätzliche Bedrohung für andere Zonen aus
geht. Ohne gegenteiligen Vermerk in der Zonenpolicy können mit Zustimmung des
Zoneninhabers innerhalb der Zone auch IKT-Systeme von anderen (auch externen)
LE betrieben werden. Diese LE sind dann in ihren jeweiligen Zuständigkeitsbereichen
für die Einhaltung der Zonenpolicy mitverantwortlich.
2
Jede Zone muss dokumentiert und sowohl vom Inhaber als auch vom Betreiber geprüft7
und analog zu der Sicherheitsdokumentation einer Fachanwendung genehmigt sein.
3
Der ISBD führt eine aktuelle Liste von Zonen, in denen eine Verwaltungseinheit des Depar
tementes entweder als Inhaber oder als Betreiber auftritt, und stellt diese Liste dem NCSC
zur Verfügung.
4
Jedes in der Bundesverwaltung eingesetzte IKT-System muss einer Zone zugeordnet sein
4
Eine Kommunikationsbeziehung ist ausgehend, wenn der entsprechende Datenaustausch von einem IKT-Sys
tem der zur Diskussion stehenden Zone angestossen wird. Demgegenüber ist sie eingehend, wenn der Daten
austausch zwar von einem IKT-System ausserhalb der Zone angestossen wird, sich aber an ein IKT-System in
der Zone richtet. In beiden Fällen kann der eigentliche Datenaustausch bidirektional erfolgen.
5
Diese Zonen können auch über unterschiedliche Inhaber verfügen.
6
Falls der Inhaber der Zone ein LE ist, können der Inhaber und der Betreiber auch identisch sein. Umfasst die
Zone IKT-Systeme und Anwendungen, die ausserhalb der Bundesverwaltung (z.B. in einer Public Cloud) betrie
ben werden, dann beschränkt sich der Betrieb der Zone auf die netzwerkmässige Erschliessung dieser IKT-Sys
teme und Anwendungen.
7
Für die Prüfung ist der jeweilige ISBO des Inhabers bzw. des LE zuständig. Auf der Seite des LE muss insbe
sondere geprüft sein, dass durch den Betrieb der Zone keine zusätzlichen und für die Inhaber der anderen Zo
nen nicht abschätzbaren Risiken entstehen.
6/15Si003 - Netzwerksicherheit in der Bundesverwaltung
und gemäss der für diese Zone geltenden Policy betrieben werden. Ist ein IKT-System keiner
anderen Zone zugeordnet, gehört es im Hinblick auf diese Vorgaben dem Internet an.
4 Zugriffsmatrix
1
Die Zugriffsmatrix legt die minimalen Anforderungen an die (zentrale oder dezentrale) Au
thentifikation bzw. die entsprechenden Authentifikations- und Identitätsnachweismittel fest.
Auf dieser Grundlage muss gemäss Ziffer 3 Absatz 1 c) in der Zonenpolicy festgelegt sein,
wie Personen und automatisierte Prozesse auf die in der Zone betriebenen IKT-Systeme und
Anwendungen zugreifen können, bzw. wie diese zu authentifizieren und allenfalls zu autori
sieren sind. Darüber hinaus kann ein System- oder Anwendungsverantwortlicher auch wei
tere Anforderungen an die Art und Weise des Zugriffs spezifizieren bzw. bestimmte Zugriffs
möglichkeiten unterbinden.
2
Grundsätzlich soll eine Authentifikation vor dem Zonenzugriff zentral in der PEZ erfolgen.
Falls dies nicht möglich oder nicht sinnvoll ist, kann die Authentifikation auch dezentral auf
einem PEP in der Zone selbst erfolgen. Allerdings muss dann in der Zonenpolicy dargelegt
sein, wie die in der Zone betriebenen IKT-Systeme und Fachanwendungen vor Fremdzugrif
fen geschützt werden. Insbesondere ist dann eine Netzwerksegmentierung und eine mög
lichst umfassende netzwerktechnische Abschottung dieser IKT-Systeme und Fachanwen
dungen erforderlich.
3
Die zur Verfügung stehenden Authentifikations- und Identitätsnachweismittel mit entspre
chenden Föderationsverfahren werden in die folgenden vier Sicherheitsstufen (tief, mittel,
hoch und hoch+) eingeteilt8:
a) Tief: Die Authentifikationsinformation, die netzwerktechnisch übertragen wird, ist sta
tisch und bei jeder Authentifikation identisch, d.h. sie kann von einem Angreifer abge
griffen und z.B. für einen «Replay»-Angriff und eine anschliessende Identitätstäu
schung missbraucht werden. Typisches Beispiel ist Benutzername und Passwort.
Wird die Authentifikationsinformation als Föderationstoken im Sinne von [4] einge
setzt, dann muss diese nur schwach gegen Integritätsangriffe geschützt und an den
Anwenderkontext gebunden sein. Beispiele sind verschiedene «Bearer-Token» wie
Cookies.
b) Mittel: Die Authentifikationsinformation ändert sich bei jeder Authentifikation dyna
misch und kann entsprechend nicht für einen «Replay»-Angriff und eine anschlies
sende Identitätstäuschung missbraucht werden. Beispiele sind Username und Pass
wort mit SMS-Verifikationscode9 oder Gerätebindung, OTP-Softwarelösungen (z.B.
Google Authenticator) und von der SG-PKI ausgegebene Software-Zertifikate (Klas
sen C, D oder E). Wird die Authentifikationsinformation als Föderationstoken einge
setzt, dann muss diese gegen Integritätsangriffe geschützt und auf eine dem Stand
der Technik entsprechende Art an den Anwenderkontext gebunden sein. Beispiele
sind Kerberos-Tickets der Ressourcen-Forests des IKT-SD BA, sowie per SAML oder
OIDC/OAuth übertragene «Bearer-Token» wie JWT.
c) Hoch: Die Authentifikationsinformation ist dynamisch und hängt von einem kryptogra
fischen Schlüssel ab, der in einem dedizierten Hardware-Modul gespeichert ist und
8
Grundsätzlich definiert der IKT-Standard I050 [4] vier Verlässlichkeitsstufen (Level of Assurance, LoA) 1 – 4, die
zur Spezifikation der minimalen Sicherheitsanforderungen an die einzusetzenden Authentifikations- und Identi
tätsnachweismittel herangezogen werden könnten. Weil die LoA-Einstufung der heute verfügbaren und im Ein
satz stehenden Authentifikations- und Identitätsnachweismittel aber noch nicht vorliegt, wird hier im Sinne einer
Übergangslösung eine einfache und auf ein paar wenige technische Sicherheitsaspekte der Authentifikations-
und Identitätsnachweismittel selbst fokussierende Einstufung verwendet.
9
Obwohl Username und Passwort mit SMS-Verifikationscode als Beispiel hier noch aufgeführt ist, sollte es als
Authentifikations- und Identitätsnachweismittel aus heutiger Sicht nicht mehr eingesetzt werden. Es hat sich ge
zeigt, dass die SMS-Verifizierung in der Praxis allzu oft und einfach umgangen werden kann.
7/15Si003 - Netzwerksicherheit in der Bundesverwaltung
von dort (mit vertretbarem Aufwand) nicht ausgelesen werden kann. Falls das Au
thentifikations- und Identitätsnachweismittel persönlich ist, muss die Registrierung der
Person oder die Übergabe des Nachweismittels an die Person auf der Basis eines
amtlichen Identitätsausweises (z.B. Reisepass oder Identitätskarte) erfolgen. Erfolgt
die Identitätsüberprüfung der Person bei deren Registrierung, so muss die Übergabe
des Nachweismittels per eingeschriebener Post erfolgen. Die Übergabe darf auch mit
einem Geheimnis (z.B. Passwort/PIN) oder mit biometrischen Merkmalen (z.B. Touch
ID oder Face ID im Falle von Apple oder Hello im Falle von Windows) geschützt erfol
gen. Beispiele sind OTP-Token, OTP-Lösungen auf der Basis eines TPM, FIDO2-To
ken, Swisscom Mobile ID und SuisseID. Wird die Authentifikationsinformation als Fö
derationstoken eingesetzt, dann muss diese gegen Integritätsangriffe geschützt und
auf eine dem Stand der Technik entsprechende Art an den Anwenderkontext gebun
den sein. Insgesamt muss das Föderationsverfahren einem mit CC EAL4+-vergleich
baren Schutzprofil entsprechen. Beispiele sind SSO-Identity/SSO-Federation des
SSO-Portals und Kerberos-Tickets der User-Forests, wenn diese aufgrund einer Be
nutzerauthentifizierung mit einem von der SG-PKI ausgegebenen Zertifikat ausge
stellt worden sind.
d) Hoch+: Das Authentifikations- und Identitätsnachweismittel erfüllt die Anforderungen
der Stufe «hoch» (inkl. Anforderungen an das Föderationsverfahren). Zudem müssen
sowohl das Hardware-Modul als auch der dahinterliegende Registrationsprozess vom
NCSC für die Bundesverwaltung anerkannt sein. Einziges Beispiel sind von der SG-
PKI ausgegebene Zertifikate auf Smartcards (Klasse B).
Die genannten Beispiele sind nicht abschliessend zu verstehen und in Tabelle 1 zusammen
gestellt.
Sicherheits-
Beispiele von Authentifikations- und Identitätsnachweismitteln
stufe
tief • Benutzername und Passwort
• «Bearer-Token» (z.B. Cookies)
mittel • Benutzername und Passwort mit SMS-Verifikationscode9
• Benutzername und Passwort mit Gerätebindung
• OTP-Softwarelösung (z.B. Google Authenticator)
• Von der SG-PKI ausgegebenes Software-Zertifikat (Klasse C, D oder E)
• Kerberos-Tickets der Ressourcen-Forests des IKT-SD BA
• Per SAML oder OIDC/OAuth übertragene «Bearer-Token» wie JWT
• OTP-Token (z.B. RSA, Vasco, …)
hoch • OTP-Lösung auf der Basis eines TPM
• FIDO2-Token
• Swisscom Mobile ID
• SuisseID (solange offiziell angeboten)
• SSO-Identity/SSO-Federation des SSO-Portals
• Kerberos-Tickets der User-Forests (SG-PKI)
hoch+ • Von der SG-PKI ausgegebenes Zertifikat auf Smartcard (Klasse B)
Tabelle 1: Sicherheitsstufen einiger Authentifikations- und Identitätsnachweismittel
8/15Si003 - Netzwerksicherheit in der Bundesverwaltung
Grundsätzlich kann durch das Kumulieren von mehreren Authentifikations- und Identitäts
nachweismitteln einer Sicherheitsstufe diese Stufe nicht erhöht werden, d.h. ein der SG-PKI
ausgegebenes Software-Zertifikat bleibt z.B. in der Sicherheitsstufe «mittel», auch wenn es
mit Benutzername und Passwort mit SMS-Verifikationscode kombiniert wird.
4
Ausgenommen von den Anforderungen der Zugriffsmatrix sind anonyme und personali
sierte Zugriffsmöglichkeiten, die im Rahmen von E-Government-Anwendungen geschaffen
und einer breiten Bevölkerungsschicht in einer SZ zugänglich gemacht werden (z.B. öffentli
che Web-Auftritte der Bundesverwaltung), zeitlich befristete Zugriffsmöglichkeiten zum Hoch
laden von Daten auf ein Server-System in einer SZ10, sowie automatisierte und im Einver
ständnis mit einem Zoneninhaber durchgeführte Zugriffe im Rahmen von Sicherheitsüberprü
fungen von Web-Auftritten (Scans).
5
Ein eingeschränkter11 Zugriff in eine Zone ist für Personen und automatisierte Prozesse er
laubt, wenn diese mit einem Authentifikations- und Identitätsnachweismittel mindestens der
Stufe «mittel» authentifiziert worden sind (für Messgeräte12 auch Stufe «tief»). Erfolgt der Zu
griff in eine Zone mit erhöhtem Schutzbedarf (z.B. SZ+) muss das Authentifikations- und
Identitätsnachweismittel mindestens der Stufe «hoch» sein.
6
Ein uneingeschränkter Zugriff auf eine Zone ist nur für Personen erlaubt, die sich über ein
Client-System, das im IKT-SD BA geführt wird13, verbinden und in der PEZ mit einem Au
thentifikations- und Identitätsnachweismittel mindestens der Stufe «hoch» authentifiziert wor
den sind.
7
Die Zugriffsmatrix und die obigen Absätze 5 und 6 können folgendermassen tabellarisch
dargestellt werden [2]:
Zugreifendes IKT-System
MG PS FT
BC
(Mess- (Partner- (Fremdtermi
(Bundesclient)
gerät) system) nal)
uneingeschränkt
Zugriff
hoch hoch Zugriff nicht erlaubt
eingeschränkt tief mittel hoch mittel hoch mittel hoch
GS GS ES GS ES GS ES
Schutzbedarf
Tabelle 2: Zugriffsmatrix
10
Die Abgrenzung der entsprechenden Server-Systeme gegenüber den anderen IKT-Systemen in der SZ muss
in diesem Fall entweder in der Zonenpolicy oder – zusammen mit allen komplementären Sicherheitsmassnah
men zur Minimierung der Risiken – in der Sicherheitsdokumentation der Anwendung dokumentiert sein. Selbst
verständlich muss auch der Zoneninhaber mit dem Betrieb der Server-Systeme einverstanden sein.
11
Ein Zugriff ist eingeschränkt, wenn er mit Hilfe technischer Vorkehrungen (z.B. IP-Paketfilterung) auf ein oder
ein paar wenige definierte IKT-Systeme oder Anwendungen und auf die für den Zugriff zwingend erforderlichen
Protokolle eingeschränkt ist. Anderenfalls heisst der Zugriff uneingeschränkt.
12
Ein Messgerät ist ein IKT-System, dessen primäre Aufgabe darin besteht, Messwerte eines am Messort befind
lichen Messfühlers (Sensor) über eine dedizierte und nicht für andere Zwecke nutzbare Verbindung zu einem
geografisch abgesetzten IKT-System zu übertragen. Das empfangende IKT-System kann die Messwerte entwe
der nur sammeln und aufzeichnen oder diese auch auswerten und weiterverarbeiten. Die Kommunikation kann
bilateral erfolgen und z.B. auch die Übertragung von Steuerungsinformation an das MG beinhalten.
13
Dabei kann es sich entweder um ein Arbeitsplatzsystem (APS) oder um ein virtualisiertes, in einer Sandbox mit
Mobile Device Management (MDM) betriebenes Client-System handeln. In beiden Fällen werden alle Sicher
heitsvorgaben der Bundesverwaltung eingehalten. In [2] und Tabelle 2 werden solche Client-Systeme als Bun
desclients (BC) bezeichnet.
9/15Si003 - Netzwerksicherheit in der Bundesverwaltung
5 Weitere Anforderungen
1
Innerhalb einer Zone dürfen IKT-Systeme virtualisiert betrieben werden. Eine zonen- und
segmentübergreifende Virtualisierung ist unter Berücksichtigung der Anforderung 13.1.2 des
IKT-Grundschutzes [3] zulässig, sofern keine der betroffenen Zonenpolicies dies verbietet.
Dies betrifft namentlich auch die Teile einer PEZ, die nicht den Zonenübergang zum Internet
betreffen (hier ist eine zonenübergreifende Virtualisierung nicht zulässig).
2
Innerhalb einer Zone muss die Kommunikation dahingehend überwacht werden, dass Netz
werk-basierte Angriffe und Angriffe auf IKT-Systeme möglichst zuverlässig erkannt werden
können (z.B. mit Hilfe von Integritätsprüfungssoftware und IDS/IPS), und der Betreiber im
Bedarfsfall zeitnah und adäquat reagieren kann.
3
Jede zonenübergreifende Kommunikation muss über eine PEZ erfolgen14. Diese hat sicher
zustellen, dass die Kommunikation konform zu den betroffenen Zonenpolicies ist. Dazu müs
sen die erlaubten Kommunikationsmuster und -beziehungen in den Policies so präzis wie
möglich (idealerweise auf der Anwendungsschicht und in Form einer „White List“) spezifiziert
sein. Ist eine Konformitätsprüfung in einer PEZ nicht möglich (z.B. im Falle End-zu-End ver
schlüsselter Kommunikation), kann die Prüfung auch durch die IKT-Systeme in den Zonen
selbst durchgeführt werden (Im Sinne eines PEP). Allerdings sind dann komplementäre risi
komildernde Massnahmen vorzusehen. Das NCSC kann beratend beigezogen werden.
4
Es sollen standardisierte und etablierte Kommunikationsprotokolle aus der TCP/IP-Proto
kollsuite (statt proprietäre Protokolle) eingesetzt werden. Dabei muss das „Least Privilege“-
Prinzip im Sinne der Anforderung 7.1.4 des IKT-Grundschutzes [3] berücksichtigt sein, d.h.
es dürfen nur Protokolle unterstützen werden, die von den in der Zone betriebenen IKT-Sys
temen auch effektiv benötigt werden.
5
Im Sinne der Anforderung 13.1.5 des IKT-Grundschutzes [3] muss geregelt sein, wie der
Zugriff auf Ressourcen im Internet über eine Web-Proxy-Infrastruktur erfolgt und welche Zu
griffe zulässig sind. Diese Regelung kann entweder in der Zonenpolicy der PEZ, über die die
Zugriffe stattfinden, den Policies der betroffenen Zonen oder in einer separaten Vorgabe er
folgen. Das NCSC kann in jedem Fall Einträge in den entsprechenden Regelsätzen beitra
gen.
6
Die Anbindung einer PEZ an das Internet muss über hochverfügbar und allenfalls redun
dant ausgelegt sein. Darüber hinaus muss der Betreiber mit Hilfe geeigneter Massnahmen
sicherstellen, dass die durch die PEZ vom Internet getrennten IKT-Systeme adäquat vor De
nial-of-Service (DoS) und Distributed DoS (DDoS) Angriffen geschützt sind.
7
Für den Einsatz von kryptografischen Verfahren und Mechanismen gelten die Empfehlun
gen aus [5].
6 Finanzierung
1
Die Finanzierung einer Zone und deren Umsetzung muss vom Inhaber sichergestellt wer
den. Es gelten die Grundsätze zur Kosten- und Leistungsrechnung (KLR) in der Bundesver
waltung.
14
Obwohl das grundsätzlich auch für die Kommunikation von einer Unterzone in die darüber liegende Zone gilt,
kann in begründeten und in den Policies der entsprechenden Unterzonen dokumentierten Fällen darauf verzich
tet werden.
10/15Si003 - Netzwerksicherheit in der Bundesverwaltung
7 Inkraftsetzung und Übergangsbestimmungen
1
Die Vorgaben zur Netzwerksicherheit treten am 01. Januar 2021 in Kraft.
2
Ausnahmen sind über das IKT-Anforderungs- und Vorgabenmanagement Bund (P035) zu
beantragen.
3
DTI klärt ab, ob und wenn ja in welcher Form Zonen in Bezug auf Zweckmässigkeit und
Wirtschaftlichkeit geprüft und genehmigt werden müssen, und erlässt entsprechende Vorga
ben. In der Zwischenzeit müssen Zonen über das IKT-Anforderungs- und Vorgabenmanage
ment Bund (P035) zuhanden DTI beantragt werden.
4
Bis die Inhaberschaft der Netzdomäne blau geklärt und entsprechende Vorgaben erlassen
sind, gelten sowohl die Zonenpolicy aus Anhang A mit allen Abweichungsbewilligungen
(Ausnahmen) und Vereinbarungen15 als auch die Zugriffsmatrix aus Anhang B16.
5
Bis zum Inkrafttreten einer Vorgabe gemäss Ziffer 5 Absatz 5 gilt [6] für die Web-Proxy-Inf
rastruktur des IKT-SD DAKO.
6
Die Vorgaben zur Netzwerksicherheit in der Bundesverwaltung werden regelmässig über
prüft und bei Bedarf angepasst.
15
Dabei handelt es sich um eine Vereinbarung mit den Parlamentsdiensten.
16
Allfällige Entscheidungen diesbezüglich wird DTI dem NCSC vorlegen.
11/15Si003 - Netzwerksicherheit in der Bundesverwaltung
Abkürzungen
APS Arbeitsplatzsystem
BA Büroautomation
BC Bundesclient
BinfV Bundesinformatikverordnung
BYOD Bring Your Own Device
CAZ Central Access Zone
CC Common Criteria
CyRV Verordnung über den Schutz vor Cyberrisiken in der Bundesverwaltung
CZ Client Zone
DAKO Datenkommunikation
DDoS Distributed DoS
DoS Denial-of-Service
DTI Digitale Transformation und IKT-Lenkung
EAL Evaluation Assurance Level
FIDO Fast IDentity Online
FT Fremdterminal
HTTPS Hypertext Transfer Protocol Secure
IDS Intrusion Detection System
IKT Informations- und Kommunikationstechnik
IoT Internet of Things
IP Internet Protocol
IPS Intrusion Prevention System
ISDS Informationssicherheit und Datenschutz
ISZ Interne Server Zone
JSON JavaScript Object Notation
JWT JSON Web Token
KLR Kosten- und Leistungsrechnung
LB Leistungsbezüger
LE Leistungserbringer
LEMF Law Enforcement Monitoring Facility
LoA Level of Assurance
MDM Mobile Device Management
NCSC Nationale Zentrum für Cybersicherheit
NW Full Network Access
OAuth Open Authorization
OIDC OpenID Connect
OSI Open Systems Interconnection
OTP One-Time Password
PEP Policy Enforcement Point
PEZ Policy Enforcement Zone
PIN Personal Identification Number
RA Restricted Access
REST Representational State Transfer
SAML Security Assertion Markup Language
Schuban Schutzbedarfsanalyse
SD Standarddienst
SG-PKI Swiss Government Public Key Infrastructure
SMS Short Messaging Service
SOAP Simple Object Access Protocol
SSZ Shared Service Zone
SZ Server Zone
12/15Si003 - Netzwerksicherheit in der Bundesverwaltung
SZ+ Server Zone mit erhöhtem Schutzbedarf
TCP Transport Control Protocol
TPM Trusted Platform Module
UCC Unified Communication & Collaboration
XML Extensible Markup Language
Referenzen
[1] Verordnung über den Schutz vor Cyberrisiken in der Bundesverwaltung (CyRV) vom
27. Mai 2020
[2] Si002 – Zugriffsmatrix, Version 5.1 vom 19. Dezember 2013 (Stand 22. Mai 2019)
[3] Si001 – IKT-Grundschutz in der Bundesverwaltung, Version 4.4 vom 19. Dezember
2013 (Stand 1. Januar 2020)
[4] IKT-Standard I050 - Verlässlichkeit von Identitätsbestätigungen, Version 1.0, 1.7.2019
[5] IKT-Sicherheitsempfehlungen für den IKT-Grundschutz – Kryptografische Verfahren:
Algorithmen und Protokolle, Version 1.2 vom 13.12.2019
[6] Si004 – Regelung der Zugriffe auf Ressourcen im Internet, Web Proxy Richtlinie BV,
Version 1.3 vom 4. Oktober 2016 (Stand 1. April 2019)
13/15Si003 - Netzwerksicherheit in der Bundesverwaltung
Anhang A: Zonenpolicy «Netzdomäne blau»
A.1 Anforderungen und Vorgaben an die IKT-Systeme
1
Ein IKT-System darf in der Netzdomäne blau betrieben werden, wenn es die Anforderun
gen aus Kapitel 3a der CyRV [1] namentlich in Bezug auf Schutzbedarfsanalyse (Schuban),
IKT-Grundschutz und ISDS-Konzept erfüllt.
A.2 Anforderungen und Vorgaben an die Netzdomäne blau
1
Die Netzdomäne blau kann netzwerkmässig segmentiert sein.
2
Eine Unterzonierung in Netz-Subdomänen im Sinne von Ziffer 1.3 Buchstabe d) ist möglich.
A.3 Anforderungen und Vorgaben an die zulässige Kommunika
tion
A.3.1 Interne Kommunikation
1
Die interne Kommunikation kann direkt erfolgen und unterliegt keinen über eine Netzwerk
segmentierung im Sinne von Ziffer A.3 Absatz 1 hinausgehenden Einschränkungen.
A.3.2 Externe Kommunikation
1
Die externe Kommunikation darf nicht direkt und muss über einen oder mehrere PEPs (z.B.
in einer PEZ) erfolgen.
2
Es muss sichergestellt sein, dass ein IKT-System in der Netzdomäne blau nicht gleichzeitig
mehrere externe Kommunikationsbeziehungen mit IKT-Systemen in anderen Zonen unter
halten kann.
3
Für eingehende Kommunikationsbeziehungen gelten die folgenden Anforderungen und
Vorgaben:
a) Als Protokolle werden ausschliesslich Protokolle verwendet, die offengelegt und stan
dardisiert sind oder für die es einen vertrauenswürdigen Reverse Proxy Server gibt.
Für Webservices müssen die Protokolle/Datenformate SOAP/XML, REST/XML
und/oder REST/JSON verwendet werden.
b) Die Kommunikation wird über einen Reverse Proxy Server geführt, der (i) die die
Kommunikationsbeziehung anstossende Person authentifiziert, (ii) den Datenverkehr
absichert und (iii) die Randdaten der Kommunikation aufzeichnet und zeitnah aus
wertet. Im Falle von Webservices ist eine Authentifizierung der Prozesse (Webservice
Consumer und Webservice Provider) auf der Basis von anerkannten SSL/TLS-Zertifi
katen ausreichend, und die Absicherung des Datenverkehrs muss durch eine Über
prüfung der Nachrichteninhalte17 und eine transparente Datenverschlüsselung und -
authentifizierung auf der Basis von HTTPS erfolgen.
c) Ein unbeschränkter Netzwerkzugriff ist nur von einem IKT-System aus möglich, das
von einer Organisationseinheit der Bundesverwaltung betrieben wird.
3
Für ausgehende Kommunikationsbeziehungen gilt die Web Proxy Richtlinie BV [6].
17
Falls eine End-zu-End-Verschlüsselung zwischen Webservice Consumer und Webservice Provider erforderlich
ist und der Webservice Firewall die Nachrichteninhalte entsprechend nicht direkt überprüfen kann, sind komple
mentäre Massnahmen einzusetzen, damit die Nachrichteninhalte wenigstens indirekt überprüft werden können.
14/15Si003 - Netzwerksicherheit in der Bundesverwaltung
Anhang B: Zugriffsmatrix blaue Netzdomäne und SSZ
Die folgenden Tabellen sind der Version 4.0 der Zugriffsmatrix entnommen und gelten für die
Authentifizierung von Personen an der blauen Netzdomäne und der SSZ (Tabelle B.1), bzw.
für die Authentifizierung von Partnersystemen und Prozessen (Tabelle B.2). Die Ausnahme
bestimmungen bezüglich E-Government-Anwendungen aus Kapitel 4 Ziffer 4 gelten auch
hier.
Schutzniveau Basis (SN0) 1 (SN1) 2 (SN2)
Benutzerterminal BC BC FT FT BC BC FT FT BC BC FT FT
Zugriffsmethode NW RA NW RA NW RA NW RA NW RA NW RA
Hard Crypto Token j j n j j j n j j j n j
Blaue Netzdomäne
OTP j j n j j j n j j j n j
OTP ohne Device n j n j n j n j n n n n
Soft Crypto Token n n n n n n n n n n n n
Password or PIN token n n n n n n n n n n n n
Hard Crypto Token j18) j n j j18) j n j j18) j n j
OTP j18) j n j j18) j n j j18) j18) n j
SSZ
OTP ohne Device n j n j n j n j n n n n
Soft Crypto Token n j n j n j n j n n n n
Password or PIN token n j n j n j n j n n n n
Tabelle B.1: Authentifizierung von Personen an der blauen Netzdomäne bzw. der SSZ
Schutzniveau Basis (SN0) 1 (SN1) 2 (SN2)
Zugriffsmethode NW RA NW RA NW RA
Blaue Netzdomäne /
Hard Crypto Token n j n j n j
OTP / OTP ohne Device Keine praktischen Anwendungen
SSZ
Soft Crypto Token n j n j n j19)
Password or PIN token n j20) n n n n
Tabelle B.2: Authentifizierung von Partnersystemen und entsprechenden Prozessen
18
Der einzige Anwendungsfall ist die Administration von Systemen via Admin-LAN (Management Zone LE).
19
Nur zulässig für den Zugriff auf Sedex und andere Anwendungen, über die nur standardisierte Nachrichten aus
getauscht und/oder definierte Abläufe verfolgt werden können.
20
Nur zulässig für Telemetriedaten (Messgeräte).
15/15Sie können auch lesen
