Une sécurité sur laquelle tout votre établissement peut compter.

Les mots de passe sont stockés sous forme de hachages irréversibles

Les mots de passe sont hachés avec Argon2id — l’algorithme conçu pour être lent et gourmand en mémoire, précisément afin de contrecarrer les tentatives de cassage — et seul le hachage est stocké. Il n’existe aucun moyen de revenir au mot de passe d’origine : c’est pourquoi nous pouvons aider une personne à réinitialiser son mot de passe, mais jamais lui communiquer l’ancien.

• Changer de mot de passe exige le mot de passe actuel, et sa réutilisation est refusée
• Une réinitialisation réussie révoque immédiatement toutes les sessions existantes de ce compte

Les tentatives à répétition verrouillent le compte

Cinq tentatives de connexion échouées en quinze minutes verrouillent le compte pendant quinze minutes. Le verrouillage est enregistré avec le compte plutôt que conservé en mémoire : il survit donc aux redémarrages et ne peut pas être esquivé en s’adressant à un autre serveur.

• Le verrouillage couvre toutes les voies d’accès — connexion par adresse e-mail comme par nom d’utilisateur
• Le titulaire du compte est prévenu, dans l’application et par e-mail, lorsque son compte est verrouillé

Les sessions sont de courte durée et font l’objet d’une rotation

Le jeton qui autorise les requêtes courantes est valable quinze minutes. Son renouvellement passe par un jeton d’actualisation distinct, échangé contre un nouveau à chaque fois, sans exception : un jeton d’actualisation intercepté est donc déjà consommé au moment où quelqu’un tente de s’en servir.

• Les jetons d’actualisation sont conservés dans un cookie que le navigateur ne laisse pas lire par JavaScript, marqué Secure et SameSite, et limité aux seuls points de terminaison de connexion
• Chaque jeton d’actualisation est suivi côté serveur et peut être révoqué ; le motif est conservé — rotation, déconnexion, expiration, signature non concordante, compte désactivé, mot de passe réinitialisé
• La falsification de requête intersites est bloquée par ce cookie SameSite, et les points de terminaison de connexion n’acceptent que les requêtes venant de nos propres sites

Un second facteur est disponible, et un établissement peut l’imposer

Le personnel, les administrateurs et les parents peuvent ajouter une application d’authentification à leur connexion : un code à six chiffres renouvelé toutes les trente secondes, complété par dix codes de secours à usage unique. Il n’existe volontairement aucun facteur par SMS ou par e-mail, tous deux plus faibles que le mot de passe qu’ils renforceraient, et le secret qui le sous-tend est lui-même chiffré au repos.

• Un établissement peut l’imposer à chaque membre du personnel, c’est-à-dire à toute personne détenant un rôle autre qu’élève, ancien élève ou parent, avec un délai de grâce d’aucun, trois, sept, quatorze ou trente jours, qui court à partir de la date d’arrivée pour une personne arrivée plus tard
• Une fois l’échéance passée, le serveur refuse les requêtes de ce compte vers l’établissement et ne laisse ouverts que ses propres réglages de compte, la déconnexion et la configuration du second facteur, et le personnel ne peut pas le désactiver tant que l’établissement l’impose
• Un établissement ne peut réinitialiser un second facteur perdu que pour un compte utilisé chez lui seul, en indiquant un motif ; seul le propriétaire peut réinitialiser un administrateur, et personne dans l’établissement ne peut réinitialiser le propriétaire
• Chaque réinitialisation est inscrite au journal d’audit et signalée par e-mail au titulaire du compte ; les élèves et les anciens élèves ne peuvent pas détenir de second facteur, et pour les parents il reste facultatif

Les liens de réinitialisation du mot de passe sont à usage unique et expirent

Un lien de réinitialisation n’est stocké que sous forme de hachage — le lien contenu dans l’e-mail en est le seul exemplaire — et il est marqué comme utilisé dès qu’il est employé. Il expire une heure après son émission, qu’il ait été utilisé ou non.

Le service refuse de démarrer dans une configuration non sécurisée

Une erreur de configuration est un moyen discret de perdre tout ce qui précède ; c’est pourquoi, en production, le démarrage vérifie les paramètres essentiels et échoue de façon explicite plutôt que de fonctionner en mode dégradé. Un déploiement dépourvu de cookies de session sécurisés, de clés de signature ou de la clé de chiffrement des données ne démarre pas du tout.

Chaque requête fait l’objet d’une autorisation individuelle

Les points de terminaison protégés passent par un contrôle de politique d’accès qui évalue les rôles de l’appelant au regard de l’action exacte que représente la requête, avant l’exécution de tout gestionnaire. Il n’existe pas de niveau « connecté, donc autorisé » : si rien n’accorde l’action, la requête est refusée, et le refus est consigné.

C’est vous qui façonnez les rôles

Les établissements partent de rôles prêts à l’emploi et peuvent créer les leurs grâce à un générateur de rôles visuel qui se lit comme une phrase plutôt que comme une matrice d’autorisations. Les autorisations sont granulaires — par module, par action — afin que l’accès corresponde à un véritable poste plutôt qu’au modèle approximatif le plus proche.

• Les autorisations d’un module que l’établissement n’a pas activé ne peuvent tout simplement pas être accordées
• Les modifications de qui détient quels droits sont elles-mêmes des événements auditables, et déclenchent une alerte de sécurité

Le portail depuis lequel vous agissez entre dans la décision

Une même personne peut être à la fois membre du personnel et parent. Chaque requête déclare le portail au titre duquel elle agit, et cet élément est pris en compte dans la décision d’autorisation : une session du portail parents ne peut donc pas atteindre les données côté personnel, même lorsque la personne derrière elle travaille aussi dans l’établissement.

Le personnel voit les élèves dont il a la charge

Au-delà des autorisations par module, les élèves qu’un membre du personnel peut voir sont restreints par des critères déclarés — classe, cycle, statut, maison, etc. — appliqués au sein même de la requête de base de données. Un professeur de matière ou un professeur principal qui tente d’accéder à une classe qui ne lui est pas attribuée est refoulé par un contrôle dédié.

L’administration de la plateforme est un monde à part

Notre propre interface de super-administration est un contexte distinct, avec sa propre session, sa propre portée de cookies et son propre ensemble d’autorisations. Ce n’est pas un mode privilégié d’un compte d’établissement, et on ne peut pas y parvenir en élevant les privilèges d’un tel compte.

L’établissement vient de la session signée

Chaque requête s’exécute sous l’établissement inscrit dans le jeton de session signé de la personne, et non sous une valeur fournie par son navigateur. Une requête qui désigne un autre établissement est refusée avant l’exécution de tout gestionnaire.

Chaque requête est limitée à cet établissement

L’accès aux données passe par une couche de dépôts partagée — près de trois cents dépôts reposent sur elle — qui ajoute l’établissement à chaque requête qu’elle construit, et refuse catégoriquement d’exécuter une requête d’établissement qui n’en désigne aucun.

Les opérations entre établissements sont explicites

Les opérations de la plateforme qui couvrent légitimement plusieurs établissements, comme les tâches planifiées, passent par des méthodes nommées à part. Franchir la frontière entre établissements est un choix visible dans le code, et non quelque chose qu’une requête ordinaire peut faire par accident.

Chiffrement en transit

Tout le trafic passe par TLS. En production, nous envoyons un en-tête Strict-Transport-Security d’une durée de six mois, couvrant les sous-domaines et marqué pour le préchargement, de sorte que les navigateurs refusent de se connecter en HTTP simple, ne serait-ce qu’une seule fois.

Chiffrement au repos — et à nouveau, au niveau des champs

La base de données et le stockage de fichiers sont chiffrés au repos par défaut. En plus de cela, les textes libres les plus sensibles que détient un établissement sont chiffrés séparément avec AES-256-GCM avant même d’être écrits, de sorte qu’ils sont illisibles pour tout ce qui lit le stockage sous-jacent — 167 colonnes réparties sur 79 tables.

• Sont concernés : les dossiers de protection de l’enfance et les dossiers disciplinaires, les notes de l’infirmerie et les notes médicales, les informations médicales de l’internat, les dossiers et réclamations RH, les notes de recrutement, les notes et adresses des responsables légaux et des élèves, les pièces d’admission et de transfert, ainsi que les sujets et réponses d’examens
• Chaque valeur porte son propre vecteur d’initialisation, et la colonne à laquelle elle appartient est liée au chiffrement lui-même : un texte chiffré ne peut donc pas être déplacé d’un champ à un autre
• Les clés peuvent faire l’objet d’une rotation sans interruption de service, grâce à une passe de rechiffrement qui peut reprendre là où elle s’est arrêtée ; la production ne démarre pas sans la clé

Ce qui n’est délibérément pas chiffré, et pourquoi

Un texte chiffré ne peut être ni recherché, ni trié, ni filtré. Plutôt que de chiffrer un champ et de casser en silence la fonctionnalité qui en dépend, un petit ensemble de colonnes est volontairement laissé en clair — treize au total, comme le corps des messages et les champs sur lesquels repose la recherche RH — et chacune est consignée, avec sa justification, dans le registre même qui pilote le chiffrement. Lorsque nous pouvions plutôt restreindre une recherche, nous l’avons fait : plusieurs récits de dossiers sont désormais chiffrés, car leurs vues en liste effectuent la recherche sur la référence et la catégorie plutôt que sur le récit lui-même.

Le registre est vérifié par le compilateur et par le build

Un registre unique fait foi pour déterminer quelles colonnes sont chiffrées ; le code qui chiffre, le rattrapage des données existantes et la rotation des clés en dérivent tous, et toute incohérence provoque une erreur de compilation. Un contrôle bloquant du build détecte les trois choses que les types ne peuvent pas voir — une entrée sans chiffrement associé, une colonne du mauvais type et une colonne à la fois chiffrée et interrogée.

Les fichiers sont chiffrés, et les liens qui y mènent expirent

Les fichiers téléversés sont chiffrés par le service de stockage à l’écriture, et cette exigence est inscrite dans l’autorisation de téléversement signée, si bien qu’un navigateur ne peut pas s’y soustraire. Les fichiers ne sont jamais publics : chaque consultation passe par un lien signé qui expire — une heure pour la plupart des téléchargements (un jour pour les pièces jointes des messages, une semaine pour les photos de profil et les logos d’établissement), quinze minutes pour les téléversements.

Les requêtes sont validées, et les champs inconnus sont supprimés

Chaque corps de requête est validé par rapport à une structure déclarée avant qu’un gestionnaire n’y ait accès, et toute propriété qui ne fait pas partie de cette structure est retirée plutôt que transmise. L’accès à la base de données passe systématiquement par des requêtes paramétrées, de sorte que les valeurs ne sont jamais assemblées dans du SQL.

Les fichiers téléversés sont inspectés avant d’être stockés

Les fichiers téléversés sont contrôlés au regard de la taille maximale et des types de contenu qu’accepte chaque fonctionnalité. Les pièces jointes des messages, par exemple, sont limitées aux images, aux PDF et aux présentations de 5 Mo au plus chacune.

Les notifications de paiement sont vérifiées cryptographiquement

Les webhooks de notre prestataire de paiement sont vérifiés au moyen d’une signature calculée sur le corps brut de la requête et comparée en temps constant. Une notification non signée ou altérée est rejetée : personne ne peut donc fabriquer un paiement de toutes pièces en appelant le point de terminaison.

Le grand livre financier est signé

Les écritures de crédit et de portefeuille portent des signatures d’intégrité et sont chaînées à l’écriture précédente, avec des domaines de signature distincts pour les soldes et pour les écritures, afin que l’un ne puisse jamais être rejoué à la place de l’autre. Un enregistrement financier modifié en silence échoue à la vérification.

La surface de l’API reste réduite en production

La documentation interactive de l’API n’est servie qu’en dehors de la production. L’accès depuis d’autres origines est limité à celles que nous configurons, et une requête modifiant l’état qui arrive sans origine autorisée est refusée.

Le journal est écrit là où la décision est prise

Les entrées d’audit sont émises au point même où la requête est autorisée. L’enregistrement inclut donc les tentatives refusées — les entrées dont une enquête a généralement le plus besoin, et celles qu’un journal d’audit greffé après coup omet généralement.

Les entrées sont scellées et chaînées

Chaque entrée est scellée par une signature à clé calculée sur un ensemble fixe de ses champs, et liée à l’entrée qui la précède. Modifier un enregistrement, ou en supprimer un, rompt la chaîne à partir de ce point — la falsification est donc détectable plutôt qu’invisible. La forme canonique est versionnée, de sorte qu’améliorer ce que nous enregistrons n’invalide jamais l’historique déjà scellé.

La chaîne est résumée chaque jour

Chaque jour, la dernière portion de la chaîne est scellée dans un condensé signé et écrite dans le stockage de fichiers, hors de la base de données. Si la base de données était un jour altérée, les condensés fourniraient une trace distincte de ce qu’était l’historique.

Les journaux restent lisibles, et leur volume reste maîtrisé

L’auteur d’une action est enregistré sous forme d’instantané au moment où elle a eu lieu, de sorte qu’un journal garde tout son sens après un changement de rôle ou de nom. La durée de conservation est paramétrable, avec la possibilité d’archiver avant toute suppression.

Les établissements peuvent consulter leur propre journal

Il ne s’agit pas d’un outil réservé à un usage interne. Le journal d’audit est une fonctionnalité de la plateforme : les établissements peuvent rechercher dans leur propre historique par personne, action, ressource et date, et l’exporter.

L’activité est agrégée en métriques

L’activité d’audit est agrégée en métriques de séries temporelles ventilées par établissement, service, action et type de ressource ; c’est ce qui fait d’« inhabituel » un constat mesurable plutôt qu’une impression.

Les alarmes se déclenchent sur des changements durables, pas sur de simples pics

Chaque alarme additionne sa métrique sur une fenêtre glissante et change d’état après le nombre de relevés en dépassement configuré pour elle, de sorte qu’elle peut être réglée pour ignorer un pic momentané sans manquer une tendance qui s’installe lentement.

Les événements liés à la sécurité déclenchent des alertes

Les connexions suspectes, les schémas d’attaque par force brute, les modifications d’autorisations et d’accès, les exportations massives de données et les activités inhabituelles déclenchent chacun une alerte de sécurité graduée, acheminée vers les personnes qui doivent en avoir connaissance.

Les données d’authentification n’apparaissent jamais dans les journaux

Les en-têtes d’autorisation, les cookies et les jetons CSRF sont masqués au niveau du module de journalisation lui-même plutôt qu’à chaque point d’appel, de sorte qu’une seule ligne de journal malencontreuse ne peut pas inscrire une session active dans nos journaux.

Chaque modification est analysée avant de pouvoir être fusionnée

Les pull requests déclenchent une recherche de secrets sur l’ensemble du dépôt, un examen des dépendances nouvellement introduites et un audit qui échoue en cas de vulnérabilité de gravité élevée dans tout ce dont nous dépendons.

Les garde-fous ont leurs propres contrôles bloquants

Le pipeline d’intégration continue vérifie que les rôles limités le restent, que le registre des colonnes chiffrées et le code concordent, que les migrations permettent de provisionner une base de données à partir de zéro et que les frontières architecturales sont respectées — en plus de la vérification des types et des tests unitaires, d’intégration et de bout en bout.

Des valeurs par défaut sûres, des modifications relues

Les modifications sont relues avant d’être intégrées, et les valeurs par défaut sont choisies pour rester sûres en cas d’oubli : le refus plutôt que l’autorisation, la validation plutôt que la confiance, et les contrôles au démarrage plutôt que les dégradations silencieuses.

Le moindre privilège, au sein de l’entreprise aussi

L’accès interne aux systèmes de production est limité à ce qu’exige une tâche, accordé de manière restreinte et retiré lorsque les rôles évoluent. Personne n’a besoin d’une clé permanente vers les données d’un établissement pour faire son travail.

Une infrastructure reconnue et gérée

La plateforme fonctionne sur une infrastructure cloud éprouvée, avec une isolation réseau et des accès internes strictement délimités, et s’appuie sur des services gérés pour la base de données et le stockage de fichiers, afin que les correctifs et le durcissement à ce niveau soient assurés par des spécialistes plutôt qu’improvisés par nous.

Chaque sous-traitant ultérieur est nommé

Les entreprises susceptibles de traiter des données à caractère personnel pour le compte d’un établissement — infrastructure, stockage et hébergement de la base de données, traitement des paiements, envoi d’e-mails et de SMS — figurent dans un registre public, avec ce que chacune traite et où. En ajouter une passe par une modification de ce registre, et non par un discret changement de configuration.

Le navigateur reçoit des consignes strictes

Nos pages sont servies avec une politique de sécurité du contenu, une sécurité de transport stricte, une politique no-referrer et une protection du type de contenu ; elles ne peuvent pas être affichées dans un cadre par d’autres sites, et renoncent aux fonctionnalités du navigateur dont elles n’ont pas besoin — caméra, microphone, géolocalisation, paiement et USB sont tous refusés d’office.

L’établissement maîtrise ses données

Votre établissement est le responsable du traitement et nous sommes le sous-traitant : nous agissons sur vos instructions, dans le but de fournir le service, et pour rien d’autre. Nos conditions relatives au traitement des données l’exposent intégralement, y compris ce qui se passe lorsqu’un contrat prend fin.

Nous ne les vendons pas, et n’en tirons aucune publicité

Nous ne vendons pas d’informations personnelles, et nous n’utilisons jamais les données des enfants à des fins de publicité ou de profilage. Il n’y a ici aucune activité publicitaire à alimenter, et il n’y en aura pas.

Nous demandons le moins possible

La plateforme collecte ce que le fonctionnement d’un établissement exige réellement, et rien de plus. Lorsqu’un champ est facultatif, il reste facultatif, et les données dont un établissement n’a plus besoin peuvent être supprimées selon ses propres choix en matière de conservation.