La sécurité à chaque couche

AYAN LABS FRONTIER SOFTWARE - FZCO (« AYAN ») est une société domiciliée à Dubaï qui développe AYAN, la gestion de marque à l’ère de l’IA. Nous traitons pour le compte de nos clients des éléments de marque, des prompts, de la télémétrie de perception et les résultats d’audit qui en découlent. Le présent document décrit les contrôles de sécurité dont AYAN est responsable, et ceux qui restent à la charge de nos clients.

AYAN est responsable de :

• La sécurité physique et plateforme de l’environnement d’hébergement.
• Le chiffrement des données en transit et au repos.
• La sécurité applicative, le cycle de développement sécurisé et la gestion des vulnérabilités.
• La journalisation, la supervision et la réponse aux incidents sur la plateforme.
• L’évaluation préalable des fournisseurs et des sous-traitants ultérieurs.

Le client est responsable de :

• Le cycle de vie des utilisateurs de son côté (arrivées, mobilités, départs, configuration du SSO).
• La garde des clés d’API délivrées à son organisation.
• La classification des données qu’il téléverse et la base légale de leur traitement.
• La configuration des réglages propres à l’organisation (listes de modèles autorisés, conservation, intégrations).

Les données client transitent par une chaîne restreinte et bien définie. Entrée : téléversement HTTPS vers l’API applicative. Stockage : une base Postgres managée dans une région de l’UE, avec un stockage objet chiffré pour les médias et les documents. Traitement : des workers éphémères effectuent les appels d’inférence aux LLM et réécrivent des sorties structurées en base. Audit : chaque lecture et chaque modification portant sur des données client est consignée dans un journal infalsifiable.

Les données de production sont stockées dans l’UE. L’inférence des LLM peut être routée vers des fournisseurs situés dans l’UE ou aux États-Unis, selon le modèle sélectionné par le client. Les clients peuvent configurer, par organisation, une liste régionale autorisée qui restreint l’inférence à des régions de fournisseurs déterminées.

Les transferts transfrontaliers s’appuient sur les Clauses contractuelles types de la Commission européenne, sur l’addendum britannique le cas échéant, et sur les mécanismes de transfert de la PDPL des Émirats arabes unis pour le sens inverse. Les sous-traitants ultérieurs dont les flux de données passent par les États-Unis opèrent dans le cadre des dispositifs de transfert de données applicables.

Les contrôles en résumé :

• TLS 1.3 pour tout le trafic en transit, avec HSTS préchargé sur la surface marketing publique.
• AES-256-GCM pour les données au repos : base de données, sauvegardes, stockage objet.
• Chiffrement à enveloppe : des clés de chiffrement de données (DEK) cloisonnées par client, encapsulées par des clés de chiffrement de clés (KEK) détenues dans le KMS de l’hébergeur.
• Rotation des clés : les KEK sont renouvelées chaque année ; les DEK le sont à la demande et lors du départ d’un client.
• Pas de clés gérées par le client à ce jour. Le BYOK (apportez vos propres clés) figure à la feuille de route à 12 mois.

Accès des collaborateurs :

• Authentification unique avec double authentification par clé matérielle, imposée à tous les rôles d’ingénierie et d’administration.
• L’accès à la production est fondé sur les rôles et limité dans le temps : les opérations privilégiées exigent une élévation juste-à-temps et sont journalisées de façon immuable.
• Principe du moindre privilège appliqué à chaque couche. Revue des accès chaque trimestre.

Accès côté client :

• SSO SAML / OIDC disponible sur l’offre entreprise.
• Clés d’API par organisation, à permissions restreintes et prenant en charge la rotation.
• Journal d’audit des actions d’administration, exporté sur demande.

AYAN est construit autour de l’inférence par LLM. La façon dont nous traitons les données envoyées à ces modèles et reçues d’eux est le contrôle le plus important de cette page.

• Les données de marque du client ne servent jamais à entraîner les modèles d’AYAN ni aucun modèle tiers.
• Tous les fournisseurs de LLM vers lesquels nous routons l’inférence opèrent sous leurs conditions entreprise sans entraînement.
• Les charges utiles des prompts et des réponses sont chiffrées en transit et stockées uniquement dans l’espace client correspondant de notre base de données.
• Lorsque cela est possible, les champs identifiants sont expurgés ou remplacés par un identifiant stable avant d’être transmis à un fournisseur.
• Les clients peuvent configurer, par organisation, une liste de modèles autorisés (quels fournisseurs et quelles régions sont éligibles).
• La durée de conservation côté fournisseur est réglée sur la fenêtre la plus courte disponible. Nous pouvons fournir sur demande l’addendum de traitement des données de chaque fournisseur.

Toute modification livrée en production suit un cycle de développement sécurisé documenté :

• Revue de la pull request par au moins un ingénieur qui n’en est pas l’auteur.
• CI automatisée : lint, vérification des types, tests unitaires et d’intégration sur chaque PR.
• Analyse statique (règles de lint orientées sécurité, semgrep) et analyse des dépendances sur chaque PR.
• Les secrets ne se trouvent jamais dans le code source : ils sont conservés dans le gestionnaire de secrets de l’hébergeur et injectés à l’exécution.
• Protection de la branche principale. Les force-pushes sont bloqués. Les versions sont taguées et signées.

La production s’appuie sur des services managés fournis par des prestataires certifiés SOC 2 Type II, dans des régions de l’UE et des Émirats arabes unis. Les noms des prestataires figurent dans le tableau des sous-traitants ultérieurs ci-dessous ou sont disponibles sur demande.

• Réseau de périphérie et pare-feu applicatif web devant chaque point d’accès public.
• Les plans applicatif, données et administration sont segmentés ; la base de données n’a aucun point d’accès public.
• Images de conteneurs durcies, infrastructure immuable, infrastructure-as-code pour chaque modification en production.
• Secrets et configuration gérés via le coffre du prestataire, sans compte de service partagé.

Les journaux applicatifs et les pistes d’audit sont centralisés dans un entrepôt infalsifiable, avec une conservation de douze mois. Les événements pertinents pour la sécurité (échecs de connexion administrateur, usage détourné d’un jeton à portée restreinte, sorties de données anormales, changements de configuration en production) déclenchent des alertes routées vers l’astreinte. La couverture de détection est revue chaque trimestre au regard de l’OWASP Top 10 et des techniques MITRE ATT&CK les plus pertinentes pour les plateformes SaaS.

Notre programme de gestion des vulnérabilités fonctionne en continu :

• Analyse des dépendances à chaque push, avec des pull requests automatisées pour les paquets présentant des vulnérabilités connues.
• Correctifs pilotés par SLA : critiques sous 72 heures, élevés sous 7 jours, moyens sous 30 jours.
• Test d’intrusion annuel par un tiers dès que la plateforme atteindra la disponibilité générale ; en attendant, une rotation de red team interne est en place.
• Boîte de réception bug bounty et divulgation responsable à security@ayanlabs.ai, voir la section contact ci-dessous.

AYAN maintient un runbook de réponse aux incidents documenté, avec une astreinte nominative et une matrice de gravité (Sev 1 à Sev 4). Objectifs :

• Sev 1 : accusé de réception sous 30 minutes, information au client sous 2 heures.
• Sev 2 : accusé de réception sous 2 heures ouvrées.
• Sev 3 et 4 : accusé de réception sous 1 jour ouvré.

Pour les incidents dont il est confirmé qu’ils affectent des données client, AYAN notifie le client concerné dans les 72 heures suivant la confirmation, avec une chronologie, un périmètre et un plan de remédiation, conformément à l’article 33 du RGPD et à la PDPL des Émirats arabes unis. Un post-mortem écrit est communiqué au client concerné une fois l’incident clos.

Les données client sont protégées par des sauvegardes à plusieurs niveaux et un plan de reprise testé :

• Restauration de la base à un instant donné, complétée par des instantanés chiffrés quotidiens.
• Le stockage objet est versionné, avec réplication inter-régions pour les objets critiques.
• Objectif de point de reprise (RPO) visé : 24 heures. Objectif de délai de reprise (RTO) visé : 8 heures pour l’environnement de production.
• Les sauvegardes sont testées par des exercices de restauration au moins une fois par an. Des exercices de reprise après sinistre sont menés au moins une fois par an.
• Le risque de concentration fournisseur est réexaminé à chaque jalon d’architecture.

Chaque sous-traitant ultérieur fait l’objet d’une évaluation documentée qui consigne sa posture de sécurité, ses certifications, sa localisation et l’accord de traitement des données qui nous lie à lui. Les ajouts ou changements substantiels de sous-traitants ultérieurs sont annoncés au moins trente jours avant leur mise en service, par le canal e-mail des administrateurs client. Les catégories de sous-traitants ultérieurs actuellement utilisées figurent dans le tableau de cette page ; une liste nominative à jour, avec les régions et les accords de traitement, est disponible sur demande à security@ayanlabs.ai.

Les engagements détaillés en matière de confidentialité figurent dans la Politique de confidentialité, à l’adresse /privacy. AYAN fournit sur demande un accord de traitement des données pré-signé et peut signer celui du client lorsque les clauses de fond concordent. Les demandes des personnes concernées (accès, rectification, effacement, portabilité, limitation, opposition) sont adressées à legal@ayanlabs.ai et traitées dans les délais imposés par le RGPD et la PDPL des Émirats arabes unis.

Contrôles relatifs aux personnes :

• Vérifications d’antécédents lorsque la loi de la juridiction du collaborateur le permet.
• Formation à la sécurité obligatoire à l’arrivée, avec piqûre de rappel annuelle.
• Accords de confidentialité et d’usage autorisé signés.
• Gestion du parc avec chiffrement intégral du disque, verrouillage d’écran imposé et EDR.
• SSO avec double authentification obligatoire imposée sur les identités des collaborateurs.
• Le départ d’un collaborateur entraîne la révocation des accès sous un jour ouvré.

Divulgation responsable :

• Écrivez à security@ayanlabs.ai pour signaler une vulnérabilité.
• Nous accusons réception des signalements sous un jour ouvré.
• Protection pour la recherche de sécurité de bonne foi dans le périmètre défini : nous n’engagerons pas de poursuites contre les chercheurs agissant de bonne foi et dans le cadre de la politique de divulgation.