Architecture et virtualisation

[bertr@nd]

Bonjour à tous,

Voilà, pour moi la virtualisation est actuellement un outils de tests j'utilise un esxi 4 pour tester des distribs,config, et autres. Mais mon chef veux passer à l'étape suivante et virtualiser tous les serveurs de prod. Sauf qu'il veut mettre tous les serveurs sur un cluster : et la ça me laisse un peu perplexe...

Voici en gros notre infra :
1lien SDSL, 1 pare feu
LAN
3 windows srv, 1 esxi,1 nas
DMZ
2 srv web, 1 srv ftp, 1 srv vpn

Donc en effet, il veut mettre la DMZ et le LAN sur le même hyperviseur(un esx ou un esxi suivant le budget), je suis pas chaud du tout même si à priori d'autres l'ont déjà fait...J'ai lu quelques docs et posts sur le sujet mais je ne trouve pas d'argument suffisant pour faire pencher la balance. Mon chef a exposé tous les fabuleux avantages de la virtualisation à la direction, mais j'ai peur que la sécurité soit sacrifiée sur l'hôtel de la productivité... Je m'égare...

Qu'en pensez vous ?
la virtualisation est elle une technologie incontournable pour les petites structures ?

Merci de votre participation

[jibe]

Salut,

Déjà, surtout en matière de sécurité, il ne faut pas confondre ce qui est possible et ce qui est souhaitable ! Il ne faut non plus jamais partir du principe que puisque certains le font, c'est que c'est une bonne solution.

Ensuite, je comprends mal :

il veut mettre tous les serveurs sur un cluster

C'est à dire qu'il veut regrouper un groupe de bécanes... sur un groupe de bécanes ?

Un ensemble de serveurs tel que le tien peut éventuellement tourner sur esxi, et c'est heureux : cela permet de tester dans des conditions assez similaires à la réalité tout un réseau relativement complexe en restant dans un environnement virtualisé. Mais que ce soit possible pour test ne veut pas dire que c'est une bonne solution en prod. En prod, il faut en rester au minimum à la séparation des zones : WAN, LAN et DMZ ne doivent jamais cohabiter sur le même matériel. C'est une des premières choses qu'on apprend en matière de sécurité, et je ne vois pas pourquoi et comment la virtualisation y changerait quelque chose...

[jdh]

Par exemple, on peut commencer par lire ce qui est un peu récurrent sur ce forum ou ailleurs.
Chez HSC (juste une référence), http://www.hsc.fr/ressources/presentati ... ex.html.fr

En test, on peut faire ce qu'on veut.

En prod,
- on ne virtualise pas un firewall : que se passerait-il s'il y avait une faille alors qu'Internet est directement relié à l'hôte ?
- on virtualise par zones : un (ou plusieurs) hôte par zone,
Comme indiqué sur l'url "système hote compromis = toutes les VM compromises" ! (slide 26)


C'est simple, c'est sûr, ...

[bertr@nd]

Salut,

@jibe
Autant pour moi, ce que j'entends par tous les serveurs sur un cluster c'est : cluster = (un san et 2 serveurs physique avec hyperviseur esx ou esxi).
je suis d'accord avec ta première affirmation, mais je n'est pas d'arguments probant. Si plusieurs cartes réseau physique sont disponibles alors on peut réellement séparer les flux wan et lan...il reste l'hyperviseur lui-même qui peut être compromis.

Si il faut un "cluster" esx pour chaque partie du réseau...Alors la virtualisation n'est peu-être pas viable pour nous.
Je suis déjà convaincu de la nécessité de séparer les zones mais économiquement parlant... (les directions sont très sensible sur ce sujet)

@jdh
En effet j'ai vu cette présentation qui me conforte sur mon point de vu. Dans le projet actuel il n'est aucunement question de virtualiser le pare feu mais uniquement les serveurs qui sont derrière.

@tous
Il y aurait pas un vent de virtualisationite aigu qui traine un peu partout ?

[ccnet]

Bonjour à tous,

Voilà, pour moi la virtualisation est actuellement un outils de tests j'utilise un esxi 4 pour tester des distribs,config, et autres.

Là dessus ps de problème on est d'accord.

Mais mon chef veux passer à l'étape suivante et virtualiser tous les serveurs de prod. Sauf qu'il veut mettre tous les serveurs sur un cluster : et la ça me laisse un peu perplexe...

Là aussi on est d'accord sur un point, le chef s'emporte et ne maitrise pas toutes les conséquences de son choix.

Voici en gros notre infra :
1lien SDSL, 1 pare feu
LAN
3 windows srv, 1 esxi,1 nas
DMZ
2 srv web, 1 srv ftp, 1 srv vpn

Pas de serveur de messagerie, pas de proxy ?

Donc en effet, il veut mettre la DMZ et le LAN sur le même hyperviseur(un esx ou un esxi suivant le budget), je suis pas chaud du tout même si à priori d'autres l'ont déjà fait...J'ai lu quelques docs et posts sur le sujet mais je ne trouve pas d'argument suffisant pour faire pencher la balance. Mon chef a exposé tous les fabuleux avantages de la virtualisation à la direction, mais j'ai peur que la sécurité soit sacrifiée sur l'hôtel de la productivité... Je m'égare...

Qu'en pensez vous ?

Je pense que vos craintes sont fondées. Le chef s'emballe et ne voit qu'une partie du sujet. La complexité induite lui échappe. Pas facile de le lui dire ainsi.

la virtualisation est elle une technologie incontournable pour les petites structures ?

Je pense qu'elle peut être fort utile. Mais de là à dire qu'elle est incontournable, je n'en ferai pas une religion.

L'idée de le redondance avec un cluster est bonne. Mais il y a des implications techniques fortes. Tout d'abord Vmaware recommande de ne pas utiliser le même réseau pour l'administration d'ESX et les vm, ni le même switch virtuel. De même il est recommandé de dédier une interface à Vmotion (c'est ce qui fera fonctionner votre cluster comme vous l'attendez) là aussi dans un réseau isolé, car flux TCP spécifiques. Ensuite vous aurez besoin d'une machine avec Vcenter (Virtual Center), autre flux TCP.
Pour le reste je souscris pleinement aux recommandations de JDH.

Je sujet n'est épuisé pour autant (il est tard) et il y a bien d'autres choses à dire. La sécurité est une question très globale d'où mes questions plus haut. En d'autres termes si l'architecture réseau n'est pas saine la présence des hyperviseurs et la virtualisation de l'ensemble n'apportera que des risques supplémentaires. Même chose avec le san (tiens encore des flux TCP et autres).

Comme disait Hervé Schauer, pour en avoir parlé avec lui : sur le papier c'est beau c'est propre. En réalité c'est souvent un plat de spaghettis.

J'ai un document Vmaware sur les "best practices" : Sécurty Hardening. Je n'en ai pus l'url mais juste le pdf. Si cela vous intéresse. C'est un document de l'éditeur, c'est déjà assez lourd et on peut penser qu'ils sont en dessous de la barre puisque le marketing veille au grain dans ces entreprises. Peut être pas autant que chez Microsoft.

Cela dit ne vous méprenez pas je suis partisan de l'utilisation de Vmware ESX, c'est un réel atout. Mais pas n'importe comment. On peut continuer à en parler.

[ccnet]

Le document Vmware est disponible ici : http://www.vmware.com/pdf/vi3_security_hardening_wp.pdf

Je complète.
Si l'on regarde les avis de sécurité du Certa on trouvera pour 2010 ceux qui concernent Vmware. On voit en particulier que des failles concernent la possibilité de contourner la politique de sécurité. (par exemple : http://www.certa.ssi.gouv.fr/site/CERTA ... I-160.html ou encore http://www.certa.ssi.gouv.fr/site/CERTA ... I-553.html).
A noter que dans des conditions très particulières (difficiles à reproduire et expérimentales aujourd'hui, mais demain ?) il est possible de réaliser des sorties d'isolation de l'hyperviseur.
Il en ressort que la cohabitation de plusieurs systèmes (vm) sur un même hôte a une incidence réelle sur la sécurité et en particulier une attention très particulière doit être portée au cloisonnement des vm sur le plan réseau. Deux risques supplémentaires sont donc introduits. Celui relatif à l'hyperviseur lui même (c'est un noyau Linux dans le cas d'ESX) : déni de service, élévation de privilèges et d'autre part la possibilité, si une vm est compromise, d'atteindre les autres du fait du "partage", par exemple, de périphériques (SAN, Switchx virtuels, lecteurs CD, ...).
Tout cela plaide en faveur de la séparation des zones sur différents ESX. Je sais d'expérience et je connais plusieurs configurations de production dans de très grandes entreprises où ce n'est pas le cas. Pour une fois la prudence est chez Microsoft. Si Vmware n'hésite pas proposer des configurations où l'on trouve le lan et les dmz sur la même machine physique, Microsoft déconseille explicitement de "mélanger" les zones sur une même machine HyperV.
In fine beaucoup de choses vont dépendre des risques qui vous sont propres. Cela suppose que vous ayez une vision claire des risques et des conséquences de leur occurrence. Je crois que votre chef est loin de tout cela. A mon sens sa perception trop "euphorique" de la virtualisation est en elle même un risque puisque cela conduit à sous estimer les risques induits par cette technologie.
La virtualisation peut améliorer certains aspect de la sécurité (disponibilité par exemple) mais elle impacte fortement l'organisation de celle-ci. Ignorer cet impact est une erreur. Je pense que votre chef est en train de la faire.

[bertr@nd]

Salut à tous,

@ccnet
merci pour les docs...
En effet, j'ai bien un serveur de messagerie en dmz qui cohabite avec un site web (SME 7.5.1). Par contre pas encore de proxy ...

Bon, sinon sur le fond, entre la théorie et la pratique, il y a toujours une marge qui reste a apprécier en fonction des moyens (technique et financier), des risques (fiabilité,sécurité...), et du but recherché.

Aujourd'hui j'en ai discuté rapidement, plusieurs arguments m'ont été exposé :
- un hyperviseur n'est pas exempt de faille, d'accord, mais une pare feu qui gère plusieurs zones a potentiellement des failles aussi ... (m'a laissé sans voix! raisonnement par l'absurde ?)
- si le projet de virtualisation doit être segmenté en fonction des zones de notre réseau cela implique un investissement trop important pour nous...
- 4 ou 5 cartes réseau par serveur du cluster et un bon paramétrage, permettra d'atteindre déjà un bon niveau de segmentation ... une bonne politique de sauvegarde fera le reste.

voilà,voilà...

[jibe]

Salut,

cluster = (un san et 2 serveurs physique avec hyperviseur esx ou esxi).

Mis à part le nombre de 2 que j'ignorais, j'avais bien compris les choses ainsi. Ce que je voulais dire, c'est que ton chef remplace un groupe de n serveurs par un cluster composé de plusieurs bécanes. C'est un peu surprenant quand on donne pour seul justification l'économie de bécanes !

Bon, cela dit, on en réduit quand même le nombre, et on se donne une redondance qui peut éventuellement être utile. Mais alors, il faut bien définir les besoins : est-ce la haute disponibilité ou la sécurité qui est le plus important ? Comme il n'y a aucune indication sur ce point et qu'on est sur un forum dédié à la sécurité, j'opte donc pour la seconde hypothèse : sécurité plus importante que haute disponibilité.

Et dans ce cas, le montage devient clair : on garde le firewall, et on monte deux esx séparés sur chacun une bécane. Même matos, mais on peut ainsi séparer DMZ et LAN !

Après, s'ils veulent vraiment réduire les coûts, il faut peut-être envisager de mettre en place une SME... N'ayant à peu près aucune idée des besoins ni même de l'importance du réseau, je ne sais pas si c'est possible, souhaitable ou complètement inenvisageable.

Pour le reste, je crois que ccnet a vraiment bien décortiqué la question...

un hyperviseur n'est pas exempt de faille, d'accord, mais une pare feu qui gère plusieurs zones a potentiellement des failles aussi ... (m'a laissé sans voix! raisonnement par l'absurde ?)

Pas raisonnement par l'absurde, raisonnement absurde, oui
A moins qu'ils pensent mettre la *box comme pare-feu, bien sûr

La différence entre un firewall et un hyperviseur, c'est que dans un cas les failles éventuelles sont dues aux règles que tu maïtrises et peux donc facilement corriger, alors que je ne pense pas que tu puisses corriger une faille dans VMWare !

Mais c'est encore pire que ça : mettre tous les serveurs dans le même hyperviseur, admettons, mais quand même pas dans la même zone ? Donc, s'il reste toujours une DMZ et un LAN, le firewall aura bien les mêmes règles qu'il y ait un ou plusieurs superviseurs ! Comme le souligne ccnet, ton chef s'emballe et trouve son idée si géniale qu'il en oublie tout le reste, à commencer par les besoins et l'architecture de son réseau !!!

- si le projet de virtualisation doit être segmenté en fonction des zones de notre réseau cela implique un investissement trop important pour nous...

Alors, il ne faut changer que les serveurs à bout de souffle : ça coûtera moins cher que de vouloir tout virtualiser. Le matériel existant n'est quand même pas tout à mettre à la poubelle ?

Sinon, un hôte en DMZ, et un en LAN, ça fait deux serveurs, pile le nombre qu'il voulait mettre en cluster... Ou alors, une SME...

Mais je répète : on ne sait rien des besoins réels. Si ces besoins sont importants, alors il faut en prendre les moyens. S'ils ne le sont pas, alors il faut choisir la solution la mieux adaptée, pas celle dont on a envie et qui oblige à sacrifier la moitié des besoins pour satisfaire les envies et la fierté du chef !

Bref : la virtualisation est un moyen parmi tant d'autres, pas un besoin !!!

4 ou 5 cartes réseau par serveur du cluster et un bon paramétrage, permettra d'atteindre déjà un bon niveau de segmentation ... une bonne politique de sauvegarde fera le reste.

Autrement dit : on fait une usine à gaz et on compte sur les sauvegardes en cas d'explosion ! Ce qui veut dire une indisponibilité pendant un certain temps, même un temps certain pour remonter l'usine à gaz à partir des sauvegardes. Dans ce cas, il n'y a aucun besoin en haute disponibilité !
=> on fait un montage plus simple, et donc plus fiable, et en cas de défaillance du matos (pas d'usine à gaz => bonne sécurité et fiabilité sur les autres plans) on compte sur les sauvegardes qui seront plus faciles à remonter puisque le montage est plus simple et séparé.

[bertr@nd]

Alors j'ai du neuf !

Aujourd'hui suite à un entretient avec un fournisseur, mon chef me demande mon avis sur la possibilité de changer notre pare feu vieillissant par une vm netasq ... soit directement intégré sur le fameux clusteur soit sur une machine dédié mais en vm de toute façon...
J'ai lu quelques posts sur le sujet et pense savoir ce que ça vous inspire ...

J'ai quand-même beaucoup de difficulté à trouver de la documentation impartiale sur le sujet, la majorité des informations que je pêche vente toujours les avantages procurés par cette technologie. Avez-vous des retours d'expérience sur la virtualisation d'éléments actif ?

J'ai trouver une étude intéressante sur "Evaluation des performances réseau dans le contexte de la virtualisation XEN"
http://prunel.ccsd.cnrs.fr/docs/00/25/05/89/PDF/submission_41.pdf
qui me conforte un peu dans mes intuitions, mais les études publique sur esx ne sont pas légions ...

J'ai trouvé ça aussi : "Virtualisation de la sécurité ou Sécurité de la virtualisation"
http://www.clusir-rha.fr/uploads/lyon/SSI/2009-2010/DossierDePresentation-ColloqueIE2010.pdf

@jibe

Mais je répète : on ne sait rien des besoins réels. Si ces besoins sont importants, alors il faut en prendre les moyens. S'ils ne le sont pas, alors il faut choisir la solution la mieux adaptée, pas celle dont on a envie et qui oblige à sacrifier la moitié des besoins pour satisfaire les envies et la fierté du chef !

Oui, le fond du problème et bien là, la solution en découlera...
principal objectifs de mon chef :
- gagner du temps sur l'administration
- anticipé la futur monté en charge du SI(nouveau projet,hébergement supplémentaire...)
- s'affranchir de la couche matériel
- peut-être pca et pra

en terme d'utilisateurs interne du SI : 80 personnes réparties sur trois site actuellement voir plus dans un avenir proche
services web externe accessible potentiellement à 500 utilisateurs

[jibe]

Salut,

Concernant les besoins, je pense que jdh te conseillera de prendre un papier et un crayon et de commencer par en établir la liste, puis de les classer par priorité. J'ai la très nette impression que ça n'a pas été fait, tu pourrais déjà reprendre ton chef sur ce point : soit tu n'es qu'un exécutant et il décide et prend la responsabilité de tout et ne te demande que d'installer ce qu'il a choisi, ou il te demande de t'impliquer et de prendre des décisions, et à ce moment là il faut que tu aies bien toutes les données du problème.

Et ce n'est pas le cas :

• Le problème des coûts ne semble intervenir que pour refuser les solutions dont il n'a pas envie d'entendre parler
• Le pca est défini en "peut-être" dans les besoins, mais probablement mis en avant pour imposer un système redondant. Il faudrait savoir...
• Rien n'est évoqué concernant les sites multiples (hormis qu'il y a un serveur VPN à virtualiser !)
• La liste des besoins me parait bien faible : rien concernant les sauvegardes (hormis "peut-être" un pra à envisager !!!), presque rien concernant la montée en charge prévue, rien concernant les applications, le web, la messagerie etc. ( et j'oublie probablement des choses importantes) Si tout ce qui est en place va bien, pourquoi donc en changer ?

Quant à l'adéquation entre les besoins et les solutions imposées, ça me laisse perplexe :

• gagner du temps sur l'administration : En quoi la virtualisation fera-t-elle gagner du temps d'administration ? Si elle n'est pas incompatible (bien que... il faudra bien administrer l'hyperviseur en plus du reste !), elle n'apporte rien et rien n'a été évoqué qui puisse améliorer ce point,
• anticipé la futur monté en charge du SI(nouveau projet,hébergement supplémentaire...) : mêmes remarques : la virtualisation n'apporte rien, et aucune solution proposée !
• s'affranchir de la couche matériel : Là, effectivement, la virtualisation s'impose. Elle s'impose même à tel point que je me demande si ce "besoin" en est réellement un, et en tous cas s'il est aussi prioritaire que ça. Ça me laisse plutôt l'impression d'un moyen pour ton chef d'imposer ses envies. D'ailleurs, comment pourrait-il s'agir d'un besoin ? Pour moi, c'est plutôt un moyen qu'un objectif...
• peut-être pca et pra : Je l'ai dit, cela montre que la haute disponibilité n'est pas la priorité, loin de là. Quant au pra, il me semble nettement plus simple à mettre en place quand les tâches sont bien réparties que quand on met tout dans une usine à gaz. Mais bon, puisqu'il n'est pas prioritaire...

Bref, l'étude des besoins m'a l'air assez mal faite et farfelue. C'est le premier point sur lequel je me battrais Un projet informatique, pour être mené à bien, doit absolument partir des besoins pour aboutir à une solution. Or, là comme hélas bien trop souvent, on commence à penser à LA solution avant même d'avoir envisagé de définir les besoins !

[ccnet]

Aujourd'hui suite à un entretient avec un fournisseur, mon chef me demande mon avis sur la possibilité de changer notre pare feu vieillissant par une vm netasq ... soit directement intégré sur le fameux clusteur soit sur une machine dédié mais en vm de toute façon...
J'ai lu quelques posts sur le sujet et pense savoir ce que ça vous inspire ...

Je crois que vous avez bien compris ce que l'on en pense.

en vm de toute façon...

Là je ne comprend carrément pas. C'est un non sens. Quel objectif recherché en utisisant une vm pour le firewall ? Pourquoi un Netasq ?

Le chef est, je crois, atteint de virtualisationnite aigu. A ce niveau c'est mystique, il doit penser avoir atteint le Graal . Un cluster de firewall physique avec deux FAi différent ça je comprend bien et j'en vois l'utilité, l'apport, la performance. Mais un Netasq dans une vm non vraiment pas.

Sur les objectifs du chef :

- gagner du temps sur l'administration

Je pense qu'il se trompe sur ce point. Vous ajoutez un niveau, l'hyperviseur avec ses fonctionnalités (switchs virtuels, vlan, san, ...). Il faut l'administrer, regarder les logs, monitorer le tout en plus du reste qui ne change pas. Il faut aussi patcher Vmware. Exploiter un Windows physique ou en vm c'est du pareil au même. Tous les problèmes restent. Cf page 18, 27, 28 du doc Clusir. Sur la page 26 je ne suis pas du tout d'accord.

- anticipé la futur monté en charge du SI(nouveau projet,hébergement supplémentaire...)

Ok il y a de nouvelles possibilités réellement mais attention au dimensionnement initial. Par exemple on ne change pas facilement la taille d'une partition disque. L'ajout d'un proc à une vm n'est pas si évident que cela. L'expérience m'a montré que les machines Windows physiques transférée via Vmware converter sont parfois instables. Un de mes clients à renoncer à cette méthode. Toutes les vm Windows ont été créées "nativement" par une nouvelle installation de l'OS.

- s'affranchir de la couche matériel

Non, pas convaincu. La HCL des machines acceptant ESX est relativement limitée. Si les serveurs choisis ne sont pas dans la liste, pas de support vmware et des ennuis quasiment garantis.

- peut-être pca et pra

Oui, mais il faut les outils et les licences qui vont avec.

Sur le doc Clusir. Page 31 on retrouve ce que je vous avais indiqué sur les vulnérabilités du type sortie d'isolation. Je suis d'accord sur l'ensemble à l'exception notable de la page 26. On voit bien en lisant ce document que l'administration n'est pas simplifiée du tout, bien au contraire. Par contre il est vrai que les possibilités de PRA, PCA sont nettement améliorées, autant en couverture fonctionnelle, qu'en délai sous réserve d'avoir ... "ce qu'il faut".

[jibe]

il est vrai que les possibilités de PRA, PCA sont nettement améliorées, autant en couverture fonctionnelle, qu'en délai sous réserve d'avoir ... "ce qu'il faut".

Argh ! Je suis loin d'être aussi expérimenté que ccnet en matière de virtualisation, et j'ai plutôt dit le contraire par ignorance et surtout manque de réflexion (maintenant, je vois bien pourquoi et comment la virtualisation améliore les PCA et PRA, j'aurais dû y penser !)

Bon, on en reste quand même sur le fait que l'étude des besoins est négligée au profit de la "virtualisationnite aigu", comme dit ccnet ! Je crois que d'excellents arguments ont été donnés, mais cela suffira-t-il à convaincre "un mystique qui croit avoir atteint le graal" ? Ces gens là, hélas, n'ont plus les pieds sur terre et ne croient plus qu'en leurs visions... Reste la solution que je suggérais : refuser toute prise de responsabilité, et coucher les arguments par écrit (tant qu'Ixus existe, ce fil peut d'ailleurs être une bonne référence). De cette manière, tu pourras au moins dire lorsqu'un inévitable problème apparaitra : "j'avais prévenu que cette solution n'était pas bonne"...

Bon courage !

[bertr@nd]

Salut à tous,

Bon en effet, la sagesse est de prendre le temps d'étudier correctement le SI, afin de choisir une solution en toute connaissance de cause. Donc J'essaie de tempérer en proposant de faire une analyse de nos besoins (utile dans tout les cas). Ce qui permettra je l'espère que tout le monde tombe d'accord par la suite ...
dans cette optique je commence un réflexion sur l'analyse de l'existant :

- analyse de l’existant en terme de services
- hiérarchie des services et criticité
- Evaluation des ressources requise par services

- analyse de l’infra, os, serveur, matériel actif
- état de la consommation des ressources par serveur

- segmentation du réseau
- schéma des flux réseau
- politique de sécurité et de sauvegarde

Qu'en pensez-vous ? Avez-vous quelques documentation à partager sur ce sujet ?
Question subsidiaire : quelqu'un a-t-il déjà eu un accès snmp sur routeur fourni par Oléane ? et si oui avec quel outil peut-on l'exploiter ?

[ccnet]

Un petit coup d'œil à la méthode Mehari sur le site du clusif. Cela vous donnera des idées sur la partie analyse de risques / couverture / risques résiduels. Le guide des services de sécurité vous fournira une vue pratiquement exhaustive des risques à considérer même si une bonne partie ne vous concernera sans doute pas. Je pense que votre décision est sage dans son principe.

[jibe]

Salut,

Je pense que votre décision est sage dans son principe.

+1 ! C'est exactement la méthode à adopter dans le contexte que tu nous as décrit.

Question subsidiaire : quelqu'un a-t-il déjà eu un accès snmp sur routeur fourni par Oléane ? et si oui avec quel outil peut-on l'exploiter ?

Je pense que tu aurais plus de chances d'obtenir des réponses en ouvrant un nouveau post sur cette question. Du même coup, tu pourrais le mettre dans le forum "configuration matériel réseau" qui me semble mieux adapté