Politique de sécurité des données

Introduction

Notre plateforme propose des services aux utilisateurs et entreprises (les Clients) pour accéder à leurs données internes via des logiciels d'IA propriétaires. Chaque Client bénéficie d'un environnement isolé au niveau L7 que nous appelons leur coffre-fort, offrant un haut niveau de sécurité tout en profitant du partage des ressources sous-jacentes. Toute donnée liée à l'entreprise sera stockée dans ce coffre-fort, chiffrée au repos et en transit.

Principes de sécurité

Un coffre-fort par locataire

Chaque locataire dispose de ce que nous appelons un coffre-fort dédié, matérialisé par un environnement isolé au niveau L7 grâce à un namespace Kubernetes unique. Dans ce namespace unique, nous déployons un ensemble dédié de :

• Base de données et bus de messages
• API privée
• Workers privés
• Partitions de disque dédiées pour toutes les données persistantes

Protection en profondeur avec le "modèle de l'oignon"

Notre stratégie de sécurité repose sur une approche de protection en profondeur, superposant plusieurs vérifications de sécurité sur toute la profondeur et l'étendue de notre infrastructure informatique, à l'image des couches d'un oignon. Cette méthode garantit que si un contrôle échoue, d'autres sont en place pour atténuer les menaces.

Vous pouvez imaginer cette stratégie comme les couches d'un oignon (voir l'image suivante).

Sécurité réseau

Nous utilisons des contre-mesures de niveau entreprise contre les attaques par déni de service distribué (DDoS) et des politiques de pare-feu applicatif (WAF) pour réduire notre surface d'attaque depuis l'extérieur.

Sécurité des terminaux

Nous appliquons une politique de zéro confiance pour sécuriser tous nos terminaux — externes et internes. Notre maillage de services impose cette politique de sécurité au niveau du cluster, garantissant que tous nos services internes et externes communiquent via des canaux sécurisés. Si l'un de nos services tente de communiquer en clair, notre maillage de services l'empêchera et terminera la communication avant même qu'elle n'envoie des paquets.

Sécurité des applications

Chaque locataire dispose d'un namespace isolé dans lequel le code de Documentalist s'exécute, ce qui entraîne une segmentation du réseau au niveau L7 entre les locataires. Cette politique est imposée par notre maillage de services, restreignant les communications entre namespaces et les attaches de volumes.

Notre stratégie de sécurité des conteneurs comprend plusieurs mesures pour réduire notre surface d'attaque :

1. Utilisation d'images Docker de base minimales
2. Exécution des conteneurs sous un utilisateur non-root
3. Analyse de nos conteneurs de production contre les vulnérabilités connues
4. Analyse de notre code source pour détecter les vulnérabilités de dépendances connues

Sécurité des données

Les données sont stockées dans des volumes isolés par locataire dans Kubernetes, ces volumes de stockage sont également liés au namespace du locataire et ne peuvent pas être attachés à un autre locataire par conception. Les données sont chiffrées au repos à l'aide du chiffrement AES-256, garantissant que les informations stockées sont sécurisées contre les accès non autorisés, et à l'avenir nos clients entreprises pourront demander l'utilisation de leurs propres clés de chiffrement — a.k.a. Bring Your Own Key (BYOK). Pour les données en transit, nous utilisons le chiffrement TLS 1.3 et des certificats émis par une autorité de certification de confiance (Let's Encrypt), protégeant les données à l'intérieur de votre coffre-fort ainsi qu'entre nos serveurs et les appareils des utilisateurs.

Sécurité physique

Notre sous-traitant IaaS (Scaleway) sécurise ses centres de données en appliquant la même approche de modèle en couches, limitant l'accès aux éléments critiques de son centre de données à une liste restreinte d'employés. Dans tous les cas, puisque nous chiffrons les données au repos, les données des clients sont protégées même en cas de violation des données au niveau du centre de données.

Contrôle d'accès

Au niveau de Documentalist, les contrôles d'accès sont imposés par des fournisseurs de gestion des identités et des accès (IAM) reconnus dans l'industrie tels que Google Workspace, Microsoft Active Directory, Okta, JumpCloud, pour n'en citer que quelques-uns. Le choix de l'IAM est fait par le client déployant un coffre-fort Documentalist.

En interne, le contrôle d'accès est géré selon le principe du moindre privilège, garantissant que les individus n'ont accès qu'aux données et ressources nécessaires à leur rôle.

Formation à la sécurité pour les employés

Des formations régulières à la sécurité pour le personnel, associées à une culture de sensibilisation à la sécurité, renforcent notre couche humaine de défense pour accroître notre résilience face aux menaces cybernétiques en constante évolution.

Politiques d'accès pour les sous-traitants

Nous effectuons toutes nos opérations sur Scaleway — certifié ISO-27001 — dans leurs centres de données en France.

Réponse aux incidents et protocole de violation

Préparation

Il est essentiel de se former à réagir rapidement à un incident, tout comme les exercices d'évacuation incendie dans les bureaux. Nous allons consacrer une semaine entière par semestre à nous entraîner à cela, en cassant intentionnellement des parties de notre plateforme. Plus techniquement, nous utiliserons notre maillage de services pour déclencher intentionnellement des disjoncteurs dans notre réseau de services et étudier notre plan de détection et de mitigation.

Détection

Notre stratégie de détection repose sur les outils de sécurité de Cloudflare, leader dans les pratiques de cybersécurité. De plus, nous surveillerons en permanence notre infrastructure pour détecter des modèles inhabituels dans l'utilisation de nos ressources Kubernetes.

Dès que l'équipe de sécurité atteindra une taille de deux employés, nous utiliserons le concept d'une équipe bleue et rouge — où l'équipe bleue défend et l'équipe rouge attaque.

Atténuation

Pour chaque risque identifié — à partir de notre modèle de menaces — nous développons et mettons en œuvre des stratégies de mitigation pour défendre notre service contre les menaces les plus importantes.

Notification

En cas de violation des données, nous nous engageons à :

• Notifier toutes les parties concernées dans les 72 heures suivant le début de l'incident ;
• Fournir un résumé transparent et non technique de ce qui s'est passé ;
• Expliquer notre réponse immédiate et notre plan de mitigation ;
• Guider les utilisateurs avec des actions pour protéger leurs comptes si nécessaire.

Analyse post-mortem

Une fois la vulnérabilité atténuée et nos utilisateurs impactés notifiés, nous pouvons commencer le processus systématique de rédaction d'un rapport post-mortem : une bonne pratique des équipes techniques pour recueillir toute la chronologie et les preuves ayant conduit à l'incident et apprendre de ces erreurs.

Un document post-mortem conduit souvent à la mise en œuvre de nouvelles couches de sécurité, grâce à la collaboration entre l'équipe de sécurité et l'équipe produit.

Amélioration continue

Nous réaliserons régulièrement des audits internes de tests de pénétration, afin de détecter et de corriger de manière proactive les problèmes de sécurité.

Contactez-nous à tout moment à [email protected] pour vos questions liées à la sécurité.