Cinq politiques d'infrastructure qui empêchent votre cloud de brûler de l'argent et de la sécurité

Un développeur a besoin d'un accès SSH à un serveur de production pour une session de débogage rapide. Il ouvre le port 22 vers 0.0.0.0/0 pour pouvoir se connecter depuis son IP personnelle. Le débogage se termine, le ticket est fermé, et cette règle de groupe de sécurité reste ouverte pendant trois mois. Personne ne remarque rien jusqu'à ce que la facture cloud arrive avec une surprise : quelqu'un a lancé une instance m5.24xlarge dans le compte de dev, tournant 24h/24 et 7j/7, sans tags, nommée test123.

Ce n'est pas une hypothèse. Ce schéma se répète dans toutes les équipes chaque trimestre. La solution n'est pas plus de revues manuelles ou un contrôle d'accès plus strict. La solution, c'est une politique écrite sous forme de code, vérifiée automatiquement avant que toute ressource ne soit créée.

Les politiques d'infrastructure se répartissent en cinq catégories. Chacune résout une classe spécifique de problèmes. Les comprendre vous aide à décider lesquelles prioriser dans votre pipeline.

Sécurité : Le socle non négociable

Les politiques de sécurité sont les plus critiques car les violations ont des conséquences immédiates et visibles. L'exemple classique est le blocage des règles de groupe de sécurité qui ouvrent les ports SSH ou base de données vers 0.0.0.0/0. Les développeurs ouvrent souvent ces accès temporaires et oublient de les fermer. Une politique qui rejette ces règles au moment du pipeline empêche l'exposition accidentelle des ressources de production à Internet.

Autres politiques de sécurité courantes :

  • Exiger le chiffrement au repos pour les buckets S3 et les volumes EBS
  • Bloquer les versions obsolètes de TLS sur les équilibreurs de charge
  • Imposer le trafic HTTPS uniquement sur tous les points de terminaison publics
  • Exiger les journaux de flux VPC pour les environnements de production
  • Imposer l'utilisation de rôles IAM plutôt que des clés d'accès à longue durée de vie

Les politiques de sécurité ont généralement un comportement d'échec strict : si la vérification échoue, le pipeline s'arrête et la ressource n'est pas créée. Il n'y a pas de mode d'avertissement pour un port ouvert à Internet entier.

Coût : Prévenir les faillites bancaires accidentelles

Les ressources cloud sont chères si elles ne sont pas contrôlées. Un seul développeur peut provisionner accidentellement un type d'instance qui coûte autant que le salaire mensuel d'un membre de l'équipe. Les politiques de coût mettent en place des garde-fous autour des dépenses sans nécessiter d'approbation manuelle pour chaque ressource.

Politiques de coût typiques :

  • Bloquer les types d'instances coûteux (comme m5.24xlarge ou r5.metal) dans les environnements non-production
  • Limiter le nombre de volumes EBS ou de GPU par compte
  • Exiger des instances spot pour les charges de travail tolérantes aux pannes
  • Définir des tailles de stockage maximales pour les bases de données
  • Imposer des plannings d'arrêt automatique pour les environnements de développement

Les politiques de coût aident les équipes à rester conscientes de leur budget, surtout lorsque de nombreux développeurs ont accès au cloud. Sans elles, la commodité d'une personne peut devenir la facture surprise de l'équipe.

Tagging : Les métadonnées qui maintiennent les opérations

Le tagging semble ennuyeux jusqu'à ce que vous ayez besoin de savoir qui possède une ressource qui tourne depuis six mois. Les tags comme owner, environment, cost-center et project sont essentiels pour suivre les coûts, automatiser le nettoyage et déboguer les incidents.

Les politiques de tagging imposent que chaque ressource ait les tags requis au moment de la création. Par exemple :

  • Chaque ressource doit avoir un tag owner avec une adresse email valide
  • Chaque ressource doit avoir un tag environment : dev, staging ou production
  • Chaque ressource doit avoir un tag cost-center correspondant au code budgétaire de l'équipe

Lorsqu'une ressource échoue à la politique de tagging, le pipeline peut soit la rejeter, soit la créer avec un avertissement et un nettoyage planifié. L'important est que les ressources non taguées ne s'accumulent pas silencieusement. Les politiques de tagging empêchent le problème des « ressources orphelines » où les équipes de facturation trouvent des ressources mystères qui tournent depuis des mois sans propriétaire clair.

Nommage : La cohérence pour les humains et l'automatisation

Les noms de ressources comptent plus que la plupart des équipes ne le pensent. Un bucket nommé test123 et un autre nommé data-barang sont difficiles à rechercher, difficiles à automatiser et difficiles à dépanner. Les politiques de nommage imposent des schémas cohérents pour que les équipes d'exploitation et les outils d'automatisation puissent trouver les ressources rapidement.

Politiques de nommage courantes :

  • Tous les buckets S3 doivent commencer par le nom du projet
  • Tous les groupes de sécurité doivent avoir un préfixe indiquant l'environnement
  • Toutes les instances RDS doivent suivre le modèle {projet}-{env}-{fonction}
  • Tous les rôles IAM doivent inclure le nom du service et le niveau de permission

Les politiques de nommage sont souvent combinées avec les politiques de tagging. Ensemble, elles garantissent que chaque ressource est identifiable, recherchable et gérable à grande échelle. Sans elles, vous vous retrouvez avec un compte cloud qui ressemble à un tiroir à bazar.

Conformité : Traduire les règles externes en code

Les politiques de conformité traitent des exigences provenant de réglementations externes comme PCI DSS, HIPAA, SOC 2 ou RGPD. Elles ne sont pas optionnelles. Elles traduisent les exigences légales et réglementaires en vérifications automatisées qui s'exécutent avant le déploiement de toute ressource.

Exemples de politiques de conformité :

  • Toutes les bases de données de production doivent utiliser le chiffrement au repos
  • Tout accès aux ressources de production doit être journalisé dans une piste d'audit centralisée
  • Toutes les données doivent être stockées dans des régions géographiques approuvées
  • Toutes les sauvegardes doivent être chiffrées et stockées dans un compte séparé
  • Tout accès API doit utiliser l'authentification multi-facteurs

Les politiques de conformité sont souvent les plus difficiles à négocier car elles viennent de l'extérieur de l'équipe technique. Mais les encoder sous forme de code les rend cohérentes, auditées et beaucoup plus faciles à appliquer que des listes de contrôle manuelles.

Comment ces politiques interagissent

Ces cinq catégories ne fonctionnent pas en isolation. Une seule instance EC2 est vérifiée contre plusieurs politiques à la fois : règles de groupe de sécurité, type d'instance, tags, schéma de nommage et exigences de conformité. Un bon pipeline exécute toutes ces vérifications avant que la ressource ne soit créée, pas après.

Le diagramme suivant montre comment les cinq catégories de politiques sont liées entre elles et au pipeline de déploiement :

flowchart TD A[Déclencheur Pipeline] --> B{Sécurité & Conformité} B -->|Succès| C{Coût} B -->|Échec| D[Rejeter Ressource] C -->|Succès| E{Tagging} C -->|Échec| D E -->|Succès| F{Nommage} E -->|Échec| G[Avertir ou Rejeter] F -->|Succès| H[Créer Ressource] F -->|Échec| G D --> I[Alerter Équipe] G --> I

L'ordre compte aussi. Les vérifications de sécurité et de conformité doivent s'exécuter en premier car les violations dans ces catégories sont non négociables. Les vérifications de coût et de tagging peuvent suivre. Les vérifications de nommage sont généralement les moins critiques mais valent toujours la peine d'être appliquées pour la santé opérationnelle.

Liste de contrôle pratique pour démarrer

Si vous débutez avec les politiques d'infrastructure, commencez petit. Choisissez une catégorie et automatisez une vérification. Voici une séquence qui fonctionne pour la plupart des équipes :

  • Semaine une : Ajoutez une politique de sécurité qui bloque l'accès SSH public. Faites échouer le pipeline de manière stricte.
  • Semaine deux : Ajoutez une politique de tagging qui exige les tags owner et environment. Commencez par un avertissement, puis passez à un échec strict après deux semaines.
  • Semaine trois : Ajoutez une politique de coût qui bloque les types d'instances coûteux dans les comptes de dev. Avertissez en cas de violation, escaladez au chef d'équipe.
  • Semaine quatre : Ajoutez des conventions de nommage pour les types de ressources les plus courants dans votre compte.
  • Mois deux : Passez en revue les exigences de conformité et encodez les trois principales en vérifications automatisées.

L'objectif n'est pas d'écrire toutes les politiques à la fois. L'objectif est de créer une dynamique en résolvant d'abord les problèmes les plus douloureux.

Ce qui compte le plus

Les politiques de sécurité et de conformité vous protègent des menaces externes et des risques juridiques. Les politiques de coût protègent votre budget. Les politiques de tagging et de nommage protègent votre santé opérationnelle. Les cinq catégories travaillent ensemble pour transformer la gestion de l'infrastructure d'un processus manuel et sujet aux erreurs en un processus automatisé et cohérent.

Commencez par la politique qui fait le plus mal aujourd'hui. Pour la plupart des équipes, c'est soit le groupe de sécurité grand ouvert sur Internet, soit la ressource mystère qui fait grimper la facture. Automatisez cette vérification, puis passez à la suivante. Avec le temps, votre pipeline deviendra un filet de sécurité qui attrape les erreurs avant qu'elles ne deviennent des incidents.