Creazione manuale di un ruolo IAM per l'audit in SQL Server - Amazon Relational Database Service

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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.

Esempio relazione di attendibilità per la verifica in SQL Server
JSON
{
	    "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.

  • Utilizzare aws:SourceArn se si desidera un accesso cross-service per una singola risorsa.

  • Utilizzare aws:SourceAccount se si desidera consentire l'associazione di qualsiasi risorsa in tale account all'uso cross-service.

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.

Esempio relazione di affidabilità con la chiave di contesto delle condizioni globali per la verifica in SQL Server
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"
                    ]
                }
            }
        }
    ]
}

Nel seguente esempio di policy di autorizzazione per la verifica in SQL Server, specifichiamo un ARN per il bucket Amazon S3. Puoi utilizzarlo ARNs per identificare un account, un utente o un ruolo specifico a cui desideri concedere l'accesso. Per ulteriori informazioni sull'utilizzo ARNs, consulta Amazon resource names (ARNs).

Esempio policy di autorizzazione per la verifica in SQL Server
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/*"
	        }
	    ]
	}
Nota

L's3:ListAllMyBucketsazione è necessaria per verificare che lo stesso AWS account possieda sia il bucket S3 che l'istanza DB di SQL Server. L'operazione elenca i nomi dei bucket dell'account.

Gli spazi dei nomi dei bucket S3 sono globali. Se elimini accidentalmente il bucket, un altro utente può creare un bucket con lo stesso nome in un account diverso. Quindi i dati di audit di SQL Server vengono scritti nel nuovo bucket.