Si003 - Sécurité des réseaux dans l'adminis-tration fédérale - Sécurité des réseaux dans l'administration ...
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Département fédéral des finances DFF
Centre national pour la cybersécurité NCSC
Sécurité informatique de la Confédération SEC
Version 3.1
Si003 - Sécurité des réseaux dans l’adminis
tration fédérale
du 19 décembre 2013 (état au 1er avril 2021)
En vertu de l’art. 11, al. 1, let. e, de l’ordonnance du 27 mai 2020 sur les cyber
risques (OPCy) [1], le délégué à la cybersécurité édicte les prescriptions suivantes sur la sé
curité des réseaux, qui s’appliquent à la protection de base conformément à l’art. 14c OPCy.
Les prescriptions Si002 - Matrice d'accès, version 5.1 du 19 décembre 2013 (état au 22 mai
2019), [2] sont incorporées dans le présent document et abrogées à l’entrée en vigueur de
celui-ci.Si003 - Sécurité des réseaux dans l’administration fédérale
Table des matières
Table des matières .................................................................................................... 2
1 Dispositions générales ................................................................................ 3
1.1 Objet........................................................................................................................ 3
1.2 Champ d’application .............................................................................................. 3
1.3 Définitions .............................................................................................................. 3
2 Modèle de zones de la Confédération......................................................... 4
3 Principes ....................................................................................................... 6
4 Matrice d’accès ............................................................................................. 7
5 Autres exigences ........................................................................................ 10
6 Financement ............................................................................................... 11
7 Entrée en vigueur et dispositions transitoires ......................................... 12
Abréviations............................................................................................................. 12
Références ............................................................................................................... 13
Annexe A: Réglementation de zone «Domaine de réseau bleu» ........................ 14
A.1 Exigences et prescriptions relatives aux systèmes informatiques .................. 14
A.2 Exigences et prescriptions relatives au domaine de réseau bleu .................... 14
A.3 Exigences et prescriptions relatives à la communication autorisée ................ 14
A.3.1 Communication interne ....................................................................................... 14
A.3.2 Communication externe ...................................................................................... 14
Annexe B: Matrice d’accès domaine de réseau bleu et SSZ ............................... 16
2/17Si003 - Sécurité des réseaux dans l’administration fédérale
1 Dispositions générales
1.1 Objet
1
Les présentes prescriptions doivent être considérées comme une partie des directives sur
la protection informatique de base dans l'administration fédérale [3] et s’appliquent spécifi
quement à la sécurité des réseaux.
1.2 Champ d’application
1
Le champ d’application est réglé par l’art. 2 de l’ordonnance du 27 mai 2020 sur les cyber
risques (OPCy) [2].
1.3 Définitions
1
Les définitions suivantes s’appliquent dans les présentes prescriptions:
a) Système informatique (système): système technique d’information et de communi
cation qui est exploité comme un logiciel sur un matériel dédié ou virtualisé, respecti
vement une machine virtuelle1. Dans le deuxième cas, on parle de système informa
tique virtualisé.
b) Un système informatique est2:
• un système serveur lorsqu’il est avant tout un fournisseur de prestations in
formatiques;
• un système client lorsqu’il est avant tout le bénéficiaire de prestations infor
matiques;
• un élément du réseau lorsqu’il sert principalement à transporter des données
entre d’autres systèmes informatiques tels que des switches, des routeurs ou
des filtres de paquets statiques simples (pare-feu IP). Dans le modèle de réfé
rence OSI (open systems interconnection), les éléments du réseau évoluent
jusqu’à la couche 4 (couche transport), y compris celle-ci;
• un point d’application des règles ou policy enforcement point (PEP) lorsqu’il
sert principalement à mettre en œuvre des règles (provenant de réglementa
tions). Exemples: filtres de paquets dynamiques, gateway (passerelles) pour
protocoles d’application, serveurs proxy et proxy inverse3. Dans le modèle de
référence OSI, les PEP évoluent jusqu’à la couche 7 (couche application), y
compris celle-ci.
c) Zone: regroupement logique de systèmes informatiques qui présentent des exi
gences de sécurité similaires et sont soumis à la même réglementation (policy) de
zone. Par conséquent, une zone n’est pas limitée à un périmètre précis (p. ex. un
centre de calcul). Le raccordement au niveau réseau des éléments d’une zone est ré
alisé grâce aux éléments du réseau, tandis que l’application de la réglementation de
zone relève des PEP. Dans l’idéal, ces derniers sont exploités dans une Policy enfor
cement zone (PEZ).
1
Le système informatique qui met à disposition le matériel virtualisé ou la machine virtuelle (hyperviseur) est lui
aussi un logiciel et constitue donc un système informatique autonome.
2
Cette distinction n’est pas précise, car un système informatique peut exécuter simultanément plusieurs fonctions
et, partant, être considéré tant comme un système serveur que comme un système client.
3
Un PEP travaille sur la couche application et contrôle le(s) protocole(s) transmis; c’est sa principale caractéris
tique.
3/17Si003 - Sécurité des réseaux dans l’administration fédérale
d) Sous-zone: une zone peut être subdivisée en sous-zones si la réglementation cor
respondante le prévoit. À son tour, chaque sous-zone constitue une zone. En particu
lier, toute sous-zone doit avoir une réglementation qui peut uniquement renforcer
celle de la zone supérieure; en d’autres termes, cette règle ne peut contenir que des
exigences ou prescriptions supplémentaires (tout assouplissement est proscrit). En
principe, une sous-zone peut être subdivisée en sous-zones supplémentaires, mais
uniquement en cas d’absolue nécessité.
e) Segment: partie d'un réseau (à l'intérieur d'une zone) qui - pour des raisons d'équili
brage de charges ou de sécurité - est séparée du reste du réseau au moyen de com
posants de réseau conformément aux prescriptions de la réglementation de zone.
Tous les segments d'un réseau (au sein d'une zone) sont en principe soumis à la
même réglementation de zone, les restrictions sélectives demeurant possibles.
2 Modèle de zones de la Confédération
1
Le modèle de zones de la Confédération est un modèle générique destiné à la création de
zones dans l’administration fédérale qui est contraignant pour toutes les unités administra
tives (bénéficiaires et fournisseurs de prestations). Il définit en particulier comment les sys
tèmes informatiques et les réseaux de la Confédération doivent être organisés et gérés en
zones et en sous-zones.
2
À l’exception d’Internet, chaque (sous-)zone doit avoir un propriétaire et un exploitant (voir
ch. 3). Le propriétaire est responsable de la réglementation de zone et l’exploitant de la mise
en œuvre de celle-ci. Lorsque le propriétaire d’une (sous-)zone en modifie la réglementation,
un délai raisonnable de mise en œuvre doit être accordé à l’exploitant.
Illustration 1: Modèle (générique) de zones de la Confédération
4/17Si003 - Sécurité des réseaux dans l’administration fédérale
3
L’illustration 1 présente le modèle de zones de la Confédération sous forme de schéma. On
distingue les zones et sous-zones suivantes:
a) Internet: zone qui ne correspond à aucun critère des autres zones et pour laquelle
aucune exigence (de sécurité) ne peut être définie;
b) Policy enforcement zone (PEZ)4: zone pour les PEP nécessaires à l’application des
règles de communication externe avec d’autres zones;
c) zone de services (Service Zone): zone destinée aux systèmes serveurs néces
saires à la fourniture de services d’infrastructure (p. ex. serveurs DNS et serveurs de
temps);
d) zone de serveurs (Server Zone, SZ): zone destinée à des systèmes sur lesquels
sont gérées des applications spécialisées dont le besoin de protection n’est pas élevé
selon l’analyse des besoins de protection (Schuban);
e) zone de serveurs avec besoin de protection élevé (SZ+): sous-zone de la SZ des
tinée à des systèmes serveurs sur lesquels sont gérées des applications spécialisées
ayant un besoin de protection élevé selon l’analyse des besoins de protection (Schu
ban);
f) Client Zone (CZ): zone destinée aux systèmes clients. L’exploitation de systèmes
serveurs dans la CZ ou une sous-zone est autorisée si la réglementation (policy) cor
respondante le prévoit et si ces systèmes serveurs sont utilisés principalement par
les systèmes clients de la même (sous-)zone (p. ex. serveur local de bureautique ou
d’impression);
g) zone SPT: sous-zone de la CZ destinée aux systèmes clients qui fonctionnent
comme des systèmes de poste de travail (SPT) et sont utilisés exclusivement pour le
service standard Bureautique / UCC;
h) zone invités: sous-zone de la CZ destinée aux systèmes clients qui ne sont pas gé
rés par une unité administrative de la Confédération, tels que les appareils utilisés
par des collaborateurs externes ou des employés de l’administration fédérale dans le
cadre de la politique «Bring Your Own Device» (BYOD);
i) zone spéciale: zone destinée aux systèmes informatiques de l’administration fédé
rale qui présentent des caractéristiques particulières et des exigences correspon
dantes (p. ex. exploitation autosuffisante ou connexion réseau à faible bande) et qui
peuvent être administrés depuis la zone de gestion (p. ex. réseau de transport assorti
d’exigences spécifiques);
j) zone technique: zone particulière destinée aux systèmes informatiques et systèmes
de l’Internet des objets (Internet of Things, IoT) (p. ex. systèmes techniques des bâti
ments ou de facility management, systèmes d’enregistrement du temps de travail,
systèmes de mesure ou systèmes de télédiagnostic);
k) zone de gestion: zone particulière destinée aux systèmes informatiques qui sont uti
lisés exclusivement pour administrer les systèmes informatiques des autres zones.
En plus de ces zones, différents domaines de réseau peuvent être gérés dans le cadre des
dispositions transitoires énoncées au ch. 7, al. 2. Ils ne font pas partie du modèle de zones
et ne figurent dès lors pas dans l’illustration 1.
4
Chaque (sous-)zone du modèle de zones de la Confédération peut être mise en œuvre plu
sieurs fois.
5
Si une application spécialisée n'est pas exploitée dans une zone de l'administration fédé
rale (p. ex. dans un nuage public), la documentation de sécurité correspondante (c'est-à-dire
4
zone d’application des règles
5/17Si003 - Sécurité des réseaux dans l’administration fédérale
la mise en œuvre de mesures pour la protection informatique de base ou le concept SIPD
élargi) doit expliquer comment un niveau de sécurité adéquat comparable à celui de l'admi
nistration fédérale peut être atteint et garanti dans cet environnement. Cette documentation
doit être examinée par le délégué à la sécurité informatique (DSIO) et approuvée par le res
ponsable du processus d’affaires.
Les explications suivantes s’appliquent tant aux zones qu’aux sous-zones. Pour faciliter la
lecture, seul le terme «zone» est utilisé ci-après.
3 Principes
1
Dans l’administration fédérale, peuvent être créées et gérées uniquement des zones con
formes au modèle de zones de la Confédération, qui répondent aux prescriptions énoncées
au ch. 4 (Matrice d’accès) et au ch. 5 (Exigences de sécurité) et ont un propriétaire, un nom
univoque, une réglementation (policy) de zone fixée par le propriétaire et un exploitant.
a) Propriétaire: nom de l’unité administrative de la Confédération qui est responsable
de la zone. Le propriétaire d’une zone doit en assurer le financement (cf. ch. 6) et dé
cider des systèmes informatiques pouvant être gérés dans la zone.
b) Nom: nom univoque de la zone. Une possibilité est d’accoler le propriétaire au nom
en tant que suffixe (p. ex. SZ-BAC pour une zone de serveurs gérée par la Base
d’aide au commandement). Si un propriétaire met plusieurs fois en œuvre une zone,
les noms correspondants doivent être clairement différenciés.
c) Réglementation de zone: établie par le propriétaire selon les prescriptions du
NCSC, elle décrit de manière structurée les exigences et les conditions relatives
• aux systèmes informatiques de la zone;
• à la zone elle-même (p. ex. peut-elle être segmentée sur le réseau et, si oui, com
ment?);
• à l'authentification des personnes et des processus automatisés qui sont autori
sés à accéder aux systèmes et applications informatiques exploités dans la zone
(conformément à la matrice d'accès ch. 4), et
• à la communication interne (qui peut s’étendre à plusieurs segments) et externe
(qui peut dépasser le simple cadre de la PEZ) autorisée pour la zone, c’est-à-dire
les communications entrantes et sortantes admises5. Une communication entre
deux ou plusieurs zones similaires6 est considérée comme interne si les inter
faces entre les zones sont conformes aux réglementations (policy) correspon
dantes et sont contrôlées par la PEZ commune. La communication externe en
globe également les communications avec les domaines de réseau qui sont en
core gérés au sens des dispositions transitoires visées au ch. 7, al. 2.
d) Exploitant: nom de l’unité administrative de la Confédération qui est le fournisseur
de prestations et exploite au niveau du réseau la zone sur mandat du propriétaire7.
En particulier, l'exploitant doit s'assurer que seules les communications à destination
5
Une communication est sortante lorsque l’échange de données correspondant est initié par un système informa
tique de la zone en question. Dès lors, elle est entrante lorsque l’échange de données a certes été initié par un
système informatique situé hors de la zone, mais s’adresse à un système informatique se trouvant dans cette
dernière. Dans les deux cas, les données peuvent être échangées dans les deux directions.
6
Les zones peuvent appartenir à des propriétaires différents.
7
Si le propriétaire de la zone est un fournisseur de prestations, il peut être identique à l’exploitant. Si la zone
comprend des systèmes et des applications informatiques qui sont exploités en dehors de l'administration fédé
rale (p. ex. dans un nuage public), l'exploitation de la zone est alors limitée à l'accès au réseau de ces systèmes
et applications informatiques.
6/17Si003 - Sécurité des réseaux dans l’administration fédérale
et en provenance de la zone qui sont autorisées par la réglementation de zone peu
vent avoir lieu et que, à l'aide de mesures de sécurité complémentaires appropriées,
ces communications ne constituent pas une menace supplémentaire pour les autres
zones. Sauf mention contraire dans la réglementation de zone, des systèmes infor
matiques d’autres fournisseurs de prestations (aussi externes) peuvent, avec l’accord
du propriétaire de la zone, également être gérés au sein de la zone. Ces fournisseurs
sont alors coresponsables du respect de la réglementation de zone dans leurs do
maines de responsabilité respectifs.
2
Chaque zone doit être documentée et contrôlée8 par le propriétaire et l'exploitant d'une ma
nière analogue à la documentation de sécurité d'une application spécialisée.
3
La SIPD tient à jour une liste des zones dans lesquelles une unité administrative du dépar
tement est soit propriétaire soit exploitant et met cette liste à la disposition du NCSC.
4
Tout système informatique utilisé dans l’administration fédérale doit être affecté à une zone
et exploité conformément à la réglementation (policy) en vigueur pour cette dernière. Du
point de vue des présentes prescriptions, si un système informatique n’est rattaché à aucune
autre zone, il fait partie d’Internet.
4 Matrice d’accès
1
La matrice d'accès définit les exigences minimales applicables à l'authentification (centrali
sée ou décentralisée) ou aux moyens d'authentification et de vérification d'identité corres
pondants. Sur cette base, conformément au ch. 3, al. 1, let. c), la politique de zone doit préci
ser comment les personnes et les processus automatisés peuvent accéder aux systèmes et
applications informatiques exploités dans la zone, c’est-à-dire comment ceux-ci doivent être
authentifiés et, le cas échéant, autorisés. En outre, le propriétaire d'un système ou d'une ap
plication peut également spécifier des exigences supplémentaires concernant le type et le
mode d'accès ou empêcher certaines voies d'accès.
2
En principe, l'authentification doit être effectuée de manière centralisée dans la PEZ avant
l'accès à la zone. Si cela n'est pas possible ou judicieux, l'authentification peut également
avoir lieu de manière décentralisée sur un PEP dans la zone même. Dans ce cas, la régle
mentation de zone doit toutefois préciser comment les systèmes informatiques et les applica
tions spécialisées exploités dans la zone sont protégés contre les accès non autorisés. En
particulier, la segmentation du réseau et l'isolation la plus complète possible de ces sys
tèmes informatiques et des applications spécialisées sont alors nécessaires.
3
Les moyens d'authentification et de vérification d'identité disponibles avec les protocoles de
fédération afférents sont répartis selon les quatre niveaux de sécurité suivants (faible,
moyen, élevé et élevé+)9:
a) Faible: les informations d'authentification transmises par le réseau étant statiques et
identiques pour chaque authentification, elles peuvent être exploitées par un intrus et
utilisées à mauvais escient, par exemple pour une attaque par rejeu suivie d’une
8
Le DSIO du propriétaire ou du FP est responsable de l'inspection. Du côté du FP, il faut notamment vérifier que
l'exploitation de la zone ne donne pas lieu à des risques supplémentaires qui ne peuvent être évalués par les
propriétaires des autres zones.
9
En principe, la norme informatique I050 [4] définit quatre niveaux de garantie (Level of Assurance, LoA 1 – 4),
qui pourraient être utilisés pour spécifier les exigences minimales de sécurité applicables aux moyens d'authen
tification et de vérification d'identité à utiliser. Toutefois, comme la classification LoA des moyens d'authentifica
tion et de vérification de l'identité actuellement disponibles et utilisés n'est pas encore disponible, une simple
classification axée sur quelques aspects techniques de sécurité des moyens d'authentification et de vérification
de l'identité eux-mêmes est utilisée ici comme solution provisoire.
7/17Si003 - Sécurité des réseaux dans l’administration fédérale
usurpation d'identité. Le nom d'utilisateur et le mot de passe sont des exemples ty
piques pour ce genre d’informations d’authentification. Si celles-ci sont utilisées en
tant que jeton de fédération au sens de [4], il suffit de les protéger à un niveau faible
contre les attaques visant leur intégrité et de les relier au contexte de l'utilisateur. À
titre d'exemple, on peut citer divers «jetons au porteur» tels que les cookies.
b) Moyen: les informations d'authentification sont systématiquement modifiées à
chaque connexion et ne peuvent donc pas être utilisées à mauvais escient pour une
attaque de rejeu suivie d’une usurpation d'identité. Font partie de cette catégorie par
exemple les noms d'utilisateur et les mots de passe avec code de vérification envoyé
par SMS10 ou la restriction à un appareil, les solutions logicielles utilisant des mots de
passe à usage unique (one-time password [OTP], p. ex. Google Authenticator) ainsi
que les certificats logiciels délivrés par la SG-PKI (classe C, D ou E). Si les informa
tions d'authentification sont utilisées comme un jeton de fédération, elles doivent être
protégées contre les attaques visant leur intégrité et liées au contexte de l'utilisateur
d'une manière qui correspond à l'état de la technique. On peut citer comme exemples
les tickets Kerberos des forêts de ressources de la norme standard Bureautique,
ainsi que les jetons au porteur tels JWT transmis via SAML ou OIDC/OAuth.
c) Élevé: les informations d'authentification sont dynamiques et dépendent d'une clé
cryptographique qui est stockée dans un module matériel dédié et ne peut, en dé
ployant un effort raisonnable, pas être déchiffrée à l’aide de ce module. Si le moyen
d'authentification et de vérification d'identité est personnel, l'enregistrement de la per
sonne ou la remise du moyen de vérification à celle-ci doit être basé sur un document
d'identité officiel (passeport ou carte d'identité, p. ex.). Si la vérification de l'identité de
la personne et l'enregistrement ont lieu conjointement, les moyens d'identification doi
vent être remis par courrier recommandé. La remise peut également être protégée
par un code secret (mot de passe ou NIP, p. ex.) ou par des caractéristiques biomé
triques (Touch ID ou Face ID avec Apple, Hello avec Windows, p. ex.). Cette catégo
rie comprend notamment les jetons OTP, les solutions OTP basées sur un TPM, les
jetons FIDO2, l'ID Mobile de Swisscom et la SuisseID. Si les informations d'authentifi
cation sont utilisées en tant que jeton de fédération, elles doivent être protégées
contre les attaques visant leur intégrité et liées au contexte de l'utilisateur d'une ma
nière qui correspond à l'état de la technique. Globalement, la procédure de fédération
doit correspondre à un profil de protection comparable au CC EAL4+. Il s'agit par
exemple de l'identité SSO/fédération SSO du portail SSO et des tickets Kerberos des
forêts utilisateurs, si ceux-ci ont été émis sur la base d'une authentification de l'utilisa
teur avec un certificat délivré par la SG-PKI.
d) Élevé+: les moyens d'authentification et de preuve d'identité répondent aux exi
gences du niveau «élevé» (y c. les exigences applicables au protocole de fédération).
En outre, le NCSC doit approuver tant le module matériel que le processus d'enregis
trement sous-jacent avant leur utilisation par l'administration fédérale. Cette catégorie
ne comprend que les certificats de classe B délivrés par la SG-PKI sur des cartes à
puce.
Les exemples cités dans le texte et figurant sous forme de résumé dans le tableau 1 ne
constituent pas une liste exhaustive.
Niveau de
Exemples de moyens d'authentification et de preuves d'identité
sécurité
10
Même si le nom d'utilisateur et le mot de passe avec le code de vérification envoyé par SMS apparaissent dans
cette liste, ils ne devraient plus être utilisés comme moyen d'authentification et de preuve d'identité en l’état ac
tuel des connaissances. Il s’est en effet révélé dans la pratique que la vérification par SMS est trop souvent ai
sément contournée.
8/17Si003 - Sécurité des réseaux dans l’administration fédérale
faible • Nom d’utilisateur et mot de passe
• «Jeton au porteur» (p. ex. cookies)
moyen • Nom d'utilisateur et mot de passe avec code de vérification envoyé par
SMS9
• Nom d'utilisateur et mot de passe avec restriction à un appareil
• Solution logicielle OTP (p. ex. Google Authenticator)
• Certificat logiciel délivré par la SG-PKI (classe C, D ou E)
• Tickets Kerberos de la forêt de ressources du service standard Bureau
tique
• «Jeton au porteur» tel JWT transmis par SAML ou OIDC/OAuth
• Jeton OTP (p. ex. RSA, Vasco, …)
élevé • Solution OTP basée sur un TPM
• Jeton FIDO2
• Swisscom Mobile ID
• SuisseID (pour autant qu'elle soit officiellement offerte)
• SSO-Identity/fédération SSO du portail SSO
• Tickets Kerberos des forêts utilisateur (SG-PKI)
élevé + • Certificat délivré par la SG-PKI sur carte à puce (classe B)
Tableau 1: niveaux de sécurité de moyens d'authentification et de vérification d'identité sélectionnés
Fondamentalement, un niveau de sécurité ne peut pas être amélioré en cumulant plusieurs
moyens d'authentification et de vérification d'identité de même niveau. Ainsi, un certificat lo
giciel délivré par la SG-PKI reste par exemple au niveau de sécurité «moyen», même s'il est
combiné avec un nom d'utilisateur et un mot de passe avec code de vérification envoyé par
SMS.
4
Sont exceptées des exigences applicables à la matrice d'accès les possibilités d'accès ano
nymes et personnalisées qui sont créées dans le cadre des applications de cyberadministra
tion et rendues accessibles à une large partie de la population dans une SZ (p. ex. les sites
Internet publics de l'administration fédérale), les options d'accès temporaires pour le télé
chargement de données vers un système serveur dans une SZ11, ainsi que les accès auto
matisés effectués avec le consentement d'un propriétaire de zone dans le cadre des con
trôles de sécurité des sites Internet (scans).
5
L'accès restreint12 à une zone est autorisé aux personnes et aux processus automatisés qui
ont été authentifiés par un moyen d'authentification et de vérification de l'identité d'un niveau
au moins «moyen» (pour les appareils de mesure13, le niveau «faible» peut suffire). Si l'ac
cès se fait à une zone avec des exigences de protection accrues (par exemple SZ+), les
11
Dans ce cas, la délimitation des systèmes de serveurs correspondants par rapport aux autres systèmes infor
matiques de la SZ doit être documentée soit dans la réglementation de zone, soit – conjointement avec toutes
les mesures de sécurité complémentaires visant à minimiser les risques - dans la documentation de sécurité de
l'application. Bien entendu, le propriétaire de la zone doit également donner son accord à l’exploitation des sys
tèmes de serveurs.
12
L'accès est restreint si, à l'aide de précautions techniques (p. ex., le filtrage des paquets IP), il est limité à un ou
quelques systèmes ou applications informatiques définis et aux protocoles qui sont absolument nécessaires
pour l'accès. Dans tous les autres cas, l'accès est réputé illimité.
13
Un appareil de mesure est un système informatique dont la tâche principale est de transmettre les valeurs en
registrées par une sonde de mesure (capteur) sur le lieu de mesure à un système informatique géographique
ment distant au moyen d’une connexion dédiée qui ne peut être utilisée à d'autres fins. Le système informatique
9/17Si003 - Sécurité des réseaux dans l’administration fédérale
moyens d'authentification et de preuve d'identité doivent être au moins du niveau «élevé».
6
L'accès sans restriction à une zone n'est autorisé qu'aux personnes qui se connectent en
passant par un système client géré au sein du service standard Bureautique14 et qui ont été
authentifiées dans la PEZ avec un moyen d'authentification et de vérification d'identité por
tant au moins le niveau «élevé».
7
La matrice d'accès et les al. 5 et 6 ci-dessus peuvent être schématisés sous forme de ta
bleau comme suit [2]:
Système informatique qui demande l’accès
Ap
pareil Système par Terminaux de
de Client fédéral
tenaire tiers
mesure
illimité élevé élevé Accès interdit
Accès
restreint faible moye moye moye
élevé élevé élevé
n n n
PB PE PE PB PE PB PE
Besoin de protection
Tableau 2: matrice d’accès
5 Autres exigences
1
Les systèmes informatiques peuvent être gérés de manière virtualisée au sein d’une zone.
Une virtualisation interzone ou intersegment est autorisée en tenant compte de l’exi
gence 13.1.2 de la protection informatique de base [3], à condition qu’aucune réglementation
des zones concernées ne l’interdise. Cela vaut également pour les parties d’une PEZ qui ne
concernent pas les interfaces avec Internet (dans ce cas, la virtualisation interzone est pros
crite).
2
La communication au sein d’une zone doit être surveillée de telle manière que les attaques
en réseau et les attaques de systèmes informatiques puissent être identifiées de manière
aussi fiable que possible (p. ex. grâce à des logiciels vérifiant l’intégrité et des systèmes de
détection ou de prévention d’intrusion [intrusion detection system, IDS, et intrusion preven
tion system, IPS]) et que l’exploitant puisse réagir rapidement et adéquatement en cas de
besoin.
récepteur peut soit uniquement collecter et enregistrer les valeurs mesurées, soit les évaluer et les traiter. La
communication peut être bilatérale et peut, par exemple, également transmettre des informations concernant le
pilotage à l’appareil de mesure.
14
Il peut s'agir soit d'un système de poste de travail (SPT), soit d'un système client virtualisé exploité dans un en
vironnement sécurisé (sandbox) au moyen d’un système de gestion des terminaux mobiles (MDM). Dans les
deux cas, toutes les exigences de sécurité de l'administration fédérale sont respectées. Dans [2] et le tableau 2,
ces systèmes de clients sont appelés clients fédéraux.
10/17Si003 - Sécurité des réseaux dans l’administration fédérale
3
Toute communication interzone doit passer par une PEZ15. Celle-ci doit s’assurer que la
communication est conforme à la réglementation des zones concernées. Pour ce faire, les
modèles et relations de communication autorisés doivent être définis aussi précisément que
possible dans les réglementations des zones (dans l’idéal sur la couche applicative et sous
forme de liste blanche [white list]). Si un test de conformité dans une PEZ n'est pas possible
(p. ex. dans le cas d'une communication cryptée de bout en bout), le test peut également
être effectué par les systèmes informatiques dans les zones elles-mêmes (au sens d'une
PEP). Toutefois, des mesures complémentaires d'atténuation des risques doivent alors être
prévues. Le NCSC peut apporter un soutien à titre consultatif.
4
Des protocoles de communication standardisés et établis provenant de la suite de proto
coles TCP/IP doivent être utilisés (au lieu de protocoles propriétaires). Ce faisant, le principe
du moindre privilège (least privilege) au sens de l’exigence 7.1.4 de la protection informa
tique de base [3] doit être pris en compte, ce qui signifie que seuls les protocoles qui sont ef
fectivement requis par les systèmes informatiques opérant dans la zone peuvent être pris en
charge.
5
Conformément à l'exigence 13.1.5 de la protection informatique de base [3], il faut régle
menter la manière dont l'accès aux ressources sur Internet se fait via une infrastructure
proxy web et quels accès sont autorisés. Il est possible de le faire soit dans le cadre de la ré
glementation de zone de la PEZ par laquelle les accès ont lieu, soit dans les réglementations
des zones concernées, soit dans des directives distinctes. Dans tous les cas, le NCSC peut
participer à l’élaboration des ensembles de règles correspondants.
6
La connexion d’une PEZ à Internet doit être hautement disponible, voire redondante. En
outre, l’exploitant doit s’assurer grâce à des mesures appropriées que les systèmes informa
tiques séparés d’Internet par la PEZ sont dûment protégés contre des attaques de déni de
service (denial of service, DoS) et de déni de service distribué (distributed DoS, DDoS).
7
Les recommandations de sécurité [5] s’appliquent à l’utilisation de procédés et mécanismes
cryptographiques.
6 Financement
1
Le financement d’une zone et sa mise en œuvre doivent être garantis par le propriétaire.
Les principes de la comptabilité analytique (CA) dans l’administration fédérale s’appliquent.
15
Bien que cela s’applique en principe également pour la communication d'une sous-zone vers sa zone supé
rieure, il est possible d'y renoncer dans des cas justifiés documentés dans les réglementations des sous-zones
correspondantes.
11/17Si003 - Sécurité des réseaux dans l’administration fédérale
7 Entrée en vigueur et dispositions transitoires
1
Les prescriptions sur la sécurité des réseaux entrent en vigueur le 1er janvier 2021.
2
Toute dérogation doit être sollicitée en passant par la Gestion des exigences et des direc
tives concernant l’informatique de l’administration fédérale (P035).
3
Le secteur TNI précise si et, le cas échéant, sous quelle forme les zones doivent être exa
minées quant à leur pertinence et leur rentabilité et approuvées, et publie les directives cor
respondantes. Dans l’intervalle, les zones doivent être sollicitées à l'intention du secteur TNI
en passant par la Gestion des exigences et des directives concernant l’informatique de l’ad
ministration fédérale (P035).
4
Tant que la propriété du domaine de réseau bleu n'a pas été clarifiée et que les directives
correspondantes n'ont pas été publiées, la réglementation de zone de l'annexe A avec toutes
les autorisations de dérogation (exceptions) et accords16 et la matrice d'accès de l'annexe
B17 s'appliquent.
5
Jusqu'à l'entrée en vigueur d'une directive conformément au ch. 5, al. 5, [6] s'applique à
l'infrastructure proxy web du service standard Transmission de données.
6
Les prescriptions sur la sécurité des réseaux dans l’administration fédérale sont vérifiées
régulièrement et adaptées en cas de besoin.
Abréviations
BP bénéficiaire de prestations
BYOD Bring Your Own Device
CAZ Central Access Zone
CF Client fédéral
CZ Client Zone
DDoS Distributed DoS, déni de service distribué
DoS Denial of Service, déni de service
EAL Evaluation Assurance Level, niveau d’évaluation
FIDO Fast IDentity Online
FP fournisseur de prestations
HTTPS Hypertext Transfer Protocol Secure
IDS Intrusion Detection System, système de détection d’intrusion
IoT Internet of Things, Internet des objets
IP Internet Protocol, protocole Internet
IPS Intrusion Prevention System, système de prévention d’intrusion
JSON JavaScript Object Notation
JWT JSON Web Token
LEMF Law Enforcement Monitoring Facility
LoA Level of Assurance, niveau de garantie
MDM Mobile Device Management, gestion des terminaux mobiles
NCSC Centre national pour la cybersécurité
NIP code confidentiel (numéro d’identification personnel)
NW Full Network Access
OAuth Open Authorization
OIAF ordonnance sur l’informatique dans l’administration fédérale
OIDC OpenID Connect
OPCy ordonnance sur les cyberrisques
OSI Open Systems Interconnection
16
Il s'agit d'un accord avec les services du Parlement.
17
Toute décision à cet égard sera soumise par le secteur TNI au NCSC.
12/17Si003 - Sécurité des réseaux dans l’administration fédérale
OTP One-Time Password, mot de passe à usage unique
PB protection de base
PE protection élevée
PEP Policy Enforcement Point, point d’application des règles
PEZ Policy Enforcement Zone, zone d’application des règles
RA Restricted Access, accès limité
REST Representational State Transfer
SAML Security Assertion Markup Language
Schuban analyse des besoins de protection
SG-PKI Swiss Government Public Key Infrastructure
SIPD sécurité de l’information et protection des données
SMS Short Messaging Service, texto
SOAP Simple Object Access Protocol
SPT système de poste de travail
SSZ Shared Service Zone
SZ zone de serveurs (Server Zone)
SZ+ zone de serveurs présentant un besoin de protection élevé
TCP Transport Control Protocol
TIC technologies de l’information et de la communication
TPM Trusted Platform Module
TT Terminal de tiers
UCC Unified Communication & Collaboration
XML Extensible Markup Language
Références
[1] Ordonnance du 27 mai 2020 sur la protection contre les cyberrisques dans l’adminis
tration fédérale (ordonnance sur les cyberrisques, OPCy)
[2] Si002 - Matrice d’accès, version 5.1 du 19 décembre 2013 (état au 22 mai 2019)
[3] Si001 - Protection informatique de base dans l’administration fédérale, version 4.4 du
19 décembre 2013 (état au 1er janvier 2020)
[4] Norme informatique I050 - Fiabilité des confirmations d'identité, version 1.0, 1er juillet
2019
[5] Recommandations de sécurité informatique pour la protection de base - Procédés
cryptographiques: algorithmes et protocoles, version 1.2 du 13 décembre 2019
[6] Si004 - Réglementation de l’accès aux ressources sur Internet. Directive de l’adminis
tration fédérale relative aux proxys web, version 1.3 du 4 octobre 2016 (état au 1er avril
2019)
13/17Si003 - Sécurité des réseaux dans l’administration fédérale
Annexe A: Réglementation de zone «Domaine de réseau
bleu»
A.1 Exigences et prescriptions relatives aux systèmes informa
tiques
1
Un système informatique peut être géré dans le domaine de réseau bleu s’il remplit les exi
gences visées au chapitre 3a de l’OPCy [7], à savoir les exigences relatives à l’analyse des
besoins de protection (Schuban), à la protection informatique de base et au concept SIPD.
A.2 Exigences et prescriptions relatives au domaine de réseau
bleu
1
Le domaine de réseau bleu peut être segmenté18.
2
Une subdivision en sous-domaines de réseau au sens du ch. 1.3, let. d, est possible.
A.3 Exigences et prescriptions relatives à la communication
autorisée
A.3.1 Communication interne
1
La communication interne peut être réalisée directement. Elle n’est soumise à aucune res
triction allant au-delà d’une segmentation réseau au sens du ch. A.3, al. 1.
A.3.2 Communication externe
1
La communication externe ne doit pas être réalisée directement, mais doit passer par un ou
plusieurs PEP (p. ex. dans une PEZ).
2
Il faut s’assurer qu’un système informatique du domaine de réseau bleu ne peut pas entre
tenir simultanément plusieurs communications externes avec des systèmes informatiques
d’autres zones.
3
Les exigences et prescriptions suivantes s’appliquent aux communications entrantes:
a) Seuls des protocoles qui sont publiés et standardisés ou pour lesquels il existe un
serveur reverse proxy digne de confiance peuvent être utilisés en tant que tels. Les
protocoles et formats de données SOAP/XML, REST/XML et/ou REST/JSON doivent
être employés pour les services web.
b) La communication est réalisée grâce à un serveur reverse proxy qui (i) authentifie la
personne initiant la communication, (ii) protège le trafic des données et (iii) enregistre
et évalue rapidement les données secondaires correspondantes. Dans le cas des
services web, une authentification des processus (consommateurs et fournisseur de
ces services) sur la base de certificats SSL/TLS reconnus suffit, et la protection du
trafic des données doit être exécutée grâce à une vérification du contenu des mes
sages19 ainsi qu’à une authentification et un cryptage transparents des données repo
sant sur HTTPS.
c) Un accès illimité au réseau est uniquement possible à partir d’un système informa
tique exploité par une unité organisationnelle.
18
Segmentation réseau
19
Si un cryptage de bout en bout entre le consommateur et le fournisseur du service web est nécessaire et si le
pare-feu de ce service ne peut dès lors pas vérifier directement le contenu des messages, des mesures com
plémentaires devront être mises en œuvre pour garantir cette vérification au moins indirectement.
14/17Si003 - Sécurité des réseaux dans l’administration fédérale
3
La directive de l’administration fédérale relative aux proxys web [6] s’applique aux commu
nications sortantes.
15/17Si003 - Sécurité des réseaux dans l’administration fédérale
Annexe B: Matrice d’accès domaine de réseau bleu et SSZ
Les tableaux suivants sont tirés de la version 4.0 de la matrice d'accès et s'appliquent à l'au
thentification des personnes dans le domaine de réseau bleu et la ZSS (tableau B.1), ainsi
qu'à l'authentification des systèmes et processus partenaires (tableau B.2). Les exceptions
concernant les demandes de cyberadministration du chapitre 4, chiffre 4, s'appliquent égale
ment ici.
Niveau de protection Base (NP0) 1 (NP1) 2 (NP2)
Terminal utilisateur CF CF TT TT CF CF TT TT CF CF TT TT
Méthode d’accès NW RA NW RA NW RA NW RA NW RA NW RA
Domaine de réseau bleu
Jeton Hard Crypto o o n o o o n o o o n o
OTP o o n o o o n o o o n o
OTP sans appareil n o n o n o n o n n n n
Jeton Soft Crypto n n n n n n n n n n n n
Mot de passe ou jeton NIP n n n n n n n n n n n n
Jeton Hard Crypto o20) o n o o18) o n o o18) o n o
OTP o18) o n o o18) o n o o18) o18) n o
SSZ
OTP sans appareil n o n o n o n o n n n n
Jeton Soft Crypto n o n o n o n o n n n n
Mot de passe ou jeton NIP n o n o n o n o n n n n
Tableau B.1: Authentification des personnes dans le domaine de réseau bleu ou la SSZ
Niveau de protection Base (NP0) 1 (NP1) 2 (NP2)
Méthode d’accès NW RA NW RA NW RA
Domaine de réseau
Jeton Hard Crypto n o n o n o
bleu / SSZ
OTP / OTP sans appareil Aucune application pratique
Jeton Soft Crypto n o n o n o21)
Mot de passe ou jeton NIP n o22) n n n n
Tableau B.2: Authentification des systèmes partenaires et des processus correspondants
20
La seule application est l'administration des systèmes par Admin-LAN (Management Zone FP).
21
Autorisé uniquement pour l'accès à Sedex et à d'autres applications par lesquelles seuls des messages stan
dardisés peuvent être échangés ou par lesquelles des processus définis peuvent être suivis.
22
Autorisé uniquement pour les données de télémétrie (appareils de mesure).
16/17Si003 - Sécurité des réseaux dans l’administration fédérale
17/17Vous pouvez aussi lire
