Configuration et activation de la surveillance améliorée

Pour utiliser la surveillance améliorée, vous devez créer un IAM rôle, puis activer la surveillance améliorée.

Création d'un IAM rôle pour une surveillance améliorée

La surveillance améliorée nécessite l'autorisation d'agir en votre nom pour envoyer des informations métriques du système d'exploitation à CloudWatch Logs. Vous accordez des autorisations de surveillance améliorée à l'aide d'un rôle AWS Identity and Access Management (IAM). Vous pouvez soit créer ce rôle lorsque vous activez la surveillance améliorée, soit le créer au préalable.

Création du IAM rôle lorsque vous activez la surveillance améliorée

Lorsque vous activez la surveillance améliorée dans la RDS console, Amazon RDS peut créer le IAM rôle requis pour vous. Le rôle est nommé rds-monitoring-role. RDSutilise ce rôle pour l'instance de base de données, la réplique de lecture ou le cluster de base de données multi-AZ spécifié.

Création du IAM rôle avant d'activer la surveillance améliorée

Vous pouvez créer le rôle requis avant d'activer la surveillance améliorée. Lorsque vous activez la surveillance améliorée, spécifiez le nom de votre nouveau rôle. Vous devez créer ce rôle obligatoire si vous activez la surveillance améliorée à l'aide du AWS CLI ou du RDSAPI.

L'utilisateur qui active la surveillance améliorée doit se voir accorder l'autorisation PassRole. Pour plus d'informations, consultez l'exemple 2 de la section Octroi à un utilisateur des autorisations pour transmettre un rôle à un AWS service dans le Guide de IAM l'utilisateur.

Activer et désactiver la surveillance améliorée

Vous pouvez gérer la surveillance améliorée à l'aide du AWS Management Console AWS CLI, ou RDSAPI. Vous pouvez définir différentes granularités pour la collecte des métriques sur chaque instance de base de données de de base de données.

aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --monitoring-interval 30 \
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess

aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --monitoring-interval 30 ^
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --monitoring-interval 30 \
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --monitoring-interval 30 ^
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess

Lutter contre le problème de l'adjoint confus

Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner un problème de confusion chez les adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le service appelant) appelle un autre service (le service appelé). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé d’accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services avec des principaux de service qui ont eu accès aux ressources de votre compte. Pour de plus amples informations, veuillez consulter Le problème de l'adjoint confus.

Pour limiter les autorisations à la ressource qu'Amazon RDS peut accorder à un autre service, nous vous recommandons d'utiliser les clés de contexte de condition aws:SourceAccount globale aws:SourceArn et les clés de contexte dans une politique de confiance pour votre rôle de surveillance améliorée. Si vous utilisez les deux clés de contexte de condition globale, elles doivent utiliser le même ID de compte.

Le moyen le plus efficace de se protéger contre le problème de confusion des adjoints consiste à utiliser la clé de contexte de la condition aws:SourceArn globale avec l'intégralité ARN de la ressource. Pour AmazonRDS, réglez aws:SourceArn surarn:aws:rds:Region:my-account-id:db:dbname.

L'exemple suivant utilise les clés de contexte de condition globale aws:SourceArn et aws:SourceAccount dans une politique d'approbation afin d'empêcher le problème d'adjoint confus.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "monitoring.rds.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "aws:SourceArn": "arn:aws:rds:Region:my-account-id:db:dbname"
        },
        "StringEquals": {
          "aws:SourceAccount": "my-account-id"
        }
      }
    }
  ]
}