Le webinar du 25 novembre consacré à Trustsec est en ligne sur la chaîne Youtube du blog.
Continuez à me remonter les sujets que vous voulez voir abordés dans les prochains webinars.
Authors
Laisser un commentaire
3 commentaires
Bonjour Jérome,
Webinar vraiment très intéressant, n’ayant pas eu la possibilité d’y assister en direct je me permet de poser une question ici.
Y’a t’il une contrainte ou une impossibilité a pousser toutes les SGACL à l’accès (si se n’est un switch d’accès qui ne gère pas les SGACL) afin de ne pas remonter des flux jusqu’au coeur ou datacenter ou il seront de toutes manière rejeté?
Merci d’avance,
Bonjour Julien,
Merci d’avoir posé ta question, je trouve ce blog beaucoup trop calme! C’est une excellente question. Le point est qu’une trame va intégrer le SGT de la source, et non celui de la destination! La SGACL ne peut avoir une action que sur les équipements ou le SGT de la destination (parfois appelé DGT) est connu. La question est donc de savoir où tu vas connaitre le SGT de destination? Cela peut être:
– le switch où la destination est connectée si tu gères l’authN,
– n’importe quel équipement (switch, routeur, FW) ou tu auras configuré un SGTIP mapping,
– sur le FW où tu auras fait des règles hybrides SGT sources / IP destination,
– n’importe quel équipement qui recevra le mapping (IPSGT) via le protocole SXP – SGT eXchange Protocol.
Je doute que quelqu’un configure des mappings sur tous les switchs, cela serait d’ailleurs beaucoup trop stressant en terme d’usage mémoire puisque cela t’imposerait d’avoir beaucoup trop de règles sur chaque équipement. Tu pourras par contre faire des règles plus avancées sur le FW du DC. La conséquence en effet est que tu ne filtres pas tout au plus près de la source. Mais je rappelle que sur l’accès source tu peux également positionner une première dACL (downloadable ACL) qui va pouvoir commencer à faire un peu le ménage.
J’espère avoir clarifié.
Merci!
Parfait, merci beaucoup pour ces précisions.