Sécurité

Les points durs de l'architecture Anonari, et le périmètre exact où chacun s'applique — sans promesse de conformité générale.

Isolation des comptes

Chaque requête est filtrée par compte et, pour les revendeurs, par périmètre revendeur. Un client ne peut pas accéder aux données d'un autre, y compris via une clé compromise. Un revendeur n'a jamais accès aux credentials de connexion de ses clients.

Clés rattachées à un profil

Une clé API est rattachée à un seul profil de données, choisi à sa création, et la requête ne peut pas demander un profil plus permissif : elle peut seulement déclarer le profil qu'elle attend, ce qui provoque un refus en cas d'écart. Périmètre exact : cette liaison est appliquée par l'endpoint de minimisation ; les endpoints de signaux agrégés, antérieurs à ce moteur, vérifient la clé, son expiration et son quota mais pas encore son profil.

Socle d'interdictions non contournable

Sept catégories — identité directe, coordonnées, notes internes, champs libres, pièces jointes, identifiants d'accès, données sensibles — sont interdites au niveau du moteur, hors de la base, et aucun profil ne peut les réautoriser. Un champ inconnu du schéma tombe dans la catégorie la plus restrictive. Leur présence provoque un refus explicite, pas un nettoyage silencieux.

Absence de charge utile dans les journaux

Les journaux d'Anonari enregistrent des métadonnées : endpoint, méthode, code de statut, horodatage, durée, taille de réponse, nombre de champs restitués, motif normalisé de refus. Jamais le contenu métier transmis ou restitué, jamais la valeur fautive à l'origine d'un refus.

Politiques versionnées et empreintées

Chaque profil porte un numéro de version et une empreinte SHA-256 de sa politique, recalculée à chaque écriture. Les reçus déjà émis conservent la version et l'empreinte qui s'appliquaient au moment du traitement : une évolution de politique ne réécrit pas le passé.

Révocation et expiration

Une clé API se révoque immédiatement depuis votre espace, et peut porter une date d'expiration. La révocation comme l'expiration coupent l'accès sur tous les endpoints, sans affecter les autres clés ni la collecte en cours.

Conservation minimale

Anonari conserve des curseurs de collecte (identifiants techniques et compteurs) et des métadonnées de reçus. Aucune donnée métier nominative n'est stockée : le principe est qu'il n'y ait rien d'exploitable à voler.

Journal d'audit et journal d'accès

Deux journaux distincts : un journal d'audit et de sécurité (création et révocation de clé, refus de minimisation, tentative inter-comptes) et un journal d'accès par clé consultable dans votre espace. Le profil utilisé y est enregistré pour les appels passés par l'endpoint de minimisation.

Credentials de connexion à la plateforme métier

L'URL et la clé API de votre Dolibarr ou Odoo sont chiffrées en AES-256-GCM avec une clé conservée hors base, et ne sont jamais accessibles en clair, y compris par l'équipe d'Anonari. Elles sont supprimées à la déconnexion de l'instance.

Ce qui est en cours, et que nous préférons écrire

◦ Le rattachement des endpoints de signaux agrégés au moteur de profils n'est pas terminé : ils authentifient la clé mais n'appliquent pas encore sa politique.
◦ L'endpoint public de vérification de signature d'un reçu n'est pas encore ouvert.
◦ La politique d'identifiant « par session » est aujourd'hui dégradée en « par requête », faute de notion de session sur une API sans état.
◦ Deux opérations de transformation déclarables (agrégation, suppression des valeurs rares) ne sont pas implémentées : un champ qui les demanderait est retiré par défaut, jamais restitué tel quel.

Clé « Tableau de trésorerie »
→ profil : financial.cashflow-forecast

Clé « Agent de relance »
→ profil : financial.payment-risk

Clé « Comparaison sectorielle »
→ profil : sector.benchmark

Voir tous les profils