Qui possède la production ? Pourquoi les limites de privilèges entre environnements sont cruciales

Un développeur de votre équipe modifie un petit fichier de configuration. Il pensait mettre à jour l'environnement de staging, mais a accidentellement exécuté la commande contre la production. Cinq minutes plus tard, les utilisateurs commencent à signaler des erreurs. L'équipe s'agite pour comprendre ce qui s'est passé, qui a fait la modification et comment l'annuler. Pendant ce temps, le développeur à l'origine du problème n'est même pas sûr d'avait eu la permission de toucher à la production.

Ce scénario se produit plus souvent que la plupart des équipes ne veulent l'admettre. Il ne s'agit pas de mauvaises intentions ou d'ingénieurs incompétents. Il s'agit d'une frontière manquante entre les environnements. Lorsque tout le monde a le même accès au développement, au staging et à la production, le système n'a aucun moyen de distinguer les changements intentionnels des erreurs.

Le problème de l'accès universel

De nombreuses équipes commencent avec une configuration simple : tout le monde a accès à tout. Les développeurs peuvent modifier le staging, la production, ou même l'environnement de développement d'une autre équipe. Cela semble pratique au début. Personne n'a à attendre les permissions. Personne n'a besoin de demander de l'aide pour déployer un correctif.

Mais cette approche crée deux problèmes. Premièrement, la responsabilité devient floue. Quand quelque chose casse en production et que tout le monde y avait accès, trouver la cause racine prend plus de temps. Il faut vérifier qui a exécuté quelle commande, depuis quelle machine, à quelle heure. Deuxièmement, le rayon d'explosion d'une erreur augmente. Un développeur travaillant sur une branche de fonctionnalité peut accidentellement déclencher un déploiement en production. Une faute de frappe dans un fichier de configuration peut faire tomber un service dont dépendent des centaines d'utilisateurs.

La solution n'est pas de tout verrouiller si fort que personne ne peut travailler. La solution est de créer des limites de privilèges claires entre les environnements.

Qu'est-ce qu'une limite de privilège ?

Une limite de privilège est une séparation claire de qui peut faire quoi dans chaque environnement. Il ne s'agit pas seulement des permissions dans un outil. Il s'agit de la façon dont vous structurez votre backend d'état, votre dépôt et votre configuration de pipeline.

Par exemple, le fichier d'état pour la production devrait vivre dans un emplacement différent du fichier d'état pour le développement. Si vous utilisez Terraform, le backend d'état de production pourrait être un bucket S3 séparé avec des politiques IAM plus strictes. Seules quelques personnes de l'équipe ont accès à ce bucket. Le backend d'état de développement pourrait être dans un bucket partagé que tout le monde dans l'équipe peut lire et écrire.

Le principe ici est le moindre privilège. Chaque personne ou système reçoit uniquement l'accès nécessaire pour faire son travail. Un développeur peut avoir besoin d'un accès complet à l'environnement de développement. Il peut avoir besoin d'un accès en lecture seule à l'état de production pour comprendre ce qui s'exécute. Mais s'il doit faire un changement en production, ce changement doit passer par un processus plus formel : une pull request revue par un autre membre de l'équipe, ou un pipeline qui nécessite une approbation.

La propriété rend les limites concrètes

Les limites de privilèges fonctionnent mieux lorsque chaque environnement a un propriétaire clair. Le propriétaire est la personne ou l'équipe responsable quand quelque chose tourne mal dans cet environnement. La propriété n'est pas une question de contrôle. C'est une question de responsabilité.

En pratique, la propriété ressemble souvent à ceci :

• L'équipe d'ingénierie de plateforme possède la production. Elle est responsable de sa stabilité, de ses performances et de sa sécurité.
• L'équipe de développement d'application possède le staging. Elle l'utilise pour valider ses changements avant de demander un déploiement en production.
• Les développeurs individuels possèdent leurs environnements de développement personnels. Ils peuvent les casser, les reconstruire et expérimenter librement.

Cette division ne signifie pas que les développeurs ne peuvent pas toucher à la production. Cela signifie que lorsqu'ils le font, ils suivent un processus qui implique le propriétaire de la production. Le propriétaire examine le changement, comprend le risque et approuve ou rejette le déploiement.

Comment implémenter les limites de privilèges en pratique

Les limites de privilèges se manifestent à trois endroits : la structure de votre dépôt, la configuration de votre pipeline et votre backend d'état.

Structure du dépôt

La façon la plus simple d'appliquer les limites est via la structure de répertoires et la protection des branches. Les configurations de production peuvent vivre dans un répertoire séparé ou même un dépôt séparé. Si elles sont dans le même dépôt, le répertoire de production doit être protégé. Seuls certains membres de l'équipe peuvent y pousser des modifications. Les pull requests qui modifient les configurations de production nécessitent l'approbation du propriétaire de la production.

Le diagramme suivant montre comment une demande de changement traverse les limites de privilèges en fonction de qui fait le changement et de l'environnement cible.

Configuration du pipeline

Votre pipeline CI/CD est l'endroit où les limites deviennent opérationnelles. Le pipeline pour la production ne doit s'exécuter que lorsque certaines conditions sont remplies. Par exemple, il peut ne se déclencher qu'à partir d'une branche protégée. Il peut nécessiter une approbation manuelle d'une personne désignée. Il peut exécuter des étapes de validation supplémentaires que le pipeline de développement ignore.

Certaines équipes vont plus loin. Elles configurent le pipeline de production pour qu'il ne s'exécute que depuis un runner CI/CD spécifique qui a accès au backend d'état de production. Les développeurs ne peuvent pas exécuter le pipeline de production depuis leurs ordinateurs portables car leurs machines locales n'ont pas les identifiants requis.

Backend d'état

Le backend d'état est l'endroit où les outils d'infrastructure-as-code stockent l'état actuel de vos environnements. Si vous utilisez Terraform, le fichier d'état pour la production doit être dans un backend séparé avec des contrôles d'accès stricts. La politique IAM pour ce backend ne doit autoriser les opérations qu'à partir du pipeline de production, pas depuis les comptes individuels des développeurs.

Par exemple, vous pouvez configurer le backend d'état de production avec une politique qui dit : "Seul le compte de service CI/CD peut écrire dans ce fichier d'état. Tous les autres peuvent seulement le lire." Ainsi, même si un développeur exécute accidentellement une commande Terraform contre la production, la commande échoue car il ne peut pas acquérir un verrou d'état.

Voici une politique IAM Terraform qui applique cette limite en autorisant l'écriture uniquement sur les fichiers d'état de développement tout en refusant l'écriture sur les fichiers d'état de production :

data "aws_iam_policy_document" "state_access" {
  statement {
    sid    = "AllowDevWrite"
    effect = "Allow"
    actions = [
      "s3:PutObject",
      "s3:GetObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-tf-state-bucket/env:/dev/*"
    ]
  }

  statement {
    sid    = "DenyProdWrite"
    effect = "Deny"
    actions = [
      "s3:PutObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-tf-state-bucket/env:/prod/*"
    ]
  }
}

Les limites ne sont pas une question de méfiance

Certaines équipes résistent aux limites de privilèges car elles les perçoivent comme un signe de méfiance. "Nous avons embauché des gens intelligents. Pourquoi ne pouvons-nous pas leur faire confiance avec l'accès à la production ?"

Ce point de vue rate la cible. Les limites de privilèges ne sont pas une question de confiance. Elles sont une question de clarté et de responsabilité. Quand tout le monde a accès à tout, personne ne sait qui appeler quand quelque chose casse. Quand les limites sont claires, l'équipe sait exactement qui possède chaque environnement et quel processus suivre.

Les limites protègent aussi les personnes qui font des erreurs. Un développeur qui casse accidentellement la production parce qu'il avait un accès illimité se sent mal. Il fait aussi perdre du temps à l'équipe pendant que tout le monde enquête sur l'incident. Avec des limites claires, ce même développeur aurait été arrêté avant que le changement n'atteigne la production. Le système attrape l'erreur, pas la personne.

Une liste de vérification rapide pour mettre en place des limites de privilèges

Si vous examinez votre configuration actuelle, voici quelques points à vérifier :

• Le backend d'état de production est-il séparé de celui du développement et du staging ?
• Les développeurs peuvent-ils écrire dans l'état de production depuis leurs ordinateurs portables ?
• Le pipeline de production nécessite-t-il une approbation manuelle ?
• Y a-t-il un propriétaire clair pour chaque environnement ?
• Les modifications des configurations de production sont-elles revues par le propriétaire avant le déploiement ?

Ces vérifications ne sont pas exhaustives, mais elles couvrent les lacunes les plus courantes qui mènent à des incidents de production.

Et ensuite

Une fois que vous avez des limites de privilèges et une propriété en place, le prochain défi est de maintenir l'état de votre infrastructure précis. Parfois, des changements se produisent en dehors de vos outils d'infrastructure-as-code. Quelqu'un modifie une configuration de serveur directement depuis la console cloud. Un membre de l'équipe applique un correctif à chaud manuellement lors d'un incident. Ces changements créent une dérive entre votre état et la réalité. La dérive compromet la fiabilité de votre infrastructure et rend les changements futurs imprévisibles. C'est un sujet qui mérite d'être exploré séparément, mais pour l'instant, l'étape importante est d'établir des limites claires d'abord. Sans elles, la détection et la correction de la dérive deviennent beaucoup plus difficiles à gérer.