Resource Access Management:AccessKey leak response plan

Gérer une fuite de paire AccessKey du compte Alibaba Cloud (compte racine)

• La paire AccessKey n'est plus utilisée — Accédez à la page de gestion des AccessKeys et désactivez et supprimez immédiatement la paire AccessKey.

• La paire AccessKey est utilisée — Effectuez une rotation de la paire AccessKey sur la page de gestion des AccessKeys :

  1. Créez une nouvelle paire AccessKey et stockez le secret AccessKey de manière sécurisée.

  2. Remplacez la paire AccessKey d'origine par la nouvelle.

  3. Après avoir confirmé que tout fonctionne normalement, désactivez et supprimez la paire AccessKey d'origine.

Avant de supprimer la paire AccessKey d'origine, identifiez son étendue d'utilisation comme décrit dans Identifier l'étendue d'utilisation de la paire AccessKey. Après avoir effectué la rotation ou supprimé la paire AccessKey, suivez les étapes décrites dans Enquêter sur les opérations anormales et Vérifier les frais anormaux.

Gérer une fuite de paire AccessKey d'un utilisateur RAM

La réponse appropriée dépend du fait que la paire AccessKey est toujours utilisée et, le cas échéant, si elle peut faire l'objet d'une rotation à court terme. Si la paire AccessKey peut être renouvelée, la rotation est la réponse recommandée.

La paire AccessKey n'est plus utilisée

Accédez à la console RAM et désactivez et supprimez la paire AccessKey. Pour obtenir des instructions, consultez Désactiver l'AccessKey d'un utilisateur RAM et Supprimer l'AccessKey d'un utilisateur RAM.

Lorsque vous désactivez une paire AccessKey, la console vous demande d'effectuer une authentification de sécurité (authentification multifacteur, MFA). Le statut de la paire AccessKey passe à Désactivé uniquement après la réussite de l'authentification. Si la paire AccessKey a été utilisée au cours des 60 derniers jours, la console vous avertit que sa désactivation peut perturber votre activité. Confirmez qu'aucune activité ne dépend de la paire AccessKey avant de continuer.

La paire AccessKey est utilisée et peut faire l'objet d'une rotation (Recommandé)

Effectuez une rotation de la paire AccessKey dès que possible :

1. Cliquez sur Create AccessKey. Dans la boîte de dialogue Scenarios, sélectionnez le scénario correspondant à votre utilisation réelle parmi CLI, Local Development, ECS, ACK, Third-party Application et Other.

2. Créez la nouvelle paire AccessKey et stockez le secret AccessKey de manière sécurisée.

3. Remplacez la paire AccessKey d'origine par la nouvelle.

4. Après avoir confirmé que tout fonctionne normalement, désactivez et supprimez l'ancienne paire AccessKey.

   Pour obtenir des instructions, consultez Effectuer la rotation de l'AccessKey d'un utilisateur RAM.

Lorsque vous supprimez une paire AccessKey, vous devez saisir manuellement l'AccessKey ID pour effectuer une seconde confirmation. Si la paire AccessKey a été désactivée depuis moins de sept jours, la console vous avertit que sa suppression peut perturber votre activité. Confirmez qu'aucune activité ne dépend de la paire AccessKey avant de continuer. Une paire AccessKey supprimée n'est pas détruite immédiatement. Elle est déplacée vers la corbeille, conservée pendant 30 jours, puis automatiquement effacée. Pour restaurer la paire AccessKey, effectuez l'opération dans le délai de conservation.

La paire AccessKey est utilisée mais ne peut pas faire l'objet d'une rotation à court terme

Si vous confirmez que la paire AccessKey est utilisée mais ne peut pas être renouvelée facilement à court terme, suivez les étapes illustrées dans la figure suivante pour réduire l'impact d'une utilisation abusive. Effectuez la rotation dès que possible par la suite.

Étape 1 : Réduire les permissions de la paire AccessKey

Identifiez d'abord votre scénario métier. Sans perturber les opérations en cours, réduisez dès que possible les permissions de la paire AccessKey suspectée. Restreignez les permissions à haut risque pour diminuer le risque de dommages à votre activité et à votre facturation. Ne révoquez pas cette politique restrictive tant que la paire AccessKey n'a pas été désactivée et supprimée.

Les permissions à haut risque recommandées à restreindre incluent : empêcher l'utilisateur RAM de créer de nouveaux utilisateurs RAM ou d'accorder des permissions dans RAM, bloquer la libération des ressources ECS, RDS, OSS et SLS, et bloquer l'envoi de SMS.

L'exemple suivant montre une politique personnalisée qui refuse les actions à haut risque. Évaluez son impact minutieusement et ajustez-la en fonction de vos besoins métier.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ram:AddUserToGroup",
        "ram:AttachPolicyToGroup",
        "ram:AttachPolicyToRole",
        "ram:AttachPolicyToUser",
        "ram:ChangePassword",
        "ram:CreateAccessKey",
        "ram:CreateLoginProfile",
        "ram:CreatePolicyVersion",
        "ram:CreateRole",
        "ram:CreateUser",
        "ram:DetachPolicyFromUser",
        "ram:PassRole",
        "ram:SetDefaultPolicyVersion",
        "ram:UpdateAccessKey",
        "ram:SetPasswordPolicy",
        "ram:UpdateRole",
        "ram:UpdateLoginProfile",
        "ram:UpdateUser"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ecs:DeleteInstance",
        "ecs:DeleteInstances",
        "ecs:DeregisterManagedInstance",
        "ecs:ReleaseDedicatedHost"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "rds:DeleteAccount",
        "rds:DeleteDatabase",
        "rds:DeleteDBInstance",
        "rds:DestroyDBInstance"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteBucket",
        "oss:DeleteObject",
        "oss:PutBucketAcl",
        "oss:PutBucketPolicy"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "log:DeleteLogStore",
        "log:DeleteProject",
        "log:PutProjectPolicy",
        "log:DeleteProjectPolicy"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "dysms:CreateProductNew",
        "dysms:CreateSmsTemplateNew",
        "dysms:AddSmsTemplate",
        "dysms:SendSms",
        "dysms:SendBatchSms"
      ],
      "Resource": "*"
    }
  ]
}

Pour obtenir des instructions, consultez Créer une politique personnalisée et Gérer les permissions des utilisateurs RAM.

Définissez clairement les permissions métier dont la paire AccessKey a besoin et supprimez toutes les permissions inutiles.

Étape 2 : Activer la MFA pour l'utilisateur RAM

En tant que bonne pratique, activez l'authentification multifacteur (MFA) pour tous les utilisateurs RAM sous votre compte Alibaba Cloud (compte racine) qui accèdent à la console.

• Exigez la MFA pour que les utilisateurs RAM sous le compte racine se connectent à la console. Pour obtenir des instructions, consultez Exiger la MFA pour la connexion des utilisateurs RAM.

• Associez un dispositif MFA à l'utilisateur. Pour obtenir des instructions, consultez Associer un dispositif MFA à un utilisateur RAM.

  Après avoir réduit les permissions et activé la MFA, suivez les étapes décrites dans Enquêter sur les opérations anormales, Identifier l'étendue d'utilisation de la paire AccessKey et Vérifier les frais anormaux. Ensuite, effectuez la rotation dès que possible.

Enquêter sur les opérations anormales

Vérifiez si la paire AccessKey qui a fuité présente des opérations anormales et enquêtez pour déterminer si d'autres identités sont suspectées d'avoir fuité. Concentrez-vous sur les adresses IP source anormales et les opérations de création ou de suppression de ressources dont votre activité n'a pas besoin.

Les opérations dangereuses à investiguer pendant la période de fuite incluent :

• Modifications d'identité et de permissions : création d'utilisateurs RAM (CreateUser), création de paires AccessKey (CreateAccessKey), attachement de politiques d'accès (AttachPolicyToUser), création de rôles (CreateRole) et activation de la connexion à la console (CreateLoginProfile). Des événements tels que CreateLoginProfile, AttachPolicyToUser et CreateUser indiquent généralement qu'un attaquant crée des comptes backdoor ou élève ses privilèges. Soyez particulièrement attentif aux adresses IP source et aux UserAgents de ces appels.

• Suppression et libération de ressources : suppression d'instances ECS (DeleteInstance), suppression d'instances RDS (DeleteDBInstance) et suppression de buckets OSS (DeleteBucket).

• Exfiltration de données : modification des permissions d'accès aux buckets OSS (PutBucketAcl), modification des politiques de buckets OSS (PutBucketPolicy) et opérations similaires.

• Comportement d'appel anormal : grand nombre de requêtes API sur une courte période, opérations provenant d'adresses IP ou de régions inhabituelles et opérations par lots en dehors des heures de travail.

  Pour vérifier : dans la console RAM, trouvez la liste des AccessKeys de l'utilisateur RAM et consultez les enregistrements d'opérations dans la liste, ou saisissez l'AccessKey ID sur la page AccessKey audit de la console ActionTrail pour interroger directement les enregistrements d'opérations.

En plus d'ActionTrail, vous pouvez vous connecter à la console Security Center pour afficher les détails des alertes de fuite d'AccessKey, y compris les noms des utilisateurs RAM créés malicieusement et les adresses IP d'appel anormales.

La fonctionnalité d'audit AccessKey d'ActionTrail affiche tous les appels API d'une paire AccessKey spécifiée au cours des 90 derniers jours, y compris l'heure de l'appel, le nom de l'action, l'adresse IP source et le service cloud accédé. Pour obtenir des instructions, consultez Audit AccessKey.

Pour les journaux d'opérations du plan de données qui ne sont pas connectés à ActionTrail, tels que ceux d'OSS et de SLS, utilisez la fonctionnalité de journalisation de chaque service cloud pour effectuer des requêtes.

Enquêtez plus avant pour déterminer si d'autres utilisateurs RAM et paires AccessKey présentent des opérations anormales en plus de la paire AccessKey présentant un risque de fuite connu. Si vous constatez un comportement anormal, confirmez avec la personne concernée si les opérations ont été effectuées par elle. Si une fuite est suspectée, procédez comme suit :

• Si l'utilisateur RAM doit rester utilisé, changez immédiatement le mot de passe de l'utilisateur RAM et activez l'authentification multifacteur (MFA).

• Si l'utilisateur RAM n'a pas été créé légitimement ou s'il est confirmé qu'il s'agit d'un utilisateur inactif qui n'est plus nécessaire, supprimez-le. Un utilisateur RAM supprimé est déplacé vers la corbeille. Surveillez si votre activité est affectée. Si c'est le cas, l'utilisateur RAM peut être restauré rapidement.

• Pour les opérations anormales d'une paire AccessKey, restreignez d'abord ses permissions, puis effectuez une rotation.

Identifier l'étendue d'utilisation de la paire AccessKey

Les adresses IP source enregistrées par ActionTrail ne reflètent que les appels d'événements de type gestion, tels que les opérations de gestion GetService et GetBucketInfo d'OSS. Les opérations du plan de données qui ne sont pas connectées à ActionTrail, telles que les téléchargements et téléversements d'objets OSS, ne sont pas enregistrées par défaut. Par conséquent, la liste des adresses IP source seule ne peut pas révéler l'étendue complète d'utilisation de la paire AccessKey. Avant de désactiver ou de supprimer la paire AccessKey d'origine, vérifiez la configuration AccessKey dans chacun des environnements suivants :

• Machines de développement locales — Variables d'environnement du développeur, fichiers de configuration SDK et fichiers d'identifiants CLI.

• Pipelines CI/CD — Variables d'environnement des jobs de build, magasins d'identifiants et scripts de déploiement.

• Applications tierces et SaaS — Identifiants accordés aux plateformes externes qui appellent les API Alibaba Cloud.

• Conteneurs et images — Couches d'images de conteneurs, secrets Kubernetes et identifiants dans les modèles d'orchestration.

• Tâches planifiées et scripts d'exploitation — Entrées crontab du serveur, scripts de sauvegarde et collecteurs de surveillance.

• Services de messagerie et de notification — Appelants tels que les applications qui appellent Short Message Service pour envoyer des SMS.

  Après avoir remplacé tous ces environnements par la nouvelle paire AccessKey et confirmé que votre activité fonctionne normalement, désactivez ou supprimez la paire AccessKey d'origine. Cela évite les perturbations de l'activité causées par un appelant oublié.

Vérifier les frais anormaux

Dans Expenses and Costs, vérifiez si des frais anormaux sont générés. Pour les services affectés, prenez des mesures de protection basées sur les opérations anormales que vous avez identifiées lors de l'enquête.

Que faire si une fuite d'AccessKey empêche un utilisateur RAM de se connecter ou si le compte est gelé ?

Lorsque le système de sécurité d'Alibaba Cloud détecte qu'une paire AccessKey présente un risque de fuite, il déclenche automatiquement des mécanismes de protection qui restreignent la connexion de l'utilisateur RAM associé à la console. Vous pouvez rencontrer des messages d'erreur tels que Authentication.Block.AccountFrozen ou « The current account is not allowed to log on. »

Pour résoudre ce problème :

1. Connectez-vous à la console RAM avec le compte Alibaba Cloud (compte racine). Désactivez ou supprimez immédiatement la paire AccessKey qui a fuité, puis créez une nouvelle paire AccessKey pour effectuer la rotation. La simple désactivation de la paire AccessKey peut ne pas lever la restriction. Vous devez la supprimer ou effectuer une rotation.

2. Après avoir traité la paire AccessKey, si l'utilisateur RAM ne peut toujours pas se connecter, soumettez un ticket pour demander la levée de la restriction de contrôle des risques de sécurité.

Pourquoi ma paire AccessKey est-elle détectée comme ayant fuité alors qu'elle est stockée dans un dépôt privé, Nacos ou une base de données hors ligne ?

Même si vous pensez que votre paire AccessKey est stockée de manière sécurisée, elle peut toujours être détectée ou volée via les voies courantes suivantes :

• Dépôts de code — Si un dépôt privé était auparavant public, a été forké ou si un collaborateur a téléchargé le code vers un autre emplacement, la paire AccessKey peut toujours être détectée par les services de scan.

• Centres de configuration (tels que Nacos) — Si le centre de configuration manque de contrôle d'accès, présente des vulnérabilités ou si le serveur a été compromis, les paires AccessKey stockées en texte clair peuvent être volées.

• Stockage hors ligne — Si l'application ou le script qui lit la paire AccessKey se connecte à Internet pour appeler des API, la clé peut être interceptée pendant la transmission ou écrite dans un enregistrement de journal.

• Vulnérabilités des applications — Les vulnérabilités d'exécution de code à distance (RCE) ou de lecture de fichier arbitraire peuvent permettre aux attaquants de voler des paires AccessKey à partir des fichiers de configuration sur le serveur.

  Pour prévenir les fuites futures :

• Utilisez l'outil Credentials pour gérer les identifiants au lieu de coder en dur les paires AccessKey.

• Configurez des restrictions d'accès réseau (liste blanche IP) pour les paires AccessKey.

• Évitez d'écrire directement les paires AccessKey dans le code source ou les fichiers de configuration.

Puis-je demander la désactivation d'urgence d'une paire AccessKey appartenant à un autre compte ?

En raison de la protection de la vie privée et de l'isolation des permissions, Alibaba Cloud ne peut pas désactiver directement, sur la base d'un signalement de fuite, une paire AccessKey qui n'appartient pas à votre compte actuellement connecté. Procédez comme suit :

1. Si vous connaissez le compte propriétaire de la paire AccessKey, contactez le titulaire du compte et demandez-lui de traiter la situation.

2. Si vous avez accès au compte propriétaire de la paire AccessKey, utilisez l'API DeleteAccessKey ou la console RAM pour supprimer la clé vous-même.

3. Pour les paires AccessKey ayant fuité qui appartiennent à d'autres comptes auxquels vous ne pouvez pas accéder, coordonnez le traitement par le biais de canaux juridiques ou de conformité en matière de sécurité.