

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.

# Sicherheit in Amazon Aurora DSQL
<a name="security"></a>

Cloud-Sicherheit hat AWS höchste Priorität. Als AWS Kunde profitieren Sie von Rechenzentren und Netzwerkarchitekturen, die darauf ausgelegt sind, die Anforderungen der sicherheitssensibelsten Unternehmen zu erfüllen.

Sicherheit ist eine gemeinsame AWS Verantwortung von Ihnen und Ihnen. Das [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) beschreibt dies als Sicherheit *der* Cloud und Sicherheit *in* der Cloud:
+ **Sicherheit der Cloud** — AWS ist verantwortlich für den Schutz der Infrastruktur, auf der AWS Dienste in der ausgeführt AWS Cloud werden. AWS bietet Ihnen auch Dienste, die Sie sicher nutzen können. Externe Prüfer testen und verifizieren regelmäßig die Wirksamkeit unserer Sicherheitsmaßnahmen im Rahmen der [AWS](https://aws.amazon.com/compliance/programs/) . Weitere Informationen zu den Compliance-Programmen, die für Amazon Aurora DSQL gelten, finden Sie unter [AWS Services im Umfang nach Compliance-Programm AWS](https://aws.amazon.com/compliance/services-in-scope/) .
+ **Sicherheit in der Cloud** — Ihre Verantwortung richtet sich nach dem AWS Service, den Sie nutzen. Sie sind auch für andere Faktoren verantwortlich, etwa für die Vertraulichkeit Ihrer Daten, für die Anforderungen Ihres Unternehmens und für die geltenden Gesetze und Vorschriften. 

Diese Dokumentation hilft Ihnen zu verstehen, wie Sie das Modell der geteilten Verantwortung bei der Verwendung von Aurora DSQL einsetzen können. In den folgenden Themen wird veranschaulicht, wie Sie Aurora DSQL zur Erfüllung Ihrer Sicherheits- und Compliance-Ziele konfigurieren können. Sie lernen auch, wie Sie andere AWS Dienste nutzen können, die Ihnen helfen, Ihre Aurora DSQL-Ressourcen zu überwachen und zu sichern. 

**Topics**
+ [AWS verwaltete Richtlinien für Amazon Aurora DSQL](security-iam-awsmanpol.md)
+ [Datenschutz in Amazon Aurora DSQL](data-protection.md)
+ [Datenverschlüsselung für Amazon Aurora DSQL](data-encryption.md)
+ [Identitäts- und Zugriffsverwaltung für Aurora DSQL](security-iam.md)
+ [Ressourcenbasierte Richtlinien für Aurora DSQL](resource-based-policies.md)
+ [Verwenden von serviceverknüpften Rollen in Aurora DSQL](working-with-service-linked-roles.md)
+ [Verwenden von IAM-Bedingungsschlüsseln mit Amazon Aurora DSQL](using-iam-condition-keys.md)
+ [Vorfallreaktion in Amazon Aurora DSQL](incident-response.md)
+ [Compliance-Validierung für Amazon Aurora DSQL](compliance-validation.md)
+ [Ausfallsicherheit in Amazon Aurora DSQL](disaster-recovery-resiliency.md)
+ [Infrastruktursicherheit in Amazon Aurora DSQL](infrastructure-security.md)
+ [Konfigurations- und Schwachstellenanalyse in Amazon Aurora DSQL](configuration-vulnerability.md)
+ [Serviceübergreifende Confused-Deputy-Prävention](cross-service-confused-deputy-prevention.md)
+ [Bewährte Methoden für die Aurora DSQL-Sicherheit](best-practices-security.md)

# AWS verwaltete Richtlinien für Amazon Aurora DSQL
<a name="security-iam-awsmanpol"></a>



Eine AWS verwaltete Richtlinie ist eine eigenständige Richtlinie, die von erstellt und verwaltet AWS wird. AWS Verwaltete Richtlinien sind so konzipiert, dass sie Berechtigungen für viele gängige Anwendungsfälle bereitstellen, sodass Sie damit beginnen können, Benutzern, Gruppen und Rollen Berechtigungen zuzuweisen.

Beachten Sie, dass AWS verwaltete Richtlinien für Ihre speziellen Anwendungsfälle möglicherweise keine Berechtigungen mit den geringsten Rechten gewähren, da sie für alle AWS Kunden verfügbar sind. Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie [vom Kunden verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind.

Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen nicht ändern. Wenn die in einer AWS verwalteten Richtlinie definierten Berechtigungen AWS aktualisiert werden, wirkt sich das Update auf alle Prinzidentitäten (Benutzer, Gruppen und Rollen) aus, denen die Richtlinie zugeordnet ist. AWS aktualisiert eine AWS verwaltete Richtlinie höchstwahrscheinlich, wenn eine neue Richtlinie eingeführt AWS-Service wird oder neue API-Operationen für bestehende Dienste verfügbar werden.

Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) im *IAM-Benutzerhandbuch*.

 





## AWS verwaltete Richtlinie: AmazonAurora DSQLFull Zugriff
<a name="security-iam-awsmanpol-AmazonAuroraDSQLFullAccess"></a>



Sie können `AmazonAuroraDSQLFullAccess` an Ihre Benutzer, Gruppen und Rollen anfügen.

Diese Richtlinie gewährt administrative Berechtigungen, die vollständigen Administratorzugriff auf Aurora DSQL ermöglichen. Prinzipale mit diesen Berechtigungen können:
+ Erstellen, Löschen und Aktualisieren von Aurora DSQL-Clustern und Clustern mit mehreren Regionen
+ Cluster-Inline-Richtlinien verwalten (Richtlinien erstellen, anzeigen, aktualisieren und löschen)
+ Entfernen und Hinzufügen von Tags bei einem Cluster
+ Auflistung und Anzeige von Clustern und Informationen zu einzelnen Clustern
+ Anzeige von an Aurora DSQL-Cluster angehängten Tags
+ Datenbankverbindung als beliebiger Benutzer herstellen (einschließlich als Administrator)
+ Durchführen von Sicherungs- und Wiederherstellungsvorgängen für Aurora DSQL-Cluster, einschließlich Starten, Stoppen und Überwachen von Sicherungs- und Wiederherstellungsaufträgen
+ Verwenden Sie vom Kunden verwaltete AWS KMS Schlüssel für die Clusterverschlüsselung
+ Sehen Sie sich alle Metriken CloudWatch für ihr Konto an
+ Verwenden Sie AWS Fault Injection Service (AWS FIS), um Fehler in Aurora DSQL-Cluster für Fehlertoleranztests einzuschleusen
+ Erstellen serviceverknüpfter Rollen für den `dsql.amazonaws.com`-Service, der für die Erstellung von Clustern erforderlich ist



**Details zu Berechtigungen**

Diese Richtlinie umfasst die folgenden Berechtigungen.


+ `dsql`— gewährt Prinzipalen vollen Zugriff auf Aurora DSQL.
+ `cloudwatch`— erteilt die Erlaubnis, metrische Datenpunkte auf Amazon CloudWatch zu veröffentlichen.
+ `iam`— gewährt die Berechtigung zum Erstellen einer serviceverknüpften Rolle.
+ `backup and restore`— gewährt Berechtigungen zum Starten, Stoppen und Überwachen von Sicherungs- und Wiederherstellungsaufträgen für Aurora DSQL-Cluster. 
+ `kms`— gewährt die erforderlichen Berechtigungen zum Validieren des Zugriffs auf kundenseitig verwaltete Schlüssel, die für die Aurora DSQL-Clusterverschlüsselung beim Erstellen, Aktualisieren oder Herstellen einer Verbindung zu Clustern verwendet werden. 
+ `fis`— gewährt Nutzungsberechtigungen AWS Fault Injection Service (AWS FIS) zum Einschleusen von Fehlern in Aurora DSQL-Cluster für Fehlertoleranztests.

Sie finden die von `AmazonAuroraDSQLFullAccess` Richtlinie in der IAM-Konsole und im [Referenzleitfaden zur AWS -verwalteten Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLFullAccess.html).

## AWS verwaltete Richtlinie: AmazonAurora DSQLRead OnlyAccess
<a name="security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess"></a>



Sie können `AmazonAuroraDSQLReadOnlyAccess` an Ihre Benutzer, Gruppen und Rollen anfügen.

Erlaubt den Lesezugriff auf Aurora DSQL. Prinzipale mit diesen Berechtigungen können Cluster auflisten und Informationen zu einzelnen Clustern einsehen. Sie können die an Aurora DSQL-Cluster angehängten Tags und die Cluster-Inline-Richtlinien einsehen. Sie können alle Metriken aus CloudWatch Ihrem Konto abrufen und einsehen. 



**Details zu Berechtigungen**

Diese Richtlinie umfasst die folgenden Berechtigungen.




+ `dsql`— gewährt Lesezugriff für alle Ressourcen in Aurora DSQL.
+ `cloudwatch`— erteilt die Erlaubnis, stapelweise Mengen von CloudWatch metrischen Daten abzurufen und metrische Berechnungen mit abgerufenen Daten durchzuführen 

Sie finden die `AmazonAuroraDSQLReadOnlyAccess`-Richtlinie in der IAM-Konsole und im [Referenzleitfaden zur von AWS verwalteten Richtlinie.](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLReadOnlyAccess.html)

## AWS verwaltete Richtlinie: AmazonAurora DSQLConsole FullAccess
<a name="security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess"></a>



Sie können `AmazonAuroraDSQLConsoleFullAccess` an Ihre Benutzer, Gruppen und Rollen anfügen.

Ermöglicht vollen Administratorzugriff auf Amazon Aurora DSQL über die AWS-Managementkonsole. Prinzipale mit diesen Berechtigungen können:
+ Aurora DSQL-Cluster, einschließlich Clustern mit mehreren Regionen erstellen, löschen und aktualisieren
+ Cluster-Inline-Richtlinien über die Konsole verwalten (Richtlinien erstellen, anzeigen, aktualisieren und löschen)
+ Auflistung und Anzeige von Clustern und Informationen zu einzelnen Clustern
+ Sehen Sie sich Tags für jede Ressource in Ihrem Konto an
+ Datenbankverbindung als beliebiger Benutzer herstellen (einschließlich als Administrator)
+ Durchführen von Sicherungs- und Wiederherstellungsvorgängen für Aurora DSQL-Cluster, einschließlich Starten, Stoppen und Überwachen von Sicherungs- und Wiederherstellungsaufträgen
+ Verwenden Sie vom Kunden verwaltete AWS KMS Schlüssel für die Clusterverschlüsselung
+ Starten Sie AWS CloudShell von AWS-Managementkonsole
+ Sehen Sie sich alle Metriken CloudWatch in Ihrem Konto an
+ Verwenden Sie AWS Fault Injection Service (AWS FIS), um Fehler in Aurora DSQL-Cluster für Fehlertoleranztests einzuschleusen
+ Erstellen serviceverknüpfter Rollen für den `dsql.amazonaws.com`-Service, der für die Erstellung von Clustern erforderlich ist

Sie finden die `AmazonAuroraDSQLConsoleFullAccess` Richtlinie auf der IAM-Konsole und [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLConsoleFullAccess.html)im AWS Managed Policy Reference Guide.



**Details zu Berechtigungen**

Diese Richtlinie umfasst die folgenden Berechtigungen.




+ `dsql`— gewährt volle Administratorrechte für alle Ressourcen in Aurora DSQL über AWS-Managementkonsole.
+ `cloudwatch`— erteilt die Berechtigung zum Abrufen von Batchmengen von CloudWatch Metrikdaten und zum Durchführen von metrischen Berechnungen mit abgerufenen Daten. 
+ `tag`— erteilt die Erlaubnis, Tag-Schlüssel und -Werte zurückzugeben, die derzeit in dem AWS-Region für das aufrufende Konto angegebenen Tag verwendet werden.
+ `backup and restore`— gewährt Berechtigungen zum Starten, Stoppen und Überwachen von Sicherungs- und Wiederherstellungsaufträgen für Aurora DSQL-Cluster. 
+ `kms`— gewährt die erforderlichen Berechtigungen zum Validieren des Zugriffs auf kundenseitig verwaltete Schlüssel, die für die Aurora DSQL-Clusterverschlüsselung beim Erstellen, Aktualisieren oder Herstellen einer Verbindung zu Clustern verwendet werden. 
+ `cloudshell`— gewährt Startberechtigungen für AWS CloudShell die Interaktion mit Aurora DSQL.
+ `ec2`— gewährt die Berechtigung, Amazon VPC-Endpunktinformationen einzusehen, die für Aurora DSQL-Verbindungen benötigt werden.
+ `fis`— gewährt Berechtigungen AWS FIS zur Eingabe von Fehlern in Aurora DSQL-Cluster für Fehlertoleranztests.
+ `access-analyzer:ValidatePolicy`erteilt die Erlaubnis für den Linter im Policy-Editor, der in Echtzeit Feedback zu Fehlern, Warnungen und Sicherheitsproblemen in der aktuellen Richtlinie liefert.
+ `fis`— gewährt Nutzungsberechtigungen AWS Fault Injection Service (AWS FIS) zum Einschleusen von Fehlern in Aurora DSQL-Cluster für Fehlertoleranztests.

Sie finden die `AmazonAuroraDSQLConsoleFullAccess`-Richtlinie in der IAM-Konsole und im [Referenzleitfaden zur von AWS verwalteten Richtlinie.](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLConsoleFullAccess.html)

## AWS verwaltete Richtlinie: Aurora DSQLService RolePolicy
<a name="security-iam-awsmanpol-AuroraDSQLServiceRolePolicy"></a>



Sie können Aurora nicht DSQLService RolePolicy an Ihre IAM-Entitäten anhängen. Diese Richtlinie ist an eine servicegebundene Rolle angehängt, mit der Aurora DSQL auf Kontoressourcen zugreifen kann.

Sie finden die `AuroraDSQLServiceRolePolicy` Richtlinie auf der IAM-Konsole und DSQLService RolePolicy in [Aurora](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDSQLServiceRolePolicy.html) im AWS Managed Policy Reference Guide.





## Aurora DSQL-Updates für AWS verwaltete Richtlinien
<a name="security-iam-awsmanpol-updates"></a>



Sehen Sie sich Details zu Aktualisierungen der AWS verwalteten Richtlinien für Aurora DSQL an, seit dieser Service begonnen hat, diese Änderungen zu verfolgen. Abonnieren Sie den RSS-Feed auf der Seite Aurora DSQL-Dokumentverlauf, um automatische Benachrichtigungen über Änderungen an dieser Seite zu erhalten.




| Änderungen | Beschreibung | Date | 
| --- | --- | --- | 
|  AmazonAuroraDSQLFullZugriff und Aktualisierung AmazonAurora DSQLConsole FullAccess  |  Unterstützung für die AWS Fault Injection Service (AWS FIS) -Integration mit Aurora DSQL hinzugefügt. Dadurch können Sie Ausfälle in Aurora DSQL-Cluster mit einer oder mehreren Regionen einschleusen, um die Fehlertoleranz Ihrer Anwendungen zu testen. Sie können in der AWS FIS Konsole Versuchsvorlagen erstellen, um Fehlerszenarien zu definieren und bestimmte Aurora DSQL-Cluster für Tests als Ziel zu verwenden. Weitere Informationen zu diesen Richtlinien finden Sie unter [AmazonAuroraDSQLFullZugriff](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) und [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess).  | 19. August 2025 | 
|  AmazonAuroraDSQLFullZugriff AmazonAurora DSQLReadOnlyAccess, und AmazonAurora DSQLConsole FullAccess Aktualisierung  |  Unterstützung für ressourcenbasierte Richtlinien (RBP) mit neuen Berechtigungen hinzugefügt:`PutClusterPolicy`, und`GetClusterPolicy`. `DeleteClusterPolicy` Diese Berechtigungen ermöglichen die Verwaltung von Inline-Richtlinien, die an Aurora DSQL-Cluster angehängt sind, um eine differenzierte Zugriffskontrolle zu gewährleisten. Weitere Informationen finden Sie unter [AmazonAuroraDSQLFullZugriff](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess), und [AmazonAuroraDSQLReadOnlyAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess). [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)  | 15. Oktober 2025 | 
|  AmazonAuroraDSQLFullZugriffsupdate  |  Es wurde die Möglichkeit hinzugefügt, Backup- und Wiederherstellungsoperationen für Aurora DSQL-Cluster durchzuführen – einschließlich Starten, Stoppen und Überwachen von Aufträgen. Weiterhin wurde die Möglichkeit hinzugefügt, kundenseitig verwaltete KMS-Schlüssel für die Clusterverschlüsselung zu verwenden. Weitere Informationen finden Sie unter [AmazonAuroraDSQLFullZugreifen](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) und [Verwenden von serviceverknüpften Rollen in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html).  | 21. Mai 2025 | 
|  AmazonAuroraDSQLConsoleFullAccess update  |  Ermöglicht jetzt die Durchführung von Sicherungs- und Wiederherstellungsvorgänge für Aurora DSQL-Cluster über die AWS Console Home. Dies beinhaltet das Starten, Stoppen und Überwachen von Aufträgen. Weiterhin wird jetzt auch die Verwendung von kundenseitig verwalteten KMS-Schlüsseln für die Clusterverschlüsselung und den AWS CloudShell-Start unterstützt. Weitere Informationen finden Sie unter [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)und [Verwenden von serviceverknüpften Rollen in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html).  | 21. Mai 2025 | 
| AmazonAuroraDSQLFullZugriffsupdate |  Die Richtlinie fügt vier neue Berechtigungen zum Erstellen und Verwalten von Datenbankclustern für mehrere AWS-Regionen:`PutMultiRegionProperties`, `PutWitnessRegion``AddPeerCluster`, und hinzu`RemovePeerCluster`. Zu diesen Berechtigungen gehören Steuerungen auf Ressourcenebene und Bedingungsschlüssel zur Steuerung, welche Cluster-Benutzer Sie ändern können. Die Richtlinie fügt auch die `GetVpcEndpointServiceName`-Berechtigung hinzu, die Ihnen hilft, eine Verbindung zu Ihren Aurora DSQL-Clustern über AWS PrivateLink herzustellen. Weitere Informationen finden Sie unter Weitere Informationen finden Sie unter [AmazonAuroraDSQLFullZugreifen](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) und [Verwenden von serviceverknüpften Rollen in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html).  | 13. Mai 2025 | 
| AmazonAuroraDSQLReadOnlyAccess update | Beinhaltet die Möglichkeit, den richtigen VPC-Endpunkt-Servicenamen zu ermitteln, wenn über AWS PrivateLink Aurora DSQL eine Verbindung zu Ihren Aurora DSQL-Clustern hergestellt wird. Dadurch werden eindeutige Endpunkte pro Zelle erstellt, sodass diese API sicherstellt, dass Sie den richtigen Endpunkt für Ihren Cluster identifizieren und Verbindungsfehler vermeiden können.Weitere Informationen finden Sie unter [AmazonAuroraDSQLReadOnlyAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess)und [Verwenden von serviceverknüpften Rollen in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13. Mai 2025 | 
| AmazonAuroraDSQLConsoleFullAccess update | Neue Berechtigungen wurden Aurora DSQL hinzugefügt, um Clustermanagement in mehreren Regionen und VPC-Endpunktverbindungen zu unterstützen. Zu den neuen Berechtigungen gehören: PutMultiRegionProperties, PutWitnessRegion, AddPeerCluster, RemovePeerCluster und GetVpcEndpointServiceName. Weitere Informationen finden Sie unter [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)und [Verwenden von serviceverknüpften Rollen in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13. Mai 2025 | 
| AuroraDsqlServiceLinkedRolePolicy update | Es wurde die Möglichkeit hinzugefügt, Metriken in den AWS/AuroraDSQL- und AWS/Usage CloudWatch-Namespaces der Richtlinie zu veröffentlichen. Auf diese Weise kann der zugehörige Dienst oder die zugehörige Rolle umfassendere Nutzungs- und Leistungsdaten an Ihre CloudWatch Umgebung senden. Weitere Informationen finden Sie unter [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDsqlServiceLinkedRolePolicy.html)und [Verwenden von serviceverknüpften Rollen in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 8. Mai 2025 | 
| Seite wurde erstellt. | Mit der Verfolgung AWS verwalteter Richtlinien im Zusammenhang mit Amazon Aurora DSQL wurde begonnen | 03. Dezember 2024 | 

# Datenschutz in Amazon Aurora DSQL
<a name="data-protection"></a>

Das [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) bezieht sich auf den Datenschutz. Wie in diesem Modell beschrieben, ist verantwortlich für den Schutz der globalen Infrastruktur, auf der AWS Cloud alle Systeme laufen. Sie sind dafür verantwortlich, die Kontrolle über Ihre in dieser Infrastruktur gehosteten Inhalte zu behalten. Sie sind auch für die Sicherheitskonfiguration und die Verwaltungsaufgaben für die von Ihnen verwendeten verantwortlich. Weitere Informationen zum Datenschutz finden Sie unter [Häufig gestellte Fragen zum Datenschutz](https://aws.amazon.com/compliance/data-privacy-faq/). Informationen zum Datenschutz in Europa finden Sie im Blog-Beitrag [-Modell der geteilten Verantwortung und in der DSGVO](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) im *-Sicherheitsblog*.

Aus Datenschutzgründen empfehlen wir, dass Sie Anmeldeinformationen schützen und einzelne Benutzer mit AWS IAM Identity Center oder einrichten AWS Identity and Access Management. So erhält jeder Benutzer nur die Berechtigungen, die zum Durchführen seiner Aufgaben erforderlich sind. Außerdem empfehlen wir, die Daten mit folgenden Methoden schützen:
+ Verwenden Sie für jedes Konto die Multi-Faktor-Authentifizierung (MFA).
+ Wird verwendet SSL/TLS , um mit Ressourcen zu kommunizieren. Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Richten Sie die API und die Protokollierung von Benutzeraktivitäten mit ein AWS CloudTrail. Informationen zur Verwendung von Trails zur Erfassung von Aktivitäten finden Sie unter [Arbeiten mit Trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) im *Benutzerhandbuch*.
+ Verwenden Sie Verschlüsselungslösungen zusammen mit allen darin enthaltenen Standardsicherheitskontrollen AWS-Services.
+ Verwenden Sie erweiterte verwaltete Sicherheitsservices wie Amazon Macie, die dabei helfen, in Amazon S3 gespeicherte persönliche Daten zu erkennen und zu schützen.

Wir empfehlen dringend, niemals vertrauliche oder sensible Informationen wie die E-Mail-Adressen Ihrer Kunden in Tags oder Freitextfeldern wie **Name** einzugeben. Dazu gehört auch, wenn Sie mit der Konsole, der API oder oder arbeiten oder AWS CLI anderweitig verwenden AWS SDKs. Alle Daten, die Sie in Tags oder Freitextfelder eingeben, die für Namen verwendet werden, können für Abrechnungs- oder Diagnoseprotokolle verwendet werden. Wenn Sie eine URL für einen externen Server bereitstellen, empfehlen wir dringend, keine Anmeldeinformationen zur Validierung Ihrer Anforderung an den betreffenden Server in die URL einzuschließen.



## Datenverschlüsselung
<a name="data-encryption"></a>

Amazon Aurora DSQL bietet eine sehr robuste Speicherinfrastruktur, die für geschäftskritische und primäre Datenspeicher entwickelt wurde. Daten werden redundant auf mehreren Geräten in verschiedenen Anlagen einer Aurora DSQL-Region gespeichert.

### Verschlüsselung während der Übertragung
<a name="encryption-transit"></a>

Die Verschlüsselung bei der Übertragung ist für Sie standardmäßig vorkonfiguriert. Aurora DSQL verwendet TLS zur Verschlüsselung des gesamten Datenverkehrs zwischen Ihrem SQL-Client und Aurora DSQL.

Verschlüsselung und Signierung von Daten bei der Übertragung zwischen SDK AWS CLI- oder API-Clients und Aurora DSQL-Endpunkten:
+ Aurora DSQL stellt HTTPS-Endpunkte zur Verschlüsselung von Daten während der Übertragung bereit. 
+ Um die Integrität von API-Anforderungen an Aurora DSQL zu schützen, müssen API-Aufrufe vom Aufrufer signiert werden. Anrufe werden mit einem X.509-Zertifikat oder dem AWS geheimen Zugriffsschlüssel des Kunden gemäß dem Signature Version 4-Signaturprozess (Sigv4) signiert. Weitere Informationen finden Sie unter [Signaturprozess mit Signaturversion 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) im *Allgemeine AWS-Referenz*.
+  Verwenden Sie die AWS CLI oder eine der Optionen, um Anfragen AWS SDKs an zu stellen. AWS Diese Tools signieren automatisch die Anforderungen für Sie mit dem Zugriffsschlüssel, den Sie bei der Konfiguration der Tools angegeben haben. 

#### Compliance mit FIPS
<a name="fips-compliance"></a>

Aurora DSQL-Datenebenen-Endpunkte (Cluster-Endpunkte, die für Datenbankverbindungen verwendet werden) verwenden standardmäßig FIPS 140-2-validierte kryptografische Module. Für Clusterverbindungen sind keine separaten FIPS-Endpunkte erforderlich.

Für den Betrieb auf der Kontrollebene bietet Aurora DSQL spezielle FIPS-Endpunkte in unterstützten Regionen. Weitere Informationen zu FIPS-Endpunkten auf Kontrollebene finden Sie unter [Aurora DSQL-Endpunkte und](https://docs.aws.amazon.com/general/latest/gr/dsql.html) Kontingente in der. *Allgemeine AWS-Referenz*

Siehe [Verschlüsselung im Ruhezustand in Aurora DSQL](data-encryption.md#encryption-at-rest) zum Thema Verschlüsselung im Ruhezustand.

### Datenschutz für den Datenverkehr zwischen Netzwerken
<a name="inter-network-traffic-privacy"></a>

Verbindungen sind sowohl zwischen Aurora DSQL und lokalen Anwendungen als auch zwischen Aurora DSQL und anderen AWS Ressourcen innerhalb derselben geschützt. AWS-Region

Sie haben zwei Verbindungsoptionen zwischen Ihrem privaten Netzwerk und: AWS
+ Eine AWS Site-to-Site VPN-Verbindung. Weitere Informationen finden Sie unter [Was ist AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Eine Direct Connect Verbindung. Weitere Informationen finden Sie unter [Was ist Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)

Sie erhalten Zugriff auf Aurora DSQL über das Netzwerk, indem Sie AWS-veröffentlichte API-Operationen verwenden. Kunden müssen Folgendes unterstützen:
+ Transport Layer Security (TLS). Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Verschlüsselungs-Suiten mit Perfect Forward Secrecy (PFS) wie DHE (Ephemeral Diffie-Hellman) oder ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Die meisten modernen Systeme wie Java 7 und höher unterstützen diese Modi.

## Datenschutz in Witness-Regionen
<a name="witness-regions"></a>

Wenn Sie einen Cluster mit mehreren Regionen erstellen, ermöglicht eine Witness-Region die automatische Wiederherstellung nach einem Ausfall, indem sie an der synchronen Replikation verschlüsselter Transaktionen teilnimmt. Wenn ein Peer-Cluster nicht mehr verfügbar ist, steht die Witness-Region weiterhin für die Validierung und Verarbeitung von Datenbank-Schreibvorgängen zur Verfügung, sodass kein Verfügbarkeitsverlust entsteht. 

Witness-Regionen schützen und sichern Ihre Daten mithilfe der folgendern Designmerkmale:
+ Die Witness-Region empfängt und speichert ausschließlich verschlüsselte Transaktionsprotokolle. Sie wird niemals Ihre Verschlüsselungsschlüssel hosten, speichern oder weitergeben.
+ Die Witness-Region dient lediglich zur Protokollierung von Schreibtransaktionen und Quorumfunktionen. Sie wurde speziell so entwickelt, dass sie Ihre Daten nicht lesen kann.
+ Die Witness-Region arbeitet ohne Clusterverbindungsendpunkte oder Abfrageprozessoren. Dadurch wird jeglicher Zugriff auf die Benutzerdatenbank verhindert.

Weitere Informationen zu Witness-Regionen finden Sie unter [Konfigurieren von Clustern mit mehreren Regionen](configuring-multi-region-clusters.md).

# Konfiguration von SSL/TLS Zertifikaten für Aurora DSQL-Verbindungen
<a name="configure-root-certificates"></a><a name="ssl-certificate-overview"></a>

Aurora DSQL verlangt von allen Verbindungen eine Transport Layer Security (TLS)-Verschlüsselung. Ihr Client-System muss der Amazon Root Certificate Authority (Amazon Root CA 1) vertrauen, um sichere Verbindungen herzustellen. Dieses Zertifikat ist bei vielen Betriebssystemen vorinstalliert. Dieser Abschnitt enthält Anleitungen zur Überprüfung des vorinstallierten Amazon Root CA 1-Zertifikats bei verschiedenen Betriebssystemen und führt Sie durch den Prozess der manuellen Installation des Zertifikats, falls es noch nicht vorhanden ist. 

Wir empfehlen die Verwendung von PostgreSQL Version 17.

**Wichtig**  
Für Produktionsumgebungen empfehlen wir die Verwendung des `verify-full`-SSL-Modus, um ein Höchstmaß an Verbindungssicherheit zu gewährleisten. In diesem Modus wird überprüft, ob das Serverzertifikat von einer vertrauenswürdigen Zertifizierungsstelle signiert ist und ob der Server-Hostname mit dem Zertifikat übereinstimmt.

## Überprüfen vorinstallierter Zertifikate
<a name="verify-installed-certificates"></a>

Bei den meisten Betriebssystemen ist **Amazon Root CA 1** bereits vorinstalliert. Um dies zu überprüfen, führen Sie die folgenden Schritte aus.

### Linux () RedHat/CentOS/Fedora
<a name="verify-linux"></a>

Führen Sie den folgenden Befehl in Ihrem Terminal aus:

```
trust list | grep "Amazon Root CA 1"
```

Wenn das Zertifikat installiert ist, wird die folgende Ausgabe angezeigt:

```
label: Amazon Root CA 1
```

### macOS
<a name="verify-macos"></a>

1. Öffnen Sie die Spotlight-Suche (**Befehlstaste** \$1 **Leerzeichen**)

1. Suchen Sie nach **Keychain Access**

1. Wählen Sie unter **Systemschlüsselketten** die Option **Systemstammverzeichnis** aus

1. Suchen Sie in der Zertifikatsliste nach **Amazon Root CA 1**

### Windows
<a name="verify-windows"></a>

**Anmerkung**  
Aufgrund eines bekannten Problems mit dem PSQL-Windows-Client kann bei der Verwendung von Systemstammzertifikaten (`sslrootcert=system`) der folgende Fehler zurückgegeben werden: `SSL error: unregistered scheme`. Alternativ können Sie den Schritten unter [Eine Verbindung von Windows aus herstellen](#connect-windows) folgen, um mithilfe von SSL eine Verbindung zu Ihrem Cluster herzustellen. 

Wenn **Amazon Root CA 1** nicht in Ihrem Betriebssystem installiert ist, gehen Sie wie im Folgenden beschrieben vor. 

## Installieren von Zertifikaten
<a name="install-certificates"></a>

 Wenn das `Amazon Root CA 1`-Zertifikat nicht auf Ihrem Betriebssystem vorinstalliert ist, müssen Sie es manuell installieren, um sichere Verbindungen zu Ihrem Aurora DSQL-Cluster herzustellen. 

### Installieren eines Linux-Zertifikats
<a name="install-linux"></a>

Gehen Sie wie folgt vor, um das Amazon Root CA-Zertifikat auf Linux-Systemen zu installieren.

1. Laden Sie das Stammzertifikat herunter:

   ```
   wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
   ```

1. Kopieren Sie das Zertifikat in den Vertrauensspeicher ein.

   ```
   sudo cp ./AmazonRootCA1.pem /etc/pki/ca-trust/source/anchors/
   ```

1. Aktualisieren Sie den CA Trust Store:

   ```
   sudo update-ca-trust
   ```

1. Überprüfen der Installation:

   ```
   trust list | grep "Amazon Root CA 1"
   ```

### Installieren des macOS-Zertifikats
<a name="install-macos"></a>

Diese Schritte zur Installation des Zertifikats sind optional. Die Schritte unter [Installieren eines Linux-Zertifikats](#install-linux) funktionieren auch für macOS.

1. Das Stammzertifikat herunterladen:

   ```
   wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
   ```

1. Fügen Sie das Zertifikat zur Systemschlüsselkette hinzu:

   ```
   sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain AmazonRootCA1.pem
   ```

1. Überprüfen der Installation:

   ```
   security find-certificate -a -c "Amazon Root CA 1" -p /Library/Keychains/System.keychain
   ```

## Verbindung mit SSL/TLS Verifizierung herstellen
<a name="connect-using-certificates"></a>

 Bevor Sie SSL/TLS Zertifikate für sichere Verbindungen zu Ihrem Aurora DSQL-Cluster konfigurieren, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen. 
+ PostgreSQL Version 17 ist installiert
+ AWS CLI mit den entsprechenden Anmeldeinformationen konfiguriert
+ Informationen zum Aurora DSQL-Cluster-Endpunkt

### Eine Verbindung von Linux aus herstellen
<a name="connect-linux"></a>

1. Generieren und Festlegen des Authentifizierungstokens:

   ```
   export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
   ```

1. Mithilfe von Systemzertifikaten eine Verbindung herstellen (falls vorinstalliert):

   ```
   PGSSLROOTCERT=system \
   PGSSLMODE=verify-full \
   psql --dbname postgres \
   --username admin \
   --host your-cluster-endpoint
   ```

1. Alternativ mithilfe eines heruntergeladenen Zertifikats eine Verbindung herstellen:

   ```
   PGSSLROOTCERT=/full/path/to/root.pem \
   PGSSLMODE=verify-full \
   psql --dbname postgres \
   --username admin \
   --host your-cluster-endpoint
   ```

**Anmerkung**  
 Weitere Informationen zu den PGSSLMODE-Einstellungen finden Sie unter [sslmode](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) in der Dokumentation zu den [Datenbankverbindung-Steuerungsfunktionen](https://www.postgresql.org/docs/current/libpq-connect.html) von PostgreSQL 17. 

### Eine Verbindung von macOS aus herstellen
<a name="connect-macos"></a>

1. Generieren und Festlegen des Authentifizierungstokens:

   ```
   export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
   ```

1. Mithilfe von Systemzertifikaten eine Verbindung herstellen (falls vorinstalliert):

   ```
   PGSSLROOTCERT=system \
   PGSSLMODE=verify-full \
   psql --dbname postgres \
   --username admin \
   --host your-cluster-endpoint
   ```

1. Alternativ laden Sie das Stammzertifikat herunter und speichern es unter `root.pem` (falls das Zertifikat nicht vorinstalliert ist)

   ```
   PGSSLROOTCERT=/full/path/to/root.pem \
   PGSSLMODE=verify-full \
   psql —dbname postgres \
   --username admin \
   --host your_cluster_endpoint
   ```

1. Eine Verbindung mithilfe von psql herstellen:

   ```
   PGSSLROOTCERT=/full/path/to/root.pem \
   PGSSLMODE=verify-full \
   psql —dbname postgres \
   --username admin \
   --host your_cluster_endpoint
   ```

### Eine Verbindung von Windows aus herstellen
<a name="connect-windows"></a>

#### Verwenden der Eingabeaufforderung
<a name="windows-command-prompt"></a>

1. Erstellen des Authentifizierungstokens:

   ```
   aws dsql generate-db-connect-admin-auth-token ^
   --region=your-cluster-region ^
   --expires-in=3600 ^
   --hostname=your-cluster-endpoint
   ```

1. Legen Sie die Passwortumgebungsvariable fest:

   ```
   set "PGPASSWORD=token-from-above"
   ```

1. Legen Sie die SSL-Konfiguration fest:

   ```
   set PGSSLROOTCERT=C:\full\path\to\root.pem
   set PGSSLMODE=verify-full
   ```

1. Verbindung mit der Datenbank herstellen:

   ```
   "C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres ^
   --username admin ^
   --host your-cluster-endpoint
   ```

#### Verwenden PowerShell
<a name="windows-powershell"></a>

1. Generieren und Festlegen des Authentifizierungstokens:

   ```
   $env:PGPASSWORD = (aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --expires-in=3600 --hostname=your-cluster-endpoint)
   ```

1. Die SSL-Konfiguration festlegen:

   ```
   $env:PGSSLROOTCERT='C:\full\path\to\root.pem'
   $env:PGSSLMODE='verify-full'
   ```

1. Verbindung mit der Datenbank herstellen:

   ```
    "C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres `
   --username admin `
   --host your-cluster-endpoint
   ```

## Weitere Ressourcen
<a name="additional-resources"></a>
+  [PostgreSQL-SSL-Dokumentation](https://www.postgresql.org/docs/current/libpq-ssl.html) 
+  [Amazon Trust Services](https://www.amazontrust.com/repository/) 

# Datenverschlüsselung für Amazon Aurora DSQL
<a name="data-encryption"></a>

Amazon Aurora DSQL verschlüsselt alle Benutzerdaten im Ruhezustand. Diese Verschlüsselung verwendet AWS Key Management Service (AWS KMS) für erhöhte Sicherheit. Diese Funktionalität trägt zur Verringerung des Betriebsaufwands und der Komplexität bei, die mit dem Schutz sensibler Daten einhergeht. Verschlüsselung im Ruhezustand:
+ Reduzierung des betrieblichen Aufwands, der durch den Schutz sensibler Daten entsteht
+ Aufbau sicherheitsrelevanter Anwendungen, die strenge Verschlüsselungsvorschriften und gesetzliche Auflagen erfüllen
+ Hinzufügung einer zusätzlichen Datenschutzebene, wodurch Ihre Daten immer in einem verschlüsselten Cluster gesichert sind
+ Einhaltung aller Unternehmensrichtlinien, Branchen- oder behördliche Vorschriften sowie Compliance-Anforderungen

Mit Aurora DSQL können Sie sicherheitsrelevante Anwendungen erstellen, die eine strenge Einhaltung der Verschlüsselungsvorschriften und der gesetzlichen Bestimmungen garantieren. In den folgenden Abschnitten wird erklärt, wie Sie die Verschlüsselung für neue und bestehende Aurora DSQL-Datenbanken konfigurieren und Ihre Verschlüsselungsschlüssel verwalten.

**Topics**
+ [KMS-Schlüsseltypen für Aurora DSQL](#kms-key-types)
+ [Verschlüsselung im Ruhezustand in Aurora DSQL](#encryption-at-rest)
+ [Verwendung AWS KMS und Datenschlüssel mit Aurora DSQL](#using-kms-and-data-keys)
+ [Autorisieren der Verwendung Ihres AWS KMS key für Aurora DSQL](#authorizing-kms-key-use)
+ [Aurora DSQL Verschlüsselungskontext](#dsql-encryption-context)
+ [Überwachung der Aurora DSQL-Interaktion mit AWS KMS](#monitoring-dsql-kms-interaction)
+ [Erstellen eines verschlüsselten Aurora DSQL-Clusters](#creating-encrypted-cluster)
+ [Entfernen oder Aktualisieren eines Schlüssels für Ihren Aurora DSQL-Cluster](#updating-encryption-key)
+ [Überlegungen zur Verschlüsselung mit Aurora DSQL](#considerations-with-encryption)

## KMS-Schlüsseltypen für Aurora DSQL
<a name="kms-key-types"></a>

Aurora DSQL lässt sich integrieren AWS KMS , um die Verschlüsselungsschlüssel für Ihre Cluster zu verwalten. Weitere Informationen zu Schlüsseltypen und -zustände finden Sie unter [AWS Key Management Service Konzepte](https://docs.aws.amazon.com/kms/latest/developerguide/concepts-intro.html) im *AWS Key Management Service Entwicklerhandbuch*. Wenn Sie einen neuen Cluster erstellen, können Sie für Ihre Clusterverschlüsselung aus den folgenden KMS-Schlüsseltypen wählen:

**AWS-eigener Schlüssel**  
Standardverschlüsselungstyp. Aurora DSQL besitzt den Schlüssel ohne zusätzliche Kosten für Sie. Amazon Aurora DSQL entschlüsselt Cluster-Daten transparent, wenn Sie auf einen verschlüsselten Cluster zugreifen. Es ist kein Code- oder Anwendungswechsel nötig, um verschlüsselte Cluster zu verwenden oder zu verwalten. Alle Aurora DSQL-Abfragen funktionieren mit Ihren verschlüsselten Daten.

**Kundenseitig verwalteter Schlüssel**  
Sie erstellen, besitzen und verwalten den Schlüssel in Ihrem AWS-Konto. Sie haben die volle Kontrolle über den KMS-Schlüssel. AWS KMS Es fallen Gebühren an.

Die Verschlüsselung im Ruhezustand mit der AWS-eigener Schlüssel ist ohne zusätzliche Kosten verfügbar. Für vom Kunden verwaltete Schlüssel fallen jedoch AWS KMS Gebühren an. Weitere Informationen finden Sie in der [AWS KMS](https://aws.amazon.com/kms/pricing/)-Preisliste.

Sie können jederzeit zwischen diesen Schlüsseltypen wechseln. Weitere Informationen zu Schlüsseltypen finden Sie unter [Kundenseitig verwaltete Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) und [AWS-eigene Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) im *AWS Key Management Service -Entwicklerhandbuch*.

**Anmerkung**  
Aurora DSQL Encryption at Rest ist in allen AWS Regionen verfügbar, in denen Aurora DSQL verfügbar ist.

## Verschlüsselung im Ruhezustand in Aurora DSQL
<a name="encryption-at-rest"></a>

Amazon Aurora DSQL verwendet den 256-Bit Advanced Encryption Standard (AES-256) zur Verschlüsselung Ihrer Daten im Ruhezustand. Diese Verschlüsselung schützt Ihre Daten vor unbefugtem Zugriff auf den zugrunde liegenden Speicher. AWS KMS verwaltet die Verschlüsselungsschlüssel für Ihre Cluster. Sie können die standardmäßigen [AWS-eigene Schlüssel](#aws-owned-keys) verwenden, oder aber Ihre eigenen AWS KMS -[Kundenseitig verwaltete Schlüssel](#customer-managed-keys) auswählen. Weitere Informationen zur Festlegung und Verwaltung von Schlüsseln für Ihre Aurora DSQL-Cluster finden Sie unter [Erstellen eines verschlüsselten Aurora DSQL-Clusters](#creating-encrypted-cluster) und [Entfernen oder Aktualisieren eines Schlüssels für Ihren Aurora DSQL-Cluster](#updating-encryption-key).

**Topics**
+ [AWS-eigene Schlüssel](#aws-owned-keys)
+ [Kundenseitig verwaltete Schlüssel](#customer-managed-keys)

### AWS-eigene Schlüssel
<a name="aws-owned-keys"></a>

Aurora DSQL verschlüsselt standardmäßig alle Cluster mit. AWS-eigene Schlüssel Diese Schlüssel können kostenlos verwendet werden und werden jährlich gewechselt, um Ihre Kontoressourcen zu schützen. Sie müssen diese Schlüssel nicht einsehen, verwalten, verwenden oder prüfen, sodass keine Maßnahmen für den Datenschutz erforderlich werden. Weitere Informationen zu AWS-eigene Schlüssel finden Sie [AWS-eigene Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)im *AWS Key Management Service Entwicklerhandbuch*.

### Kundenseitig verwaltete Schlüssel
<a name="customer-managed-keys"></a>

Kundenseitig verwaltete Schlüssel erstellen, besitzen und verwalten Sie über Ihr AWS-Konto. Sie haben die vollständige Kontrolle über diese KMS-Schlüssel, einschließlich ihrer Richtlinien, Verschlüsselungsmaterialien, Tags und Aliasse. Weitere Informationen finden Sie unter [Kundenseitig verwaltete Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) im *AWS Key Management Service -Entwicklerhandbuch*.

Wenn Sie einen kundenseitig verwalteten Schlüssel für die Verschlüsselung auf Clusterebene angeben, verschlüsselt Aurora DSQL den Cluster und alle seine regionalen Daten mit diesem Schlüssel. Um Datenverlust zu verhindern und den Cluster-Zugriff aufrechtzuerhalten, benötigt Aurora DSQL Zugriff auf Ihren Verschlüsselungsschlüssel. Wenn Sie Ihren kundenseitig verwalteten Schlüssel deaktivieren, Ihren Schlüssel für die Löschung planen oder eine Richtlinie festgelegt haben, die Ihren Servicezugriff einschränkt, ändert sich der Verschlüsselungsstatus für Ihren Cluster auf `KMS_KEY_INACCESSIBLE`. Wenn Aurora DSQL nicht auf den Schlüssel zugreifen kann, können Benutzer keine Verbindung zum Cluster herstellen. Der Verschlüsselungsstatus für den Cluster ändert sich auf `KMS_KEY_INACCESSIBLE` und der Service verliert den Zugriff auf die Clusterdaten.

Bei Clustern mit mehreren Regionen können Kunden den AWS KMS Verschlüsselungsschlüssel jeder Region separat konfigurieren, und jeder regionale Cluster verwendet seinen eigenen Verschlüsselungsschlüssel auf Clusterebene. Wenn Aurora DSQL nicht auf den Verschlüsselungsschlüssel für einen Peer in einem Cluster mit mehreren Regionen zugreifen kann, wird der Status für diesen Peer auf `KMS_KEY_INACCESSIBLE` gesetzt, wodurch er nicht mehr für Lese- und Schreibvorgänge verfügbar ist. Andere Peers setzen den normalen Betrieb fort.

**Anmerkung**  
Wenn Aurora DSQL nicht auf Ihren kundenseitig verwalteten Schlüssel zugreifen kann, ändert sich Ihr Cluster-Verschlüsselungsstatus auf `KMS_KEY_INACCESSIBLE`. Nachdem Sie den Schlüsselzugriff wiederhergestellt haben, erkennt der Dienst die Wiederherstellung automatisch innerhalb von 15 Minuten. Weitere Informationen finden Sie unter Clusterleerlauf.  
Wenn bei Clustern mit mehreren Regionen der Schlüsselzugriff über einen längeren Zeitraum verloren geht, hängt die Cluster-Wiederherstellungszeit davon ab, wie viele Daten geschrieben wurden, während auf den Schlüssel nicht zugegriffen werden konnte.

## Verwendung AWS KMS und Datenschlüssel mit Aurora DSQL
<a name="using-kms-and-data-keys"></a>

Die Aurora-DSQL-Verschlüsselung im Ruhezustand verwendet eine AWS KMS key und eine Hierarchie von Datenschlüsseln, um Ihre Clusterdaten zu schützen.

Wir empfehlen, Ihre Verschlüsselungsstrategie im Voraus zu planen, bevor Sie Ihren Cluster in Aurora DSQL implementieren. Wenn Sie sensible oder vertrauliche Daten in Aurora DSQL speichern, sollten Sie erwägen, eine clientseitige Verschlüsselung in Ihren Plan aufzunehmen. Auf diese Weise können Sie Daten so nah wie möglich an ihrem Ursprung verschlüsseln und den Schutz der Daten während ihres gesamten Lebenszyklus gewährleisten.

**Topics**
+ [Verwenden von AWS KMS key s mit Aurora DSQL](#aws-kms-key)
+ [Clusterschlüssel mit Aurora DSQL verwenden](#cluster-keys)
+ [Clusterschlüssel-Caching](#cluster-key-caching)

### Verwenden von AWS KMS key s mit Aurora DSQL
<a name="aws-kms-key"></a>

Die Verschlüsselung im Ruhezustand schützt Ihren Aurora DSQL-Cluster unter einem AWS KMS key. Standardmäßig verwendet Aurora DSQL einen Mehrmandanten-Verschlüsselungsschlüssel AWS-eigener Schlüssel, der in einem Aurora DSQL-Dienstkonto erstellt und verwaltet wird. Sie können Ihre Aurora DSQL-Cluster jedoch unter einem kundenseitig verwalteten Schlüssel in Ihrem AWS-Konto verschlüsseln. Für jeden Cluster können Sie einen anderen KMS-Schlüssel auswählen, auch wenn dieser an einer multiregionalen Konfiguration beteiligt ist.

Den KMS-Schlüssel für ein Cluster wählen Sie beim Erstellen oder Aktualisieren des Clusters aus. Sie können den KMS-Schlüssel für ein Cluster jederzeit entweder in der Aurora DSQL-Konsole oder mithilfe der `UpdateCluster`-Operation ändern. Der Vorgang des Schlüsselwechsels ist nahtlos und erfolgt ohne Ausfallzeiten oder Servicebeeinträchtigung.

**Wichtig**  
Aurora DSQL unterstützt ausschließlich symmetrische KMS-Schlüssel. Ein asymmetrischer KMS-Schlüssel kann nicht zum Verschlüsseln Ihrer Aurora DSQL-Cluster verwendet werden.

Ein kundenseitig verwalteter Schlüssel bietet die folgenden Vorteile:
+ Sie erstellen und verwalten den KMS-Schlüssel selbst, einschließlich der Einstellung der Schlüsselrichtlinien und IAM-Richtlinien, um den Zugriff auf den KMS-Schlüssel zu steuern. Sie können den KMS-Schlüssel aktivieren und deaktivieren, die automatische Schlüsseldrehung aktivieren und deaktivieren und den KMS-Schlüssel löschen, wenn er nicht mehr verwendet wird.
+ Sie können einen kundenseitig verwalteten Schlüssel mit importiertem Schlüsselmaterial oder einen kundenverwalteten Schlüssel in einem benutzerdefinierten Schlüsselspeicher verwenden, den Sie besitzen und verwalten.
+ Sie können die Verschlüsselung und Entschlüsselung Ihres Aurora DSQL-Clusters überprüfen, indem Sie die Aurora-DSQL-API-Aufrufe in den Protokollen untersuchen. AWS KMS AWS CloudTrail 

Sie AWS-eigener Schlüssel ist jedoch kostenlos und ihre Nutzung wird nicht auf die AWS KMS Ressourcen- oder Anforderungskontingente angerechnet. Für kundenseitig verwaltete Schlüssel fällt bei jedem API-Aufruf eine Gebühr an, und die AWS KMS -Kontingente gelten für diese Schlüssel.

### Clusterschlüssel mit Aurora DSQL verwenden
<a name="cluster-keys"></a>

**Aurora DSQL verwendet den AWS KMS key für den Cluster, um einen eindeutigen Datenschlüssel für den Cluster, den so genannten Clusterschlüssel, zu generieren und zu verschlüsseln.**

Der Clusterschlüssel wird als Schlüssel für den Verschlüsselungsschlüssel verwendet. Aurora DSQL verwendet diesen Clusterschlüssel zum Schutz von Datenverschlüsselungsschlüsseln, die wiederum zum Verschlüsseln der Clusterdaten verwendet werden. Aurora DSQL generiert für jede zugrunde liegende Struktur in einem Cluster einen eindeutigen Datenverschlüsselungsschlüssel, wobei mehrere Clusterelemente durch denselben Schlüssel geschützt sein können.

Um den Clusterschlüssel zu entschlüsseln, sendet Aurora DSQL eine Anfrage an, AWS KMS wenn Sie zum ersten Mal auf einen verschlüsselten Cluster zugreifen. Um die Verfügbarkeit des Clusters sicherzustellen, überprüft Aurora DSQL regelmäßig den Entschlüsselungszugriff auf den KMS-Schlüssel – auch wenn Sie gerade nicht aktiv auf den Cluster zugreifen.

Aurora DSQL speichert und verwendet den Clusterschlüssel und die Datenverschlüsselungsschlüssel außerhalb von AWS KMS. Alle Schlüssel werden mit Advanced Encryption Standard (AES)-Verschlüsselung und 256-Bit-Verschlüsselungsschlüsseln geschützt. Anschließend werden die verschlüsselten Schlüssel zusammen mit den verschlüsselten Daten gespeichert, damit sie on-demand für die Entschlüsselung der Clusterdaten verfügbar sind.

Wenn Sie den KMS-Schlüssel für Ihren Cluster ändern, verschlüsselt Aurora DSQL den vorhandenen Clusterschlüssel erneut mit dem neuen KMS-Schlüssel.

### Clusterschlüssel-Caching
<a name="cluster-key-caching"></a>

Um zu vermeiden, dass jede Aurora-DSQL-Operation aufgerufen AWS KMS wird, speichert Aurora DSQL die Klartext-Clusterschlüssel für jeden Aufrufer im Speicher zwischen. Wenn Aurora DSQL nach 15 Minuten Inaktivität eine Anfrage für den zwischengespeicherten Clusterschlüssel erhält, sendet es eine neue Anfrage an, um den Clusterschlüssel AWS KMS zu entschlüsseln. Dieser Aufruf erfasst alle Änderungen, die nach der letzten Anfrage zur Entschlüsselung des AWS KMS key Clusterschlüssels an den Zugriffsrichtlinien von In AWS KMS oder AWS Identity and Access Management (IAM) vorgenommen wurden.

## Autorisieren der Verwendung Ihres AWS KMS key für Aurora DSQL
<a name="authorizing-kms-key-use"></a>

Wenn Sie einen kundenseitig verwalteten Schlüssel in Ihrem Konto zum Schutz Ihres Aurora DSQL-Clusters verwenden, müssen die Richtlinien dieses Schlüssels Aurora DSQL die Berechtigung erteilen, ihn in Ihrem Namen zu verwenden.

Sie haben die vollständige Kontrolle über die Richtlinien eines kundenseitig verwalteten Schlüssels. Aurora DSQL benötigt keine zusätzliche Autorisierung, um die Standardeinstellung AWS-eigener Schlüssel zum Schutz der Aurora DSQL-Cluster in Ihrem zu verwenden. AWS-Konto

### Schlüsselrichtlinie für einen kundenseitig verwalteten Schlüssel
<a name="key-policy-customer-managed-key"></a>

Wenn Sie einen vom AWS KMS key Kunden verwalteten Schlüssel zum Schutz eines Aurora DSQL-Clusters auswählen, benötigt Aurora DSQL die Erlaubnis, den im Namen des Prinzipals zu verwenden, der die Auswahl trifft. Dieser Prinzipal, ein Benutzer oder eine Rolle, muss über die Berechtigungen verfügen AWS KMS key , die Aurora DSQL benötigt. Sie können diese Berechtigungen in einer Schlüsselrichtlinie oder einer IAM-Richtlinie bereitstellen.

Als Minimum benötigt Aurora DSQL die folgenden Berechtigungen für einen kundenseitig verwalteten Schlüssel:
+ `kms:Encrypt`
+ `kms:Decrypt`
+ `kms:ReEncrypt*`(für kms: ReEncryptFrom und kms:ReEncryptTo)
+ `kms:GenerateDataKey`
+ `kms:DescribeKey`

Beispielsweise bietet die folgende Beispiel-Schlüsselrichtlinie nur die erforderlichen Berechtigungen. Die Richtlinie hat folgende Auswirkungen:
+ Ermöglicht Aurora DSQL die Verwendung von AWS KMS key in kryptografischen Vorgängen, jedoch nur, wenn es im Namen von Prinzipalen im Konto handelt, die die Erlaubnis haben, Aurora DSQL zu verwenden. Falls die in der Richtlinienerklärung angegebenen Prinzipalen keine Berechtigung zur Nutzung von Aurora DSQL haben, schlägt der Aufruf fehl – selbst wenn er vom Aurora DSQL-Service stammt.
+ Der Bedingungsschlüssel `kms:ViaService` erlaubt die Berechtigungen nur, wenn die Anforderung im Auftrag der in der Richtlinienanweisung aufgeführten Prinzipale von Aurora DSQL stammt. Diese Prinzipale können diese Operationen nicht direkt aufrufen.

Bevor Sie ein Beispiel für eine Schlüsselrichtlinie verwenden, ersetzen Sie die Beispielprinzipale durch tatsächliche Prinzipale aus Ihrem. AWS-Konto

```
{
  "Sid": "Enable dsql IAM User Permissions",
  "Effect": "Allow",
  "Principal": {
    "Service": "dsql.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:Encrypt",
    "kms:ReEncryptFrom",
    "kms:ReEncryptTo"
  ],
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "kms:EncryptionContext:aws:dsql:ClusterId": "w4abucpbwuxx",
      "aws:SourceArn": "arn:aws:dsql:us-east-2:111122223333:cluster/w4abucpbwuxx"
    }
  }
},
{
  "Sid": "Enable dsql IAM User Describe Permissions",
  "Effect": "Allow",
  "Principal": {
    "Service": "dsql.amazonaws.com"
  },
  "Action": "kms:DescribeKey",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:SourceArn": "arn:aws:dsql:us-east-2:111122223333:cluster/w4abucpbwuxx"
    }
  }
}
```

## Aurora DSQL Verschlüsselungskontext
<a name="dsql-encryption-context"></a>

Ein Verschlüsselungskontext ist eine Gruppe von Schlüssel/Wert-Paaren mit willkürlichen, nicht geheimen Daten. Wenn Sie einen Verschlüsselungskontext in eine Anfrage zur Verschlüsselung von Daten einbeziehen, wird der Verschlüsselungskontext AWS KMS kryptografisch an die verschlüsselten Daten gebunden. Zur Entschlüsselung der Daten müssen Sie denselben Verschlüsselungskontext übergeben.

Aurora DSQL verwendet bei allen AWS KMS kryptografischen Vorgängen denselben Verschlüsselungskontext. Wenn Sie einen vom Kunden verwalteten Schlüssel zum Schutz Ihres Aurora DSQL-Clusters verwenden, können Sie den Verschlüsselungskontext verwenden, um die Verwendung des AWS KMS key in Auditaufzeichnungen und Protokollen zu identifizieren. Er erscheint auch im Klartext in Protokollen wie denen von AWS CloudTrail.

Der Verschlüsselungskontext kann außerdem als Bedingung für die Autorisierung in Richtlinien verwendet werden.

In seinen Anfragen an AWS KMS verwendet Aurora DSQL einen Verschlüsselungskontext mit einem Schlüssel-Wert-Paar:

```
"encryptionContext": {
  "aws:dsql:ClusterId": "w4abucpbwuxx"
},
```

Das Schlüssel-Wert-Paar identifiziert den Cluster, den Aurora DSQL verschlüsselt. Der Schlüssel lautet `aws:dsql:ClusterId`. Dieser Wert ist die ID des Clusters.

## Überwachung der Aurora DSQL-Interaktion mit AWS KMS
<a name="monitoring-dsql-kms-interaction"></a>

Wenn Sie einen vom Kunden verwalteten Schlüssel zum Schutz Ihrer Aurora DSQL-Cluster verwenden, können Sie AWS CloudTrail Protokolle verwenden, um die Anfragen zu verfolgen, an die Aurora DSQL in AWS KMS Ihrem Namen sendet.

Erweitern Sie die folgenden Abschnitte, um zu erfahren, wie Aurora DSQL die AWS KMS Operationen `GenerateDataKey` und `Decrypt` verwendet.

### `GenerateDataKey`
<a name="GenerateDataKey"></a>

Wenn Sie die Verschlüsselung im Ruhezustand auf einem Cluster aktivieren, erstellt Aurora DSQL einen eindeutigen Clusterschlüssel. Es sendet eine `GenerateDataKey` Anfrage an AWS KMS , die den AWS KMS key für den Cluster spezifiziert.

Das Ereignis, das die `GenerateDataKey`-Operation aufzeichnet, ähnelt dem folgenden Beispielereignis. Der Benutzer ist das Aurora DSQL-Servicekonto. Zu den Parametern gehören der Amazon-Ressourcenname (ARN) von AWS KMS key, ein Schlüsselspezifizierer, für den ein 256-Bit-Schlüssel erforderlich ist, und der Verschlüsselungskontext, der den Cluster identifiziert.

```
{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "AWSService",
        "invokedBy": "dsql.amazonaws.com"
    },
    "eventTime": "2025-05-16T18:41:24Z",
    "eventSource": "kms.amazonaws.com",
    "eventName": "GenerateDataKey",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "dsql.amazonaws.com",
    "userAgent": "dsql.amazonaws.com",
    "requestParameters": {
        "encryptionContext": {
            "aws:dsql:ClusterId": "w4abucpbwuxx"
        },
        "keySpec": "AES_256",
        "keyId": "arn:aws:kms:us-east-1:982127530226:key/8b60dd9f-2ff8-4b1f-8a9c-bf570cbfdb5e"
    },
    "responseElements": null,
    "requestID": "2da2dc32-d3f4-4d6c-8a41-aff27cd9a733",
    "eventID": "426df0a6-ba56-3244-9337-438411f826f4",
    "readOnly": true,
    "resources": [
        {
            "accountId": "AWS Internal",
            "type": "AWS::KMS::Key",
            "ARN": "arn:aws:kms:us-east-1:982127530226:key/8b60dd9f-2ff8-4b1f-8a9c-bf570cbfdb5e"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111122223333",
    "sharedEventID": "f88e0dd8-6057-4ce0-b77d-800448426d4e",
    "vpcEndpointId": "AWS Internal",
    "vpcEndpointAccountId": "vpce-1a2b3c4d5e6f1a2b3",
    "eventCategory": "Management"
}
```

### Decrypt
<a name="Decrypt"></a>

Wenn Sie auf einen verschlüsselten Aurora DSQL-Cluster zugreifen, muss Aurora DSQL den Clusterschlüssel entschlüsseln, um die darunterliegenden Schlüssel in der Hierarchie entschlüsseln zu können. Anschließend werden die Daten im Cluster entschlüsselt. Um den Clusterschlüssel zu entschlüsseln, sendet Aurora DSQL eine `Decrypt` Anfrage an AWS KMS , die den AWS KMS key für den Cluster spezifiziert.

Das Ereignis, das die `Decrypt`-Operation aufzeichnet, ähnelt dem folgenden Beispielereignis. Der Benutzer ist Ihr Hauptbenutzer AWS-Konto , der auf den Cluster zugreift. Zu den Parametern gehören der verschlüsselte Clusterschlüssel (als Chiffretext-Blob) und der Verschlüsselungskontext, der den Cluster identifiziert. AWS KMS leitet die ID von aus dem Chiffretext ab. AWS KMS key 

```
{
  "eventVersion": "1.05",
  "userIdentity": {
    "type": "AWSService",
    "invokedBy": "dsql.amazonaws.com"
  },
  "eventTime": "2018-02-14T16:42:39Z",
  "eventSource": "kms.amazonaws.com",
  "eventName": "Decrypt",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "dsql.amazonaws.com",
  "userAgent": "dsql.amazonaws.com",
  "requestParameters": {
    "keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab",
    "encryptionContext": {
      "aws:dsql:ClusterId": "w4abucpbwuxx"
    },
    "encryptionAlgorithm": "SYMMETRIC_DEFAULT"
  },
  "responseElements": null,
  "requestID": "11cab293-11a6-11e8-8386-13160d3e5db5",
  "eventID": "b7d16574-e887-4b5b-a064-bf92f8ec9ad3",
  "readOnly": true,
  "resources": [
    {
      "ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab",
      "accountId": "AWS Internal",
      "type": "AWS::KMS::Key"
    }
  ],
  "eventType": "AwsApiCall",
  "managementEvent": true,
  "recipientAccountId": "111122223333",
  "sharedEventID": "d99f2dc5-b576-45b6-aa1d-3a3822edbeeb",
  "vpcEndpointId": "AWS Internal",
  "vpcEndpointAccountId": "vpce-1a2b3c4d5e6f1a2b3",
  "eventCategory": "Management"
}
```

## Erstellen eines verschlüsselten Aurora DSQL-Clusters
<a name="creating-encrypted-cluster"></a>

Alle Aurora DSQL-Cluster sind im Ruhezustand verschlüsselt. Standardmäßig verwenden Cluster einen, AWS-eigener Schlüssel der kostenlos ist, oder Sie können einen benutzerdefinierten Schlüssel angeben. AWS KMS Gehen Sie wie folgt vor, um Ihren verschlüsselten Cluster entweder aus dem AWS-Managementkonsole oder dem zu erstellen AWS CLI.

------
#### [ Console ]

**Um einen verschlüsselten Cluster im zu erstellen AWS-Managementkonsole**

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Aurora DSQL-Konsole unter [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql/).

1. Wählen Sie im Navigationsbereich auf der linken Seite der Konsole die Option **Cluster** aus.

1. Klicken Sie oben rechts auf **Cluster erstellen** und wählen Sie dann **Einzelne Region** aus.

1. Wählen Sie in den **Cluster-Verschlüsselungseinstellungen** eine der folgenden Optionen aus.
   + Akzeptieren Sie die Standardeinstellungen für die Verschlüsselung ohne zusätzliche AWS-eigener Schlüssel Kosten.
   + Wählen Sie **Verschlüsselungseinstellungen anpassen (erweitert)** aus, um einen benutzerdefinierten KMS-Schlüssel anzugeben. Suchen Sie dann nach der ID oder dem Alias Ihres KMS-Schlüssels oder geben Sie ihn ein. Wählen Sie alternativ **Create an AWS KMS Key**, um einen neuen Schlüssel in der AWS KMS Konsole zu erstellen.

1. Wählen Sie **Cluster erstellen**.

Um den Verschlüsselungstyp Ihres Clusters zu bestätigen, navigieren Sie zur Seite **Cluster** und wählen Sie dort die ID des Clusters aus, um dessen Details anzuzeigen. Überprüfen Sie die Registerkarte **Cluster-Einstellungen**. Die **Cluster-KMS-Schlüsseleinstellung** zeigt den **Aurora DSQL-Standardschlüssel** für Cluster, die AWS eigene Schlüssel verwenden, oder die Schlüssel-ID für andere Verschlüsselungstypen.

**Anmerkung**  
Wenn Sie einen eigenen Schlüssel besitzen und verwalten möchten, stellen Sie sicher, dass Sie die KMS-Schlüsselrichtlinie entsprechend festlegen. Beispiele und weitere Informationen finden Sie unter [Schlüsselrichtlinie für einen kundenseitig verwalteten Schlüssel](#key-policy-customer-managed-key).

------
#### [ CLI ]

**Um einen Cluster zu erstellen, der mit dem Standard verschlüsselt ist AWS-eigener Schlüssel**
+ Verwenden Sie den folgenden Befehl, um einen Aurora DSQL-Cluster zu erstellen:

  ```
  aws dsql create-cluster
  ```

Wie in den folgenden Verschlüsselungsdetails dargestellt, ist die Verschlüsselung für den Cluster standardmäßig aktiviert, und der voreingestellte Verschlüsselungstyp ist ein von AWS verwalteter Schlüssel. Der Cluster ist nun mit dem standardmäßigen AWS-Schlüssel im Aurora DSQL-Servicekonto verschlüsselt.

```
"encryptionDetails": {
  "encryptionType" : "AWS_OWNED_KMS_KEY",
  "encryptionStatus" : "ENABLED"
}
```

**So erstellen Sie einen mit Ihrem kundenseitig verwalteten Schlüssel verschlüsselten Cluster**
+ Verwenden Sie den folgenden Befehl, um einen Aurora DSQL-Cluster zu erstellen, und ersetzen Sie die rot markierte Schlüssel-ID durch die ID Ihres kundenseitig verwalteten Schlüssels.

  ```
  aws dsql create-cluster \
  --kms-encryption-key d41d8cd98f00b204e9800998ecf8427e
  ```

Wie in den folgenden Verschlüsselungsdetails dargestellt, ist die Verschlüsselung für den Cluster standardmäßig aktiviert, und der Verschlüsselungstyp ist ein kundenseitig verwalteter KMS-Schlüssel. Der Cluster ist nun mit Ihrem Schlüssel verschlüsselt.

```
"encryptionDetails": {
  "encryptionType" : "CUSTOMER_MANAGED_KMS_KEY",
  "kmsKeyArn" : "arn:aws:kms:us-east-1:111122223333:key/d41d8cd98f00b204e9800998ecf8427e",
  "encryptionStatus" : "ENABLED"
}
```

------

## Entfernen oder Aktualisieren eines Schlüssels für Ihren Aurora DSQL-Cluster
<a name="updating-encryption-key"></a>

Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um die Verschlüsselungsschlüssel auf vorhandenen Clustern in Amazon Aurora DSQL zu aktualisieren oder zu entfernen. Wenn Sie einen Schlüssel entfernen, ohne ihn zu ersetzen, verwendet Aurora DSQL den Standard- AWS-eigener Schlüssel. Im Folgenden sehen Sie, wie Sie die Verschlüsselungsschlüssel eines bestehenden Clusters über die Aurora DSQL-Konsole oder die AWS CLI aktualisieren.

------
#### [ Console ]

**Um einen Verschlüsselungsschlüssel zu aktualisieren oder zu entfernen in AWS-Managementkonsole**

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Aurora DSQL-Konsole unter [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql/).

1. Wählen Sie im Navigationsbereich auf der linken Seite der Konsole die Option **Cluster** aus.

1. Suchen Sie in der Listenansicht die Zeile des Clusters, den Sie aktualisieren möchten, und wählen Sie sie aus.

1. Klicken Sie auf das Menü **Aktionen** und dann auf **Bearbeiten**.

1. Wählen Sie in den **Cluster-Verschlüsselungseinstellungen** eine der folgenden Optionen aus, um Ihre Verschlüsselungseinstellungen zu ändern.
   + Wenn Sie von einem benutzerdefinierten Schlüssel zu einem wechseln möchten AWS-eigener Schlüssel, deaktivieren Sie die Option **Verschlüsselungseinstellungen anpassen (erweitert)**. Die Standardeinstellungen werden angewendet und Ihr Cluster wird kostenlos verschlüsselt. AWS-eigener Schlüssel 
   + Wenn Sie von einem benutzerdefinierten KMS-Schlüssel zu einem anderen oder von einem AWS-eigener Schlüssel zu einem KMS-Schlüssel wechseln möchten, wählen Sie die Option **Verschlüsselungseinstellungen anpassen (erweitert)**, falls sie nicht bereits ausgewählt ist. Suchen Sie dann nach der ID oder dem Alias des Schlüssels, den Sie verwenden möchten, und wählen Sie dies aus. Wählen Sie alternativ **Create an AWS KMS Key**, um einen neuen Schlüssel in der AWS KMS Konsole zu erstellen.

1. Wählen Sie **Speichern**.

------
#### [ CLI ]

Die folgenden Beispiele zeigen, wie Sie mit AWS CLI dem einen verschlüsselten Cluster aktualisieren können.

Um einen verschlüsselten Cluster mit der Standardeinstellung zu aktualisieren AWS-eigener Schlüssel

```
aws dsql update-cluster \
--identifier aiabtx6icfp6d53snkhseduiqq \
--kms-encryption-key "AWS_OWNED_KMS_KEY"
```

Der `EncryptionStatus` in der Clusterbeschreibung ist auf `ENABLED` gesetzt, und der `EncryptionType` ist `AWS_OWNED_KMS_KEY`.

```
"encryptionDetails": {
  "encryptionType" : "AWS_OWNED_KMS_KEY",
  "encryptionStatus" : "ENABLED"
}
```

Dieser Cluster ist jetzt mit der Standardeinstellung AWS-eigener Schlüssel im Aurora DSQL-Dienstkonto verschlüsselt.

So aktualisieren Sie einen verschlüsselten Cluster mit einem kundenseitig verwalteten Schlüssel für Aurora DSQL

Aktualisieren Sie den verschlüsselten Cluster wie im folgenden Beispiel gezeigt:

```
aws dsql update-cluster \
--identifier aiabtx6icfp6d53snkhseduiqq \
--kms-encryption-key arn:aws:kms:us-east-1:123456789012:key/abcd1234-abcd-1234-a123-ab1234a1b234
```

Der `EncryptionStatus` in der Clusterbeschreibung wechselt zu `UPDATING`, und der `EncryptionType` ist `CUSTOMER_MANAGED_KMS_KEY`. Nachdem Aurora DSQL den neuen Schlüssel vollständig in der Plattform propagiert hat, wird der Verschlüsselungsstatus auf `ENABLED` gesetzt.

```
"encryptionDetails": {
  "encryptionType" : "CUSTOMER_MANAGED_KMS_KEY",
  "kmsKeyArn" : "arn:aws:us-east-1:kms:key/abcd1234-abcd-1234-a123-ab1234a1b234",
  "encryptionStatus" : "ENABLED"
}
```

------

**Anmerkung**  
Wenn Sie einen eigenen Schlüssel besitzen und verwalten möchten, stellen Sie sicher, dass Sie die KMS-Schlüsselrichtlinie entsprechend festlegen. Beispiele und weitere Informationen finden Sie unter [Schlüsselrichtlinie für einen kundenseitig verwalteten Schlüssel](#key-policy-customer-managed-key).

## Überlegungen zur Verschlüsselung mit Aurora DSQL
<a name="considerations-with-encryption"></a>
+ Aurora DSQL verschlüsselt alle Clusterdaten im Ruhezustand. Sie können diese Verschlüsselung nicht deaktivieren oder nur einzelne Elemente in einem Cluster verschlüsseln.
+ AWS Backup verschlüsselt Ihre Backups und alle Cluster, die aus diesen Backups wiederhergestellt wurden. Sie können Ihre Backup-Daten entweder AWS Backup mit dem AWS eigenen Schlüssel oder mit einem vom Kunden verwalteten Schlüssel verschlüsseln.
+ Die folgenden Datenschutzzustände sind für Aurora DSQL aktiviert:
  + **Daten im Ruhezustand** — Aurora DSQL verschlüsselt alle statischen Daten auf persistenten Speichermedien
  + **Daten während der Übertragung** — Aurora DSQL verschlüsselt die gesamte Kommunikation standardmäßig mit Transport Layer Security (TLS)
+ Wenn Sie zu einem anderen Schlüssel wechseln, empfehlen wir, den ursprünglichen Schlüssel aktiviert zu lassen, bis der Übergang abgeschlossen ist. AWS benötigt den Originalschlüssel zum Entschlüsseln von Daten, bevor Ihre Daten mit dem neuen Schlüssel verschlüsselt werden. Der Vorgang ist abgeschlossen, wenn der `encryptionStatus` des Clusters auf `ENABLED` gesetzt ist und Sie die `kmsKeyArn` des neuen kundenseitig verwalteten Schlüssels sehen.
+ Wenn Sie Ihren kundenseitig verwalteten Schlüssel deaktivieren oder den Zugriff für Aurora DSQL auf Ihren Schlüssel widerrufen, wechselt Ihr Cluster in den Status `IDLE`.
+ Die DSQL-API AWS-Managementkonsole und die Amazon Aurora DSQL API verwenden unterschiedliche Begriffe für Verschlüsselungstypen:
  + AWS Konsole — In der Konsole sehen Sie, `KMS` wann Sie einen vom Kunden verwalteten Schlüssel verwenden und `DEFAULT` wann Sie einen AWS-eigener Schlüssel verwenden.
  + API — Die Amazon Aurora DSQL API verwendet `CUSTOMER_MANAGED_KMS_KEY` für kundenseitig verwaltete Schlüssel und `AWS_OWNED_KMS_KEY` für AWS-eigene Schlüssel.
+ Wenn Sie bei der Clustererstellung keinen Verschlüsselungsschlüssel angeben, verschlüsselt Aurora DSQL Ihre Daten automatisch mit dem. AWS-eigener Schlüssel
+ Sie können jederzeit zwischen einem AWS-eigener Schlüssel und einem vom Kunden verwalteten Schlüssel wechseln. Nehmen Sie diese Änderung mithilfe der AWS-Managementkonsole AWS CLI, oder der Amazon Aurora SQL API vor.

# Identitäts- und Zugriffsverwaltung für Aurora DSQL
<a name="security-iam"></a>

AWS Identity and Access Management (IAM) hilft einem Administrator AWS-Service , den Zugriff auf Ressourcen sicher zu AWS kontrollieren. IAM-Administratoren steuern, wer für die Nutzung von Aurora DSQL-Ressourcen *authentifiziert* (angemeldet) und *autorisiert* (mit Berechtigungen versehen) werden kann. IAM ist ein Programm AWS-Service , das Sie ohne zusätzliche Kosten nutzen können.

**Topics**
+ [Zielgruppe](#security_iam_audience)
+ [Authentifizierung mit Identitäten](#security_iam_authentication)
+ [Verwalten des Zugriffs mit Richtlinien](#security_iam_access-manage)
+ [Funktionsweise von Amazon Aurora DSQL mit IAM](security_iam_service-with-iam.md)
+ [Beispiele für identitätsbasierte Richtlinien für Amazon Aurora DSQL](security_iam_id-based-policy-examples.md)
+ [Fehlerbehebung für Amazon Aurora DSQL-Identität und -Zugriff](security_iam_troubleshoot.md)

## Zielgruppe
<a name="security_iam_audience"></a>

Wie Sie AWS Identity and Access Management (IAM) verwenden, hängt von Ihrer Rolle ab:
+ **Servicebenutzer** – Fordern Sie von Ihrem Administrator Berechtigungen an, wenn Sie nicht auf Features zugreifen können (siehe [Fehlerbehebung für Amazon Aurora DSQL-Identität und -Zugriff](security_iam_troubleshoot.md)).
+ **Serviceadministrator** – Bestimmen Sie den Benutzerzugriff und stellen Sie Berechtigungsanfragen (siehe [Funktionsweise von Amazon Aurora DSQL mit IAM](security_iam_service-with-iam.md)).
+ **IAM-Administrator** – Schreiben Sie Richtlinien zur Zugriffsverwaltung (siehe [Beispiele für identitätsbasierte Richtlinien für Amazon Aurora DSQL](security_iam_id-based-policy-examples.md)).

## Authentifizierung mit Identitäten
<a name="security_iam_authentication"></a>

Authentifizierung ist die Art und Weise, wie Sie sich AWS mit Ihren Identitätsdaten anmelden. Sie müssen sich als IAM-Benutzer authentifizieren oder eine IAM-Rolle annehmen. Root-Benutzer des AWS-Kontos

Sie können sich als föderierte Identität anmelden, indem Sie Anmeldeinformationen aus einer Identitätsquelle wie AWS IAM Identity Center (IAM Identity Center), Single Sign-On-Authentifizierung oder Anmeldeinformationen verwenden. Google/Facebook Weitere Informationen zum Anmelden finden Sie unter [So melden Sie sich bei Ihrem AWS-Konto an](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) im *Benutzerhandbuch für AWS-Anmeldung *.

 AWS Bietet für den programmatischen Zugriff ein SDK und eine CLI zum kryptografischen Signieren von Anfragen. Weitere Informationen finden Sie unter [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) im *IAM-Benutzerhandbuch*.

### AWS-Konto Root-Benutzer
<a name="security_iam_authentication-rootuser"></a>

 Wenn Sie einen erstellen AWS-Konto, beginnen Sie mit einer Anmeldeidentität, dem sogenannten AWS-Konto *Root-Benutzer*, der vollständigen Zugriff auf alle AWS-Services Ressourcen hat. Wir raten ausdrücklich davon ab, den Root-Benutzer für Alltagsaufgaben zu verwenden. Eine Liste der Aufgaben, für die Sie sich als Root-Benutzer anmelden müssen, finden Sie unter [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) im *IAM-Benutzerhandbuch*. 

### Verbundidentität
<a name="security_iam_authentication-federated"></a>

Es hat sich bewährt, dass menschliche Benutzer für den Zugriff AWS-Services mithilfe temporärer Anmeldeinformationen einen Verbund mit einem Identitätsanbieter verwenden müssen.

Eine *föderierte Identität* ist ein Benutzer aus Ihrem Unternehmensverzeichnis, Ihrem Directory Service Web-Identitätsanbieter oder der AWS-Services mithilfe von Anmeldeinformationen aus einer Identitätsquelle zugreift. Verbundene Identitäten übernehmen Rollen, die temporäre Anmeldeinformationen bereitstellen.

Für die zentrale Zugriffsverwaltung empfehlen wir AWS IAM Identity Center. Weitere Informationen finden Sie unter [Was ist IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) im *AWS IAM Identity Center -Benutzerhandbuch*.

### IAM-Benutzer und -Gruppen
<a name="security_iam_authentication-iamuser"></a>

Ein *[IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* ist eine Identität mit bestimmten Berechtigungen für eine einzelne Person oder Anwendung. Wir empfehlen die Verwendung temporärer Anmeldeinformationen anstelle von IAM-Benutzern mit langfristigen Anmeldeinformationen. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Erfordern, dass menschliche Benutzer den Verbund mit einem Identitätsanbieter verwenden müssen, um AWS mithilfe temporärer Anmeldeinformationen darauf zugreifen zu](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) können.

Eine [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spezifiziert eine Sammlung von IAM-Benutzern und erleichtert die Verwaltung von Berechtigungen für große Gruppen von Benutzern. Weitere Informationen finden Sie unter [Anwendungsfälle für IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) im *IAM-Benutzerhandbuch*.

### IAM-Rollen
<a name="security_iam_authentication-iamrole"></a>

Eine *[IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* ist eine Identität mit spezifischen Berechtigungen, die temporäre Anmeldeinformationen bereitstellt. Sie können eine Rolle übernehmen, indem Sie [von einer Benutzer- zu einer IAM-Rolle (Konsole) wechseln](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) AWS CLI oder einen AWS API-Vorgang aufrufen. Weitere Informationen finden Sie unter [Methoden, um eine Rolle zu übernehmen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) im *IAM-Benutzerhandbuch*.

IAM-Rollen sind nützlich für den Verbundbenutzer-Zugriff, temporäre IAM-Benutzerberechtigungen, kontoübergreifenden Zugriff, serviceübergreifenden Zugriff und Anwendungen, die auf Amazon EC2 laufen. Weitere Informationen finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.

## Verwalten des Zugriffs mit Richtlinien
<a name="security_iam_access-manage"></a>

Sie kontrollieren den Zugriff, AWS indem Sie Richtlinien erstellen und diese an AWS Identitäten oder Ressourcen anhängen. Eine Richtlinie definiert Berechtigungen, wenn sie mit einer Identität oder Ressource verknüpft sind. AWS bewertet diese Richtlinien, wenn ein Principal eine Anfrage stellt. Die meisten Richtlinien werden AWS als JSON-Dokumente gespeichert. Weitere Informationen zu JSON-Richtliniendokumenten finden Sie unter [Übersicht über JSON-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) im *IAM-Benutzerhandbuch*.

Mit Hilfe von Richtlinien legen Administratoren fest, wer Zugriff auf was hat, indem sie definieren, welches **Prinzipal** welche **Aktionen** auf welchen **Ressourcen**und unter welchen **Bedingungen**durchführen darf.

Standardmäßig haben Benutzer, Gruppen und Rollen keine Berechtigungen. Ein IAM-Administrator erstellt IAM-Richtlinien und fügt sie zu Rollen hinzu, die die Benutzer dann übernehmen können. IAM-Richtlinien definieren Berechtigungen unabhängig von der Methode, die zur Ausführung der Operation verwendet wird.

### Identitätsbasierte Richtlinien
<a name="security_iam_access-manage-id-based-policies"></a>

Identitätsbasierte Richtlinien sind JSON-Berechtigungsrichtliniendokumente, die Sie einer Identität (Benutzer, Gruppe oder Rolle) anfügen können. Diese Richtlinien steuern, welche Aktionen Identitäten für welche Ressourcen und unter welchen Bedingungen ausführen können. Informationen zum Erstellen identitätsbasierter Richtlinien finden Sie unter [Definieren benutzerdefinierter IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.

Identitätsbasierte Richtlinien können *Inline-Richtlinien* (direkt in eine einzelne Identität eingebettet) oder *verwaltete Richtlinien* (eigenständige Richtlinien, die mit mehreren Identitäten verbunden sind) sein. Informationen dazu, wie Sie zwischen verwalteten und Inline-Richtlinien wählen, finden Sie unter [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) im *IAM-Benutzerhandbuch*.

### Ressourcenbasierte Richtlinien
<a name="security_iam_access-manage-resource-based-policies"></a>

Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource anfügen. Beispiele hierfür sind *Vertrauensrichtlinien für IAM-Rollen* und Amazon S3*-Bucket-Richtlinien*. In Services, die ressourcenbasierte Richtlinien unterstützen, können Service-Administratoren sie verwenden, um den Zugriff auf eine bestimmte Ressource zu steuern. Sie müssen in einer ressourcenbasierten Richtlinie [einen Prinzipal angeben](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).

Ressourcenbasierte Richtlinien sind Richtlinien innerhalb dieses Diensts. Sie können AWS verwaltete Richtlinien von IAM nicht in einer ressourcenbasierten Richtlinie verwenden.

### Weitere Richtlinientypen
<a name="security_iam_access-manage-other-policies"></a>

AWS unterstützt zusätzliche Richtlinientypen, mit denen die maximalen Berechtigungen festgelegt werden können, die durch gängigere Richtlinientypen gewährt werden:
+ **Berechtigungsgrenzen** – Eine Berechtigungsgrenze legt die maximalen Berechtigungen fest, die eine identitätsbasierte Richtlinie einer IAM-Entität erteilen kann. Weitere Informationen finden Sie unter [Berechtigungsgrenzen für IAM-Entitäten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) im *-IAM-Benutzerhandbuch*.
+ **Richtlinien zur Dienstkontrolle (SCPs)** — Geben Sie die maximalen Berechtigungen für eine Organisation oder Organisationseinheit in an AWS Organizations. Weitere Informationen finden Sie unter [Service-Kontrollrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) im *AWS Organizations -Benutzerhandbuch*.
+ **Richtlinien zur Ressourcenkontrolle (RCPs)** — Legen Sie die maximal verfügbaren Berechtigungen für Ressourcen in Ihren Konten fest. Weitere Informationen finden Sie im *AWS Organizations Benutzerhandbuch* unter [Richtlinien zur Ressourcenkontrolle (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html).
+ **Sitzungsrichtlinien** – Sitzungsrichtlinien sind erweiterte Richtlinien, die als Parameter übergeben werden, wenn Sie eine temporäre Sitzung für eine Rolle oder einen Verbundbenutzer erstellen. Weitere Informationen finden Sie unter [Sitzungsrichtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) im *IAM-Benutzerhandbuch*.

### Mehrere Richtlinientypen
<a name="security_iam_access-manage-multiple-policies"></a>

Wenn für eine Anfrage mehrere Arten von Richtlinien gelten, sind die daraus resultierenden Berechtigungen schwieriger zu verstehen. Informationen darüber, wie AWS bestimmt wird, ob eine Anfrage zulässig ist, wenn mehrere Richtlinientypen betroffen sind, finden Sie unter [Bewertungslogik für Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) im *IAM-Benutzerhandbuch*.

# Funktionsweise von Amazon Aurora DSQL mit IAM
<a name="security_iam_service-with-iam"></a>

Bevor Sie IAM für die Aurora DSQL-Zugriffsverwaltung einsetzen, informieren Sie sich bitte hier, welche IAM-Features Sie mit Aurora DSQL verwenden können.






**IAM-Features, die Sie mit Amazon Aurora DSQL verwenden können**  

| IAM-Feature | Aurora DSQL-Unterstützung | 
| --- | --- | 
|  [Identitätsbasierte Richtlinien](#security_iam_service-with-iam-id-based-policies)  |   Ja  | 
|  [Ressourcenbasierte Richtlinien](#security_iam_service-with-iam-resource-based-policies)  |   Ja  | 
|  [Richtlinienaktionen](#security_iam_service-with-iam-id-based-policies-actions)  |   Ja  | 
|  [Richtlinienressourcen](#security_iam_service-with-iam-id-based-policies-resources)  |   Ja  | 
|  [Bedingungsschlüssel für die Richtlinie](#security_iam_service-with-iam-id-based-policies-conditionkeys)  |   Ja  | 
|  [ACLs](#security_iam_service-with-iam-acls)  |   Nein   | 
|  [ABAC (Tags in Richtlinien)](#security_iam_service-with-iam-tags)  |   Ja  | 
|  [Temporäre Anmeldeinformationen](#security_iam_service-with-iam-roles-tempcreds)  |   Ja  | 
|  [Prinzipalberechtigungen](#security_iam_service-with-iam-principal-permissions)  |   Ja  | 
|  [Servicerollen](#security_iam_service-with-iam-roles-service)  |   Ja  | 
|  [Service-verknüpfte Rollen](#security_iam_service-with-iam-roles-service-linked)  |   Ja  | 

*Einen allgemeinen Überblick darüber, wie Aurora DSQL und andere AWS Dienste mit den meisten IAM-Funktionen funktionieren, finden Sie im [AWS IAM-Benutzerhandbuch unter Dienste, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*

## Identitätsbasierte Aurora DSQL-Richtlinien
<a name="security_iam_service-with-iam-id-based-policies"></a>

**Unterstützt Richtlinien auf Identitätsbasis:** Ja

Identitätsbasierte Richtlinien sind JSON-Berechtigungsrichtliniendokumente, die Sie einer Identität anfügen können, wie z. B. IAM-Benutzern, -Benutzergruppen oder -Rollen. Diese Richtlinien steuern, welche Aktionen die Benutzer und Rollen für welche Ressourcen und unter welchen Bedingungen ausführen können. Informationen zum Erstellen identitätsbasierter Richtlinien finden Sie unter [Definieren benutzerdefinierter IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.

Mit identitätsbasierten IAM-Richtlinien können Sie angeben, welche Aktionen und Ressourcen zugelassen oder abgelehnt werden. Darüber hinaus können Sie die Bedingungen festlegen, unter denen Aktionen zugelassen oder abgelehnt werden. Informationen zu sämtlichen Elementen, die Sie in einer JSON-Richtlinie verwenden, finden Sie in der [IAM-Referenz für JSON-Richtlinienelemente](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) im *IAM-Benutzerhandbuch*.

### Beispiele für identitätsbasierte Aurora DSQL-Richtlinien
<a name="security_iam_service-with-iam-id-based-policies-examples"></a>



Beispiele für identitätsbasierte Aurora DSQL-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien für Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).

## Ressourcenbasierte Richtlinien in Aurora DSQL
<a name="security_iam_service-with-iam-resource-based-policies"></a>

**Unterstützt ressourcenbasierte Richtlinien:** Ja

Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource anfügen. Beispiele für ressourcenbasierte Richtlinien sind IAM-Rollen-Vertrauensrichtlinien und Amazon-S3-Bucket-Richtlinien. In Services, die ressourcenbasierte Richtlinien unterstützen, können Service-Administratoren sie verwenden, um den Zugriff auf eine bestimmte Ressource zu steuern. Für die Ressource, an welche die Richtlinie angehängt ist, legt die Richtlinie fest, welche Aktionen ein bestimmter Prinzipal unter welchen Bedingungen für diese Ressource ausführen kann. Sie müssen in einer ressourcenbasierten Richtlinie [einen Prinzipal angeben](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). Prinzipale können Konten, Benutzer, Rollen, verbundene Benutzer oder AWS-Services umfassen. Ressourcenbasierte Richtlinien sind Richtlinien innerhalb dieses Diensts. Sie können AWS-verwaltete Richtlinien von IAM nicht in einer ressourcenbasierten Richtlinie verwenden.

Informationen zum Erstellen und Verwalten ressourcenbasierter Richtlinien für Aurora DSQL-Cluster finden Sie unter [Ressourcenbasierte](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/resource-based-policies.html) Richtlinien für Aurora DSQL.

## Richtlinienaktionen für Aurora DSQL
<a name="security_iam_service-with-iam-id-based-policies-actions"></a>

**Unterstützt Richtlinienaktionen:** Ja

Administratoren können AWS JSON-Richtlinien verwenden, um festzulegen, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.

Das Element `Action` einer JSON-Richtlinie beschreibt die Aktionen, mit denen Sie den Zugriff in einer Richtlinie zulassen oder verweigern können. Nehmen Sie Aktionen in eine Richtlinie auf, um Berechtigungen zur Ausführung des zugehörigen Vorgangs zu erteilen.



Eine Liste der Aurora DSQL-Aktionen finden Sie unter [Von Amazon Aurora DSQL definierte Aktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions) in der *Service Authorization-Referenz*.

Richtlinienaktionen in Aurora DSQL verwenden das folgende Präfix vor der Aktion:

```
dsql
```

Um mehrere Aktionen in einer einzigen Anweisung anzugeben, trennen Sie sie mit Kommata:

```
"Action": [
      "dsql:action1",
      "dsql:action2"
]
```





Beispiele für identitätsbasierte Aurora DSQL-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien für Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).

## Richtlinienressourcen für Aurora DSQL
<a name="security_iam_service-with-iam-id-based-policies-resources"></a>

**Unterstützt Richtlinienressourcen:** Ja

Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.

Das JSON-Richtlinienelement `Resource` gibt die Objekte an, auf welche die Aktion angewendet wird. Als Best Practice geben Sie eine Ressource mit dem zugehörigen [Amazon-Ressourcennamen (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) an. Verwenden Sie für Aktionen, die keine Berechtigungen auf Ressourcenebene unterstützen, einen Platzhalter (\$1), um anzugeben, dass die Anweisung für alle Ressourcen gilt.

```
"Resource": "*"
```

Eine Liste der Aurora DSQL-Ressourcentypen und ihrer ARNs Eigenschaften finden Sie unter [Von Amazon Aurora DSQL definierte Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-resources-for-iam-policies) in der *Service Authorization Reference*. Informationen zu den Aktionen, mit denen Sie den ARN einzelner Ressourcen angeben können, finden Sie unter [Von Amazon Aurora DSQL definierte Aktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions).





Beispiele für identitätsbasierte Aurora DSQL-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien für Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).

## Richtlinien-Bedingungsschlüssel für Aurora DSQL
<a name="security_iam_service-with-iam-id-based-policies-conditionkeys"></a>

**Unterstützt servicespezifische Richtlinienbedingungsschlüssel:** Ja

Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.

Das Element `Condition` gibt an, wann Anweisungen auf der Grundlage definierter Kriterien ausgeführt werden. Sie können bedingte Ausdrücke erstellen, die [Bedingungsoperatoren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html) verwenden, z. B. ist gleich oder kleiner als, damit die Bedingung in der Richtlinie mit Werten in der Anforderung übereinstimmt. Eine Übersicht aller AWS globalen Bedingungsschlüssel finden Sie unter [Kontextschlüssel für AWS globale Bedingungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) im *IAM-Benutzerhandbuch*.

Eine Liste von Aurora DSQL-Bedingungsschlüsseln finden Sie unter [Bedingungsschlüssel für Amazon Aurora DSQL](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonauroradsql.html#amazonauroradsql-policy-keys) in der *Service-Authorization-Referenz*. Informationen dazu, für welche Aktionen und Ressourcen Sie einen Bedingungsschlüssel verwenden können, finden Sie unter [Von Amazon Aurora DSQL definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonauroradsql.html#amazonauroradsql-actions-as-permissions).

Beispiele für identitätsbasierte Aurora DSQL-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien für Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).

## ACLs in Aurora DSQL
<a name="security_iam_service-with-iam-acls"></a>

**Unterstützt ACLs: Nein** 

Zugriffskontrolllisten (ACLs) steuern, welche Principals (Kontomitglieder, Benutzer oder Rollen) über Zugriffsberechtigungen für eine Ressource verfügen. ACLs ähneln ressourcenbasierten Richtlinien, verwenden jedoch nicht das JSON-Richtliniendokumentformat.

## ABAC mit Aurora DSQL
<a name="security_iam_service-with-iam-tags"></a>

**Unterstützt ABAC (Tags in Richtlinien):** Ja

Die attributbasierte Zugriffskontrolle (ABAC) ist eine Autorisierungsstrategie, bei der Berechtigungen basierend auf Attributen, auch als Tags bezeichnet, definiert werden. Sie können Tags an IAM-Entitäten und AWS -Ressourcen anhängen und dann ABAC-Richtlinien so entwerfen, dass Operationen möglich sind, wenn das Tag des Prinzipals mit dem Tag auf der Ressource übereinstimmt.

Um den Zugriff auf der Grundlage von Tags zu steuern, geben Sie im Bedingungselement einer[ Richtlinie Tag-Informationen ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)an, indem Sie die Schlüssel `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, oder Bedingung `aws:TagKeys` verwenden.

Wenn ein Service alle drei Bedingungsschlüssel für jeden Ressourcentyp unterstützt, lautet der Wert für den Service **Ja**. Wenn ein Service alle drei Bedingungsschlüssel für nur einige Ressourcentypen unterstützt, lautet der Wert **Teilweise**.

*Weitere Informationen zu ABAC finden Sie unter [Definieren von Berechtigungen mit ABAC-Autorisierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) im IAM-Benutzerhandbuch*. Um ein Tutorial mit Schritten zur Einstellung von ABAC anzuzeigen, siehe [Attributbasierte Zugriffskontrolle (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) verwenden im *IAM-Benutzerhandbuch*.

## Verwenden temporärer Anmeldeinformationen mit Aurora DSQL
<a name="security_iam_service-with-iam-roles-tempcreds"></a>

**Unterstützt temporäre Anmeldeinformationen:** Ja

Temporäre Anmeldeinformationen ermöglichen den kurzfristigen Zugriff auf AWS Ressourcen und werden automatisch erstellt, wenn Sie einen Verbund verwenden oder die Rollen wechseln. AWS empfiehlt, temporäre Anmeldeinformationen dynamisch zu generieren, anstatt langfristige Zugriffsschlüssel zu verwenden. Weitere Informationen finden Sie unter [Temporäre Anmeldeinformationen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) und [AWS-Services , die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) im *IAM-Benutzerhandbuch*.

## Serviceübergreifende Prinzipal-Berechtigungen für Aurora DSQL
<a name="security_iam_service-with-iam-principal-permissions"></a>

**Unterstützt Forward Access Sessions (FAS):** Ja

 Forward Access Sessions (FAS) verwenden die Berechtigungen des Prinzipals, der einen aufruft AWS-Service, in Kombination mit der Anfrage, Anfragen AWS-Service an nachgeschaltete Dienste zu stellen. Einzelheiten zu den Richtlinien für FAS-Anforderungen finden Sie unter [Zugriffssitzungen weiterleiten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). 

## Servicerollen für Aurora DSQL
<a name="security_iam_service-with-iam-roles-service"></a>

**Unterstützt Servicerollen:** Ja

 Eine Servicerolle ist eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die ein Service annimmt, um Aktionen in Ihrem Namen auszuführen. Ein IAM-Administrator kann eine Servicerolle innerhalb von IAM erstellen, ändern und löschen. Weitere Informationen finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen AWS-Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) im *IAM-Benutzerhandbuch*. 

**Warnung**  
Eine Änderung der Berechtigungen für eine Servicerolle könnte die Aurora DSQL-Funktionalität beeinträchtigen. Bearbeiten Sie Servicerollen nur, wenn Aurora DSQL eine Anleitung dazu bereitstellt.

## Serviceverknüpfte Rollen für Aurora DSQL
<a name="security_iam_service-with-iam-roles-service-linked"></a>

**Unterstützt serviceverknüpfte Rollen:** Ja

 Eine serviceverknüpfte Rolle ist eine Art von Servicerolle, die mit einer verknüpft ist. AWS-Service Der Service kann die Rolle übernehmen, um eine Aktion in Ihrem Namen auszuführen. Dienstbezogene Rollen werden in Ihrem Dienst angezeigt AWS-Konto und gehören dem Dienst. Ein IAM-Administrator kann die Berechtigungen für Service-verknüpfte Rollen anzeigen, aber nicht bearbeiten. 

Details zum Erstellen oder Verwalten von serviceverknüpften Aurora DSQL-Rollen finden Sie unter [Verwenden von serviceverknüpften Rollen in Aurora DSQL](working-with-service-linked-roles.md).

# Beispiele für identitätsbasierte Richtlinien für Amazon Aurora DSQL
<a name="security_iam_id-based-policy-examples"></a>

Benutzer und Rollen haben standardmäßig nicht die Berechtigung, Aurora DSQL-Ressourcen zu erstellen oder zu ändern. Ein IAM-Administrator muss IAM-Richtlinien erstellen, die Benutzern die Berechtigung erteilen, Aktionen für die Ressourcen auszuführen, die sie benötigen.

Informationen dazu, wie Sie unter Verwendung dieser beispielhaften JSON-Richtliniendokumente eine identitätsbasierte IAM-Richtlinie erstellen, finden Sie unter [Erstellen von IAM-Richtlinien (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) im *IAM-Benutzerhandbuch*.

Einzelheiten zu den von Aurora DSQL definierten Aktionen und Ressourcentypen, einschließlich des Formats ARNs für die einzelnen Ressourcentypen, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html) in der *Service Authorization* Reference.

**Topics**
+ [Best Practices für Richtlinien](#security_iam_service-with-iam-policy-best-practices)
+ [Verwenden der Aurora DSQL-Konsole](#security_iam_id-based-policy-examples-console)
+ [Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Clusterverwaltung und Datenbankverbindung zulassen](#security_iam_id-based-policy-examples-cluster-management)
+ [Aurora DSQL-Ressourcenzugriff basierend auf Tags](#security_iam_id-based-policy-examples-tag-based-access)

## Best Practices für Richtlinien
<a name="security_iam_service-with-iam-policy-best-practices"></a>

Identitätsbasierte Richtlinien legen fest, ob jemand Aurora DSQL-Ressourcen in Ihrem Konto erstellen, auf sie zugreifen oder sie löschen kann. Dies kann zusätzliche Kosten für Ihr verursachen AWS-Konto. Wenn Sie identitätsbasierte Richtlinien erstellen oder bearbeiten, befolgen Sie diese Richtlinien und Empfehlungen:
+ **Erste Schritte mit AWS verwalteten Richtlinien und Umstellung auf Berechtigungen mit den geringsten Rechten** — Verwenden Sie die *AWS verwalteten Richtlinien*, die Berechtigungen für viele gängige Anwendungsfälle gewähren, um damit zu beginnen, Ihren Benutzern und Workloads Berechtigungen zu gewähren. Sie sind in Ihrem verfügbar. AWS-Konto Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie vom AWS Kunden verwaltete Richtlinien definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind. Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) oder [Von AWS verwaltete Richtlinien für Auftragsfunktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) im *IAM-Benutzerhandbuch*.
+ **Anwendung von Berechtigungen mit den geringsten Rechten** – Wenn Sie mit IAM-Richtlinien Berechtigungen festlegen, gewähren Sie nur die Berechtigungen, die für die Durchführung einer Aufgabe erforderlich sind. Sie tun dies, indem Sie die Aktionen definieren, die für bestimmte Ressourcen unter bestimmten Bedingungen durchgeführt werden können, auch bekannt als *die geringsten Berechtigungen*. Weitere Informationen zur Verwendung von IAM zum Anwenden von Berechtigungen finden Sie unter [ Richtlinien und Berechtigungen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von Bedingungen in IAM-Richtlinien zur weiteren Einschränkung des Zugriffs** – Sie können Ihren Richtlinien eine Bedingung hinzufügen, um den Zugriff auf Aktionen und Ressourcen zu beschränken. Sie können beispielsweise eine Richtlinienbedingung schreiben, um festzulegen, dass alle Anforderungen mithilfe von SSL gesendet werden müssen. Sie können auch Bedingungen verwenden, um Zugriff auf Serviceaktionen zu gewähren, wenn diese für einen bestimmten Zweck verwendet werden AWS-Service, z. CloudFormation B. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von IAM Access Analyzer zur Validierung Ihrer IAM-Richtlinien, um sichere und funktionale Berechtigungen zu gewährleisten** – IAM Access Analyzer validiert neue und vorhandene Richtlinien, damit die Richtlinien der IAM-Richtliniensprache (JSON) und den bewährten IAM-Methoden entsprechen. IAM Access Analyzer stellt mehr als 100 Richtlinienprüfungen und umsetzbare Empfehlungen zur Verfügung, damit Sie sichere und funktionale Richtlinien erstellen können. Weitere Informationen finden Sie unter [Richtlinienvalidierung mit IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) im *IAM-Benutzerhandbuch*.
+ **Multi-Faktor-Authentifizierung (MFA) erforderlich** — Wenn Sie ein Szenario haben, das IAM-Benutzer oder einen Root-Benutzer in Ihrem System erfordert AWS-Konto, aktivieren Sie MFA für zusätzliche Sicherheit. Um MFA beim Aufrufen von API-Vorgängen anzufordern, fügen Sie Ihren Richtlinien MFA-Bedingungen hinzu. Weitere Informationen finden Sie unter [Sicherer API-Zugriff mit MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) im *IAM-Benutzerhandbuch*.

Weitere Informationen zu bewährten Methoden in IAM finden Sie unter [Best Practices für die Sicherheit in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) im *IAM-Benutzerhandbuch*.

## Verwenden der Aurora DSQL-Konsole
<a name="security_iam_id-based-policy-examples-console"></a>

Sie müssen über einen Mindestsatz von Berechtigungen verfügen, um auf die Amazon Aurora DSQL-Konsole zugreifen zu können. Diese Berechtigungen müssen es Ihnen ermöglichen, Details zu den Aurora DSQL-Ressourcen in Ihrem AWS-Konto aufzulisten und anzuzeigen. Wenn Sie eine identitätsbasierte Richtlinie erstellen, die strenger ist als die mindestens erforderlichen Berechtigungen, funktioniert die Konsole nicht wie vorgesehen für Entitäten (Benutzer oder Rollen) mit dieser Richtlinie.

Sie müssen Benutzern, die nur die API AWS CLI oder die AWS API aufrufen, keine Mindestberechtigungen für die Konsole gewähren. Stattdessen sollten Sie nur Zugriff auf die Aktionen zulassen, die der API-Operation entsprechen, die die Benutzer ausführen möchten.

Um sicherzustellen, dass Benutzer und Rollen die Aurora DSQL-Konsole weiterhin verwenden können, fügen Sie den Entitäten auch die Aurora DSQL `AmazonAuroraDSQLConsoleFullAccess` - oder `AmazonAuroraDSQLReadOnlyAccess` AWS verwaltete Richtlinie hinzu. Weitere Informationen finden Sie unter [Hinzufügen von Berechtigungen zu einem Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) im *IAM-Benutzerhandbuch*.

## Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer
<a name="security_iam_id-based-policy-examples-view-own-permissions"></a>

In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen, die IAM-Benutzern die Berechtigung zum Anzeigen der eingebundenen Richtlinien und verwalteten Richtlinien gewährt, die ihrer Benutzeridentität angefügt sind. Diese Richtlinie beinhaltet Berechtigungen zum Ausführen dieser Aktion auf der Konsole oder programmgesteuert mithilfe der OR-API. AWS CLI AWS 

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}
```

## Clusterverwaltung und Datenbankverbindung zulassen
<a name="security_iam_id-based-policy-examples-cluster-management"></a>

Die folgende Richtlinie gewährt einem IAM-Benutzer die Berechtigung, einen bestimmten Aurora DSQL-Cluster zu verwalten und eine Verbindung zu diesem herzustellen. Die Richtlinie erstreckt sich auf Clusterverwaltung und Verbindungsaktionen auf einen einzelnen Cluster mit Amazon Resource Name (ARN), lässt aber alle Ressourcen zu, da diese Aktion keine Berechtigungen `dsql:ListClusters` auf Ressourcenebene unterstützt.

In diesem Beispiel wird eine `dsql:DbConnectAdmin` Verbindung mit der Rolle hergestellt. `admin` Um stattdessen eine Verbindung mit einer benutzerdefinierten Datenbankrolle herzustellen, `dsql:DbConnectAdmin` ersetzen Sie durch`dsql:DbConnect`. Weitere Informationen finden Sie unter [Authentifizierung und Autorisierung für Aurora DSQL](authentication-authorization.md).

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowClusterManagement",
            "Effect": "Allow",
            "Action": [
                "dsql:GetCluster",
                "dsql:UpdateCluster",
                "dsql:DeleteCluster",
                "dsql:DbConnectAdmin",
                "dsql:TagResource",
                "dsql:ListTagsForResource",
                "dsql:UntagResource"
            ],
            "Resource": "arn:aws:dsql:*:123456789012:cluster/my-cluster-id"
        },
        {
            "Sid": "AllowListClusters",
            "Effect": "Allow",
            "Action": "dsql:ListClusters",
            "Resource": "*"
        }
    ]
}
```

------

## Aurora DSQL-Ressourcenzugriff basierend auf Tags
<a name="security_iam_id-based-policy-examples-tag-based-access"></a>

Sie können Bedingungen in Ihrer identitätsbasierten Richtlinie verwenden, um den Zugriff auf Aurora DSQL-Ressourcen anhand von Tags zu steuern. Das folgende Beispiel zeigt, wie Sie eine Richtlinie erstellen können, die die Anzeige eines Clusters ermöglicht. Die Richtlinie gewährt jedoch nur dann Berechtigungen, wenn das Cluster-Tag den Wert des Benutzernamens dieses Benutzers `Owner` hat. Diese Richtlinie gewährt auch die Berechtigungen, die für die Ausführung dieser Aktion auf der Konsole erforderlich sind.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ListClustersInConsole",
            "Effect": "Allow",
            "Action": "dsql:ListClusters",
            "Resource": "*"
        },
        {
            "Sid": "ViewClusterIfOwner",
            "Effect": "Allow",
            "Action": "dsql:GetCluster",
            "Resource": "arn:aws:dsql:*:*:cluster/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Owner": "${aws:username}"
                }
            }
        }
    ]
}
```

------

Sie können diese Richtlinie den IAM-Benutzern in Ihrem Konto anfügen. Wenn ein benannter Benutzer `richard-roe` versucht, einen Aurora DSQL-Cluster aufzurufen, muss der Cluster mit `Owner=richard-roe` oder `owner=richard-roe` gekennzeichnet werden. Andernfalls verweigert IAM den Zugriff. Der Tag-Schlüssel `Owner` der Bedingung stimmt sowohl mit `Owner` als auch mit `owner` überein, da die Namen von Bedingungsschlüsseln nicht zwischen Groß- und Kleinschreibung unterscheiden. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*.

Die folgende Richtlinie ermöglicht es einem Benutzer, Cluster nur zu erstellen, wenn er den Cluster mit seinem eigenen Benutzernamen als kennzeichnet. `Owner` Außerdem erlaubt sie das Tagging nur für Cluster, die der Benutzer bereits besitzt.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCreateTaggedCluster",
            "Effect": "Allow",
            "Action": "dsql:CreateCluster",
            "Resource": "arn:aws:dsql:*:123456789012:cluster/*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/Owner": "${aws:username}"
                }
            }
        },
        {
            "Sid": "AllowTagOwnedClusters",
            "Effect": "Allow",
            "Action": "dsql:TagResource",
            "Resource": "arn:aws:dsql:*:123456789012:cluster/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Owner": "${aws:username}"
                }
            }
        }
    ]
}
```

------







# Fehlerbehebung für Amazon Aurora DSQL-Identität und -Zugriff
<a name="security_iam_troubleshoot"></a>

Verwenden Sie die folgenden Informationen, um häufige Probleme zu diagnostizieren und zu beheben, die beim Arbeiten mit Aurora DSQL und IAM auftreten könnten.

**Topics**
+ [Ich bin nicht autorisiert, eine Aktion in Aurora DSQL auszuführen.](#security_iam_troubleshoot-no-permissions)
+ [Ich bin nicht berechtigt, iam auszuführen: PassRole](#security_iam_troubleshoot-passrole)
+ [Ich möchte Personen außerhalb von mir den Zugriff AWS-Konto auf meine Aurora DSQL-Ressourcen ermöglichen](#security_iam_troubleshoot-cross-account-access)

## Ich bin nicht autorisiert, eine Aktion in Aurora DSQL auszuführen.
<a name="security_iam_troubleshoot-no-permissions"></a>

Wenn Sie eine Fehlermeldung erhalten, dass Sie nicht zur Durchführung einer Aktion berechtigt sind, müssen Ihre Richtlinien aktualisiert werden, damit Sie die Aktion durchführen können.

Der folgende Beispielfehler tritt auf, wenn ein `mateojackson` versucht, über die Konsole Details zu der `my-dsql-cluster`-Ressource anzuzeigen, jedoch nicht über die entsprechenden `GetCluster`-Berechtigungen verfügt.

```
User: iam:::user/mateojackson is not authorized to perform: GetCluster on resource: my-dsql-cluster
```

In diesem Fall muss die Richtlinie für den Benutzer `mateojackson` aktualisiert werden, damit er mit der `GetCluster`-Aktion auf die `my-dsql-cluster`-Ressource zugreifen kann.

Wenden Sie sich an Ihren -Administrator, falls Sie weitere Unterstützung benötigen. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.

## Ich bin nicht berechtigt, iam auszuführen: PassRole
<a name="security_iam_troubleshoot-passrole"></a>

Wenn Sie eine Fehlermeldung erhalten, dass Sie nicht berechtigt sind, eine `iam:PassRole`-Aktion auszuführen, müssen Ihre Richtlinien aktualisiert werden, um eine Rolle an Aurora DSQL übergeben zu können.

Einige AWS-Services ermöglichen es Ihnen, eine bestehende Rolle an diesen Dienst zu übergeben, anstatt eine neue Servicerolle oder eine dienstverknüpfte Rolle zu erstellen. Hierzu benötigen Sie Berechtigungen für die Übergabe der Rolle an den Dienst.

Der folgende Beispielfehler tritt auf, wenn ein IAM-Benutzer mit dem Namen `marymajor` versucht, die Konsole zu verwenden, um eine Aktion in Aurora DSQL auszuführen. Die Aktion erfordert jedoch, dass der Service über Berechtigungen verfügt, die durch eine Servicerolle gewährt werden. Mary besitzt keine Berechtigungen für die Übergabe der Rolle an den Dienst.

```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```

In diesem Fall müssen die Richtlinien von Mary aktualisiert werden, um die Aktion `iam:PassRole` ausführen zu können.

Wenn Sie Hilfe benötigen, wenden Sie sich an Ihren AWS Administrator. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.

## Ich möchte Personen außerhalb von mir den Zugriff AWS-Konto auf meine Aurora DSQL-Ressourcen ermöglichen
<a name="security_iam_troubleshoot-cross-account-access"></a>

Sie können eine Rolle erstellen, mit der Benutzer in anderen Konten oder Personen außerhalb Ihrer Organisation auf Ihre Ressourcen zugreifen können. Sie können festlegen, wem die Übernahme der Rolle anvertraut wird. Für Dienste, die ressourcenbasierte Richtlinien oder Zugriffskontrolllisten (ACLs) unterstützen, können Sie diese Richtlinien verwenden, um Personen Zugriff auf Ihre Ressourcen zu gewähren.

Weitere Informationen dazu finden Sie hier:
+ Informationen dazu, ob Aurora DSQL diese Features unterstützt, finden Sie unter [Funktionsweise von Amazon Aurora DSQL mit IAM](security_iam_service-with-iam.md).
+ *Informationen dazu, wie Sie Zugriff auf Ihre Ressourcen in AWS-Konten Ihrem Besitz gewähren können, finden Sie im IAM-Benutzerhandbuch unter [Gewähren des Zugriffs für einen IAM-Benutzer in einem anderen AWS-Konto , dem Sie](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) gehören.*
+ Informationen dazu, wie Sie Dritten Zugriff auf Ihre Ressourcen gewähren können AWS-Konten, finden Sie [AWS-Konten im *IAM-Benutzerhandbuch* unter Gewähren des Zugriffs für Dritte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html).
+ Informationen dazu, wie Sie über einen Identitätsverbund Zugriff gewähren, finden Sie unter [Gewähren von Zugriff für extern authentifizierte Benutzer (Identitätsverbund)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) im *IAM-Benutzerhandbuch*.
+ Informationen zum Unterschied zwischen der Verwendung von Rollen und ressourcenbasierten Richtlinien für den kontoübergreifenden Zugriff finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.

# Ressourcenbasierte Richtlinien für Aurora DSQL
<a name="resource-based-policies"></a>

Verwenden Sie ressourcenbasierte Richtlinien für Aurora DSQL, um den Zugriff auf Ihre Cluster mithilfe von JSON-Richtliniendokumenten einzuschränken oder zu gewähren, die direkt mit Ihren Clusterressourcen verknüpft sind. Diese Richtlinien bieten eine detaillierte Kontrolle darüber, wer unter welchen Bedingungen auf Ihren Cluster zugreifen kann.

Aurora DSQL-Cluster sind standardmäßig über das öffentliche Internet zugänglich, wobei die IAM-Authentifizierung die primäre Sicherheitskontrolle ist. Mithilfe ressourcenbasierter Richtlinien können Sie Zugriffsbeschränkungen hinzufügen, insbesondere um den Zugriff über das öffentliche Internet zu blockieren.

Ressourcenbasierte Richtlinien arbeiten mit identitätsbasierten IAM-Richtlinien zusammen. AWS bewertet beide Arten von Richtlinien, um die endgültigen Berechtigungen für jede Zugriffsanfrage auf Ihren Cluster zu ermitteln. Standardmäßig sind Aurora DSQL-Cluster innerhalb eines Kontos zugänglich. Wenn ein IAM-Benutzer oder eine IAM-Rolle über Aurora DSQL-Berechtigungen verfügt, kann er auf Cluster zugreifen, ohne dass eine ressourcenbasierte Richtlinie angehängt ist.

**Anmerkung**  
Änderungen an ressourcenbasierten Richtlinien sind letztlich konsistent und werden in der Regel innerhalb einer Minute wirksam.

*Weitere Informationen zu den Unterschieden zwischen identitätsbasierten und ressourcenbasierten Richtlinien finden Sie unter [Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) im IAM-Benutzerhandbuch.*

## Wann sollten ressourcenbasierte Richtlinien verwendet werden
<a name="rbp-when-to-use"></a>

Ressourcenbasierte Richtlinien sind in diesen Szenarien besonders nützlich:
+ *Netzwerkbasierte Zugriffskontrolle* — Beschränken Sie den Zugriff auf der Grundlage der VPC oder IP-Adresse, von der Anfragen stammen, oder blockieren Sie den öffentlichen Internetzugang vollständig. Verwenden Sie Bedingungsschlüssel wie `aws:SourceVpc` und`aws:SourceIp`, um den Netzwerkzugriff zu kontrollieren.
+ *Mehrere Teams oder Anwendungen* — Gewähren Sie mehreren Teams oder Anwendungen Zugriff auf denselben Cluster. Anstatt einzelne IAM-Richtlinien für jeden Prinzipal zu verwalten, definieren Sie Zugriffsregeln nur einmal im Cluster.
+ *Komplexer bedingter Zugriff* — Steuern Sie den Zugriff auf der Grundlage mehrerer Faktoren wie Netzwerkattributen, Anforderungskontext und Benutzerattributen. Sie können mehrere Bedingungen in einer einzigen Richtlinie kombinieren.
+ *Zentralisierte Sicherheitssteuerung* — Ermöglichen Sie es Cluster-Besitzern, den Zugriff mithilfe einer vertrauten AWS Richtliniensyntax zu kontrollieren, die sich in Ihre bestehenden Sicherheitspraktiken einfügt.

**Anmerkung**  
Kontoübergreifender Zugriff wird für ressourcenbasierte Aurora DSQL-Richtlinien noch nicht unterstützt, wird aber in future Versionen verfügbar sein.

Wenn jemand versucht, eine Verbindung zu Ihrem Aurora DSQL-Cluster herzustellen, AWS bewertet Ihre ressourcenbasierte Richtlinie als Teil des Autorisierungskontextes zusammen mit allen relevanten IAM-Richtlinien, um festzustellen, ob die Anfrage zugelassen oder abgelehnt werden soll.

Ressourcenbasierte Richtlinien können Prinzipalen Zugriff gewähren, die sich innerhalb desselben Kontos wie der Cluster befinden. AWS Bei Clustern mit mehreren Regionen hat jeder regionale Cluster seine eigene ressourcenbasierte Richtlinie, die bei Bedarf regionsspezifische Zugriffskontrollen ermöglicht.

**Anmerkung**  
Bedingungskontextschlüssel können je nach Region variieren (z. B. VPC IDs).

**Topics**
+ [Wann sollte dies verwendet werden?](#rbp-when-to-use)
+ [Mit Richtlinien erstellen](rbp-create-cluster.md)
+ [Richtlinien hinzufügen und bearbeiten](rbp-attach-policy.md)
+ [Richtlinie anzeigen](rbp-view-policy.md)
+ [Richtlinie entfernen](rbp-remove-policy.md)
+ [Beispiele für Richtlinien](rbp-examples.md)
+ [Blockieren des öffentlichen Zugriffs](rbp-block-public-access.md)
+ [API-Operationen](rbp-api-operations.md)

# Cluster mit ressourcenbasierten Richtlinien erstellen
<a name="rbp-create-cluster"></a>

Sie können beim Erstellen eines neuen Clusters ressourcenbasierte Richtlinien anhängen, um sicherzustellen, dass die Zugriffskontrollen von Anfang an vorhanden sind. Jedem Cluster kann eine einzelne Inline-Richtlinie direkt an den Cluster angehängt werden.

## AWS Management-Konsole
<a name="rbp-create-cluster-console"></a>

**Um bei der Clustererstellung eine ressourcenbasierte Richtlinie hinzuzufügen**

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Aurora DSQL-Konsole unter [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).

1. Wählen Sie **Cluster erstellen**.

1. Konfigurieren Sie Ihren Clusternamen, Ihre Tags und Einstellungen für mehrere Regionen nach Bedarf.

1. Suchen Sie im Abschnitt **Clustereinstellungen** nach der Option **Ressourcenbasierte Richtlinie**.

1. Aktivieren Sie die Option **Ressourcenbasierte Richtlinie hinzufügen**.

1. Geben Sie Ihr Richtliniendokument im JSON-Editor ein. Um beispielsweise den öffentlichen Internetzugang zu blockieren:

   ```
   {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Deny",
         "Principal": {
           "AWS": "*"
         },
         "Resource": "*",
         "Action": [
           "dsql:DbConnect",
           "dsql:DbConnectAdmin"
         ],
         "Condition": {
           "Null": {
             "aws:SourceVpc": "true"
           }
         }
       }
     ]
   }
   ```

1. Sie können die Option **Aussage bearbeiten** oder **Neue Erklärung hinzufügen** verwenden, um Ihre Richtlinie zu erstellen.

1. Schließen Sie die verbleibende Clusterkonfiguration ab und wählen Sie **Create cluster** aus.

## AWS CLI
<a name="rbp-create-cluster-cli"></a>

Verwenden Sie den `--policy` Parameter beim Erstellen eines Clusters, um eine Inline-Richtlinie anzuhängen:

```
aws dsql create-cluster --policy '{
    "Version": "2012-10-17",		 	 	 
    "Statement": [{
        "Effect": "Deny",
        "Principal": {"AWS": "*"},
        "Resource": "*",
        "Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
        "Condition": { 
            "StringNotEquals": { "aws:SourceVpc": "vpc-123456" } 
        }
    }]
}'
```

## AWS SDKs
<a name="rbp-create-cluster-sdk"></a>

------
#### [ Python ]

```
import boto3
import json

client = boto3.client('dsql')

policy = {
    "Version": "2012-10-17",		 	 	 
    "Statement": [{
        "Effect": "Deny",
        "Principal": {"AWS": "*"},
        "Resource": "*",
        "Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
        "Condition": { 
            "StringNotEquals": { "aws:SourceVpc": "vpc-123456" } 
        }
    }]
}

response = client.create_cluster(
    policy=json.dumps(policy)
)

print(f"Cluster created: {response['identifier']}")
```

------
#### [ Java ]

```
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.CreateClusterRequest;
import software.amazon.awssdk.services.dsql.model.CreateClusterResponse;

DsqlClient client = DsqlClient.create();

String policy = """
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Deny",
    "Principal": {"AWS": "*"},
    "Resource": "*",
    "Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
    "Condition": { 
      "StringNotEquals": { "aws:SourceVpc": "vpc-123456" } 
    }
  }]
}
""";

CreateClusterRequest request = CreateClusterRequest.builder()
    .policy(policy)
    .build();

CreateClusterResponse response = client.createCluster(request);
System.out.println("Cluster created: " + response.identifier());
```

------

# Hinzufügen und Bearbeiten ressourcenbasierter Richtlinien für Cluster
<a name="rbp-attach-policy"></a>

## AWS Management-Konsole
<a name="rbp-attach-console"></a>

**Um einem vorhandenen Cluster eine ressourcenbasierte Richtlinie hinzuzufügen**

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Aurora DSQL-Konsole unter [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).

1. Wählen Sie Ihren Cluster aus der Cluster-Liste aus, um die Cluster-Detailseite zu öffnen.

1. Wählen Sie die Registerkarte **Berechtigungen**.

1. Wählen Sie im Abschnitt **Ressourcenbasierte Richtlinie die** Option Richtlinie **hinzufügen** aus.

1. Geben Sie Ihr Richtliniendokument im JSON-Editor ein. Sie können die Option **Erklärung bearbeiten** oder **Neue Erklärung hinzufügen** verwenden, um Ihre Richtlinie zu erstellen.

1. Wählen Sie **Richtlinie hinzufügen** aus.

**Um eine bestehende ressourcenbasierte Richtlinie zu bearbeiten**

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Aurora DSQL-Konsole unter [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).

1. Wählen Sie Ihren Cluster aus der Cluster-Liste aus, um die Cluster-Detailseite zu öffnen.

1. Wählen Sie die Registerkarte **Berechtigungen**.

1. **Wählen Sie im Abschnitt **Ressourcenbasierte Richtlinie die** Option Bearbeiten aus.**

1. Ändern Sie das Richtliniendokument im JSON-Editor. Sie können die Option **Erklärung bearbeiten** oder **Neue Erklärung hinzufügen** verwenden, um Ihre Richtlinie zu aktualisieren.

1. Wählen Sie **Änderungen speichern ** aus.

## AWS CLI
<a name="rbp-attach-cli"></a>

Verwenden Sie den `put-cluster-policy` Befehl, um eine neue Richtlinie anzuhängen oder eine bestehende Richtlinie auf einem Cluster zu aktualisieren:

```
aws dsql put-cluster-policy --identifier your_cluster_id --policy '{
    "Version": "2012-10-17",		 	 	 
    "Statement": [{
        "Effect": "Deny",
        "Principal": {"AWS": "*"},
        "Resource": "*",
        "Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
        "Condition": { 
            "Null": { "aws:SourceVpc": "true" } 
        }
    }]
}'
```

## AWS SDKs
<a name="rbp-attach-sdk"></a>

------
#### [ Python ]

```
import boto3
import json

client = boto3.client('dsql')

policy = {
    "Version": "2012-10-17",		 	 	 
    "Statement": [{
        "Effect": "Deny",
        "Principal": {"AWS": "*"},
        "Resource": "*",
        "Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
        "Condition": {
            "Null": {"aws:SourceVpc": "true"}
        }
    }]
}

response = client.put_cluster_policy(
    identifier='your_cluster_id',
    policy=json.dumps(policy)
)
```

------
#### [ Java ]

```
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.PutClusterPolicyRequest;

DsqlClient client = DsqlClient.create();

String policy = """
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Deny",
    "Principal": {"AWS": "*"},
    "Resource": "*",
    "Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
    "Condition": {
      "Null": {"aws:SourceVpc": "true"}
    }
  }]
}
""";

PutClusterPolicyRequest request = PutClusterPolicyRequest.builder()
    .identifier("your_cluster_id")
    .policy(policy)
    .build();

client.putClusterPolicy(request);
```

------

# Ressourcenbasierte Richtlinien anzeigen
<a name="rbp-view-policy"></a>

Sie können sich die ressourcenbasierten Richtlinien ansehen, die Ihren Clustern zugeordnet sind, um sich über die aktuellen Zugriffskontrollen zu informieren.

## AWS Management-Konsole
<a name="rbp-view-console"></a>

**Um ressourcenbasierte Richtlinien anzuzeigen**

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Aurora DSQL-Konsole unter [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).

1. Wählen Sie Ihren Cluster aus der Cluster-Liste aus, um die Cluster-Detailseite zu öffnen.

1. Wählen Sie die Registerkarte **Berechtigungen**.

1. Sehen Sie sich die beigefügte Richtlinie im **Abschnitt Ressourcenbasierte Richtlinie** an.

## AWS CLI
<a name="rbp-view-cli"></a>

Verwenden Sie den `get-cluster-policy` Befehl, um die ressourcenbasierte Richtlinie eines Clusters anzuzeigen:

```
aws dsql get-cluster-policy --identifier your_cluster_id
```

## AWS SDKs
<a name="rbp-view-sdk"></a>

------
#### [ Python ]

```
import boto3
import json

client = boto3.client('dsql')

response = client.get_cluster_policy(
    identifier='your_cluster_id'
)

# Parse and pretty-print the policy
policy = json.loads(response['policy'])
print(json.dumps(policy, indent=2))
```

------
#### [ Java ]

```
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.GetClusterPolicyRequest;
import software.amazon.awssdk.services.dsql.model.GetClusterPolicyResponse;

DsqlClient client = DsqlClient.create();

GetClusterPolicyRequest request = GetClusterPolicyRequest.builder()
    .identifier("your_cluster_id")
    .build();

GetClusterPolicyResponse response = client.getClusterPolicy(request);
System.out.println("Policy: " + response.policy());
```

------

# Entfernen ressourcenbasierter Richtlinien
<a name="rbp-remove-policy"></a>

Sie können ressourcenbasierte Richtlinien aus Clustern entfernen, um die Zugriffskontrollen zu ändern.

**Wichtig**  
Wenn Sie alle ressourcenbasierten Richtlinien aus einem Cluster entfernen, wird der Zugriff vollständig durch identitätsbasierte IAM-Richtlinien gesteuert.

## AWS Management-Konsole
<a name="rbp-remove-console"></a>

**Um eine ressourcenbasierte Richtlinie zu entfernen**

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Aurora DSQL-Konsole unter [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).

1. Wählen Sie Ihren Cluster aus der Cluster-Liste aus, um die Cluster-Detailseite zu öffnen.

1. Wählen Sie die Registerkarte **Berechtigungen**.

1. **Wählen Sie im Abschnitt **Ressourcenbasierte Richtlinie die** Option Löschen aus.**

1. Geben Sie im Bestätigungsdialogfeld ein, **confirm** um den Löschvorgang zu bestätigen.

1. Wählen Sie **Löschen** aus.

## AWS CLI
<a name="rbp-remove-cli"></a>

Verwenden Sie den `delete-cluster-policy` Befehl, um eine Richtlinie aus einem Cluster zu entfernen:

```
aws dsql delete-cluster-policy --identifier your_cluster_id
```

## AWS SDKs
<a name="rbp-remove-sdk"></a>

------
#### [ Python ]

```
import boto3

client = boto3.client('dsql')

response = client.delete_cluster_policy(
    identifier='your_cluster_id'
)

print("Policy deleted successfully")
```

------
#### [ Java ]

```
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.DeleteClusterPolicyRequest;

DsqlClient client = DsqlClient.create();

DeleteClusterPolicyRequest request = DeleteClusterPolicyRequest.builder()
    .identifier("your_cluster_id")
    .build();

client.deleteClusterPolicy(request);
System.out.println("Policy deleted successfully");
```

------

# Allgemeine Beispiele für ressourcenbasierte Richtlinien
<a name="rbp-examples"></a>

Diese Beispiele zeigen gängige Muster für die Steuerung des Zugriffs auf Ihre Aurora DSQL-Cluster. Sie können diese Muster kombinieren und ändern, um Ihre spezifischen Zugriffsanforderungen zu erfüllen.

## Sperren Sie den öffentlichen Internetzugang
<a name="rbp-example-block-public"></a>

Diese Richtlinie blockiert Verbindungen zu Ihren Aurora DSQL-Clustern aus dem öffentlichen Internet (ohne VPC). Die Richtlinie legt nicht fest, von welcher VPC Kunden eine Verbindung herstellen können, sondern nur, dass sie sich von einer VPC aus verbinden müssen. Um den Zugriff auf eine bestimmte VPC zu beschränken, verwenden Sie ihn `aws:SourceVpc` zusammen mit dem `StringEquals` Bedingungsoperator.

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Resource": "*",
      "Action": [
        "dsql:DbConnect",
        "dsql:DbConnectAdmin"
      ],
      "Condition": {
        "Null": {
          "aws:SourceVpc": "true"
        }
      }
    }
  ]
}
```

**Anmerkung**  
In diesem Beispiel wird nur `aws:SourceVpc` nach VPC-Verbindungen gesucht. Die Schlüssel `aws:VpcSourceIp` und `aws:SourceVpce` Condition bieten zusätzliche Granularität, sind aber für die grundlegende reine VPC-Zugriffskontrolle nicht erforderlich.

Verwenden Sie stattdessen diese Richtlinie, um eine Ausnahme für bestimmte Rollen bereitzustellen:

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "DenyAccessFromOutsideVPC",
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Resource": "*",
      "Action": [
        "dsql:DbConnect",
        "dsql:DbConnectAdmin"
      ],
      "Condition": {
        "Null": {
          "aws:SourceVpc": "true"
        },
        "StringNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::123456789012:role/ExceptionRole",
            "arn:aws:iam::123456789012:role/AnotherExceptionRole"
          ]
        }
      }
    }
  ]
}
```

## Beschränken Sie den Zugriff auf die AWS Organisation
<a name="rbp-example-org-access"></a>

Diese Richtlinie schränkt den Zugriff auf Prinzipale innerhalb einer Organisation ein AWS :

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "dsql:DbConnect",
        "dsql:DbConnectAdmin"
      ],
      "Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/mydsqlclusterid0123456789a",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-exampleorgid"
        }
      }
    }
  ]
}
```

## Beschränken Sie den Zugriff auf eine bestimmte Organisationseinheit
<a name="rbp-example-ou-access"></a>

Diese Richtlinie schränkt den Zugriff auf Prinzipale innerhalb einer bestimmten Organisationseinheit (OU) in einer AWS Organisation ein und bietet so eine detailliertere Kontrolle als der organisationsweite Zugriff:

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "dsql:DbConnect"
      ],
      "Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/mydsqlclusterid0123456789a",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalOrgPaths": "o-exampleorgid/r-examplerootid/ou-exampleouid/*"
        }
      }
    }
  ]
}
```

## Clusterrichtlinien für mehrere Regionen
<a name="rbp-example-multi-region"></a>

Bei Clustern mit mehreren Regionen unterhält jeder regionale Cluster seine eigene Ressourcenpolitik, die regionsspezifische Kontrollen ermöglicht. Hier ist ein Beispiel mit unterschiedlichen Richtlinien pro Region:

*US-Ost-1-Politik:*

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Resource": "*",
      "Action": [
        "dsql:DbConnect"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpc": "vpc-east1-id"
        },
        "Null": {
          "aws:SourceVpc": "true"
        }
      }
    }
  ]
}
```

*US-Ost-2-Politik:*

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Resource": "*",
      "Action": [
        "dsql:DbConnect"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "vpc-east2-id"
        }
      }
    }
  ]
}
```

**Anmerkung**  
Die Schlüssel für den Bedingungskontext können zwischen diesen variieren AWS-Regionen (z. B. VPC IDs).

# Blockieren des öffentlichen Zugriffs mit ressourcenbasierten Richtlinien in Aurora DSQL
<a name="rbp-block-public-access"></a>

Block Public Access (BPA) ist eine Funktion, die das Anhängen von ressourcenbasierten Richtlinien, die öffentlichen Zugriff auf Ihre Aurora DSQL-Cluster über Ihre Konten gewähren, identifiziert und verhindert. AWS Mit BPA können Sie den öffentlichen Zugriff auf Ihre Aurora DSQL-Ressourcen verhindern. BPA führt während der Erstellung oder Änderung einer ressourcenbasierten Richtlinie Prüfungen durch und hilft Ihnen, Ihre Sicherheitslage mit Aurora DSQL zu verbessern.

BPA analysiert mittels [Automated Reasoning](https://aws.amazon.com/what-is/automated-reasoning/) den durch Ihre ressourcenbasierte Richtlinie gewährten Zugriff und warnt Sie, wenn solche Berechtigungen zum Zeitpunkt der Verwaltung einer ressourcenbasierten Richtlinie gefunden werden. Bei der Analyse wird der Zugriff über alle ressourcenbasierten Richtlinienanweisungen, Aktionen und die in Ihren Richtlinien verwendeten Bedingungsschlüssel überprüft.

**Wichtig**  
BPA trägt zum Schutz Ihrer Ressourcen bei, indem verhindert wird, dass öffentlicher Zugriff über die ressourcenbasierten Richtlinien gewährt wird, die direkt mit Ihren Aurora DSQL-Ressourcen wie Clustern verknüpft sind. Überprüfen Sie zusätzlich zur Aktivierung von BPA sorgfältig die folgenden Richtlinien, um sicherzustellen, dass sie keinen öffentlichen Zugriff gewähren:  
Identitätsbasierte Richtlinien, die mit zugehörigen AWS Principals verknüpft sind (z. B. IAM-Rollen)
Ressourcenbasierte Richtlinien, die mit zugehörigen AWS Ressourcen verknüpft sind (z. B. AWS Key Management Service (KMS) -Schlüssel)

Sie müssen sicherstellen, dass der [Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) keinen `*`-Eintrag enthält oder dass keiner der angegebenen Bedingungsschlüssel den Zugriff der Prinzipale auf die Ressource einschränkt. Wenn die ressourcenbasierte Richtlinie AWS kontenübergreifend öffentlichen Zugriff auf Ihren Cluster gewährt, blockiert Aurora DSQL Sie daran, die Richtlinie zu erstellen oder zu ändern, bis die Spezifikation in der Richtlinie korrigiert und als nicht öffentlich eingestuft wurde.

Sie können eine Richtlinie als nicht öffentlich festlegen, indem Sie einen oder mehrere Prinzipale im `Principal`-Block angeben. Im folgenden Beispiel für eine ressourcenbasierte Richtlinie wird der öffentliche Zugriff blockiert, indem zwei Prinzipale angegeben werden.

```
{
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "123456789012",
      "111122223333"
    ]
  },
  "Action": "dsql:*",
  "Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/cluster-id"
}
```

Richtlinien, die den Zugriff durch die Angabe bestimmter Bedingungsschlüssel einschränken, gelten ebenfalls nicht als öffentlich. Neben der Auswertung des in der ressourcenbasierten Richtlinie angegebenen Prinzipals werden die folgenden [vertrauenswürdigen Bedingungsschlüssel](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) verwendet, um die Auswertung einer ressourcenbasierten Richtlinie für den nicht öffentlichen Zugriff abzuschließen:
+ `aws:PrincipalAccount`
+ `aws:PrincipalArn`
+ `aws:PrincipalOrgID`
+ `aws:PrincipalOrgPaths`
+ `aws:SourceAccount`
+ `aws:SourceArn`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:UserId`
+ `aws:PrincipalServiceName`
+ `aws:PrincipalServiceNamesList`
+ `aws:PrincipalIsAWSService`
+ `aws:Ec2InstanceSourceVpc`
+ `aws:SourceOrgID`
+ `aws:SourceOrgPaths`

Damit eine ressourcenbasierte Richtlinie nicht öffentlich ist, dürfen die Werte für den Amazon-Ressourcennamen (ARN) und Zeichenfolgenschlüssel außerdem keine Platzhalter oder Variablen enthalten. Wenn Ihre ressourcenbasierte Richtlinie den `aws:PrincipalIsAWSService`-Schlüssel verwendet, müssen Sie sicherstellen, dass Sie den Schlüsselwert auf „true“ gesetzt haben.

Die folgende Richtlinie grenzt den Zugriff auf den Benutzer `Ben` im angegebenen Konto ein. Aufgrund dieser Bedingung ist der `Principal` eingeschränkt und wird als nicht öffentlich betrachtet.

```
{
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": "dsql:*",
  "Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/cluster-id",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalArn": "arn:aws:iam::123456789012:user/Ben"
    }
  }
}
```

Das folgende Beispiel für eine nicht öffentliche ressourcenbasierte Richtlinie schränkt `sourceVPC` auf die Verwendung des `StringEquals`-Operators ein.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "dsql:*",
      "Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/cluster-id",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": [
            "vpc-91237329"
          ]
        }
      }
    }
  ]
}
```

# Aurora DSQL API-Operationen und ressourcenbasierte Richtlinien
<a name="rbp-api-operations"></a>

Ressourcenbasierte Richtlinien in Aurora DSQL steuern den Zugriff auf bestimmte API-Operationen. In den folgenden Abschnitten sind alle Aurora DSQL-API-Operationen nach Kategorien geordnet aufgeführt, mit Angabe, welche Operationen ressourcenbasierte Richtlinien unterstützen.

Die Spalte *Unterstützt RBP* gibt an, ob der API-Vorgang einer ressourcenbasierten Richtlinienbewertung unterzogen wird, wenn eine Richtlinie an den Cluster angehängt wird.

## Tag APIs
<a name="rbp-tag-apis"></a>


| API-Operation | Description | Unterstützt RBP | 
| --- | --- | --- | 
| [ListTagsForResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_ListTagsForResource.html) | Listet die Tags für eine Aurora DSQL-Ressource auf | Ja | 
| [TagResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_TagResource.html) | Fügt einer Aurora DSQL-Ressource Tags hinzu | Ja | 
| [UntagResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UntagResource.html) | Entfernt Tags aus einer Aurora DSQL-Ressource | Ja | 

## Cluster-Verwaltung APIs
<a name="rbp-cluster-management-apis"></a>


| API-Operation | Description | Unterstützt RBP | 
| --- | --- | --- | 
| [CreateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_CreateCluster.html) | Erstellt einen Cluster | Nein | 
| [DeleteCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_DeleteCluster.html) | Löscht einen Cluster | Ja | 
| [GetCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetCluster.html) | Ruft Informationen über einen Cluster ab | Ja | 
| [GetVpcEndpointServiceName](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetVpcEndpointServiceName.html) | Ruft den VPC-Endpunktdienstnamen für einen Cluster ab | Ja | 
| [ListClusters](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_ListClusters.html) | Listet Cluster in Ihrem Konto auf | Nein | 
| [UpdateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UpdateCluster.html) | Aktualisiert die Konfiguration eines Clusters | Ja | 

## Eigenschaft für mehrere Regionen APIs
<a name="rbp-multi-region-apis"></a>


| API-Operation | Description | Unterstützt RBP | 
| --- | --- | --- | 
| [AddPeerCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_AddPeerCluster.html) | Fügt einer Konfiguration mit mehreren Regionen einen Peer-Cluster hinzu | Ja | 
| [PutMultiRegionProperties](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutMultiRegionProperties.html) | Legt Eigenschaften für mehrere Regionen für einen Cluster fest | Ja | 
| [PutWitnessRegion](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutWitnessRegion.html) | Legt die Zeugenregion für einen Cluster mit mehreren Regionen fest | Ja | 

## Ressourcenbasierte Richtlinie APIs
<a name="rbp-policy-apis"></a>


| API-Operation | Description | Unterstützt RBP | 
| --- | --- | --- | 
| [DeleteClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_DeleteClusterPolicy.html) | Löscht die ressourcenbasierte Richtlinie aus einem Cluster | Ja | 
| [GetClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetClusterPolicy.html) | Ruft die ressourcenbasierte Richtlinie für einen Cluster ab | Ja | 
| [PutClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutClusterPolicy.html) | Erstellt oder aktualisiert die ressourcenbasierte Richtlinie für einen Cluster | Ja | 

## AWS Fault Injection Service APIs
<a name="rbp-fis-apis"></a>


| API-Operation | Description | Unterstützt RBP | 
| --- | --- | --- | 
| [InjectError](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_InjectError.html) | Fügt Fehler beim Testen von Fehlerinjektionen ein | Nein | 

## Backup und Wiederherstellung APIs
<a name="rbp-backup-restore-apis"></a>


| API-Operation | Description | Unterstützt RBP | 
| --- | --- | --- | 
| [GetBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetBackupJob.html) | Ruft Informationen über einen Backup-Job ab | Nein | 
| [GetRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetRestoreJob.html) | Ruft Informationen über einen Wiederherstellungsauftrag ab | Nein | 
| [StartBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StartBackupJob.html) | Startet einen Backup-Job für einen Cluster | Ja | 
| [StartRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StartRestoreJob.html) | Startet einen Wiederherstellungsauftrag aus einem Backup | Nein | 
| [StopBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StopBackupJob.html) | Stoppt einen laufenden Backup-Job | Nein | 
| [StopRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StopRestoreJob.html) | Stoppt einen laufenden Wiederherstellungsauftrag | Nein | 

# Verwenden von serviceverknüpften Rollen in Aurora DSQL
<a name="working-with-service-linked-roles"></a>

 Aurora DSQL verwendet AWS Identity and Access Management (IAM) [serviceverknüpfte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) Rollen. Eine serviceverknüpfte Rolle ist ein spezieller Typ einer IAM-Rolle, die direkt mit Aurora DSQL verknüpft ist. Service-verknüpfte Rollen sind von Aurora DSQL vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um im Namen Ihres Aurora DSQL-Clusters aufzurufen AWS-Services . 

Serviceverknüpfte Rollen erleichtern den Einrichtungsprozess, da Sie die erforderlichen Berechtigungen zur Verwendung von Aurora DSQL nicht manuell hinzufügen müssen. Wenn Sie einen Cluster erstellen, erstellt Aurora DSQL automatisch die serviceverknüpfte Rolle für Sie. Sie können die serviceverknüpfte Rolle erst löschen, nachdem Sie alle Cluster gelöscht haben. Dies schützt Ihre Aurora DSQL-Ressourcen, da Zugriffsberechtigungen nicht versehentlich für den Zugriff auf die Ressourcen entfernt werden können.

Informationen zu anderen Services, die serviceverknüpfte Rollen unterstützen, finden Sie unter [AWS-Services die mit IAM arbeiten](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer serviceverknüpften Rolle für diesen Service anzuzeigen. 

Serviceverknüpfte Rollen sind in allen unterstützten Aurora DSQL-Regionen verfügbar.

## Serviceverknüpfte Rollenberechtigungen für Aurora DSQL
<a name="working-with-service-linked-roles-permissions"></a>

Aurora DSQL verwendet die serviceverknüpfte Rolle mit dem Namen `AWSServiceRoleForAuroraDsql` — Erlaubt Amazon Aurora DSQL, AWS Ressourcen in Ihrem Namen zu erstellen und zu verwalten. Diese verwaltete Richtlinie ist mit der folgenden serviceverknüpften Rolle verbunden: [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDsqlServiceLinkedRolePolicy.html).

**Anmerkung**  
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Möglicherweise wird die folgende Fehlermeldung angezeigt:. `You don't have the permissions to create an Amazon Aurora DSQL service-linked role` Wenn Sie diesen Fehler erhalten, überprüfen Sie, ob die folgenden Berechtigungen aktiviert sind:  

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CreateDsqlServiceLinkedRole",
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:AWSServiceName": "dsql.amazonaws.com"
                }
            }
        }
    ]
}
```
Weitere Informationen finden Sie unter [Serviceverknüpfte Rollenberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions.html).

## Erstellen einer serviceverknüpften Rolle
<a name="working-with-service-linked-roles-create"></a>

Sie müssen keine mit dem DSQLService LinkedRolePolicy Service verknüpfte Aurora-Rolle manuell erstellen. Aurora DSQL erstellt die serviceverknüpfte Rolle für Sie. Wenn die mit dem DSQLService LinkedRolePolicy Aurora-Dienst verknüpfte Rolle aus Ihrem Konto gelöscht wurde, erstellt Aurora DSQL die Rolle, wenn Sie einen neuen Aurora DSQL-Cluster erstellen.

## Bearbeiten einer serviceverknüpften Rolle
<a name="working-with-service-linked-roles-edit"></a>

 Aurora DSQL erlaubt es Ihnen nicht, die mit dem DSQLService LinkedRolePolicy Aurora-Dienst verknüpfte Rolle zu bearbeiten. Nachdem Sie eine serviceverknüpfte Rolle erstellt haben, können Sie den Namen der Rolle nicht mehr ändern, da verschiedene Entitäten auf die Rolle verweisen könnten. Sie können die Beschreibung der Rolle jedoch mithilfe der IAM-Konsole, der AWS Command Line Interface (AWS CLI) oder der IAM-API bearbeiten. 

## Löschen Sie eine serviceverknüpfte Rolle
<a name="working-with-service-linked-roles-delete"></a>

Wenn Sie ein Feature oder einen Service, die bzw. der eine servicegebundene Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte Entität, die nicht aktiv überwacht oder verwaltet wird.

Bevor Sie die serviceverknüpfte Rolle aus einem Konto löschen können, müssen Sie alle Cluster aus dem Konto löschen.

Sie können die IAM-Konsole, die oder die IAM-API verwenden AWS CLI, um eine dienstverknüpfte Rolle zu löschen. Weitere Informationen finden Sie unter [Erstellen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#delete-service-linked-role) im IAM-Benutzerhandbuch.

## Unterstützte Regionen für serviceverknüpfte Aurora DSQL-Rollen
<a name="working-with-service-linked-role-regions"></a>

Aurora DSQL unterstützt die Verwendung von serviceverknüpften Rollen in allen Regionen, in denen der Service verfügbar ist. Weitere Informationen finden Sie unter [AWS -Regionen und Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html).

# Verwenden von IAM-Bedingungsschlüsseln mit Amazon Aurora DSQL
<a name="using-iam-condition-keys"></a>

Wenn Sie in Aurora DSQL Berechtigungen gewähren, können Sie Bedingungen angeben, die bestimmen, wie eine Berechtigungsrichtlinie wirksam wird. Im Folgenden finden Sie Beispiele für die Verwendung von Bedingungsschlüsseln in den IAM-Berechtigungsrichtlinien.

## Beispiel 1: Erteilen Sie die Erlaubnis, einen Cluster in einem bestimmten AWS-Region
<a name="using-iam-condition-keys-create-cluster"></a>

Die folgende Richtlinie erteilt die Genehmigung zum Erstellen von Clustern in den Regionen USA Ost (Nord-Virginia) und USA Ost (Ohio). Diese Richtlinie verwendet den Ressourcen-ARN, um die zulässigen Regionen zu begrenzen, sodass Aurora DSQL nur Cluster erstellen kann, wenn dieser ARN im `Resource`-Abschnitt der Richtlinie angegeben ist. 

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Action": ["dsql:CreateCluster"], 
            "Resource": [
                "arn:aws:dsql:us-east-1:*:cluster/*",
                "arn:aws:dsql:us-east-2:*:cluster/*"
            ],
            "Effect": "Allow"
        }
    ]
}
```

------

## Beispiel 2: Erteilen Sie die Erlaubnis, einen Cluster mit mehreren Regionen in bestimmten AWS-Region s zu erstellen
<a name="using-iam-condition-keys-create-mr-cluster"></a>

Die folgende Richtlinie erteilt die Genehmigung zum Erstellen von Clustern mit mehreren Regionen in den Regionen USA Ost (Nord-Virginia) und USA Ost (Ohio). Diese Richtlinie verwendet den Ressourcen-ARN, um die zulässigen Regionen einzugrenzen, sodass Aurora DSQL Cluster mit mehreren Regionen nur dann erstellen kann, wenn dieser ARN im `Resource`-Abschnitt der Richtlinie angegeben ist. Beachten Sie, dass für die Erstellung von Clustern mit mehreren Regionen auch die Berechtigungen `AddPeerCluster`, `PutMultiRegionProperties` und `PutWitnessRegion` und in den angegebenen Region erforderlich sind. 

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "dsql:CreateCluster",
          "dsql:PutMultiRegionProperties",
          "dsql:PutWitnessRegion",
          "dsql:AddPeerCluster"
        ],
        "Resource": [
           "arn:aws:dsql:us-east-1:123456789012:cluster/*",
           "arn:aws:dsql:us-east-2:123456789012:cluster/*"
        ]
      }
    ]
}
```

------

## Beispiel 3: Erteilen der Berechtigung zum Erstellen eines Clusters mit mehreren Regionen mit einer bestimmten Witness-Region
<a name="using-iam-condition-keys-create-mr-cluster-witness"></a>

Die folgende Richtlinie verwendet einen Aurora DSQL-`dsql:WitnessRegion`-Bedingungsschlüssel und ermöglicht dem Benutzer, Cluster mit mehreren Regionen mit einer Witness-Region in USA West (Oregon) zu erstellen. Wenn Sie die `dsql:WitnessRegion`-Bedingung nicht angeben, können Sie eine beliebige Region als Witness-Region verwenden. 

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dsql:CreateCluster",
                "dsql:PutMultiRegionProperties",
                "dsql:AddPeerCluster"
            ],
            "Resource": "arn:aws:dsql:*:123456789012:cluster/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "dsql:PutWitnessRegion"
            ],
            "Resource": "arn:aws:dsql:*:123456789012:cluster/*",
            "Condition": {
                "StringEquals": {
                    "dsql:WitnessRegion": [
                        "us-west-2"
                    ]
                }
            }
        }
    ]
}
```

------

# Vorfallreaktion in Amazon Aurora DSQL
<a name="incident-response"></a>

Sicherheit hat bei AWS höchste Priorität. AWS Verwaltet im Rahmen des Modells der gemeinsamen Verantwortung in der AWS Cloud eine Rechenzentrums-, Netzwerk- und Softwarearchitektur, die die Anforderungen der sicherheitssensibelsten Unternehmen erfüllt. AWS ist für jegliche Reaktion auf Vorfälle in Bezug auf den Amazon Aurora DSQL-Service selbst verantwortlich. Außerdem tragen Sie als AWS Kunde gemeinsam die Verantwortung für die Aufrechterhaltung der Sicherheit in der Cloud. Das bedeutet, dass Sie die Sicherheit, die Sie implementieren möchten, anhand der AWS Tools und Funktionen, auf die Sie Zugriff haben, kontrollieren. Darüber hinaus sind Sie im Rahmen des Shared-Responsibility-Modells für die Reaktion auf Sicherheitsvorfälle auf Ihrer Seite verantwortlich.

Indem Sie eine Sicherheitsgrundlage schaffen, die den Anforderungen Ihrer in der Cloud betriebenen Anwendungen entspricht, können Sie Abweichungen erkennen und entsprechend darauf reagieren. Um besser zu verstehen, wie sich Ihre Entscheidungen und die Reaktion auf Sicherheitsvorfälle auf Ihre Unternehmensziele auswirken, empfehlen wir Ihnen, die folgenden Ressourcen zu prüfen:
+ [AWS Leitfaden zur Reaktion auf Sicherheitsvorfälle](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
+ [AWS Bewährte Methoden für Sicherheit, Identität und Compliance](https://aws.amazon.com/architecture/security-identity-compliance/)
+ [Das Whitepaper AWS Cloud Adoption Framework (CAF) aus der Sicherheitsperspektive](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html)

[Amazon GuardDuty](https://aws.amazon.com/guardduty/) ist ein verwalteter Service zur Bedrohungserkennung, der kontinuierlich bösartiges oder unbefugtes Verhalten überwacht, um Kunden dabei zu unterstützen, ihre Workloads zu schützen AWS-Konten und verdächtige Aktivitäten zu identifizieren, bevor sie zu einem Vorfall eskalieren. Der Dienst überwacht Aktivitäten wie ungewöhnliche API-Aufrufe oder potenziell unbefugte Bereitstellungen, die auf eine mögliche Kompromittierung von Konten oder Ressourcen oder auf Auskundschaften durch Angreifer hinweisen. Amazon GuardDuty ist beispielsweise in der Lage, verdächtige Aktivitäten in Amazon Aurora DSQL zu erkennen APIs, z. B. wenn sich ein Benutzer von einem neuen Standort aus anmeldet und einen neuen Cluster erstellt.

# Compliance-Validierung für Amazon Aurora DSQL
<a name="compliance-validation"></a>

Informationen darüber, ob AWS-Service ein [AWS-Services in den Geltungsbereich bestimmter Compliance-Programme fällt, finden Sie unter Umfang nach Compliance-Programm AWS-Services unter](https://aws.amazon.com/compliance/services-in-scope/) . Wählen Sie dort das Compliance-Programm aus, an dem Sie interessiert sind. Allgemeine Informationen finden Sie unter [AWS Compliance-Programme AWS](https://aws.amazon.com/compliance/programs/) .

Sie können Prüfberichte von Drittanbietern unter herunterladen AWS Artifact. Weitere Informationen finden Sie unter [Berichte herunterladen unter ](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).

Ihre Verantwortung für die Einhaltung der Vorschriften bei der Nutzung AWS-Services hängt von der Vertraulichkeit Ihrer Daten, den Compliance-Zielen Ihres Unternehmens und den geltenden Gesetzen und Vorschriften ab. Weitere Informationen zu Ihrer Verantwortung für die Einhaltung der Vorschriften bei der Nutzung AWS-Services finden Sie in der [AWS Sicherheitsdokumentation](https://docs.aws.amazon.com/security/).

# Ausfallsicherheit in Amazon Aurora DSQL
<a name="disaster-recovery-resiliency"></a>

Die AWS globale Infrastruktur basiert auf AWS-Regionen Availability Zones (AZ). AWS-Regionen stellen mehrere physisch getrennte und isolierte Availability Zones bereit, die über Netzwerke mit niedriger Latenz, hohem Durchsatz und hoher Redundanz miteinander verbunden sind. Mithilfe von Availability Zones können Sie Anwendungen und Datenbanken erstellen und ausführen, die automatisch Failover zwischen Zonen ausführen, ohne dass es zu Unterbrechungen kommt. Availability Zones sind besser verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren. Aurora DSQL wurde so konzipiert, dass Sie die Vorteile der AWS regionalen Infrastruktur nutzen und gleichzeitig die höchste Datenbankverfügbarkeit bieten können. Standardmäßig bieten Cluster mit einer Region in Aurora DSQL Multi-AZ-Verfügbarkeit, sodass größere Komponentenausfälle und Infrastrukturunterbrechungen, die den Zugriff auf eine vollständige AZ beeinträchtigen könnten, toleriert werden. Cluster mit mehreren Regionen bieten alle Vorteile der Multi-AZ-Resilienz und gleichzeitig äußerst konsistente Datenbankverfügbarkeit – sogar wenn Anwendungsclients nicht auf AWS-Region zugreifen können.

Weitere Informationen zu Availability Zones AWS-Regionen und Availability Zones finden Sie unter [AWS Globale Infrastruktur](https://aws.amazon.com/about-aws/global-infrastructure/).

Zusätzlich zur AWS globalen Infrastruktur bietet Aurora DSQL mehrere Funktionen, um Ihre Datenstabilität und Backup-Anforderungen zu erfüllen.

## Backup und Wiederherstellung
<a name="disaster-recovery-resiliency-backup-and-restore"></a>

Aurora DSQL unterstützt Backup und Wiederherstellung mit AWS-Backup-Konsole. Sie können einen vollständigen Backup und eine Wiederherstellung für Ihre Cluster mit einer oder mehreren Regionen durchführen. Weitere Informationen finden Sie unter [Backup und Wiederherstellung für Amazon Aurora DSQLBackup und Wiederherstellung](backup-aurora-dsql.md).

## Replikation
<a name="disaster-recovery-resiliency-replication"></a>

Standardmäßig schreibt Aurora DSQL alle Schreibtransaktionen in ein verteiltes Transaktionslog ein und repliziert alle übergebenen Protokolldaten synchron in drei Benutzerspeicherreplikaten. AZs Cluster mit mehreren Regionen bieten umfassende regionsübergreifende Replikationsfunktionen zwischen Lese- und Schreibregionen.

Eine ausgewiesene Witness-Region unterstützt ausschließlich Transaktionsprotokoll-Schreibvorgänge und verbraucht keinen Speicherplatz. Witness-Regionen haben keinen Endpunkt. Das bedeutet, dass Witness-Regionen nur verschlüsselte Transaktionsprotokolle speichern, keine Verwaltung oder Konfiguration erfordern, und für Benutzer nicht zugänglich sind. Wenn die Zeugenregion beeinträchtigt wird, hat dies keine Auswirkungen auf die Cluster-Verfügbarkeit. Bei Schreibtransaktionen kann es zu einem leichten Anstieg der Latenz kommen, bis sich die Zeugenregion erholt.

Aurora DSQL-Transaktionsprotokolle und Benutzerspeicher werden so verteilt, dass alle Daten den Aurora DSQL-Abfrageprozessoren als ein einziges logisches Volume präsentiert werden. Aurora DSQL teilt, repliziert und führt automatisch Daten auf der Grundlage des Primärschlüsselbereichs der Datenbank und der Zugriffsmuster zusammen. Basierend auf der Lesezugriffshäufigkeit skaliert Aurora DSQL Lesereplikate automatisch nach oben und unten.

Cluster-Speicherreplikate sind auf eine Speicherflotte mit mehreren Mandanten verteilt. Wenn eine Komponente oder AZ beeinträchtigt wird, leitet Aurora DSQL den Zugriff automatisch auf überlebende Komponenten um und repariert asynchron fehlende Replikate. Sobald Aurora DSQL die beeinträchtigten Replikate repariert hat, werden sie automatisch wieder dem Speicherquorum hinzugefügt und Ihrem Cluster zur Verfügung gestellt.

## Hohe Verfügbarkeit
<a name="disaster-recovery-resiliency-high-availability"></a>

Standardmäßig sind Cluster mit einer Region und mehreren Regionen in Aurora DSQL aktiv-aktiv, und es müssen keine Cluster manuell bereitgestellt, konfiguriert oder neu konfiguriert werden. Aurora DSQL automatisiert die Cluster-Wiederherstellung vollständig, wodurch herkömmliche primär-sekundäre Failover-Operationen überflüssig werden. Die Replikation erfolgt immer synchron und mehrfach AZs, sodass kein Risiko eines Datenverlusts aufgrund von Verzögerungen bei der Replikation oder eines Failovers auf eine asynchrone sekundäre Datenbank während der Wiederherstellung nach einem Ausfall besteht.

Cluster mit einer Region bieten einen redundanten Multi-AZ-Endpunkt, der automatisch den gleichzeitigen Zugriff mit hoher Datenkonsistenz über drei Bereiche hinweg ermöglicht. AZs Das bedeutet, dass Benutzerspeicherreplikate auf einem dieser drei Geräte AZs immer dasselbe Ergebnis an einen oder mehrere Leser zurückgeben und immer für Schreibvorgänge verfügbar sind. Diese starke Konsistenz und Multi-AZ-Resilienz ist in allen Regionen für Aurora DSQL-Cluster mit mehreren Regionen verfügbar. Das bedeutet, dass Cluster mit mehreren Regionen zwei stark konsistente regionale Endpunkte bieten, sodass Clients in jede Regione lesen oder schreiben können, ohne dass eine Replikationsverzögerung beim Commit auftritt. 

Aurora DSQL bietet eine Verfügbarkeit von 99,99% für Cluster mit einer Region und 99,999% für Cluster mit mehreren Regionen.

## Testen mit Fehlerinjektionen
<a name="fault-injection-testing"></a>

Amazon Aurora DSQL ist in AWS Fault Injection Service (AWS FIS) integriert, einen vollständig verwalteten Service zur Durchführung kontrollierter Fehlerinjektionsexperimente, um die Widerstandsfähigkeit einer Anwendung zu verbessern. Mit Hilfe AWS FIS können Sie:
+ Versuchsvorlagen erstellen, die spezifische Fehlerszenarien definieren
+ Fehler injizieren (erhöhte Fehlerraten bei Clusterverbindungen), um die Mechanismen zur Behandlung und Wiederherstellung von Anwendungsfehlern zu validieren
+ Testen Sie das Verhalten von Anwendungen in mehreren Regionen, um zu überprüfen, ob sich der Datenverkehr zwischen Anwendungen verschiebt, AWS-Regionen wenn hohe Verbindungsfehlerraten auftreten AWS-Region 

 In einem Cluster mit mehreren Regionen, der sich über die Regionen USA Ost (Nord-Virginia) und USA Ost (Ohio) erstreckt, können Sie beispielsweise ein Experiment in USA Ost (Ohio) durchführen, um dort Fehler zu testen, während USA Ost (Nord-Virginia) den normalen Betrieb fortsetzt. Diese kontrollierten Tests helfen Ihnen dabei, potenzielle Probleme zu identifizieren und zu lösen, bevor sie sich auf den Produktions-Workload auswirken. 

Eine vollständige Liste der AWS FIS unterstützten Aktionen finden Sie im *AWS FIS Benutzerhandbuch* unter [Aktionsziele](https://docs.aws.amazon.com/fis/latest/userguide/action-sequence.html#action-targets).

Informationen zu Amazon Aurora DSQL-Aktionen, die in verfügbar sind AWS FIS, finden Sie in der [Aurora DSQL-Aktionsreferenz](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dsql-actions-reference) im *AWS FIS Benutzerhandbuch*.

Informationen zu den ersten Schritten mit der Durchführung von Fehlerinjektionsexperimenten finden Sie unter [Planung Ihrer AWS FIS -Experimente](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.html) im *AWS FIS -Benutzerhandbuch*. 

# Infrastruktursicherheit in Amazon Aurora DSQL
<a name="infrastructure-security"></a>

Als verwalteter Service ist Amazon Aurora DSQL durch die AWS globalen Netzwerksicherheitsverfahren geschützt, die in [Best Practices for Security, Identity and Compliance](https://aws.amazon.com/architecture/security-identity-compliance) beschrieben sind.

Sie verwenden AWS veröffentlichte API-Aufrufe, um über das Netzwerk auf Aurora DSQL zuzugreifen. Clients müssen Transport Layer Security (TLS) 1.2 oder höher unterstützen. Clients müssen außerdem Verschlüsselungs-Suiten mit Perfect Forward Secrecy (PFS) wie DHE (Ephemeral Diffie-Hellman) oder ECDHE (Elliptic Curve Ephemeral Diffie-Hellman) unterstützen. Die meisten modernen Systemen wie Java 7 und höher unterstützen diese Modi.

Außerdem müssen Anforderungen mit einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel signiert sein, der einem IAM-Prinzipal zugeordnet ist. Alternativ können Sie mit [AWS -Security-Token-Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) temporäre Sicherheitsanmeldeinformationen erstellen, um die Anforderungen zu signieren.

# Verwaltung und Verbindung zu Amazon Aurora DSQL-Clustern mithilfe AWS PrivateLink
<a name="privatelink-managing-clusters"></a>

Mit AWS PrivateLink for Amazon Aurora DSQL können Sie Amazon VPC-Schnittstellenendpunkte (Schnittstellenendpunkte) in Ihrer Amazon Virtual Private Cloud bereitstellen. Auf diese Endpunkte kann direkt von Anwendungen aus zugegriffen werden, die sich vor Ort befinden Direct Connect, über Amazon VPC und/oder auf andere Weise AWS-Region über Amazon VPC Peering. Mithilfe von Endpunkten AWS PrivateLink und Schnittstellen können Sie die private Netzwerkkonnektivität zwischen Ihren Anwendungen und Aurora DSQL vereinfachen.

Anwendungen in Ihrer Amazon VPC können über Amazon VPC-Schnittstellenendpunkte auf Aurora DSQL zugreifen, ohne dass öffentliche IP-Adressen erforderlich sind.

Schnittstellenendpunkte werden durch eine oder mehrere elastische Netzwerkschnittstellen (ENIs) repräsentiert, denen private IP-Adressen aus Subnetzen in Ihrer Amazon VPC zugewiesen wurden. Anfragen an Aurora DSQL über Schnittstellenendpunkte bleiben im AWS Netzwerk. Weitere Informationen darüber, wie Sie Ihre Amazon VPC mit Ihrem On-Premises-Netzwerk verbinden, finden Sie im [Direct Connect -Benutzerhandbuch](https://docs.aws.amazon.com/directconnect/latest/UserGuide/) und im [AWS Site-to-Site VPN -VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)-Benutzerhandbuch.

Allgemeine Informationen zu Schnittstellenendpunkten finden Sie unter [Zugreifen auf einen AWS Service mithilfe eines Amazon VPC-Schnittstellenendpunkts](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) im [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink)Benutzerhandbuch.

## Arten von Amazon VPC-Endpunkten für Aurora DSQL
<a name="endpoint-types-dsql"></a>

 Aurora DSQL erfordert zwei verschiedene Arten von AWS PrivateLink Endpunkten. 

1. *Verwaltungsendpunkt* – Dieser Endpunkt wird für Verwaltungsvorgänge wie, `get`, `create`, `update`, `delete` und `list` auf Aurora SQL-Clustern verwendet. Siehe [Verwaltung von Aurora DSQL-Clustern mit AWS PrivateLink](#managing-dsql-clusters-using-privatelink).

1. *Verbindungsendpunkt* – Dieser Endpunkt wird für die Verbindung zu Aurora DSQL-Clustern über PostgreSQL-Clients verwendet. Siehe [Verbindung zu Aurora DSQL-Clustern herstellen mit AWS PrivateLink](#privatelink-connecting-clusters). 

## Überlegungen bei der Verwendung von AWS PrivateLink Aurora DSQL
<a name="privatelink-dsql-considerations"></a>

Überlegungen zu Amazon VPC gelten AWS PrivateLink für Aurora DSQL. Weitere Informationen finden Sie im AWS PrivateLink Handbuch unter [Zugreifen auf einen AWS Dienst über eine Schnittstelle, VPC-Endpunkt](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#vpce-interface-limitations) und [AWS PrivateLink Kontingente](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html).

## Verwaltung von Aurora DSQL-Clustern mit AWS PrivateLink
<a name="managing-dsql-clusters-using-privatelink"></a>

Sie können die AWS Command Line Interface oder AWS Software Development Kits (SDKs) verwenden, um Aurora DSQL-Cluster über Aurora DSQL-Schnittstellenendpunkte zu verwalten.

### Erstellen eines Amazon VPC-Endpunkts
<a name="create-vpc-endpoint"></a>

Informationen zum Erstellen eines Amazon VPC-Schnittstellenendpunkts finden Sie unter [Erstellen eines Amazon VPC-Endpunkts](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) im AWS PrivateLink Handbuch. 

```
aws ec2 create-vpc-endpoint \
--region region \
--service-name com.amazonaws.region.dsql \
--vpc-id your-vpc-id \
--subnet-ids your-subnet-id \
--vpc-endpoint-type Interface \
--security-group-ids client-sg-id \
```

Um den standardmäßigen regionalen DNS-Namen für Aurora DSQL-API-Anfragen zu verwenden, deaktivieren Sie beim Erstellen des Aurora DSQL-Schnittstellenendpunkts nicht die private DNS-Option. Wenn private DNS aktiviert ist, werden Anfragen an den Aurora DSQL-Dienst, die aus Ihrer Amazon VPC gestellt werden, automatisch zur privaten IP-Adresse des Amazon VPC-Endpunkts aufgelöst – und nicht zum öffentlichen DNS-Namen. Wenn private DNS aktiviert ist, werden Aurora DSQL-Anfragen, die innerhalb Ihrer Amazon VPC gestellt werden, automatisch zum Amazon VPC-Endpunkt aufgelöst. 

Wenn privates DNS nicht aktiviert ist, verwenden Sie die `--endpoint-url` Parameter `--region` und mit AWS CLI Befehlen, um Aurora DSQL-Cluster über Aurora DSQL-Schnittstellenendpunkte zu verwalten.

### Auflisten von Clustern mithilfe einer Endpunkt-URL
<a name="list-clusters-endpoint-url"></a>

Ersetzen Sie im folgenden Beispiel den AWS-Region `us-east-1` und den DNS-Namen der Amazon VPC-Endpunkt-ID `vpce-1a2b3c4d-5e6f.dsql.us-east-1.vpce.amazonaws.com` durch Ihre eigenen Informationen.

```
aws dsql --region us-east-1 --endpoint-url https://vpce-1a2b3c4d-5e6f.dsql.us-east-1.vpce.amazonaws.com list-clusters
```

### API-Operationen
<a name="api-operations"></a>

In der [Aurora DSQL-API-Referenz](CHAP_api_reference.md) finden Sie Informationen zur Ressourcenverwaltung in Aurora DSQL.

### Verwalten von Endpunktrichtlinien
<a name="managing-endpoint-policies"></a>

Durch gründliches Testen und Konfigurieren der Amazon VPC-Endpunktrichtlinien können Sie sicherstellen, dass Ihr Aurora DSQL-Cluster sicher, konform und auf die spezifischen Anforderungen Ihrer Organisation in Bezug auf Zugriffskontrolle und Governance abgestimmt ist.

**Beispiel: Vollständige Aurora DSQL-Zugriffsrichtlinie**

Die folgende Richtlinie gewährt Vollzugriff auf alle Aurora DSQL-Aktionen und -Ressourcen über den angegebenen Amazon VPC-Endpunkt. 

```
aws ec2 modify-vpc-endpoint \
    --vpc-endpoint-id vpce-xxxxxxxxxxxxxxxxx \
    --region region \
    --policy-document '{
      "Version": "2012-10-17",		 	 	 
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": "*",
          "Action": "dsql:*",
          "Resource": "*"
        }
      ]
    }'
```

**Beispiel: Eingeschränkte Aurora DSQL-Zugriffsrichtlinie**

Die folgende Richtlinie erlaubt nur diese Aurora DSQL-Aktionen.
+ `CreateCluster`
+ `GetCluster`
+ `ListClusters`

Alle anderen Aurora DSQL-Aktionen werden verweigert.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "dsql:CreateCluster",
        "dsql:GetCluster",
        "dsql:ListClusters"
      ],
      "Resource": "*"
    }
  ]
}
```

------

## Verbindung zu Aurora DSQL-Clustern herstellen mit AWS PrivateLink
<a name="privatelink-connecting-clusters"></a>

Sobald Ihr AWS PrivateLink Endpunkt eingerichtet und aktiv ist, können Sie mit einem PostgreSQL-Client eine Verbindung zu Ihrem Aurora DSQL-Cluster herstellen. In den folgenden Verbindungsanweisungen werden die Schritte zur Erstellung des richtigen Hostnamens für die Verbindung über den Endpunkt beschrieben. AWS PrivateLink 

### Einen AWS PrivateLink Verbindungsendpunkt einrichten
<a name="setting-up-privatelink-endpoint"></a>

******Schritt 1: Rufen Sie den Dienstnamen für Ihren Cluster ab**

Wenn Sie einen AWS PrivateLink Endpunkt für die Verbindung zu Ihrem Cluster erstellen, müssen Sie zuerst den clusterspezifischen Dienstnamen abrufen.

------
#### [ AWS CLI ]

```
aws dsql get-vpc-endpoint-service-name \
--region us-east-1 \
--identifier your-cluster-id
```

Beispielantwort

```
{
    "serviceName": "com.amazonaws.us-east-1.dsql-fnh4"
}
```

Der Servicename enthält eine ID wie `dsql-fnh4` im Beispiel. Diese ID wird auch benötigt, wenn der Hostname für die Verbindung zu Ihrem Cluster erstellt wird.

------
#### [ AWS SDK for Python (Boto3) ]

```
import boto3

dsql_client = boto3.client('dsql', region_name='us-east-1')
response = dsql_client.get_vpc_endpoint_service_name(
    identifier='your-cluster-id'
)
service_name = response['serviceName']
print(f"Service Name: {service_name}")
```

------
#### [ AWS SDK for Java 2.x ]

```
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.GetVpcEndpointServiceNameRequest;
import software.amazon.awssdk.services.dsql.model.GetVpcEndpointServiceNameResponse;

String region = "us-east-1";
String clusterId = "your-cluster-id";

DsqlClient dsqlClient = DsqlClient.builder()
    .region(Region.of(region))
    .credentialsProvider(DefaultCredentialsProvider.create())
    .build();

GetVpcEndpointServiceNameResponse response = dsqlClient.getVpcEndpointServiceName(
    GetVpcEndpointServiceNameRequest.builder()
        .identifier(clusterId)
        .build()
);
String serviceName = response.serviceName();
System.out.println("Service Name: " + serviceName);
```

------<a name="create-vpc-endpoint"></a>

**Schritt 2: Erstellen des Amazon VPC-Endpunkts**

Erstellen Sie mit dem im vorherigen Schritt abgerufenen Servicenamen einen Amazon VPC-Endpunkt. 

**Wichtig**  
Die folgenden Verbindungsanweisungen funktionieren nur für Clusterverbindungen, wenn Private DNS aktiviert ist. Verwenden Sie das `--no-private-dns-enabled`-Flag nicht, wenn Sie den Endpunkt erstellen, da sonst die unten aufgeführten Verbindungsanleitungen nicht ordnungsgemäß funktionieren. Wenn Sie Private DNS deaktivieren, müssen Sie Ihren eigenen privaten DNS-Wildcard-Eintrag erstellen, der auf den erstellten Endpunkt verweist.

------
#### [ AWS CLI ]

```
aws ec2 create-vpc-endpoint \
    --region us-east-1 \
    --service-name service-name-for-your-cluster \
    --vpc-id your-vpc-id \
    --subnet-ids subnet-id-1 subnet-id-2  \
    --vpc-endpoint-type Interface \
    --security-group-ids security-group-id
```

**Beispielantwort**

```
{
    "VpcEndpoint": {
        "VpcEndpointId": "vpce-0123456789abcdef0",
        "VpcEndpointType": "Interface",
        "VpcId": "vpc-0123456789abcdef0",
        "ServiceName": "com.amazonaws.us-east-1.dsql-fnh4",
        "State": "pending",
        "RouteTableIds": [],
        "SubnetIds": [
            "subnet-0123456789abcdef0",
            "subnet-0123456789abcdef1"
        ],
        "Groups": [
            {
                "GroupId": "sg-0123456789abcdef0",
                "GroupName": "default"
            }
        ],
        "PrivateDnsEnabled": true,
        "RequesterManaged": false,
        "NetworkInterfaceIds": [
            "eni-0123456789abcdef0",
            "eni-0123456789abcdef1"
        ],
        "DnsEntries": [
            {
                "DnsName": "*.dsql-fnh4.us-east-1.vpce.amazonaws.com",
                "HostedZoneId": "Z7HUB22UULQXV"
            }
        ],
        "CreationTimestamp": "2025-01-01T00:00:00.000Z"
    }
}
```

------
#### [ SDK for Python ]

```
import boto3

ec2_client = boto3.client('ec2', region_name='us-east-1')
response = ec2_client.create_vpc_endpoint(
    VpcEndpointType='Interface',
    VpcId='your-vpc-id',
    ServiceName='com.amazonaws.us-east-1.dsql-fnh4',  # Use the service name from previous step
    SubnetIds=[
        'subnet-id-1',
        'subnet-id-2'
    ],
    SecurityGroupIds=[
        'security-group-id'
    ]
)

vpc_endpoint_id = response['VpcEndpoint']['VpcEndpointId']
print(f"VPC Endpoint created with ID: {vpc_endpoint_id}")
```

------
#### [ SDK for Java 2.x ]

Verwenden Sie eine Endpunkt-URL für Aurora DSQL APIs

```
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.ec2.Ec2Client;
import software.amazon.awssdk.services.ec2.model.CreateVpcEndpointRequest;
import software.amazon.awssdk.services.ec2.model.CreateVpcEndpointResponse;
import software.amazon.awssdk.services.ec2.model.VpcEndpointType;

String region = "us-east-1";
String serviceName = "com.amazonaws.us-east-1.dsql-fnh4";  // Use the service name from previous step
String vpcId = "your-vpc-id";

Ec2Client ec2Client = Ec2Client.builder()
    .region(Region.of(region))
    .credentialsProvider(DefaultCredentialsProvider.create())
    .build();

CreateVpcEndpointRequest request = CreateVpcEndpointRequest.builder()
    .vpcId(vpcId)
    .serviceName(serviceName)
    .vpcEndpointType(VpcEndpointType.INTERFACE)
    .subnetIds("subnet-id-1", "subnet-id-2")
    .securityGroupIds("security-group-id")
    .build();

CreateVpcEndpointResponse response = ec2Client.createVpcEndpoint(request);
String vpcEndpointId = response.vpcEndpoint().vpcEndpointId();
System.out.println("VPC Endpoint created with ID: " + vpcEndpointId);
```

------<a name="additional-setup-for-peering"></a>

**Zusätzliche Einrichtung bei der Verbindung über Direct Connect oder Amazon VPC-Peering**

Möglicherweise sind zusätzliche Einstellungen erforderlich, um über einen AWS PrivateLink Verbindungsendpunkt von lokalen Geräten über Amazon VPC-Peering oder eine Verbindung zu Aurora DSQL-Clustern herzustellen. Direct Connect Dieses Setup ist nicht erforderlich, wenn Ihre Anwendung in derselben Amazon VPC wie Ihr AWS PrivateLink Endpunkt läuft. Die oben erstellten privaten DNS-Einträge werden außerhalb der Amazon VPC des Endpunkts nicht korrekt aufgelöst. Sie können jedoch Ihre eigenen privaten DNS-Einträge erstellen, die zu Ihrem AWS PrivateLink Verbindungsendpunkt aufgelöst werden. 

Erstellen Sie einen privaten CNAME-DNS-Eintrag, der auf den vollständig qualifizierten Domainnamen des AWS PrivateLink Endpunkts verweist. Der Domainname des erstellten DNS-Eintrags sollte aus den folgenden Komponenten bestehen:

1. Die Service-ID aus dem Servicenamen. Beispiel: `dsql-fnh4`

1. Der AWS-Region

Erstellen Sie den CNAME-DNS-Eintrag mit einem Domainnamen im folgenden Format: `*.service-identifier.region.on.aws` 

Das Format des Domainnamens ist aus zwei Gründen wichtig:

1. Der Hostname, der für die Verbindung mit Aurora DSQL verwendet wird, muss mit dem Serverzertifikat von Aurora DSQL übereinstimmen, wenn der SSL-Modus verwendet wird`verify-full`. Dies gewährleistet ein Höchstmaß an Verbindungssicherheit.

1. Aurora DSQL verwendet den Cluster-ID-Teil des Hostnamens, der für die Verbindung mit Aurora DSQL verwendet wird, um den Verbindungscluster zu identifizieren.

Wenn das Erstellen von privaten DNS-Einträgen nicht möglich ist, können Sie trotzdem eine Verbindung zu Aurora DSQL herstellen. Siehe [Herstellen einer Verbindung zu einem Aurora DSQL-Cluster über einen AWS PrivateLink Endpunkt ohne privates DNS](#connecting-cluster-id-option).

### Über einen Verbindungsendpunkt eine Verbindung zu einem Aurora DSQL-Cluster herstellen AWS PrivateLink
<a name="connecting-endpoints"></a>

Sobald Ihr AWS PrivateLink Endpunkt eingerichtet und aktiv ist (stellen Sie sicher, dass dies der Fall `State` ist`available`), können Sie über einen PostgreSQL-Client eine Verbindung zu Ihrem Aurora DSQL-Cluster herstellen. Anweisungen zur Verwendung von finden Sie in den Anleitungen unter [Programmieren mit Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/programming-with.html). AWS SDKs Sie müssen den Cluster-Endpunkt so ändern, dass er dem Hostnamenformat entspricht.

#### Konstruieren des Hostnamens
<a name="construct-hostname"></a>

Der Hostname für die Verbindung AWS PrivateLink unterscheidet sich vom öffentlichen DNS-Hostnamen. Sie müssen ihn mit den folgenden Komponenten erstellen.

1. `Your-cluster-id`

1. Die Service-ID aus dem Servicenamen. Beispiel: `dsql-fnh4` 

1. Der. AWS-Region Beispiel: `us-east-1` 

Verwenden Sie das folgende Format: `cluster-id.service-identifier.region.on.aws`

**Beispiel: Verbindung über PostgreSQL**

```
# Set environment variables
export CLUSTERID=your-cluster-id
export REGION=us-east-1
export SERVICE_IDENTIFIER=dsql-fnh4  # This should match the identifier in your service name

# Construct the hostname
export HOSTNAME="$CLUSTERID.$SERVICE_IDENTIFIER.$REGION.on.aws"

# Generate authentication token
export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $HOSTNAME)

# Connect using psql
psql -d postgres -h $HOSTNAME -U admin
```

#### Herstellen einer Verbindung zu einem Aurora DSQL-Cluster über einen AWS PrivateLink Endpunkt ohne privates DNS
<a name="connecting-cluster-id-option"></a>

Die obigen Verbindungsanweisungen basieren auf privaten DNS-Einträgen. Wenn Ihre Anwendung in derselben Amazon VPC wie Ihr AWS PrivateLink Endpunkt ausgeführt wird, werden die DNS-Einträge für Sie erstellt. Wenn Sie über Amazon VPC-Peering oder von lokalen Geräten aus eine Verbindung herstellen Direct Connect, können Sie alternativ Ihre eigenen privaten DNS-Einträge erstellen. Die Einrichtung von DNS-Einträgen ist jedoch aufgrund von Netzwerkbeschränkungen, die von Ihren Sicherheitsteams auferlegt wurden, nicht immer möglich. Wenn Ihre Anwendung eine Verbindung über Direct Connect oder von einer Peering-Amazon-VPC herstellen muss und die Einrichtung eines DNS-Eintrags nicht möglich ist, können Sie trotzdem eine Verbindung zu Aurora DSQL herstellen.

 Aurora DSQL verwendet den Cluster-ID-Teil Ihres Hostnamens, um den verbindenden Cluster zu identifizieren. Wenn die Einrichtung eines DNS-Eintrags jedoch nicht möglich ist, unterstützt Aurora DSQL die Angabe des Zielclusters mithilfe der `amzn-cluster-id` Verbindungsoption. Mit dieser Option ist es möglich, den vollständig qualifizierten Domainnamen Ihres AWS PrivateLink Endpunkts als Hostnamen zu verwenden, wenn Sie eine Verbindung herstellen.

**Wichtig**  
Wenn Sie eine Verbindung mit dem vollständig qualifizierten Domainnamen oder der IP-Adresse Ihres AWS PrivateLink Endpunkts herstellen, wird der `verify-full` SSL-Modus nicht unterstützt. Aus diesem Grund wird die Einrichtung von privatem DNS bevorzugt.

**Beispiel: Angabe der Cluster-ID-Verbindungsoption mit PostgreSQL**

```
# Set environment variables
export CLUSTERID=your-cluster-id
export REGION=us-east-1
export HOSTNAME=vpce-04037adb76c111221-d849uc2p.dsql-fnh4.us-east-1.vpce.amazonaws.com # This should match your endpoint's fully-qualified domain name

# Construct the hostname used to generate the authentication token
export AUTH_HOSTNAME="$CLUSTERID.dsql.$REGION.on.aws"

# Generate authentication token
export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $AUTH_HOSTNAME)

# Specify the amzn-cluster-id connection option
export PGOPTIONS="-c amzn-cluster-id=$CLUSTERID"

# Connect using psql
psql -d postgres -h $HOSTNAME -U admin
```

### Behebung von Problemen mit AWS PrivateLink
<a name="troubleshooting-privatelink"></a>

#### Häufige Probleme und Lösungen
<a name="common-issues"></a>

In der folgenden Tabelle sind häufig auftretende Probleme und Lösungen im Zusammenhang mit AWS PrivateLink und Aurora DSQL aufgeführt.


| Problem | Mögliche Ursache | Lösung | 
| --- | --- | --- | 
|  Verbindungstimeout  |  Die Sicherheitsgruppe ist nicht richtig konfiguriert  |  Verwenden Sie den Amazon VPC Reachability Analyzer, um sicherzustellen, dass Ihr Netzwerk-Setup Datenverkehr auf Port 5432 zulässt.  | 
|  Fehler für die DNS-Auflösung  |  Private DNS nicht aktiviert  |  Stellen Sie sicher, dass der Amazon VPC-Endpunkt mit aktiviertem Private DNS erstellt wurde.  | 
|  Authentifizierungsfehler  |  Falsche Anmeldeinformationen oder abgelaufenes Token  |  Generieren Sie ein neues Authentifizierungstoken und überprüfen Sie den Benutzernamen.  | 
|  Servicename nicht gefunden  |  Falsche Cluster-ID  |  Überprüfen Sie Ihre Cluster-ID und AWS-Region beim Abrufen des Dienstnamens.  | 

### Verwandte Ressourcen
<a name="related-resources"></a>

Weitere Informationen finden Sie in den folgenden Ressourcen:
+ [Amazon Aurora DSQL-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-dsql.html)
+ [AWS PrivateLink -Dokumentation](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)
+ [Greifen Sie auf Dienste zu über AWSAWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)

# Konfigurations- und Schwachstellenanalyse in Amazon Aurora DSQL
<a name="configuration-vulnerability"></a>

AWS erledigt grundlegende Sicherheitsaufgaben wie das Patchen von Gastbetriebssystemen (OS) und Datenbanken, die Firewallkonfiguration und die Notfallwiederherstellung. Diese Verfahren wurden von qualifizierten Dritten überprüft und zertifiziert. Weitere Informationen finden Sie in den folgenden Ressourcen:
+ [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [Amazon Web Services: Übersicht über Sicherheitsverfahren](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) (Whitepaper)

# Serviceübergreifende Confused-Deputy-Prävention
<a name="cross-service-confused-deputy-prevention"></a>

Das Confused-Deputy-Problem ist ein Sicherheitsproblem, bei dem eine juristische Stelle, die nicht über die Berechtigung zum Ausführen einer Aktion verfügt, eine privilegiertere juristische Stelle zwingen kann, die Aktion auszuführen. In kann AWS ein dienstübergreifender Identitätswechsel zum Problem des verwirrten Stellvertreters führen. Ein dienstübergreifender Identitätswechsel kann auftreten, wenn ein Dienst (der *Anruf-Dienst*) einen anderen Dienst anruft (den *aufgerufenen Dienst*). Der aufrufende Service kann manipuliert werden, um seine Berechtigungen zu verwenden, um Aktionen auf die Ressourcen eines anderen Kunden auszuführen, für die er sonst keine Zugriffsberechtigung haben sollte. Um dies zu verhindern, bietet AWS Tools, mit denen Sie Ihre Daten für alle Services mit Serviceprinzipalen schützen können, die Zugriff auf Ressourcen in Ihrem Konto erhalten haben. 

Wir empfehlen die Verwendung der globalen Bedingungskontext-Schlüssel [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) und [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) in ressourcenbasierten Richtlinien, um die Berechtigungen, die Amazon Aurora DSQL einem anderen Service erteilt, auf eine bestimmte Ressource zu beschränken. Verwenden Sie `aws:SourceArn`, wenn Sie nur eine Ressource mit dem betriebsübergreifenden Zugriff verknüpfen möchten. Verwenden Sie `aws:SourceAccount`, wenn Sie zulassen möchten, dass Ressourcen in diesem Konto mit der betriebsübergreifenden Verwendung verknüpft werden.

Der effektivste Weg, um sich vor dem Confused-Deputy-Problem zu schützen, ist die Verwendung des globalen Bedingungskontext-Schlüssels `aws:SourceArn` mit dem vollständigen ARN der Ressource. Wenn Sie den vollständigen ARN der Ressource nicht kennen oder wenn Sie mehrere Ressourcen angeben, verwenden Sie den globalen Kontextbedingungsschlüssel `aws:SourceArn` mit Platzhalterzeichen (`*`) für die unbekannten Teile des ARN. Beispiel, `arn:aws:dsql:*:123456789012:*`. 

Wenn der `aws:SourceArn`-Wert die Konto-ID nicht enthält, z. B. einen Amazon-S3-Bucket-ARN, müssen Sie beide globale Bedingungskontextschlüssel verwenden, um Berechtigungen einzuschränken. 

Der `aws:SourceArn`-Wert muss ResourceDescription lauten.

Das folgende Beispiel zeigt, wie Sie die globalen Bedingungskontext-Schlüssel `aws:SourceArn` und `aws:SourceAccount` in Aurora DSQL verwenden können, um das Confused-Deputy-Problem zu vermeiden.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Sid": "ConfusedDeputyPreventionExamplePolicy",
    "Effect": "Allow",
    "Principal": {
      "Service": "backup.amazonaws.com"
    },
    "Action": "dsql:GetCluster",
    "Resource": [
      "arn:aws:dsql:*:123456789012:cluster/*"
    ],
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:backup:*:123456789012:*"
      },
      "StringEquals": {
        "aws:SourceAccount": "123456789012"
      }
    }
  }
}
```

------

# Bewährte Methoden für die Aurora DSQL-Sicherheit
<a name="best-practices-security"></a>

Aurora DSQL enthält eine Reihe von Sicherheitsfeatures, die Sie bei der Entwicklung und Implementierung Ihrer eigenen Sicherheitsrichtlinien berücksichtigen sollten. Die folgenden bewährten Methoden sind allgemeine Richtlinien und keine vollständige Sicherheitslösung. Da diese bewährten Methoden für Ihre Umgebung möglicherweise nicht angemessen oder ausreichend sind, sollten Sie sie als hilfreiche Überlegungen und nicht als bindend ansehen.

**Topics**
+ [Bewährte detektivische Sicherheitsmethoden für Aurora DSQL](best-practices-security-detective.md)
+ [Bewährte Methoden für vorbeugende Sicherheitsmaßnahmen für Aurora DSQL](best-practices-security-preventative.md)

# Bewährte detektivische Sicherheitsmethoden für Aurora DSQL
<a name="best-practices-security-detective"></a>

Zusätzlich zu den folgenden Möglichkeiten zur sicheren Verwendung von Aurora DSQL finden Sie unter [Sicherheit](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) in AWS Well-Architected Tool mehr darüber, wie Cloud-Technologien Ihre Sicherheit verbessern.

** CloudWatch Amazon-Alarme**  
Mithilfe von CloudWatch Amazon-Alarmen beobachten Sie eine einzelne Metrik über einen von Ihnen angegebenen Zeitraum. Wenn die Metrik einen bestimmten Schwellenwert überschreitet, wird eine Benachrichtigung an ein Amazon SNS SNS-Thema oder eine AWS Auto Scaling Richtlinie gesendet. CloudWatch Alarme lösen keine Aktionen aus, da sie sich in einem bestimmten Status befinden. Der Status muss sich stattdessen geändert haben und für eine festgelegte Anzahl an Zeiträumen aufrechterhalten worden sein.

**Markieren Sie Ihre Aurora DSQL-Ressourcen zur Identifizierung und Automatisierung**  
Sie können Ihren AWS Ressourcen Metadaten in Form von Tags zuweisen. Jedes Tag ist eine einfache Bezeichnung, die aus einem benutzerdefinierten Schlüssel und einem optionalen Wert besteht, der das Verwalten, Suchen und Filtern von Ressourcen erleichtern kann.   
Tagging ermöglicht die Implementierung gruppierter Steuerelemente. Obwohl es keine inhärenten Typen von Tags gibt, können Sie Ressourcen nach Zweck, Besitzer, Umgebung oder anderen Kriterien kategorisieren. Im Folgenden sind einige Beispiele aufgeführt:  
+ Sicherheit – Wird verwendet, um Anforderungen wie Verschlüsselung zu bestimmen.
+ Vertraulichkeit – Eine Kennung für die spezifische Datenvertraulichkeitsebene, die eine Ressource unterstützt
+ Umgebung – Wird verwendet, um zwischen Entwicklungs-, Test- und Produktionsinfrastruktur zu unterscheiden.
Sie können Ihren AWS Ressourcen Metadaten in Form von Tags zuweisen. Jedes Tag ist eine einfache Bezeichnung, die aus einem benutzerdefinierten Schlüssel und einem optionalen Wert besteht, der das Verwalten, Suchen und Filtern von Ressourcen erleichtern kann.  
Tagging ermöglicht die Implementierung gruppierter Steuerelemente. Obwohl es keine inhärenten Typen von Tags gibt, können Sie -Ressourcen nach Zweck, Eigentümer, Umgebung oder anderen Kriterien kategorisieren. Im Folgenden sind einige Beispiele aufgeführt:  
+ Sicherheit – Wird verwendet, um Anforderungen wie Verschlüsselung zu bestimmen.
+ Vertraulichkeit – Eine Kennung für die spezifische Datenvertraulichkeitsebene, die eine Ressource unterstützt
+ Umgebung – Wird verwendet, um zwischen Entwicklungs-, Test- und Produktionsinfrastruktur zu unterscheiden.
Weitere Informationen finden Sie unter [Bewährte Methoden für das Markieren von AWS Ressourcen](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).

# Bewährte Methoden für vorbeugende Sicherheitsmaßnahmen für Aurora DSQL
<a name="best-practices-security-preventative"></a>

Zusätzlich zu den folgenden Möglichkeiten zur sicheren Verwendung von Aurora DSQL finden Sie unter [Sicherheit](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) in AWS Well-Architected Tool mehr darüber, wie Cloud-Technologien Ihre Sicherheit verbessern.

**Verwenden von IAM-Rollen zum Authentifizieren des Zugriffs auf Aurora DSQL**  
Benutzer, Anwendungen und andere, AWS-Services die auf Aurora DSQL zugreifen, müssen gültige AWS Anmeldeinformationen in AWS API und AWS CLI Anfragen angeben. Sie sollten AWS Anmeldeinformationen nicht direkt in der Anwendung oder in den EC2-Instances speichern. Es handelt sich hierbei um langfristige Anmeldeinformationen, die nicht automatisch rotiert werden. Wenn diese Anmeldeinformationen kompromittiert werden, kann dies erhebliche geschäftliche Auswirkungen nach sich ziehen. Mit einer IAM-Rolle können Sie temporäre Zugriffsschlüssel abrufen, mit denen Sie auf Ressourcen zugreifen AWS-Services können.  
Weitere Informationen finden Sie unter [Authentifizierung und Autorisierung für Aurora DSQL](authentication-authorization.md).

**Verwenden von IAM-Richtlinien für die Aurora DSQL-Basisautorisierung**  
Beim Erteilen von Berechtigungen entscheiden Sie, wer sie erhält, für welche Aurora DSQL-API-Operationen Berechtigungen erteilt werden und welche spezifischen Aktionen Sie für diese Ressourcen zulassen möchten. Die Implementierung der geringsten Rechte ist der Schlüssel zur Verringerung des Sicherheitsrisikos und der Auswirkungen, die sich aus Fehlern oder böswilligen Absichten ergeben können.  
Fügen Sie Berechtigungsrichtlinien zu IAM-Rollen hinzu und erteilen Sie Berechtigungen zur Ausführung von Operationen auf Aurora DSQL-Ressourcen. Weiterhin sind [Berechtigungsgrenzen für IAM-Entitäten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) verfügbar, mit denen Sie die maximalen Berechtigungen festlegen, die eine identitätsbasierte Richtlinie einer IAM-Entität gewähren kann.  
Ähnlich wie bei den [bewährten Methoden für Root-Benutzer AWS-Konto sollten Sie](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html) die `admin` Rolle in Aurora DSQL nicht für alltägliche Operationen verwenden. Stattdessen empfehlen wir, benutzerdefinierte Datenbankrollen zu erstellen, um Ihren Cluster zu verwalten und eine Verbindung herzustellen. Weitere Informationen finden Sie unter [Zugreifen auf Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html) und [Grundlegendes zur Authentifizierung und Autorisierung für Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html).

**Einsatz von `verify-full` in Produktionsumgebungen**  
Diese Einstellung überprüft, ob das Serverzertifikat von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde und ob der Server-Hostname mit dem Zertifikat übereinstimmt. 

**Aktualisieren Ihres PostgreSQL-Clients**  
Aktualisieren Sie Ihren PostgreSQL-Client regelmäßig auf die neueste Version, um von Sicherheitsverbesserungen zu profitieren. Wir empfehlen die Verwendung von PostgreSQL Version 17. 