Quand la politique d'infrastructure fait obstacle : gérer les exceptions sans compromettre la sécurité

Vous avez passé des semaines à élaborer des politiques d'infrastructure. Chaque ressource doit respecter des conventions de nommage, utiliser des types d'instances approuvés et ne jamais exposer certains ports au public. Le pipeline applique ces règles automatiquement. Tout est propre, contrôlé et sécurisé.

Puis une équipe arrive avec une demande qui viole trois politiques à la fois. Ils ont besoin d'une instance à grande mémoire normalement interdite pour des raisons de coût. Ils doivent ouvrir un port de débogage temporairement parce qu'un problème de production ne se reproduit que dans l'environnement réel. Et le système legacy qu'ils migrent les force à utiliser un nom de ressource qui brise votre standard de nommage.

Que faites-vous ?

Le problème des politiques rigides

Si votre réponse est « la politique, c'est la politique, pas d'exceptions », vous vous préparez à l'échec. Les équipes trouveront des contournements. Elles modifieront discrètement les politiques, créeront des ressources en dehors du pipeline ou ignoreront simplement les règles. La politique devient inutile car les gens préfèrent contourner le système plutôt que de se battre avec des règles rigides.

L'objectif n'est pas d'éliminer les politiques. C'est de les rendre suffisamment flexibles pour que les gens ne se sentent pas obligés de les contourner. Vous avez besoin d'un mécanisme clair pour les exceptions qui maintient tout le monde responsable.

Trois choses dont chaque exception a besoin

Un système d'exception bien conçu comporte trois composants non négociables : la journalisation, l'approbation et l'expiration.

Journalisation

Chaque exception doit être enregistrée. Qui l'a demandée, quelle politique a été contournée, quelles ressources ont été affectées, pourquoi l'exception était nécessaire et qui l'a approuvée. Cette information ne doit jamais disparaître. Elle sert à plusieurs fins : pistes d'audit, analyses post-mortem et un rappel discret que l'équipe opère en dehors des règles normales.

Sans journalisation, les exceptions deviennent une dette technique invisible. Vous ne saurez pas combien d'exceptions existent, qui les a accordées ou si elles sont encore nécessaires.

Approbation

La personne qui demande une exception ne peut pas l'approuver elle-même. Quelqu'un d'autre doit donner son accord, idéalement quelqu'un qui comprend les risques que la politique était censée atténuer. Si l'exception touche à la sécurité, l'équipe sécurité approuve. Si elle affecte les coûts, les finances ou un responsable technique approuvent.

Cette approbation peut être intégrée directement dans votre pipeline comme un point de contrôle. Le pipeline se met en pause jusqu'à ce que la personne autorisée examine et approuve la demande d'exception. Pas d'approbation, pas de déploiement.

Expiration

Les exceptions ne doivent jamais être permanentes. Chaque exception a besoin d'une limite de temps, généralement de 7 à 30 jours. Après cela, la politique se réapplique automatiquement. La ressource en infraction doit être corrigée ou supprimée. Si l'exception est toujours nécessaire, l'équipe doit soumettre une nouvelle demande avec des justifications mises à jour.

Ce mécanisme empêche les exceptions de devenir la nouvelle norme. Il force les équipes à soit corriger le problème sous-jacent, soit justifier pourquoi la politique doit changer.

Concevoir le flux d'exception

Le processus d'exception devrait être légèrement inconfortable. Pas pour punir les gens, mais pour s'assurer qu'ils ont vraiment besoin de l'exception. Si c'est trop facile, tout le monde utilisera des exceptions au lieu de suivre les politiques. Si c'est trop difficile, les gens trouveront des failles. Le juste milieu se situe quelque part entre les deux : assez ennuyeux pour faire réfléchir les gens à deux fois, mais pas assez douloureux pour bloquer le travail légitime.

En pratique, le flux ressemble à ceci :

Le diagramme suivant illustre le processus de demande d'exception :

flowchart TD A[Le pipeline détecte une violation de politique] --> B{Choisir une action} B -->|Annuler| C[Changement bloqué] B -->|Demander une exception| D[Soumettre une demande d'exception] D --> E[Enregistrer les détails de la demande] E --> F[Notifier l'approbateur] F --> G{Approuvé ?} G -->|Non| H[Changement bloqué] G -->|Oui| I[Le pipeline continue avec le statut d'exception] I --> J[Définir la date d'expiration] J --> K[Envoyer des rappels avant l'expiration] K --> L{Expiré ?} L -->|Non| M[Ressource en exception] L -->|Oui| N[Relancer la vérification de politique] N --> O{Conforme ?} O -->|Oui| P[Exception fermée] O -->|Non| Q[Appliquer la politique / corriger la ressource]
  1. Le pipeline exécute ses vérifications de politique pendant le plan ou l'apply.
  2. Une violation est détectée. Le pipeline propose deux options : annuler le changement ou soumettre une demande d'exception.
  3. Si l'équipe soumet une exception, le pipeline crée un ticket ou une notification pour l'approbateur autorisé.
  4. Une fois approuvée, le pipeline continue, mais marque la ressource comme étant en statut d'exception.
  5. Le système envoie des rappels avant l'expiration de l'exception. Après expiration, il relance automatiquement la vérification de politique.

Ce qu'il ne faut pas faire

Ne créez jamais d'exceptions sans dates d'expiration ni approbation. Cela équivaut à n'avoir aucune politique du tout. Une exception qui n'expire jamais est simplement une politique qui a été réécrite en silence.

Aussi, n'utilisez pas les exceptions comme excuse pour éviter d'améliorer vos politiques. Si le même type d'exception apparaît sans cesse, votre politique est peut-être trop stricte. Peut-être avez-vous besoin d'une nouvelle catégorie de ressources, ou la règle d'origine n'a plus de sens. Les exceptions fréquentes sont un signal que vos politiques ont besoin d'être évaluées, pas seulement contournées.

Liste de contrôle pratique pour la gestion des exceptions

  • Chaque exception est journalisée avec le demandeur, la politique contournée, les ressources affectées, la raison et l'approbateur
  • Les exceptions nécessitent l'approbation de quelqu'un qui comprend le risque de la politique
  • Toutes les exceptions ont des dates d'expiration explicites (7 à 30 jours recommandés)
  • Le pipeline bloque le déploiement jusqu'à ce que l'exception soit approuvée
  • Des rappels automatisés sont envoyés avant l'expiration de l'exception
  • Les exceptions expirées déclenchent une revérification automatique de la politique
  • La fréquence des exceptions est examinée trimestriellement pour identifier les améliorations de politique

L'essentiel à retenir

Les politiques sans mécanismes d'exception créent des systèmes parallèles. Les équipes les contourneront, et vous perdez la visibilité sur ce qui s'exécute réellement dans votre infrastructure. Un flux d'exception bien conçu n'affaiblit pas vos politiques. Il les renforce en les rendant suffisamment réalistes pour que les gens les suivent réellement. La clé est la journalisation, l'approbation et l'expiration. Sans ces trois éléments, vous n'avez pas un processus d'exception. Vous avez une politique déjà brisée.