Un compte AWS sécurisé et une CI/CD optimisée
Koacher est une startup dont l'équipe développe le produit, pas l'infrastructure. Après la reprise de leur application auprès d'un éditeur de logiciel, nous avons relu toute l'infrastructure, sécurisé le compte AWS et optimisé la CI/CD, dont le temps a été divisé par 2.
Gratuit, sans engagement. Vous repartez avec un premier avis.
- Compte AWS
- sécurisé de bout en bout
- ÷ 2
- sur le temps de déploiement
- Prometheus · Loki · Grafana
- supervision mise en place
Le contexte
Koacher est une startup. L'équipe développe le produit et n'a pas de poste dédié à l'infrastructure.
L'application était en phase de développement et de mise sur le marché. Elle venait d'être remise à l'équipe par un éditeur de logiciel.
Ce qui bloquait
Hugo, le CEO, s'inquiétait de la sécurité de l'application et du compte AWS après la livraison de l'application. Il voulait un avis externe, et un expert capable de relire l'ensemble de l'infrastructure.
Les environnements de staging et de préproduction tournaient en permanence, y compris quand l'équipe ne travaillait pas, et la chaîne de CI/CD coûtait du temps à chaque déploiement.
Ce que nous avons fait, étape par étape
Dans l'ordre, avec la raison de chaque choix.
- 01
Revue complète de l'infrastructure
Inventaire des accès, des droits, des clés et des ressources exposées, puis relecture de toute l'infrastructure du compte AWS.
Pourquoi ce choix. On ne sécurise pas ce qu'on n'a pas listé. Après une reprise par un éditeur, c'est aussi la seule façon d'avoir un avis indépendant sur ce qui a été livré.
- 02
Sécurisation du compte et de l'infrastructure
Reprise des droits et des identités, suppression de ce qui ne servait plus : clés SSH retirées des serveurs, utilisateurs AWS inactifs et clés d'accès supprimés, accès réseau autorisés par IP devenus inutiles retirés des security groups.
Pourquoi ce choix. La majorité des incidents sur un compte cloud passe par un accès trop large laissé en place, pas par une faille exotique.
- 03
Optimisation de la CI/CD
Les runners, qui tournaient sur des serveurs AWS, ont été migrés vers les runners managés par GitLab. Certains pipelines restaient plusieurs dizaines de minutes à attendre l'arrêt de serveurs : ils ont été revus pour durer quelques minutes, puis adaptés à la nouvelle stack. Le coût de la CI a fortement baissé et le temps de déploiement a été divisé par 2.
Pourquoi ce choix. Un service managé coûte parfois moins cher que des serveurs gérés soi-même, parce qu'on ne paie que le temps où on s'en sert. Encore faut-il des pipelines courts, d'où leur refonte avant la migration.
- 04
Mise en place de la supervision
Une stack de monitoring a été déployée avec Prometheus, Loki et Grafana : métriques, logs et tableaux de bord au même endroit.
Pourquoi ce choix. Sans supervision, on découvre les incidents par les utilisateurs. Elle sert aussi à repérer ce qui consomme pour rien.
- 05
Extinction des environnements hors production
L'usage des serveurs de staging et de préproduction, sur AWS Elastic Beanstalk, a été revu : ils sont éteints quand les développeurs ne travaillent pas et ne tournent que lorsque c'est nécessaire.
Pourquoi ce choix. Un environnement de test n'a pas besoin de tourner la nuit et le week-end. C'est de la facture AWS économisée sans toucher à la production.
- 06
Transfert à l'équipe
Tout a été livré dans les dépôts et les comptes de Koacher, documenté. La passation s'est faite en pairing avec les développeurs, puis par une formation en direct sur les nouveautés mises en place.
Le résultat
- Compte AWS sécurisé, avec un avis externe sur l'ensemble de l'infrastructure.
- Temps de déploiement divisé par 2 et coût de la CI en forte baisse, grâce à la migration des runners AWS vers les runners managés par GitLab.
- Supervision en place avec Prometheus, Loki et Grafana.
- Consommation des environnements de staging et de préproduction réduite : ils ne tournent que quand l'équipe en a besoin.
« Au-delà d'être hyper qualifiés, ils sont hyper préventifs et investis. Des qualités rares dans ce domaine. Je compte retravailler avec eux très vite. »
Questions fréquentes
Par quoi commence une sécurisation de compte cloud ?
Par l'inventaire des accès. Qui peut faire quoi, avec quelles clés, sur quelles ressources. C'est rarement spectaculaire et c'est là que se trouvent la plupart des risques réels.
Faut-il arrêter de déployer pendant ce type de mission ?
Non. Nous travaillons sur une infrastructure vivante, par étapes, en prévenant l'équipe avant chaque changement qui peut la gêner.
Une startup de quelques personnes a-t-elle besoin de tout cela ?
Pas de tout, non. Nous disons ce qui est urgent, ce qui peut attendre, et ce qui ne vaut pas le coût à votre stade. C'est l'intérêt de commencer par un audit plutôt que par un devis de projet.
Les offres que ce cas illustre
← Voir toutes les réalisationsCommençons par 30 minutes
Nous faisons le point sur votre situation. Si un audit a du sens, nous vous proposons un périmètre et un prix fixe.