Rotation des mots de passe MySQL: utilisation d'un seul utilisateur pour modifier les autres mots de passe des utilisateurs

Aug 16 2020

Je travaille actuellement sur la mise en place d'une stratégie de rotation des mots de passe pour une application basée sur AWS Aurora / MySQL.

Mon plan était d'utiliser une stratégie comme celle-ci ...

  • Noms d'utilisateur / mots de passe d'application stockés dans les paramètres chiffrés AWS SSM.
  • Les serveurs d'applications ont accès pour récupérer uniquement leurs informations d'identification à partir de SSM. Restreint par l'environnement (mise en scène, production, etc.)
  • Lambda est configuré pour s'exécuter périodiquement pour modifier les mots de passe dans MySQL et stocker les nouvelles valeurs dans SSM. Lambda pour s'authentifier auprès de la base de données en utilisant des rôles AWS IAM, plutôt qu'en utilisant un mot de passe.

Le dernier élément est celui dont je ne suis pas sûr. Cette configuration exigerait que le rôle / l'utilisateur lambda soit autorisé à modifier les mots de passe de tous les autres utilisateurs de l'application.

Est-ce une manière raisonnable de le faire, du point de vue de la sécurité? Étant donné que l'utilisateur lambda mysql utilisera un rôle IAM plutôt qu'un mot de passe, cela devrait restreindre son utilisation aux seuls rôles autorisés.

L'alternative serait de ne pas avoir un utilisateur de base de données spécial pour que le lambda se connecte, mais plutôt que la fonction lambda récupère les informations d'identification de chaque utilisateur à partir de SSM, puis se connecte en tant qu'utilisateur pour changer son mot de passe.

Dans tous les cas, le lambda devra avoir accès à chaque utilisateur.

En supposant que je puisse récupérer soigneusement l'accès à "lambda_user" dans MySQL, y a-t-il d'autres problèmes flagrants avec le fait qu'un utilisateur ait l'autorisation de changer les mots de passe des autres utilisateurs?

En outre, juste pour clarifier, ce sont des utilisateurs d'applications, et non des utilisateurs de type humain réguliers qui utiliseront ces informations d'identification.

Réponses

1 ConorMancone Aug 16 2020 at 17:39

Il s'agit de la meilleure façon de procéder, pour exactement les raisons que vous indiquez. En demandant au Lambda d'utiliser un rôle pour l'authentification au lieu des informations d'identification, vous minimisez le nombre de secrets que vous gardez, ce qui est certainement une bonne chose. Il n'y a que 2 choses à souligner:

  1. Vous pouvez désormais utiliser CloudFormation pour automatiser l'approvisionnement et le déploiement d'un Lambda à usage spécial pour cela. En conséquence, vous pouvez le faire avec une relative facilité. Personnellement, je ne suis pas un grand fan de CloudFormation mais je l'utiliserais quand même ici.

  2. Le passage aux points de terminaison de métadonnées V2 peut fournir une sécurité supplémentaire de SSRF trouvée dans votre infrastructure ainsi que d'autres formes d'effraction, bien que cela ne soit pas très pertinent dans ce cas d'utilisation.