Fintech : refonte IAM organization-wide avant audit ACPR

Le contexte

Une fintech B2B française, agréée ACPR, 80 personnes dont 25 ingénieurs. Un audit annuel ACPR programmé dans 8 semaines, avec un focus annoncé sur la sécurité d’accès aux environnements de production.

L’organisation AWS comptait alors 12 comptes, 280 IAM users, et un nombre indéterminé d’access keys long-lived disséminés. Pas de SSO, pas de SCPs, pas d’audit trail organisationnel. Un héritage de 4 ans de croissance rapide où chaque équipe avait créé ses propres rôles selon ses propres conventions.

L’équipe interne savait ce qu’il fallait faire. Elle n’avait simplement pas la bande passante pour mener la migration en parallèle de la roadmap produit, et l’auditeur arrivait.

Le diagnostic en semaine 1

Verdict : la posture IAM ne tiendrait pas 30 minutes en audit. Mais le périmètre était circonscrit et adressable en 6 semaines avec une équipe dédiée.

L’intervention

Semaine 1-2 — Foundation IAM Identity Center

Activation de AWS IAM Identity Center (ex-AWS SSO) au niveau de l’organisation, fédération SAML avec l’IdP existant (Okta) déjà utilisé pour les autres SaaS internes.

Définition de 6 permission sets correspondant aux profils métier :

• BillingReadOnly, DeveloperAccess, DataAnalyst, SecurityAuditor, Operator, Administrator

Chaque permission set est versionné en Terraform. Sessions limitées à 8 h (4 h pour Administrator). MFA obligatoire au niveau IdP, propagé au SSO.

resource "aws_ssoadmin_permission_set" "developer" {
  name             = "DeveloperAccess"
  instance_arn     = local.identity_center_arn
  session_duration = "PT8H"
}

resource "aws_ssoadmin_managed_policy_attachment" "developer_powers" {
  instance_arn       = local.identity_center_arn
  managed_policy_arn = "arn:aws:iam::aws:policy/PowerUserAccess"
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
}

Semaine 3 — SCPs organization-wide

Trois SCPs déployées au niveau Organizations :

1. DenyRegionsOutsideEU : interdit l’usage de régions hors eu-west-1 / eu-west-3 (sauf services globaux IAM/CloudFront/Route53). Compliance localisation des données.
2. DenyRootUser : aucune action n’est autorisée pour le root user en dehors des 4 comptes les plus sensibles, où une SCP override documentée s’applique.
3. DenyDisablingSecurityServices : interdiction de désactiver CloudTrail, Config, GuardDuty, Security Hub. Même pour un Administrator.

Application progressive : OU Sandbox d’abord (test), puis Workloads en mode dry-run via Service Last Accessed, puis enforcement hard.

Semaine 4 — Migration des accès humains

L’opération critique. 280 IAM users à supprimer, mais sans casser les accès du jour au lendemain.

La bascule s’est faite par OU sur 5 jours :

• Jour 1-2 : équipes Data + BI (40 users) — usage console uniquement, bascule simple
• Jour 3 : équipes Dev (180 users) — communication anticipée, runbook partagé, bouton de retour visible
• Jour 4 : équipes Ops + SecOps (50 users) — coordination avec les rotations on-call
• Jour 5 : Admins + Auditeurs (10 users)

Pour chaque user IAM supprimé, mapping documenté vers son groupe Okta + permission set. Aucune perte d’accès, aucun ticket support critique pendant la fenêtre.

Semaine 5 — Access keys et rôles

47 access keys IAM long-lived identifiées via le Credential Report. Catégorisation :

Toutes les keys ont été rotées ou supprimées en semaine 5. Le Credential Report est passé de 47 à 0 access keys long-lived sur des principals humains.

Semaine 6 — CloudTrail organisationnel + audit trail

Création d’un compte dédié Log Archive, déjà partiellement existant mais non scopé organisation-wide. Bascule de tous les CloudTrails par compte vers un organization-wide trail unique :

resource "aws_cloudtrail" "organization" {
  name                          = "organization-trail"
  s3_bucket_name                = aws_s3_bucket.log_archive.id
  is_organization_trail         = true
  is_multi_region_trail         = true
  include_global_service_events = true
  enable_log_file_validation    = true
}

Bucket S3 avec Object Lock COMPLIANCE 7 ans, accès lecture seule depuis le compte d’audit. Les findings GuardDuty et Security Hub sont également agrégés dans le compte d’audit.

Le résultat à l’audit ACPR

L’audit a eu lieu 2 semaines après la fin de la mission. Le périmètre IAM a tenu 4 h d’examen sans difficulté :

• 0 IAM user humain résiduel, 100 % des accès via SSO + MFA
• 0 access key long-lived sur principals humains, machines via OIDC ou rôles assumables uniquement
• 3 SCPs documentées et appliquées, avec preuves de revue trimestrielle planifiée
• CloudTrail organisationnel avec rétention 7 ans, intégrité validée
• Permission sets versionnés en Git, traçabilité complète des changements

L’auditeur a sorti 0 finding critique sur le périmètre IAM. Deux observations mineures sur la fréquence des access reviews (trimestrielle au lieu de mensuelle) — corrigées avant la rédaction du rapport.

Ce qu’on en retient

Cette mission illustre trois principes que nous appliquons systématiquement :

1. L’urgence d’audit n’autorise pas le bricolage. Tout ce qu’on a fait reste en place 18 mois plus tard, parce qu’on a investi le temps de bien faire le passage par Identity Center et Terraform plutôt que de patcher en surface.
2. Le bouton de retour est non-négociable. Avant chaque bascule (OU, SCP, suppression d’access key), un runbook de rollback signé. C’est ce qui permet de bouger vite sans casser.
3. L’humain est le facteur limitant. La migration technique d’IAM Identity Center prend 5 jours. La conduite du changement (formation, runbooks, communication, tickets de support) prend les 5 semaines restantes. Sous-estimer cette partie, c’est se retrouver avec une infra propre et des équipes hostiles.

Le client a depuis intégré la revue trimestrielle des permission sets dans son cycle d’engineering, et a ajouté un dashboard Security Hub partagé en weekly avec le RSSI.