Zedmos
Démonstration et tarifs:info@zedmos.comDemander une démonstration

SASE et connectivité sécurisée

Chaque site et chaque utilisateur distant sous une seule politique

Un overlay bâti sur WireGuard et orchestré depuis la console, dans la forme dont le parc a besoin — un hub, une paire de hubs, des tunnels directs entre les sites qui en ont besoin, ou un maillage complet. Les sites se connectent vers l'extérieur, les hubs inspectent, et l'accès appartient à une personne et à une application plutôt qu'à l'adresse que le paquet transporte.

Demander une démonstration
Overlay SASE · une seule politique au huben attente · routes d'hôtes uniquementSitesSiège10.0.1.0/24Agence10.0.2.0/24Entrepôt10.0.3.0/24Personne en télétravailclé par appareilHub principaltermine · inspecte · transmetHub de secoursen attenteprend les sites en charge quand le principal cesse de répondreIdentité · Active Directory · Azure AD · SCIMChaque session rencontreContrôle applicatifIDS / IPSInspection TLSSécurité IA et DLPInternet et SaaSune seule politique pour touttunnel établien attenteOverlay chiffré · WireGuard, OpenVPN ou GRE
Site 1Site 2Site 3Site 4Hub

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.

SecoursSite 1Site 2Site 3Site 4Hub

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.

Site 1Site 2Site 3Site 4Hub

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é.

Site 1Site 2Site 3Site 4Hub

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.

Tunnel établiChemin direct entre deux sitesChemin d'attente — routes d'hôtes seulement jusqu'à la bascule

Construire le réseau, c'est le dessiner

Placez les sites et reliez-les. La console écrit la configuration des deux extrémités de chaque tunnel et la pousse — personne n'ouvre un pare-feu pour taper une règle. Des minutes, pas un après-midi.

Le canevas SASE de la console : les passerelles listées à gauche, des sites et un hub principal placés sur une carte sombre avec des tunnels verts entre eux, et une barre d'outils avec la classe de bascule, la disposition, l'historique et un bouton de redéploiement.

  1. Les passerelles, issues de la flotte

    Les pare-feu que le client possède déjà, listés par site. Faites-en glisser un sur le canevas et il devient un site raccordé ou le hub.

  2. Dans cette forme, un seul hub termine tous les tunnels

    Tout ce qui arrive au hub principal rencontre la même politique : contrôle applicatif, IDS/IPS, inspection TLS, DLP et passerelle IA. Tracez plutôt un tunnel direct entre deux sites et leur trafic est inspecté aux deux extrémités plutôt qu'au milieu — la console le dit avant que vous ne validiez.

  3. Chaque tunnel rend compte de lui-même

    Établi ou non, latence, octets dans chaque sens — sur le lien, là où vous regardez, pas dans un journal qu'il faudrait ouvrir.

  4. La bascule, choisie par topologie

    Savoir si les sites passent automatiquement sur un hub de secours quand le principal cesse de répondre — et après combien de silence — est un réglage du dessin, pas de chaque pare-feu.

  5. Changez le dessin, puis déployez

    Le canevas sait quand il diffère de ce que les pare-feu exécutent. Un seul bouton écrit la configuration des deux extrémités de chaque tunnel et la pousse.

Personne n'ouvre un pare-feu pour taper une règle. Les deux extrémités de chaque tunnel sont écrites par la console et poussées.console.zedmos.com · SASE Network

Transport du tunnel

Choisi une fois pour la topologie.

WireGuard
Recommandé
OpenVPN
Appareils distants pris en charge
GRE
Site à site uniquement

Des personnes, pas seulement des sites

Les utilisateurs distants s'ajoutent de la même façon, avec un lien d'enrôlement à usage unique. L'accès est par appareil : un portable perdu se révoque tout seul.

Garder la flotte à jour

Zedmos publie les versions. Vous décidez quels pare-feu les prennent, et quand.

  1. Zedmos

    Nous publions une version

    Pour la console et pour le pare-feu, selon leurs propres calendriers. La console vous signale qu'une version est disponible au lieu d'attendre que vous regardiez.

  2. Vous

    Vous choisissez qui la prend

    Quelques pare-feu d'abord, puis le reste — ou tout le parc d'un coup. Mettre à jour un petit groupe avant les autres, c'est ce qui permet de trouver un problème tant qu'il est petit.

  3. Vous

    Vous voyez ce qui tourne où

    La version de chaque pare-feu, dans une seule liste. Un équipement en retard l'est pour une raison, et il lui manque tous les correctifs depuis.

Comment un site et une personne sont raccordés

Quatre étapes, et seules les deux premières demandent quelqu'un. Les clés sont générées sur chaque appareil et ne voyagent jamais ; la console ne distribue que la moitié publique.

  1. Vous

    Choisir une forme, et un hub

    Un site devient le hub — d'ordinaire celui qui a une adresse fixe et la place pour inspecter. Tous les autres sites sont des sites raccordés ; rien n'a besoin d'une adresse fixe, sauf le hub. Un second hub, des tunnels directs entre les sites qui en ont besoin, ou un maillage complet sont les trois autres formes, et chacune dit sur sa carte ce que ce choix coûte.

  2. Vous

    Ajouter les sites

    Ajouter un site à la topologie écrit d'un coup la configuration des deux extrémités du tunnel — le site et le changement correspondant sur le hub — pour que les deux ne puissent pas diverger.

  3. Zedmos

    Les sites se connectent vers l'extérieur

    Chaque site établit le tunnel en sortie vers le hub. C'est pour cela qu'une agence sur une ligne grand public à adresse changeante fonctionne sans que personne ne lui ouvre un port.

  4. Zedmos

    Les personnes enrôlent leurs propres appareils, auprès de votre fournisseur

    Une personne distante ouvre un lien à usage unique et, si vous l'exigez, se connecte d'abord à votre propre fournisseur OpenID Connect — un jeton sans revendication de facteur multiple est refusé. Son appareil fabrique sa propre clé et reçoit les applications nommées que ses groupes d'annuaire autorisent, pas un réseau. Une échéance la ramène devant le fournisseur ; perdre un portable révoque cet appareil et laisse les autres fonctionner.

Ce dont la console s'occupe pour vous

Les tunnels que la console provisionne

Clés, adressage et routes sont générés et poussés depuis une seule vue de topologie, dans la forme que vous choisissez : un hub, une paire de hubs, des tunnels directs entre les sites qui en ont besoin, ou un maillage complet jusqu'à huit sites. Ajouter un site, c'est poser un nœud, pas éditer à la main la configuration de deux pare-feu. 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é.

Un second hub, et un moyen de l'atteindre

Déployez un hub de secours et la console peut y déplacer les sites quand le principal cesse de répondre. La bascule s'active à la demande et prend quelques minutes, parce qu'elle attend l'expiration d'un seuil de silence puis confirme par un contrôle de santé, au lieu de réagir à un paquet manqué. Vous pouvez aussi la déclencher vous-même, avec un aperçu de ce qui va changer.

Des personnes distantes, liées à votre propre annuaire

Un lien d'enrôlement à usage unique génère la paire de clés sur l'appareil de la personne — la clé privée n'est jamais vue par la console — et l'enrôlement peut exiger au préalable une connexion auprès de votre propre fournisseur OpenID Connect, en refusant un jeton dépourvu de revendication de facteur multiple. Ce que la personne atteint ensuite est une liste d'applications nommées et de leurs ports, pas un réseau. Une échéance la ramène devant le fournisseur, et la santé de l'appareil vient de l'Intune ou du CrowdStrike que vous exploitez déjà.

Lire en entier

Cette page expose l'argument. Celles-ci disent comment c'est fait en pratique, écran par écran et réglage par réglage.

Manuel d'exploitation SASE

Chaque écran et chaque commande de la section SASE de la console, avec les captures : le canevas, les réglages des nœuds, l'accès privé, les applications d'accès, la posture des appareils, le SD-WAN et le moniteur.

Note d'architecture SASE

Ce qui tourne où : les hubs, les sites, les formes d'overlay, la décision de bascule, et les quatre questions auxquelles répond l'accès privé.

État des versions

Ce qui est livré aujourd'hui, sur quelle plateforme, et ce qui est encore en construction.

Questions et réponses

En quoi consiste Zedmos SASE ?

Un overlay sur WireGuard, OpenVPN ou GRE provisionné depuis la console, dans la forme dont le parc a besoin — en étoile, double hub, raccourcis entre sites ou maillage complet — avec un hub de secours optionnel et une bascule automatique, plus un relais pour les paires derrière un NAT qui réécrit les ports. Les personnes distantes se connectent avec un client WireGuard standard, liées à l'enrôlement à votre propre fournisseur, et tout ce qu'elles envoient est inspecté au hub : contrôle applicatif, IDS/IPS, inspection TLS, DLP et passerelle IA.

Zedmos SASE fait-il passer mon trafic par un cloud éditeur ?

Non. Les hubs sont vos propres pare-feu, sur votre matériel ou sur ZedmOS, et l'inspection a lieu sur le hub que vous exploitez. Rien ne passe par Zedmos.

Les utilisateurs distants ont-ils besoin d'un client Zedmos ?

Non. Les utilisateurs distants se connectent avec un client WireGuard standard. Un lien d'enrôlement à usage unique génère la paire de clés sur l'appareil de l'utilisateur et n'envoie que la moitié publique ; la clé privée n'est jamais vue par la console. Il n'y a pas de licence client par poste.

Que se passe-t-il quand un hub tombe ?

Avec un hub de secours déployé, la console y déplace tous les sites dès que le principal a cessé de répondre : elle attend l'expiration d'un seuil de silence, confirme par un contrôle de santé, puis bascule. La bascule automatique s'active à la demande ; vous pouvez aussi la déclencher vous-même avec un aperçu de ce qui va changer. Les sites sont ramenés une fois le hub préféré redevenu stable.

Quels transports de tunnel sont pris en charge ?

WireGuard pour la plupart des déploiements, OpenVPN là où un parc à base de certificats est déjà la norme, et GRE là où le transport est déjà privé et où vous voulez du routage sans seconde couche de chiffrement. Les trois sont intégrés au moteur.

Comment l'identité d'un utilisateur distant s'applique-t-elle à la politique ?

Les utilisateurs et les groupes viennent d'Active Directory, d'Azure AD ou de SCIM, et la politique les sélectionne par leur nom. Un utilisateur distant en tunnel est identifié dès qu'il se connecte, parce que son adresse lui est attribuée à l'enrôlement.

Démonstration et tarifs: info@zedmos.com

Demander une démonstration