SQL Server Audit

Dans Amazon RDS, vous pouvez effectuer un audit des bases de données Microsoft SQL Server à l'aide du mécanisme d'audit SQL Server intégré. Vous pouvez créer des audits et des spécifications d'audit de la même manière que pour des serveurs de base de données sur site.

RDS charge les journaux d'audit terminés dans votre compartiment S3 à l'aide du rôle IAM que vous fournissez. Si vous activez la rétention, RDS conserve vos journaux d'audit sur votre instance de base de données pendant la période configurée.

Pour de plus amples informations, veuillez consulter SQL Server Audit (Database Engine) dans la documentation Microsoft SQL Server.

Audit SQL Server avec des flux d'activité de base de données

Vous pouvez utiliser Database Activity Streams for RDS pour intégrer les événements d'audit de SQL Server aux outils de surveillance de l'activité des bases de données d'Imperva et d' McAfeeIBM. Pour plus d'informations sur l'audit avec les flux d'activité de base de données pour RDS SQL Server, consultez Audit dans Microsoft SQL Server

Prise en charge de SQL Server Audit

Dans Amazon RDS à partir de SQL Server 2014, toutes les éditions de SQL Server prennent en charge les audits au niveau du serveur, et l'édition Enterprise prend également en charge les audits au niveau de la base de données. À partir de SQL Server 2016 (13.x) SP1, toutes les éditions prennent en charge les audits au niveau du serveur et au niveau de la base de données. Pour de plus amples informations, consultez SQL Server Audit (moteur de base de données) dans la documentation SQL Server.

RDS prend en charge la configuration des paramètres d'option suivants pour SQL Server Audit :

Ajout de SQL Server Audit aux options d'instance de base de données

L'activation de SQL Server Audit se fait en deux étapes : l'activation de l'option sur l'instance de base de données et l'activation de la fonction dans SQL Server. Le processus d'ajout de l'option SQL Server Audit à une instance de base de données est le suivant :

Une fois que vous avez ajouté l'option SQL Server Audit, vous n'avez pas besoin de redémarrer votre instance de base de données. Dès que le groupe d'options est actif, vous pouvez créer des audits et stocker les journaux d'audit dans votre compartiment S3.

Modification de l'option SQL Server Audit

Une fois que vous avez activé l'option SQL Server Audit, vous pouvez modifier les paramètres. Pour de plus amples informations sur la modification des paramètres d'option, veuillez consulter Modification d'un paramètre d'option.

Suppression de SQL Server Audit des options d'instance de base de données

Vous pouvez désactiver la fonction SQL Server Audit en désactivant les audits, puis en supprimant l'option.

Utilisation de SQL Server Audit

Vous pouvez contrôler les audits de serveur, les spécifications d'audit de serveur et les spécifications d'audit de base de données, de la même manière que vous les contrôlez pour vos serveurs de base de données sur site.

Création d'audits

Vous pouvez créer des audits de serveur de la même manière que pour des serveurs de base de données sur site. Pour plus d'informations sur la création d'audits de serveur, consultez CREATE SERVER AUDIT dans la documentation Microsoft SQL Server.

Pour éviter les erreurs, respectez les limitations suivantes :

Création de spécifications d'audit

Vous créez des spécifications d'audit de serveur et des spécifications d'audit de base de données, de la même manière que vous les créez pour vos serveurs de base de données sur site. Pour plus d'informations sur la création de spécifications d'audit, consultez CREATE SERVER AUDIT SPECIFICATION et CREATE DATABASE AUDIT SPECIFICATION dans la documentation Microsoft SQL Server.

Pour éviter les erreurs, n'utilisez pas RDS_ comme préfixe dans le nom de la spécification d'audit de base de données ou la spécification d'audit de serveur.

Consultation des journaux d'audit

Vos journaux d'audit sont stockés dans D:\rdsdbdata\SQLAudit.

Après que SQL Server a fini d'écrire dans un fichier de journal d'audit (quand le fichier atteint sa limite de taille), Amazon RDS charge le fichier dans votre compartiment S3. Si la rétention est activée, Amazon RDS déplace le fichier vers le dossier de rétention : D:\rdsdbdata\SQLAudit\transmitted.

Pour plus d'informations sur la rétention, consultez Ajout de SQL Server Audit aux options d'instance de base de données.

Les enregistrements d'audit sont conservés sur l'instance de base de données jusqu'à ce que le fichier de journal soit chargé. Vous pouvez afficher les enregistrements d'audit en exécutant la commande suivante.

SELECT   * 
	FROM     msdb.dbo.rds_fn_get_audit_file
	             ('D:\rdsdbdata\SQLAudit\*.sqlaudit'
	             , default
	             , default )

Vous pouvez utiliser la même commande pour afficher les enregistrements d'audit de votre dossier de rétention en modifiant le filtre en D:\rdsdbdata\SQLAudit\transmitted\*.sqlaudit.

SELECT   * 
	FROM     msdb.dbo.rds_fn_get_audit_file
	             ('D:\rdsdbdata\SQLAudit\transmitted\*.sqlaudit'
	             , default
	             , default )

Utilisation de SQL Server Audit avec des instances multi-AZ

Pour les instances multi-AZ, le processus d'envoi de fichiers de journal d'audit à Amazon S3 est similaire au processus utilisé pour les instances mono-AZ. Cependant, il existe quelques différences importantes :

Pour capturer des audits de serveur ou une spécification d'audit de serveur depuis les deux nœuds :

Configuration d'un compartiment S3

Les fichiers journaux d'audit sont chargés automatiquement depuis l'instance de base de données vers votre compartiment S3. Les restrictions suivantes s'appliquent au compartiment S3 que vous utilisez comme cible pour vos fichiers d'audit :

La clé cible qui est utilisée pour stocker les données suit ce schéma de dénomination : DOC-EXAMPLE-BUCKET/key-prefix/instance-name/audit-name/node_file-name.ext

Le schéma est composé des éléments suivants :

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.

{
	    "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.

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.

{
    "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 utiliser des ARN pour identifier un compte, un utilisateur ou un rôle spécifique auquel vous souhaitez accorder l'accès. Pour de plus amples informations sur l'utilisation des ARN, veuillez consulter Amazon Resource Names (ARN).

{
	    "Version": "2012-10-17",
	    "Statement": [
	        {
	            "Effect": "Allow",
	            "Action": "s3:ListAllMyBuckets",
	            "Resource": "*"
	        },
	        {
	            "Effect": "Allow",
	            "Action": [
	                "s3:ListBucket",
	                "s3:GetBucketACL",
	                "s3:GetBucketLocation"
	            ],
	            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET"
	        },
	        {
	            "Effect": "Allow",
	            "Action": [
	                "s3:PutObject",
	                "s3:ListMultipartUploadParts",
	                "s3:AbortMultipartUpload"
	            ],
	            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/key_prefix/*"
	        }
	    ]
	}