View a markdown version of this page

Utiliser le courrier électronique des services de reporting pour envoyer des rapports - Amazon Relational Database Service

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.

Utiliser le courrier électronique des services de reporting pour envoyer des rapports

SSRS et PBIRS incluent une extension de courrier électronique que vous pouvez utiliser pour envoyer des rapports aux utilisateurs.

Pour configurer le courrier électronique pour SSRS, utilisez les paramètres des SSRS options. Pour configurer le courrier électronique pour le PBIRS, utilisez les paramètres des PBIRS options. Pour de plus amples informations, veuillez consulter Ajout de l'option SSRS ou PBIRS à votre groupe d'options.

Après avoir configuré le courrier électronique, vous pouvez vous abonner aux rapports sur le serveur de rapports. Pour obtenir plus d'informations, consultez la rubrique Email delivery in Reporting Services (Livraison d'e-mails dans Reporting Services) dans la documentation Microsoft.

L'intégration avec AWS Secrets Manager est requise pour que le courrier électronique des services de reporting fonctionne sur RDS. Pour l'intégrer à Secrets Manager, il faut créer un secret.

Note

Si vous modifiez le secret ultérieurement, vous devez également mettre à jour l'PBIRSoption SSRS ou dans le groupe d'options.

Pour créer un secret pour le courrier électronique des services de reporting

  1. Suivez les étapes de la section Create a secret (Créer un secret) du Guide de l'utilisateur AWS Secrets Manager .

    1. Pour Select secret type (Sélectionner un type de secret), choisissez Other type of secrets (Autre type de secrets).

    2. Pour les Key/value paires, entrez ce qui suit :

      • SMTP_USERNAME : entrez un utilisateur ayant l'autorisation d'envoyer des e-mails à partir du serveur SMTP.

      • SMTP_PASSWORD : saisissez un mot de passe pour l'utilisateur SMTP.

    3. Pour Encryption key (Clé de chiffrement), n'utilisez pas la valeur AWS KMS key par défaut. Utilisez votre propre clé existante, ou créez-en une.

      La politique de clé KMS doit autoriser l'action kms:Decrypt, par exemple :

      {
    "Sid": "Allow use of the key",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "rds.amazonaws.com"
        ]
    },
    "Action": [
        "kms:Decrypt"
    ],
    "Resource": "*"
}

  2. Suivez les étapes de la section Attach a permissions policy to a secret (Attacher une politique d'autorisations à un secret) du Guide de l'utilisateur AWS Secrets Manager . La politique d'autorisations transmet l'action secretsmanager:GetSecretValue au principal du service rds.amazonaws.com.

    Nous vous recommandons d'utiliser les conditions aws:sourceAccount et aws:sourceArn dans la politique pour éviter le problème de l’adjoint confus. Utilisez votre Compte AWS for aws:sourceAccount et l'ARN du groupe d'options pouraws:sourceArn. Pour de plus amples informations, veuillez consulter Prévention des problèmes d'adjoint confus entre services.

    Voici un exemple de stratégie d'autorisation.

    JSON
    {
  "Version":"2012-10-17",
  "Statement" : [ {
    "Effect" : "Allow",
    "Principal" : {
      "Service" : "rds.amazonaws.com"
    },
    "Action" : "secretsmanager:GetSecretValue",
    "Resource" : "*",
    "Condition" : {
      "StringEquals" : {
        "aws:sourceAccount" : "123456789012"
      },
      "ArnLike" : {
        "aws:sourceArn" : "arn:aws:rds:us-west-2:123456789012:og:ssrs-se-2017"
      }
    }
  } ]
}

    Pour plus d'exemples, consultez les exemples de politique d'autorisations pour AWS Secrets Manager dans le guide de AWS Secrets Manager l'utilisateur.