Sécurité et conformité

Authentification

Les jetons d’accès sont des JWT de courte durée (15 minutes), vérifiés par la passerelle d’API ; les jetons de rafraîchissement vivent 30 jours d’inactivité et 90 jours au maximum, changent à chaque utilisation et sont stockés dans un cookie HttpOnly, Secure, SameSite. La réutilisation d’un jeton de rafraîchissement déjà remplacé révoque toute la chaîne.
Les clés de signature sont renouvelées tous les 90 jours avec une période de chevauchement ; les clés publiques sont publiées sur /.well-known/jwks.json.
Les permissions ne sont pas intégrées aux jetons : elles sont lues à chaque requête, si bien qu’un changement de rôle s’applique immédiatement et que toute session peut être révoquée de façon centralisée.
L’authentification à deux facteurs (TOTP) peut être facultative, obligatoire pour les Propriétaires et les Admins, ou obligatoire pour tous. L’authentification unique avec Google Workspace et Apple est disponible sur tous les forfaits. SAML 2.0, les passkeys et le provisionnement SCIM sont prévus et pas encore disponibles.
Les clés d’API ne sont affichées qu’une fois, stockées sous forme de hachage SHA-256, limitées à des portées issues d’un catalogue fermé, bornées par les permissions de leur propriétaire et révocables instantanément. Voir Authentification.
La connexion est limitée par IP et par e-mail ; dix échecs verrouillent le compte pendant 30 minutes ; les échecs répétés depuis une même adresse IP sont comptés et consignés, mais par défaut ils ne bloquent pas cette adresse. Chaque connexion, échec, rafraîchissement, changement de permission et action d’administration est consigné dans le journal d’audit.

Isolation des locataires

Chaque ligne de chaque service porte le compte auquel elle appartient, et chaque requête est automatiquement filtrée sur ce compte ; désactiver ce filtre exige un appel explicite, figurant sur une liste autorisée, réservé aux opérations internes inter-locataires et couvert par des tests. Les rôles par site ajoutent un filtre de site par-dessus. Une requête visant la ressource d’un autre compte reçoit 404, jamais 403, pour que les identifiants ne puissent pas être énumérés. Chaque endpoint d’écriture utilise une liste stricte de champs autorisés. Un test d’accès inter-comptes est obligatoire pour chaque nouvel endpoint.

L’en-tête X-Account-Id de chaque requête est comparé au jeton, si bien qu’un bug client ou un jeton rejoué ne peut jamais lire silencieusement les données d’un autre locataire.

Chiffrement

TLS 1.2 ou plus récent vers chaque endpoint public, TLS mutuel entre les services, TLS vers chaque stockage de données, volumes chiffrés au repos et chiffrement par enveloppe propre à chaque compte pour les champs sensibles. Les certificats publics sont émis et renouvelés automatiquement ; les certificats internes ont une courte durée de vie.

Secrets

Tous les secrets, y compris vos clés de fournisseurs BYOK et vos secrets de webhooks, sont conservés dans un gestionnaire de secrets dédié, chiffrés, cloisonnés par service et audités. Rien ne se trouve dans le contrôle de source (vérifié par une analyse avant chaque commit) ni dans les images de conteneurs (vérifié en CI). Par défaut, les développeurs n’ont aucun accès aux secrets de production ; un accès d’urgence nécessite deux approbations, est de courte durée et est consigné dans un canal impossible à mettre en sourdine.

Webhooks

Les envois sortants sont signés en HMAC-SHA256 sur l’horodatage et le corps brut, portent un nonce et un identifiant d’événement, sont rejetés en dehors d’une fenêtre de cinq minutes et font l’objet de nouvelles tentatives avec temporisation progressive jusqu’à une file de lettres mortes. Les secrets sont renouvelés avec une période de chevauchement et peuvent être révoqués instantanément. Les webhooks entrants des fournisseurs sont vérifiés selon le schéma propre à chaque fournisseur avant tout traitement. Détails : Webhooks.

Limitation du débit

Quatre niveaux : protection contre les DDoS et les bots au niveau du réseau périphérique, limites par IP au niveau du proxy inverse, seaux de jetons par compte et par identité au niveau de la passerelle d’API, et limites métier à l’intérieur des services. Les limites figurent dans la vue d’ensemble de l’API.

Audit

Chaque modification est écrite dans un journal d’audit en ajout seul et chaîné par hachage, avec deux classes de conservation : les événements généraux et les événements de conformité (demandes des personnes concernées, violations, sous-traitants ultérieurs et enregistrements KYC). La classe est attribuée à l’écriture de l’entrée ; personne ne peut modifier ni supprimer le journal, et un nettoyage automatique par classe n’est pas encore en service. Les Propriétaires et les Admins peuvent le filtrer et l’exporter. Les mots de passe, jetons et clés ne sont jamais journalisés ; la couche de journalisation masque les clés connues comme sensibles.

Protection des données

Les demandes des personnes concernées au titre du RGPD, du RGPD britannique, du CCPA et de la LGPD (accès, export, effacement) sont reçues et suivies dans la console de conformité avec leurs délais. L’effacement est effectué par le personnel de RolChat, et la demande n’est clôturée qu’après sa confirmation ; un effacement automatique dans tous les modules n’est pas encore disponible.
Résidence des données : les données sont stockées dans l’UE. La région n’est pas choisie selon le pays à l’inscription ; le réglage de région dans les paramètres du compte est seulement enregistré et ne déplace pas encore les données.
Conservation selon le forfait : 1, 2 ou 3 ans. Supprimer une conversation ou un contact le masque jusqu’à la fin de cette durée ; la suppression d’un compte est une demande assortie de 30 jours pour l’annuler, après quoi le personnel efface les données ; un compte impayé est conservé 90 jours puis effacé. Le nettoyage automatique qui applique ces durées est en cours de déploiement.
Un Accord de traitement des données, la liste des sous-traitants ultérieurs, la politique de confidentialité et la politique relative aux cookies sont publiés sur rolchat.com ; l’Accord de traitement des données est accepté lors de l’inscription.
Notification des violations sous 72 heures, comme l’exige l’article 33 du RGPD.

Gestion des vulnérabilités

Les dépendances sont surveillées en continu ; les fichiers de verrouillage sont versionnés ; les images de base sont figées par empreinte ; les actions CI sont figées par commit. Un test d’intrusion par un tiers est prévu chaque année à partir de la bêta, couvrant l’API, le widget et les pages publiques, ainsi qu’un scénario interne de compromission supposée. Un programme de bug bounty privé suivra la disponibilité générale. Signalez les problèmes de sécurité à security@rolchat.com.

Disponibilité

La plateforme fonctionne sur plusieurs nœuds avec basculement automatique pour les services sans état et réplication gérée pour les bases de données. Les objectifs de disponibilité par forfait sont fixés dans votre contrat.

Réponse aux incidents

Des procédures d’exploitation pour chaque service, une rotation d’astreinte, un système d’alerte externe qui fonctionne même lorsque notre propre infrastructure est en panne, et des obligations de notification des clients intégrées au processus.