Livrer sans crainte sur votre propre infrastructure

Ce que la norme exige, et ce qu'elle n'exige pas

Beaucoup d'institutions maintiennent leurs systèmes et leurs données sur une infrastructure propre, en raison de leur modèle de risque, de leurs contrats ou de leurs systèmes hérités. Elles ne sont pas une minorité : dans l'enquête 2024 de la CNCF, 59 % des participants utilisent une infrastructure propre autogérée, autant que le cloud public autogéré (750 participants de sa communauté). Opérer chez soi n'est pas une excuse pour livrer sans discipline.

Une précision qu'il faut avoir bien en tête devant n'importe quel comité : en général, la réglementation mexicaine n'impose pas que l'infrastructure soit chez vous. Les dispositions de la CNBV pour les banques admettent une infrastructure propre ou de tiers, y compris à l'étranger, avec des exigences qui dépendent du service : avis ou autorisation préalable, continuité en cas de défaillance du fournisseur et accès de l'autorité à l'information. La loi sur les données personnelles ne fixe pas non plus d'emplacement obligatoire, bien qu'elle pose des conditions pour le traitement et les transferts. Le détail se valide pour chaque entité et chaque service.

Ce que ces cadres demandent, en revanche, c'est de démontrer le contrôle : une preuve et une traçabilité proportionnées au risque. Avoir l'infrastructure chez soi ne le garantit pas. Ce qui change, c'est la responsabilité : chez vous, tout le contrôle et toute l'atténuation sont à vous. Si le chemin vers la production est bien conçu, ce contrôle se démontre par des preuves et non par des promesses.

Votre infrastructure actuelle vous permet-elle de démontrer ce contrôle avec la même discipline qu'un cloud public ? Cloud et infrastructure

Ce qui est non sécurisé d'origine

Un cluster qui réussit les tests fonctionnels peut échouer à un audit de sécurité s'il conserve sa configuration d'usine. Selon la documentation officielle de Kubernetes et le guide de durcissement de la NSA et de la CISA, plusieurs éléments sont ainsi par défaut :

• Les secrets sont stockés non chiffrés dans la base du cluster.
• Le journal d'audit est désactivé.
• Les espaces de noms n'isolent pas le réseau : sans politiques explicites, tout communique avec tout.
• Dans les clusters créés avec kubeadm, les certificats client expirent au bout d'un an par défaut. Ils se renouvellent avec les mises à jour ou par une procédure explicite ; si personne ne le fait, le cluster cesse de répondre un jour quelconque.

Et il y en a un, physique, que presque personne ne mesure : le magasin d'état du cluster (etcd) est très sensible à la latence du disque. Son guide matériel donne comme référence 50 opérations séquentielles par seconde, et 500 pour les clusters chargés, et recommande un disque SSD. Avec une latence élevée ou très variable, le symptôme n'est pas « c'est lent » : ce sont des délais d'attente dépassés, des élections de leader et des chutes de disponibilité. Cela se mesure avec des tests de charge représentatifs, avant la production.

Quelqu'un de votre équipe pourrait-il dire aujourd'hui, sans chercher, quand expirent les certificats de votre cluster ?

Un seul chemin vers la production

Du changement du développeur jusqu'à la production, tout passe par le même chemin, et chaque porte peut arrêter la livraison :

1. Des tests qui arrêtent. Les tests obligatoires bloquent la promotion ; les signaux non concluants sont enregistrés et traités selon une politique explicite. Pour une urgence, il existe une procédure d'exception, avec approbation et trace.
2. Une qualité dont le motif est visible. La porte ne se contente pas de « terminé sans erreur » : elle dit quelle condition a échoué.
3. Un scan par catégories : code, dépendances, secrets exposés, images et configuration, avec des seuils et des exceptions traçables. Et il distingue « a trouvé quelque chose » de « n'a pas fini de vérifier » : les deux arrêtent la livraison.
4. Construire une fois, promouvoir la même chose. Ce qui a été testé est ce qui arrive jusqu'à la production ; on ne recompile pas par environnement. La configuration et les secrets de chaque environnement se contrôlent à part, avec version et trace.
5. Échouer tôt et clairement. S'il manque quelque chose au serveur de construction, il échoue dès la première étape en disant ce qui manque.

Que vérifie aujourd'hui votre processus avant d'arriver à la production, et que laisse-t-il passer sans que personne ne s'en aperçoive ? DevSecOps

Sans internet, le scanner vieillit aussi

Sur un réseau isolé, la partie la plus négligée est la plus silencieuse : la base de vulnérabilités du scanner. Si personne ne la met à jour, le scanner continue de dire « aucune découverte » parce qu'il ne connaît pas ce qui est nouveau. Certains outils refusent de s'exécuter avec une base de plus de cinq jours ; d'autres restent au vert avec la base figée. Un chemin isolé bien conçu apporte son propre miroir de ces bases, avec une date visible et une alerte lorsqu'elle vieillit.

Votre scanner connaît-il les vulnérabilités publiées cette semaine ? DevSecOps

Trois destinations, le même critère

Les portes et les preuves se réutilisent d'une destination à l'autre ; chaque destination conserve ses propres exigences de déploiement, d'identité, de supervision et de reprise, et passer à Kubernetes oblige à en repenser plusieurs.

Laquelle des trois est la vôtre aujourd'hui, et laquelle devrait-elle être dans deux ans ?

Défaillances que nous voyons souvent

• Des processus de livraison dupliqués et sans gouvernance. Quand chaque équipe maintient sa propre copie, les copies divergent en silence et les preuves cessent d'être comparables. Mieux vaut un seul modèle partagé et versionné.
• Installer à la main depuis l'outil de construction. Mélanger « qui construit » et « qui installe » laisse des changements sans trace. Mieux vaut les séparer et décrire l'environnement comme du code.
• Des exceptions temporaires qui deviennent permanentes. Un contrôle omis « seulement en développement » est celui qui échoue ensuite en production.
• Des identités éparses. L'annuaire propre de l'orchestrateur, distinct de celui de l'entreprise, accumule des comptes orphelins à privilèges élevés (NIST SP 800-190).

D'autres contrôles sont souvent pertinents —gestion des secrets, signature et inventaire de ce qui est livré, approbation humaine pour la production, séparation des tâches, reprise et conservation— et se définissent selon votre modèle de risque.