Sécurité et accès
Sécurité et contrôle d'accès : des accès que vous pouvez lire sur une grille
Une matrice de rôles par tenant avec 11 catégories d'autorisations, 41 autorisations et une colonne par rôle. Un journal d'audit qui enregistre l'utilisateur et l'adresse IP, des clés API hachées au repos et limitées à un seul tenant, et une isolation des tenants au niveau des lignes dans chaque service.
Essai gratuit de 14 jours · crédit IA gratuit pour essayer l'agent vocal IA · sans carte bancaire
Réponse rapide
Ce que vous obtenez
Tout dans un seul espace de travail
Une matrice de rôles par tenant
11 catégories d'autorisations, 41 autorisations et une colonne par rôle, modifiables par tenant. L'accès est une grille que vous pouvez lire, pas un nom de rôle auquel il faut faire confiance.
Des rôles jusqu'au lecteur des réservations
Administrateur plateforme, administrateur partenaire, administrateur, superviseur, chef d'équipe, agent et lecteur des réservations. Les rôles restreints comptent autant que les rôles étendus.
Emprunt d'identité audité
Les administrateurs plateforme peuvent emprunter l'identité d'un utilisateur pour reproduire un problème, et l'emprunt est inscrit au journal d'audit. Un accès support qui laisse une trace.
Journal d'audit avec adresse IP
Un journal d'audit par tenant qui enregistre l'action, l'utilisateur et l'adresse IP d'origine. Lors d'une revue, la question est : qui, et depuis où ? Les deux sont enregistrés.
Clés API hachées et limitées au tenant
Les clés API sont hachées au repos et limitées à leur tenant. Une fuite de base de données ne livre pas de clés utilisables, et une clé ne peut pas atteindre un autre tenant.
Chiffrement par tenant des secrets de canaux
Les secrets de canaux sont chiffrés par tenant : les identifiants WhatsApp ou opérateur d'un tenant ne sont pas protégés par la même clé que ceux de tous les autres.
Masquage des PII dans les transcriptions
Les données personnelles sont masquées dans les transcriptions : un numéro de carte prononcé pendant un appel ne reste pas en clair dans un enregistrement consultable.
Protection contre l'injection CSV dans les exports
Les exports sont protégés contre l'injection CSV : une valeur malveillante dans un champ de lead ne peut pas devenir une formule qui s'exécute à l'ouverture du fichier.
L'isolation des tenants au niveau des lignes
L'isolation des tenants est appliquée au niveau des lignes dans chaque service, pas filtrée dans l'interface. Un filtre manquant sur un écran ne peut pas exposer les lignes d'un autre tenant.
Périmètre des partenaires
Les administrateurs partenaires ne voient que les tenants qui leur appartiennent. La vue d'un revendeur s'arrête à son propre portefeuille clients.
Limitation des tentatives de connexion
Les tentatives de connexion sont limitées en débit : un contrôle peu coûteux qui rend le credential stuffing sans intérêt.
Réinitialisation et récupération du mot de passe
Les parcours de réinitialisation et de mot de passe oublié sont intégrés : la récupération de compte ne passe pas à la main par la boîte mail de quelqu'un.
Les rôles
Sept rôles, y compris les plus restreints
Chacun d'eux est une colonne que vous pouvez modifier dans la matrice d'autorisations de votre propre tenant.
Administrateur plateforme
Gère la plateforme elle-même. Peut emprunter l'identité d'un utilisateur d'un tenant, et chaque emprunt d'identité est audité.
Administrateur partenaire
Gère un portefeuille de tenants. Ne voit que les tenants qui lui appartiennent, jamais le reste de la plateforme.
Administrateur
Gère un tenant : campagnes, utilisateurs, numéros, intégrations et paramètres.
Superviseur
Pilote le plateau : supervision, files, reporting et vue en direct.
Chef d'équipe
Un superviseur au périmètre réduit, limité à sa propre équipe.
Agent
Reçoit et passe des appels depuis le poste agent. Rien de plus.
Lecteur des réservations
Voit les réservations et rien d'autre. Pour la personne à l'accueil qui ne doit jamais accéder à une campagne.
L'authentification unique est disponible dès aujourd'hui via OIDC ou SAML, avec le provisionnement des utilisateurs par SCIM depuis le propre fournisseur d'identité de chaque entreprise ; l'accès se fait par utilisateur avec des permissions par rôle et des clés API. L'authentification multifacteur est disponible, ainsi qu'une liste d'adresses IP autorisées et la déconnexion après inactivité.
Journal d'audit
Qui l'a fait, et depuis quelle adresse
Le journal d'audit est propre à chaque tenant et enregistre l'action, l'utilisateur qui l'a effectuée et l'adresse IP d'origine. Ce troisième élément est celui qu'on oublie de demander, puis dont on a besoin.
L'emprunt d'identité figure dans le même journal. Un administrateur plateforme peut entrer dans la session d'un utilisateur pour reproduire un problème — c'est ainsi que le support se fait réellement — et le fait qu'il l'ait fait est consigné plutôt que laissé à la mémoire.
- Journal d'audit par tenant avec l'utilisateur et l'adresse IP sur chaque entrée
- L'emprunt d'identité par les administrateurs plateforme est audité
- Les actions correctives et administratives sont consignées dans le même registre
- Limitation des tentatives de connexion, plus parcours de réinitialisation et de mot de passe oublié
Clés et secrets
Hachées au repos, limitées à un seul tenant
Les clés API sont hachées au repos et limitées au tenant qui les a créées. Aucune des deux mesures n'est facultative. Le hachage fait qu'une copie de la base de données n'est pas un jeu d'identifiants utilisables ; la limitation fait qu'une clé qui fuit ne peut pas entrer dans un autre tenant.
Les secrets de canaux bénéficient d'un chiffrement par tenant : les identifiants opérateur ou de messagerie d'un client ne partagent pas leur protection avec le reste de la plateforme. Les transcriptions sont expurgées des PII et les exports sont protégés contre l'injection CSV.
- Clés API hachées au repos et limitées à leur tenant
- Chiffrement par tenant des secrets de canaux
- Masquage des PII dans les transcriptions
- Protection contre l'injection CSV dans les exports
Comment il se compare
| Des rôles comme simples étiquettes figées | Sécurité et accès DialerBee | |
|---|---|---|
| Définition des accès | Trois ou quatre rôles fixes | Une matrice par tenant de 11 catégories d'autorisations, 41 autorisations et une colonne par rôle |
| Accès au support | Quelqu'un emprunte un mot de passe | Emprunt d'identité par les administrateurs plateforme, inscrit au journal d'audit |
| La piste d'audit | Une liste d'actions sans contexte | Journal d'audit par tenant enregistrant l'utilisateur et l'adresse IP |
| Clés API | Stockées pour pouvoir être réaffichées | Hachées au repos et limitées au tenant |
| Séparation des tenants | Un filtre dans l'interface | Isolation des tenants au niveau des lignes dans chaque service |
| Visibilité des revendeurs | Tout ou rien | Les administrateurs partenaires ne voient que les tenants qui leur appartiennent |
Questions fréquentes
Que recouvre Sécurité et accès dans DialerBee ?+
C'est le volet contrôle d'accès de la plateforme : une matrice de rôles par tenant de 11 catégories d'autorisations, 41 autorisations et une colonne par rôle, un journal d'audit enregistrant l'utilisateur et l'adresse IP, des clés API hachées au repos et limitées à leur tenant, un chiffrement par tenant des secrets de canaux, le masquage des PII dans les transcriptions et une isolation des tenants au niveau des lignes dans chaque service.
Quels rôles existent ?+
Administrateur plateforme, administrateur partenaire, administrateur, superviseur, chef d'équipe, agent et lecteur des réservations. Le lecteur des réservations est volontairement restreint : pour quelqu'un qui doit voir les réservations sans jamais accéder à une campagne.
Prenez-vous en charge l'authentification unique (SSO) ?+
L'authentification unique est disponible dès aujourd'hui via OIDC ou SAML, avec le provisionnement des utilisateurs par SCIM depuis le propre fournisseur d'identité de chaque entreprise ; l'accès se fait par utilisateur avec des permissions par rôle et des clés API.
Existe-t-il une authentification à deux facteurs ?+
L'authentification multifacteur est disponible, ainsi qu'une liste d'adresses IP autorisées et la déconnexion après inactivité. La connexion est également protégée par une limitation des tentatives, avec des parcours de réinitialisation et de mot de passe oublié pour la récupération.
Le support peut-il voir mes données ?+
Les administrateurs plateforme peuvent emprunter l'identité d'un utilisateur pour reproduire un problème, et chaque emprunt d'identité est inscrit au journal d'audit avec l'utilisateur et l'adresse IP. L'accès passe par une voie tracée plutôt que par un mot de passe partagé.
Comment les tenants sont-ils isolés les uns des autres ?+
L'isolation des tenants est appliquée au niveau des lignes dans chaque service, pas par un filtre dans l'interface. En outre, les administrateurs partenaires ne voient que les tenants qui leur appartiennent : la vue d'un revendeur s'arrête à son propre portefeuille clients.
Comment les clés API sont-elles stockées ?+
Hachées au repos et limitées au tenant qui les possède. Une clé ne peut pas être relue depuis la plateforme et ne peut pas atteindre les données d'un autre tenant.
Qu'est-ce qui protège les données qui finissent dans un fichier ou une transcription ?+
Les transcriptions sont expurgées des PII : les données personnelles prononcées pendant un appel ne restent pas en clair. Les exports sont protégés contre l'injection CSV : une valeur malveillante dans un champ de lead ne peut pas s'exécuter comme une formule à l'ouverture du fichier.
Parcourez la matrice de rôles et le journal d'audit sur un tenant de démo
Une présentation de 30 minutes sur un tenant de démo, en anglais ou en arabe.