Les petites équipes font l'expérience de mathématiques cruelles. Les mêmes deux, trois, cinq personnes doivent gérer le produit, le code, l'infrastructure, le support et, quelque part sur cette liste, la sécurité. Il n'y a pas de spécialiste dédié. Il n'y a pas de relâche dans le calendrier. Il y a des gens bien qui font de leur mieux avec le temps qui leur reste.
Dans ce contexte, les conseils de sécurité habituels semblent presque offensants. Embauchez une équipe de sécurité, effectuez des tests d'intrusion réguliers, mettez en place un programme de gouvernance. Super, avec quelles personnes ? Avec quel budget ?
Ce texte part d’une prémisse différente. Vous êtes peu nombreux, vous le resterez pendant un certain temps et vous devez quand même protéger votre application. La bonne question n’est pas « comment avoir une équipe de sécurité », mais plutôt « comment faire de la sécurité un élément naturel du fonctionnement de cette petite équipe ».
Le problème spécifique de la petite équipe
La petite équipe n’a pas le problème d’une startup en quête de validation ni celui d’une entreprise en quête d’échelle. Il y a le problème de la surcharge.
Chaque personne cumule les rôles. Les connaissances sont concentrées, parfois dans la tête d'une seule personne. Quand quelqu'un part en vacances ou en entreprise, des trous s'ouvrent. Et la sécurité, parce qu’elle est invisible lorsqu’elle fonctionne, est la première chose à sacrifier lorsque la journée devient dure.
La stratégie de sécurité des petites équipes ne peut donc pas dépendre de l’héroïsme ou d’une discipline constante. Cela doit dépendre de la structure. Le chemin sûr doit aussi être le chemin le plus facile.
La thèse : la sécurité devient une habitude ou rien
Voici ma position. Dans une petite équipe, la sécurité ne peut pas être résolue avec plus de personnes. Il est résolu par des décisions standard, des choix intégrés dans le processus qui protègent par l’inertie et non par l’effort.
Lorsque la sécurité dépend du fait que quelqu’un se souvienne de faire quelque chose, elle échouera. Les gens oublient, surtout les gens surmenés. Mais lorsque l'assurance constitue le comportement par défaut du système, la protection est assurée même dans les mauvais jours.
Cela change la question de « comment pouvons-nous le rendre plus sécurisé ? » à "comment pouvons-nous rendre ce qui est dangereux difficile à faire par accident ?". C'est un changement de mentalité qui s'inscrit parfaitement dans la réalité de ceux qui sont peu nombreux.
Principes pratiques pour ceux qui sont peu nombreux
Des normes sécurisées qui protègent automatiquement
La meilleure sécurité pour une petite équipe est celle qui est toute prête. Utilisez des frameworks et des bibliothèques qui font ce qu'il faut par défaut. Configurez en toute sécurité vos services cloud comme état initial, et non après coup.
Lorsque le modèle de projet force déjà HTTPS, valide déjà les entrées et garde déjà des secrets en dehors du code, la petite équipe bénéficie de la sécurité sans perdre d'attention. L'effort est concentré une fois, lors de l'assemblage du modèle, et s'amortit à chaque fois par la suite.
Automatisez la surveillance que vous n'avez pas le temps de faire
Vous ne pouvez pas auditer manuellement les dépendances chaque semaine. Alors ne le faites pas. Laissez les outils automatiques vous avertir lorsqu'une bibliothèque présente une vulnérabilité connue. Mettez en place des contrôles de sécurité dans le pipeline afin que le code présentant des problèmes évidents ne passe pas sans avertissement.
L’automatisation est le multiplicateur de force de la petite équipe. Chaque contrôle automatisé est une tâche que vous n’aurez plus jamais à penser à refaire. Cela libère les quelques esprits disponibles pour les problèmes qui nécessitent un jugement humain.
Réduisez la surface à entretenir
Moins il y a de choses, moins les choses peuvent mal tourner. Pour la petite équipe, la simplicité est synonyme de sécurité.
Collectez moins de données. Utilisez moins d’intégrations. Gardez moins de services en cours d’exécution. Chaque composant supplémentaire est une chose de plus à configurer, surveiller et corriger. Un système Lean est non seulement moins cher à exploiter, mais il est également moins dangereux à entretenir.
Documenter les éléments essentiels pour survivre au turnover
Le talon d'Achille d'une petite équipe réside dans les connaissances contenues dans la tête d'une seule personne. Lorsque cette personne part, la sécurité l’accompagne.
Aucune documentation détaillée n’est requise. L'essentiel suffit : où sont les secrets, comment fonctionne l'authentification, quels sont les points sensibles du système. Un document court et mis à jour vaut plus qu’un manuel géant que personne ne lit. La continuité est une forme de sécurité que les petites équipes ignorent souvent jusqu'à ce qu'il soit trop tard.
Un exemple quotidien
Imaginez une équipe de trois personnes gérant une application de planification pour les cliniques. Il s'agit de données de santé, à caractère sensible et protégées par la LGPD. Il n'y a personne avec le titre de « sécurité » dans l'équipe.
L’approche réaliste ne consiste pas à élaborer un programme de sécurité. Il s’agit d’intégrer la protection dans le modèle de travail. Le projet est né avec des secrets dans le backend et un stockage sécurisé sur l'appareil. Le pipeline exécute déjà la vérification des dépendances. La collecte de données est minime par décision consciente. Et il y a un document d'une page qui vous explique comment tout cela fonctionne.
Aucune de ces mesures ne nécessite un spécialiste. Ils exigent tous que l’équipe décide, une fois, qu’il s’agit là de la norme. Après cela, la sécurité fonctionne presque toute seule.
Les risques auxquels la petite équipe doit faire face
Le plus grand risque réside dans le sentiment erroné que la sécurité est le problème des grandes entreprises. Les petites applications sont constamment attaquées, souvent par une automatisation qui ne cible pas en fonction de leur taille. Être peu nombreux ne vous rend pas invisible.
Le deuxième risque est le burn-out. Essayer d’être en sécurité par des efforts brutaux, sans structure, conduit à l’abandon. L'équipe se fatigue, la laisse de côté et la protection disparaît avec l'énergie. C'est pourquoi il faut miser sur l'automatisation et les normes, et non sur la volonté.
Le troisième est la concentration des connaissances. Lorsqu’une seule personne comprend la sécurité du système, vous n’avez aucune sécurité, vous avez un seul point de défaillance humain. Il est essentiel de diffuser les connaissances de base.
Une sécurité qui s'adapte à la réalité
La meilleure architecture de sécurité pour une petite équipe est celle qui n’est pas lourde au quotidien. Cela protège sans demander une attention constante. Cela survit aux vacances, aux sorties et aux journées chaotiques.
Cela se construit avec des décisions structurelles prises dans le calme, et non avec une vigilance héroïque exercée sous pression. La petite équipe qui comprend cela transforme ses limites en discipline : comme elle ne peut pas faire grand-chose, l'essentiel est fait très bien et automatiquement.
La sécurité n'a pas besoin d'une armée. Vous avez besoin de bonnes normes et de la décision de les respecter.
Si vous faites partie d'une équipe réduite qui essaie d'équilibrer la livraison et la sécurité, cela vaut la peine de changer d'idée. J'ai d'autres articles sur le blog sur l'automatisation, les bonnes pratiques et la LGPD conçus précisément pour ceux qui font beaucoup avec peu.
A lire aussi
-Sécurité dans les applications mobiles : une architecture pour ceux qui ont besoin d'évoluer -Sécurité dans les applications mobiles : architecture pour startups -Backend pour les applications : bonnes pratiques pour les petites équipes qui ne peuvent pas faire d'erreurs