Sécurité chez Lendbox

• Lendbox fonctionne sur Amazon Web Services dans la région us-east-1, aux États-Unis. L'application, la base de données et les documents téléversés dans Amazon S3 se trouvent tous dans cette région.
• Les données sont chiffrées en transit avec TLS 1.3.
• Les données sont chiffrées au repos avec AES-256. Les volumes de stockage de la base de données et de l'application sont chiffrés avec le chiffrement AWS EBS. Les documents téléversés et les sauvegardes sont chiffrés côté serveur dans Amazon S3. Les clés de chiffrement sont gérées via AWS Key Management Service.
• Les clients peuvent exporter l'intégralité de leurs données à tout moment depuis le produit. Aucune demande auprès de nous n'est nécessaire.

À la clôture d'un compte, les données du client sont conservées 60 jours puis définitivement supprimées. Pendant cette période, le compte peut être rétabli sur demande.

• L'application et la base de données fonctionnent sur une infrastructure AWS isolée. Les bases de données ne sont pas joignables publiquement et n'acceptent aucune connexion depuis Internet. La couche web est servie par Vercel.
• Tout le trafic entrant passe par Cloudflare, qui assure l'atténuation DDoS et un pare-feu applicatif web.
• Les environnements sont séparés : la production, la préproduction et le développement fonctionnent sur des infrastructures distinctes sans identifiants partagés. Le développement et la préproduction ne contiennent aucune donnée de production.

Les contrôles de cette section sont opérés par le client, pas par nous. L'institution les configure elle-même et peut vérifier à tout moment ce que chaque membre du personnel peut faire.

• Permissions graduées par module. Chaque module peut être réglé par membre du personnel sur l'un des six niveaux présentés ci-dessous.
• Attribution de rôles multi-agences. Un même compte peut recevoir l'accès à plusieurs agences et détenir un rôle différent dans chacune : un responsable d'agence à un endroit est un utilisateur en lecture seule ailleurs.
• Séparation demandeur-approbateur. Les actions sensibles sont réparties entre le membre du personnel qui les demande et celui qui les approuve. Les circuits d'approbation sont configurables par institution, y compris le nombre d'étapes et les rôles autorisés à agir à chaque étape.
• Authentification multifacteur. Disponible à chaque connexion, et activable indépendamment par chaque utilisateur et membre du personnel.
• Les sessions expirent après 5 jours et exigent une nouvelle authentification.

• Chaque action effectuée dans le produit est enregistrée avec l'utilisateur qui l'a réalisée, l'enregistrement concerné et un horodatage.
• Les enregistrements d'audit sont en ajout seul. Ils ne peuvent être ni modifiés ni supprimés depuis l'application, y compris par les administrateurs de l'institution.
• Les périodes comptables clôturées sont verrouillées contre toute modification rétroactive.
• Les administrateurs de l'institution peuvent exporter l'historique d'audit à tout moment.

L'historique d'audit est conservé pendant toute la durée de vie du compte, depuis sa date de création. Il n'y a ni fenêtre glissante ni troncature.

• Les bases de données sont sauvegardées toutes les heures.
• Les sauvegardes sont chiffrées et conservées 6 mois.
• Objectif de point de reprise (RPO) : 1 heure.

Les restaurations sont testées chaque semaine sur un environnement hors production. Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde.

• L'accès aux données de production est limité à une seule personne nommée, le fondateur. Aucun autre employé, prestataire ou tiers ne détient d'identifiants de production. C'est une décision de conception délibérée : c'est la plus petite surface possible de personnes pouvant atteindre les données des clients.
• L'accès à la production est nominatif et protégé par une authentification multifacteur. Aucun compte ni identifiant partagé n'est utilisé nulle part dans l'organisation.
• Les secrets et identifiants applicatifs sont gérés dans Doppler. Ils ne sont stockés ni dans le contrôle de version ni sur les postes des développeurs.
• Continuité : une procédure documentée de secours couvre le cas où la personne détenant les identifiants de production serait indisponible. Les identifiants de secours sont conservés sous séquestre scellé auprès d'un tiers nommé, libérés sur déclencheur défini, et chaque utilisation est journalisée. La procédure rétablit l'accès des clients à leurs propres données ; elle n'accorde d'accès permanent à personne.

Les vulnérabilités de sécurité sont corrigées selon des délais fonction de la gravité, comptés à partir du moment où la vulnérabilité est confirmée comme affectant Lendbox.

• Les dépendances applicatives sont surveillées en continu par Renovate, qui ouvre automatiquement des pull requests de correctifs dès la publication des versions en amont.
• Les mises à jour de dépendances sont revues et fusionnées selon un cycle hebdomadaire. Les avis assortis d'un exploit connu court-circuitent ce cycle et sont traités immédiatement.
• Les images de base du système d'exploitation et des conteneurs sont reconstruites et redéployées mensuellement, et immédiatement en cas de divulgation d'une vulnérabilité critique.

Les services listés ici traitent des données pour notre compte, sous contrat.

Les clients sont prévenus par e-mail au moins 30 jours avant l'ajout d'un nouveau sous-traitant ou le remplacement d'un sous-traitant existant, à l'adresse du contact administratif du compte.

Composants auto-hébergés

Les éléments suivants fonctionnent sur une infrastructure que nous contrôlons. Ils sont nommés parce qu'ils sont visibles pour quiconque inspecte le produit, mais ce ne sont pas des sous-traitants : aucun tiers ne reçoit de données par leur intermédiaire.

• La santé de l'infrastructure et de l'application est surveillée en continu avec Prometheus, Alertmanager et cAdvisor, les alertes étant acheminées vers un ingénieur d'astreinte.
• En cas d'incident de sécurité affectant des données clients, les clients concernés sont informés dans les 72 heures suivant la confirmation. Les notifications indiquent ce qui s'est passé, quelles données ont été touchées, ce que nous avons fait pour contenir l'incident, et l'action éventuellement requise du client.
• Les incidents de disponibilité sont publiés sur la page de statut pendant leur traitement, et non après leur résolution.

• Écrivez à [email protected]. Incluez les étapes de reproduction.
• Nous accusons réception de chaque signalement sous 3 jours ouvrés, et fournissons une évaluation de la gravité et du délai de correction prévu sous 10 jours ouvrés.
• Nous n'engageons pas de poursuites contre les chercheurs qui signalent de bonne foi, évitent les atteintes à la vie privée et la dégradation du service, et nous laissent un délai raisonnable pour corriger avant divulgation.
• Nos coordonnées lisibles par machine sont publiées sur /.well-known/security.txt.