Création manuelle d'un rôle IAM pour SQL Server Audit - 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.

Création manuelle d'un rôle IAM pour SQL Server Audit

Généralement, lorsque vous créez une nouvelle option, le AWS Management Console rôle IAM et la politique de confiance IAM sont créés pour vous. Cependant, vous pouvez créer manuellement un rôle IAM à utiliser avec les audits SQL Server pour pouvoir le personnaliser avec les exigences supplémentaires que vous pourriez avoir. Pour ce faire, vous créez un rôle IAM et vous déléguez des autorisations pour que le service Amazon RDS puisse utiliser votre compartiment Amazon S3. Lorsque vous créez ce rôle IAM, vous attachez des politiques d'approbation et d'autorisation. La politique d'approbation permet à Amazon RDS 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.

Voici un exemple de relation d'approbation de rôle pour SQL Server Audit. Elle utilise le principal de service rds.amazonaws.com pour autoriser RDS à écrire dans le compartiment S3. Un principal de service est un identifiant utilisé pour accorder des autorisations à un service. Chaque fois que vous autorisez l'accès à rds.amazonaws.com de cette manière, vous autorisez RDS à exécuter une action en votre nom. Pour en savoir plus sur les principaux de service, veuillez consulter Éléments de politique JSON d'AWS  : Principal.

Exemple relation d'approbation pour SQL Server Audit
JSON
{
	    "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 d'approbation, assurez-vous d'utiliser la clé de contexte de condition globale aws:SourceArn avec l'Amazon Resource Name (ARN) complet des ressources qui accèdent au rôle. Pour SQL Server Audit, veillez à 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 d'approbation avec la clé de contexte de condition globale pour SQL Server Audit
JSON
{
    "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 SQL Server Audit, 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'utilisation ARNs, consultez Amazon resource names (ARNs).

Exemple politique d'autorisations pour SQL Server Audit
JSON
{
	    "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:ListAllMyBucketsaction 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 Server. 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. Ensuite, les données d'audit SQL Server sont écrites dans le nouveau compartiment.