Sécurité & Transparence technique — SuperDMZ

Flux du trafic :

Chaque nœud public est une machine dédiée dans une région (actuellement São Paulo, Virginie, Francfort et Tokyo). Toute la communication client-nœud transite par TLS 1.2/1.3.

• Le contenu de la requête (URL, headers, body) existe en RAM sur le nœud le temps nécessaire pour le transmettre à votre client (typiquement millisecondes).
• Ce contenu n'est jamais écrit sur disque, jamais indexé, jamais loggué en clair. Les logs d'accès (nginx) ne contiennent que des métadonnées opérationnelles : timestamp, méthode HTTP, path, status, bytes entrée/sortie, temps de réponse, IP source.
• Cookies, headers d'auth (Authorization, Cookie) et body POST n'apparaissent jamais dans les logs.
• Les tokens internes SuperDMZ (utilisés par le client pour s'authentifier au nœud) sont masqués automatiquement avant tout logging.

Implication honnête : techniquement, un opérateur malveillant avec root sur le nœud pourrait intercepter le contenu en RAM pendant qu'il est transmis. Cela vaut pour tout service de tunnel inverse avec TLS terminé en bordure (ngrok, Cloudflare Tunnel, localtunnel). Pour les scénarios où c'est inacceptable (PCI-DSS, santé, secrets d'entreprise), nous recommandons le mode TCP décrit ci-dessous.

• SSH, RDP, MySQL et tout protocole TCP qui transporte sa propre cryptographie (y compris TLS effectué par votre propre service) atteint la destination chiffré de bout en bout.
• SuperDMZ ne voit que : ports source/destination, comptage d'octets, timestamps de début/fin de connexion.
• C'est le mode recommandé pour toute charge régulée (santé, finance, secrets industriels) et pour les administrateurs IT qui ont besoin d'accéder à des machines internes sans confier la clé à aucun maillon de la chaîne.

• Body de requête ou de réponse.
• Headers Authorization, Cookie, Set-Cookie, X-Auth-Token et variantes connues.
• Query strings sensibles (clés d'API passées via URL — déconseillé, mais masquées avant log si présentes).
• Tokens internes SuperDMZ échangés entre client et nœud (masqués via filtre de log avant tout fichier).
• Contenu des tunnels TCP, peu importe leur nature.

Rétention logs nginx : 14 jours. Logs d'audit du panneau (login, CRUD tunnel) : 90 jours. Détails dans la Politique de confidentialité.

• SSH avec auth par mot de passe uniquement pour un utilisateur non privilégié. Login root via SSH désactivé sur tous les nœuds.
• Firewall (UFW) avec whitelist minimale : 22/tcp (SSH), 80/tcp (redirect HTTP→HTTPS + Let's Encrypt), 443/tcp (HTTPS public + WebSocket clients).
• fail2ban avec bans progressifs sur tentatives de force brute SSH et panneau admin.
• Mises à jour de sécurité automatiques (unattended-upgrades).
• Résolveur DNS figé à 1.1.1.1 / 1.0.0.1 (Cloudflare) + 9.9.9.9 (Quad9). /etc/resolv.conf avec flag chattr +i.
• Panneau admin sur path non évident, protégé par rate-limit, 2FA, CSRF sur chaque POST et IP-ban automatique.
• Secrets sensibles (clé Stripe, mot de passe SMTP, token GoDaddy) chiffrés au repos en base avec clé hors versionnement.

Le failover est aujourd'hui manuel. Si un nœud tombe, la procédure est de repointer l'enregistrement A du nœud sur Cloudflare vers une autre IP saine (changement DNS avec TTL 60s) — les clients se reconnectent automatiquement dès que le DNS est mis à jour. Temps typique de détection + action : 5 à 30 minutes selon l'heure.

Nous ne vendons pas de SLA contractuel. Le plan Business inclut un support prioritaire (réponse initiale sous 4h ouvrées) — pas de crédit de downtime garanti. Promettre un SLA exige un historique mesuré, et nous collectons encore ces données avant de publier un chiffre défendable. Même posture que sur les audits externes : transparence radicale plutôt que vendre des promesses que nous ne pouvons tenir.

Status public en temps réel : superdmz.com/status — affiche l'état de chaque nœud (online/offline) et les incidents récents, avec rafraîchissement automatique chaque minute.

Roadmap de disponibilité : failover automatique via health-check + réécriture DNS par l'API Cloudflare ; historique d'uptime mois par mois sur la status page ; publication du SLA une fois 6 mois de données consistantes accumulées.

• Mots de passe stockés en hash bcrypt avec cost factor recommandé par l'industrie. Jamais en clair, même pas en log d'erreur.
• 2FA actuellement disponible : code à 6 chiffres par e-mail (opt-in, par utilisateur).
• Roadmap proche : 2FA via TOTP (Google Authenticator, Authy, Aegis) et Passkeys/WebAuthn — voir "Roadmap de sécurité" ci-dessous.
• Changement d'e-mail principal exige code sur le nouveau + alerte sur l'ancien avec lien "bloquer le compte maintenant" (fenêtre de 7 jours).
• Suppression de compte avec fenêtre de récupération de 48h par lien e-mail avant la purge définitive.

• 2FA TOTP (RFC 6238) : setup par QR code, backup codes, e-mail en fallback recovery.
• Passkeys / WebAuthn : authentification sans mot de passe résistante au phishing, alignée FIDO2.
• HTTPS passthrough (SNI routing) : TLS sans terminaison à l'edge SuperDMZ (BYO certificate).
• Client open-source : code du client Go publié pour audit.
• Changelog de sécurité public : CVE internes et fixes documentés sur /changelog.
• Self-host complet des assets : retirer les dépendances CDN restantes (polices, icônes, Tailwind) en servant tout depuis notre domaine.

Pas de SLA public pour l'instant. Cette section sera mise à jour à mesure que chaque item arrive en prod.

• Canal préféré : [email protected]
• Contact technique équivalent : [email protected]
• Contact opérationnel : [email protected]
• Fichier RFC 9116 : /.well-known/security.txt

Ce que nous demandons : n'exploitez pas au-delà du nécessaire pour confirmer la vulnérabilité, n'accédez pas aux données d'autres utilisateurs, et donnez-nous une fenêtre raisonnable pour corriger avant divulgation publique. En retour : réponse initiale sous 5 jours ouvrés, crédit public (si souhaité) et mois gratuits de plan payant en remerciement — proportionnel à la sévérité.