Sécurité & données

Cette page répond aux questions que se posent les équipes sécurité avant d’adopter Abra : où vivent vos données, comment elles sont chiffrées et isolées, qui peut y accéder, et comment l’usage de l’IA est encadré. Les points contractuels et réglementaires (certifications, RGPD, sous-traitants, rétention) sont signalés comme à compléter plutôt qu’affirmés — nous préférons être exacts plutôt qu’impressionnants.

En résumé

Deux modes de déploiement : SaaS (opéré par Abra, données chiffrées et isolées par organisation) ou auto-hébergé / on-premise (vos données restent entièrement sur votre infrastructure, réseau privé ou air-gap possible).
Chiffrement fort : secrets et jetons OAuth chiffrés au repos en AES-256-GCM ; clés API stockées uniquement sous forme de hash.
Isolation stricte : chaque requête est cloisonnée par organizationId — une organisation ne peut jamais lire ni écrire les données d’une autre. Prouvé par une suite de tests adversariale en intégration continue.
Authentification d’entreprise : Better Auth, modèle à 5 rôles, SSO Microsoft Entra ID et Google Workspace.
Vous gardez la main sur l’IA : clés modèles en BYOK (votre clé) ou clé plateforme, jamais exposées aux utilisateurs finaux ; les admins fixent la liste des modèles autorisés, les budgets et la gouvernance des connecteurs.

Où sont vos données

Vous choisissez le périmètre. Le produit est identique dans les deux modes ; seule change la personne qui exploite l’infrastructure.

	SaaS (opéré par Abra)	Auto-hébergé / on-premise
Qui exploite l’infra	Abra	Vous
Où vivent les données	Infrastructure opérée par Abra, chiffrées et isolées par organisation	Entièrement sur votre infrastructure (base, fichiers, historiques, RAG)
Données métier sortantes	—	Aucune ne transite par les serveurs d’Abra
Réseau privé / air-gap	—	Possible (mode hors-ligne sur demande)
Mises à jour, sauvegardes	Gérées par Abra	Gérées par vous (Auto-hébergement)

En auto-hébergé, seules des données techniques de licence (validité, version, volume d’usage agrégé) sortent vers le service de licence Abra — aucune donnée métier. Un mode air-gap (sans Internet sortant) est disponible sur demande.

[À COMPLÉTER par Raphaël : régions/résidence des données en mode SaaS (pays, fournisseur cloud, localisation exacte).]

Chiffrement

Tous les secrets réutilisables sont chiffrés au repos en AES-256-GCM ; ce qui n’a pas besoin d’être relu (clés API émises) est seulement haché.

Donnée	Traitement	Clé / secret
Secrets de connecteur (`client_secret`, clés API fournisseur)	AES-256-GCM (chiffré, réversible)	`CONNECTOR_SECRET_KEY` (32 octets)
Jetons OAuth (`access` / `refresh` / `id`)	AES-256-GCM au repos	`CONNECTOR_SECRET_KEY`
État OAuth (anti-CSRF)	HMAC-SHA256 signé + TTL 10 min + nonce	intégrité, non chiffré
Clés API émises (Agents-as-API)	SHA-256 + pepper (non réversible)	`API_KEY_PEPPER`
Sessions / cookies	Signés (Better Auth)	`BETTER_AUTH_SECRET`

Points clés :

IV aléatoire à chaque chiffrement : deux chiffrements du même texte donnent deux résultats différents. Le tag d’authentification GCM rend toute falsification du ciphertext détectable (pas de « déchiffrement silencieusement faux »).
Une fuite de base seule ne suffit pas. Le contenu d’une ligne chiffrée est inutilisable sans la clé, qui vit dans la configuration serveur validée au démarrage — jamais en dur dans le code, jamais en base.
Clés API montrées une seule fois, à l’émission ; la base ne stocke que leur hash + un pepper externe, donc un dump de la colonne reste inexploitable.
Validation au démarrage : toutes les clés cryptographiques sont vérifiées au boot — une configuration invalide empêche le démarrage plutôt que de produire des données corrompues.

En auto-hébergé, le chiffrement en transit (TLS) se termine sur le reverse-proxy inclus (certificat Cloudflare Origin, Let’s Encrypt ou votre PKI interne).

[À COMPLÉTER par Raphaël : chiffrement de disque au repos côté infrastructure SaaS (ex. volumes/DB chiffrés par le fournisseur cloud) — à préciser si on veut l’affirmer.]

Isolation multi-tenant

Une organisation ne peut jamais accéder aux données d’une autre. Chaque requête sur des données métier est cloisonnée par organizationId.

L’organizationId ne vient jamais du client : ni de l’URL, ni du corps, ni d’un en-tête manipulable. Il est résolu à partir de la session signée (Better Auth) — impossible à forger.
Anti-IDOR par construction : un objet n’est jamais recherché par son seul identifiant. Un id appartenant à une autre organisation ne correspond à aucune ligne → réponse 404 (l’existence de l’objet n’est même pas révélée).
Rôles calculés par organisation : les droits ne « fuitent » pas d’une organisation à l’autre. Un admin de l’org A n’a aucun pouvoir sur l’org B.
Clés API liées à une organisation : une clé Agents-as-API est rattachée à une seule organisation à sa création et ne peut jamais en servir une autre.
Prouvé en continu : une suite de tests adversariale (une org attaque les endpoints d’une autre) tourne en intégration continue ; toute régression de cloisonnement fait échouer la CI.

En auto-hébergé, l’isolation est renforcée par le fait qu’une instance ne sert souvent qu’une seule organisation, sur votre propre réseau.

Authentification & SSO

Authentification bâtie sur Better Auth, avec sessions signées et prise en charge du SSO d’entreprise.

Fournisseurs d’identité : Microsoft Entra ID (Azure AD) et Google Workspace — les deux peuvent être actifs simultanément.
Découverte par domaine : après connexion SSO, l’utilisateur est rattaché à la bonne organisation d’après le domaine de son e-mail.
Mapping groupe → rôle : les groupes de l’annuaire (Entra ID) peuvent être traduits en rôles Abra, avec une règle « attrape-tout ».
Provisioning : au choix, création automatique de compte (JIT) ou accès sur invitation uniquement.
2FA disponible via Better Auth.

Bonne pratique : avant d’imposer le SSO seul, gardez au moins un administrateur avec un accès de secours, pour éviter tout verrouillage.

[À COMPLÉTER par Raphaël : politique de mots de passe (longueur, complexité, rotation) et durée de session par défaut, si on souhaite les documenter publiquement.]

Contrôle d’accès (rôles)

Le droit d’agir dépend d’un rôle, appliqué par organisation. Quand plusieurs rôles coexistent, le plus fort l’emporte.

Rôle	Résumé
Membre	Utilise les agents/workflows attribués. Aucune administration.
Développeur	Construit et téléverse workflows/agents, puis soumet à validation.
Manager	Gère ses équipes (membres, attributions, invitations).
Super-manager	Variante de manager, priorité un cran au-dessus.
Admin d’organisation	Contrôle toute l’organisation (membres, connecteurs, gouvernance IA, SSO, marque).

Deux axes indépendants, jamais déduits l’un de l’autre :

Rôle d’organisation — au sein d’une org, via l’appartenance (member).
Rôle de plateforme (opérateur / hébergeur) — au-dessus des organisations, jamais obtenu par simple inscription ; il est attribué au bootstrap de la licence. Le seul acteur pouvant traverser les organisations est cet opérateur, et ses actions « dans » une org passent par une impersonation tracée et limitée dans le temps (bannière + session attribuée).

Gouvernance des modèles LLM & clés

Vous gardez le contrôle de quels modèles sont utilisables, par qui, et à quel coût — et les clés modèles ne sont jamais exposées aux utilisateurs finaux.

BYOK ou clé plateforme : votre organisation utilise sa propre clé fournisseur (BYOK, saisie dans les connecteurs, chiffrée au repos) ou une clé plateforme mutualisée fournie par l’opérateur. Dans les deux cas, la clé n’est jamais visible des utilisateurs finaux.
Modèles autorisés (allowlist) : les admins choisissent la liste des modèles réellement proposés. Un modèle non autorisé est inutilisable pour toute l’organisation. En SaaS, le résultat effectif est l’intersection de votre liste et de celle de l’opérateur (vous pouvez resserrer, jamais élargir).
Budgets & plafonds : budget mensuel par utilisateur (côté org) et plafond global par organisation (côté opérateur). Une fois atteint, les appels IA sont refusés jusqu’à la période suivante.
Suivi de consommation : tableau de bord d’usage IA (dépense par modèle, par période) pour repérer un usage coûteux.
Gouvernance des connecteurs : les admins décident quels outils métier (Microsoft 365, Google Workspace, bases, API internes…) sont branchés et accessibles aux agents.

Détail complet dans le Guide de l’administrateur.

Conformité & RGPD

[À COMPLÉTER par Raphaël : posture RGPD — rôle d’Abra (sous-traitant / responsable de traitement selon SaaS vs auto-hébergé), base légale, registre des traitements.]
[À COMPLÉTER par Raphaël : disponibilité d’un DPA (accord de traitement des données) et à quelles conditions.]
[À COMPLÉTER par Raphaël : certifications — SOC 2, ISO 27001, autres — ou statut « non certifié / en cours ». Ne rien affirmer sans preuve.]
[À COMPLÉTER par Raphaël : localisation / résidence des données en SaaS et options de région.]

Sous-traitants

[À COMPLÉTER par Raphaël : liste des sous-traitants / sub-processors en mode SaaS (hébergeur cloud, fournisseurs de modèles IA activés, e-mail transactionnel, observabilité) et leur rôle. En auto-hébergé, les seuls tiers sont ceux que le client active lui-même — à formuler explicitement.]

Rétention & suppression

[À COMPLÉTER par Raphaël : durées de rétention par type de donnée (conversations, logs d’audit, usage IA, sauvegardes) en mode SaaS.]
[À COMPLÉTER par Raphaël : procédure de suppression / export sur demande, et délai de suppression après résiliation.]

En auto-hébergé, la rétention et la suppression sont sous votre entière maîtrise : vous appliquez vos propres politiques, sauvegardes et cycles de vie des données.

Signaler une vulnérabilité

Nous accueillons les signalements responsables de sécurité.

[À COMPLÉTER par Raphaël : adresse de contact sécurité (ex. security@abracadabrai.com), politique de divulgation responsable, et délai de notification en cas d’incident / de violation de données.]

Cette page décrit des mécanismes techniques réellement en place. Les éléments marqués [À COMPLÉTER] sont d’ordre contractuel ou réglementaire et doivent être renseignés avant diffusion à un client.