Guide de bonnes pratiques pour un développement sécurisé
Ce présent guide est référencé par le processus "Développer une application informatique", qui s'applique obligatoirement aux applications répondant à l'un des critères suivants :
- Diffusion large: Destinées à plusieurs filières, services, écoles ou partenaires externes.
- Données sensibles: Manipulant des données personnelles ou confidentielles.
- Intégration IT: Se connectant aux ressources informatiques de la HES-SO Fribourg.
- ex: comptes utilisateurs internes, ceux-ci doivent provenir des annuaires de la HES-SO Fribourg.
Ce processus ne s'applique pas aux applications strictement limitées à un usage interne et à petite échelle, telles que :
-
Outils pédagogiques: Développés dans le cadre de la formation ou de la Ra&D.
-
Applications locales: Utilisées par un petit groupe d'utilisateurs. (interne filière)
Les développements strictement limitées à un usage interne sont autorisés sous réserve de respecter les conditions suivantes :
- Conformité: Le développement doit être conforme à l'ensemble des lois et réglementations en vigueur (RGPD, LPD, nLPrD, etc.) ainsi qu'aux normes de sécurité informatique de la HES-SO Fribourg.
- Portée limitée: L'application développée doit être exclusivement destinée à un usage interne et restreint à la filière concernée, sans perspective d'extension à d'autres entités.
- Autonomie: La filière assure seule la prise en charge du développement, du support, de la maintenance et des coûts associés.
Guide DevSecOps
Gérer les secrets de manière sécurisée: Il est recommandé d’utiliser un gestionnaire de secrets (ex: Devolutions : Gestionnaire de mots de passe Entreprise). Il convient également de s’assurer de l’absence de secrets en dur dans le code source, dans les journaux d’événements des tâches (jobs), ou dans les dépôts de code.
Prévoir des tests de sécurité automatisés dans le processus CI/CD: Tests de non régression (pour éviter de nouvelles vulnérabilités), étanchéité entre profils d’utilisateurs, tests d’analyses statique et dynamique, tests de conformité de l’IaC (Infrastructure as Code).
Sécuriser le déploiement en production des applications en maintenant l’intégrité du code source de bout en bout, en signant et vérifiant les signatures des tags de version des artefacts.
Implémenter une authentification multifacteur pour l’accès aux dépôts de code et pour la signature des commits.
Séparer les infrastructures CI/CD de développement et de production et ne pas les exposer directement sur Internet.
Réinstancier régulièrement l’infrastructure CI/CD et ne pas y stocker de données persistantes.
Être vigilants sur les besoins en confidentialité vis-à-vis de l’infrastructure de CI/CD (ex. : localisation, tests du code source en SaaS public).
Valider les entrées: Autoriser uniquement les chaines autorisées. Quand le champ est un champ date, on peut saisir qu’une date à un format strictement défini.
Toutes les données doivent être nettoyées et saines avant d’être envoyés à d’autres applications ou systèmes.
Respecter et appliquer le principe du moindre privilège: une tâche ne doit bénéficier que de privilèges strictement nécessaires. N’imposez pas une élévation des privilèges. Toute modification des accès doit être encadrée.
Défense en profondeur : la sécurité, et particulièrement le secure by design, se fait à plusieurs niveaux. La défense en profondeur se pense et s’applique à tous les éléments de votre environnement et vos applications.