Sécurité et protection des données chez ROSIE
Chiffrement
| Niveau | Mesure |
|---|---|
| Transmission | TLS pour toutes les connexions, HSTS imposé (sous-domaines compris, preload) |
| Stockage | Les champs confidentiels tels que diagnostics, certificats médicaux, données de protection de la maternité, numéro AVS et IBAN sont chiffrés individuellement (AES-GCM) ; les sauvegardes horaires sont chiffrées (age) |
| Niveau du champ | Chiffrement AES-GCM (256 bits) pour les champs particulièrement sensibles, par exemple les secrets 2FA et les justifications libres dans les réglages |
| Journaux d’audit | Le journal lui-même est protégé contre une modification inaperçue par la chaîne de hachage, il n’est pas chiffré. Les justifications libres et les références qu’il contient sont chiffrées avec la même clé de champ (pas de clé séparée). |
En toute transparence : ne sont notamment pas chiffrés individuellement les données salariales (salaire mensuel, taux horaire), la date de naissance, le nom, l’adresse e-mail et le numéro de téléphone, les plannings ainsi que le type, les dates et le statut des absences (seuls le motif, les notes et la pièce jointe du certificat médical sont chiffrés). Ces données sont protégées par la transmission chiffrée, les contrôles d’accès, la séparation des mandants et les sauvegardes chiffrées. Nous ne promettons pas de chiffrement du support de données entier. Le chiffrement de champs supplémentaires est prévu comme extension, sans date promise.
Accès et authentification
- Mots de passe : PBKDF2-SHA256 avec 100 000 itérations et sel de 32 octets — jamais en clair
- Sessions : JWT signés (HMAC-SHA256), validité de 8 heures, rotation des jetons de rafraîchissement
- Authentification à deux facteurs (TOTP selon RFC 6238) activable en option
- Contrôle d’accès basé sur les rôles (admin / planification / collaborateurs)
- Limitation du débit contre la force brute : 10 tentatives de connexion par 60 secondes et par IP
L’authentification unique (SSO/SAML/OIDC) n’est actuellement pas disponible. La connexion s’effectue par e-mail et mot de passe, avec authentification à deux facteurs (TOTP) en option, ou avec une clé d’accès (passkey). Le SSO est en cours d’évaluation ; aucune date ferme n’est fixée.
Séparation des mandants
Les données de chaque client sont traitées de manière logiquement séparée : chaque requête de base de données est liée à des claims de mandant vérifiés cryptographiquement (JWT) et filtrée côté serveur sur l’identifiant du mandant (isolation au niveau des lignes dans une base de données exploitée en commun). Les champs particulièrement sensibles sont en outre chiffrés au niveau du champ. Il n’existe pas de séparation physique par client.
Sauvegarde et restauration
- Sauvegardes horaires de la base de données, conservées 30 jours ; l’objectif est un point de restauration d’environ une heure au plus, ce n’est pas une promesse
- Chaque sauvegarde avec hachage d’intégrité SHA-256, compressée et chiffrée avec age, déposée dans un stockage objet en Suisse
- Exportation des données possible à tout moment par l’admin du mandant (export entier au format JSON)
Protection des données selon la nLPD
- Mise en œuvre des droits des personnes concernées selon la nLPD (accès, rectification, effacement, portabilité, opposition au profilage, révocation du consentement)
- Minimisation des données comme principe du produit : pas de profils de santé individuels, pas de profilage des jours de maladie, pas d’identification biométrique, pas de profils de déplacement
- La planification automatique utilise uniquement les souhaits d’horaire facultatifs, le taux d’occupation, les vacances approuvées et les absences du jour — jamais la fréquence historique des maladies ni l’état de santé
- Consentements granulaires, révocables à tout moment, par collaborateur
Auditabilité
Un journal d’audit côté serveur avec une chaîne de hachage SHA-256 rend visible la manipulation ultérieure d’entrées isolées. Il consigne qui a modifié quoi, quand et pourquoi — les modifications de paramètres juridiques exigent une justification.