Accès délégué
Invitez un développeur, confiez la facturation à votre comptable, offrez à un client un accès en lecture seule à ses propres sites ou laissez notre équipe de support examiner un problème. Chaque accès est un rôle doté de permissions définies, circonscrit à une organisation, appliqué dans la base de données et consigné dans un journal d'audit non modifiable.
Le partage d'identifiants est la première cause de compromission des accès. Sur Zinn Digital®, chaque personne dispose de sa propre identité, et l'accès repose sur un abonnement — un utilisateur, une organisation et un rôle — que vous pouvez attribuer, modifier ou révoquer de manière indépendante.
Chaque collaborateur se connecte en son nom propre via Keycloak, notre couche d'identité. Personne ne tape votre mot de passe, personne ne partage de session de navigateur, et supprimer quelqu'un se résume à une seule action au lieu d'une rotation de mot de passe et d'une course pour déterminer qui d'autre le connaissait.
Les comptes sont hiérarchiques : une organisation de revendeur contient des organisations clientes, et les organisations clientes contiennent des sites. Une adhésion s'applique à une organisation et à tout ce qui se trouve en dessous, ce qui vous permet de confier à un client en agence le contrôle de sa propre organisation sans jamais exposer vos autres clients.
La séparation des locataires n'est pas un filtre dans le code applicatif qu'un bogue pourrait contourner. La sécurité au niveau des lignes de Postgres limite chaque requête à la sous-arborescence de l'organisation appelante, de sorte qu'une requête en dehors de votre périmètre n'a rien à renvoyer.
Demandez une organisation ou un site hors de votre périmètre et l'API répond par une simple erreur « non trouvé » plutôt que par une erreur de permission. Une erreur de permission confirmerait l'existence de l'enregistrement ; « non trouvé » ne révèle absolument rien à un tiers.
Les permissions sont des clés granulaires (module et action, comme sites.restart ou billing.refund) et les rôles les regroupent. Quatre rôles couvrent les besoins des équipes réelles, et chacun d'eux correspond à des données initiales et non à de la logique intégrée au code.
Contrôle total : création d'organisations enfants, invitation et suppression de membres, modification des rôles, gestion des clés API, création, redémarrage, purge, suspension et suppression de sites, gestion de la facturation et des factures, soumission de tickets et consultation du journal d'audit. Le rôle que vous gardez pour vous.
Affiche l'organisation, ses membres et le catalogue de forfaits, et gère les factures, les modes de paiement et les frais. Aucun accès pour créer, modifier ou supprimer un seul site — exactement le profil qu'un comptable externe devrait avoir.
Consulte et crée des sites, redémarre les services, vide le cache, gère les clés d'API et traite les tickets. Sont délibérément exclus : la facturation, les factures, les modes de paiement, la gestion des membres, la suspension et la suppression de sites. Un prestataire peut concevoir sans pouvoir vous facturer ni rien détruire.
A accès à l'organisation, à ses membres, à ses sites, à sa facturation, au catalogue des abonnements, aux tickets, à l'état des traductions et au journal d'audit, sans pouvoir modifier aucun de ces éléments. Le rôle idéal pour un client en quête de visibilité, un auditeur ou une partie prenante ayant uniquement besoin de consulter.
Déléguer l'accès n'est sûr que si les comptes auxquels vous déléguez sont difficiles à pirater. L'authentification passe par Keycloak pour chaque personne sur le compte, sur toutes les surfaces.
Le travail de support implique parfois de regarder à l'intérieur de votre compte. Cet accès est régi par le même modèle d'autorisation que tout le reste : le personnel fait simplement partie d'une organisation du personnel, répartie en départements dotés de droits d'accès restreints.
Les collaborateurs sont répartis dans les équipes Support, Facturation et Finances, Abus et Confiance-et-Sécurité, Ventes, Intégration, Ingénierie et Opérations, Marketing et Management. Chaque rôle accorde des modules et des actions spécifiques, de sorte qu'un agent ne voit que la partie de la console d'administration requise par son travail et rien d'autre.
Le rôle d'agent du support accorde précisément cela : consulter les clients, consulter et répondre aux tickets, consulter les sites, redémarrer un site et vider son cache. Il n'inclut aucune configuration de facturation, aucun remboursement, aucune modification de forfait et aucune gestion de parc. La correction qu'un agent peut effectuer est limitée par le rôle, et non par de bonnes intentions.
La permission customer.impersonate ne fait pas partie du rôle Manager — elle est exclusivement détenue par le Super Admin. Lorsqu'une session est active en votre nom, le tableau de bord affiche une bannière d'usurpation persistante afin qu'il n'y ait jamais d'ambiguïté sur la personne qui agit.
Chaque action privilégiée et administrative est ajoutée à un journal d'audit en écriture seule qui enregistre l'auteur, l'action, la cible, les métadonnées associées, l'adresse IP et l'horodatage — partitionné par temps en production. Les propriétaires et les membres en lecture seule peuvent consulter eux-mêmes le journal de leur organisation.
Les actions sensibles et destructrices du personnel peuvent nécessiter une authentification renforcée ou une approbation par deux personnes avant d'être exécutées, et les nouveaux départements et rôles relèvent de la configuration plutôt que d'une modification de code.
Les scripts, les pipelines CI, la CLI, le fournisseur Terraform et les agents d'IA s'authentifient tous via le même modèle d'autorisation que les utilisateurs : pas d'identifiants humains partagés, pas de secrets à long terme collés dans une compilation.
Les clés appartiennent à une organisation et possèdent des portées granulaires liées aux mêmes autorisations RBAC (en lecture seule, facturation, provisionnement). Accordez à un pipeline la portée restreinte dont il a besoin plutôt que l'intégralité du compte d'un membre.
Les clés de mode test et de mode production sont distinctes, de sorte qu'une intégration en cours de développement ne peut pas accéder aux données de production par accident ou en raison d'une variable d'environnement copiée.
Nous stockons un hachage SHA-256 du secret et un préfixe de recherche — jamais la clé brute. Vous ne voyez une clé qu'une seule fois, lors de sa création. Chaque clé indique quand elle a été utilisée pour la dernière fois et peut être révoquée individuellement sans perturber quoi que ce soit d'autre.
Notre serveur MCP permet à tout agent compatible MCP de gérer votre hébergement en langage naturel, authentifié avec OAuth 2.1 et limité à votre organisation et à votre rôle RBAC, avec des jetons révocables par outil, une confirmation pour les actions destructrices, des plafonds de dépenses et un journal d'audit complet.
L'accès au compte et l'accès au serveur sont deux problèmes différents. Les identifiants au niveau du site sont gérés dans le tableau de bord, attribués selon le principe du moindre privilège et isolés de sorte que le shell d'un collaborateur correspond au shell d'un seul site.
Un exploitant individuel gère une seule organisation et un unique abonnement de propriétaire, et ajoute un rôle de développeur lorsqu'un prestataire intervient pour un projet. Lorsque le projet se termine, l'adhésion est supprimée et sa connexion cesse de fonctionner immédiatement ; aucun identifiant partagé n'est laissé derrière à renouveler.
Une agence utilise l'arborescence des organisations. Chaque client dispose de sa propre organisation enfant, qui héberge ses sites, et ses propres collaborateurs y obtiennent des adhésions — en lecture seule pour un acteur clé souhaitant de la visibilité, ou en tant que propriétaire pour un client souhaitant un accès en libre-service. Votre personnel détient des adhésions plus haut dans l'arborescence et supervise le portefeuille ; un client ne voit que sa propre branche, et c'est la sécurité au niveau des lignes (Row-Level Security) qui garantit cette réalité plutôt qu'une simple promesse.
Un revendeur fonctionne de la même manière, un niveau plus haut : une organisation de revendeurs détient des organisations clientes, chacune ayant ses propres membres, sa propre vue de facturation et ses propres sites. La même structure fondamentale alimente les sous-comptes, les équipes d'agences et les hiérarchies de revendeurs — il n'existe aucun mécanisme distinct ou amoindri pour aucun d'entre eux.
Tout est disponible dans le cadre de l'essai de 14 jours sans carte bancaire. Inscrivez-vous sans coordonnées de paiement, invitez un collègue, observez ce que chaque rôle peut ou ne peut pas consulter et consultez votre propre journal d'audit.
Aujourd'hui, un abonnement confère son rôle à l'échelle d'une organisation et de tout ce qui se trouve en dessous dans l'arborescence. La méthode pour séparer des ensembles de sites consiste donc à séparer les organisations : placez ces sites dans leur propre organisation enfant et accordez l'abonnement à cet endroit. C'est un modèle propre pour les agences et les revendeurs, où chaque client dispose déjà de sa propre limite. La gestion des ressources par abonnement, qui permet d'associer un unique abonnement à des sites spécifiques au sein d'une même organisation, est une amélioration planifiée et non une fonctionnalité disponible actuellement.
Le rôle de développeur n'inclut ni la suppression ni la suspension de sites — ces prérogatives appartiennent au rôle de propriétaire. Il permet d'afficher et de créer des sites, de redémarrer les services, de vider le cache, de gérer les clés API et de traiter les tickets. Les autorisations de déploiement et de mise en ligne ne font pas non plus partie des attributions du développeur, de sorte que la promotion en production reste du ressort du propriétaire du compte. Associez cela à un environnement de staging pour que les travaux de construction s'effectuent hors du site en direct dès le départ.
Cela dépend entièrement du rôle du personnel, et chaque rôle correspond à un ensemble restreint de clés de permission. Un agent du support, par exemple, peut consulter votre compte et vos sites, consulter et répondre à vos tickets, redémarrer un site et vider son cache, mais ne peut pas toucher à la configuration de la facturation, aux remboursements, aux forfaits ni au parc de serveurs. Se connecter en tant que client est une permission distincte détenue uniquement par le super administrateur, et lorsque cela se produit, le tableau de bord affiche une bannière d'usurpation d'identité persistante. Chaque action privilégiée est enregistrée dans le journal d'audit avec l'auteur, l'action, la cible, l'adresse IP et l'horodatage, et vous pouvez consulter vous-même le journal de votre organisation.
Supprimez l'adhésion et leur accès à cette organisation prend fin : ils conservent leur propre identité, mais n'ont plus aucun rôle et par conséquent aucune permission dans votre compte. Les clés API sont révoquées individuellement, ce qui permet de supprimer une clé de pipeline sans perturber le reste. Si vous utilisez l'authentification unique SAML, la désvisionnement dans votre fournisseur d'identité gère les connexions de manière centralisée. Les identifiants au niveau du site, tels que les clés SSH, sont révoqués dans le tableau de bord, et la suppression elle-même est enregistrée dans le journal d'audit.
Non — mais il convient d'être précis sur les raisons. Les clés API appartiennent à l'organisation, et non à un membre individuel, et elles possèdent leurs propres portées granulaires liées au même catalogue de permissions. Ainsi, plutôt que de confier une clé à une personne, vous créez une clé pour la tâche qu'elle accomplit, avec la portée la plus restreinte dont cette tâche a besoin, et vous révoquez cette clé lorsque la tâche se termine. Seul un hachage du secret est stocké, et chaque clé enregistre sa dernière utilisation afin de faciliter l'identification et la suppression des clés inutilisées.
Oui. Notre serveur MCP authentifie les agents via OAuth 2.1 et les restreint à votre organisation et à votre rôle RBAC, avec des jetons révocables par outil, ce qui vous permet d'accorder une capacité spécifique plutôt qu'un accès global. Les actions destructrices nécessitent une confirmation, des plafonds de dépenses s'appliquent et chaque action est enregistrée dans le même journal d'audit que l'activité humaine.
La sécurité au niveau des lignes de Postgres limite les requêtes au sous-arbre de l'organisation de l'appelant directement dans la base de données, le filtre au niveau de l'application servant de défense en profondeur plutôt que de ligne unique. Les demandes d'enregistrements hors de portée renvoient un résultat introuvable plutôt qu'une erreur de permission, afin de ne rien révéler sur ce qui existe. Côté serveur, l'isolation par site via CageFS restreint le shell et les fichiers de chaque locataire à leur propre site.
Oui. L'essai de 14 jours est sans carte — sans coordonnées de paiement ni engagement — et couvre l'hébergement Footprint-Free Hosting avec jusqu'à cinq sites. C'est suffisant pour inviter un collègue, attribuer un rôle et confirmer que les limites se comportent comme vous le souhaitez avant de vous engager.
Commencez l'essai de 14 jours sans carte bancaire, invitez quelqu'un et observez le modèle de permissions faire son travail : des rôles personnalisables, des périmètres révocables et un journal d'audit qui indique précisément qui a fait quoi.
Commencer gratuitement