ZTXGate vs Firezone
ZTXGate et Firezone fournissent tous deux un accès aux ressources privées piloté par politique et utilisent WireGuard. La différence principale est opérationnelle : le produit Firezone pris en charge utilise un plan de contrôle géré par Firezone, tandis que ZTXGate peut fonctionner avec son environnement de contrôle d'accès exploité par le client ou un MSP sans plan de contrôle cloud CoreZT obligatoire.
En bref
| Domaine | ZTXGate | Firezone |
|---|---|---|
| Plan de contrôle | Exploité par client/MSP | Entièrement géré par Firezone dans le service pris en charge |
| Composants de données côté client | Passerelle/proxy ZTXGate | Clients et Gateways Firezone ; Relays si nécessaire |
| Couche d'accès | WireGuard + proxy HTTP/HTTPS sans client sous licence | Accès Layer 3 via Clients/Gateways |
| Politique de ressources | Oui | Oui |
| Confiance appareil | Enrôlement + posture MDM/EDR | Certificat/attestation cryptographique |
| Posture générale | Via intégrations listées | La documentation distingue attestation et posture OS/malware/conformité MDM |
| Plan de contrôle auto-hébergé | Modèle principal | Source disponible, mais plan pris en charge non conçu pour l'auto-hébergement |
| Mode autonome air-gapped | Pris en charge | Pas le modèle de service pris en charge documenté |
| Résilience | Sauvegarde/restauration, pas de HA conventionnelle | Plan de contrôle géré par le fournisseur ; plan de données client |
Exploitation du plan de contrôle
Firezone documente une séparation plan de contrôle/plan de données. Portail d'administration, API de contrôle et moteur de politique sont gérés par Firezone dans le produit pris en charge. Le code source est disponible, mais Firezone indique ne pas fournir support ou documentation pour un plan de contrôle auto-hébergé.
ZTXGate adopte un autre modèle : son déploiement est exploité par le client ou un MSP et l'accès principal ne nécessite pas de plan de contrôle hébergé par CoreZT. ZTXHub optionnel peut centraliser licences et mises à jour dans les environnements connectés.
Plan de données et WireGuard
Clients, Gateways et Relays Firezone forment le plan de données et protègent les ressources IP au Layer 3. ZTXGate utilise WireGuard via sa passerelle et propose également un parcours HTTP/HTTPS sans client. Dans les deux architectures, WireGuard assure le transport ; identité, politique et définition des ressources viennent du produit environnant.
Accès aux ressources
Les deux produits utilisent des ressources et politiques explicites. ZTXGate peut prendre en compte identité, appareil, posture, rôle, heure, approbation et autres conditions configurées.
Confiance appareil : modèles différents
Le Device Trust Firezone se concentre sur l'attestation cryptographique de l'appareil au moyen d'un certificat X.509 émis par un MDM ou une PKI et la preuve de possession de la clé privée. Firezone distingue explicitement cette fonction de l'évaluation générale de posture comme version d'OS, chiffrement disque, protection antimalware ou conformité MDM.
ZTXGate enrôle individuellement les appareils et peut intégrer la posture de Microsoft Intune, Microsoft Defender for Endpoint, SentinelOne Singularity, CrowdStrike et Jamf. Attestation de certificat et posture MDM/EDR dynamique répondent à des besoins différents.
Accès sans client
ZTXGate offre un proxy HTTP/HTTPS sous licence pour les applications web prises en charge. La documentation Firezone examinée décrit l'accès via Clients et Gateways ; nous n'y avons pas trouvé un proxy navigateur HTTP/HTTPS équivalent pour l'accès utilisateur final. Ce point doit être revérifié lors de futures mises à jour de la comparaison.
Auto-hébergement et open source
Open source ne signifie pas nécessairement plan de contrôle auto-hébergé pris en charge. Firezone publie son source tout en supportant son plan de contrôle géré. ZTXGate n'est pas open source ; c'est un logiciel commercial conçu pour une infrastructure exploitée par le client ou un MSP.
Fonctionnement déconnecté et air-gapped
ZTXGate peut fonctionner de façon autonome et totalement air-gapped avec licences et mises à jour manuelles. ZTXBAS intégré sous licence reste disponible pour une authentification biométrique résistante au phishing. L'architecture Firezone prise en charge dépend de son plan de contrôle géré ; le fonctionnement durablement déconnecté n'est pas le modèle standard documenté.
Disponibilité et reprise
Firezone exploite son plan de contrôle comme infrastructure cloud et conçoit les composants de données pour tolérer temporairement une partition du contrôle pour le trafic existant. ZTXGate utilise aujourd'hui un modèle DR sauvegarde/restauration plutôt qu'un cluster actif/actif ou actif/passif conventionnel. Les exigences de basculement automatique doivent être comparées explicitement.
Choix d'architecture
Firezone peut convenir lorsqu'un plan de contrôle fournisseur, l'open source, l'attestation par certificat et l'accès Layer 3 via client/gateway sont recherchés. ZTXGate peut être pertinent si l'exploitation client/MSP, le mode air-gapped permanent, la posture MDM/EDR dynamique, l'accès HTTP/HTTPS sans client ou ZTXBAS intégré sont nécessaires. Il ne s'agit pas d'un classement général mais d'une comparaison d'architectures.