Reprise du message précédent :
Tu connais direct la réponse :
 
"Ouais mais y'a des fils ça fait pas propre/joli"

Genre tes users ils sont soigneux ?  
 
A la limite la fibre dans le faux plancher avec le miniswitch sous l'îlot, de là tirer les câbles vers les PC.  
A voir si le miniswitch résistera aux power-users bourrin-users qui tirent violemment sur les câbles, typiquement le RJ qui va au téléphone IP.

Pas propre > Y'a déjà la goulotte/câbles pour l'alim et le réseau, wut ?
Mais effectivement @ptibeur il faut que ça soit bien fait. Déjà une prise murale histoire de remplacer easy la fibre pétée
Après le switch local peut rebalancer en POE ou 1GbE classique rien dans les murs

Si, tu as tjrs la fibre dans les murs, elle remplace ton cat5/6 et réduit le nombre de brins grâce aux switches, mais ça n'élimine pas magiquement tout ton inventaire de liaisons à gérer

A voir ce que tu gagnes entre moins de brins, moins de génie civil pour les trous, et de l'autre côté de la balance une multitude de switches éventuellement PoE au lieu d'un seul gros switch mutualisé. Si tu veux des fonctions avancées (802.1x) tu ne peux pas mettre des switches soho pourris non manageables, ça peut peser dans la balance pour l'un ou l'autre des designs en fonction de tes besoins/budget.

J'aime bien ces discussions pour étudier de nouvelles façons de faire

138 balles pour 8 ports avec PoE+ et 2 SFP : https://www.fs.com/fr/products/73457.html
On peut même faire un ring

edit: et exit les 100m max, du coup pas de trucs de distributions sur les gros bâtiments.

FS je sais pas comment ils arrivent à sortir ce tarif, c'est même pas le prix des matières premières A voir le bruit que fait le ventilo, si c'est supportable pour mettre dans un bureau.

Ah merde j'avais pas checké ça, alors celui la : https://www.fs.com/fr/products/35289.html
164€, fanless,plus de poe, plus de garantie

bof, HP/Aruba fait le même genre mais fanless et avec des ports SFP+ (2930f), pour moitié moins cher que ça encore si t'as de quoi négocier... je pense que les matières premières sur ce genre de matos ne représentent pas grand chose au final.

Uplink en ethernet au pire osef non ?

https://www.ldlc.com/fiche/PB00245340.html

ça donne une idée de la marge qu'ils se font si tu l'achètes au prix public

J'ai eu la même.  

 
Pour avoir utilisé ce type de solution en fibre avec la technologie Microsens c’est vraiment très sympa

Personne dans un cloud (azure/aws) avec des firewall d'une marque autre (type palo alto, forti, ...)
 
On regarde comment faire ça dans Azure.
Entre les services PaaS définis en ip publique par défaut, un oubli flagrant de sécurisation forte & la difficulté de monter des instances de firewall sur des VM (donc cluster, load balancer, ip multiples, configuration de nic, ...)
 
Franchement, je m'en sors pas

Ton mini switch a intérêt à être manageable et avoir toutes les protections modernes (bpdu guard et compagnie) sinon c'est une très mauvaise idée.

j'ai du palo alto dans azure, ça fonctionne. Après y'a pas de mystère, c'est pas ton IP sur ethernet classique comme à la maison donc au début faut bouffer de la doc pour bien comprendre comment ça marche.

Mais bon plus globalement, à mon avis ce genre de setup ne va pas vraiment dans la logique de ces services.

Et les oublis de sécurisation sont bien plus dans l'implémentation du client que dans l'outil azure/AWS en lui-même. Après si tu laisses ta meute de devs cliquer partout oui forcément ça va pas bien se passer, mais ce serait le même problème avec un firewall dans un DC classique.

Le waf/firewall d'Azure ne fait pas l'affaire ?
C'est quoi l'intérêt de vouloir mettre une appliance de FW dans le Cloud plutôt que d'utiliser le service managé ? (vraie question)

dans mon cas c'est l'intégration avec le reste du parc de firewalls (azure est voué à rester une petite partie du SI).

 
Je me suis bouffé de la littérature justement.
 
La partie IaaS, c'est chiant mais ok, j'ai pigé.
1 vnet "wan" dédié express route (voire azure wan selon coût) + microsoft peering pour accéder aux ressources PaaS de l'interne
1 vnet portant FW avec LB externe et interne + WAF + qqs jumpbox hors réseau (pour intervenir sur les FW en cas de soucis, mais éteintes sinon)
1 souscription prod, 1 souscription non-prod,
1 vnet par souscription avec les mêmes découpages de subnets (front, back, admin, data)
vnet peering vers le vnet des FW
 
Mais tu as fait comment pour forcer les composants PaaS à passer par lui ?
 
J'aurais tendance à utiliser les services endpoint pour forcer leurs cname à être accessibles des subnets internes.
+ config de leurs Firewall pour refuser les accès externes autres que les subnets & certaines IP internes
 
C'est vraiment pas au niveau d'un AWS pour ça.
 
Pour toi, c'est quoi la logique de sécurisation de ces services PaaS ?

je fais que du IaaS désolé je me serais imaginé que pour le PaaS on pouvait utiliser la même logique, vnet, NSG, UDR et compagnie mais j'ai pas regardé vu que j'ai pas besoin.

 
pour moi, en l'occurence, c'est du Forti sur tout le reste du réseau :
- avoir la même logique technique partout sur tous les sites
- les FW de Palo Alto/Forti ont au-dessus du niveau de FW fourni par Azure
- les Azure WAF et Azure Firewall sont TRES chers pour ce que c'est
- FortiAnalyser permet de récupérer et centraliser les analyses des différents FW

Je comprends oui, ça fait du sens. Même si c'est un peu étrange par rapport à la logique PaaS. Après effectivement si le service est naze par rapport à son coût..

Utiliser un cloud provider et pas utiliser les services managés  

on n'en a aucune utilité on n'est pas du tout dans la cible du client typique de ce genre de service, on ne s'en sert pas pour développer ni publier des application.

 
ces composant PaaS Azure, enfin leur logique initiale, c'est vraiment de la merde.
 
Exemple :
vous déployez un composant type storage account / datawarehouse / webapp / ... ,
dans votre Tenant, votre souscription, votre chez vous hein ...
 
Ah pas de bol, le nommage est déjà pris quelque part dans le monde => le NOMMAGE est commun à TOUT le monde.
 
ba oui, parce ce que vous allez avoir un accès en :
webapp : <app_name>.azurewebsites.net
database/datawarehouse : <bdd_name>.database.windows.net
aks : <aks_name>-id.hcp.<region>.azmk8s.io (bon, c'est bizarre mais autogénéré par Azure aussi)
 
D'autres accès comme les cognitives services ont des endpoints communs.
Typiquement https://westcentralus.api.cognitive [...] analytics/  
pour un service cognitif d'analyse de text, avec un name & une shared key associée
 
Enfin bref, qu'est-ce que c'est chiant de faire quelque chose de sécurisé  
sans, par exemple, cocher comme dans le tutoriel  
[x] Allow access to all Azure services  
Car ce qui n'est pas bien expliqué, c'est que cela donne accès à la ressource (ici un adsl datalake gen 1) à toute ressource déployée partout dans Azure quelle qu'elle soit (pas que ma souscription), service Paas ou vm ou power bi ou ... TOUT.
 
Il ne reste que les rôles d'accès pour protéger les données du datalake.
Si vous avez laisser un accès default en read-only à tout, n'importe qui peut récupérer vos données.
 
C'est pas grand chose, une simple petite case à cocher et ça crée une ouverture béante.
 
Les fuites par manque de sécurisation des données ne me choquent plus du tout vu la technicité de ces trucs et le manque de compétence disponible pour vraiment sécuriser.

Filtering L4+ ; IDS/IPS et, on va pas se le cacher, ne pas bousculer les opérations à la secu.

Pour AWS les SG et NACL te donnent respectivement un filtering au niveau de l' host qui fait du allow / deny  in/out stateful sur L3 et la même chose en edge VPC mais stateless. Si tu veux inspecter ou filtrer de manière plus fine tu vas devoir trouver une solution.

Je suis étonné, permets-moi d'en douter.

Si t'operes une infra un minimum sérieuse et complète tu devrais trouver très probablement des moyens de re-architecturer voir re-factoriser.
Je comprends pas l'idée de juste faire de l'instance dans le Cloud.
Ok c'est disponible à la demande, et si tu géres bien ton FinOps tu gratteras des points sur ton TCO.
Néanmoins, c'est économiquement pas optimal, peu flexible, ajoute un overhead d'opérations, occupe de la ressource inutilisée (c'est jamais 100% opti même si tu fais du right sizing)... Bref c'est bien mais pas la finalité.

 
   
 
Mais la stratégie de déploiement des services PaaS dans AWS n'est pas la même que dans Azure et c'est quand même plus simple côté infra.
mais qu'est-ce que je fous dans Azure moi ... *snif*
 
A se poser réellement la question de l'intérêt final de mettre des FW en place si la moitié du traffic réseau ne passe pas/n'est pas visible d'eux (ou alors après un effort réellement titanesque et sans garantie que ça tienne longtemps)

Merci pour ces infos

une plaie à gérer donc tu vas le payer en main d'oeuvre et support

Pourquoi ça serait une plaie à gérer ?

"On n'a plus de réseau"
"Pourquoi il sent le café mon switch ? vous n'avez rien renversé dessus ?"
"Nous ? noon, promis".
 
"on n'a plus de réseau".
"mais où est la table avec le switch collé dessous?"
"ah ben on a réorganisé les bureaux et on a jeté les anciens meubles, pourquoi c'était important ?"
 
"On n'a plus de réseau"
"Mais, où est le cable d'alimentation du switch ?"
"Ah ce truc ? comme c'est à aucun d'entre nous, on l'a débranché pour mettre la bouilloire".
 
"On n'a plus de réseau"
"Pourquoi le switch est éteint ?"
"ça faisait trop de bruit."
 
"On n'a plus de réseau"
"Euh, vous avez fait une boucle là"
"Oui c'est plus joli, pourquoi , c'est un problème ?"
 
 
et encore je suis à froid là.
 
Quand je vois la durée de vie des téléphones de conférences et autres machins technologiques dans les lieux fréquentés par plus de trois employés à la fois, je n'y vois que des emmerdes potentielles

Ce que tu peut être aigri mon pauvre flash

Malheureusement, que des experiences vécues (y compris le coup du changement de meubles).

 
c'est nous, c'est filaire partout ... sauf demande express de chertains VIPs d'avoir une grosse borne wifi "parce que les fils c'est moche".
 
Donc faut du wifi, faut que ça capte bien, faut que ça aille vite ...
 
  mais c'est pas grave

Ce défaitisme
 
Ca n'est pas très détaillé mais on a au moins un mec qui a fait ça
http://media.frnog.org/FRnOG_23/FRnOG_23-8.pdf
https://www.dailymotion.com/video/x29raxt

 
Et quand tu viens les installer: "hé mais toutes ces ondes là, c'est dangereux, on va en parler au CHSCT"

Plus qu'à leur installer du token ring.

 
Perso j’appelle ça de l’expérience
 
 
Pas plus tard que la semaine dernière j'ai installée une Zoom Room pour enfin éliminer notre dernière salle de réunion qui utilisait encore des cables.
 

 
 
Tout passe en sans fil, c'est géré par un écran tactile avec trois boutons ("Meeting zoom" / "présentation only" / "phone only" ) etc.. Et on utilise déja zoom depuis 5 ans sur tous les ordis.
 

 
Et bien sûr malgré les trois boutons je leur ai aussi imprimé une petite fiche avec les instructions de base.
 
 
La salle a duré montre en main 1h30.
 
 
Je suis passé faire un tour voir comment se passaient les premières réunions avec le nouveau système, j'ai trouvé un gars debout sur la table de réunion. Il avait trouvé l'ordi attaché sous la table qui gère le bouzin, arraché le cable HDMI qui allait de cet ordi au mur et s’appliquait quand je suis arrivé à le brancher directement sur le vidéoprojecteur afin de brancher son laptop dessus.
 
Alors des switchs sous les bureaux utilisateurs

tout ces blames et mises a pied que ca mérite
 
destruction de matériel, sabotage de l'infrastructure et j'en passe

Ca me rappelle une levée de bouclier d'une Secrétaire de Direction qui se plaignait de ne pas capter le Wifi avec son iPommePhone (Perso... Hein! Bien sûr! Conso de l'enveloppe Data! Toussa! ) mais qui refusait catégoriquement que la borne Wifi soit installée dans son bureau... Niet! Trop dangereux!
On a donc du l'installer de l'autre côté de la cloison, dans le bureau voisin, avec accord de ladite utilisatrice qui se sentait tout de suite mieux à l'idée de penser que le Wifi était derrière le mur...

J'ai riz