Dans mon activité pro j'échange régulièrement avec ce genre d'autorité de tutelle (dont l'ANSSI qui est en plein développement et qui commence à sortir de très bons guides)
La mise en place d'un bastion en back-to-back est utile du moment ou l'on gère correctement le sectionnement des domaines de routage. Dans une infra de ce type, dans les règles de l'art, les réseaux de confiance (interne) ne dispose pas de route par défaut vers l’extérieur, seul le firewall frontal est capable de joindre les réseaux publiques. Malheureusement, bien souvent ces architectures étaient perverties et leur objectif initial de cloisonnement du routage disparaissait.
Dans les règles de base que je vous conseille:
les serveurs de production ne doivent jamais pouvoir sortir librement sur Internet ceci afin de limiter la casse en cas de compromission. En effet, en analyse killchain, dans 9 Cas sur 10 l'assaillant va compromettre le service cible en lui faisant télécharger un code malveillant (payload) puis en l'exécutant. Si votre serveur compromis ne peut télécharger le payload cela vous donne plus de chance de détecter l'attaque (ex : analyse des logs, détection de tentative de sortie etc.). Si les serveur consomment des ressources externes (API etc.), il faut ouvrir spécifiquement ces flux
ne pas avoir de règles de NAT outbound pour les réseaux les plus sensibles, cela rajoute une sécurité additionnelle en cas de filtrage laxiste
avoir un partenaire de protection contre les dénis de service par flood, ce problème se gère en amont
par défaut tout fermer et ouvrir seulement ce qui est nécessaire
centraliser les logs sur une plateforme d'analyse pour détecter, analyser et comprendre la situation (perso j'utilise Splunk, c'est payant certes mais c'est efficace, voir pj )
comprendre ce que l'on fait.
ovpn.png
ovpn.png_thumb
heatmap.png
heatmap.png_thumb
siem.png
siem.png_thumb