1. Isolation des organisations
- Les données métier sont rattachées à un identifiant d’organisation (
tenant_id). - Les routes sensibles déterminent l’organisation effective à partir de la session authentifiée et appliquent ce périmètre aux lectures et aux modifications.
- Les rôles et autorisations sont contrôlés côté serveur ; une valeur envoyée par le navigateur ne suffit pas à obtenir un droit supplémentaire.
- Les parcours de démonstration utilisent un statut résolu côté serveur et restent séparés des organisations clientes.
2. Authentification et sessions
- Les mots de passe sont stockés sous forme dérivée avec PBKDF2-SHA-512, un sel aléatoire propre à chaque mot de passe et 210 000 itérations.
- La politique applicative exige au minimum 12 caractères, avec minuscule, majuscule, chiffre et caractère spécial.
- Les échecs de connexion sont comptabilisés et peuvent verrouiller temporairement le compte.
- Les jetons de session sont aléatoires et seul leur condensat SHA-256 est conservé en base.
- En production, les cookies de session utilisent les attributs HttpOnly, Secure et SameSite=Lax. Le nombre de sessions actives par utilisateur est limité.
- Les jetons de réinitialisation de mot de passe sont temporaires, hachés et utilisables une seule fois.
3. Contrôle des droits
- Les profils Administrateur, RH, Recrutement, Manager, Collaborateur, SuperAdmin et Démo disposent de périmètres distincts.
- Les opérations métier sensibles vérifient le rôle authentifié, le périmètre autorisé et l’organisation concernée.
- Les changements de rôle, les accès administratifs et les refus d’autorisation sont traçables dans les journaux d’audit prévus à cet effet.
4. Protection web et API
- Les services publics sont exposés en HTTPS et l’application active HSTS en production.
- Une politique de sécurité du contenu (CSP) limite les sources utilisables. Le cadrage externe et les objets embarqués sont refusés.
- Des en-têtes réduisent les risques de détournement de type MIME, d’intégration dans une frame, de fuite de référent et d’accès non nécessaire à la caméra ou à la géolocalisation.
- Les écritures exigent une origine autorisée ; CORS repose sur une liste d’origines autorisées.
- Des limites de fréquence protègent notamment l’authentification et les formulaires publics contre les abus automatisés.
- Les erreurs serveur renvoient un message générique en production et un identifiant d’incident, sans exposer la pile technique au navigateur.
5. Journalisation et supervision
Le Control Plane consolide des signaux opérationnels et de sécurité sur une fenêtre récente :
- connexions réussies, refusées et comptes verrouillés ;
- nouvelles origines réseau par rapport à l’historique connu ;
- changements de rôle et appels d’API sensibles ;
- erreurs serveur critiques ;
- accès Démo autorisés ou refusés, notamment codes absents, expirés, révoqués, réutilisés ou falsifiés.
Les alertes sont priorisées. Les identifiants sensibles tels que mots de passe, jetons, cookies et autorisations sont masqués dans les détails d’audit ; les empreintes d’e-mail et d’IP affichées par le centre de sécurité sont hachées.
6. Sauvegarde, restauration et rollback
- La procédure MySQL versionnée produit des sauvegardes cohérentes, inclut les objets nécessaires, chiffre les archives avec Age et les transfère vers un stockage objet OVH.
- Des sommes SHA-256 et des contrôles de taille servent à vérifier les archives transférées.
- Une procédure de vérification déchiffre une sauvegarde dans un espace temporaire, contrôle les sommes internes et teste les dumps sans remplacer la base active.
- Le déploiement utilise des répertoires de release et un lien de version active. Le script de rollback vérifie la santé et la disponibilité, puis revient automatiquement à la release précédente en cas d’échec.
7. Démonstrations et données temporaires
- L’accès libre à une plateforme de démonstration exige une autorisation validée côté serveur.
- Les codes expirés, révoqués, réutilisés ou falsifiés sont refusés et journalisés.
- Les organisations de démonstration sont identifiées séparément et leur nettoyage est prévu à la fin du parcours.
- Le simple mode de présentation interactive ne confère aucun accès à une organisation cliente.
8. Données, export et départ d’un client
- Les exports et opérations de départ sont soumis aux contrôles de rôle et d’organisation.
- Les exports CSV appliquent une neutralisation des valeurs susceptibles d’être interprétées comme des formules par un tableur.
- Les opérations sensibles sont conçues pour être auditables et ne reposent pas sur un identifiant d’organisation fourni librement par le navigateur.
9. Livraison du logiciel
- Les changements passent par Git, revue de pull request et contrôles CI avant intégration.
- Les migrations de schéma sont versionnées et séparées du compte d’exécution applicatif.
- Les secrets opérationnels sont fournis par l’environnement ou des fichiers protégés ; ils ne doivent pas être inscrits dans le dépôt.
- Les releases sont identifiées par un commit et restent disponibles pour un retour arrière contrôlé.
10. Responsabilités partagées et limites
La sécurité dépend aussi de l’entreprise cliente et de ses utilisateurs : gestion rigoureuse des comptes, attribution correcte des rôles, suppression rapide des accès devenus inutiles, confidentialité des identifiants et signalement des comportements inhabituels.
Yloria ne revendique sur cette page aucune certification ISO, qualification de sécurité ou invulnérabilité. Les audits, tests et contrôles réduisent le risque mais ne peuvent pas le supprimer entièrement.
11. Signaler un incident ou une vulnérabilité
Un incident, un accès suspect ou une vulnérabilité peut être signalé à support@yloria.fr. Merci de ne transmettre ni mot de passe, ni jeton, ni donnée personnelle complète. Indiquez seulement l’heure, la page concernée, l’action réalisée et, s’il existe, l’identifiant d’incident affiché.