Manuelles Erstellen einer IAM-Rolle für SQL Server Audit - Amazon Relational Database Service

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Manuelles Erstellen einer IAM-Rolle für SQL Server Audit

Wenn Sie eine neue Option erstellen, werden in der Regel die IAM-Rolle und die IAM-Vertrauensrichtlinie für Sie AWS Management Console erstellt. Sie können jedoch manuell eine neue IAM-Rolle für die Verwendung mit SQL Server Audits erstellen, sodass Sie diese an mögliche weitere Anforderungen anpassen können. Dazu erstellen Sie eine IAM-Rolle und delegieren Berechtigungen, sodass der Amazon RDS-Service Ihren Amazon S3-Bucket verwenden kann. Beim Anlegen dieser IAM-Rolle geben Sie Vertrauens- und Berechtigungsrichtlinien an. Die Vertrauensrichtlinie erlaubt es Amazon RDS, diese Rolle zu übernehmen. Die Berechtigungsrichtlinie definiert die Aktionen, die über diese Rolle ausgeführt werden können. Weitere Informationen finden Sie unter Erstellen einer Rolle zum Delegieren von Berechtigungen für einen AWS Dienst im AWS Identity and Access Management-Benutzerhandbuch.

Sie können anhand der Beispiele in diesem Abschnitt die benötigten Vertrauensbeziehungen und Berechtigungsrichtlinien erstellen.

Das folgende Beispiel zeigt eine Vertrauensbeziehung für SQL Server Audit. Das Service-Prinzipal rds.amazonaws.com kommt zum Einsatz, um RDS das Schreiben in den S3-Bucket zu erlauben. EinService-Prinzipal ist eine Kennung, die verwendet wird, um einem Service Berechtigungen zu erteilen. Wann immer Sie auf diese Art Zugriff auf rds.amazonaws.com gewähren, erlauben Sie RDS, eine Aktion in Ihrem Namen auszuführen. Weitere Informationen zu Service-Prinzipalen finden Sie unter AWS JSON-Richtlinienelemente: Prinzipal.

Beispiel Vertrauensbeziehung für SQL Server Audit
JSON
{
	    "Version": "2012-10-17",
	    "Statement": [
	        {
	            "Effect": "Allow",
	            "Principal": {
	                "Service": "rds.amazonaws.com"
	            },
	            "Action": "sts:AssumeRole"
	        }
	    ]
	}

Wir empfehlen die Verwendung der globalen Bedingungskontextschlüssel aws:SourceArn und aws:SourceAccount in ressourcenbasierten Vertrauensbeziehungen, um die Berechtigungen des Services auf eine bestimmte Ressource zu beschränken. Dies ist der effektivste Weg, um sich vor dem verwirrtes Stellvertreterproblem zu schützen.

Sie können beide globalen Bedingungskontextschlüssel verwenden und der Wert aws:SourceArn enthält die Konto-ID. Stellen Sie in diesen Fällen sicher, dass der Wert aws:SourceAccount und das Konto im Wert aws:SourceArn dieselbe Konto-ID verwenden, wenn sie in derselben Anweisung verwendet werden.

  • Verwenden von aws:SourceArn wenn Sie einen serviceübergreifenden Zugriff für eine einzelne Ressource wünschen.

  • Verwenden von aws:SourceAccount wenn Sie zulassen möchten, dass eine Ressource in diesem Konto mit der betriebsübergreifenden Verwendung verknüpft wird.

Stellen Sie in der Vertrauensbeziehung sicher, dass Sie den globalen Bedingungskontextschlüssel aws:SourceArn mit dem vollständigen Amazon-Ressourcennamen (ARN) der Ressourcen verwenden, die auf die Rolle zugreifen. Stellen Sie bei SQL Server Audit sicher, dass Sie sowohl die DB-Optionsgruppe als auch die DB-Instances einschließen, wie im folgenden Beispiel gezeigt.

Beispiel Vertrauensbeziehung mit dem globalen Bedingungskontextschlüssel für 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"
                    ]
                }
            }
        }
    ]
}

Im folgenden Beispiel einer Berechtigungsrichtlinie für SQL Server Audit, wird ein ARN für den Amazon S3 Bucket angegeben. Sie können ARNs damit ein bestimmtes Konto, einen bestimmten Benutzer oder eine bestimmte Rolle identifizieren, für die Sie Zugriff gewähren möchten. Weitere Informationen zur Verwendung ARNs finden Sie unter Amazon-Ressourcennamen (ARNs).

Beispiel Berechtigungsrichtlinie für 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/*"
	        }
	    ]
	}
Anmerkung

Die s3:ListAllMyBuckets Aktion ist erforderlich, um zu überprüfen, ob dasselbe AWS Konto sowohl den S3-Bucket als auch die SQL Server-DB-Instance besitzt. Die Aktion listet die Namen der Buckets in dem Konto auf.

S3-Bucket-Namespaces sind global. Wenn Sie Ihren Bucket versehentlich löschen, kann ein anderer Benutzer einen Bucket mit demselben Namen in einem anderen Konto erstellen. Dann werden die SQL Server-Prüfungsdaten in den neuen Bucket geschrieben.