Validation des autorisations pour les API appels Application Auto Scaling sur les ressources cibles - Application Autoscaling

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Validation des autorisations pour les API appels Application Auto Scaling sur les ressources cibles

Pour envoyer des demandes autorisées aux API actions Application Auto Scaling, l'APIappelant doit être autorisé à accéder aux AWS ressources du service cible et du service cible. CloudWatch Application Auto Scaling valide les autorisations pour les demandes associées à la fois au service cible et CloudWatch avant de traiter la demande. Pour ce faire, nous lançons une série d'appels pour valider les IAM autorisations sur les ressources cibles. Lorsqu’une réponse est renvoyée, elle est lue par Application Auto Scaling. Si les IAM autorisations n'autorisent pas une action donnée, Application Auto Scaling échoue à la demande et renvoie une erreur à l'utilisateur contenant des informations sur l'autorisation manquante. Cela garantit que la configuration de mise à l’échelle que l’utilisateur souhaite déployer fonctionne comme prévu et qu’une erreur utile est renvoyée en cas d’échec de la demande.

À titre d'exemple de la manière dont cela fonctionne, les informations suivantes fournissent des détails sur la manière dont Application Auto Scaling effectue les validations d'autorisations avec Aurora et CloudWatch.

Lorsqu'un utilisateur appelle le pour RegisterScalableTarget API un cluster de base de données Aurora, Application Auto Scaling effectue toutes les vérifications suivantes pour vérifier que l'utilisateur dispose des autorisations requises (en gras).

  • RDS:c reateDBInstance : Pour déterminer si l'utilisateur dispose de cette autorisation, nous envoyons une demande à l'CreateDBInstanceAPIopération, en essayant de créer une instance de base de données avec des paramètres non valides (ID d'instance vide) dans le cluster de base de données Aurora spécifié par l'utilisateur. Pour un utilisateur autorisé, le API renvoie une réponse par code InvalidParameterValue d'erreur après avoir audité la demande. Cependant, pour un utilisateur non autorisé, nous obtenons une erreur AccessDenied et nous faisons échouer la demande d’Application Auto Scaling avec une erreur ValidationException pour l’utilisateur qui énumère les autorisations manquantes.

  • rds:D eleteDBInstance : Nous envoyons un identifiant d'instance vide à l'opération. DeleteDBInstance API Pour un utilisateur autorisé, cette demande aboutit à une erreur InvalidParameterValue. Pour un utilisateur non autorisé, le résultat est AccessDenied et une exception de validation est envoyée à l’utilisateur (même traitement que celui décrit dans le premier point).

  • rds : AddTagsToResource : L'AddTagsToResourceAPIopération nécessitant un nom de ressource Amazon (ARN), il est nécessaire de spécifier une ressource « fictive » en utilisant un identifiant de compte (12345) et un identifiant d'instance factice () non valides pour créer le (non-existing-db). ARN arn:aws:rds:us-east-1:12345:db:non-existing-db Pour un utilisateur autorisé, cette demande aboutit à une erreur InvalidParameterValue. Pour un utilisateur non autorisé, le résultat est AccessDenied et une exception de validation est envoyée à l’utilisateur.

  • rds:D escribeDBClusters : Nous décrivons le nom du cluster pour la ressource enregistrée pour le dimensionnement automatique. Pour un utilisateur autorisé, nous obtenons un résultat de description valide. Pour un utilisateur non autorisé, le résultat est AccessDenied et une exception de validation est envoyée à l’utilisateur.

  • rds:D escribeDBInstances : Nous les appelons DescribeDBInstances API avec un db-cluster-id filtre qui filtre en fonction du nom de cluster fourni par l'utilisateur pour enregistrer la cible évolutive. Pour un utilisateur autorisé, nous sommes autorisés à décrire toutes les instances de la base de données dans le cluster de bases de données. Pour un utilisateur non autorisé, cet appel aboutit à AccessDenied et envoie une exception de validation à l’utilisateur.

  • cloudwatch : PutMetricAlarm : Nous les appelons PutMetricAlarm API sans aucun paramètre. Parce que le nom de l’alarme est manquant, la demande aboutit à ValidationError pour un utilisateur autorisé. Pour un utilisateur non autorisé, le résultat est AccessDenied et une exception de validation est envoyée à l’utilisateur.

  • cloudwatch : DescribeAlarms : Nous appelons le DescribeAlarms API avec la valeur maximale du nombre d'enregistrements fixée à 1. Pour un utilisateur autorisé, nous attendons des informations sur une alarme dans la réponse. Pour un utilisateur non autorisé, cet appel aboutit à AccessDenied et envoie une exception de validation à l’utilisateur.

  • cloudwatch : DeleteAlarms : Comme PutMetricAlarm ci-dessus, nous ne fournissons aucun paramètre à DeleteAlarms demander. Comme il manque un nom d'alarme dans la demande, cet appel échoue avec ValidationError pour un utilisateur autorisé. Pour un utilisateur non autorisé, le résultat est AccessDenied et une exception de validation est envoyée à l’utilisateur.

Chaque fois que l’une de ces exceptions de validation se produit, elle est enregistrée. Vous pouvez prendre des mesures pour identifier manuellement les appels qui n'ont pas été validés en utilisant AWS CloudTrail. Pour plus d’informations, consultez le AWS CloudTrail Guide de l’utilisateur .

Note

Si vous recevez des alertes concernant des événements Application Auto Scaling en utilisant CloudTrail, ces alertes incluront les appels d'Application Auto Scaling pour valider les autorisations des utilisateurs par défaut. Pour filtrer ces alertes, utilisez le champ invokedBy, qui contiendra application-autoscaling.amazonaws.com pour ces vérifications de validation.