FAQ
Une question par bloc, le fait avant l’explication. AtriShield est une protection applicative installée en bordure de votre serveur (HAProxy, CrowdSec, inspection AppSec), pilotée par une console. Les réponses ci-dessous décrivent ce qui est livré aujourd’hui ; les évolutions sont signalées comme telles.
Le filtrage s’exécute sur votre serveur, à l’entrée, avant votre application. Le trafic passe par HAProxy en terminaison TLS, puis par l’inspection AppSec et CrowdSec. Une requête bloquée n’atteint jamais PHP. Aucune requête n’est envoyée à un service externe pour obtenir un verdict : la décision est locale.
Non. AtriShield s’installe sur votre serveur, à l’entrée, devant l’application. Il ne remplace pas un CDN et n’en exige pas. Vous gardez votre hébergeur et votre chaîne réseau actuels ; l’inspection s’ajoute en bordure, sans détour par un tiers pour obtenir un verdict.
La requête est arrêtée à l’entrée et n’atteint pas votre application. L’IP source est bannie automatiquement, pour une durée par défaut de 4 heures, 24 heures pour les scanners, sans limite pour les exploits, selon les profils. L’événement est remonté à la console : IP source, URI et query string.
Oui. L’inspection couvre l’URL et le corps des requêtes POST, à la recherche d’injections SQL et de XSS. La charge est analysée sur votre serveur, avant l’application. Rien n’est transmis à un service externe pour l’analyse : le verdict est rendu localement, à l’entrée du serveur.
Les robots légitimes sont reconnus par origine : 2 194 plages d’adresses de Google, Bing, Apple et DuckDuckGo sont vérifiées. Les passerelles de paiement à IP publiées disposent de préréglages de confiance. Les autres robots se classent depuis la console ; sans IP stable, on s’appuie sur la signature applicative, jamais sur une plage devinée.
La mesure de latence est en cours de publication ; nous ne communiquons pas de chiffre tant qu’il n’est pas documenté. Par conception, la décision est rendue sur votre serveur, à l’entrée, sans appel à un service externe pour obtenir un verdict : aucun aller-retour réseau vers un tiers n’est ajouté.
AtriShield fonctionne sur Debian 11 et 13 et protège l’entrée du serveur quel que soit l’applicatif derrière : Magento, WordPress, API maison, serveur Linux. Le mode d’installation s’adapte à la façon dont le serveur reçoit le trafic : assisté, intégré (nginx/Apache) ou autonome, détecté automatiquement.
Debian 11 ou 13, un accès root, une sortie HTTPS vers votre console et un jeton d’enrôlement. L’agent s’installe en paquet Debian ; HAProxy, le moteur de détection et WireGuard sont tirés automatiquement par apt. Une licence par serveur. Aucun accès distant n’est ouvert vers votre machine.
L’agent s’installe en paquet Debian (apt tire HAProxy, le moteur et WireGuard), puis une seule commande d’enrôlement relie la machine à la console et récupère la configuration signée : l’auto-installeur met tout en place en moins de deux minutes. Vous passez ensuite en mode observation avant d’activer le blocage.
Non. AtriShield se place à l’entrée du serveur, devant l’application ; vous ne touchez ni au code ni aux gabarits de votre site. Le mode d’installation s’adapte à votre point d’entrée (assisté, intégré à nginx/Apache, ou autonome). Vous conservez votre hébergeur ; l’inspection s’ajoute en bordure, sans redéploiement.
Oui. À l’enrôlement, l’option `--install-mode` accepte trois valeurs — assisté, intégré, autonome — détectées automatiquement si elle est omise, selon la façon dont le serveur reçoit le trafic. Le mode intégré se place avec votre nginx ou Apache existant ; le port applicatif se précise avec `--backend-port`.
Le mode observation est actif par défaut avant tout blocage : vous voyez ce qui serait bloqué avant d’agir. Vous pouvez simuler les règles, puis activer la protection une fois l’impact validé. Les IP de confiance et les robots légitimes, vérifiés par origine, passent sans être arrêtés.
Les passerelles de paiement à IP publiées — Stripe, PayPal, Klarna, Postmark — disposent de préréglages d’IP de confiance, laissés passer à l’entrée. Quand un service n’a pas d’IP stable, on s’appuie sur la signature applicative plutôt que de deviner une plage. Vous validez le comportement en mode observation.
Des préréglages d’IP de confiance existent pour les passerelles de paiement et les services dont les IP sont publiées. Vous les gérez depuis la console. Pour un service sans IP stable, aucune plage n’est devinée : on s’appuie sur la signature applicative. Le mode observation permet de vérifier avant activation.
Oui. Les robots des moteurs légitimes sont reconnus par origine : 2 194 plages d’adresses de Google, Bing, Apple et DuckDuckGo sont vérifiées et laissées passer. Les autres robots se classent depuis la console. Cela écarte les robots qui se font passer pour un moteur sans pénaliser votre référencement.
C’est le comportement par défaut avant blocage. Chaque requête est évaluée et journalisée sans être arrêtée : vous voyez l’impact réel sur votre trafic. Vous pouvez aussi simuler des règles. Une fois l’impact validé, vous activez la protection depuis la console, par mode et par profil.
Si le composant d’inspection s’arrête, le serveur refuse les requêtes (503) plutôt que de les laisser passer sans contrôle. Il redémarre seul en quelques secondes, et la console affiche l’état. Le choix est volontaire : en cas de doute, on ferme la porte plutôt que de l’ouvrir.
La protection continue de fonctionner sur votre serveur : la configuration signée déjà en place reste active. La console sert à piloter et à superviser, pas à rendre les verdicts. Les décisions et l’inspection restent locales, à l’entrée du serveur, indépendamment du lien avec la console.
Les mises à jour de configuration sont signées (Ed25519) et récupérées automatiquement toutes les heures depuis la console. Chaque paquet est vérifié avant d’être appliqué ; toute source non signée est rejetée. En cas d’échec de vérification, un retour arrière automatique rétablit la configuration précédente.
Oui. Les configurations sensibles suivent un schéma : sauvegarde, validation à blanc, application atomique, vérification de santé, puis restauration automatique si la vérification échoue. Une configuration qui ne passe pas la validation n’est jamais appliquée. L’état est visible depuis la console.
La console reçoit l’état des services, l’inventaire des paquets et des compteurs. Pour chaque requête bloquée, elle reçoit l’IP source, l’URI et la query string telles que reçues. Aucun log de trafic complet n’est récupéré. Le masquage de ces champs est une évolution annoncée, sans date promise.
La console est actuellement hébergée chez un hébergeur cloud. Une migration vers OVH Beauharnois, au Québec, est en cours ; nous ne communiquons pas de date. L’agent communique avec la console par un tunnel chiffré sortant ; aucune donnée de trafic complète ne transite par ce lien.
Personne, côté Atrilya, n’a d’accès distant à votre serveur. La communication agent-console se fait dans un tunnel chiffré, à l’initiative de l’agent ; aucun canal d’administration distant n’est ouvert vers votre machine. Les rares opérations privilégiées locales passent par des droits bornés.
Le principal tiers impliqué est l’hébergeur de la console : aujourd’hui un hébergeur cloud, avec une migration en cours vers OVH Beauharnois (Québec), sans date communiquée. L’inspection et les décisions restent sur votre serveur. La liste et le détail figurent dans la documentation fournie pour votre évaluation.
La procédure de fin de contrat est en cours de documentation. L’agent s’installe et se retire comme un paquet Debian standard ; la configuration et le registre d’incidents résident sur votre serveur. Le détail de la restitution et de la suppression est précisé dans la documentation fournie pour votre évaluation.
Un accord de traitement des données (DPA) est fourni sur demande, avant signature. Il précise les rôles, les données concernées — état des services, inventaire, et pour chaque requête bloquée l’IP, l’URI et la query string — ainsi que l’hébergement de la console. Il est remis pour votre évaluation.
AtriShield n’est pas une attestation PCI. Une documentation est fournie pour votre QSA : filtrage à l’entrée, inspection des injections, registre d’incidents. Elle sert à votre évaluation et ne remplace pas votre démarche de conformité, qui reste de votre ressort et de celui de votre QSA.
AtriShield s’adresse aux agences web, aux hébergeurs et aux infogéreurs, ainsi qu’aux boutiques disposant d’une infogérance. Il protège l’entrée du serveur, avant l’application, pour des sites exposés : Magento, WordPress, API ou serveur Linux. La licence est attribuée par serveur protégé.
La licence est attribuée par serveur protégé. Chaque serveur enrôlé dispose de sa configuration signée et apparaît dans la console. Les modalités et la grille ne sont pas publiées : elles sont communiquées sur demande, dans le cadre du programme pilote. Les paliers sont présentés sans prix.
AtriShield est proposé dans le cadre d’un programme pilote : un premier serveur est installé en conditions réelles, d’abord en mode observation, pour mesurer l’impact avant blocage. Les conditions et la grille tarifaire sont communiquées à l’adhésion. L’objectif est de valider l’ajustement sur votre infrastructure.
Les paliers se distinguent par le niveau de durcissement et les profils appliqués à l’entrée. Le filtrage se règle par mode du serveur, palier et profils de durcissement, pas par interrupteur règle par règle. Le détail figure dans la documentation ; les prix ne sont pas publiés.
Une démonstration se demande via le formulaire de contact ou par courriel. Un échange technique précède l’installation d’un premier serveur en mode pilote, en observation. Les modalités sont communiquées à l’adhésion. La démonstration porte sur la console et le comportement du filtrage à l’entrée du serveur.
Une question qui n’est pas couverte ici ? Écrivez-nous : un ingénieur Atrilya vous répond.
Écrire à Atrilya