Fondation de la plateforme

RBAC et permissions

Modèle de permissions formel `module.ressource.action`, rôles par tenant, et portée d'accès par LOB — composable plutôt qu'une explosion de rôles.

Pourquoi cela compte pour les acheteurs d'entreprise

Les permissions en BPO sont intrinsèquement multi-dimensionnelles : un superviseur du LOB anglais de ClientA ne devrait jamais voir les données de ClientB. Le RBAC de FrontLine impose cela au niveau de la politique, pour qu'ajouter un nouveau rôle ne nécessite pas d'en dupliquer dix avec des filtres de portée différents.

Comment c'est implémenté

Permissions composables, non un labyrinthe de rôles qui se chevauchent

Chaque permission est une chaîne de la forme `<module>.<ressource>.<action>` (par exemple `recruiting.requisition.create`). Les rôles regroupent des permissions. Les rôles sont toujours portés par un tenant — il n'existe pas de super-admin global. Les liaisons rôle-utilisateur peuvent ajouter une portée client ou LOB spécifique, donc le même rôle attribué deux fois (un par client) donne des accès effectifs différents. Le rôle `client` est restreint aux points d'accès du portail client uniquement.

Capacités

Ce qui est couvert dès le départ

Registre de permissions module.ressource.action (180+ permissions)

Rôles par tenant — aucun super-admin inter-tenant

Liaisons rôle-utilisateur, par client et par LOB

Catalogue de rôles avec valeurs par défaut sensées

Rôles personnalisés créés dans le produit

Décisions d'autorisation journalisées sur chaque refus

Changements de permission capturés dans la piste d'audit

Vue de débogage des permissions effectives par utilisateur

Standards et conformité

Artefacts prêts pour l'audit sur lesquels vos évaluateurs peuvent s'appuyer

SOC 2 Type II — contrôles d'accès logique
ISO/IEC 27001 A.9 contrôle d'accès
Valeurs par défaut au moindre privilège
Rapport trimestriel de révision des rôles pour la conformité

FAQ des achats

Ce que les évaluateurs sécurité et conformité demandent vraiment

Pouvons-nous utiliser nos groupes IdP existants pour piloter les rôles ?+

Oui. SAML et SCIM portent tous deux les revendications de groupe, qui correspondent aux rôles FrontLine via des assertions configurées. Les changements de rôle suivent votre IdP.

Comment empêchez-vous l'escalade de privilèges ?+

Seul Tenant Admin peut attribuer des rôles, et l'attribution de Tenant Admin elle-même est une permission distincte derrière un flux d'approbation. Les tentatives d'escalade sont journalisées.

Un superviseur peut-il être limité à son seul LOB ?+

Oui — les liaisons de rôle acceptent une portée client et LOB optionnelle. Un superviseur sur le LOB anglais de ClientA ne voit que ces agents, horaires et scores QA.

Où pouvons-nous réviser qui a accès à quoi ?+

Le Tableau de bord de conformité expose un rapport d'accès effectif par utilisateur avec expansion complète des rôles et portées, exportable pour les audits.

Présentez ceci à votre équipe sécurité

Nous partageons les aperçus de sécurité, le DDL des politiques RLS, les schémas d'événements d'audit, et l'avancement SOC 2 sur demande. Réservez une revue de sécurité de 30 minutes avec les fondateurs.

Réserver une revue de sécurité Retour à Atlas