Sécurité chez SahelTech

SahelTech sépare la vitrine publique, l'identité, les applications métier et les services éditoriaux afin de réduire le périmètre d'impact d'un incident. Une compromission d'un composant ne doit pas donner automatiquement accès aux autres domaines.

Les services publics et authentifiés sont destinés à être accessibles via HTTPS. Les communications entre composants sensibles doivent utiliser des canaux protégés et les bases de données ne sont pas destinées à être exposées directement à Internet.

Le compte SahelTech peut utiliser plusieurs méthodes de connexion : mot de passe, Google Sign-In, authentification multifacteur, codes de récupération ou passkeys. Une méthode de connexion authentifie une identité mais ne donne pas à elle seule tous les droits applicatifs.

Pour certaines fonctions sensibles, SahelTech peut exiger un second facteur ou une confirmation renforcée appelée step-up. Les preuves de step-up sont conçues pour être temporaires et liées au contexte de l'opération lorsqu'elles sont utilisées.

Les sessions authentifiées sont destinées à rester isolées par application ou hôte. Les fonctions de gestion de compte peuvent permettre de consulter et révoquer des sessions ou appareils. Un changement de mot de passe ou un événement de sécurité peut entraîner l'invalidation de sessions existantes.

Dans les applications métier, l'accès peut dépendre d'une organisation, d'un rôle, d'un profil d'accès, de capacités et d'un périmètre. SahelTech cherche à appliquer le principe du moindre privilège : chaque utilisateur et chaque service ne doit recevoir que les droits nécessaires.

Les secrets d'infrastructure, clés OAuth, clés d'e-mail et identifiants techniques ne doivent pas être intégrés dans les bundles publics ou committés dans le dépôt. Ils sont destinés à être injectés depuis les environnements sécurisés des services concernés.

Les services peuvent enregistrer des événements techniques et de sécurité afin de diagnostiquer des erreurs, détecter des comportements anormaux, enquêter sur des incidents et assurer la traçabilité des opérations sensibles.

Les données persistantes critiques sont destinées à être sauvegardées selon leur niveau de sensibilité, idéalement avec une copie distincte de l'environnement principal et des tests de restauration périodiques. La vitrine statique, elle, reste reconstructible depuis son dépôt et son pipeline de build.

Si vous pensez avoir découvert une vulnérabilité ou un comportement de sécurité anormal, contactez [email protected] avec les informations nécessaires pour comprendre le problème.

Merci d'éviter l'accès aux données d'autres utilisateurs, la destruction de données, l'ingénierie sociale, le déni de service ou toute action susceptible de perturber le service.