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.
Création manuelle d'un IAM rôle pour l'audit SQL du serveur
Généralement, lorsque vous créez une nouvelle option, le AWS Management Console IAM rôle et la politique de IAM confiance sont créés pour vous. Cependant, vous pouvez créer manuellement un nouveau IAM rôle à utiliser avec les audits de SQL serveur, afin de pouvoir le personnaliser en fonction de vos exigences supplémentaires. Pour ce faire, vous créez un IAM rôle et déléguez des autorisations afin que le RDS service Amazon puisse utiliser votre compartiment Amazon S3. Lorsque vous créez ce IAM rôle, vous y associez des politiques de confiance et d'autorisation. La politique de confiance permet RDS à Amazon d'assumer ce rôle. La politique d'autorisation définit les actions que ce rôle peut exécuter. Pour plus d'informations, consultez la section Création d'un rôle pour déléguer des autorisations à un AWS service dans le guide de l'utilisateur d'AWS Identity and Access Management.
Vous pouvez utiliser les exemples de cette section pour créer les relations d'approbation et les politiques d'autorisation dont vous avez besoin.
L'exemple suivant montre une relation de confiance pour SQL Server Audit. Il utilise le principal de service rds.amazonaws.com
pour RDS autoriser l'écriture dans le compartiment S3. Un principal de service est un identifiant utilisé pour accorder des autorisations à un service. Chaque fois que vous autorisez rds.amazonaws.com
l'accès de cette manière, vous êtes autorisé RDS à effectuer une action en votre nom. Pour plus d'informations sur les principaux de service, voir Éléments AWS JSON de politique : Principal.
Exemple relation de confiance pour l'audit des SQL serveurs
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "
rds.amazonaws.com
" }, "Action": "sts:AssumeRole" } ] }
Nous vous recommandons d'utiliser les clés de contexte de condition globale aws:SourceArn
et aws:SourceAccount
dans des relations d'approbation basées sur les ressources pour limiter les autorisations du service à une ressource spécifique. C'est le moyen le plus efficace de se protéger contre le problème du député confus.
Vous pouvez utiliser les deux clés de contexte de condition globale et faire en sorte que la valeur aws:SourceArn
contienne l'ID de compte. Dans ce cas, la valeur aws:SourceAccount
et le compte dans la valeur aws:SourceArn
doivent utiliser le même ID de compte lorsqu'ils sont utilisés dans la même instruction.
-
Utilisez
aws:SourceArn
si vous souhaitez un accès interservices pour une seule ressource. -
Utilisez
aws:SourceAccount
si vous souhaitez autoriser une ressource de ce compte à être associée à l'utilisation interservices.
Dans la relation de confiance, veillez à utiliser la clé de contexte de condition aws:SourceArn
globale avec le nom complet de la ressource Amazon (ARN) des ressources accédant au rôle. Pour l'audit SQL du serveur, assurez-vous d'inclure à la fois le groupe d'options de base de données et les instances de base de données, comme indiqué dans l'exemple suivant.
Exemple relation de confiance avec la clé de contexte de condition globale pour l'audit SQL du serveur
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceArn": [ "arn:aws:rds:
Region
:my_account_ID
:db:db_instance_identifier
", "arn:aws:rds:Region
:my_account_ID
:og:option_group_name
" ] } } } ] }
Dans l'exemple suivant de politique d'autorisation pour l'audit de SQL serveur, nous spécifions un ARN pour le compartiment Amazon S3. Vous pouvez l'utiliser ARNs pour identifier un compte, un utilisateur ou un rôle spécifique auquel vous souhaitez accorder l'accès. Pour plus d'informations sur l'utilisationARNs, consultez Amazon resource names (ARNs).
Exemple politique d'autorisations pour l'audit des SQL serveurs
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketACL", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::
amzn-s3-demo-bucket
" }, { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:ListMultipartUploadParts", "s3:AbortMultipartUpload" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket
/key_prefix
/*" } ] }
Note
L's3:ListAllMyBuckets
action est requise pour vérifier que le même AWS compte possède à la fois le compartiment S3 et l'instance de base de données SQL du serveur. L'action répertorie les noms des compartiments du compte.
Les espaces de noms de compartiment S3 sont globaux. Si vous supprimez accidentellement votre compartiment, un autre utilisateur peut créer un compartiment portant le même nom dans un compte différent. Les données d'audit SQL du serveur sont ensuite écrites dans le nouveau compartiment.