Terraform pour provisionner un hébergement conforme HDS pour la santé

« L’infrastructure telle qu’elle existe aujourd’hui n’est documentée que dans la tête de la personne qui l’a configurée » — c’est le constat que nous avons fait en reprenant l’hébergement d’un site pour un établissement de santé, où chaque paramètre du pare-feu, chaque règle de sauvegarde, chaque droit d’accès avait été ajusté à la main au fil des mois, sans trace écrite.

Sur un hébergement soumis à la certification HDS (hébergeur de données de santé), cette absence de documentation devient un problème sérieux : un audit de certification exige de pouvoir justifier chaque réglage, et une reconstruction à l’identique en cas de sinistre devient impossible sans la mémoire de la bonne personne. Nous avons donc entièrement redécrit cette infrastructure en Terraform.

Pourquoi l’infrastructure as code s’impose sur ce type de projet

Terraform permet de décrire l’état souhaité d’une infrastructure dans des fichiers de configuration, puis de laisser l’outil calculer et appliquer les changements nécessaires pour atteindre cet état. Sur un hébergement de données de santé, cette approche apporte trois garanties recherchées par les auditeurs :

• Une trace versionnée de chaque modification, avec l’auteur et la date, via l’historique Git du dépôt de configuration.
• Une reproductibilité totale : reconstruire l’infrastructure à l’identique sur un nouveau compte ne dépend plus de la mémoire d’une personne.
• Une revue possible avant application, puisque chaque changement peut être relu par un pair avant d’être exécuté en production.

Structurer le projet Terraform

Nous organisons systématiquement la configuration en modules distincts, pour séparer ce qui change souvent (la configuration applicative) de ce qui reste stable (le réseau, le pare-feu) :

infra/
├── modules/
│   ├── reseau/         # VPC, sous-réseaux, règles de pare-feu
│   ├── serveur/        # instance de calcul, disque chiffré
│   └── sauvegarde/      # politique de sauvegarde automatisée
├── environnements/
│   ├── production/
│   │   └── main.tf
│   └── recette/
│       └── main.tf
└── variables.tf

Un extrait de configuration du serveur

Voici un exemple simplifié de la déclaration du serveur qui héberge WordPress, avec un disque chiffré et des règles de pare-feu restrictives :

resource "openstack_compute_instance_v2" "wordpress" {
  name            = "wp-sante-prod"
  image_name      = "debian-11"
  flavor_name     = "s1-4"
  security_groups = ["pare-feu-hds"]

  block_device {
    source_type           = "image"
    destination_type      = "volume"
    volume_size           = 40
    boot_index             = 0
    delete_on_termination = false
  }
}

resource "openstack_networking_secgroup_rule_v2" "https_seulement" {
  direction         = "ingress"
  ethertype         = "IPv4"
  protocol          = "tcp"
  port_range_min    = 443
  port_range_max    = 443
  security_group_id = openstack_networking_secgroup_v2.pare_feu_hds.id
}

Le disque de données n’accepte pas la suppression automatique (delete_on_termination = false), une précaution volontaire : une commande terraform destroy lancée par erreur ne doit jamais pouvoir emporter les données du client avec elle.

Les points où la vigilance reste manuelle

Terraform décrit l’infrastructure, mais certains aspects propres à un hébergement HDS restent hors de son périmètre et nécessitent une vérification humaine régulière :

1. La certification HDS elle-même de l’hébergeur sous-jacent, à vérifier lors du choix du fournisseur cloud, pas dans le code.
2. Le contenu réel des sauvegardes, dont Terraform ne garantit que la politique de déclenchement, pas l’intégrité des données sauvegardées.
3. Les mises à jour de sécurité du système d’exploitation, gérées séparément par un outil de gestion de configuration comme Ansible.

Ce que l’audit a validé

Lors de l’audit suivant réalisé par le client, la capacité à présenter l’historique Git de l’infrastructure, avec chaque modification datée et justifiée dans le message de commit correspondant, a été citée comme un point fort par rapport à l’infrastructure précédente, configurée entièrement à la main.

Ce qui n’est pas décrit dans un fichier de configuration n’existe pas aux yeux d’un audit, même si cela fonctionne parfaitement en production.

En résumé

Décrire une infrastructure d’hébergement de données de santé en Terraform ne se substitue pas à la certification HDS de l’hébergeur, mais elle transforme une configuration opaque en un artefact traçable, relisable et reproductible — exactement ce qu’attend un auditeur, et exactement ce qui rassure une équipe qui doit reprendre le projet plus tard.