Sécurité du compte
La sécurité du serveur protège les sites. La sécurité du compte protège les clés d’accès à ceux-ci. Chaque connexion à Zinn Digital® s’appuie sur un système d’identité unique basé sur des normes — clés d’accès et WebAuthn, authentification à deux facteurs TOTP, connexion par lien magique, SAML SSO pour les équipes d’entreprise et d’agence — avec des rôles granulaires, des clés d’API par organisation et un journal d’audit en ajout seul.
La plupart des comptes d’hébergement se résument à un mot de passe dans une base de données, rattaché à un panneau de configuration. Le nôtre est un système d’identité dédié — Keycloak, prenant en charge OIDC et SAML — qui se place en amont de tout : le tableau de bord client, la console d’administration du personnel, ce site public et la base de connaissances, ainsi que vos tickets d’assistance. Connectez-vous une seule fois et vous serez connecté à l’ensemble de ces services.
Puisqu’elle repose sur des normes ouvertes plutôt que sur une connexion propriétaire, la couche d’identité peut être remplacée de la même manière que n’importe quel autre composant de la plateforme. Aucune partie de votre modèle d’accès n’est enfermée dans le produit d’un fournisseur, et l’authentification de votre équipe ne dépend pas du maintien d’un fournisseur unique de notre part. C’est ce même principe d’absence de verrouillage que nous appliquons aux comptes CDN, au DNS et aux prestataires de paiement.
La connexion est localisée, et le passage du site à l’écran de connexion conserve votre langue — ainsi, une équipe répartie dans plusieurs pays n’est pas contrainte d’utiliser une interface de connexion exclusivement en anglais.
Quatre méthodes, toutes de premier ordre, toutes configurables par personne. Personne n’est contraint d’utiliser l’option la plus faible au motif qu’elle serait la seule disponible.
Saisissez votre adresse e-mail, cliquez sur le lien et vous êtes connecté. Aucun mot de passe susceptible d’être hameçonné, réutilisé ou divulgué lors d’une fuite de données. Il s’agit du parcours par défaut pour les nouveaux comptes, et pour la plupart des utilisateurs, c’est le seul dont ils auront jamais besoin.
Enregistrez une clé d’accès (passkey) — Touch ID, Face ID, Windows Hello ou une clé matérielle comme une YubiKey — et connectez-vous sans aucun mot de passe. Les clés d’accès sont liées à l’origine, de sorte qu’une page de connexion trompeuse ne peut pas en dérober une. La plateforme accepte les authentificateurs ES256 et RS256 et privilégie la vérification de l’utilisateur.
Connectez-vous avec Google via une connexion standard de fournisseur d’identité, afin qu’un compte hérite des contrôles que votre Google Workspace applique déjà. D’autres fournisseurs se connectent de la même manière — il ne s’agit en aucun cas d’une intégration sur mesure.
Conservé pour les personnes et les scripts qui en ont besoin, et soumis à une véritable politique : douze caractères au minimum, jamais votre nom d’utilisateur ni votre adresse e-mail, aucune réutilisation de vos trois derniers, haché avec Argon2. Les adresses e-mail sont vérifiées avant qu’un compte ne devienne utilisable.
Les seconds facteurs font partie du système d’identité, et non d’un module complémentaire que vous achetez ou d’un plugin que vous installez sur votre propre site.
Si votre organisation utilise déjà un fournisseur d’identité — Okta, Entra ID, Google Workspace ou tout autre système prenant en charge SAML —, connectez-le et vos collaborateurs se connecteront à Zinn Digital® avec leurs identifiants d’entreprise habituels. Il n’y a pas de second mot de passe à gérer pour votre équipe, ni de seconde liste de contrôle de départ à oublier.
Cela revêt une importance capitale à l’échelle des agences et des revendeurs, où le roulement du personnel constitue un véritable événement de sécurité. Lorsque quelqu’un quitte l’entreprise et que vous le désactivez dans votre annuaire, vous désactivez également son accès à votre hébergement. L’accès suit la situation professionnelle, de manière centralisée, plutôt que d’être recherché à travers une douzaine d’outils SaaS.
SAML fonctionne aux côtés de tout le reste plutôt que de le remplacer : les prestataires peuvent toujours bénéficier d’un compte avec lien magique au sein d’un rôle délimité, tandis que le personnel permanent se connecte via SSO. Une seule organisation, un seul modèle de permissions, deux portes d’entrée.
L’accès est limité à l’arborescence de l’organisation — du revendeur au client puis au site — et est appliqué directement dans la base de données via la sécurité au niveau des lignes, pas seulement dans l’application. L’accès inter-locataires n’est pas une règle que nous demandons de respecter ; c’est une requête qui ne peut renvoyer aucune ligne. Quatre rôles client couvrent la répartition réaliste des tâches.
Contrôle total de l’organisation et de ses sous-comptes : créez des organisations secondaires, invitez et supprimez des membres, attribuez des rôles, gérez chaque site, effectuez la facturation, gérez les clés d’API et consultez le journal d’audit.
Factures, abonnements, modes de paiement et catalogue des forfaits — et rien d’autre. Votre responsable financier ou comptable peut régler une facture sans jamais avoir la possibilité de modifier, suspendre ou supprimer un site en ligne.
Accès aux sites et à l’API sans gestion de la facturation : visualisez et provisionnez des sites, redémarrez des services, purgez les caches, gérez les clés d’API et les tickets de travail. Délibérément aucun accès aux modes de paiement, à la facturation ou aux changements de forfait.
Lecture seule dans toute l’organisation — sites, facturation, forfaits, tickets, état de la traduction et journal d’audit. Le rôle idéal pour un auditeur, un client souhaitant de la visibilité ou une nouvelle recrue lors de sa première semaine.
Le tableau de bord est une voie d’accès. L’API, la CLI, le fournisseur Terraform et le serveur MCP en sont d’autres — et ils sont soumis au même modèle d’accès, car une clé sans portée définie contourne chaque rôle que vous venez de configurer.
Une clé API est délivrée à une organisation, et non à une personne physique, et possède ses propres portées. Traitez-la comme un identifiant partagé : nommez-la en fonction de son utilisation, attribuez-lui les portées les plus restreintes possibles et renouvelez-la lorsque la personne qui l’a créée quitte ses fonctions.
La clé brute ne vous est présentée qu’une seule fois, lors de sa création. Nous ne conservons qu’un hachage SHA-256 et un court préfixe pour la recherche. Nous ne pouvons plus vous afficher une clé, et une compromission de la base de données ne livre pas d’identifiants exploitables à un attaquant.
Chaque clé comporte des périmètres précis liés au même catalogue d’autorisations que celui utilisé par les rôles, enregistre sa dernière utilisation et peut être révoquée sur-le-champ dès qu’elle semble suspecte. Des clés de sandbox distinctes permettent de tester l’API sans aucune facturation ni provisionnement réel sous-jacent.
Le serveur MCP permet à tout agent compatible MCP de gérer votre hébergement — et il s’authentifie via OAuth 2.1, limité à votre organisation et à ses autorisations RBAC, avec des jetons révocables par outil, une confirmation pour les actions destructrices, des plafonds de dépenses et une journalisation complète des audits. Connecter un assistant IA ne signifie pas lui confier les clés de tout.
Chaque action privilégiée consigne un enregistrement en ajout seul — qui l’a effectuée, ce qui a été fait, sur quoi cela a porté, les preuves à l’appui et l’adresse IP source, avec un horodatage. Il ne s’agit pas d’un outil de débogage pratique ; c’est la piste de preuves.
Non — et nous préférerions que vous ne le fassiez pas. La connexion par lien magique envoyé par e-mail est l’option par défaut, et vous pouvez enregistrer une clé d’accès (Touch ID, Face ID, Windows Hello ou une clé matérielle) et vous connecter sans jamais définir de mot de passe. L’e-mail et le mot de passe restent disponibles en tant que solution de secours, soumis à un minimum de douze caractères, à l’interdiction de réutiliser vos trois derniers mots de passe et au hachage Argon2.
L’authentification à deux facteurs TOTP est intégrée à la couche d’identité et peut être imposée par une politique à l’échelle de l’organisation, plutôt que d’être laissée au choix de chaque membre. Les clés d’accès (passkeys) constituent l’option la plus robuste lorsque les appareils de votre équipe les prennent en charge, car elles suppriment le mot de passe qu’un attaquant tenterait d’obtenir par hameçonnage.
Oui. Le rôle de Gestionnaire de facturation donne accès aux factures, aux abonnements, aux moyens de paiement et au catalogue des forfaits, et à rien d’autre — aucune possibilité d’afficher, de provisionner, de redémarrer, de suspendre ou de supprimer un site. L’inverse est également vrai : le rôle de Développeur gère les sites et l’accès à l’API sans aucun contrôle sur la facturation. Les rôles sont attribués par organisation, de sorte qu’un rôle dans une organisation ne confère aucun accès dans une organisation distincte et non liée — bien qu’un rôle dans une organisation parente s’applique aux organisations imbriquées sous celle-ci.
Révoquez-la depuis le tableau de bord et elle cessera immédiatement de fonctionner. La portée des dommages est limitée par ce que cette clé pouvait faire à l’origine, c’est pourquoi les clés comportent des portées granulaires et enregistrent un horodatage de dernière utilisation — des portées restreintes et un suivi visible de l’utilisation permettent de transformer une fuite en un incident circonscrit plutôt qu’en une compromission totale du compte. Veuillez noter que les clés sont délivrées à l’organisation plutôt qu’à un individu ; traitez-les donc comme des identifiants partagés et renouvelez-les lors des départs de collaborateurs. Seul un hachage de la clé est stocké de notre côté, de sorte qu’une fuite provenant de notre base de données ne produit aucun identifiant exploitable.
Oui. Chaque action privilégiée est consignée dans un journal d’audit accessible uniquement en ajout, avec l’auteur, l’action, la cible, les éléments justificatifs, l’adresse IP source et un horodatage. Les rôles Propriétaire et Lecture seule peuvent le lire directement. Les actions du personnel sur votre compte sont consignées dans la même piste, et les actions sensibles ou destructrices du personnel peuvent d’abord nécessiter une authentification renforcée ou l’approbation de deux personnes.
Oui — SAML SSO est pris en charge pour les comptes d’entreprise et d’agence, de sorte que vos collaborateurs s’authentifient avec leurs identifiants d’entreprise existants et que leur radiation de votre annuaire révoque également leur accès ici. Vous pouvez combiner les approches : SSO pour le personnel permanent, comptes magic-link ciblés pour les prestataires, le tout au sein du même modèle d’autorisations.
Non — les mots de passe ne sont délibérément pas migrés. Votre compte est importé sans mot de passe, et lors de votre première connexion, vous utilisez un lien magique ou définissez un nouveau mot de passe conformément à la politique actuelle. Le portage des anciens hachages de mots de passe introduirait d’anciennes vulnérabilités dans un nouveau système, c’est pourquoi nous ne le faisons pas.
L’essai Footprint-Free dure 14 jours, sans carte requise, et couvre jusqu’à cinq sites. Vous bénéficiez de l’ensemble de la couche d’identité pendant l’essai — les clés d’accès, la double authentification, les rôles, les clés d’API et le journal d’audit ne sont pas réservés à un forfait payant.
Enregistrez une clé d’accès, invitez votre équipe en lui attribuant les rôles appropriés et générez une clé API restreinte — le tout dans le cadre d’un essai de 14 jours sans carte bancaire requise.
Commencer gratuitement