SÉCURITÉ ET RÉSILIENCE OPÉRATIONNELLE
Protéger le service. Limiter les impacts. Préserver une voie de reprise. Notre approche relie l’infrastructure, les frontières applicatives et les responsabilités opérationnelles.
Ces principes guident chaque déploiement. Les contrôles, la surveillance, la rétention des sauvegardes et les objectifs de reprise dépendent de l’environnement et des services convenus. Aucune architecture n’élimine toutes les menaces ou les pannes.
01 · DÉFENSE EN PROFONDEUR
Les frontières réseau, la configuration des hôtes, les accès applicatifs et les procédures opérationnelles ont chacun un rôle. Leur examen conjoint évite de considérer un seul contrôle comme une garantie.
02 · TLS À L’ORIGINE
Le site principal webTronex fournit HTTPS à son origine Nginx avec un certificat reconnu publiquement. La gestion DNS et la terminaison TLS sont distinctes. Les connexions internes ont leur propre frontière de confiance; nous n’affirmons pas que chaque saut interne utilise TLS.
03 · ISOLATION DES CHARGES
Le site principal utilise un conteneur applicatif et un conteneur de base de données distinct sur un réseau Docker dédié. L’application s’exécute sans privilèges root et aucun des deux conteneurs n’est privilégié. Les conteneurs partagent le noyau de l’hôte et ne garantissent pas l’isolation entre clients.
04 · MOINDRE PRIVILÈGE
Limiter les comptes, les permissions et les points d’accès au nécessaire. Sur le site principal, les ports applicatifs sont liés à l’interface locale et aucun port de base de données n’est publié sur l’hôte. La révision des rôles et la gestion des identifiants doivent être définies pour chaque déploiement.
05 · REPRISE ET RETOUR ARRIÈRE
Intégrer la reprise à chaque changement : conserver l’état précédent, valider en préproduction, examiner les différences et prévoir un retour arrière. La fréquence des sauvegardes, leur rétention, les essais de restauration et les objectifs de délai et de perte de données doivent être convenus; une licence logicielle ne les inclut pas implicitement.
06 · SURVEILLANCE RESPONSABLE
Les attaques et tentatives d’accès suspectes sont surveillées par les contrôles activés dans l’environnement. Le serveur d’hébergement dispose d’une prévention automatisée active des abus pour les accès SSH. Cette vérification ne démontre pas une détection équivalente des attaques applicatives. La couverture, les alertes et les heures d’intervention dépendent des services convenus; il ne s’agit pas d’une promesse de centre opérationnel de sécurité 24 h sur 24.
Les observations DNS publiques actuelles pour webtronex.ca et www.webtronex.ca correspondent à une livraison DNS uniquement : Cloudflare fournit le DNS faisant autorité et le trafic Web rejoint directement l’origine. Cette observation ponctuelle ne constitue pas un audit de tout le compte.
Résout le nom d’hôte
Le DNS intervient dans la résolution; il ne relaie pas le trafic HTTP dans ce chemin. Ce schéma conceptuel décrit le site principal, pas chaque produit ou environnement client.
L’absence du proxy HTTP Cloudflare dans ce chemin réduit la dépendance à son traitement. Les protections WAF, CDN et DDoS du proxy Cloudflare ne sont donc pas fournies pour ces enregistrements DNS uniquement. La protection de l’origine, sa capacité et la résilience du fournisseur réseau restent essentielles. Le DNS, l’hébergement, la connectivité et les autres fournisseurs demeurent des dépendances.
Le rapport de Cloudflare du 18 novembre 2025 décrit une défaillance de configuration de Bot Management, pas une cyberattaque. Cet incident illustre l’importance des dépendances de livraison. Nous n’avons pas vérifié les relevés de surveillance webTronex ni les réglages DNS et proxy historiques de cette période; nous n’affirmons donc pas que tous les services webTronex sont restés disponibles.
Observations du site principal vérifiées le 15 octobre 2026.
Les attaques et tentatives d’accès suspectes sont surveillées selon la couverture configurée. Tout accès non autorisé, toute perturbation et toute tentative de contourner les contrôles d’accès sont interdits. Les essais de sécurité nécessitent une autorisation écrite préalable et un périmètre convenu.
Signalez une vulnérabilité présumée à notre service de soutien avec une description concise et des détails de reproduction minimaux, sans données sensibles. Ne transmettez ni identifiants ni données clients. Cessez les essais si vous rencontrez des renseignements privés.
Contacter le soutien