korridor — Sécuriser vos accès sans service tiers

Le pare-feu ne sait rien de vos utilisateurs

Il ouvre des ports à des adresses IP. Quand quelqu'un quitte l'organisation, ses accès doivent être retirés à la main — et ils le sont rarement.

Le reverse-proxy ne sait rien de vos liens

La fibre tombe, la 5G prend le relais, et les tunnels comme les certificats ne s'en aperçoivent qu'après coup.

Le SaaS, lui, sait tout — mais chez un tiers

La valeur est réelle. L'opacité d'un service impossible à auditer et le transit du trafic chez un tiers le sont aussi. Et il s'arrête au réseau : ni votre pare-feu, ni vos liens.

Entre les deux, aucune trace

Qui a changé quoi, quand, et est-ce bien ce qui s'exécute ? Une interface d'administration par site ne répond à aucune de ces trois questions.

01 — Écrire

Le bundle est du YAML relu en revue de code, versionné dans git — ou composé dans le control plane. C'est la même chose pour l'edge : un fichier.

02 — Signer

Signature détachée, clé privée conservée hors de l'hôte. Aucune clé de signature de configuration ni de binaire au bord : l'hôte ne détient que les clés publiques qui les vérifient.

03 — Livrer

Le binaire est lui aussi signé. La bascule est blue-green sous chien de garde : si la nouvelle génération ne devient pas prête, l'ancienne reprend la main toute seule.

04 — Vérifier, puis appliquer

Signature invalide, version qui recule, champ inconnu : rejet, et la dernière configuration valide reste en vigueur. Du pare-feu jusqu'au L7.

Publication web

Servir vos applications et vos sites, sous TLS, sans pile à assembler.

• Reverse-proxy HTTP/1.1, HTTP/2 et HTTP/3
• Certificats TLS émis et renouvelés automatiquement, sans ouvrir le port 80
• Répartition sur plusieurs serveurs, avec coupe-circuit sur ceux qui tombent
• WebSocket, flux d'événements et streaming, sans configuration par route
• Hébergement de sites statiques avec cache mémoire et compression
• Chambre d'attente : file d'admission qui se déclenche seule sur pic ou incident

Sécurité applicative

Filtrer avant que la requête n'atteigne votre application.

• WAF Coraza et règles OWASP, activables et désactivables route par route
• Limitation de débit, en global ou par source
• Filtrage par pays et par listes de réputation, appliqué avant l'authentification
• Détection comportementale d'abus : rafales d'erreurs, balayage, parcours d'identifiants d'objets
• En-têtes de sécurité, CORS et blocage des chemins sensibles
• Collecte des violations de politique de contenu

Identité et contrôle d'accès

Qui atteint quoi, réévalué à chaque requête — le Zero Trust pris au mot, sans confiance accordée au réseau d'origine.

• Politique réévaluée à chaque requête, jamais seulement à la connexion
• Portail de connexion compatible avec votre fournisseur d'identité
• Portail d'enrôlement autonome : code par e-mail, application d'authentification, clés d'accès
• Niveaux de preuve différents selon la ressource demandée
• Jetons de service pour les échanges entre machines
• Certificat client, plages horaires, plages d’adresses, groupes et domaines

Réseau du site

Le point d'entrée tient aussi le L3 et le L4 de la machine.

• Pare-feu nftables entièrement décrit dans la configuration
• Multi-WAN : chaque lien testé à travers lui-même, bascule et retour automatiques
• Haute disponibilité à deux machines, adresse virtuelle reprise en 0,45 seconde
• Proxy TCP et UDP pour SSH, RDP et bases de données
• Approbations et enrôlements répliqués entre machines, sans base de données
• Mise à jour d'une machine par retrait progressif, sans coupure de service

Accès distant

Rejoindre un site ou un réseau interne sans ouvrir un port entrant.

• Un site distant se publie en se connectant vers l'edge, sans ouvrir le moindre port — et c'est le même korridor à l'autre bout, pas un agent séparé
• Postes itinérants sous Linux : le réseau interne passe par l'edge, Internet reste direct — TCP, UDP et ping
• Règles par appareil : services nommés, réseaux et ports, et au besoin une identité prouvée au portail
• Enrôlement d'appareil avec approbation explicite ; retirer un appareil de la configuration coupe aussi son tunnel en cours
• Si un point de présence ne répond pas, l'appareil se connecte au suivant de sa liste
• Une ligne d'audit à l'ouverture et à la fermeture de chaque flux d'appareil
• Passage sans déchiffrement pour les services qui gèrent leur propre TLS
• Adresse réelle du visiteur conservée de bout en bout

Exploitation

Ce qu'il faut pour tenir la machine dans la durée.

• Configuration signée, rechargée à chaud ; une version invalide n'est jamais appliquée
• Mise à jour signée, sans coupure, avec retour arrière automatique
• Métriques Prometheus et journaux JSON exploitables par votre SIEM
• Console locale de diagnostic : trafic, tunnels, cluster, liens, système
• Secrets chiffrés au repos ; un fichier volé seul ne se déchiffre pas
• Aucune base de données ; hors nftables, fourni par le système, aucun logiciel tiers requis

Privilèges séparés

Le processus qui reçoit Internet ne tourne pas en root par défaut : il abandonne tout privilège sauf celui d'écouter sur le port 443, et le forcer en root déclenche un avertissement au démarrage. Ce qui touche le noyau — pare-feu, adresse virtuelle, routage — vit dans un superviseur qui n'a aucune surface réseau publique. Un composant web compromis n'a pas les droits de reconfigurer le réseau.

Aucune clé de configuration au bord

La machine exposée ne détient aucune clé de signature de configuration ni de binaire, seulement les clés publiques qui les vérifient : elle ne peut ni forger une configuration, ni fabriquer une mise à jour, ni émettre une identité fédérée. La seule clé privée qu'elle garde est celle qui signe les certificats des appareils itinérants, chiffrée au repos, et un appareil n'est enrôlé qu'après approbation explicite.

Refus par défaut

La posture sûre est l'absence de configuration. Une route sans politique n'est pas publiée. Un tunnel inconnu est refusé. Un poste sans réseau déclaré n'atteint rien. Un accès oublié reste fermé.

L'identité pilote le réseau

Un enrôlement ouvre un port, son expiration le referme. Quand quelqu'un prouve son identité au portail, la règle de pare-feu suit en quelques millisecondes — sans intégration à écrire entre deux produits.

Vous sortez du SaaS, ou vous ne pouvez plus y entrer

Réglementation NIS2, DORA, HDS ; trafic et journaux qui sortent de chez vous ; boîte noire impossible à auditer. korridor rend la même valeur applicative sur vos machines, avec une configuration que votre auditeur peut lire ligne à ligne.

Vous avez des sites, pas une équipe réseau

Agences, ateliers, laboratoires. Une appliance par site : pare-feu, deux liens Internet, VPN, publication d'applications, portail d'identité — configurée par un fichier signé poussé à distance, et non par une interface web à reprendre site par site.

Vous exposez les applications de vos clients

Hébergeurs et infogéreurs : chaque client se connecte à vos points de présence sans ouvrir un seul port entrant. Les routes et les politiques sont par client, dans un artefact versionné. Un point de présence se remplace sans reconnecter personne.

Vous entretenez une pile assemblée à la main

Un reverse-proxy, un pare-feu applicatif, un proxy d'authentification, un service de tunnel, un client ACME, un démon de bascule : six cycles de vie, six configurations, aucune signée. korridor consolide l'ensemble derrière un artefact unique, sans base de données ni composant tiers à opérer — le pare-feu s'appuie sur nftables, fourni par le système.