Que faut-il vérifier avant le lancement ?
Votre date de lancement approche. Le produit fonctionne, l’équipe a testé les principaux parcours et vos clients sont prêts à l’utiliser. Une question appelle pourtant encore une réponse claire : quelles preuves avez-vous que leurs comptes et leurs informations sont protégés ?
Commencez par les contrôles d’accès, les données sensibles, les paramètres de déploiement et un plan de réponse en cas de problème. Testez ensuite les risques propres à votre produit, corrigez les failles qui comptent et vérifiez ces correctifs. Une revue de sécurité utile donne à la personne qui approuve la mise en production une décision compréhensible, y compris sur ce qui reste en suspens.
Voici notre checklist de départ, pensée pour une équipe produit. Adaptez le périmètre aux données que vous détenez, à votre architecture et aux conséquences d’une défaillance.
1. Définir ce que couvre la revue
Listez l’application web, les applications mobiles, les API, les outils d’administration et les intégrations externes. Incluez les différents rôles utilisateurs et les systèmes qui hébergent les données clients. Notez la version évaluée afin de pouvoir relier les constats à ce que vous déployez réellement.
Convenez de qui autorise les tests, des environnements qui peuvent être testés et du moment où les tests doivent s’arrêter. Utilisez des données clients synthétiques dès que possible. Pour toute intervention en production, convenez de garde-fous avec les responsables du service.
Appuyez-vous sur l’OWASP ASVS pour sélectionner des exigences de sécurité applicative vérifiables. Précisez la version et le périmètre dans l’évaluation. Votre équipe dispose ainsi d’une référence commune sur ce qui doit être prouvé.
2. Vérifier ce à quoi chaque personne a accès
Une connexion réussie n’est qu’un début. Un client ne doit accéder qu’à ses propres données, et un compte support ne doit disposer que des droits nécessaires à son travail. Appliquez ces décisions côté serveur pour chaque requête concernée, y compris les requêtes adressées directement à une API.
L’OWASP recommande le principe du moindre privilège, le refus d’accès par défaut et la validation des autorisations à chaque requête. Construisez les contrôles autour des relations réelles de votre produit. Consultez les recommandations de l’OWASP sur l’autorisation.
- Testez l’accès entre deux comptes clients et, le cas échéant, entre deux organisations.
- Vérifiez ce qui se passe après un changement de rôle ou la désactivation d’un compte.
- Examinez l’accès administrateur et la récupération de compte avec le même soin que la connexion.
3. Suivre les données sensibles à travers le système
Suivez une requête client typique depuis le navigateur ou l’application jusqu’à l’API, la base de données et le service tiers. Identifiez où les données personnelles et les identifiants sont stockés, copiés ou journalisés. Cela rend souvent la revue plus facile à expliquer aux ingénieurs comme au responsable métier.
Gardez les secrets de service hors des bundles frontend et du contrôle de version. Limitez les permissions de chaque identifiant, séparez les environnements et définissez la façon dont les identifiants sont renouvelés ou révoqués. Si un identifiant a été exposé, le supprimer de la dernière version du fichier ne l’invalide pas : révoquez-le ou renouvelez-le et enquêtez sur son utilisation. Les recommandations de l’OWASP sur la gestion des secrets couvrent le cycle de vie des identifiants.
4. Combiner analyses automatisées et évaluation ciblée
Les analyses des dépendances et de la configuration sont des sources utiles. Examinez aussi les parcours où votre produit prend des décisions lourdes de conséquences : approuver une action, partager un document, changer le propriétaire d’un compte ou accepter un paiement. Un constat n’est utile que si l’équipe peut en comprendre l’impact et le reproduire en toute sécurité.
Le OWASP Web Security Testing Guide fournit un cadre de test structuré. Convenez des domaines qui s’appliquent à votre produit et consignez les exclusions. Pour un produit mobile, incluez les clients mobiles et leurs API dans le périmètre plutôt que de supposer qu’une revue web les couvre.
Demandez une synthèse pour la direction, des preuves techniques, la liste des composants concernés, des recommandations de correction et un retest convenu. Fixez les dates en fonction du périmètre réel et des accès de test disponibles.
5. S’assurer que quelqu’un peut détecter et réagir
Déterminez quels événements nécessitent une attention, qui reçoit les alertes et ce que ces personnes doivent faire ensuite. Les événements de sécurité utiles peuvent inclure les accès refusés, les modifications de privilèges et les actions d’administration. Protégez les journaux eux-mêmes et évitez d’y consigner des identifiants ou des données personnelles inutiles. Les recommandations de l’OWASP sur la journalisation expliquent l’équilibre entre preuves utiles et données sensibles.
Dans votre plan de mise en production, désignez la personne capable de désactiver une intégration, de révoquer un accès ou d’annuler un déploiement. Entraînez-vous à restaurer une sauvegarde récente dans un environnement de test approprié. Consignez le résultat et la durée réelle de la restauration.
6. Vérifier les correctifs et consigner la décision de mise en production
Attribuez à chaque constat un responsable et une date cible. Priorisez-le selon sa gravité technique, mais aussi selon l’exposition, les données concernées et l’effet sur les clients. Testez à nouveau la modification et les comportements associés avant de marquer le constat comme résolu.
Le compte rendu de mise en production que nous recommandons est court : ce qui a été évalué, quelle version a été testée, ce qui a été corrigé, ce qui reste ouvert et qui a accepté le risque résiduel. Maintenez la surveillance et la responsabilité des revues après le lancement ; une revue constitue une preuve pour un périmètre et un moment donnés.
Les questions que posent les équipes produit
Un test d’intrusion garantit-il qu’un produit est sécurisé ?
Non. Il peut révéler des faiblesses dans un périmètre et une fenêtre de test convenus. Le développement sécurisé, la maintenance, la surveillance et les contrôles de suivi restent indispensables à l’exploitation du produit.
Un VPN suffit-il à sécuriser une application ?
Un VPN peut protéger une connexion réseau et restreindre l’accès à des services privés. Votre application a néanmoins besoin de sa propre authentification, de ses propres autorisations, d’une configuration sécurisée et d’une revue.
Quand les tests de sécurité doivent-ils commencer ?
Commencez à discuter des risques pendant que les décisions d’architecture et de produit sont encore en cours. Planifiez des tests au périmètre défini suffisamment tôt pour corriger et retester les constats avant la mise en production, et réexaminez le périmètre lorsque des fonctionnalités ou intégrations importantes évoluent.
Besoin d’une vision claire des risques de votre produit ? Découvrez les services de sécurité et de test de CloudCoder. Nous relions les constats techniques à des correctifs concrets et à un plan pour les vérifier.
