Passerelle applicative Zero Trust

Publiez des services internes en toute sécurité, sans les exposer directement à internet.

Que signifie Zero Trust ici ?

La sécurité réseau traditionnelle part du principe que tout ce qui se trouve à l’intérieur de votre réseau peut être considéré comme fiable. Zero Trust inverse ce modèle : aucune requête n’est fiable par défaut, même si elle provient du VPN.

Dans wireguard_webadmin, la passerelle applicative Zero Trust se place devant vos services internes. Chaque requête doit s’authentifier avant d’atteindre l’application, et le service lui-même n’a jamais besoin d’être exposé directement.


Comment une requête circule

1 Le client atteint la passerelle

Le point d'entrée public reçoit la requête à la place du service interne.

2 Validation du navigateur

La preuve de travail Altcha peut bloquer les abus automatisés avant même le début de la connexion.

3 Vérifications d'identité

Les identifiants, le TOTP et la politique d'IP source sont évalués.

4 Transmission vers l'upstream

Seules les requêtes approuvées sont transmises à Grafana, Proxmox ou à une autre application interne.


Méthodes d’authentification

TOTP / 2FA
Mots de passe à usage unique basés sur le temps. Fonctionne avec toute application TOTP : Google Authenticator, Aegis, Authy.
Identifiants locaux
Nom d'utilisateur et mot de passe gérés directement dans wireguard_webadmin. Aucun IdP externe nécessaire.
ACL IP
Autorisez des IP ou sous-réseaux spécifiques. Les pairs VPN peuvent être automatiquement considérés comme fiables via leur adresse de tunnel.
OIDC bientôt disponible
Déléguez l'authentification à Keycloak, Authentik, Google Workspace ou à tout fournisseur compatible OIDC.

Anti brute force : preuve de travail Altcha

Avant même qu’un formulaire de connexion ne s’affiche, le navigateur doit résoudre un léger défi computationnel (Altcha).

Cela ne crée aucune friction pour les vrais utilisateurs, car le matériel moderne le résout en quelques millisecondes, mais cela rend les attaques automatisées de credential stuffing coûteuses à grande échelle.

Protection en couches : Une limitation de débit est déjà en place. La preuve de travail vient la compléter : là où le rate limiting borne le volume de requêtes par IP, Altcha ajoute un coût de calcul par requête qui rend les attaques distribuées coûteuses, quel que soit le nombre d'IP sources impliquées.


Cas d’usage

  • Exposez Grafana à votre équipe sans ouvrir le port 3000 sur internet
  • Publiez une console web Proxmox derrière TOTP, accessible uniquement depuis votre VPN
  • Partagez une application auto-hébergée avec un client à l’aide d’identifiants temporaires
  • Protégez n’importe quel service HTTP interne sans modifier sa configuration

Aucune modification de l'application n'est nécessaire. Le gatekeeper transmet la requête de manière transparente. Votre service interne n'a pas besoin d'implémenter l'authentification : la passerelle s'en charge.


La gestion VPN et la passerelle applicative fonctionnent comme une seule stack auto-hébergée. Aucun compte chez un service tiers, aucune dépendance à un tunnel sortant, aucun trafic qui quitte votre infrastructure.