Sécurité et isolation des données

Cette page explique le modèle de sécurité sur lequel les évaluateurs se penchent : comment les organisations sont isolées les unes des autres, comment fonctionnent les différents jetons d’accès et comment les données sensibles sont protégées au repos. Elle s’applique aussi bien à la forme cloud qu’à la forme sur site : le modèle est identique.

Isolation des tenants

Un tenant est la frontière de plus haut niveau pour les données d’une organisation. Chaque vidéo, résultat de classification, appartenance d’utilisateur et valeur de configuration appartient à exactement un tenant, et Gaard partitionne les données par tenant au niveau de la base de données : les données opérationnelles de chaque tenant résident dans leur propre base dédiée, identifiée par le nom du tenant.

Cela a deux conséquences importantes pour un évaluateur :

Aucune lecture inter-tenant. Une requête est liée à un seul tenant pendant toute sa durée de vie. Les requêtes ne s’exécutent que sur la base de ce tenant : une organisation ne peut donc ni voir, ni lister, ni adresser les données d’une autre organisation.
L’accès est restreint au tenant, pas partagé globalement. Les jetons d’API sont émis pour un tenant spécifique (voir ci-dessous), et un utilisateur ne voit que les tenants dont il est membre.

Consultez Concepts fondamentaux pour comprendre le lien entre les tenants et les solutions, flows, sites et caméras.

Le modèle de jetons

Gaard utilise trois types distincts d’identifiants, chacun destiné à un appelant différent.

Sessions navigateur

Lorsqu’une personne se connecte à l’application web sur app.gaard.ai, la plateforme émet un cookie de session chiffré. La connexion prend en charge l’e-mail et le mot de passe, les liens magiques à usage unique et la connexion via Google. La session porte l’identité de l’utilisateur et le tenant actuellement sélectionné ; changer de tenant modifie ce que la session peut adresser, toujours dans la limite des tenants dont l’utilisateur est membre.

Jetons d’API (limités à un tenant)

L’accès machine à machine (l’API de classification, les webhooks et les intégrations) utilise des jetons d’API. Vous les créez dans l’application web via Settings → Platform → Integrations, et vous les envoyez à chaque requête dans l’en-tête Authorization :

curl https://vision.gaard.ai/api/result/<classify_id> \
  -H "Authorization: Bearer <your-api-token>"

Chaque jeton d’API est limité à un seul tenant et, éventuellement, à un flow spécifique. Une requête présentant le jeton ne peut agir qu’au sein de ce tenant. Pour créer et gérer ces jetons, consultez Jetons d’API.

Jetons d’accès personnels (CLI)

La CLI Gaard s’authentifie avec un jeton d’accès personnel (PAT). Un PAT est associé à un compte utilisateur et se reconnaît à son préfixe pat_. Les PAT sont créés soit via un flux de connexion approuvé dans le navigateur, soit en vous connectant avec vos identifiants depuis la CLI.

Un PAT n’est affiché en entier qu’une seule fois, au moment de sa création. Gaard ne stocke qu’un hachage SHA-256 du jeton, jamais le jeton lui-même : une valeur de jeton ne peut donc pas être récupérée depuis la base de données : elle ne peut qu’être révoquée et remplacée. Vous pouvez lister et révoquer vos propres jetons à tout moment.

Chiffrement au repos

Gaard chiffre les valeurs sensibles qu’il doit stocker afin qu’elles ne soient pas lisibles dans la base de données :

Les identifiants et secrets d’intégration (tels que les identifiants utilisés pour livrer les résultats à un système externe) sont chiffrés avec AES-GCM avant d’être écrits en base, et déchiffrés uniquement lorsque la plateforme doit les utiliser. Dans l’API et l’application web, ces valeurs sont masquées (affichées sous la forme ********) plutôt que renvoyées en clair.
Les mots de passe des utilisateurs ne sont jamais stockés en clair ni sous une forme réversible ; ils sont hachés avec bcrypt.
Les jetons d’accès personnels sont stockés sous forme de hachages SHA-256, comme décrit ci-dessus.
Les cookies de session sont chiffrés.

Étapes suivantes

Rétention des données et RGPD : durée de conservation, suppression des classifications et effacement.
Cloud ou sur site : où résident vos données selon la forme de déploiement.
Jetons d’API : créer et restreindre la portée des jetons.
Utilisateurs et rôles : inviter des membres et attribuer des rôles.