Sécurité : comment nous déployons et exploitons votre logiciel
Nous ne livrons pas une archive de code en vous souhaitant bonne chance. Le logiciel que nous développons, nous le déployons et nous le faisons tourner sur une infrastructure que nous administrons. Cette page explique précisément comment, y compris ce qui nous manque encore.
Réserver un appel découverte de 30 min
Écrire le code ne représente que la moitié du travail
L'essentiel des incidents d'un logiciel métier survient après la mise en ligne : un identifiant qui fuite, une base que personne ne sauvegardait, une modification partie en production sans avoir été testée. C'est pourquoi, pour la plupart de nos clients, nous exploitons nous-mêmes ce que nous construisons. Tout ce qui suit décrit le fonctionnement réel de notre plateforme aujourd'hui, tiré du code d'infrastructure et non d'un modèle de politique de sécurité.
Hébergement et localisation de vos données
- Les applications tournent sur Google Cloud, dans Google Kubernetes Engine, par défaut dans la région europe-west1, en Belgique. Une autre région peut être mise en place pour votre projet : parlons-en lors de l'appel découverte.
- Les bases de données sont des instances PostgreSQL gérées par Cloud SQL, avec une sauvegarde automatique chaque jour, conservée sept jours.
- La préproduction et la production sont deux environnements séparés. Aucune modification n'atteint la production sans être d'abord passée par la préproduction.
- Votre équipe se connecte avec les comptes dont elle dispose déjà, Microsoft ou Google par exemple, et les droits dans l'application sont attribués par rôle.
Secrets
- Les identifiants sont conservés dans HashiCorp Vault, au sein du cluster et déverrouillé par Google Cloud KMS, ainsi que dans Google Secret Manager. L'application les reçoit au moment de son exécution : ils ne figurent jamais dans le code, dans un fichier de configuration ni dans le dépôt.
- Les services s'authentifient auprès de Google Cloud grâce à Workload Identity : il n'existe donc aucun fichier de clé de compte de service, qu'on pourrait perdre ou qu'il faudrait renouveler.
- Les jetons internes sont générés et enregistrés directement dans Secret Manager, sans que leur valeur ne s'affiche jamais à l'écran de la personne qui les crée.
Accès réseau
- Les nœuds du cluster sont privés : aucun ne dispose d'une adresse IP publique.
- Les services publics se trouvent derrière l'équilibreur de charge de Google, et des règles Cloud Armor bloquent en amont les réseaux de robots et d'aspirateurs abusifs, avant qu'ils n'atteignent l'application.
- Les outils d'administration et l'accès aux bases de données ne sont joignables que depuis notre réseau privé Tailscale, jamais depuis Internet. La politique de ce réseau est elle-même versionnée dans un dépôt et appliquée par la CI, plutôt que modifiée à la main.
Le chemin d'une modification jusqu'à la production
- Toute l'infrastructure est décrite en code (Terraform) et ne change que par des pull requests relues : chaque réglage est versionné, et l'historique indique qui a modifié quoi, et quand.
- Sur l'ensemble de nos dépôts, chaque pull request passe une analyse statique avec règles de sécurité (gosec), une recherche de vulnérabilités dans les dépendances Go (govulncheck) et une revue de sécurité automatisée, qui bloque la fusion dès qu'elle relève un problème.
- Dependabot surveille les dépendances, et une analyse programmée repasse régulièrement sur la branche principale de chaque dépôt en service ; tout ce qu'elle trouve devient un ticket.
- Une version mise en production est exactement l'image qui a déjà tourné en préproduction, et des tests de bout en bout automatisés s'exécutent chaque jour sur la préproduction.
Supervision
- Des règles d'alerte Google Cloud Monitoring, définies dans le même code d'infrastructure, surveillent la charge processeur, la mémoire et le disque des bases de production, ainsi qu'une croissance anormale du disque, et nous préviennent par e-mail.
- Les erreurs applicatives et les événements produit sont suivis : une panne remonte avec son contexte, plutôt que par l'e-mail d'un client mécontent.
Votre code, et votre porte de sortie
- Le code source, la configuration de l'infrastructure et la documentation vous appartiennent, et c'est écrit dans le contrat.
- Comme l'infrastructure est décrite en code, la plateforme entière peut être redéployée dans votre propre compte cloud, ou confiée à votre équipe ou à un autre prestataire, sans rien avoir à reconstituer.
Ce que nous ne revendiquons pas
Une page sécurité qui n'aligne que des points forts n'est qu'une plaquette commerciale. Voici ce qu'un service achats pourrait nous demander et que nous n'avons pas aujourd'hui.
- Nous ne sommes certifiés ni SOC 2 ni ISO 27001. Nous répondons à votre questionnaire de sécurité point par point, preuves à l'appui, tirées des systèmes eux-mêmes.
- Les sauvegardes des bases sont des copies quotidiennes conservées sept jours, sans restauration à un instant précis. Si votre projet exige un point de reprise plus fin, nous le configurons pour ce projet.
- Notre réseau privé tient l'administration à l'écart d'Internet, mais il ne restreint pas encore chaque personne à des services précis.
Questions fréquentes
Où nos données sont-elles hébergées ?
Par défaut sur Google Cloud, dans la région europe-west1, en Belgique, donc au sein de l'Union européenne. Les bases de données sont des instances PostgreSQL gérées par Cloud SQL. Si votre projet impose une autre région, nous la mettons en place pour lui : indiquez-nous la contrainte lors de l'appel découverte.
Êtes-vous certifiés SOC 2 ?
Non, pas plus que ISO 27001. Nous répondons en revanche à votre questionnaire de sécurité point par point, avec des preuves tirées des systèmes réels : comment les accès sont attribués, où les données sont stockées, comment les secrets sont gérés, comment les modifications sont relues puis déployées. Si votre service achats exige un rapport SOC 2 de chaque prestataire, mieux vaut nous le dire dès le départ : nous vous dirons franchement si nous pouvons convenir.
Comment gérez-vous les mots de passe et les clés d'API ?
Ils sont conservés dans HashiCorp Vault et Google Secret Manager, et l'application les reçoit au moment de son exécution. Ils ne se trouvent jamais dans le code, dans un fichier de configuration ni dans le dépôt, et les services accèdent à Google Cloud via Workload Identity plutôt qu'avec des fichiers de clé.
Pouvez-vous déployer dans notre propre compte cloud ?
Oui. L'infrastructure est écrite en Terraform : la même plateforme peut donc être déployée dans un projet Google Cloud qui vous appartient, avec votre propre facturation et vos propres contrôles d'accès. Nous pouvons ensuite l'exploiter pour vous à cet endroit, ou la confier à votre équipe.
Que se passe-t-il quand quelque chose casse en production ?
Des règles d'alerte sur les bases de production nous préviennent par e-mail dès que le processeur, la mémoire ou le disque saturent, et les erreurs applicatives sont suivies avec leur contexte. Comme chaque version mise en production est l'image qui a déjà tourné en préproduction, revenir en arrière consiste simplement à redéployer l'image précédente.
À qui appartiennent le code et l'infrastructure ?
À vous, qu'il s'agisse du code source, de la configuration de l'infrastructure ou de la documentation, et c'est écrit dans le contrat. Si vous reprenez ensuite le projet en interne ou le confiez à un autre prestataire, le code d'infrastructure vous évite de tout reconstruire.
Apportez-nous votre questionnaire de sécurité
Un appel gratuit de 30 minutes. Envoyez-nous le questionnaire au préalable si vous en avez un : nous passerons nos réponses en revue avec vous, y compris celles où nous ne cochons pas la case.
