Audit in SQL Server

In Amazon RDS, si può eseguire l'audit dei database Microsoft SQL Server utilizzando il meccanismo di audit integrato in SQL Server. Si possono creare audit e specifiche di audit nello stesso modo in cui vengono creati per i server di database locali.

RDS carica i log completi dell'audit nel bucket S3 utilizzando il ruolo IAM che viene fornito. Se si abilita la retention, RDS conserva i log di audit nell'istanza database per il periodo di tempo configurato.

Per ulteriori informazioni, consulta Audit in SQL Server (Motore di database) nella documentazione di Microsoft SQL Server.

Audit di SQL Server con flussi di attività del database

È possibile utilizzare Database Activity Streams for RDS per integrare gli eventi di SQL Server Audit con gli strumenti di monitoraggio delle attività del database di Imperva e McAfee IBM. Per ulteriori informazioni sull'audit con i flussi di attività del database per RDS in SQL Server, consulta Verifica in Microsoft SQL Server

Supporto per l'audit in SQL Server

In Amazon RDS, a partire da SQL Server 2014, tutte le edizioni di SQL Server supportano gli audit a livello di server; inoltre, l'edizione Enterprise supporta anche gli audit a livello di database. A partire da SQL Server 2016 (13.x) SP1, tutte le edizioni supportano gli audit sia a livello di server che di database. Per ulteriori informazioni, consulta Audit in SQL Server (Motore di database) nella documentazione di SQL Server.

RDS supporta la configurazione delle seguenti impostazioni delle opzioni per l'audit in SQL Server.

Aggiunta dell'audit in SQL Server alle opzioni dell'istanza database

L'abilitazione dell'audit in SQL Server richiede due fasi: l'abilitazione dell'opzione nell'istanza database e l'abilitazione della funzione in SQL Server. La procedura per aggiungere l'opzione dell'audit in SQL Server a un'istanza database è la seguente:

Dopo aver aggiunto l'opzione dell'audit in SQL Server, non è necessario riavviare l'istanza database. Non appena il gruppo di opzioni diventa attivo, è possibile creare audit e archiviarne i log nel bucket S3.

Modifica dell'opzione Audit in SQL Server

Dopo aver abilitato l'opzione Audit in SQL Server, si possono modificare le impostazioni. Per informazioni su come modificare le impostazioni dell'opzione, consulta Modifica di un'impostazione di un'opzione.

Rimozione dell'audit in SQL Server dalle opzioni dell'istanza database

È possibile disattivare la funzione Audit in SQL Server disabilitando gli audit ed eliminando l'opzione.

Utilizzo dell'audit in SQL Server

È possibile controllare gli audit del server, le specifiche degli audit del server e le specifiche degli audit del database allo stesso modo in cui si controllano per i server di database locali.

Creazione degli audit

Si possono creare audit di server nello stesso modo in cui vengono creati per i server di database locali. Per informazioni su come creare audit di server, consulta la sezione CREAZIONE DI AUDIT DI SERVER nella documentazione di Microsoft SQL Server.

Per evitare errori, rispettare le seguenti restrizioni:

Creazione delle specifiche dell'audit

È possibile creare le specifiche degli audit del server e le specifiche degli audit del database allo stesso modo in cui vengono create per i server di database locali. Per informazioni sulla creazione delle specifiche dell'audit, consulta le sezioni CREAZIONE DELLE SPECIFICHE DELL'AUDIT DEL SERVER e CREAZIONE DELLE SPECIFICHE DELL'AUDIT DEL DATABASE nella documentazione di Microsoft SQL Server.

Per evitare errori, non utilizzare RDS_ come prefisso del nome della specifica dell'audit del database o del server.

Visualizzazione dei log di audit

I log di audit vengono archiviati in D:\rdsdbdata\SQLAudit.

Quando SQL Server finisce di scrivere un file di log di audit—quando il file raggiunge la dimensione massima—Amazon RDS carica il file nel bucket S3. Se la retention è abilitata, Amazon RDS sposta il file nella cartella di retentio: D:\rdsdbdata\SQLAudit\transmitted.

Per informazioni sulla configurazione della retention, consulta Aggiunta dell'audit in SQL Server alle opzioni dell'istanza database.

I registri dell'audit vengono conservati nell'istanza database fino a quando non viene caricato il file di log dell'audit. È possibile visualizzare i registri dell'audit eseguendo il seguente comando.

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

Lo stesso comando si può utilizzare per visualizzare i registri dell'audit nella cartella di retention modificando il filtro in D:\rdsdbdata\SQLAudit\transmitted\*.sqlaudit.

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

Utilizzo dell'audit in SQL Server con le istanze Multi-AZ

Per le istanze Multi-AZ, il processo per inviare i file di log dell'audit a Amazon S3 è simile a quello per le istanze Single-AZ. Tuttavia, vi sono alcune differenze importanti:

Per acquisire gli audit del server o una specifica dell'audit del server da entrambi i nodi:

Configurazione di un bucket S3

I file di log di audit vengono caricati automaticamente dall'istanza database al bucket S3. Per il bucket S3 utilizzato come destinazione dei file dell'audit valgono le seguenti restrizioni:

La chiave di destinazione utilizzata per archiviare i dati segue questo schema di denominazion: DOC-EXAMPLE-BUCKET/key-prefix/instance-name/audit-name/node_file-name.ext

Lo schema è costituito dai seguenti elementi:

Creazione manuale di un ruolo IAM per l'audit in SQL Server

In genere, quando crei una nuova opzione, AWS Management Console crea automaticamente il ruolo IAM e la policy di fiducia IAM. Si può tuttavia creare manualmente un nuovo ruolo IAM da utilizzare con gli audit in SQL Server, in modo che l'utente possa personalizzarlo con tutti gli ulteriori requisiti che potrebbero servire. Per far ciò, l'utente crea un ruolo IAM e delega le autorizzazioni in modo che il servizio Amazon RDS possa utilizzare il bucket Amazon S3. Quando si crea un ruolo IAM, vengono collegate le policy di attendibilità e autorizzazione. La policy di attendibilità consente a Amazon RDS di assumere questo ruolo. La policy di autorizzazione definisce le operazioni che questo ruolo può eseguire. Per ulteriori informazioni, vedere Creazione di un ruolo per delegare le autorizzazioni a un AWS servizio nella Guida per l'utente di AWS Identity and Access Management.

Si possono utilizzare gli esempi riportati in questa sezione per creare le relazioni di attendibilità e le policy di autorizzazione necessarie.

Il seguente esempio mostra una relazione di attendibilità per la verifica in SQL Server. Utilizza l'entità servizio rds.amazonaws.com per autorizzare RDS a scrivere nel bucket S3. Un'entità servizio è un identificatore che viene utilizzato per concedere autorizzazioni a un servizio. Ogni volta che si autorizza l'accesso a rds.amazonaws.com, si consente a RDS di eseguire un'operazione per conto dell'utente. Per ulteriori informazioni sulle entità principali del servizio, consulta Elementi della policy JSON AWS : Entità principale.

{
	    "Version": "2012-10-17",
	    "Statement": [
	        {
	            "Effect": "Allow",
	            "Principal": {
	                "Service": "rds.amazonaws.com"
	            },
	            "Action": "sts:AssumeRole"
	        }
	    ]
	}

Si consiglia di utilizzare le chiavi di contesto delle condizioni globali aws:SourceArn e aws:SourceAccount nelle relazioni di trust basate sulle risorse per limitare le autorizzazioni del servizio relative a una risorsa specifica. Questo è il modo più efficace per proteggersi dal problema di deputy confused.

Puoi usare le chiavi di contesto delle condizioni globali e avere il valore aws:SourceArn che contiene l'ID dell'account. In questo caso, il valore aws:SourceAccount e l'account nel valore aws:SourceArn deve utilizzare lo stesso ID account quando viene utilizzato nella stessa istruzione.

Nella relazione di trust, assicurati di utilizzare la chiave di contesto della condizione globale aws:SourceArn con l'Amazon Resource Name (ARN) completo delle risorse che accedono al ruolo. Perla verifica in SQL Server assicurati di includere sia il gruppo di opzioni database che le istanze database, come illustrato nell'esempio seguente.

{
    "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"
                    ]
                }
            }
        }
    ]
}

Nel seguente esempio di policy di autorizzazione per la verifica in SQL Server, specifichiamo un ARN per il bucket Amazon S3. Si possono utilizzare gli ARN per identificare account, utenti o ruoli specifici a cui si desidera concedere l'accesso. Per ulteriori informazioni sull'utilizzo degli ARN, consulta la pagina 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/*"
	        }
	    ]
	}