Une base solide, orientée performance

La baie réseau observée présente une architecture propre, structurée et clairement pensée pour la performance. En haut du rack, on retrouve un MikroTik Cloud Core Router, véritable cœur de l’infrastructure. Ce modèle, basé sur une architecture multi-cœurs haute capacité, est conçu pour des environnements exigeants : backbone ISP, agrégation multi-sites, ou PME à forte densité de trafic.

Les ports SFP/SFP+ actifs indiquent une connectivité fibre opérationnelle. Juste en dessous, le patch panel fibre optique équipé de connecteurs SC/APC (verts) confirme une distribution optique structurée. Nous ne sommes pas face à un simple réseau LAN d’entreprise, mais à une architecture pouvant servir :

De mini-POP ISP
De nœud d’agrégation fibre
De cœur réseau d’une PME multi-bâtiments

Le CCR assure plusieurs rôles critiques :

Routage inter-VLAN
Terminaison de liens fibre
Possibilité de routage dynamique (OSPF, BGP)
NAT et gestion WAN
Filtrage stateful via RouterOS

Un environnement comme celui-ci peut facilement intégrer :

OSPF pour redistribution interne
BGP pour peering opérateur
MPLS si extension backbone
VRRP pour redondance

L’appliance fanless en rack inférieur suggère un rôle complémentaire : serveur de supervision, IDS/IPS, collecteur NetFlow, ou contrôleur RADIUS. L’ensemble forme une base d’infrastructure performante, structurée et prête pour des usages professionnels.

Cependant, performance et sécurité ne sont pas synonymes.

Les limites d’une approche traditionnelle : Firewall + VPN

Même avec un CCR correctement configuré, une architecture basée uniquement sur :

Un firewall périmétrique classique
Un VPN d’accès distant traditionnel (IPsec, L2TP, SSTP)

reste vulnérable.

Le problème fondamental réside dans le modèle du “Trusted LAN” :

Une fois connecté au VPN, l’utilisateur est considéré comme interne.

Cela implique souvent :

Accès large au réseau
Visibilité latérale excessive
Risque de propagation en cas de compromission

Dans un environnement fibre backbone ou ISP, cette logique est dangereuse. Un poste compromis connecté au VPN peut :

Scanner l’ensemble des sous-réseaux
Exploiter des services internes
Lancer des mouvements latéraux

La surface d’attaque devient interne.

C’est précisément ce que le modèle Zero Trust vise à éliminer.

Pourquoi ZTNA est plus adapté aux environnements modernes

Le Zero Trust Network Access repose sur un principe simple :

Ne jamais faire confiance par défaut, même en interne.

Dans un contexte :

Multi-sites
Télétravail
Backbone fibre
Services critiques internes

ZTNA permet :

Authentification forte par identité
Accès granulaire par ressource
Masquage complet des services internes
Réduction drastique de la surface exposée

L’objectif n’est pas seulement de chiffrer le trafic, mais de contrôler précisément qui accède à quoi.

Implémentation ZTNA sur le MikroTik CCR

1️⃣ Déploiement de WireGuard comme tunnel sécurisé

Le protocole WireGuard est parfaitement adapté :

Cryptographie moderne
Performance élevée
Configuration légère
Surface d’attaque réduite

Création de l’interface :


/interface wireguard add name=wg-ztna listen-port=13231
/ip address add address=10.10.10.1/24 interface=wg-ztna

Ajout d’un peer autorisé :


/interface wireguard peers add interface=wg-ztna \
public-key="CLIENT_PUBLIC_KEY" \
allowed-address=10.10.10.2/32

Sans clé publique enregistrée, aucune connexion n’est possible.
La cryptographie devient le premier niveau de filtrage.

2️⃣ Politique “Deny by Default”

L’erreur classique sur RouterOS est de filtrer partiellement.

Ici, la logique est inverse :

Tout est bloqué.
Seul le strict nécessaire est autorisé.


/ip firewall filter
add chain=input action=accept connection-state=established,related
add chain=input action=accept protocol=udp port=13231 comment="Allow WireGuard"
add chain=input action=drop comment="Drop everything else"

Conséquence :

Winbox inaccessible depuis WAN
SSH fermé
API fermée
Aucun service RouterOS exposé

Le CCR devient invisible aux scans Internet.

3️⃣ Blocage des services exposés

Même en interne, les services sensibles ne doivent pas être accessibles globalement.

Exemple : serveur 192.168.50.10

Autoriser uniquement via tunnel :


/ip firewall filter
add chain=forward action=accept \
src-address=10.10.10.2 \
dst-address=192.168.50.10 \
comment="ZTNA access to file server"

add chain=forward action=drop \
src-address=10.10.10.2 \
comment="Block other LAN access"

Le client ZTNA ne voit qu’une ressource, pas le réseau.

4️⃣ Micro-segmentation via Address Lists

Pour une gestion évolutive :


/ip firewall address-list
add list=ZTNA-ALLOWED address=192.168.50.10

Puis :


/ip firewall filter
add chain=forward action=accept \
src-address=10.10.10.2 \
dst-address-list=ZTNA-ALLOWED

L’accès devient dynamique et centralisé.

5️⃣ Masquage des services internes

Dans ce modèle :

Aucun port RDP exposé
Aucun SSH exposé
Aucun service web public

Les services existent, mais uniquement derrière le tunnel WireGuard.

Un scan Nmap depuis Internet ne révèle rien.

Impact sur la surface d’attaque

Cette architecture :

Neutralise les scans automatisés
Supprime l’exposition directe des services
Empêche les attaques par brute force WAN
Réduit les vecteurs d’intrusion

Dans un environnement fibre backbone, cela protège :

Le cœur CCR
Les sous-réseaux clients
Les services internes critiques
Les équipements d’administration

Extension vers une architecture Zero Trust mature

Intégration MFA via RADIUS

Le CCR peut intégrer User Manager (RADIUS) pour :

Authentification centralisée
Politique par utilisateur
Intégration avec certificats

Ajout possible :

Double facteur
Certificat + identifiant
Attribution dynamique d’IP

Intégration SIEM et NetFlow

RouterOS permet :


/ip traffic-flow set enabled=yes
/ip traffic-flow target add address=192.168.50.20

Cela permet :

Analyse comportementale
Détection d’anomalies
Corrélation via SIEM

Dans un mini-POP ISP, cette visibilité est stratégique.

Vers une architecture hybride cloud

Avec WireGuard :

Interconnexion site-to-site
Extension vers VPS cloud
Segmentation multi-régions

Le CCR devient un point d’ancrage sécurisé dans une architecture hybride.

Conclusion : de la performance brute à la résilience stratégique

L’infrastructure observée — CCR haute performance, fibre backbone, patch panel structuré — constitue une base réseau robuste.

Mais la vraie maturité ne réside pas uniquement dans :

La bande passante
Le nombre de cœurs CPU
Les liens SFP+

Elle réside dans la capacité à :

Réduire la surface d’attaque
Supprimer la confiance implicite
Segmenter par identité
Masquer les services
Contrôler l’accès au niveau granulaire

Transformer un MikroTik Cloud Core Router en passerelle ZTNA ne consiste pas à ajouter un VPN.
C’est repenser l’architecture autour du principe :

L’accès est accordé par identité et par ressource, jamais par position réseau.

Dans un contexte ISP, PME avancée ou backbone fibre, cette approche permet de concilier :

Performance
Sécurité
Évolutivité
Résilience

Et c’est précisément ce type de vision orientée production, réaliste et stratégiquement alignée qui différencie un administrateur réseau d’un architecte infrastructure.

Geekstudy

De l’infrastructure fibre performante au Zero Trust : transformer un MikroTik CCR en passerelle ZTNA de production