Empêcher les ressources cloud orphelines lors des changements de poste

Lorsque les employés changent d'équipe ou sont promus, leur empreinte numérique dans l'infrastructure cloud reste souvent inchangée. Cela crée un fossé où des ressources critiques sont toujours étiquetées avec des propriétaires qui n'en assurent plus la gestion, entraînant des risques de sécurité et des goulets d'étranglement opérationnels. Un guide récent met en lumière comment détecter et corriger ces étiquettes de propriété obsolètes en utilisant les données d'identité existantes.

Ce qui s'est passé

L'article décrit un scénario courant où un ingénieur, Marcus, passe de l'ingénierie de plateforme à un rôle lié aux données. Alors que les RH et le service informatique mettent à jour son intitulé de poste et ses accès par badge, les quarante et un environnements cloud dont il avait précédemment la charge restent étiquetés avec son adresse e-mail. Huit mois plus tard, Marcus reçoit une demande d'approbation pour l'un de ces environnements. Manquant de contexte mais sous pression pour vider sa file d'attente, il approuve la demande sans examen approprié.

Cet incident illustre que le « dernier jour » signifie rarement quitter entièrement l'entreprise. Plus souvent, il marque la fin de la responsabilité pour des actifs spécifiques. Les changements de propriété de l'infrastructure ne bénéficient pas de la même attention procédurale que les changements de rôle, laissant les ressources orphelines ou mal gérées jusqu'à ce qu'un audit de sécurité ou une défaillance survienne. La solution proposée implique l'utilisation de requêtes de données pour identifier les propriétaires inactifs et l'application de politiques empêchant les lacunes de propriété lors des transferts.

Détails clés

• Les étiquettes de propriété obsolètes persistent car les mutations internes ne déclenchent pas les listes de contrôle standard de départ.
• Les utilisateurs AWS peuvent interroger aws_iam_user_last_accessed_details pour trouver les identifiants inutilisés depuis quatre-vingt-dix jours.
• Azure Entra ID permet de joindre directement les étiquettes de propriétaire des VM au userPrincipalName dans les journaux d'audit.
• GCP ne dispose pas de registres directs de connexion IAM, nécessitant des jointures avec les données de connexion Google Workspace à la place.
• Quatre-vingt-dix jours d'inactivité sont un indicateur fort que la propriété doit être examinée, bien que cela ne constitue pas une preuve définitive.
• Les moteurs de politique comme OPA peuvent appliquer des règles bloquant les modifications de ressources si aucun propriétaire actif n'est attribué.

Contexte

Les fournisseurs cloud permettent aux utilisateurs d'étiqueter les ressources avec des métadonnées, telles qu'un champ « owner ». Ces étiquettes sont souvent de simples chaînes de caractères, comme une adresse e-mail, et ne sont pas intrinsèquement liées aux systèmes de gestion des identités. Lorsqu'un employé quitte l'entreprise ou change de rôle, ses autorisations d'accès peuvent être mises à jour, mais ces étiquettes statiques restent intactes. Ce découplage signifie que les systèmes automatisés ne peuvent pas facilement déterminer si la personne listée comme propriétaire est encore active ou responsable de cet actif.

Les fournisseurs d'identité tels que AWS IAM, Microsoft Entra ID et Google Workspace maintiennent des journaux de l'activité utilisateur. En croisant ces journaux d'activité avec les étiquettes de ressources, les équipes peuvent identifier les divergences. Si la personne étiquetée comme propriétaire ne s'est pas authentifiée ou n'a accédé à aucun service pendant une période significative, telle que quatre-vingt-dix jours, cela suggère que ses responsabilités ont changé. Cette approche basée sur les données remplace les suppositions manuelles par des signaux observables.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés ou gérant une infrastructure cloud, une propriété obsolète conduit à une paralysie décisionnelle. Lorsqu'une demande d'approbation arrive dans la boîte de réception d'un ancien propriétaire, celui-ci peut l'approuver aveuglément pour éviter l'effort d'enquêter sur un projet qu'il ne comprend plus. Cela contourne les examens nécessaires de sécurité et de coûts, introduisant potentiellement des vulnérabilités ou des dépenses inutiles dans l'environnement.

De plus, les ressources orphelines deviennent invisibles pour les membres actuels de l'équipe. Sans un propriétaire clair et actif, les tâches de maintenance telles que le patching, la mise à l'échelle ou la décommissionnement sont négligées. Avec le temps, cela accumule une dette technique et des risques de sécurité. En traitant la propriété comme un rôle dynamique plutôt qu'une étiquette statique, les organisations garantissent que chaque ressource a une partie responsable actuellement engagée avec le système.

La mise en œuvre de ces contrôles nécessite peu de nouveaux outils. La plupart des organisations collectent déjà des journaux d'identité et utilisent des pipelines d'infrastructure-as-code. L'ajout d'une requête pour signaler les propriétaires inactifs et d'une vérification de politique pour appliquer des attributions valides s'intègre dans les flux de travail existants. Cela empêche l'accumulation de ressources zombies qui drainent le budget et compliquent les efforts de conformité.

Ce que vous pouvez faire

• Exécutez des requêtes SQL contre les journaux AWS, Azure ou GCP pour identifier les propriétaires de ressources sans activité au cours des quatre-vingt-dix derniers jours.
• Mappez les étiquettes de ressources aux noms d'utilisateur du fournisseur d'identité pour automatiser la détection de la propriété obsolète.
• Ajoutez une étape aux listes de contrôle de transfert interne exigeant la réattribution de toutes les ressources possédées avant la révocation de l'accès.
• Implémentez des règles de politique-as-code utilisant Rego ou des langages similaires pour refuser les modifications si aucune attribution valide n'est présente.