Politique de sécurité

1. Approche

VERA peut publier, envoyer et dépenser en votre nom : la propriété de sécurité la plus importante n'est donc pas cryptographique, c'est le fait que VERA n'agit pas sans vous. Les actions externes sont enregistrées sous forme de propositions et exécutées uniquement après votre approbation, ou en vertu d'une règle d'automatisation que vous avez vous-même configurée. Ce contrôle d'approbation est appliqué dans le code qui exécute les actions, et pas seulement énoncé dans une politique.

Le deuxième principe : les identifiants sont les joyaux de la couronne. VERA détient des jetons pour des plateformes capables de déplacer de l'argent, de publier auprès d'un public et de consulter les comptes d'une entreprise. Ils sont chiffrés avec une clé distincte de tout le reste, et ne sont jamais réaffichés dans l'interface ni écrits dans les journaux.

2. Ce qui est en place

Chacun des éléments suivants est déjà implémenté dans le produit.

• Chiffrement en transit. Tout le trafic est servi en HTTPS. En production, les requêtes HTTP non chiffrées sont redirigées de façon permanente vers HTTPS en périphérie du réseau, et HTTP Strict Transport Security est appliqué avec un max-age de deux ans, includeSubDomains et preload.
• Chiffrement des secrets au repos. Les identifiants des connecteurs et les clés API sont chiffrés avec AES-256-GCM, un algorithme de chiffrement authentifié : un texte chiffré altéré échoue au déchiffrement au lieu de produire des données modifiées. La clé est une valeur dédiée dont la validation au démarrage en production exige qu'elle soit présente, distincte et d'une longueur suffisante.
• Sécurité des mots de passe. Les mots de passe sont hachés avec bcrypt avec un facteur de coût de 12 et ne sont jamais stockés ni journalisés sous une forme lisible. Une longueur minimale est imposée. La vérification de l'adresse e-mail est obligatoire avant qu'un compte avec mot de passe puisse se connecter.
• Gestion des sessions. Les sessions sont des JSON Web Tokens signés contenant un compteur de révocation, vérifié dans la base de données à chaque requête authentifiée. L'incrémentation de ce compteur invalide d'un coup toutes les sessions émises : c'est ce qui permet à la réinitialisation du mot de passe, à la fonction « se déconnecter de tous les appareils » et à la suspension de compte d'expulser réellement les sessions actives, et pas seulement d'empêcher l'ouverture de nouvelles sessions.
• Réinitialisation du mot de passe et vérification. Les liens de réinitialisation sont à usage unique, expirent au bout de 1 heure, sont soumis à un délai minimal entre deux envois et révoquent toutes les sessions lorsqu'ils sont utilisés. Les liens de vérification expirent au bout de 24 heures. La demande de réinitialisation ne révèle jamais si un compte existe.
• Limitation de débit. La connexion, l'inscription, la réinitialisation du mot de passe et les actions d'IA sont soumises à une limitation de débit reposant sur des compteurs durables à fenêtre fixe stockés dans la base de données : les limites survivent ainsi aux redémarrages de processus et s'appliquent à l'ensemble des instances, et pas seulement au sein d'une seule.
• Cloisonnement des comptes. Chaque requête est limitée au compte authentifié. Un échec de vérification de propriété est lui-même enregistré comme événement de sécurité.
• Rôles et licences de l'équipe. Un compte professionnel peut regrouper plusieurs personnes. Chaque membre est invité par le titulaire du compte, accepte l'invitation avec ses propres identifiants plutôt qu'avec un identifiant partagé, et se voit attribuer un rôle dont les autorisations sont vérifiées sur le serveur, et pas seulement reflétées dans l'interface. Les membres peuvent être désactivés, ce qui met fin à leur accès tout en conservant leur nom sur les enregistrements qu'ils ont créés. Les soumissions des employés, comme les dépenses et les frais kilométriques, sont attribuées au compte qui les a envoyées.
• Contrôle des accès administratifs. La console d'exploitation interne est réservée à une liste d'autorisation explicite d'opérateurs configurée dans l'environnement. Chaque action d'un opérateur est inscrite dans un journal d'audit administratif en ajout seul, qui enregistre qui a fait quoi sur quel compte.
• Piste d'audit. Chaque proposition, approbation, modification, refus, exécution et échec est enregistré dans un journal d'audit en ajout seul propre à chaque compte, avec les événements de sécurité tels que les changements de mot de passe, les révocations de session, les suspensions et les renouvellements de liens de devis. Les secrets, les jetons et les empreintes de mots de passe en sont exclus par conception.
• En-têtes de sécurité HTTP. Une Content Security Policy qui restreint les scripts, les styles, les frames et les cibles de formulaires ; X-Frame-Options DENY et frame-ancestors none contre le clickjacking ; X-Content-Type-Options nosniff ; une politique de référent strict-origin-when-cross-origin ; et une Permissions-Policy définie sur camera=(), microphone=(self), geolocation=(self). Le microphone et la localisation ne sont autorisés que sur les pages de VERA elles-mêmes, jamais pour un tiers intégré, et ne prennent effet qu'une fois que vous avez accordé au navigateur l'autorisation pour la fonctionnalité qui la demande.
• Intégrité des webhooks. Les webhooks entrants sont vérifiés selon le schéma de signature de chaque fournisseur avant traitement, notamment les signatures Stripe, l'en-tête HMAC de Meta, le HMAC de Jobber, la clé de signature de Square et le jeton de vérification dédié de QuickBooks. Les livraisons sont dédupliquées par identifiant d'événement, de sorte qu'une relecture ne puisse pas produire deux fois le même effet.
• Protection contre la falsification de requêtes côté serveur. Lorsque le produit récupère une URL que vous fournissez, comme un domaine de boutique ou un site web à analyser, l'adresse est validée selon son schéma, son port et la résolution de chacune des adresses IP vers lesquelles elle pointe, en rejetant les plages loopback, privées, link-local, NAT de classe opérateur et de métadonnées cloud. Les redirections sont gérées de sorte qu'un hôte public ne puisse pas renvoyer une requête vers un hôte interne.
• Sécurité des liens publics. Les liens de devis destinés aux clients reposent sur 256 bits d'aléa cryptographiquement sûr. Les propriétaires peuvent régénérer un lien, ce qui invalide immédiatement l'ancien et enregistre une empreinte irréversible de celui-ci à des fins d'audit. Les recherches de jetons infructueuses sont limitées afin que le point de terminaison ne puisse pas être attaqué par force brute, et les jetons sont masqués partout où ils apparaîtraient autrement dans les journaux ou les vues d'administration.
• Autorisations d'intégration limitées au strict nécessaire. Les intégrations ne demandent que les autorisations nécessaires à leurs fonctionnalités, et plusieurs sont en lecture seule par conception, notamment QuickBooks Online et Jobber. Les analyses de facturation utilisent une clé distincte, restreinte et en lecture seule auprès du prestataire de paiement, afin qu'une vue analytique ne puisse jamais modifier l'état de la facturation.
• Cloisonnement des données de paiement. Les numéros de carte ne parviennent jamais à VERA. Le paiement est encaissé sur la page de paiement hébergée par Stripe et géré via le portail de facturation de Stripe, de sorte que les systèmes de VERA ne se trouvent pas sur le circuit des données des titulaires de carte.
• Configuration sécurisée par défaut. La validation au démarrage refuse de s'exécuter en production avec le secret de session de développement, sans secret de session ou sans clé de chiffrement dédiée aux secrets, et signale les intégrations à moitié configurées qui échoueraient silencieusement.
• Sauvegardes chiffrées quotidiennes. La base de données de production est exportée une fois par jour, chiffrée en AES256 avant de quitter la machine qui l'a produite, et stockée séparément du fournisseur de base de données. Chaque exécution restaure ensuite la copie chiffrée qu'elle vient de produire dans une base de données jetable et échoue si cette restauration échoue ou revient vide : une sauvegarde n'est donc comptabilisée qu'une fois restaurée. Les sauvegardes sont conservées 30 jours, et la restauration à un instant donné proposée par le fournisseur de base de données couvre les heures intermédiaires.
• Suspension du compte. Un compte compromis ou abusif peut être suspendu : tous les points d'accès authentifiés sont alors refusés et les sessions actives révoquées, sans suppression de données et sans que la mesure soit irréversible.

3. Ce qui n'est pas encore en place

Ce sont des contrôles sur lesquels un évaluateur de sécurité pourrait légitimement s'interroger. VERA n'en dispose pas aujourd'hui. Nous les énumérons plutôt que de laisser le lecteur déduire leur présence de la section ci-dessus.

• Aucune certification. VERA n'a réalisé aucun audit SOC 2 de type I ou de type II, n'est pas certifiée ISO 27001, ne dispose d'aucun programme de business associate HIPAA et n'a pas fait l'objet d'une évaluation PCI DSS en son nom propre. Le traitement des cartes de paiement est entièrement délégué à Stripe.
• Pas d'authentification multifacteur. VERA ne propose actuellement ni authentification à deux facteurs, ni application d'authentification, ni clé matérielle, ni passkey. La connexion avec Google bénéficie de la protection multifacteur que vous avez configurée sur votre compte Google, ce qui constitue actuellement l'option la plus sûre disponible.
• Pas d'authentification unique. Il n'existe pas d'authentification unique (SSO) d'entreprise SAML ou OIDC, ni de provisionnement SCIM.
• Pas de gestion des utilisateurs via un annuaire. Les membres de l'équipe sont invités et gérés dans VERA. Il n'existe aucun provisionnement ni déprovisionnement automatique depuis un fournisseur d'identité : retirer une personne de votre propre annuaire ne lui retire donc pas son accès à VERA. Vous devez également la désactiver dans VERA.
• Pas de test d'intrusion indépendant ni de programme de bug bounty. VERA n'a pas fait réaliser de test d'intrusion par un tiers et ne gère pas de programme de bug bounty rémunéré.
• Pas de clés de chiffrement gérées par le client. Les clés de chiffrement sont gérées par VERA. L'utilisation de vos propres clés (BYOK) n'est pas disponible.
• Pas de choix de localisation des données. Les données sont traitées aux États-Unis. Il n'existe aucune option d'hébergement dans l'UE ni d'hébergement régional.
• Pas d'archive de sauvegarde à long terme. Les sauvegardes quotidiennes sont conservées 30 jours. Il n'existe aucune archive mensuelle ou annuelle, aucune troisième copie hors site, ni aucune restauration d'un compte individuel à partir d'une sauvegarde : une restauration rétablit l'ensemble de la base de données. Il s'agit donc d'une mesure de réponse aux incidents, et non d'un service de récupération proposé aux clients.
• Pas de centre d'opérations de sécurité 24 h/24, 7 j/7. Il n'existe pas de centre d'opérations de sécurité doté de personnel 24 h/24, pas de système d'astreinte formel communiqué aux clients, ni de produit de détection d'intrusion au-delà des contrôles applicatifs énumérés ci-dessus.
• Aucun engagement de disponibilité. VERA ne propose pas d'accord de niveau de service. Consultez les Conditions d'utilisation.

4. Infrastructure

VERA fonctionne comme une application Next.js conteneurisée sur Node.js, déployée à partir d'une compilation multi-étapes qui produit une image d'exécution autonome, et reposant sur une base de données PostgreSQL managée. Un point de terminaison de contrôle de santé est exposé pour la surveillance de la plateforme.

Les photographies téléversées, les images générées et les documents importés sont stockés sous forme de données encodées dans la base de données de l'application, plutôt que dans un service de stockage d'objets distinct. Il n'existe donc aucun bucket configuré séparément qui pourrait être laissé accessible publiquement en lecture, et le stockage des fichiers hérite du chiffrement au repos, quel qu'il soit, appliqué par le fournisseur de la base de données.

L'hébergement, la protection au niveau du réseau et la sécurité physique sont assurés par les fournisseurs de plateforme mentionnés dans la Liste des sous-traitants, dans le cadre de leurs propres programmes de sécurité. VERA n'exploite pas ses propres centres de données.

5. Surveillance et réponse aux incidents

La journalisation des applications et des erreurs est active en production, et la console d'opérations interne affiche l'état du système, le statut des tâches en arrière-plan, les échecs d'intégration ainsi qu'un panneau de sécurité qui signale des éléments tels que l'arriéré de liens de devis utilisant encore un ancien format de jeton.

Si nous prenons connaissance d'un incident de sécurité affectant des données clients, nous menons une enquête, le circonscrivons et évaluons les données concernées. Pour les données personnelles traitées pour le compte d'un client professionnel, VERA informe le client concerné dans les meilleurs délais et au plus tard 72 heures après en avoir pris connaissance, conformément à l'Avenant relatif au traitement des données. Les notifications aux autorités de contrôle et aux personnes concernées relèvent de la responsabilité du responsable du traitement, et nous l'assistons dans cette démarche.

VERA ne publie actuellement ni page d'état ni historique public des incidents.

6. Signaler une vulnérabilité

Signalez les problèmes de sécurité à support@meetmyvera.com avec l'objet « Security report ». Fournissez suffisamment de détails pour reproduire le problème : l'URL ou la fonctionnalité concernée, les étapes à suivre et l'impact que vous estimez qu'il a. Les échanges chiffrés sont les bienvenus ; demandez-le-nous et nous les mettrons en place.

Nous nous efforçons d'accuser réception d'un signalement sous 3 jours ouvrés et de fournir une évaluation sous 10 jours ouvrés. Nous vous tiendrons informé pendant que nous travaillons à un correctif et vous préviendrons lorsqu'il sera déployé. Nous serons heureux de vous remercier publiquement si vous le souhaitez.

7. Divulgation responsable et protection juridique

Si vous étudiez la sécurité de VERA de bonne foi et dans les limites indiquées ci-dessous, nous n'engagerons aucune action en justice contre vous et considérerons vos recherches comme autorisées au regard de la législation applicable en matière d'utilisation abusive des systèmes informatiques. Nous vous demandons de :

• Testez uniquement votre propre compte. Utilisez un compte que vous avez créé. N'accédez pas aux données d'un autre client, ne les modifiez pas et ne les conservez pas. Si vous tombez par inadvertance sur les données de quelqu'un d'autre, arrêtez-vous, ne les enregistrez pas et informez-nous de ce qui s'est passé.
• Éviter de nuire. Pas de déni de service, pas de tests de charge ou de stress, pas de spam, pas d'ingénierie sociale visant notre personnel ou nos clients, et pas d'attaques physiques.
• N'utilisez pas de scanners automatisés à grande échelle. Une analyse automatisée agressive ne se distingue pas d'une attaque et vous vaudra une limitation de débit ou un blocage.
• Laissez-nous du temps. Signalez le problème en privé et laissez-nous un délai raisonnable pour le corriger avant de le divulguer. Notre délai de référence est de 90 jours ; nous sommes généralement bien plus rapides et vous préviendrons si une correction demande plus de temps.
• Pas d'extorsion. Retenir des informations en attendant un paiement ne constitue pas un signalement de sécurité. VERA ne gère aucun programme de bug bounty rémunéré et ne peut offrir aucune récompense.

8. Votre rôle

Utilisez un mot de passe robuste et unique, et privilégiez la connexion avec Google si l'authentification multifacteur est activée sur votre compte Google, car VERA ne propose pas encore la sienne.

Ne partagez pas vos identifiants. Donnez à chaque personne qui a besoin de VERA son propre compte autorisé en l'invitant et en lui attribuant un rôle, plutôt que de distribuer un identifiant de connexion : les identifiants du titulaire du compte, s'ils sont partagés, donnent un accès complet, y compris à la facturation et à chaque plateforme connectée, et empêchent l'historique d'activité d'indiquer qui a réellement fait quoi. Désactivez un membre dès qu'il n'a plus besoin d'accès.

N'accordez des intégrations que lorsque vous avez besoin de la fonctionnalité, et déconnectez celles que vous n'utilisez plus. Régénérez un lien de devis s'il a été transféré là où vous ne le souhaitiez pas. Consultez votre journal d'audit si quelque chose vous semble anormal, et prévenez-nous à support@meetmyvera.com si vous soupçonnez un accès non autorisé.