Sécurité par conception.
Roster s'exécute dans votre infrastructure et interroge les annuaires auxquels vous faites déjà confiance.
Les données d'annuaire, la configuration de la plateforme et les enregistrements d'exploitation restent dans les systèmes que vous contrôlez. Roster ne les réplique pas vers un cloud opéré par Advantys.
Auto-hébergéAucune télémétrie d'usageIdentifiants gérés par le clientVérification locale de la licence
Le modèle en une phrase
Roster est auto-hébergé et ne communique aucune donnée vers l'extérieur.
Il lit les données d'annuaire sélectionnées, résout qui doit agir à l'aide du fournisseur de modèle que vous configurez, et stocke les données d'exploitation dans votre déploiement.
Aucun cloud opéré par Roster ne conserve vos enregistrements d'annuaire, votre historique de résolution ou votre configuration. Lorsque vous sélectionnez un fournisseur de modèle externe, les données envoyées à ce fournisseur sont régies par votre configuration et votre accord avec ce fournisseur.
Résidence et isolation des données
Choisissez la forme de déploiement adaptée à votre infrastructure — Roster conserve ses données là où vous les placez.
Auto-hébergé, toujours
Exécutez Roster comme un conteneur autonome avec SQLite embarqué, ou déployez Roster Enterprise sur plusieurs instances adossées à PostgreSQL. Sur site, cloud privé ou compte de cloud public — votre choix, votre infrastructure.
Vos données restent sous votre contrôle
Avec SQLite, les données de Roster résident dans un stockage /data durable rattaché à votre déploiement. Les déploiements Enterprise peuvent stocker les données applicatives dans une infrastructure PostgreSQL contrôlée par votre organisation. Rien n'est répliqué vers un service de données opéré par Advantys.
Pas d'appel sortant
Roster ne transmet ni télémétrie d'usage, ni données d'annuaire, ni historique de résolution à Advantys. La capacité sous licence est comptée localement. Les clés de licence payante sont vérifiées localement à l'aide du trousseau public de confiance inclus dans l'image de production.
Compatible air-gap
Roster peut s'exécuter sans accès à l'Internet public dès lors que les points d'accès requis pour l'annuaire, l'identité, la base de données et le modèle sont disponibles à l'intérieur de l'environnement contrôlé.
Authentification et contrôle d'accès
SSO via votre IdP, clés à portée réduite et gestion de la propriété par rôles — pas de comptes d'administrateur partagés.
SSO via votre fournisseur d'identité
Les utilisateurs humains s'authentifient via Microsoft Entra ID, Google, Okta, OAuth/OIDC générique ou SAML.
Clés à portée et privilège minimal
Les clés API portent des portées REST et MCP explicites. L'accès effectif est l'intersection des portées de la clé, des droits du propriétaire et des règles de ressource — une portée ne peut jamais élever une identité au-delà de ses permissions.
Authentifié par défaut
L'accès MCP prend en charge les clés API, OAuth, ou les deux. La production refuse un mode MCP explicitement non authentifié. Une nouvelle base de données de production exige un mot de passe d'administrateur d'amorçage fort et propre au déploiement.
Rôles et propriété
Administrateurs, propriétaires de projet et membres ont des responsabilités distinctes. Les propriétaires de projet gèrent leurs projets, participants et délégations sans accès administratif à l'échelle de la plateforme.
Identités dédiées
Les utilisateurs humains, les agents IA et les comptes de service peuvent utiliser des identités Roster distinctes, avec des identifiants dont la portée et la révocation sont indépendantes.
Audit et observabilité
Un historique explicable pour chaque décision — attribuable et conservé selon vos règles.
Événements d'audit Enterprise
Événements d'audit durables pour l'authentification, les identifiants, les identités, les projets, les participants, les délégations, les connecteurs et les paramètres de la plateforme. Des identifiants stables d'acteur, de ressource, de propriétaire, de principal effectif et d'identifiant rendent l'historique attribuable.
Observabilité des exécutions de modèle
Chaque résolution enregistre son fournisseur, son modèle, ses jetons, son coût et sa latence — aucune décision opaque.
Métadonnées contrôlées
Les administrateurs peuvent minimiser les adresses IP, les agents utilisateurs et les métadonnées à caractère personnel enregistrées avec les données d'exploitation.
Rétention configurable
Paramètres de rétention indépendants pour les événements d'audit, les requêtes de résolution, les exécutions de modèle et les journaux de processus — fixez les fenêtres qui correspondent à votre politique.
Export de télémétrie OTLP
Les déploiements Enterprise peuvent exporter traces, métriques et journaux via OTLP vers la pile d'observabilité que vous exploitez déjà. La télémétrie est optionnelle, dirigée par le client et n'est jamais acheminée vers Advantys.
Tableau de bord de santé système
Une vue d'exploitation intégrée expose la readiness, l'activité des workers, l'état des connecteurs et les signaux de réplication, afin que votre équipe d'astreinte vérifie le déploiement sans quitter Roster.
Confidentialité et minimisation des données
Contrôles PII au niveau du champ, appliqués à l'écriture — pas seulement à l'affichage.
Minimisation à l'écriture
Quand la rétention d'un champ est désactivée, les nouveaux enregistrements ne stockent tout simplement pas ce champ. Le contrôle s'applique à la création, pas seulement à l'affichage.
Contrôles PII au niveau du champ
Choisissez les champs personnels conservés dans les résultats de résolution, les réponses stockées, les métadonnées d'audit, les diagnostics de modèle et les journaux de processus.
Politique de réponse cohérente
La même politique de champs s'applique aux résultats de résolution stockés et aux réponses correspondantes de la plateforme, de l'API REST et de MCP.
Support de l'effacement
Des procédures d'effacement documentées couvrent les enregistrements sources, les réponses stockées, les métadonnées d'audit, les diagnostics et les journaux, pour les demandes de suppression.
Identifiants durables
L'historique d'audit peut conserver des identifiants stables et des métadonnées de sécurité sans retenir de données personnelles superflues.
Sécurité de la base de données
SQLite pour l'autonome, PostgreSQL pour Enterprise — avec séparation des rôles et contrôles de connexion.
SQLite pour l'autonome
Une seule instance Roster avec stockage /data durable. Créez des sauvegardes en ligne cohérentes via le processus de sauvegarde SQLite pris en charge par Roster, plutôt qu'en copiant indépendamment les fichiers de base et WAL.
PostgreSQL pour Enterprise
Les déploiements Enterprise peuvent utiliser PostgreSQL avec une ou plusieurs instances Roster. Utilisez le mode TLS requis par votre fournisseur de base de données pour toute connexion PostgreSQL.
Rôles de base de données distincts
Rôle applicatif limité au DML pour les instances Roster, et — quand des réplicas sont configurés — un rôle en lecture seule séparé. Les rôles d'exécution ne possèdent jamais le schéma.
Contrôles de connexion
Chaque instance Roster maintient un pool de connexions distinct pour le writer PostgreSQL et pour chaque réplica configuré. Dimensionné en fonction des limites de connexion du service de base de données.
Haute disponibilité
La haute disponibilité de Roster repose sur deux couches indépendantes, sous une configuration commune.
- Deux instances Roster identiques ou plus, derrière un répartiteur de charge
- PostgreSQL avec un primaire accessible en écriture et au moins un réplica en lecture
Chaque instance Roster utilise la même URL publique d'authentification, le même secret d'authentification, le même secret de chiffrement des fournisseurs, les mêmes endpoints de base de données, la même configuration d'exécution et la même licence Enterprise.
Routage basé sur la santé
Utilisez /health/ready pour le routage du répartiteur de charge — la sonde répond en succès uniquement lorsque la configuration est valide, que le writer PostgreSQL est joignable et que la configuration des connecteurs est compatible HA. /health/live couvre la liveness du processus. Les deux sondes sont non authentifiées, assainies et exclues de la limitation de débit.
Consistance sur le primaire
Les écritures, transactions, vérifications de readiness, données d'authentification et décisions de sécurité restent sur le primaire PostgreSQL. Si le primaire devient indisponible, ces opérations échouent de manière fermée jusqu'à la restauration de l'endpoint writer.
Routage vers les réplicas en lecture
Roster répartit les lectures ordinaires éligibles sur les réplicas configurés. Les lectures de réplica sont à cohérence éventuelle — surveillez la latence de réplication via votre service PostgreSQL.
Coordination d'exécution partagée
PostgreSQL héberge les compteurs partagés de limitation de débit et la coordination des workers. Les workers utilisent des baux, des battements de cœur, des jetons de fencing et des tentatives bornées pour que le travail puisse être repris après la défaillance d'une instance.
Périmètre de l'infrastructure
- Redondance du répartiteur de charge
- Réplication PostgreSQL
- Détection de défaillance
- Promotion du primaire
- Endpoints writer et read-only stables
- Sauvegardes et point-in-time recovery
- Santé des réplicas et surveillance de la latence de réplication
Roster valide que le mode HA utilise PostgreSQL et la configuration requise, mais n'opère pas et ne vérifie pas indépendamment la topologie du cluster.
Conformité et exploitation
Roster s'insère dans les contrôles de sécurité, de rétention et de résidence que vous exploitez déjà — avec un parcours documenté de sauvegarde et de reprise.
Votre gouvernance, votre environnement
Parce que Roster s'exécute dans votre infrastructure et sous votre fournisseur d'identité, il peut opérer à l'intérieur des contrôles de sécurité, de rétention et de résidence que vous maintenez déjà.
SOC 2
Roster poursuit la certification SOC 2 pour répondre aux exigences des clients Enterprise. Si SOC 2 est requis par votre processus d'achat, contactez-nous pour cadrer la portée, l'état et le calendrier.
Vous contrôlez le périmètre
Assurez la terminaison TLS au niveau de votre répartiteur de charge, de votre ingress ou de votre reverse proxy. Préservez le host et le schéma publics via les en-têtes de forwarding. Stockez les secrets dans votre gestionnaire de secrets — jamais dans le code source ni dans une image personnalisée.
Apportez votre modèle
Roster utilise le fournisseur de modèle et les identifiants que vous configurez — OpenAI, Anthropic, Mistral ou une passerelle approuvée compatible. Le fournisseur reste responsable de son traitement, de sa sécurité et de sa facturation.
Sauvegardes et reprise
SQLite utilise le processus de sauvegarde en ligne de Roster. PostgreSQL utilise la sauvegarde du fournisseur avec point-in-time recovery quand il est pris en charge. Une sauvegarde de base ne couvre pas nécessairement les fichiers de connecteur ni les journaux de workers — protégez chaque emplacement de stockage requis pour la reprise.
Tester les restaurations isolées
Restaurez régulièrement les sauvegardes dans un environnement SQLite ou PostgreSQL isolé. Après une restauration PostgreSQL, démarrez une seule instance Roster d'abord et vérifiez readiness, connexion, traitement des workers et accès aux connecteurs avant de revenir au nombre nominal d'instances.
Conçu par Advantys, créateurs de WorkflowGen — automatisation de processus éprouvée en production depuis 2003.
Signaler une vulnérabilité
Vous avez identifié un problème potentiel ? Écrivez à security@advantys.com. Nous accueillons la divulgation responsable et accuserons réception de votre rapport.
Comment Roster traite les données d'annuaire
Collecte minimale, synchronisation ciblée, secrets chiffrés — la couche des connecteurs est conçue pour le moindre volume de données.