. .
[nom] À L'ADMINISTRATION SÉCURISÉE DES
SYSTÈMES D'INFORMATION
[nom]
11/05/2021 ANSSI-PA-022
PUBLIC VISÉ :
Développeur · Administrateur · RSSI · DSI · Utilisateur
.
.
. .
Informations
Attention
Ce document rédigé par l’ANSSI présente les « [nom] à l’adminis-tration sécurisée des systèmes d’information ». Il est téléchargeable sur le site [lien]
[lien].
Il constitue une production originale de l’ANSSI placée sous le régime de la « Licence Ouverte v2.0 » publiée par la mission Etalab [28].
Conformément à la Licence Ouverte v2.0, le guide peut être réutilisé librement, sous réserve de mentionner sa paternité (source et date de la dernière mise à jour). La réutilisation s’entend du droit de communiquer, diffuser, redistribuer, publier, transmettre, reproduire, copier, adapter, modifier, extraire, transformer et exploiter, y compris à des fins commer-ciales.
Sauf disposition réglementaire contraire, ces [nom] n’ont pas de caractère nor-matif ; elles sont livrées en l’état et adaptées aux menaces au jour de leur publication. Au regard de la diversité des systèmes d’information, l’ANSSI ne peut garantir que ces infor-mations puissent être reprises sans adaptation sur les systèmes d’information cibles. Dans tous les cas, la pertinence de l’implémentation des éléments proposés par l’ANSSI doit être soumise, au préalable, à la validation de l’administrateur du système et/ou des personnes en
charge . · de la sécurité des systèmes d’information.
Évolutions du document :
VERSION · DATE · NATURE DES MODIFICATIONS
1.0 · 20/02/2015 · Version initiale
2.0 · 24/04/2018 · Prise en compte des retours
d’expérience, réorganisation des chapitres & refonte graphique
3.0 · 11/05/2021 · Ajout d’un chapitre sur l’administration
par des tiers et l’assistance à distance, mises à jour détaillées en annexe A
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 1
.
Table des matières
1 Introduction · 4
1.1 Objectif du guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 4
1.2 Organisation du guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 4
1.3 Convention de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 4
2 Les administrateurs, acteurs clés de la sécurité du système d’information · 6
2.1 Les administrateurs dans l’écosystème du SI de l’entité . . . . . . . . . . . . . . . . . · 6
2.2 Droits et devoirs des administrateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 8
3 Généralités sur le système d’information d’administration · 10
3.1 Analyse de risque et objectifs de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . · 10
3.1.1 Analyse de risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 10
3.1.2 Objectifs de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 10
3.2 Zones de confiance et zones d’administration . . . . . . . . . . . . . . . . . . . . . . . · 11
3.3 Produits qualifiés par l’ANSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 12
3.4 Confiance dans le cloisonnement des environnements virtualisés . . . . . . . . . . . · 13
4 Poste d’administration · 15
4.1 Maîtrise du poste d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 15
4.2 Architecture du poste d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . · 15
4.2.1 Un poste d’administration dédié . . . . . . . . . . . . . . . . . . . . . . . . . . · 16
4.2.2 Un poste d’administration multi-niveaux . . . . . . . . . . . . . . . . . . . . . . · 16
4.2.3 Un poste d’administration avec accès distant au SI bureautique . . . . . . . . . · 17
4.3 Mesures de sécurisation du poste d’administration . . . . . . . . . . . . . . . . . . . . · 20
4.3.1 Accès à Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 20
4.3.2 Sécurisation logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 20
4.3.3 Chiffrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 22
5 Réseau d’administration · 23
5.1 Protection des ressources d’administration . . . . . . . . . . . . . . . . . . . . . . . . · 23
5.2 Accès aux ressources administrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 24
5.2.1 Sécurisation locale de l’accès aux ressources administrées . . . . . . . . . . . . · 25
5.2.2 Mise en œuvre d’une interface d’administration dédiée . . . . . . . . . . . . . · 25
5.2.3 Cas d’un réseau étendu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 27
6 Outils d’administration · 29
6.1 Cloisonnement des outils d’administration . . . . . . . . . . . . . . . . . . . . . . . . · 29
6.1.1 Outils d’administration locaux . . . . . . . . . . . . . . . . . . . . . . . . . . . · 29
6.1.2 Outils d’administration centralisés . . . . . . . . . . . . . . . . . . . . . . . . . · 29
6.2 Sécurisation des flux d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . . · 30
6.3 Rupture ou continuité des flux d’administration . . . . . . . . . . . . . . . . . . . . . · 31
7 Identification, authentification et droits d’administration · 33
7.1 Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 33
7.2 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 35
2 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
7.3 Droits d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 37
8 Maintien en condition de sécurité · 39
9 Sauvegarde, journalisation et supervision de la sécurité · 41
9.1 Sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 41
9.2 Journalisation et supervision de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . · 41
10 Administration à distance et nomadisme · 43
11 Systèmes d’échanges sécurisés · 46
11.1 Échanges au sein du SI d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . · 46
11.2 Échanges en dehors du SI d’administration . . . . . . . . . . . . . . . . . . . . . . . . · 46
12 Administration par des tiers et assistance à distance · 49
12.1 Administration par des tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 49
12.1.1 Qualification PAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 49
12.1.2 Administration ponctuelle à distance par des tiers . . . . . . . . . . . . . . . . · 50
12.2 Assistance à distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 54
12.2.1 Utilisation d’un boîtier matériel d’acquisition vidéo . . . . . . . . . . . . . . . · 55
12.2.2 Mise en œuvre d’une solution logicielle collaborative dédiée . . . . . . . . . . · 55
13 Cas particuliers d’architectures de SI d’administration · 57
13.1 Utilisation d’un bastion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 57
13.2 Possible mutualisation du poste d’administration . . . . . . . . . . . . . . . . . . . . . · 58
13.3 Une ou plusieurs solutions de poste d’administration ? . . . . . . . . . . . . . . . . . . · 59
13.4 Administration des ressources d’administration . . . . . . . . . . . . . . . . . . . . . . · 60
13.5 Administration d’un SI déconnecté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 61
13.6 Administration de ressources dans un cloud public . . . . . . . . . . . . . . . . . . . . · 62
Liste des [nom] · 63
Annexe A Évolutions du guide · 65
A.1 Nouvelles [nom] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . · 65
A.2 Mises à jour entre les versions 2.0 et 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . · 65
A.3 Matrice de rétrocompatibilité depuis la version 1.0 vers les versions ultérieures . . . · 66
Annexe B Aspects juridiques · 67
Annexe C Glossaire · 70
Bibliographie · 72
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 3
.
1
Introduction
1.1 · Objectif du guide
L’administration d’un SI se traduit par un ensemble de mesures techniques et non techniques visant entre autres à maintenir le SI en condition opérationnelle et de sécurité et à gérer des changements mineurs ou des évolutions majeures.
Ce guide décrit les objectifs de sécurité et les principes d’élaboration d’une architecture tech-nique sécurisée d’administration. Il propose des éléments utiles d’aide à la conception. Il présente quelques cas d’usages concrets mais n’a pas vocation à être exhaustif.
Ce document s’adresse à des lecteurs qui disposent de connaissances minimales pour appréhender les [nom] de sécurité présentées, capables de les adapter à leur contexte et à leurs besoins. Chacun doit s’appuyer également sur la politique de sécurité du système d’information de son entité et sur les résultats d’une analyse de risque pour déterminer les [nom] les plus pertinentes à mettre en œuvre.
1.2 · Organisation du guide
Ce guide tente d’aborder l’ensemble des thèmes liés à l’administration d’un SI et liste des [nom] dont l’implémentation peut être plus ou moins complexe suivant le contexte de l’en-tité. L’application linéaire de ce guide ne saurait être adaptée à tous les contextes.
Après une première lecture pour s’approprier les concepts, il est recommandé d’évaluer le niveau de maturité de l’entité sur le sujet de l’administration d’un SI à l’aide de la liste des [nom]
(p. 63). Pour chaque recommandation, préciser si elle est « respectée », « partiellement respectée » ou « non respectée ». Une fois synthétisée, cette analyse peut être le point de départ d’un plan d’actions visant le respect le plus exhaustif possible des [nom] du guide tout en gardant un esprit critique vis-à-vis du contexte d’application.
1.3 · Convention de lecture
Pour chacune des [nom] de ce guide, l’utilisation du verbe devoir est volontairement plus prescriptive que la formulation il est recommandé.
Pour certaines [nom] de ce guide, il est proposé, au vu des menaces constatées lors de la rédaction de ce guide, plusieurs solutions qui se distinguent par le niveau de sécurité qu’elles
4 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
permettent d’atteindre. Le lecteur a ainsi la possibilité de choisir une solution offrant la meilleure protection en fonction du contexte et de ses objectifs de sécurité.
Ainsi, les [nom] sont présentées de la manière suivante :
Recommandation à l'état de l'art
R
Cette recommandation permet de mettre en œuvre un niveau de sécurité à l’état de l’art. .
Recommandation alternative de premier niveau
R-
Cette recommandation permet de mettre en œuvre une première alternative, d’un . niveau de sécurité moindre que la recommandation R.
Recommandation alternative de second niveau
R --
Cette recommandation permet de mettre en œuvre une seconde alternative, d’un . niveau de sécurité moindre que les [nom] R et R -.
Recommandation renforcée complémentaire
R+
Cette recommandation complémentaire permet de mettre en œuvre un niveau de sécurité renforcé. Elle est destinée en priorité aux entités qui sont matures en sécurité des . systèmes d’information.
La liste récapitulative des [nom] est disponible en page 63.
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 5
.
2
Les administrateurs, acteurs clés de la sécurité du système d'information
Ce chapitre introductif, consacré au rôle d’administrateur, vise à présenter l’ensemble du lexique relatif à l’administration du SI et sert donc de référence pour l’ensemble du document. Il est égale-ment un résumé des différentes thématiques abordées.
2.1 · Les administrateurs dans l'écosystème du SI de l'entité
Un administrateur est non seulement un acteur essentiel du système d’information mais aussi un contributeur majeur pour sa sécurité. Il peut être un salarié de l’entité (on parle d’administrateur interne) ou un sous-traitant de l’entité (on parle d’administrateur externe), indépendamment du lieu d’activité. De plus, qu’il soit administrateur technique (réseau, système) ou administrateur métier, les besoins d’accès et de privilèges ne sont généralement pas uniformes ; les administrateurs peuvent être regroupés par catégories.
Un administrateur est une ressource critique investie de capacités techniques d’accès aux informa-tions métier de l’entité. En effet, il se distingue des autres utilisateurs par les privilèges qui lui sont accordés sur le système d’information. Il dispose de droits d’administration nécessaires à la bonne réalisation d’actions d’administration.
Actions d'administration
Ensemble des actions d’installation, de suppression, de modification et de consulta-tion de la configuration d’un système participant au SI et susceptibles de modifier le
fonctionnement . · ou la sécurité de celui-ci.
Il est nécessaire de dissocier clairement les différents rôles d’un administrateur sur le SI : un rôle d’utilisateur standard du SI sans privilèges particuliers et un ou plusieurs rôles d’administrateur.
Cela se traduit entre autres par la création d’un compte utilisateur standard pour utiliser le SI hors administration et d’un ou plusieurs comptes d’administration dédiés aux actions d’administration.
L’identification et l’authentification des administrateurs sont les sujets du chapitre 7.
Un poste utilisé pour les actions d’administration, dénommé poste d’administration, est un terminal matériel ; il peut être fixe ou portable suivant les besoins. Il est l’objet du chapitre 4.
Un administrateur réalise ses actions grâces à des outils d’administration, généralement logiciels, mis à sa disposition sur un poste d’administration ou sur des serveurs dédiés. Un client SSH, une
6 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
console centralisée de gestion d’annuaire, un portail Web d’administration de pare-feu sont des exemples d’outils d’administration. Le chapitre 6 aborde ce sujet.
En cas d’accès distant d’un administrateur (ex. : astreinte à domicile, déplacement), on parle d’admi-nistration à distance dans le chapitre 10. Le cas particulier de l’administration ou l’assistance à distance par des tiers est abordé dans le chapitre 12.
Partie intégrante du SI de l’entité au sens large, le système d’information d’administration est le sujet de ce guide. Il inclut toutes les ressources d’administration nécessaires pour administrer le SI considéré dont les postes d’administration, les serveurs d’outils d’administration et les infrastructures d’administration nécessaires à son bon fonctionnement (serveurs d’annuaire, DNS, etc.).
Ces ressources sont connectées sur un réseau d’administration, réseau de communication faisant transiter les flux internes au SI d’administration et les flux d’administration à destination des res-sources administrées. Ce réseau est évoqué dans le chapitre 5.
La figure 2.1, à titre d’exemple, est un résumé sous forme de représentation fonctionnelle.
Fichiers
Administrateurs
Annuaire · Certificats
Infrastuctures
d’administration
Postes utilisateurs · Serveurs de production
Postes
d’administration
Concentrateur VPN · Réseau de production
Pare-feu
Ressources administrées
Commutateur · Routeur
Réseau
d’administration
Outils
d’administration
SI d’administration
F 2.1 – Représentation fonctionnelle d’un SI d’administration et de ressources administrées
En périphérie du SI d’administration, un système d’échange sécurisé, illustré par la figure 2.2 et présenté dans le chapitre 11, peut être positionné pour des échanges avec d’autres SI (ex. : un SI bureautique connecté à Internet).
Système d’échange
SI bureautique · sécurisé · SI d’administration
Internet
Analyse de codes · Serveur
malveillants · de fichiers
F 2.2 – Représentation fonctionnelle d’un système d’échange sécurisé
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 7
.
2.2 · Droits et devoirs des administrateurs
Les fonctions d’administrateur, complexes, doivent s’équilibrer entre un grand pouvoir impliquant de grandes responsabilités et le respect d’obligations précises. En particulier, un administrateur d’un système d’information est tenu à des obligations de loyauté (respect des règles d’éthique), de transparence (respect du règlement intérieur et de la charte informatique) et de confidentialité 1
(respect du secret professionnel). Le non-respect de ces obligations peut donner lieu à des sanc-tions disciplinaires (allant jusqu’au licenciement pour faute grave), voire des sanctions pénales.
L’annexe B traite plus en détail les aspects juridiques, notamment les différents droits et devoirs des administrateurs.
En premier lieu, les droits et obligations des salariés, dont font partie les administrateurs, pour l’utilisation des moyens informatiques doivent être consignés dans une charte informatique an-nexée au règlement intérieur ou au contrat de travail. L’entité peut prévoir en complément une charte informatique spécifique applicable aux administrateurs. Cette charte doit notamment ap-peler les administrateurs à la vigilance vis-à-vis des ressources d’administration mises à leur dis-position et sur les conduites à tenir en cas de compromission avérée ou suspectée, de perte ou de vol. Pour toute question relative à la sécurité des systèmes d’information (SSI), un administrateur doit pouvoir s’adresser à des référents internes de l’entité, clairement identifiés, techniques ou non techniques.
Informer les administrateurs de leurs droits et devoirs
R1
Un administrateur doit être informé de ses droits et devoirs, notamment en s’ap-puyant sur la charte informatique de l’entité.
Il est recommandé d’élaborer une charte informatique spécifique applicable aux administrateurs. .
Le rôle d’administrateur nécessite non seulement une confiance forte de l’entité au regard de la criticité de ses actions sur le SI mais également des compétences techniques élevées. Les formations initiale et continue des administrateurs sont indispensables pour garantir la maîtrise de toutes les compétences requises par l’exercice de leurs fonctions.
Former les administrateurs à l'état de l'art en matière de SSI
R2
En tant que ressource humaine critique pour le SI, un administrateur doit être formé à l’état de l’art, dans ses domaines de compétences et en sécurité des systèmes d’in-formation (ex. : sécurité des systèmes, sécurité des réseaux, infrastructure de gestion de clés).
Le . guide d’hygiène informatique de l’ANSSI [13] doit être connu.
Quels que soient l’organisation de l’entité et le partage des responsabilités (entre architectes et administrateurs par exemple), il est essentiel de concevoir et de maintenir à jour la documenta-tion des SI : schémas d’architecture, plans d’adressage IP, matrices de flux, inventaire des comptes privilégiés, etc.
- Se reporter au guide pour les employeurs et les salariés élaboré par la CNIL [1] dont notamment la fiche n°7 pour les adminis- trateurs.
8 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
Disposer d'une documentation des SI à jour
R3
Les administrateurs doivent disposer de documents reflétant fidèlement l’état courant des SI qu’ils administrent, notamment des cartographies du SI (physique, système, réseau, applications) faisant notamment apparaître clairement les intercon-
nexions . · avec l’extérieur.
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 9
.
3
Généralités sur le système d'information d'administration
3.1 · Analyse de risque et objectifs de sécurité
Les ressources d’administration sont des cibles privilégiées par un attaquant. En effet, les droits élevés nécessaires à la réalisation des actions d’administration et les larges accès généralement attribués exposent ces ressources à une menace élevée. Dans de nombreux cas de compromission ou d’intrusion sur ces équipements, l’attaquant prend le contrôle de l’ensemble du SI.
3.1.1 · Analyse de risque
Ce guide n’a pas vocation à établir une analyse de risque exhaustive ; ce travail essentiel, propre à chaque système d’information, incombe aux entités en ayant la responsabilité, en liaison avec les responsables de la sécurité des systèmes d’information (RSSI). L’analyse de risque peut être menée avec la méthode EBIOS Risk Manager [18] par exemple.
Ainsi, les architectures du SI d’administration peuvent varier en fonction de la criticité du SI ad-ministré ou des usages par différentes populations d’administrateurs, chacun ne relevant pas du même niveau de confiance, par exemple entre administrateurs internes et externes.
Mener une analyse de risque sur le SI d'administration et son écosystème
R4
Avant toute étude des mesures techniques à mettre en œuvre, une analyse de risque doit être menée en portant une attention particulière sur les besoins de sécurité du SI d’administration et ses interconnexions.
Dans une démarche d’amélioration continue, il est recommandé que l’analyse de risque et la mise en œuvre des mesures induites soient revues au moins une fois par an. .
3.1.2 · Objectifs de sécurité
Le premier objectif de sécurité des [nom] de ce guide est de protéger le SI d’administra-tion de toute tentative de compromission. En effet, le scénario de compromission le plus fréquent est l’exécution d’un code malveillant sur le poste d’administration – ou sur un poste sur lequel un administrateur s’est connecté avec ses privilèges d’administrateur. Ce code malveillant peut être introduit par le biais d’une navigation Web, par l’ouverture d’une pièce jointe dans un courriel piégé ou à partir d’un support amovible.
10 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
Scénario d'attaque
Un code malveillant peut profiter par exemple des privilèges élevés de la session d’un administrateur pour exécuter des actions telles que :
n le vol des empreintes de mots de passe sur le poste, par exemple par une copie mémoire (ex. : attaque Pass The Hash qui permet la réutilisation de ces empreintes pour accéder, sans connaître le mot de passe et donc sans devoir le recouvrer, aux ressources du système d’information) ;
n l’installation d’un logiciel espion (ex. : cheval de Troie, enregistreur de frappes clavier – keylogger) ;
n l’accès à un serveur de commande et de contrôle 2 ;
. n la diffusion d’un ver informatique.
Le deuxième objectif de sécurité est de protéger le SI administré des intrusions et compromis-sions pour lesquelles le SI d’administration serait un vecteur d’attaque. Dans ce cas, on cherche à minimiser les conséquences sur le SI administré d’une compromission du SI d’administration.
Du fait des privilèges élevés du SI d’administration sur le SI administré, une action malveillante reste possible mais un cloisonnement adéquat du SI d’administration doit permettre d’éviter une compromission totale du SI administré.
3.2 Zones de confiance et zones d'administration
Pour réduire la surface d’exposition aux attaques informatiques et les conséquences en cas de com-promission, il est nécessaire de procéder à un découpage du SI administré en zones homogènes dites zones de confiance puis d’en déduire des zones d’administration au sein du SI d’administration.
Zone de confiance
Une zone de confiance comprend exclusivement des ressources homogènes ; elle est
administrée . · par des administrateurs de même niveau de confiance.
Le découpage du SI administré en zones de confiance peut être déterminé par la combinaison de plusieurs critères d’homogénéité, parmi lesquels :
n de criticité métier (ex. : haute, moyenne, basse) ;
n organisationnels (ex. : administration interne ou infogérée) ;
n d’exposition (ex. : à Internet, à des fournisseurs, exclusivement interne) ;
n réglementaires (ex. : données de santé, données personnelles, données relevant du secret de la défense nationale) ;
n géographiques (ex. : découpage par pays).
Par défaut, à une zone de confiance correspond une zone d’administration. Les cas de mutualisation sont évoqués dans la section 13.2.
- Un serveur de commande et de contrôle (C&C) est un ordinateur qui donne des ordres aux équipements infectés par un logiciel malveillant et qui reçoit des informations de ces équipements.
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 11
.
Ce découpage du SI administré (et les conséquences sur le SI d’administration pour la définition des zones d’administration) doit être mené aussi bien en phase de conception initiale qu’avant toute évolution significative du SI administré. Il permet en effet d’alimenter les travaux d’architecture afin que soit traité dans la continuité l’ensemble des besoins d’administration.
Des mécanismes techniques de cloisonnement sont alors mis en œuvre pour matérialiser les zones d’administration : filtrage, chiffrement, authentification, etc. Ainsi, en respectant le principe du moindre privilège, un administrateur donné n’a accès qu’à la ou les zones d’administration dont il a le juste besoin opérationnel, sans possibilité technique d’accéder à une autre zone.
Définir les zones de confiance du SI administré et déduire les zones
R5 · d'administration
Avant toute étude d’architecture du SI d’administration, un découpage du SI admi-nistré en zones de confiance doit être réalisé. Ce travail permet de déduire un dé-
coupage . · du SI d’administration en zones d’administration.
3.3 · Produits qualifiés par l'ANSSI
La qualification [27] prononcée par l’ANSSI permet d’attester d’un certain niveau de sécurité et de confiance dans les produits 3 et les prestataires de service. Ce processus permet de s’assurer notamment que des produits remplissent les objectifs de sécurité définis dans des cibles de sécurité préalablement approuvées.
Il est recommandé de recourir à des produits qualifiés pour la protection du SI d’administration même si l’entité n’est soumis à aucun texte réglementaire. Une attention particulière sera portée sur la cible de sécurité qui précise le périmètre qualifié du produit (ex. : le filtrage dynamique des flux IP aux niveaux 3 et 4 pour un pare-feu) ainsi que les hypothèses d’environnement.
Privilégier l'utilisation de produits qualifiés par l'ANSSI
R6
D’une manière générale, il est recommandé que les matériels et les logiciels utilisés pour protéger le SI d’administration soient qualifiés par l’ANSSI au niveau requis par les besoins de sécurité.
À défaut, il est recommandé qu’ils disposent d’un autre visa de sécurité délivré par
l’ANSSI . · 4 .
Attention
Il est recommandé d’être toujours attentif aux versions de matériel ou logiciel
. auxquelles ils s’appliquent ainsi qu’à la définition de la cible de sécurité.
- La qualification des produits par l’ANSSI comporte trois niveaux : élémentaire, standard et renforcé.
- Se reporter à [lien]
12 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
3.4 Confiance dans le cloisonnement des environnements virtualisés
L’emploi des technologies de virtualisation est désormais courant afin de mutualiser les ressources, simplifier les tâches d’exploitation et réduire les coûts. Toutefois, la confiance dans une solution de virtualisation dépend essentiellement de la confiance accordée aux mécanismes de cloisonnement permettant la cohabitation de plusieurs environnements d’exécution sur un même socle physique.
Du point de vue de la sécurité, ces mécanismes doivent garantir une étanchéité équivalente à celle d’environnements physiquement distincts.
En pratique, le processus de qualification évoqué dans la section 3.3 est difficilement applicable aux technologies de virtualisation au vu de la complexité de la conception et des développements ainsi que des multiples cas d’intégration.
En conséquence, le principe de précaution doit prévaloir : par défaut, on considère donc que le cloisonnement entre deux environnements virtualisés, hébergés sur un même socle physique, ne garantit pas un niveau de confiance suffisant du point de vue de la sécurité. Ce constat s’applique à tout type de ressource virtualisable, non seulement les serveurs et les ressources de stockage mais également les équipements réseau (routeurs, commutateurs, etc.), les équipements de sécurité
(pare-feux, concentrateurs VPN, etc.) ou autres.
Dès lors, la virtualisation sur un même socle physique ne peut être utilisée que pour faire cohabiter des instances d’une même zone de confiance, ayant entre autres :
n les mêmes besoins de sécurité (confidentialité, intégrité, disponibilité) ;
n le même niveau d’exposition, c’est-à-dire accessibles depuis des zones et par des personnes d’un niveau de confiance et de privilège homogène.
Dans le cas présent, le principe de précaution consiste donc à dédier des socles physiques de virtu-alisation pour l’administration de SI.
À titre d’exemple, un serveur outils et un serveur de fichiers du SI d’administration, s’ils sont virtu-alisés, peuvent être hébergés sur un même socle physique sous réserve que celui-ci leur soit dédié et qu’il soit par exemple différent de celui utilisé pour des applications métier (cf. figure 3.1).
Dans un autre domaine technique, des équipements virtualisés de routage et de filtrage pour les flux internes au SI d’administration ne doivent pas non plus être mutualisés sur le même socle physique que des équipements virtualisés permettant l’accès aux services de production. De plus, la virtualisation des équipements de sécurité sur des hyperviseurs n’est pas à privilégier dans une infrastructure physique (cf. les raisons techniques dans l’annexe du guide [19]).
Dédier des socles physiques en cas de virtualisation des infrastructures
R7 · d'administration
En cas de virtualisation d’infrastructures d’administration, les instances virtuelles correspondantes doivent être déployées sur des socles physiques dédiés, non mu-
tualisés . · avec d’autres infrastructures virtualisées.
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 13
.
PRODUCTION · PRODUCTION · ADMINISTRATION ADMINISTRATION · PRODUCTION · PRODUCTION · ADMINISTRATION · ADMINISTRATION
Fichiers · Base de données · Fichiers · Outils · Fichiers · Base de données · Fichiers · Outils
Socle physique mutualisé · Socle physique PROD · Socle physique ADMIN
F 3.1 – Cloisonnement des socles physiques de virtualisation pour des serveurs
Attention
De manière générale, les produits de virtualisation, complexes, nécessitent une par-faite maîtrise pour garantir un usage sécurisé : configuration du réseau interne, con-naissance des flux d’information entre les machines virtuelles, mise en place ciblée
. de chiffrement authentifié, etc.
14 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
4
Poste d'administration
4.1 Maîtrise du poste d'administration
En tant que point d’entrée du SI d’administration, le poste de travail de l’administrateur est un com-posant critique par nature car il dispose d’accès étendus et privilégiés. En outre, il traite générale-ment des informations sensibles pour le système d’information (configurations, dossiers d’archi-tecture, versions logicielles déployées, mots de passe, etc.) et a la capacité technique d’accéder à des informations métier. Il doit donc faire l’objet d’une sécurisation physique et logicielle afin de restreindre au mieux les risques de compromission.
En premier lieu, il est indispensable que l’entité garde la maîtrise du poste d’administration qu’elle met à disposition des administrateurs, que ceux-ci soient internes ou externes. Toute pratique de type « Bring Your Own Device » (BYOD 5 ), non recommandée de manière générale, est à proscrire pour un poste d’administration.
Gérer et configurer le poste d'administration
R8
Le poste d’administration doit être géré par l’entité – ou à défaut un prestataire man-daté. En aucun cas l’utilisation d’un équipement personnel ne doit être tolérée pour
l’administration . · d’un SI.
Attention
S’agissant du risque de piégeage matériel, au-delà de maîtriser le processus d’appro-visionnement et notamment ses conditions de sécurité, il convient de sensibiliser les . administrateurs à la protection physique de leur poste d’administration.
4.2 Architecture du poste d'administration
Pour répondre à la dualité des besoins des administrateurs (réalisation des actions d’administration depuis un environnement sécurisé d’une part et accès à un SI bureautique 6 en tant qu’utilisateur d’autre part), trois solutions d’architecture sont envisageables. Elles sont présentées par niveau de sécurité décroissant au regard des objectifs de sécurité fixés :
n un poste d’administration dédié ;
n un poste d’administration multi-niveaux ;
n un poste d’administration avec accès distant à un SI bureautique.
- Terme français équivalent : AVEC – Apportez votre équipement personnel de communication.
- On convient de parler de SI bureautique au sens large, c’est-à-dire tout ce qui n’est pas le SI d’administration.
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 15
.
4.2.1 · Un poste d'administration dédié
La solution qui offre la meilleure garantie du point de vue sécurité consiste à utiliser deux postes physiquement distincts (cf. figure 4.1), respectivement pour les actions d’administration et pour les autres usages (ex. : accès aux services bureautiques, accès à Internet).
Utiliser un poste d'administration dédié
R9
La principale mesure de sécurité consiste à dédier un poste de travail physique aux actions d’administration. Ce poste doit être distinct du poste permettant d’accéder aux ressources conventionnelles accessibles sur le SI de l’entité (ressources métier,
messagerie . · interne, gestion documentaire, Internet, etc.).
Internet
SI · SI
bureautique · d’administration
F 4.1 – Poste d’administration dédié
4.2.2 · Un poste d'administration multi-niveaux
Le principe d’un poste multi-niveaux consiste à disposer de plusieurs environnements logiciels
(généralement deux) sur un même poste physique grâce à l’emploi des technologies de virtualisa-tion ou de conteneurisation. CLIP OS est un exemple de système multi-niveaux open source.
Des mécanismes de durcissement du noyau et de cloisonnement permettent d’isoler ces environ-nements pour réduire les risques de compromission du niveau de sensibilité haute ou de fuite d’information depuis le niveau de sensibilité haute (ici, le SI d’administration) vers le niveau de sensibilité basse (ici, le SI bureautique).
Cette solution (cf. figure 4.2) offre un niveau de sécurité moindre qu’une séparation physique. Dans ce cas exclusif du poste d’administration dérogeant à R7, elle doit impérativement faire l’objet d’une évaluation de confiance des mécanismes d’isolation et de cloisonnement. En effet, l’emploi de cette solution, si elle n’est pas de confiance, peut donner un faux sentiment de sécurité. Il est par ailleurs préférable que ces mécanismes soient gérés au niveau du système, et non par une application utilisateur (cf. figures 4.3 et 4.4).
Utiliser un poste d'administration multi-niveaux
R9 -
À défaut d’un poste d’administration physiquement dédié, l’emploi de technologies de virtualisation ou de conteneurisation pour obtenir un système multi-niveaux peut être envisagé, dans la mesure où le cloisonnement des environnements est réalisé par . des mécanismes évalués comme étant de confiance au niveau système.
16 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
Internet · noyau durci et évalué
SI · SI
bureautique · d’administration
F 4.2 – Poste d’administration multi-niveaux
machine virtuelle
machine hôte
noyau
Internet
SI · SI
bureautique · d’administration
F 4.3 – Poste d’administration hébergeant une machine virtuelle bureautique
machine virtuelle
machine hôte
noyau
Internet
SI · SI
bureautique · d’administration
F 4.4 – Poste bureautique hébergeant une machine virtuelle d’administration
4.2.3 Un poste d'administration avec accès distant au SI bureautique
Une dernière solution, d’un niveau de sécurité moindre, consiste en l’emploi au quotidien d’un poste d’administration physique permettant un accès au SI bureautique par connexion à distance
(cf. figure 4.5).
Dans cette architecture, la surface d’attaque du SI d’administration est en effet augmentée par l’utilisation d’un client de connexion à distance exécuté sur le poste d’administration. En cas de
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 17
.
compromission du serveur de connexion à distance situé dans le SI bureautique, un attaquant pourrait alors remonter le canal de communication établi pour compromettre le poste d’adminis-tration.
Cette pratique nécessite dans tous les cas une maîtrise plus forte de l’interconnexion entre les deux
SI.
Attention
Il est à noter que la solution inverse, qui consiste à accéder depuis un poste bureau-tique à un poste d’administration par connexion à distance, est à proscrire (cf. fi-gure 4.6).
En effet, le poste bureautique ayant potentiellement accès à Internet, sa compromis-sion pourrait permettre à un attaquant d’espionner les actions effectuées depuis le poste (frappes clavier, copies d’écran), en particulier les connexions initiées vers le poste d’administration (ex. : adresse IP, mot de passe).
Un attaquant pourrait alors rejouer ces connexions et, par rebond, accéder aux outils
. d’administration puis au SI administré.
De plus, l’utilisation d’un logiciel de connexion à distance nécessite des précautions de configura-tion qui visent à restreindre les fonctions d’échange entre le système local (administration) et le système distant (bureautique). Faute d’évaluation à la date de rédaction de ce document, les mé-canismes d’échange des logiciels de connexion à distance ne peuvent pas être, a priori, considérés comme étant de confiance.
De manière non exhaustive, les fonctions d’échange d’informations à désactiver sont :
n les fonctions avancées de copier/coller (en complément de l’activation d’un contrôle sur le vo-lume ou le format) ;
n le partage d’écran ;
n la fonction de prise en charge des périphériques (USB, imprimantes, etc.) ;
n les partages réseaux.
Dès lors, la mise en place d’un système d’échange sécurisé, détaillé dans le chapitre 11, peut être nécessaire.
Dans ce cas dérogatoire d’architecture, il est impératif que :
n un filtrage des flux de connexion à distance vers le réseau bureautique soit effectué par un pare-feu ;
n l’authentification sur le poste d’administration soit réalisée en utilisant l’annuaire du SI d’ad-ministration ;
n l’authentification sur l’environnement bureautique soit réalisée en utilisant l’annuaire du SI bureautique.
18 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
Utiliser un poste d'administration avec accès distant au SI bureautique
R9 - -
À défaut d’un poste d’administration physiquement distinct du poste bureautique ou d’un système multi-niveaux de confiance, une solution d’un niveau de sécurité moindre peut consister à ce que les administrateurs :
n utilisent un poste physique pour les actions d’administration ;
n accèdent, par connexion à distance uniquement, à leur environnement bureau-tique (physique ou virtuel, par exemple : Virtual Desktop Infrastructure) depuis ce poste d’administration.
Dans ce cas, les fonctions permettant un échange d’informations entre les deux en-
vironnements . · doivent être désactivées.
Attention
Il est à noter que cette solution est déconseillée pour l’administration d’infrastruc-tures critiques (ex. : hyperviseurs, annuaires).
Par ailleurs, pour être en mesure de réagir dans les meilleurs délais en cas de crise, il est recommandé de disposer d’une procédure pour désactiver l’accès distant au SI
. bureautique depuis les postes d’administration.
Internet
accès
distant
SI · SI
bureautique · d’administration
F 4.5 – Poste d’administration physique avec accès distant à un environnement bureautique virtualisé
Internet
accès
distant
SI · SI
bureautique · d’administration
F 4.6 – Poste bureautique physique avec accès distant à un environnement d’administration virtualisé
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 19
.
Information
En complément de la présentation de ces trois solutions d’architecture du poste d’ad-
ministration, . · la section 13.3 aborde la cohabitation de plusieurs solutions.
4.3 · Mesures de sécurisation du poste d'administration
Information
Toutes les [nom] suivantes s’appliquent quelle que soit la solution d’ar-
chitecture . · choisie précédemment pour le poste d’administration.
4.3.1 · Accès à Internet
L’accès à Internet augmente significativement la surface d’exposition aux attaques informatiques et favorise un grand nombre de vecteurs d’attaque : navigation Web, courriel, ouverture de fichiers ou exécution de programmes téléchargés, etc. Ainsi, il est très difficile de garantir l’intégrité d’un poste ayant accès à Internet.
Bloquer tout accès à Internet depuis ou vers le poste d'administration
R10
Le poste d’administration ne doit en aucun cas avoir accès à Internet.
Cette recommandation inclut en particulier la navigation Web et l’usage de mes-sageries électroniques connectées à Internet, même si ces services sont filtrés par des
passerelles . · sécurisées d’accès Internet.
Par conséquent, l’accès à Internet et aux comptes de messagerie électronique ne peut être au-torisé qu’à partir des environnements bureautiques, eux-mêmes soumis à un filtrage au travers des passerelles d’accès Internet de l’entité.
S’agissant de la récupération sur Internet des mises à jour de sécurité du poste, la mise en œuvre de serveurs relais est détaillée dans le chapitre 8. Les autres échanges depuis ou vers Internet sont traités dans le chapitre 11 sur les systèmes d’échange.
4.3.2 · Sécurisation logicielle
Pour réduire les risques de compromission du poste d’administration, la maîtrise et le durcissement de son socle logiciel et de sa configuration sont impératifs.
Des actions de configuration doivent être menées pour la sécurité du système d’exploitation. Pour cela, il est recommandé de se référer aux guides de sécurité proposés par les éditeurs. Ces derniers décrivent des configurations adaptées à leurs solutions et constituent une première étape dans la sécurisation du socle. L’ANSSI publie également des guides à cet effet, par exemple sur Linux [5], Applocker [10] ou Windows 10 [9] [8].
20 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
Durcir le système d'exploitation du poste d'administration
R11
Les guides de sécurisation des socles des éditeurs doivent être appliqués. Au mini-mum, les points suivants doivent être traités :
n la désactivation des services inutiles ;
n l’application de droits restreints au juste besoin opérationnel ;
n l’activation et la configuration du pare-feu local pour interdire toute connexion entrante et limiter les flux sortants au juste besoin ;
n le durcissement des configurations systèmes (par exemple pour Windows : GPO, Applocker, SRP ou, pour Linux : SELinux, AppArmor, durcissement du noyau) ;
n l’activation de l’ensemble des mécanismes de mise à jour dans le respect des
. · [nom] du chapitre 8 dédié au maintien en condition de sécurité.
Les administrateurs ne doivent pas pouvoir modifier la configuration du poste d’administration.
Pour cela, ils ne doivent pas être intégrés au groupe local « administrateurs » du poste. La majeure partie des actions d’administration est généralement réalisée à partir des navigateurs Web, d’outils de type clients lourds ou en ligne de commande (ex. : ssh) et ne nécessite donc pas de privilèges particuliers sur le poste.
Cette mesure remplit un double objectif : prévenir une erreur humaine qui entraînerait un abaisse-ment du niveau de sécurité du poste et limiter les conséquences de l’exécution d’un code malveil-lant.
Restreindre les droits d'administration sur le poste d'administration
R12
Par défaut, les administrateurs ne doivent pas disposer des droits d’administration sur leur poste d’administration. Ces droits doivent être attribués uniquement aux
administrateurs . · en charge de l’administration des postes d’administration.
De façon à restreindre significativement la surface d’exposition du système, il convient d’utiliser uniquement des logiciels – ainsi que leurs mises à jour – préalablement validés suivant un pro-cessus de contrôle défini. Pour cela, des vérifications cumulables sur les fichiers binaires ou de configuration à installer peuvent être :
n techniques : analyse antivirale, analyse en bac à sable, vérification de signature électronique, traçabilité à l’aide d’un condensat (hash), etc. ;
n organisationnelles : contrôle de la source de téléchargement, de l’émetteur, etc.
La mise à disposition des outils auprès des administrateurs pourra être effectuée à l’aide d’outils de « télédistribution » (ou « télédéploiement »), d’un site Web ou via un partage réseau dédié, ceux-ci étant accessibles uniquement sur le SI d’administration.
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 21
.
Limiter les logiciels installés sur le poste d'administration
R13
Il est recommandé de n’installer sur le poste d’administration que les logiciels et les outils utiles aux actions d’administration. Pour ce faire, il est nécessaire :
n de dresser et maintenir la liste des outils d’administration utiles ;
n de mettre en œuvre un processus de validation et de distribution des outils d’ad-
. · ministration suivant des critères techniques et organisationnels.
4.3.3 · Chiffrement
Le disque dur du poste d’administration peut contenir des données sensibles, utiles à l’accès au système d’information. La perte ou le vol du poste est préjudiciable car pouvant mener à une compromission de ces données.
Chiffrer l'ensemble des périphériques de stockage utilisés pour l'adminis-
R14 · tration
Il est recommandé de procéder au chiffrement complet de l’ensemble des pé-riphériques de stockage (disques durs, périphériques de stockage amovibles, etc.)
. utilisés pour les actions d’administration.
Attention
Les ordinateurs portables sont en particulier plus exposés aux risques de perte ou de vol. Dans le cadre du nomadisme (cf. chapitre 10), cette recommandation revêt un . caractère indispensable.
Les dispositifs de chiffrement utilisés doivent garantir un certain niveau de robustesse et être adap-tés à la sensibilité des données à protéger. De tels dispositifs sont au catalogue des produits qualifiés par l’ANSSI.
De plus, l’utilisation du chiffrement implique la mise au point d’un processus lié au cycle de vie des secrets (ex. : initialisation, stockage, récupération en cas de perte).
22 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
5
Réseau d'administration
Le réseau d’administration se définit comme le réseau de communication sur lequel transitent les flux internes au SI d’administration et les flux d’administration à destination des ressources admi-nistrées. Ce réseau doit faire l’objet de mesures de sécurisation spécifiques en phase avec l’analyse de risque et les objectifs de sécurité décrits dans la section 3.1.
5.1 Protection des ressources d'administration
À l’instar de [nom] les postes d’administration, la mise en œuvre d’un réseau d’administration physiquement dédié aux ressources d’administration offre un niveau de sécurité maximal pour se prémunir d’une compromission du SI d’administration et garantir un cloison-nement fort avec tout autre réseau potentiellement connecté à Internet.
Pour éviter le branchement d’équipements indésirables sur ce réseau d’administration dédié (ex. :
postes bureautiques, postes personnels), une authentification réseau est recommandée en complé-ment, par exemple par l’implémentation du protocole 802.1X en suivant les [nom] du guide de l’ANSSI [11].
Connecter les ressources d'administration sur un réseau physique dédié
R15
Les ressources d’administration (ex. : postes d’administration, serveurs outils) doivent être déployées sur un réseau physiquement dédié à cet usage.
Le cas échéant, il est recommandé que les postes d’administration s’authentifient
pour . · accéder au réseau d’administration.
Si l’application stricte de cette recommandation est techniquement impossible (ex. : sur un réseau étendu) ou disproportionnée par rapport aux besoins de sécurité, une alternative d’un niveau de sécurité moindre peut être envisagée sur la base d’un réseau logique dédié.
Connecter les ressources d'administration sur un réseau VPN IPsec dédié
R15 -
À défaut d’un réseau physique dédié, les ressources d’administration doivent être déployées sur un réseau logique dédié à cet usage en mettant en œuvre des méca-nismes de chiffrement et d’authentification de réseau, à savoir le protocole IPsec. En complément, des mécanismes de segmentation logique (VLAN) et de filtrage réseau sont recommandés pour limiter l’exposition du concentrateur VPN IPsec aux seuls postes d’administration.
Pour la mise en œuvre du protocole IPsec, les [nom] du guide de
l’ANSSI . · [16] doivent être appliquées.
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 23
.
Un regroupement des ressources d’administration par zone de confiance permet de mettre en place un cloisonnement pertinent et les mesures de filtrage réseau idoines au sein du SI d’administra-tion. En outre, afin de garantir le cloisonnement du SI d’administration vis-à-vis de l’extérieur, un filtrage périmétrique doit également être assuré. Dans le cadre du maintien en condition de sécu-rité, celui-ci doit faire l’objet d’une procédure régulière de révision. De cette façon, les règles de filtrage obsolètes, inutiles ou trop permissives sont supprimées ou, à défaut, désactivées.
Appliquer un filtrage interne et périmétrique au SI d'administration
R16
Quelle que soit la solution de réseau retenue, un filtrage réseau entre zones de con-fiance doit être mis en œuvre au sein du SI d’administration. Par ailleurs, toutes les interconnexions avec le SI d’administration doivent être identifiées et filtrées. Une matrice de flux, limitée au juste besoin opérationnel, doit être élaborée et revue
. régulièrement afin d’assurer la traçabilité et le suivi des règles de filtrage.
Information
L’ANSSI publie des [nom] pour la définition d’une politique de filtrage
réseau . · d’un pare-feu [15] et pour son nettoyage [17].
La figure 5.1 illustre les [nom] R16 et R15 (schéma de gauche), R16 et R15- (schéma de droite). L’illustration de R15-, à droite, ne représente que des postes d’administration connectés en VPN IPsec (cas classique de déploiement d’un client VPN). Cependant il est tout à fait envisageable de connecter d’autres ressources d’administration de la même manière.
Concentrateur VPN
Postes · Tunnel
Postes · IPsec
d’administration · d’administration
Lien physique · Lien physique
Infrastructures · Infrastructures
d’administration · d’administration
Filtrage · Filtrage
Outils · Outils
SI · d’administration · SI · d’administration
d’administration · d’administration
F 5.1 – Réseaux d’administration avec fonction de filtrage
5.2 · Accès aux ressources administrées
L’accès aux ressources administrées doit être maîtrisé, non seulement au niveau local grâce à des configurations applicatives sur ces ressources, mais aussi au niveau réseau par des mesures com-plémentaires de blocage ou de filtrage réseau dans une démarche de défense en profondeur.
24 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
5.2.1 Sécurisation locale de l'accès aux ressources administrées
Afin de filtrer au plus près l’accès à une ressource administrée, il est recommandé de mettre en œuvre un filtrage local, par exemple à l’aide d’un pare-feu applicatif avec une matrice des flux limitée au strict besoin opérationnel. En particulier, seules des ressources d’administration iden-tifiées peuvent accéder aux services d’administration. Par exemple, le service de production d’un serveur Web est accessible sur le port TCP/443 (HTTPS) par l’ensemble de ses clients légitimes et son service d’administration est accessible sur le port TCP/22 (SSH) par les ressources d’adminis-tration identifiées pour ce besoin.
Appliquer un filtrage local sur les ressources administrées
R17
Pour maîtriser les accès au plus près des ressources administrées, il est recommandé
. de leur appliquer un filtrage local correspondant au juste besoin opérationnel.
Information
Certains systèmes, par exemple des systèmes de gestion de contenu ou le service
Active Directory de Microso, ne distinguent pas le port d’écoute des services de production et d’administration (même port TCP). Dans ce cas de figure, l’application de R17 est toujours nécessaire mais non suffisante. La sécurité de l’administration au niveau de la ressource administrée repose de façon ultime sur la configuration applicative du service (ex : contrôle d’accès, gestion des droits) et sa robustesse ; cela
doit . · être traité avec attention mais n’est pas l’objet de ce guide.
5.2.2 Mise en œuvre d'une interface d'administration dédiée
Dès lors qu’elle est techniquement réalisable au niveau d’une ressource administrée, la sépara-tion des interfaces de production et d’administration est recommandée. Cette mesure garantit non seulement un filtrage local plus spécifique (ex. : un service d’administration n’est autorisé que sur l’interface d’administration) mais aussi une disponibilité accrue de la ressource administrée en cas de déni de service sur l’interface de production.
Une séparation en interfaces réseau physiques offre un niveau de sécurité maximal et permet ainsi de dissocier les équipements de filtrage réseau respectivement sur les réseaux de production et d’administration. À défaut, une séparation en interfaces réseau virtuelles est recommandée.
Si cette séparation n’est techniquement pas réalisable sur un système, alors l’application des mesures locales, dont la recommandation R17, doit être d’autant plus stricte.
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 25
.
Dédier une interface réseau physique d'administration
R18
Il est recommandé de dédier une interface réseau physique d’administration sur les ressources administrées en s’assurant des pré-requis suivants :
n les services logiques permettant l’exécution des actions d’administration doivent être en écoute uniquement sur l’interface réseau d’administration prévue à cet effet ;
n les fonctions internes du système d’exploitation ne doivent pas permettre le routage d’informations entre les interfaces réseau de production et l’interface réseau d’administration d’une même ressource. Elles doivent être désactivées (ex. :
. · désactivation d’IPForwarding).
Dédier une interface réseau virtuelle d'administration
R18 -
À défaut d’une interface réseau physique d’administration, il est recommandé de dédier une interface réseau virtuelle d’administration sur les ressources administrées.
Les . mêmes pré-requis que R18 s’appliquent.
Information
Certains constructeurs proposent des interfaces de gestion à distance (ex. : Cisco IMC, Dell RAC, HP iLO) permettant un accès à la couche basse de l’équipement. Dès lors, si elles sont utilisées, elles doivent être considérées comme des interfaces réseau d’ad-ministration spécifiques et raccordées au réseau d’administration. En fonction de l’analyse de risque et de l’organisation des équipes d’administration, ces interfaces peuvent être raccordées dans une zone différente de l’administration des couches
. plus hautes.
Il est nécessaire de s’assurer qu’il n’est pas possible pour un attaquant, ayant pris le contrôle d’une ressource administrée, d’utiliser l’interface réseau d’administration pour rebondir sur les ressour-ces d’administration. En conséquence, seuls les flux initialisés depuis les postes ou les serveurs d’administration vers les ressources administrées doivent être autorisés par défaut. Les remontées des journaux d’événements depuis les ressources administrées (ex. : client syslog) vers le SI d’ad-ministration peuvent constituer une exception.
Appliquer un filtrage entre ressources d'administration et ressources
R19 · administrées
La recommandation R16 doit être appliquée rigoureusement entre les ressources
. d’administration et les ressources administrées.
De même, il est nécessaire de s’assurer qu’il n’est pas possible pour un attaquant, ayant pris le contrôle d’une ressource administrée, d’utiliser l’interface réseau d’administration pour rebondir sur les autres ressources administrées. Par conséquence, toute communication entre les ressources administrées doit être interdite à travers le réseau d’administration. Dans ce cadre, il est possible d’avoir recours à :
26 – [nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION
.
n un filtrage réseau sur la base d’une « micro-segmentation » (une ressource administrée = un sous-réseau), cette pratique pouvant néanmoins représenter une certaine complexité opéra-tionnelle ;
n l’utilisation de la fonctionnalité de VLAN privé (Private VLAN ou PVLAN) au niveau des com-mutateurs (cf. le guide ANSSI [7]).
Bloquer toute connexion entre ressources administrées à travers le réseau
R20 · d'administration
Une mesure de blocage ou de filtrage réseau doit être mise en œuvre entre les res-sources administrées afin d’interdire toute tentative de compromission par rebond à
travers . · les interfaces réseaux d’administration.
5.2.3 Cas d'un réseau étendu
Dans le cas d’architectures multi-sites ou de réseaux étendus, les ressources d’administration peu-vent être éloignées des ressources administrées. Les flux d’administration transitent alors poten-tiellement par un réseau de transport tiers 7 . Dans ce cas, il est nécessaire de protéger les flux d’administration en confidentialité, en intégrité et en authenticité.
Protéger les flux d'administration transitant sur un réseau tiers
R21
Si les flux d’administration circulent à travers un réseau tiers ou hors de locaux avec un niveau de sécurité physique adéquat (ex. : portion de fibre noire traversant l’es-pace public), ceux-ci doivent être chiffrés et authentifiés de bout en bout jusqu’à at-teindre une autre zone du SI d’administration ou une ressource à administrer. Dans ce cas, un tunnel IPsec doit être établi.
Pour la mise en œuvre du protocole IPsec, les [nom] du guide de . l’ANSSI [16] doivent être appliquées.
Les figures 5.2 et 5.3 illustrent respectivement l’accès aux ressources administrées dans le cas d’un réseau local et d’un réseau étendu.
- Un réseau de transport est dit tiers dès lors qu’il n’est pas maîtrisé par l’entité (ex. : Internet ou un réseau d’opérateur de télécom- munications).
[nom] À L'ADMINISTRATION SÉCURISÉE DES SYSTÈMES D'INFORMATION – 27
.
Interface réseau de production
Interface réseau d’administration
Postes
d’administration
Outils
d’administration
Filtrage
interne
Infrastructures · Filtrage
d’administration · périmétrique
SI d’administration
Ressources administrées
avec int. admin. physique
Ressources administrées
avec int. admin. logique
Ressources administrées
sans interface admin.
SI administré
F 5.2 – Administration, sur un réseau local, à travers des interfaces d’administration dédiées
(physiques ou logiques) ou une interface de pr
