Application distribuée, politique centrale, bascule et retour automatiques.
Le moteur qui tourne sur une machine isolée en mode autonome tourne sur vos hubs en mode SASE. Les sites s'y connectent par un overlay chiffré. La politique s'applique à l'entrée. L'identité voyage avec l'utilisateur. La bascule est automatique : la console attend l'expiration d'un seuil de silence configurable, confirme par un contrôle de santé, puis déplace tous les sites en une seule opération.
Quatre formes, un seul overlay. C'est le parc qui décide.
Aucun nouveau protocole à apprendre : le moteur Zedmos que vous connaissez déjà, enveloppé dans un overlay géré qui relie agences, points de sortie cloud et personnes distantes à un plan de politique commun. La forme qu'il prend se choisit sur le canevas — un hub, une paire de hubs, des tunnels directs entre les sites qui en ont besoin, ou chaque site vers chaque site. Quand les deux extrémités d'une paire sont derrière un NAT qui réécrit les ports, un relais dans la pile de la console transporte les paquets sans jamais détenir de clé.
En étoile
Tout aboutit au même endroit. Commencez ici, sauf raison contraire.
Le trafic entre deux sites fait le grand tour — et il est inspecté en chemin.
Double hub
Une panne sur le site du hub ne doit pas emporter les autres sites.
Un second hub à l'écoute, à exploiter. Il ne détient que des routes d'hôtes jusqu'à ce qu'on en ait besoin.
Raccourci entre sites
Deux sites se parlent assez pour que le détour coûte du temps réel.
Le trafic de cette paire cesse de passer par le hub, et cesse donc d'y être inspecté.
Maillage complet
Chaque paire parle à toutes les autres. Plafonné à huit sites.
Chaque site porte un pair pour chaque autre, et un nœud reste l'intermédiaire des paires.
Quand le hub principal cesse de répondre, la console déplace les sites — et les ramène.
Le moniteur de la console surveille le lien d'agent de chaque hub principal. Passé le seuil de silence de la topologie, il déplace tous les sites vers le hub de secours en une seule opération, et les ramène une fois le principal sain pendant une période stable. Vous pouvez aussi déclencher la bascule vous-même, avec un aperçu de ce qui va changer exactement.
Quatre questions sur chaque connexion, pas une seule.
Une clé prouve un appareil, rien de plus. L'accès distant répond ici à quatre choses : qui est la personne, ce qu'elle peut atteindre, si cela reste vrai aujourd'hui, et dans quel état se trouve la machine. Ce sont quatre des cinq promesses que le secteur range sous le ZTNA 2.0 — la cinquième, une politique de données unique qui s'étend jusque dans les locataires SaaS, nous ne la faisons pas : l'inspection est en ligne, donc ce qui passe par le hub est inspecté, et ce qui repose déjà dans un locataire SaaS ne l'est pas.
Qui est la personne
L'enrôlement peut exiger une connexion auprès de votre propre fournisseur avant qu'une clé ne soit générée, avec un facteur multiple exigé via la revendication amr du jeton. L'appareil porte ensuite cette identité, et le hub peut nommer la personne derrière un paquet.
Ce qu'elle peut atteindre
Un groupe d'accès accorde des applications nommées — une adresse et les ports sur lesquels elle répond — plutôt que le réseau où se trouve le service. Le hub écrit une règle par application et par personne et bloque le reste, et il est dit au client de ne router que ce qu'il a le droit d'atteindre.
Si cela reste vrai
Une échéance remet l'appareil en réauthentification, un rappel part, et lorsqu'elle est dépassée l'appareil est coupé au hub jusqu'à ce que la personne se reconnecte. Un annuaire qui signale le compte désactivé fait la même chose, sans attendre l'échéance.
Sur quelle machine elle se trouve
La posture de l'appareil est lue dans le système de gestion que vous exploitez déjà — Microsoft Intune ou CrowdStrike Falcon — et jamais dans un agent à nous. Une machine signalée non conforme est coupée et réadmise d'elle-même dès qu'elle redevient saine ; une machine dont personne ne peut répondre garde son accès, sauf si vous demandez la lecture stricte.
Ce que ce n'est pas : il n'y a ni proxy inverse ni accès limité au navigateur, chacun se connecte donc avec un client WireGuard standard et les autorisations portent sur une application plutôt que sur une URL. Rien ne note les comportements. Le trafic autorisé est tout de même inspecté au hub — prévention d'intrusion, filtrage d'URL, inspection TLS, prévention des fuites de données — c'est justement la partie que la plupart des courtiers d'accès laissent de côté.
Cinq étapes vers un overlay SASE en production
Un orchestrateur durci gère la topologie, la distribution des politiques, la correspondance d'identités et la bascule. Il tourne sur un seul nœud pour les petits déploiements, ou en paire redondante en production.
- Modèle de topologie prêt pour le multi-locataire
- Magasin de données durci avec accès basé sur les rôles
- Source de vérité centrale pour la politique et l'identité
Les nœuds hub hébergent le moteur Zedmos en posture routée, avec une interface chiffrée dédiée. Chaque flux venant d'un site passe au hub par le DPI, la politique, l'inspection TLS et la journalisation.
- Le même moteur que Console — un binaire, un comportement
- DPI et application des politiques en ligne, dès l'entrée
- Les hubs principal et de secours forment une paire actif-passif
Un site peut être un boîtier OPNsense ou pfSense en agence, une petite passerelle Linux, ou un utilisateur distant avec un client WireGuard standard. Les boîtiers s'enregistrent avec un jeton ; les utilisateurs distants s'enrôlent par un lien à usage unique.
- Enregistrement par jeton pour les boîtiers d'agence
- Clients WireGuard standard pour les utilisateurs distants
- Reconnexion et renouvellement de clés automatiques
Les services d'annuaire alimentent le hub en utilisateurs, groupes et appareils reconnus. Chaque flux est étiqueté au moment de l'inspection : la politique peut donc distinguer des personnes, pas seulement des adresses. Une connexion distincte lie une personne distante à l'enrôlement : votre propre fournisseur OpenID Connect, avec une revendication de facteur multiple exigée avant qu'une clé n'existe.
- Active Directory via un agent sur le contrôleur de domaine
- Entra / Azure AD via Microsoft Graph
- Intégration SCIM avec Okta et les fournisseurs d'identité compatibles
- Votre propre fournisseur OpenID Connect pour l'enrôlement, MFA obligatoire
- Santé des appareils depuis Microsoft Intune ou CrowdStrike Falcon
À activer par topologie : la console surveille le lien d'agent du hub principal et, après le seuil de silence et un contrôle de santé, déplace tous les sites vers le hub de secours. Le retour est automatique dès que le principal est redevenu stable.
- Seuil de silence et délai de garde par topologie
- Aperçu avant une bascule manuelle
- Retour automatique vers le hub préféré