Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Sicurezza in Amazon Aurora DSQL
La sicurezza del cloud AWS è la massima priorità. In qualità di AWS cliente, puoi beneficiare di data center e architetture di rete progettati per soddisfare i requisiti delle organizzazioni più sensibili alla sicurezza.
La sicurezza è una responsabilità condivisa tra te e te. AWS Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) descrive questo aspetto come sicurezza *del* cloud e sicurezza *nel* cloud:
+ **Sicurezza del cloud**: AWS è responsabile della protezione dell'infrastruttura che gestisce AWS i servizi in Cloud AWS. AWS fornisce inoltre servizi che è possibile utilizzare in modo sicuro. I revisori esterni testano e verificano regolarmente l'efficacia della nostra sicurezza nell'ambito dei [AWS Programmi di AWS conformità dei Programmi di conformità](https://aws.amazon.com/compliance/programs/) dei di . Per informazioni sui programmi di conformità che si applicano ad Amazon Aurora DSQL, consulta [AWS Services in Scope by Compliance Program by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicurezza nel cloud**: la tua responsabilità è determinata dal AWS servizio che utilizzi. L’utente è anche responsabile di altri fattori, tra cui la riservatezza dei dati, i requisiti della propria azienda e le leggi e normative vigenti.
Questa documentazione consente di comprendere come applicare il modello di responsabilità condivisa quando si usa Aurora DSQL. I seguenti argomenti illustrano come configurare Aurora DSQL per soddisfare gli obiettivi di sicurezza e conformità. Scopri anche come utilizzare altri AWS servizi che ti aiutano a monitorare e proteggere le tue risorse Aurora DSQL.
**Topics**
+ [AWS politiche gestite per Amazon Aurora DSQL](security-iam-awsmanpol.md)
+ [Protezione dei dati in Amazon Aurora DSQL](data-protection.md)
+ [Crittografia dei dati per Amazon Aurora DSQL](data-encryption.md)
+ [Gestione delle identità e degli accessi per Aurora DSQL](security-iam.md)
+ [Policy basate sulle risorse per Aurora DSQL](resource-based-policies.md)
+ [Utilizzo dei ruoli collegati al servizio in Aurora DSQL](working-with-service-linked-roles.md)
+ [Utilizzo di chiavi di condizione IAM con Amazon Aurora DSQL](using-iam-condition-keys.md)
+ [Risposta agli incidenti in Amazon Aurora DSQL](incident-response.md)
+ [Convalida della conformità per Amazon Aurora DSQL](compliance-validation.md)
+ [Resilienza in Amazon Aurora DSQL](disaster-recovery-resiliency.md)
+ [Sicurezza dell’infrastruttura in Amazon Aurora DSQL](infrastructure-security.md)
+ [Analisi della configurazione e delle vulnerabilità in Amazon Aurora DSQL](configuration-vulnerability.md)
+ [Prevenzione del confused deputy tra servizi](cross-service-confused-deputy-prevention.md)
+ [Best practice di sicurezza di Aurora DSQL](best-practices-security.md)
# AWS politiche gestite per Amazon Aurora DSQL
Una policy AWS gestita è una policy autonoma creata e amministrata da. AWS AWS le politiche gestite sono progettate per fornire autorizzazioni per molti casi d'uso comuni, in modo da poter iniziare ad assegnare autorizzazioni a utenti, gruppi e ruoli.
Tieni presente che le policy AWS gestite potrebbero non concedere le autorizzazioni con il privilegio minimo per i tuoi casi d'uso specifici, poiché sono disponibili per tutti i clienti. AWS Si consiglia pertanto di ridurre ulteriormente le autorizzazioni definendo [policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) specifiche per i propri casi d'uso.
Non è possibile modificare le autorizzazioni definite nelle politiche gestite. AWS Se AWS aggiorna le autorizzazioni definite in una politica AWS gestita, l'aggiornamento ha effetto su tutte le identità principali (utenti, gruppi e ruoli) a cui è associata la politica. AWS è più probabile che aggiorni una policy AWS gestita quando ne Servizio AWS viene lanciata una nuova o quando diventano disponibili nuove operazioni API per i servizi esistenti.
Per ulteriori informazioni, consultare [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *Guida per l'utente di IAM*.
## AWS politica gestita: AmazonAurora DSQLFull accesso
È possibile associare la policy `AmazonAuroraDSQLFullAccess` a utenti, gruppi e ruoli.
Questa policy concede autorizzazioni che forniscono l’accesso completo come amministratore ad Aurora DSQL. Le entità principali con queste autorizzazioni possono:
+ Creare, eliminare e aggiornare i cluster Aurora DSQL, inclusi i cluster multi-Regione
+ Gestisci le politiche in linea del cluster (creazione, visualizzazione, aggiornamento ed eliminazione delle politiche)
+ Aggiungere e rimuover tag dai cluster
+ Elencare i cluster e visualizzare le informazioni sui singoli cluster
+ Visualizzare i tag associati ai cluster Aurora DSQL
+ Collegarsi al database come qualsiasi utente, incluso l’amministratore
+ Eseguire operazioni di backup e ripristino per i cluster Aurora DSQL, tra cui avvio, arresto e monitoraggio dei processi di backup e ripristino
+ Utilizza AWS KMS chiavi gestite dal cliente per la crittografia dei cluster
+ Visualizza tutte le metriche relative al loro account CloudWatch
+ Usa AWS Fault Injection Service (AWS FIS) per inserire errori nei cluster Aurora DSQL per i test di tolleranza ai guasti
+ Creare ruoli collegati al servizio per il servizio `dsql.amazonaws.com`, necessari per la creazione dei cluster
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `dsql` - Concede alle entità principali l’accesso completo ad Aurora DSQL.
+ `cloudwatch`—concede l'autorizzazione a pubblicare punti dati metrici su Amazon. CloudWatch
+ `iam` - Concede le autorizzazioni per creare un ruolo collegato al servizio.
+ `backup and restore` - Concede le autorizzazioni per avviare, interrompere e monitorare i processi di backup e ripristino per i cluster Aurora DSQL.
+ `kms` - Concede le autorizzazioni necessarie per convalidare l’accesso alle chiavi gestite dal cliente utilizzate per la crittografia dei cluster Aurora DSQL durante la creazione, l’aggiornamento o la connessione ai cluster.
+ `fis`—concede le autorizzazioni di utilizzo ( AWS Fault Injection Service AWS FIS) per inserire errori nei cluster Aurora DSQL per i test di tolleranza agli errori.
È possibile trovare la policy `AmazonAuroraDSQLFullAccess` nella console IAM e nella [Guida di riferimento alle policy gestite di AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLFullAccess.html).
## AWS politica gestita: AmazonAurora DSQLRead OnlyAccess
È possibile associare la policy `AmazonAuroraDSQLReadOnlyAccess` a utenti, gruppi e ruoli.
Consente l’accesso in lettura ad Aurora DSQL. Le entità principali con queste autorizzazioni possono elencare i cluster e visualizzare informazioni sui singoli cluster. Possono vedere i tag allegati ai cluster Aurora DSQL e visualizzare le policy in linea del cluster. Possono recuperare e visualizzare qualsiasi metrica del tuo account. CloudWatch
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `dsql` - Concede autorizzazioni di sola lettura su tutte le risorse in Aurora DSQL.
+ `cloudwatch`— concede l'autorizzazione a recuperare quantità batch di dati metrici ed eseguire CloudWatch calcoli metrici sui dati recuperati
È possibile trovare la policy `AmazonAuroraDSQLReadOnlyAccess` nella console IAM e nella [Guida di riferimento alle policy gestite di AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLReadOnlyAccess.html).
## AWS politica gestita: AmazonAurora DSQLConsole FullAccess
È possibile associare la policy `AmazonAuroraDSQLConsoleFullAccess` a utenti, gruppi e ruoli.
Consente l’accesso amministrativo completo ad Amazon Aurora DSQL tramite la Console di gestione AWS. Le entità principali con queste autorizzazioni possono:
+ Creare, eliminare e aggiornare i cluster Aurora DSQL, inclusi i cluster multi-Regione, con la console
+ Gestisci le politiche in linea del cluster tramite la console (creazione, visualizzazione, aggiornamento ed eliminazione delle politiche)
+ Elencare i cluster e visualizzare le informazioni sui singoli cluster
+ Visualizzare i tag su qualsiasi risorsa dell’account
+ Collegarsi al database come qualsiasi utente, incluso l’amministratore
+ Eseguire operazioni di backup e ripristino per i cluster Aurora DSQL, tra cui avvio, arresto e monitoraggio dei processi di backup e ripristino
+ Utilizza AWS KMS chiavi gestite dal cliente per la crittografia dei cluster
+ Avvia AWS CloudShell da Console di gestione AWS
+ Visualizza tutte le metriche dal CloudWatch tuo account
+ Usa AWS Fault Injection Service (AWS FIS) per inserire errori nei cluster Aurora DSQL per i test di tolleranza ai guasti
+ Creare ruoli collegati al servizio per il servizio `dsql.amazonaws.com`, necessari per la creazione dei cluster
Puoi trovare la `AmazonAuroraDSQLConsoleFullAccess` policy sulla console IAM e [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLConsoleFullAccess.html)nella Managed Policy Reference Guide. AWS
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `dsql` - Concede autorizzazioni amministrative complete a tutte le risorse in Aurora DSQL tramite la Console di gestione AWS.
+ `cloudwatch`—concede l'autorizzazione a recuperare quantità in batch di dati metrici ed eseguire CloudWatch calcoli metrici sui dati recuperati.
+ `tag`—concede l'autorizzazione a restituire le chiavi e i valori dei tag attualmente in uso nell'account specificato per la chiamata. Regione AWS
+ `backup and restore` - Concede le autorizzazioni per avviare, interrompere e monitorare i processi di backup e ripristino per i cluster Aurora DSQL.
+ `kms` - Concede le autorizzazioni necessarie per convalidare l’accesso alle chiavi gestite dal cliente utilizzate per la crittografia dei cluster Aurora DSQL durante la creazione, l’aggiornamento o la connessione ai cluster.
+ `cloudshell`—concede le autorizzazioni all'avvio AWS CloudShell per interagire con Aurora DSQL.
+ `ec2` - Concede l’autorizzazione a visualizzare le informazioni sugli endpoint Amazon VPC necessarie per le connessioni Aurora DSQL.
+ `fis`—concede le autorizzazioni da utilizzare AWS FIS per inserire errori nei cluster Aurora DSQL per il test della tolleranza agli errori.
+ `access-analyzer:ValidatePolicy`concede l'autorizzazione per il linter nell'editor delle politiche, che fornisce feedback in tempo reale su errori, avvisi e problemi di sicurezza nella politica corrente.
+ `fis`—concede le autorizzazioni di utilizzo ( AWS Fault Injection Service AWS FIS) per inserire errori nei cluster Aurora DSQL per i test di tolleranza agli errori.
È possibile trovare la policy `AmazonAuroraDSQLConsoleFullAccess` nella console IAM e nella [Guida di riferimento alle policy gestite di AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLConsoleFullAccess.html).
## AWS politica gestita: Aurora DSQLService RolePolicy
Non puoi collegare Aurora DSQLService RolePolicy alle tue entità IAM. Questa policy è allegata a un ruolo collegato al servizio che consente ad Aurora DSQL di accedere alle risorse dell’account.
Puoi trovare la `AuroraDSQLServiceRolePolicy` policy sulla console IAM e [Aurora DSQLService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDSQLServiceRolePolicy.html) nella AWS Managed Policy Reference Guide.
## Aurora DSQL si aggiorna alle policy gestite AWS
Visualizza i dettagli sugli aggiornamenti delle politiche AWS gestite per Aurora DSQL da quando questo servizio ha iniziato a tenere traccia di queste modifiche. Per gli avvisi automatici sulle modifiche apportate a questa pagina, sottoscrivi il feed RSS nella pagina della cronologia dei documenti di Aurora DSQL.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| AmazonAuroraDSQLFullAccesso e aggiornamento AmazonAurora DSQLConsole FullAccess | È stato aggiunto il supporto per l'integrazione AWS Fault Injection Service (AWS FIS) con Aurora DSQL. Ciò consente di eseguire l’iniezione di guasti in cluster Aurora DSQL a Regione singola e multi-Regione per testare la tolleranza ai guasti delle applicazioni. È possibile creare modelli di esperimento nella AWS FIS console per definire scenari di errore e indirizzare cluster Aurora DSQL specifici per i test. [Per ulteriori informazioni su queste politiche, consulta AmazonAurora DSQLFull Access and. [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) | 19 agosto 2025 |
| AmazonAuroraDSQLFullAccesso AmazonAurora DSQLRead OnlyAccess e AmazonAurora DSQLConsole FullAccess aggiornamento | È stato aggiunto il supporto per le policy basate sulle risorse (RBP) con nuove autorizzazioni:, e. `PutClusterPolicy` `GetClusterPolicy` `DeleteClusterPolicy` Queste autorizzazioni consentono di gestire le policy in linea collegate ai cluster Aurora DSQL per un controllo granulare degli accessi. [Per ulteriori informazioni, vedere Access, e. AmazonAurora DSQLFull [AmazonAuroraDSQLReadOnlyAccess[AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess)](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) | 15 ottobre 2025 |
| AmazonAuroraDSQLFullAggiornamento dell'accesso | Aggiunge la capacità di eseguire operazioni di backup e ripristino per i cluster Aurora DSQL, tra cui avvio, arresto e monitoraggio dei processi. Aggiunge inoltre la possibilità di utilizzare chiavi KMS gestite dal cliente per la crittografia dei cluster. Per ulteriori informazioni, vedere [AmazonAuroraDSQLFullAccesso](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) e [utilizzo dei ruoli collegati ai servizi in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 21 maggio 2025 |
| AmazonAuroraDSQLConsoleFullAccess update | Aggiunge la capacità di eseguire operazioni di backup e ripristino per i cluster Aurora DSQL tramite la AWS Console Home. Ciò include l’avvio, l’arresto e il monitoraggio dei processi. Supporta anche l’utilizzo di chiavi KMS gestite dal cliente per la crittografia dei cluster e l’avvio di AWS CloudShell. Per ulteriori informazioni, vedere [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)e [Utilizzo dei ruoli collegati ai servizi in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 21 maggio 2025 |
| AmazonAuroraDSQLFullAccedi all'aggiornamento | La politica aggiunge quattro nuove autorizzazioni per creare e gestire cluster di database su più livelli Regioni AWS:`PutMultiRegionProperties`, `PutWitnessRegion``AddPeerCluster`, e. `RemovePeerCluster` Queste autorizzazioni includono controlli a livello di risorsa e chiavi di condizione in modo da poter controllare quali cluster possono essere modificati dagli utenti. La policy aggiunge anche l’autorizzazione `GetVpcEndpointServiceName` per consentire di connettersi ai cluster Aurora DSQL tramite AWS PrivateLink. Per ulteriori informazioni, vedere Per ulteriori informazioni, vedere [AmazonAuroraDSQLFullAccesso](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) e [utilizzo dei ruoli collegati ai servizi in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 maggio 2025 |
| AmazonAuroraDSQLReadOnlyAccess update | Include la possibilità di determinare il nome corretto del servizio endpoint VPC durante la connessione ai cluster Aurora DSQL tramite AWS PrivateLink Aurora DSQL crea endpoint unici per cella, quindi questa API aiuta a identificare l'endpoint corretto per il cluster ed evitare errori di connessione.Per ulteriori informazioni, vedere [AmazonAuroraDSQLReadOnlyAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess)e [Utilizzo dei ruoli collegati ai servizi in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 maggio 2025 |
| AmazonAuroraDSQLConsoleFullAccess update | Aggiunge nuove autorizzazioni ad Aurora DSQL per supportare la gestione di cluster multi-Regione e la connessione agli endpoint VPC. Le nuove autorizzazioni includono: PutMultiRegionProperties, PutWitnessRegion, AddPeerCluster, RemovePeerCluster e GetVpcEndpointServiceName Per ulteriori informazioni, vedere [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)e [Utilizzo dei ruoli collegati ai servizi in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 maggio 2025 |
| AuroraDsqlServiceLinkedRolePolicy update | Aggiunge la possibilità di pubblicare metriche nei namespace AWS/AuroraDSQL e AWS/Usage CloudWatch della policy. Ciò consente al servizio o al ruolo associato di emettere dati più completi sull'utilizzo e sulle prestazioni nell'ambiente. CloudWatch Per ulteriori informazioni, vedere [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDsqlServiceLinkedRolePolicy.html)e [Utilizzo dei ruoli collegati ai servizi in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 8 maggio 2025 |
| Pagina creata | Ha iniziato a tracciare le policy AWS gestite relative ad Amazon Aurora DSQL | 3 dicembre 2024 |
# Protezione dei dati in Amazon Aurora DSQL
Alla protezione dei dati si applica il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/). Come descritto in questo modello, AWS è responsabile della protezione dell’infrastruttura globale che esegue tutto il Cloud AWS. L’utente è responsabile del controllo dei contenuti ospitati su questa infrastruttura. Il cliente è inoltre responsabile della configurazione della protezione e delle attività di gestione per i servizi utilizzati. Per maggiori informazioni sulla privacy dei dati, consulta le [Domande frequenti sulla privacy dei dati](https://aws.amazon.com/compliance/data-privacy-faq/). Per informazioni sulla protezione dei dati in Europa, consulta il post del blog relativo al [Modello di responsabilità condivisa e GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) nel *Blog sulla sicurezza*.
Ai fini della protezione dei dati, ti consigliamo di proteggere le credenziali e configurare i singoli utenti con o. AWS IAM Identity Center AWS Identity and Access Management In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Suggeriamo, inoltre, di proteggere i dati nei seguenti modi:
+ Utilizza l’autenticazione a più fattori (MFA) con ogni account.
+ SSL/TLS Da utilizzare per comunicare con le risorse. È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Configura l'API e la registrazione delle attività degli utenti con AWS CloudTrail. Per informazioni sull’utilizzo dei trail per acquisire le attività, consulta [Utilizzo dei percorsi CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) nella *Guida per l’utente di CloudTrail*.
+ Utilizza le soluzioni di crittografia, insieme a tutti i controlli di sicurezza di default all’interno dei Servizi AWS.
+ Utilizza i servizi di sicurezza gestiti avanzati, come Amazon Macie, che aiutano a individuare e proteggere i dati sensibili archiviati in Amazon S3.
Consigliamo di non inserire mai informazioni riservate o sensibili, ad esempio gli indirizzi e-mail dei clienti, nei tag o nei campi di testo in formato libero, ad esempio nel campo **Nome**. Ciò include quando lavori o utilizzi la console, l'API o AWS SDKs. AWS CLI I dati inseriti nei tag o nei campi di testo in formato libero utilizzati per i nomi possono essere utilizzati per i la fatturazione o i log di diagnostica. Quando si fornisce un URL a un server esterno, suggeriamo vivamente di non includere informazioni sulle credenziali nell’URL per convalidare la richiesta al server.
## Crittografia dei dati
Amazon Aurora DSQL offre un’infrastruttura di storage estremamente durevole, concepita per lo archiviazione di dati mission-critical e primari. I dati sono archiviati in modo ridondante su più dispositivi, in più strutture di una Regione Aurora DSQL.
### Crittografia dei dati in transito
Per impostazione predefinita, è configurata la crittografia in transito. Aurora DSQL utilizza TLS per crittografare tutto il traffico tra il client SQL e Aurora DSQL.
Crittografia e firma dei dati in transito tra AWS CLI client SDK o API e endpoint Aurora DSQL:
+ Aurora DSQL fornisce endpoint HTTPS per la crittografia dei dati in transito.
+ Per proteggere l’integrità delle richieste API ad Aurora DSQL, le chiamate API devono essere firmate dal chiamante. Le chiamate sono firmate da un certificato X.509 o dalla chiave di accesso AWS segreta del cliente in base al processo di firma della versione 4 di firma (Sigv4). Per maggiori informazioni, consulta [Processo di firma Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) nella *Riferimenti generali di AWS*.
+ Usa il AWS CLI o uno dei due per effettuare richieste AWS SDKs a. AWS Questi strumenti firmano automaticamente le richieste con la chiave di accesso specificata al momento della configurazione.
#### Conformità a FIPS
Gli endpoint del piano dati Aurora DSQL (endpoint del cluster utilizzati per le connessioni al database) utilizzano moduli crittografici convalidati FIPS 140-2 per impostazione predefinita. Non sono necessari endpoint FIPS separati per le connessioni al cluster.
Per le operazioni sul piano di controllo, Aurora DSQL fornisce endpoint FIPS dedicati nelle regioni supportate. Per ulteriori informazioni sugli endpoint FIPS del piano di controllo, vedere Endpoint e [quote Aurora DSQL](https://docs.aws.amazon.com/general/latest/gr/dsql.html) in. *Riferimenti generali di AWS*
Per la crittografia a riposo, consulta [Crittografia dei dati a riposo in Aurora DSQL](data-encryption.md#encryption-at-rest).
### Riservatezza del traffico inter-rete
Le connessioni sono protette sia tra Aurora DSQL e le applicazioni locali sia tra Aurora DSQL e altre risorse all'interno delle stesse. AWS Regione AWS
Sono disponibili due opzioni di connettività tra la rete privata e: AWS
+ Una connessione AWS Site-to-Site VPN. Per maggiori informazioni, consulta [Che cos’è AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Una Direct Connect connessione. Per ulteriori informazioni, vedi [Cos'è Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
È possibile ottenere l’accesso ad Aurora DSQL tramite la rete utilizzando le operazioni API pubblicate da AWS. I client devono supportare quanto segue:
+ Transport Layer Security (TLS). È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Suite di cifratura con Perfect Forward Secrecy (PFS), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
## Protezione dei dati nelle Regioni testimone
Quando si crea un cluster multi-Regione, una Regione testimone consente il ripristino automatico degli errori partecipando alla replica sincrona delle transazioni crittografate. Se un cluster in peering diventa non disponibile, la Regione testimone rimane disponibile per convalidare ed elaborare le scritture sul database, garantendo l’assenza di perdita di disponibilità.
Le Regioni testimone proteggono e mantengono al sicuro i dati tramite queste funzionalità imposte come requisito di progettazione:
+ La Regione testimone riceve e archivia i registri dei log delle sole transazioni crittografate. Non ospita, archivia o trasmette mai le chiavi di crittografia.
+ La Regione testimone si concentra esclusivamente sulla registrazione delle transazioni di scrittura e sulle funzioni di quorum. Per requisito di progettazione non è in grado di leggere i dati.
+ La Regione testimone funziona senza endpoint di connessione al cluster o elaboratori di query. Ciò impedisce l’accesso al database da parte degli utenti.
Per maggiori informazioni sulle Regioni testimoni, consulta [Configurazione di cluster multi-Regione](configuring-multi-region-clusters.md).
# Configurazione dei SSL/TLS certificati per le connessioni Aurora DSQL
Aurora DSQL richiede che tutte le connessioni utilizzino la crittografia Transport Layer Security (TLS). Per stabilire connessioni sicure, il sistema client deve affidarsi all’Amazon Root Certificate Authority (Amazon Root CA 1). Questo certificato è preinstallato su molti sistemi operativi. Questa sezione fornisce istruzioni per verificare il certificato Amazon Root CA 1 preinstallato su vari sistemi operativi e guida l’utente attraverso il processo di installazione manuale del certificato, qualora non fosse già presente.
Si consiglia di utilizzare PostgreSQL versione 17.
**Importante**
Per gli ambienti di produzione, si consiglia di utilizzare la modalità SSL `verify-full` per garantire il massimo livello di sicurezza della connessione. Questa modalità verifica che il certificato del server sia firmato da un’autorità di certificazione affidabile e che il nome host del server corrisponda al certificato.
## Verifica dei certificati preinstallati
Nella maggior parte dei sistemi operativi, **Amazon Root CA 1** è già preinstallato. Per convalidarlo, è possibile completare la procedura seguente.
### Linux () RedHat/CentOS/Fedora
Esegui il comando seguente nel terminale:
```
trust list | grep "Amazon Root CA 1"
```
Se il certificato è installato, verrà visualizzato il seguente output:
```
label: Amazon Root CA 1
```
### macOS
1. Apri Spotlight Search (**Command** \$1 **Spazio**)
1. Cerca **Keychain Access**
1. Seleziona **System Roots** in **System Keychains**
1. Cerca **Amazon Root CA 1** nell’elenco dei certificati
### Windows
**Nota**
A causa di un problema noto con il client psql per Windows, l’utilizzo dei certificati root di sistema (`sslrootcert=system`) può restituire il seguente errore: `SSL error: unregistered scheme`. È possibile seguire [Connessione da Windows](#connect-windows) come metodo alternativo per connettersi al cluster tramite SSL.
Se **Amazon Root CA 1** non è installato nel sistema operativo, procedi nel seguente modo.
## Installazione dei certificati
Se il certificato `Amazon Root CA 1` non è preinstallato sul sistema operativo, sarà necessario installarlo manualmente per stabilire connessioni sicure al cluster Aurora DSQL.
### Installazione del certificato su Linux
Attieniti alla seguente procedura per installare il certificato Amazon Root CA sui sistemi Linux.
1. Scarica il certificato root:
```
wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
```
1. Aggiungi il certificato all’archivio di fiducia:
```
sudo cp ./AmazonRootCA1.pem /etc/pki/ca-trust/source/anchors/
```
1. Aggiorna il CA Trust Store:
```
sudo update-ca-trust
```
1. Verifica l’installazione:
```
trust list | grep "Amazon Root CA 1"
```
### Installazione del certificato su macOS
Questi passaggi di installazione dei certificati sono facoltativi. [Installazione del certificato su Linux](#install-linux) funziona anche per macOS.
1. Scarica il certificato root:
```
wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
```
1. Aggiungi il certificato al keychain di sistema:
```
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain AmazonRootCA1.pem
```
1. Verifica l’installazione:
```
security find-certificate -a -c "Amazon Root CA 1" -p /Library/Keychains/System.keychain
```
## Connessione con SSL/TLS verifica
Prima di configurare SSL/TLS i certificati per connessioni sicure al cluster Aurora DSQL, assicurati di avere i seguenti prerequisiti.
+ PostgreSQL versione 17 installata
+ AWS CLI configurato con le credenziali appropriate
+ Informazioni sugli endpoint del cluster Aurora DSQL
### Connessione da Linux
1. Genera e imposta il token di autenticazione:
```
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
```
1. Connettiti utilizzando certificati di sistema (se preinstallati):
```
PGSSLROOTCERT=system \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
1. Oppure, connettiti utilizzando un certificato scaricato:
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
**Nota**
Per maggiori informazioni sulle impostazioni PGSSLMODE, consulta [sslmode](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) nella documentazione sulle [Funzioni di controllo della connessione del database](https://www.postgresql.org/docs/current/libpq-connect.html) di PostgreSQL 17.
### Connessione da macOS
1. Genera e imposta il token di autenticazione:
```
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
```
1. Connettiti utilizzando certificati di sistema (se preinstallati):
```
PGSSLROOTCERT=system \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
1. Oppure, scarica il certificato root e salvalo con il nome `root.pem` (se il certificato non è preinstallato)
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql —dbname postgres \
--username admin \
--host your_cluster_endpoint
```
1. Connessione tramite psql:
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql —dbname postgres \
--username admin \
--host your_cluster_endpoint
```
### Connessione da Windows
#### Utilizzo del prompt dei comandi
1. Genera il token di autenticazione:
```
aws dsql generate-db-connect-admin-auth-token ^
--region=your-cluster-region ^
--expires-in=3600 ^
--hostname=your-cluster-endpoint
```
1. Imposta la variabile di ambiente della password:
```
set "PGPASSWORD=token-from-above"
```
1. Imposta la configurazione SSL:
```
set PGSSLROOTCERT=C:\full\path\to\root.pem
set PGSSLMODE=verify-full
```
1. Connettiti al database:
```
"C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres ^
--username admin ^
--host your-cluster-endpoint
```
#### Usando PowerShell
1. Genera e imposta il token di autenticazione:
```
$env:PGPASSWORD = (aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --expires-in=3600 --hostname=your-cluster-endpoint)
```
1. Imposta la configurazione SSL:
```
$env:PGSSLROOTCERT='C:\full\path\to\root.pem'
$env:PGSSLMODE='verify-full'
```
1. Connettiti al database:
```
"C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres `
--username admin `
--host your-cluster-endpoint
```
## Risorse aggiuntive
+ [Documentazione di PostgreSQL SSL](https://www.postgresql.org/docs/current/libpq-ssl.html)
+ [Servizi Amazon Trust](https://www.amazontrust.com/repository/)
# Crittografia dei dati per Amazon Aurora DSQL
Amazon Aurora DSQL crittografa tutti i dati a riposo degli utenti. Per una maggiore sicurezza, questa crittografia utilizza AWS Key Management Service (AWS KMS). Questa funzionalità consente di ridurre gli oneri operativi e la complessità associati alla protezione dei dati sensibili. La crittografia dei dati a riposo permette di:
+ Ridurre l’onere operativo legato alla protezione dei dati sensibili
+ Creare applicazioni ad alto livello di sicurezza che rispettano rigorosi requisiti normativi e di conformità per la crittografia
+ Aggiungere un ulteriore livello di protezione dei dati proteggendo sempre i dati in un cluster crittografato
+ Rispettare le policy organizzative, le normative di settore o governative e i requisiti di conformità
La crittografia dei dati a risposo consente di creare applicazioni ad alto livello di sicurezza che rispettano rigorosi requisiti normativi e di conformità per la crittografia. Le sezioni seguenti spiegano come configurare la crittografia per i database Aurora DSQL nuovi ed esistenti e gestire le chiavi di crittografia.
**Topics**
+ [Tipi di chiave KMS per Aurora DSQL](#kms-key-types)
+ [Crittografia dei dati a riposo in Aurora DSQL](#encryption-at-rest)
+ [Utilizzo AWS KMS e chiavi dati con Aurora DSQL](#using-kms-and-data-keys)
+ [Autorizzazione all'uso del tuo AWS KMS key per Aurora DSQL](#authorizing-kms-key-use)
+ [Contesto di crittografia di Aurora DSQL](#dsql-encryption-context)
+ [Monitoraggio dell'interazione di Aurora DSQL con AWS KMS](#monitoring-dsql-kms-interaction)
+ [Creazione di un cluster Aurora DSQL crittografato](#creating-encrypted-cluster)
+ [Rimozione o aggiornamento di una chiave per il cluster Aurora DSQL](#updating-encryption-key)
+ [Considerazioni sulla crittografia con Aurora DSQL](#considerations-with-encryption)
## Tipi di chiave KMS per Aurora DSQL
Aurora DSQL si integra con la gestione delle chiavi di crittografia AWS KMS per i cluster. Per maggiori informazioni sui tipi e gli stati delle chiavi, consulta [Concetti di AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts-intro.html) nella *Guida per gli sviluppatori di AWS Key Management Service *. Quando si crea un nuovo cluster, è possibile selezionare tra i seguenti tipi di chiave KMS per crittografare il cluster:
**Chiave di proprietà di AWS**
Tipo di crittografia predefinito. Aurora DSQL possiede la chiave senza costi aggiuntivi per l’utente. Amazon Aurora DSQL decrittografa in modo trasparente i dati del cluster quando si accede a un cluster crittografato. Non è necessario modificare il codice o le applicazioni per utilizzare o gestire i cluster crittografati e tutte le query SQL di Aurora funzionano con i dati crittografati.
**Chiave gestita dal cliente**
Tu crei, possiedi e gestisci la chiave del tuo. Account AWS Hai il pieno controllo sulla chiave KMS. AWS KMS si applicano costi.
La crittografia a riposo utilizzando il Chiave di proprietà di AWS è disponibile senza costi aggiuntivi. Tuttavia, per le chiavi gestite dal cliente vengono AWS KMS addebitati dei costi. Per maggiori informazioni, consulta la pagina [Prezzi di AWS KMS](https://aws.amazon.com/kms/pricing/).
È possibile passare da un tipo di chiave all’altro in qualsiasi momento. Per maggiori informazioni sui tipi di chiave, consulta [Chiavi gestite dal cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) e [Chiavi di proprietà di AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) nella *Guida per gli sviluppatori di AWS Key Management Service *.
**Nota**
La crittografia Aurora DSQL at Rest è disponibile in tutte le regioni in AWS cui è disponibile Aurora DSQL.
## Crittografia dei dati a riposo in Aurora DSQL
Amazon Aurora DSQL utilizza Advanced Encryption Standard a 256 bit (AES-256) per crittografare i dati a riposo. Questa crittografia aiuta a proteggere i dati dall'accesso non autorizzato allo storage sottostante. AWS KMS gestisce le chiavi di crittografia per i cluster. È possibile utilizzare l’impostazione predefinita [Chiavi di proprietà di AWS](#aws-owned-keys) o scegliere di utilizzare la propria [Chiavi gestite dal cliente](#customer-managed-keys) AWS KMS . Per maggiori informazioni sulla specificazione e la gestione delle chiavi per i cluster Aurora DSQL, consulta [Creazione di un cluster Aurora DSQL crittografato](#creating-encrypted-cluster) e [Rimozione o aggiornamento di una chiave per il cluster Aurora DSQL](#updating-encryption-key).
**Topics**
+ [Chiavi di proprietà di AWS](#aws-owned-keys)
+ [Chiavi gestite dal cliente](#customer-managed-keys)
### Chiavi di proprietà di AWS
Aurora DSQL crittografa tutti i cluster per impostazione predefinita con. Chiavi di proprietà di AWS Queste chiavi possono essere utilizzate gratuitamente e ruotano ogni anno per proteggere le risorse degli account. Non è necessario visualizzare, gestire, utilizzare o controllare queste chiavi, quindi non è necessaria alcuna azione per la protezione dei dati. *Per ulteriori informazioni in merito Chiavi di proprietà di AWS, consulta la Guida per gli [Chiavi di proprietà di AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)sviluppatori.AWS Key Management Service *
### Chiavi gestite dal cliente
È possibile creare, possedere e gestire chiavi gestite dal cliente in Account AWS. L’utente mantiene il pieno controllo su queste chiavi KMS, comprese le relative policy, il materiale di crittografia, i tag e gli alias. Per maggiori informazioni sulla gestione delle autorizzazioni, consulta [Chiavi gestite dal cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) nella *Guida per gli sviluppatori di AWS Key Management Service *.
Quando si specifica una chiave gestita dal cliente per la crittografia a livello di cluster, Aurora DSQL crittografa il cluster e tutti i relativi dati regionali con quella chiave. Per prevenire la perdita di dati e mantenere l’accesso al cluster, Aurora DSQL deve accedere alla chiave di crittografia. Se si disabilita la chiave gestita dal cliente, se ne pianifica l’eliminazione o si impone una policy che limita l’accesso al servizio, lo stato di crittografia del cluster diventa `KMS_KEY_INACCESSIBLE`. Quando Aurora DSQL non è in grado di accedere alla chiave, gli utenti non possono connettersi al cluster, lo stato di crittografia del cluster diventa `KMS_KEY_INACCESSIBLE` e il servizio perde l’accesso ai dati del cluster.
Per i cluster multiregionali, i clienti possono configurare la chiave di AWS KMS crittografia di ciascuna regione separatamente e ogni cluster regionale utilizza la propria chiave di crittografia a livello di cluster. Se Aurora DSQL non è in grado di accedere alla chiave di crittografia per un peer in un cluster multi-Regione, lo stato di quel peer diventa `KMS_KEY_INACCESSIBLE` e non è più disponibile per le operazioni di lettura e scrittura. Gli altri peer continuano con la normale operatività.
**Nota**
Se Aurora DSQL non è in grado di accedere alla chiave gestita dal cliente, lo stato di crittografia del cluster diventa `KMS_KEY_INACCESSIBLE`. Dopo aver ripristinato l’accesso alla chiave, il servizio rileverà automaticamente il ripristino entro 15 minuti. Per maggiori informazioni, consulta la sezione Cluster in stato sospeso.
Per i cluster multi-Regione, se l’accesso alla chiave viene perso per un periodo prolungato, il tempo di ripristino del cluster dipende dalla quantità di dati scritti mentre la chiave era inaccessibile.
## Utilizzo AWS KMS e chiavi dati con Aurora DSQL
La funzionalità di crittografia a riposo di Aurora DSQL utilizza una AWS KMS key e una gerarchia di chiavi di dati per proteggere i dati del cluster.
Consigliamo di pianificare la strategia di crittografia prima di implementare il cluster in Aurora DSQL. Se si archiviano dati sensibili o riservati in Aurora DSQL, prendere in considerazione l’inclusione della crittografia lato client nel piano. In questo modo è possibile crittografare i dati il più vicino possibile alla loro origine e garantirne la protezione per tutto il ciclo di vita.
**Topics**
+ [Usare AWS KMS key s con Aurora DSQL](#aws-kms-key)
+ [Utilizzo delle chiavi del cluster con Aurora DSQL](#cluster-keys)
+ [Caching della chiave del cluster](#cluster-key-caching)
### Usare AWS KMS key s con Aurora DSQL
La crittografia dei dati a riposo protegge il cluster Aurora DSQL con una AWS KMS key. Per impostazione predefinita, Aurora DSQL utilizza una Chiave di proprietà di AWS chiave di crittografia multi-tenant creata e gestita in un account del servizio Aurora DSQL. È però possibile crittografare i cluster Aurora DSQL con una chiave gestita dal cliente nel proprio Account AWS. È possibile selezionare una chiave KMS differente per ogni cluster, anche se fa parte di una configurazione multi-Regione.
Quando si crea o si aggiorna il cluster si seleziona la chiave KMS relativa. È possibile modificare la chiave KMS per un cluster in qualsiasi momento, nella console di Aurora DSQL oppure utilizzando l’operazione `UpdateCluster`. Il processo di scambio di chiavi non richiede tempo di inattività e non comporta alcun calo delle prestazioni del servizio.
**Importante**
Aurora DSQL supporta solo chiavi KMS simmetriche. Non è possibile utilizzare una chiave KMS asimmetrica per crittografare i cluster Aurora DSQL.
Una chiave gestita dal cliente fornisce i seguenti vantaggi.
+ Il cliente crea e gestisce la chiave KMS, inclusa l’impostazione delle Policy delle chiavi e delle Policy IAM per controllare l’accesso alla chiave KMS. È possibile abilitare e disabilitare la chiave KMS, abilitare e disabilitare la rotazione automatica della chiave ed eliminare la chiave KMS quando non è più in uso.
+ È possibile utilizzare una chiave gestita dal cliente con materiale di chiave importato o una chiave gestita dal cliente in un archivio delle chiavi personalizzate di cui il cliente è proprietario e gestore.
+ È possibile controllare la crittografia e la decrittografia del cluster Aurora DSQL esaminando le chiamate dell'API Aurora DSQL ai log. AWS KMS AWS CloudTrail
Tuttavia, Chiave di proprietà di AWS è gratuito e il suo utilizzo non influisce sulle quote di risorse o richieste. AWS KMS Le chiavi gestite dal cliente sono soggette a un addebito per ogni chiamata API e a tali chiavi KMS vengono applicate le quote di AWS KMS .
### Utilizzo delle chiavi del cluster con Aurora DSQL
**Aurora DSQL utilizza for the cluster AWS KMS key per generare e crittografare una chiave dati univoca per il cluster, nota come chiave del cluster.**
La chiave del cluster viene utilizzata come chiave di crittografia. Aurora DSQL utilizza questa chiave del cluster per proteggere le chiavi di crittografia dei dati utilizzate per crittografare i dati del cluster. Aurora DSQL genera una chiave di crittografia dei dati univoca per ogni struttura sottostante in un cluster, ma più di un elemento della cluster potrebbe essere protetto dalla stessa chiave di crittografia dei dati.
Per decrittografare la chiave del cluster, Aurora DSQL invia una richiesta a AWS KMS quando si accede per la prima volta a un cluster crittografato. Per mantenere il cluster disponibile, Aurora DSQL verifica periodicamente l’accesso del sistema di decrittazione alla chiave KMS, anche quando non si accede attivamente al cluster.
Aurora DSQL archivia e utilizza la chiave del cluster e le chiavi di crittografia dei dati all'esterno di. AWS KMS Protegge tutte le chiavi con la crittografia Advanced Encryption Standard (AES) e le chiavi di crittografia a 256 bit. Quindi, archivia le chiavi crittografate con i dati crittografati, in modo che siano disponibili per decrittografare i dati del cluster on demand.
Quando si modifica la chiave KMS per il cluster, Aurora DSQL crittografa nuovamente la chiave del cluster esistente con la nuova chiave KMS.
### Caching della chiave del cluster
Per evitare di chiamare AWS KMS per ogni operazione Aurora DSQL, Aurora DSQL memorizza nella cache le chiavi del cluster in testo semplice per ogni chiamante in memoria. Se Aurora DSQL riceve una richiesta per la chiave del cluster memorizzata nella cache dopo 15 minuti di inattività, invia una nuova richiesta per AWS KMS decrittografare la chiave del cluster. Questa chiamata acquisirà tutte le modifiche apportate alle politiche di accesso di AWS KMS key in AWS KMS o AWS Identity and Access Management (IAM) dopo l'ultima richiesta di decrittografia della chiave del cluster.
## Autorizzazione all'uso del tuo AWS KMS key per Aurora DSQL
Se si utilizza una chiave gestita dal cliente nel proprio account per proteggere il cluster Aurora DSQL, è necessario che le policy su tale chiave forniscano ad Aurora DSQL l’autorizzazione per usarla per conto dell’utente.
L’utente ha il pieno controllo sulle policy di una chiave gestita dal cliente. Aurora DSQL non necessita di autorizzazioni aggiuntive per utilizzare l'impostazione predefinita per proteggere i Chiave di proprietà di AWS cluster Aurora DSQL nel tuo. Account AWS
### Policy della chiave per una chiave gestita dal cliente
Quando si seleziona una chiave gestita dal cliente per proteggere un cluster Aurora DSQL, Aurora DSQL necessita dell'autorizzazione per utilizzarla per AWS KMS key conto del principale che effettua la selezione. Tale principale, un utente o un ruolo, deve disporre delle autorizzazioni richieste da Aurora DSQL. AWS KMS key È possibile fornire queste autorizzazioni in una policy della chiave o in una policy IAM.
Le autorizzazioni minime richieste da Aurora DSQL per una chiave gestita dal cliente sono:
+ `kms:Encrypt`
+ `kms:Decrypt`
+ `kms:ReEncrypt*`(per e) kms: ReEncryptFrom kms: ReEncryptTo
+ `kms:GenerateDataKey`
+ `kms:DescribeKey`
Ad esempio, la policy della chiave di esempio riportata di seguito fornisce solo le autorizzazioni necessarie. La policy ha i seguenti effetti:
+ Consente ad Aurora DSQL di utilizzare Aurora DSQL AWS KMS key nelle operazioni crittografiche, ma solo quando agisce per conto dei responsabili dell'account che dispongono del permesso di utilizzare Aurora DSQL. Se le entità principali specificate nell’istruzione della policy non dispongono dell’autorizzazione per l’utilizzo di Aurora DSQL, la chiamata non riesce, anche quando proviene dal servizio Aurora DSQL.
+ La chiave di condizione `kms:ViaService` consente le autorizzazioni solo quando la richiesta proviene da Aurora DSQL per conto delle entità principali elencate nell’istruzione della policy. Tali entità principali non possono chiamare direttamente queste operazioni.
Prima di utilizzare una policy chiave di esempio, sostituisci i principali di esempio con i principali effettivi del tuo. Account AWS
```
{
"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"
}
}
}
```
## Contesto di crittografia di Aurora DSQL
Un contesto di crittografia è un set di coppie chiave-valore che contiene dati arbitrari non segreti. Quando includi un contesto di crittografia in una richiesta di crittografia dei dati, associa AWS KMS crittograficamente il contesto di crittografia ai dati crittografati. lo stesso contesto di crittografia sia necessario per decrittografare i dati.
Aurora DSQL utilizza lo stesso contesto di crittografia in tutte le AWS KMS operazioni crittografiche. Se si utilizza una chiave gestita dal cliente per proteggere il cluster Aurora DSQL, è possibile utilizzare il contesto di crittografia per identificare l'utilizzo di tale chiave nei record e AWS KMS key nei log di controllo. Viene inoltre visualizzato come testo in chiaro nei log, ad esempio quelli di AWS CloudTrail.
Il contesto di crittografia può anche essere usato come una condizione per le autorizzazioni nelle policy.
Nelle sue richieste a AWS KMS, Aurora DSQL utilizza un contesto di crittografia con una coppia chiave-valore:
```
"encryptionContext": {
"aws:dsql:ClusterId": "w4abucpbwuxx"
},
```
La coppia chiave-valore identifica il cluster che Aurora DSQL sta crittografando. La chiave è `aws:dsql:ClusterId`. Il valore è l’identificativo del cluster.
## Monitoraggio dell'interazione di Aurora DSQL con AWS KMS
Se utilizzi una chiave gestita dal cliente per proteggere i tuoi cluster Aurora DSQL, puoi utilizzare i AWS CloudTrail log per tenere traccia delle richieste a cui Aurora DSQL invia per tuo conto. AWS KMS
Espandi le seguenti sezioni per scoprire come Aurora DSQL utilizza le AWS KMS operazioni e. `GenerateDataKey` `Decrypt`
### `GenerateDataKey`
Quando si abilita la crittografia dei dati a riposo su un cluster, Aurora DSQL crea una chiave del cluster univoca. Invia una `GenerateDataKey` richiesta a AWS KMS che specifica il nome AWS KMS key per il cluster.
L’evento che registra l’operazione `GenerateDataKey` è simile a quello del seguente evento di esempio. L’utente è l’account di servizio di Aurora DSQL. I parametri includono l'Amazon Resource Name (ARN) di AWS KMS key, un identificatore di chiave che richiede una chiave a 256 bit e il contesto di crittografia che identifica il cluster.
```
{
"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"
}
```
### Decrittografia
Quando si accede a un cluster Aurora DSQL crittografato, Aurora DSQL deve decrittografare la chiave del cluster per poter decrittografare le chiavi sottostanti nella gerarchia. Quindi decrittografa i dati nel cluster. Per decrittografare la chiave del cluster, Aurora DSQL invia una `Decrypt` richiesta a AWS KMS che specifica il nome del cluster. AWS KMS key
L’evento che registra l’operazione `Decrypt` è simile a quello del seguente evento di esempio. L'utente è il principale dell'utente Account AWS che accede al cluster. I parametri includono la chiave del cluster crittografata (come blob di testo cifrato) e il contesto di crittografia che identifica il cluster. AWS KMS ricava l'ID di dal testo cifrato. 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"
}
```
## Creazione di un cluster Aurora DSQL crittografato
Tutti i cluster Aurora DSQL sono crittografati a riposo. Per impostazione predefinita, i cluster utilizzano una chiave Chiave di proprietà di AWS gratuita oppure è possibile specificare una chiave personalizzata. AWS KMS Segui questi passaggi per creare il tuo cluster crittografato da Console di gestione AWS o da. AWS CLI
------
#### [ Console ]
**Per creare un cluster crittografato in Console di gestione AWS**
1. Accedi alla console di AWS gestione e apri la console Aurora DSQL all'indirizzo. [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql/)
1. Nel pannello di navigazione sul lato sinistro della console, scegli **Cluster**.
1. Scegli **Crea cluster** in alto a destra e seleziona **Regione singola**.
1. Nelle **Impostazioni di crittografia del cluster**, seleziona una delle seguenti opzioni.
+ Accetta le impostazioni predefinite per crittografare con un file senza Chiave di proprietà di AWS costi aggiuntivi.
+ Seleziona **Personalizza le impostazioni di crittografia (avanzate)** per specificare una chiave KMS personalizzata. Quindi, cerca o inserisci l’ID o l’alias della tua chiave KMS. In alternativa, scegli **Crea una AWS KMS chiave** per creare una nuova chiave nella AWS KMS console.
1. Scegli **Crea cluster**.
Per confermare il tipo di crittografia per il cluster, vai alla pagina **Cluster** e seleziona l’ID del cluster per visualizzarne i dettagli. Esamina la scheda **Impostazioni cluster**: l'impostazione della **chiave Cluster KMS** mostra la chiave **predefinita Aurora DSQL** per i cluster che AWS utilizzano chiavi di proprietà o l'ID della chiave per altri tipi di crittografia.
**Nota**
Se scegli di possedere e gestire la tua chiave, assicurati che la policy della chiave KMS sia impostata in modo appropriato. Per esempi e maggiori informazioni, consulta [Policy della chiave per una chiave gestita dal cliente](#key-policy-customer-managed-key).
------
#### [ CLI ]
**Per creare un cluster crittografato con l'impostazione predefinita Chiave di proprietà di AWS**
+ Utilizza il comando seguente per creare un cluster Aurora DSQL.
```
aws dsql create-cluster
```
Come illustrato nei seguenti dettagli di crittografia, lo stato di crittografia per il cluster è abilitato per impostazione predefinita e il tipo di crittografia predefinito è la chiave di proprietà di AWS. Il cluster è ora crittografato con la chiave predefinita di proprietà di AWS nell’account del servizio Aurora DSQL.
```
"encryptionDetails": {
"encryptionType" : "AWS_OWNED_KMS_KEY",
"encryptionStatus" : "ENABLED"
}
```
**Come creare un cluster crittografato con la chiave gestita dal cliente**
+ Utilizza il comando seguente per creare un cluster Aurora DSQL, sostituendo l’ID della chiave scritto in rosso con l’ID della chiave gestita da te in qualità di cliente.
```
aws dsql create-cluster \
--kms-encryption-key d41d8cd98f00b204e9800998ecf8427e
```
Come illustrato nei seguenti dettagli di crittografia, lo stato di crittografia per il cluster è abilitato per impostazione predefinita e il tipo di crittografia è la chiave KMS gestita dal cliente. Il cluster è ora crittografato con la chiave dell’utente.
```
"encryptionDetails": {
"encryptionType" : "CUSTOMER_MANAGED_KMS_KEY",
"kmsKeyArn" : "arn:aws:kms:us-east-1:111122223333:key/d41d8cd98f00b204e9800998ecf8427e",
"encryptionStatus" : "ENABLED"
}
```
------
## Rimozione o aggiornamento di una chiave per il cluster Aurora DSQL
Puoi usare o AWS CLI per aggiornare Console di gestione AWS o rimuovere le chiavi di crittografia sui cluster esistenti in Amazon Aurora DSQL. Se rimuovi una chiave senza sostituirla, Aurora DSQL utilizza l’impostazione predefinita Chiave di proprietà di AWS. Segui questi passaggi per aggiornare le chiavi di crittografia di un cluster esistente dalla console Aurora DSQL o dalla AWS CLI.
------
#### [ Console ]
**Per aggiornare o rimuovere una chiave di crittografia in Console di gestione AWS**
1. Accedi alla console di AWS gestione e apri la console Aurora DSQL all'indirizzo. [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql/)
1. Nel pannello di navigazione sul lato sinistro della console, scegli **Cluster**.
1. Nella visualizzazione a elenco, trova e seleziona la riga del cluster che desideri aggiornare.
1. Seleziona il menu **Operazioni** e quindi scegli **Modifica**.
1. Nelle **Impostazioni di crittografia del cluster**, scegli una delle seguenti opzioni per modificare le impostazioni di crittografia.
+ Se desideri passare da una chiave personalizzata a una Chiave di proprietà di AWS, deseleziona l'opzione **Personalizza le impostazioni di crittografia (avanzate)**. Le impostazioni predefinite applicheranno e crittograferanno il cluster Chiave di proprietà di AWS gratuitamente.
+ Se desideri passare da una chiave KMS personalizzata a un’altra o da una Chiave di proprietà di AWS a una chiave KMS, seleziona l’opzione **Personalizza le impostazioni di crittografia (avanzate)** se non è già selezionata. Quindi, cerca e seleziona l’ID o l’alias della chiave che desideri utilizzare. In alternativa, scegli **Crea una AWS KMS chiave** per creare una nuova chiave nella AWS KMS console.
1. Scegli **Save** (Salva).
------
#### [ CLI ]
Gli esempi seguenti mostrano come utilizzare AWS CLI per aggiornare un cluster crittografato.
Per aggiornare un cluster crittografato con quello predefinito Chiave di proprietà di AWS
```
aws dsql update-cluster \
--identifier aiabtx6icfp6d53snkhseduiqq \
--kms-encryption-key "AWS_OWNED_KMS_KEY"
```
Lo `EncryptionStatus` della descrizione del cluster è impostato su `ENABLED` ed `EncryptionType` è `AWS_OWNED_KMS_KEY`.
```
"encryptionDetails": {
"encryptionType" : "AWS_OWNED_KMS_KEY",
"encryptionStatus" : "ENABLED"
}
```
Questo cluster è ora crittografato utilizzando l'impostazione predefinita Chiave di proprietà di AWS nell'account del servizio Aurora DSQL.
Come aggiornare un cluster crittografato con una chiave gestita dal cliente per Aurora DSQL
Aggiorna il cluster crittografato, come nell’esempio seguente:
```
aws dsql update-cluster \
--identifier aiabtx6icfp6d53snkhseduiqq \
--kms-encryption-key arn:aws:kms:us-east-1:123456789012:key/abcd1234-abcd-1234-a123-ab1234a1b234
```
Lo `EncryptionStatus` della descrizione del cluster passa a `UPDATING` ed `EncryptionType` è `CUSTOMER_MANAGED_KMS_KEY`. Dopo che Aurora DSQL avrà terminato la propagazione della nuova chiave attraverso la piattaforma, lo stato di crittografia diventa `ENABLED`
```
"encryptionDetails": {
"encryptionType" : "CUSTOMER_MANAGED_KMS_KEY",
"kmsKeyArn" : "arn:aws:us-east-1:kms:key/abcd1234-abcd-1234-a123-ab1234a1b234",
"encryptionStatus" : "ENABLED"
}
```
------
**Nota**
Se scegli di possedere e gestire la tua chiave, assicurati che la policy della chiave KMS sia impostata in modo appropriato. Per esempi e maggiori informazioni, consulta [Policy della chiave per una chiave gestita dal cliente](#key-policy-customer-managed-key).
## Considerazioni sulla crittografia con Aurora DSQL
+ Aurora DSQL crittografa tutti i dati a riposo del cluster. Non è possibile disabilitare questa crittografia o crittografare solo alcuni elementi in un cluster.
+ AWS Backup crittografa i backup e tutti i cluster ripristinati da questi backup. È possibile crittografare i dati di backup AWS Backup utilizzando la chiave AWS proprietaria o una chiave gestita dal cliente.
+ Per Aurora DSQL sono stati abilitati i seguenti stati di protezione:
+ **Dati a riposo** - Aurora DSQL crittografa tutti i dati statici su supporti di archiviazione persistenti
+ **Dati in transito** - Aurora DSQL crittografa tutte le comunicazioni tramite Transport Layer Security (TLS) per impostazione predefinita
+ Quando passi a una chiave diversa, ti consigliamo di mantenere abilitata la chiave originale fino al completamento della transizione. AWS necessita della chiave originale per decrittografare i dati prima di crittografare i dati con la nuova chiave. Il processo è completo quando il `encryptionStatus` del cluster è `ENABLED` e viene visualizzata la `kmsKeyArn` della nuova chiave gestita dal cliente.
+ Quando si disabilita la chiave gestita dal cliente o si revoca l’accesso ad Aurora DSQL per l’utilizzo della chiave, lo stato del cluster diventa `IDLE`.
+ L'API SQL di Amazon Aurora Console di gestione AWS e Amazon Aurora utilizzano termini diversi per i tipi di crittografia:
+ AWS Console: nella console, vedrai `KMS` quando usi una chiave gestita dal cliente e `DEFAULT` quando usi un. Chiave di proprietà di AWS
+ API - L’API di Amazon Aurora DSQL utilizza `CUSTOMER_MANAGED_KMS_KEY` per le chiavi gestite dai clienti e `AWS_OWNED_KMS_KEY` per Chiavi di proprietà di AWS.
+ Se non si specifica una chiave di crittografia durante la creazione del cluster, Aurora DSQL crittografa automaticamente i dati utilizzando il. Chiave di proprietà di AWS
+ Puoi passare da una Chiave di proprietà di AWS chiave gestita dal cliente a una chiave gestita dal cliente in qualsiasi momento. Apporta questa modifica utilizzando Console di gestione AWS AWS CLI, o l'API SQL di Amazon Aurora.
# Gestione delle identità e degli accessi per Aurora DSQL
AWS Identity and Access Management (IAM) è uno strumento Servizio AWS che aiuta un amministratore a controllare in modo sicuro l'accesso alle risorse. AWS Gli amministratori IAM controllano chi può essere *autenticato* (chi ha effettuato l’accesso) e *autorizzato* (chi dispone delle autorizzazioni) a utilizzare le risorse di Aurora DSQL. IAM è un software Servizio AWS che puoi utilizzare senza costi aggiuntivi.
**Topics**
+ [Destinatari](#security_iam_audience)
+ [Autenticazione con identità](#security_iam_authentication)
+ [Gestione dell’accesso tramite policy](#security_iam_access-manage)
+ [Funzionamento di Amazon Aurora DSQL con IAM](security_iam_service-with-iam.md)
+ [Esempi di policy basate sull’identità per Amazon Aurora DSQL](security_iam_id-based-policy-examples.md)
+ [Risoluzione dei problemi di identità e accesso in Amazon Aurora DSQL](security_iam_troubleshoot.md)
## Destinatari
Il modo in cui utilizzi AWS Identity and Access Management (IAM) varia in base al tuo ruolo:
+ **Utente del servizio**: richiedi le autorizzazioni all’amministratore se non riesci ad accedere alle funzionalità (consulta [Risoluzione dei problemi di identità e accesso in Amazon Aurora DSQL](security_iam_troubleshoot.md))
+ **Amministratore del servizio**: determina l’accesso degli utenti e invia le richieste di autorizzazione (consulta [Funzionamento di Amazon Aurora DSQL con IAM](security_iam_service-with-iam.md))
+ **Amministratore IAM**: scrivi policy per gestire l’accesso (consulta [Esempi di policy basate sull’identità per Amazon Aurora DSQL](security_iam_id-based-policy-examples.md))
## Autenticazione con identità
L'autenticazione è il modo in cui accedi AWS utilizzando le tue credenziali di identità. Devi autenticarti come utente IAM o assumendo un ruolo IAM. Utente root dell'account AWS
Puoi accedere come identità federata utilizzando credenziali provenienti da una fonte di identità come AWS IAM Identity Center (IAM Identity Center), autenticazione Single Sign-On o credenziali. Google/Facebook Per ulteriori informazioni sull’accesso, consulta [Come accedere all’ Account AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) nella *Guida per l’utente di Accedi ad AWS *.
Per l'accesso programmatico, AWS fornisce un SDK e una CLI per firmare crittograficamente le richieste. Per ulteriori informazioni, consulta [AWS Signature Version 4 per le richieste API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) nella *Guida per l’utente di IAM*.
### Account AWS utente root
Quando si crea un Account AWS, si inizia con un'identità di accesso denominata *utente Account AWS root* che ha accesso completo a tutte Servizi AWS le risorse. Consigliamo vivamente di non utilizzare l’utente root per le attività quotidiane. Per le attività che richiedono le credenziali dell’utente root, consulta [Attività che richiedono le credenziali dell’utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) nella *Guida per l’utente IAM*.
### Identità federata
Come procedura ottimale, richiedi agli utenti umani di utilizzare la federazione con un provider di identità per accedere Servizi AWS utilizzando credenziali temporanee.
Un'*identità federata* è un utente della directory aziendale, del provider di identità Web o Directory Service che accede Servizi AWS utilizzando le credenziali di una fonte di identità. Le identità federate assumono ruoli che forniscono credenziali temporanee.
Per la gestione centralizzata degli accessi, si consiglia di utilizzare AWS IAM Identity Center. Per ulteriori informazioni, consulta [Che cos’è il Centro identità IAM?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) nella *Guida per l’utente di AWS IAM Identity Center *.
### Utenti e gruppi IAM
Un *[utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* è una identità che dispone di autorizzazioni specifiche per una singola persona o applicazione. Ti consigliamo di utilizzare credenziali temporanee invece di utenti IAM con credenziali a lungo termine. *Per ulteriori informazioni, consulta [Richiedere agli utenti umani di utilizzare la federazione con un provider di identità per accedere AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) nella Guida per l'utente IAM.*
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifica una raccolta di utenti IAM e semplifica la gestione delle autorizzazioni per gestire gruppi di utenti di grandi dimensioni. Per ulteriori informazioni, consulta [Casi d’uso per utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) nella *Guida per l’utente di IAM*.
### Ruoli IAM
Un *[ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* è un’identità con autorizzazioni specifiche che fornisce credenziali temporanee. Puoi assumere un ruolo [passando da un ruolo utente a un ruolo IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) o chiamando un'operazione AWS CLI o AWS API. Per ulteriori informazioni, consulta [Metodi per assumere un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) nella *Guida per l’utente di IAM*.
I ruoli IAM sono utili per l’accesso degli utenti federati, le autorizzazioni utente IAM temporanee, l’accesso multi-account, l’accesso multi-servizio e le applicazioni in esecuzione su Amazon EC2. Per maggiori informazioni, consultare [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente IAM*.
## Gestione dell’accesso tramite policy
Puoi controllare l'accesso AWS creando policy e associandole a AWS identità o risorse. Una policy definisce le autorizzazioni quando è associata a un'identità o a una risorsa. AWS valuta queste politiche quando un preside effettua una richiesta. La maggior parte delle politiche viene archiviata AWS come documenti JSON. Per maggiori informazioni sui documenti delle policy JSON, consulta [Panoramica delle policy JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) nella *Guida per l’utente IAM*.
Utilizzando le policy, gli amministratori specificano chi ha accesso a cosa definendo quale **principale** può eseguire **azioni** su quali **risorse** e in quali **condizioni**.
Per impostazione predefinita, utenti e ruoli non dispongono di autorizzazioni. Un amministratore IAM crea le policy IAM e le aggiunge ai ruoli, che gli utenti possono quindi assumere. Le policy IAM definiscono le autorizzazioni indipendentemente dal metodo utilizzato per eseguirle.
### Policy basate sull’identità
Le policy basate su identità sono documenti di policy di autorizzazione JSON che è possibile collegare a un’identità (utente, gruppo o ruolo). Tali policy controllano le operazioni autorizzate per l’identità, nonché le risorse e le condizioni in cui possono essere eseguite. Per informazioni su come creare una policy basata su identità, consultare [Definizione di autorizzazioni personalizzate IAM con policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente IAM*.
Le policy basate su identità possono essere *policy in linea* (con embedding direttamente in una singola identità) o *policy gestite* (policy autonome collegate a più identità). Per informazioni su come scegliere tra una policy gestita o una policy inline, consulta [Scegliere tra policy gestite e policy in linea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) nella *Guida per l’utente di IAM*.
### Policy basate sulle risorse
Le policy basate su risorse sono documenti di policy JSON che è possibile collegare a una risorsa. Gli esempi includono le *policy di trust dei ruoli* IAM e le *policy dei bucket* di Amazon S3. Nei servizi che supportano policy basate sulle risorse, gli amministratori dei servizi possono utilizzarli per controllare l’accesso a una risorsa specifica. In una policy basata sulle risorse è obbligatorio [specificare un’entità principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
Le policy basate sulle risorse sono policy inline che si trovano in tale servizio. Non è possibile utilizzare le policy AWS gestite di IAM in una policy basata sulle risorse.
### Altri tipi di policy
AWS supporta tipi di policy aggiuntivi che possono impostare le autorizzazioni massime concesse dai tipi di policy più comuni:
+ **Limiti delle autorizzazioni**: imposta il numero massimo di autorizzazioni che una policy basata su identità ha la possibilità di concedere a un’entità IAM. Per ulteriori informazioni, consulta [Limiti delle autorizzazioni per le entità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) nella *Guida per l’utente di IAM*.
+ **Politiche di controllo del servizio (SCPs)**: specificano le autorizzazioni massime per un'organizzazione o un'unità organizzativa in. AWS Organizations Per ulteriori informazioni, consultare [Policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) nella *Guida per l’utente di AWS Organizations *.
+ **Politiche di controllo delle risorse (RCPs)**: imposta le autorizzazioni massime disponibili per le risorse nei tuoi account. Per ulteriori informazioni, consulta [Politiche di controllo delle risorse (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) nella *Guida per l'AWS Organizations utente*.
+ **Policy di sessione**: policy avanzate passate come parametro quando si crea una sessione temporanea per un ruolo o un utente federato. Per maggiori informazioni, consultare [Policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) nella *Guida per l’utente IAM*.
### Più tipi di policy
Quando a una richiesta si applicano più tipi di policy, le autorizzazioni risultanti sono più complicate da comprendere. Per scoprire come si AWS determina se consentire o meno una richiesta quando sono coinvolti più tipi di policy, consulta [Logica di valutazione delle policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) nella *IAM User Guide*.
# Funzionamento di Amazon Aurora DSQL con IAM
Prima di utilizzare IAM per gestire l’accesso ad Aurora DSQL è opportuno scoprire quali funzionalità di IAM sono disponibili per l’uso con questo servizio.
**Funzionalità IAM utilizzabili con Amazon Aurora DSQL**
| Funzionalità IAM | Aurora DSQL supporta |
| --- | --- |
| [Policy basate sull’identità](#security_iam_service-with-iam-id-based-policies) | Sì |
| [Policy basate su risorse](#security_iam_service-with-iam-resource-based-policies) | Sì |
| [Operazioni di policy](#security_iam_service-with-iam-id-based-policies-actions) | Sì |
| [Risorse relative alle policy](#security_iam_service-with-iam-id-based-policies-resources) | Sì |
| [Chiavi di condizione delle policy](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Sì |
| [ACLs](#security_iam_service-with-iam-acls) | No |
| [ABAC (tag nelle policy)](#security_iam_service-with-iam-tags) | Sì |
| [Credenziali temporanee](#security_iam_service-with-iam-roles-tempcreds) | Sì |
| [Autorizzazioni del principale](#security_iam_service-with-iam-principal-permissions) | Sì |
| [Ruoli di servizio](#security_iam_service-with-iam-roles-service) | Sì |
| [Ruoli collegati al servizio](#security_iam_service-with-iam-roles-service-linked) | Sì |
*Per avere una visione di alto livello di come Aurora DSQL e AWS altri servizi funzionano con la maggior parte delle funzionalità IAM, [AWS consulta i servizi che funzionano con](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) IAM nella IAM User Guide.*
## Policy basate sull’identità per Aurora DSQL
**Supporta le policy basate sull’identità:** sì
Le policy basate sull'identità sono documenti di policy di autorizzazione JSON che è possibile allegare a un'identità (utente, gruppo di utenti o ruolo IAM). Tali policy definiscono le operazioni che utenti e ruoli possono eseguire, su quali risorse e in quali condizioni. Per informazioni su come creare una policy basata su identità, consulta [Definizione di autorizzazioni personalizzate IAM con policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente di IAM*.
Con le policy basate sull’identità di IAM, è possibile specificare quali operazioni e risorse sono consentite o respinte, nonché le condizioni in base alle quali le operazioni sono consentite o respinte. Per informazioni su tutti gli elementi utilizzabili in una policy JSON, consulta [Guida di riferimento agli elementi delle policy JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) nella *Guida per l’utente IAM*.
### Esempi di policy basate sull’identità per Aurora DSQL
Per visualizzare esempi di policy basate sull’identità di Aurora DSQL, consulta [Esempi di policy basate sull’identità per Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Policy basate sulle risorse all’interno di Aurora DSQL
**Supporta le policy basate sulle risorse**: sì
Le policy basate su risorse sono documenti di policy JSON che è possibile collegare a una risorsa. Esempi di policy basate sulle risorse sono le policy di attendibilità dei ruoli IAM e le policy di bucket Amazon S3. Nei servizi che supportano policy basate sulle risorse, gli amministratori dei servizi possono utilizzarli per controllare l’accesso a una risorsa specifica. Quando è collegata a una risorsa, una policy definisce le operazioni che un principale può eseguire su tale risorsa e a quali condizioni. In una policy basata sulle risorse è obbligatorio [specificare un’entità principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). I principali possono includere account, utenti, ruoli, utenti federati o servizi AWS. Le policy basate sulle risorse sono policy inline che si trovano in tale servizio. Non è possibile utilizzare i criteri gestiti AWS da IAM in un criterio basato sulle risorse.
[Per informazioni su come creare e gestire policy basate sulle risorse per i cluster Aurora DSQL, consulta Policy basate sulle risorse per Aurora DSQL.](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/resource-based-policies.html)
## Operazioni di policy per Aurora DSQL
**Supporta le operazioni di policy:** si
Gli amministratori possono utilizzare le policy JSON per specificare chi ha accesso a cosa. AWS In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L'elemento `Action` di una policy JSON descrive le operazioni che è possibile utilizzare per consentire o negare l'accesso in una policy. Includere le operazioni in una policy per concedere le autorizzazioni a eseguire l’operazione associata.
Per visualizzare un elenco di operazioni di Amazon Aurora DSQL, consulta [Operazioni definite da Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions) nella *Guida di riferimento all’autorizzazione del servizio*.
Le operazioni delle policy in Aurora DSQL utilizzano il seguente prefisso prima dell’operazione:
```
dsql
```
Per specificare più operazioni in una sola istruzione, occorre separarle con la virgola.
```
"Action": [
"dsql:action1",
"dsql:action2"
]
```
Per visualizzare esempi di policy basate sull’identità di Aurora DSQL, consulta [Esempi di policy basate sull’identità per Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Risorse relative alle policy per Aurora DSQL
**Supporta le risorse relative alle policy:** sì
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento JSON `Resource` della policy specifica l’oggetto o gli oggetti ai quali si applica l’operazione. Come best practice, specifica una risorsa utilizzando il suo [nome della risorsa Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Per le azioni che non supportano le autorizzazioni a livello di risorsa, si utilizza un carattere jolly (\$1) per indicare che l’istruzione si applica a tutte le risorse.
```
"Resource": "*"
```
*Per visualizzare un elenco dei tipi di risorse Aurora DSQL e relativi ARNs, consulta [Resources Defined by Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-resources-for-iam-policies) nel Service Authorization Reference.* Per informazioni sulle operazioni con cui è possibile specificare l’ARN di ogni risorsa, consulta [Operazioni definite da Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions).
Per visualizzare esempi di policy basate sull’identità di Aurora DSQL, consulta [Esempi di policy basate sull’identità per Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Chiavi di condizione delle policy per Aurora DSQL
**Supporta le chiavi di condizione delle policy specifiche del servizio:** sì
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento `Condition` specifica quando le istruzioni vengono eseguite in base a criteri definiti. È possibile compilare espressioni condizionali che utilizzano [operatori di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), ad esempio uguale a o minore di, per soddisfare la condizione nella policy con i valori nella richiesta. Per visualizzare tutte le chiavi di condizione AWS globali, consulta le chiavi di [contesto delle condizioni AWS globali nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) per l'*utente IAM*.
Per un elenco delle chiavi di condizione di Aurora DSQL, consulta [Chiavi di condizione per Amazon Aurora DSQL](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonauroradsql.html#amazonauroradsql-policy-keys) in *Guida di riferimento all’autorizzazione del servizio*. Per sapere con quali azioni e risorse è possibile utilizzare una chiave di condizione, consulta [Operazioni definite da Amazon Aurora DSQL](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonauroradsql.html#amazonauroradsql-actions-as-permissions).
Per visualizzare esempi di policy basate sull’identità di Aurora DSQL, consulta [Esempi di policy basate sull’identità per Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## ACLs in Aurora SQL
**Supporti ACLs**: no
Le liste di controllo degli accessi (ACLs) controllano quali principali (membri dell'account, utenti o ruoli) dispongono delle autorizzazioni per accedere a una risorsa. ACLs sono simili alle politiche basate sulle risorse, sebbene non utilizzino il formato del documento di policy JSON.
## ABAC con Aurora DSQL
**Supporta ABAC (tag nelle policy):** sì
Il controllo degli accessi basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base ad attributi chiamati tag. È possibile allegare tag a entità e AWS risorse IAM, quindi progettare politiche ABAC per consentire operazioni quando il tag del principale corrisponde al tag sulla risorsa.
Per controllare l’accesso basato su tag, fornire informazioni sui tag nell’[elemento condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) di una policy utilizzando le chiavi di condizione `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`.
Se un servizio supporta tutte e tre le chiavi di condizione per ogni tipo di risorsa, il valore per il servizio è **Sì**. Se un servizio supporta tutte e tre le chiavi di condizione solo per alcuni tipi di risorsa, allora il valore sarà **Parziale**.
Per maggiori informazioni su ABAC, consulta [Definizione delle autorizzazioni con autorizzazione ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) nella *Guida per l’utente di IAM*. Per visualizzare un tutorial con i passaggi per l’impostazione di ABAC, consulta [Utilizzo del controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) nella *Guida per l’utente di IAM*.
## Utilizzo di credenziali temporanee con Aurora DSQL
**Supporta le credenziali temporanee:** sì
Le credenziali temporanee forniscono l'accesso a breve termine alle AWS risorse e vengono create automaticamente quando si utilizza la federazione o si cambia ruolo. AWS consiglia di generare dinamicamente credenziali temporanee anziché utilizzare chiavi di accesso a lungo termine. Per ulteriori informazioni, consulta [Credenziali di sicurezza temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Servizi AWS compatibili con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) nella *Guida per l’utente IAM*.
## Autorizzazioni dell’entità principale tra servizi per Aurora DSQL
**Supporta l’inoltro delle sessioni di accesso (FAS):** sì
Le sessioni di accesso inoltrato (FAS) utilizzano le autorizzazioni del principale che chiama e, in combinazione con la richiesta Servizio AWS, Servizio AWS per effettuare richieste ai servizi downstream. Per i dettagli delle policy relative alle richieste FAS, consultare [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Ruoli di servizio per Aurora DSQL
**Supporta i ruoli di servizio:** sì
Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che un servizio assume per eseguire operazioni per tuo conto. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall’interno di IAM. Per maggiori informazioni, consultare la sezione [Creazione di un ruolo per delegare le autorizzazioni a un Servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *Guida per l’utente di IAM*.
**avvertimento**
La modifica delle autorizzazioni per un ruolo di servizio potrebbe compromettere la funzionalità di Aurora DSQL. Modifica i ruoli di servizio solo quando Aurora DSQL fornisce le indicazioni per farlo.
## Ruoli collegati ai servizi per Aurora DSQL
**Supporta i ruoli collegati ai servizi:** sì
Un ruolo collegato al servizio è un tipo di ruolo di servizio collegato a un. Servizio AWS Il servizio può assumere il ruolo per eseguire un’operazione per tuo conto. I ruoli collegati al servizio vengono visualizzati nel tuo account Account AWS e sono di proprietà del servizio. Un amministratore IAM può visualizzare le autorizzazioni per i ruoli collegati al servizio, ma non modificarle.
Per maggiori informazioni su come creare e gestire i ruoli collegati al servizio per Aurora DSQL, consulta [Utilizzo dei ruoli collegati al servizio in Aurora DSQL](working-with-service-linked-roles.md).
# Esempi di policy basate sull’identità per Amazon Aurora DSQL
Per impostazione predefinita, gli utenti e i ruoli non dispongono dell’autorizzazione per creare o modificare risorse di Aurora DSQL. Per concedere agli utenti l’autorizzazione a eseguire azioni sulle risorse di cui hanno bisogno, un amministratore IAM può creare policy IAM.
Per informazioni su come creare una policy basata su identità IAM utilizzando questi documenti di policy JSON di esempio, consulta [Creazione di policy IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) nella *Guida per l’utente di IAM*.
*Per informazioni dettagliate sulle azioni e sui tipi di risorse definiti da Aurora DSQL, incluso il formato di ARNs per ogni tipo di risorsa, consulta [Actions, Resources and Condition Keys for Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html) nel Service Authorization Reference.*
**Topics**
+ [Best practice per le policy](#security_iam_service-with-iam-policy-best-practices)
+ [Utilizzo della console di Aurora DSQL](#security_iam_id-based-policy-examples-console)
+ [Consentire agli utenti di visualizzare le loro autorizzazioni](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Consenti la gestione dei cluster e la connessione al database](#security_iam_id-based-policy-examples-cluster-management)
+ [Accesso alle risorse Aurora DSQL basato su tag](#security_iam_id-based-policy-examples-tag-based-access)
## Best practice per le policy
Le policy basate sull’identità determinano se qualcuno può creare, accedere o eliminare risorse di Aurora DSQL nell’account. Queste operazioni possono comportare costi aggiuntivi per l’ Account AWS. Quando si creano o modificano policy basate sull’identità, seguire queste linee guida e raccomandazioni:
+ **Inizia con le politiche AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni** *a utenti e carichi di lavoro, utilizza le politiche gestite che concedono le autorizzazioni per molti casi d'uso comuni.AWS * Sono disponibili nel tuo. Account AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per maggiori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o [Policy gestite da AWS per le funzioni dei processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
+ **Applicazione delle autorizzazioni con privilegio minimo** - Quando si impostano le autorizzazioni con le policy IAM, concedere solo le autorizzazioni richieste per eseguire un’attività. È possibile farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come *autorizzazioni con privilegio minimo*. Per maggiori informazioni sull’utilizzo di IAM per applicare le autorizzazioni, consulta [Policy e autorizzazioni in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) nella *Guida per l’utente di IAM*.
+ **Condizioni d’uso nelle policy IAM per limitare ulteriormente l’accesso** - Per limitare l’accesso ad azioni e risorse è possibile aggiungere una condizione alle policy. Ad esempio, è possibile scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzando SSL. Puoi anche utilizzare le condizioni per concedere l'accesso alle azioni del servizio se vengono utilizzate tramite uno specifico Servizio AWS, ad esempio CloudFormation. Per maggiori informazioni, consultare la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l’utente di IAM*.
+ **Utilizzo dello strumento di analisi degli accessi IAM per convalidare le policy IAM e garantire autorizzazioni sicure e funzionali** - Lo strumento di analisi degli accessi IAM convalida le policy nuove ed esistenti in modo che aderiscano al linguaggio (JSON) della policy IAM e alle best practice di IAM. Lo strumento di analisi degli accessi IAM offre oltre 100 controlli delle policy e consigli utili per creare policy sicure e funzionali. Per maggiori informazioni, consultare [Convalida delle policy per il Sistema di analisi degli accessi IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) nella *Guida per l’utente di IAM*.
+ **Richiedi l'autenticazione a più fattori (MFA**): se hai uno scenario che richiede utenti IAM o un utente root nel Account AWS tuo, attiva l'MFA per una maggiore sicurezza. Per richiedere la MFA quando vengono chiamate le operazioni API, aggiungere le condizioni MFA alle policy. Per maggiori informazioni, consultare [Protezione dell’accesso API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) nella *Guida per l’utente di IAM*.
Per maggiori informazioni sulle best practice in IAM, consulta [Best practice di sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nella *Guida per l’utente di IAM*.
## Utilizzo della console di Aurora DSQL
Per accedere alla console di Amazon Aurora DSQL, è necessario disporre di un set di autorizzazioni minimo. Queste autorizzazioni devono consentire di elencare e visualizzare i dettagli sulle risorse Aurora DSQL presenti nel tuo. Account AWS Se crei una policy basata sull’identità più restrittiva rispetto alle autorizzazioni minime richieste, la console non funzionerà nel modo previsto per le entità (utenti o ruoli) associate a tale policy.
Non è necessario consentire autorizzazioni minime per la console per gli utenti che effettuano chiamate solo verso o l' AWS CLI API. AWS Al contrario, è opportuno concedere l’accesso solo alle operazioni che corrispondono all’operazione API che stanno cercando di eseguire.
Per garantire che utenti e ruoli possano ancora utilizzare la console Aurora DSQL, collega anche Aurora DSQL `AmazonAuroraDSQLConsoleFullAccess` o `AmazonAuroraDSQLReadOnlyAccess` AWS la policy gestita alle entità. Per maggiori informazioni, consulta [Aggiunta di autorizzazioni a un utente](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) nella *Guida per l’utente di IAM*.
## Consentire agli utenti di visualizzare le loro autorizzazioni
Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono collegate alla relativa identità utente. Questa politica include le autorizzazioni per completare questa azione sulla console o utilizzando l'API o a livello di codice. 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": "*"
}
]
}
```
## Consenti la gestione dei cluster e la connessione al database
La seguente policy concede a un utente IAM l'autorizzazione a gestire e connettersi a uno specifico cluster Aurora DSQL. La policy riguarda la gestione del cluster e le azioni di connessione a un singolo cluster Amazon Resource Name (ARN), pur `dsql:ListClusters` consentendo tutte le risorse perché questa azione non supporta le autorizzazioni a livello di risorsa.
Questo esempio utilizza per connettersi al ruolo. `dsql:DbConnectAdmin` `admin` Per connetterti invece con un ruolo di database personalizzato, sostituisci `dsql:DbConnectAdmin` con`dsql:DbConnect`. Per ulteriori informazioni, consulta [Autenticazione e autorizzazione per 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": "*"
}
]
}
```
------
## Accesso alle risorse Aurora DSQL basato su tag
È possibile utilizzare le condizioni nella policy basata sull'identità per controllare l'accesso alle risorse DSQL di Aurora in base ai tag. L'esempio seguente mostra come è possibile creare una politica che consenta la visualizzazione di un cluster. Tuttavia, la politica concede l'autorizzazione solo se il tag del cluster `Owner` ha il valore del nome utente di quell'utente. Questa policy concede anche le autorizzazioni necessarie per completare questa azione nella console.
------
#### [ 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}"
}
}
}
]
}
```
------
Puoi allegare questa policy agli utenti IAM nel tuo account. Se un utente denominato `richard-roe` tenta di visualizzare un cluster Aurora DSQL, al cluster deve essere contrassegnato o. `Owner=richard-roe` `owner=richard-roe` Altrimenti IAM nega l'accesso. La chiave di tag di condizione `Owner` corrisponde a `Owner` e `owner` perché i nomi delle chiavi di condizione non effettuano la distinzione tra maiuscole e minuscole. Per maggiori informazioni, consultare la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l’utente di IAM*.
La seguente politica consente a un utente di creare cluster solo se contrassegna il cluster con il proprio nome utente come. `Owner` Consente inoltre di aggiungere tag solo ai cluster già di proprietà dell'utente.
------
#### [ 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}"
}
}
}
]
}
```
------
# Risoluzione dei problemi di identità e accesso in Amazon Aurora DSQL
Utilizzare le informazioni seguenti per diagnosticare e risolvere i problemi comuni che possono verificarsi durante l’utilizzo di Aurora DSQL e IAM.
**Topics**
+ [Non si possiede l’autorizzazione a eseguire un’operazione in Aurora DSQL](#security_iam_troubleshoot-no-permissions)
+ [Non sono autorizzato a eseguire iam: PassRole](#security_iam_troubleshoot-passrole)
+ [Desidero consentire a persone esterne a me di accedere Account AWS alle mie risorse Aurora DSQL](#security_iam_troubleshoot-cross-account-access)
## Non si possiede l’autorizzazione a eseguire un’operazione in Aurora DSQL
Se si riceve un errore che indica che non si dispone dell’autorizzazione per eseguire un’operazione, le policy devono essere aggiornate in modo che sia consentito eseguire tale operazione.
L’errore di esempio seguente si verifica quando l’utente IAM `mateojackson` tenta di utilizzare la console per visualizzare i dettagli relativi alla risorsa `my-dsql-cluster` ma non dispone delle autorizzazioni `GetCluster`.
```
User: iam:::user/mateojackson is not authorized to perform: GetCluster on resource: my-dsql-cluster
```
In questo caso, la policy per l’utente `mateojackson` deve essere aggiornata per consentire l’accesso alla risorsa `my-dsql-cluster` utilizzando l’azione `GetCluster`.
Per ulteriore assistenza con l’accesso, contattare l’amministratore. L’amministratore è la persona che ti ha fornito le credenziali di accesso.
## Non sono autorizzato a eseguire iam: PassRole
Se si riceve un errore che indica che non si dispone dell’autorizzazione per eseguire l’operazione `iam:PassRole`, le policy devono essere aggiornate in modo che sia consentito trasmettere un ruolo ad Aurora DSQL.
Alcuni Servizi AWS consentono di passare un ruolo esistente a quel servizio invece di creare un nuovo ruolo di servizio o un ruolo collegato al servizio. Per eseguire questa operazione, è necessario disporre delle autorizzazioni per trasmettere il ruolo al servizio.
L’errore di esempio seguente si verifica quando un utente IAM denominato `marymajor` cerca di utilizzare la console per eseguire un’operazione in Aurora DSQL. Tuttavia, l’azione richiede che il servizio disponga delle autorizzazioni concesse da un ruolo di servizio. Mary non dispone delle autorizzazioni per trasmettere il ruolo al servizio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In questo caso, le policy di Mary devono essere aggiornate per poter eseguire l’operazione `iam:PassRole`.
Se hai bisogno di aiuto, contatta il tuo AWS amministratore. L’amministratore è la persona che ti ha fornito le credenziali di accesso.
## Desidero consentire a persone esterne a me di accedere Account AWS alle mie risorse Aurora DSQL
È possibile creare un ruolo con il quale utenti in altri account o persone esterne all’organizzazione possono accedere alle tue risorse. È possibile specificare chi è attendibile per l’assunzione del ruolo. Per i servizi che supportano politiche basate sulle risorse o liste di controllo degli accessi (ACLs), puoi utilizzare tali politiche per concedere alle persone l'accesso alle tue risorse.
Per maggiori informazioni, consulta gli argomenti seguenti:
+ Per capire se Aurora DSQL supporta queste funzionalità, consulta [Funzionamento di Amazon Aurora DSQL con IAM](security_iam_service-with-iam.md).
+ Per scoprire come fornire l'accesso alle tue risorse attraverso Account AWS le risorse di tua proprietà, consulta [Fornire l'accesso a un utente IAM in un altro Account AWS di tua proprietà](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) nella *IAM* User Guide.
+ Per scoprire come fornire l'accesso alle tue risorse a terze parti Account AWS, consulta [Fornire l'accesso a soggetti Account AWS di proprietà di terze parti](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) nella *Guida per l'utente IAM*.
+ Per informazioni su come fornire l'accesso tramite la federazione delle identità, consulta [Fornire l'accesso a utenti autenticati esternamente (federazione delle identità)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) nella *Guida per l'utente IAM*.
+ Per informazioni sulle differenze di utilizzo tra ruoli e policy basate su risorse per l’accesso multi-account, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente di IAM*.
# Policy basate sulle risorse per Aurora DSQL
Utilizza le policy basate sulle risorse per Aurora DSQL per limitare o concedere l'accesso ai cluster tramite documenti di policy JSON che si allegano direttamente alle risorse del cluster. Queste policy forniscono un controllo dettagliato su chi può accedere al cluster e in quali condizioni.
I cluster Aurora DSQL sono accessibili dalla rete Internet pubblica per impostazione predefinita, con l'autenticazione IAM come controllo di sicurezza principale. Le politiche basate sulle risorse consentono di aggiungere restrizioni di accesso, in particolare per bloccare l'accesso dalla rete Internet pubblica.
Le politiche basate sulle risorse funzionano insieme alle politiche basate sull'identità IAM. AWS valuta entrambi i tipi di policy per determinare le autorizzazioni finali per qualsiasi richiesta di accesso al cluster. Per impostazione predefinita, i cluster Aurora DSQL sono accessibili all'interno di un account. Se un utente o un ruolo IAM dispone delle autorizzazioni Aurora DSQL, può accedere ai cluster senza alcuna policy basata sulle risorse allegata.
**Nota**
Le modifiche alle policy basate sulle risorse alla fine sono coerenti e in genere entrano in vigore entro un minuto.
*Per ulteriori informazioni sulle differenze tra le politiche basate sull'identità e le politiche basate sulle risorse, consulta Politiche basate sull'identità e politiche basate sulle risorse nella [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html).*
## Quando utilizzare le politiche basate sulle risorse
Le politiche basate sulle risorse sono particolarmente utili in questi scenari:
+ *Controllo degli accessi basato sulla rete*: limita l'accesso in base al VPC o all'indirizzo IP da cui provengono le richieste o blocca completamente l'accesso pubblico a Internet. Usa chiavi condizionali come `aws:SourceVpc` e `aws:SourceIp` per controllare l'accesso alla rete.
+ *Più team o applicazioni*: concedi l'accesso allo stesso cluster a più team o applicazioni. Anziché gestire le singole policy IAM per ogni principale, definisci le regole di accesso una sola volta nel cluster.
+ *Accesso condizionale complesso*: controlla l'accesso in base a più fattori come gli attributi di rete, il contesto della richiesta e gli attributi utente. È possibile combinare più condizioni in un'unica politica.
+ *Governance della sicurezza centralizzata*: consenti ai proprietari dei cluster di controllare l'accesso utilizzando una sintassi delle AWS policy familiare che si integra con le pratiche di sicurezza esistenti.
**Nota**
L'accesso tra account non è ancora supportato per le policy basate sulle risorse di Aurora DSQL, ma sarà disponibile nelle versioni future.
Quando qualcuno tenta di connettersi al cluster Aurora DSQL, AWS valuta la policy basata sulle risorse come parte del contesto di autorizzazione, insieme a qualsiasi policy IAM pertinente, per determinare se la richiesta deve essere consentita o rifiutata.
Le politiche basate sulle risorse possono concedere l'accesso ai principali all'interno dello stesso account del cluster. AWS Per i cluster multiregionali, ogni cluster regionale dispone di una propria politica basata sulle risorse, che consente controlli di accesso specifici per regione quando necessario.
**Nota**
Le chiavi del contesto delle condizioni possono variare tra le regioni (come VPC IDs).
**Topics**
+ [Quando usare](#rbp-when-to-use)
+ [Crea con le politiche](rbp-create-cluster.md)
+ [Aggiungere e modificare le politiche](rbp-attach-policy.md)
+ [Visualizza la politica](rbp-view-policy.md)
+ [Rimuovi politica](rbp-remove-policy.md)
+ [Esempi di policy](rbp-examples.md)
+ [Blocca l'accesso pubblico](rbp-block-public-access.md)
+ [Operazioni API](rbp-api-operations.md)
# Creazione di cluster con politiche basate sulle risorse
È possibile allegare politiche basate sulle risorse durante la creazione di un nuovo cluster per garantire che i controlli di accesso siano attivi sin dall'inizio. Ogni cluster può avere una singola policy in linea collegata direttamente al cluster.
## AWS Console di gestione
**Per aggiungere una policy basata sulle risorse durante la creazione del cluster**
1. Accedi alla console di AWS gestione e apri la console Aurora DSQL all'indirizzo. [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)
1. Scegli **Crea cluster**.
1. Configura il nome del cluster, i tag e le impostazioni multiregionali in base alle esigenze.
1. Nella sezione **Impostazioni del cluster**, individua l'opzione di policy **basata sulle risorse**.
1. Attiva **Aggiungi politica basata sulle risorse**.
1. Inserisci il documento della policy nell'editor JSON. Ad esempio, per bloccare l'accesso pubblico a Internet:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect",
"dsql:DbConnectAdmin"
],
"Condition": {
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
1. Puoi utilizzare **Edit statement** o **Add new statement** per creare la tua politica.
1. Completa la configurazione rimanente del cluster e scegli **Crea cluster**.
## AWS CLI
Usa il `--policy` parametro quando crei un cluster per allegare una policy in linea:
```
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
------
#### [ 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());
```
------
# Aggiungere e modificare politiche basate sulle risorse per i cluster
## AWS Console di gestione
**Per aggiungere una policy basata sulle risorse a un cluster esistente**
1. Accedi alla console di AWS gestione e apri la console Aurora DSQL all'indirizzo. [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)
1. Scegli il tuo cluster dall'elenco dei cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Autorizzazioni**.
1. **Nella sezione **Politica basata sulle risorse, scegli Aggiungi politica**.**
1. Inserisci il tuo documento di policy nell'editor JSON. Puoi utilizzare **Modifica dichiarazione** o **Aggiungi nuova dichiarazione** per creare la tua politica.
1. Scegli **Aggiungi policy**.
**Per modificare una politica esistente basata sulle risorse**
1. Accedi alla console di AWS gestione e apri la console Aurora DSQL all'indirizzo. [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)
1. Scegli il tuo cluster dall'elenco dei cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Autorizzazioni**.
1. **Nella sezione **Politica basata sulle risorse**, scegli Modifica.**
1. Modifica il documento di policy nell'editor JSON. Puoi utilizzare **Modifica dichiarazione** o **Aggiungi nuova dichiarazione** per aggiornare la tua politica.
1. Scegli **Save changes** (Salva modifiche).
## AWS CLI
Usa il `put-cluster-policy` comando per allegare una nuova politica o aggiornare una politica esistente su un cluster:
```
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
------
#### [ 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);
```
------
# Visualizzazione delle politiche basate sulle risorse
È possibile visualizzare le politiche basate sulle risorse allegate ai cluster per comprendere gli attuali controlli di accesso in vigore.
## AWS Console di gestione
**Per visualizzare le politiche basate sulle risorse**
1. Accedi alla console di AWS gestione e apri la console Aurora DSQL all'indirizzo. [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)
1. Scegli il tuo cluster dall'elenco dei cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Autorizzazioni**.
1. Visualizza la politica allegata nella sezione Politica **basata sulle risorse**.
## AWS CLI
Usa il `get-cluster-policy` comando per visualizzare la politica basata sulle risorse di un cluster:
```
aws dsql get-cluster-policy --identifier your_cluster_id
```
## AWS SDKs
------
#### [ 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());
```
------
# Rimozione delle politiche basate sulle risorse
È possibile rimuovere le politiche basate sulle risorse dai cluster per modificare i controlli di accesso.
**Importante**
Quando rimuovi tutte le policy basate sulle risorse da un cluster, l'accesso sarà controllato interamente da policy basate sull'identità IAM.
## AWS Console di gestione
**Per rimuovere una politica basata sulle risorse**
1. Accedi alla console di AWS gestione e apri la console Aurora DSQL all'indirizzo. [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)
1. Scegli il tuo cluster dall'elenco dei cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Autorizzazioni**.
1. **Nella sezione **Politica basata sulle risorse**, scegli Elimina.**
1. Nella finestra di dialogo di conferma, digita **confirm** per confermare l'eliminazione.
1. Scegli **Elimina**.
## AWS CLI
Usa il `delete-cluster-policy` comando per rimuovere una policy da un cluster:
```
aws dsql delete-cluster-policy --identifier your_cluster_id
```
## AWS SDKs
------
#### [ 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");
```
------
# Esempi di politiche comuni basate sulle risorse
Questi esempi mostrano modelli comuni per il controllo dell'accesso ai cluster Aurora DSQL. È possibile combinare e modificare questi modelli per soddisfare i requisiti di accesso specifici.
## Blocca l'accesso pubblico a Internet
Questa policy blocca le connessioni ai cluster Aurora DSQL dalla rete Internet pubblica (non VPC). La policy non specifica da quale VPC i clienti possono connettersi, ma solo che devono connettersi da un VPC. Per limitare l'accesso a un VPC specifico, utilizzalo `aws:SourceVpc` con l'operatore delle `StringEquals` condizioni.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect",
"dsql:DbConnectAdmin"
],
"Condition": {
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
**Nota**
Questo esempio serve solo `aws:SourceVpc` a verificare la presenza di connessioni VPC. Le chiavi `aws:VpcSourceIp` e `aws:SourceVpce` condition forniscono una granularità aggiuntiva ma non sono necessarie per il controllo di accesso di base basato solo su VPC.
Per fornire un'eccezione per ruoli specifici, utilizza invece questa politica:
```
{
"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"
]
}
}
}
]
}
```
## Limita l'accesso all' AWS organizzazione
Questa politica limita l'accesso ai responsabili all'interno di un' AWS organizzazione:
```
{
"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"
}
}
}
]
}
```
## Limita l'accesso a una specifica unità organizzativa
Questa politica limita l'accesso ai responsabili all'interno di una specifica unità organizzativa (OU) di un' AWS organizzazione, fornendo un controllo più granulare rispetto all'accesso a livello di organizzazione:
```
{
"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/*"
}
}
}
]
}
```
## Politiche di cluster multiregionali
Per i cluster multiregionali, ogni cluster regionale mantiene la propria politica in materia di risorse, che consente controlli specifici per regione. Ecco un esempio con politiche diverse per regione:
*politica us-east-1:*
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpc": "vpc-east1-id"
},
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
*politica us-east-2:*
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect"
],
"Condition": {
"StringEquals": {
"aws:SourceVpc": "vpc-east2-id"
}
}
}
]
}
```
**Nota**
Le chiavi del contesto delle condizioni possono variare tra Regioni AWS (come VPC IDs).
# Blocco dell'accesso pubblico con politiche basate sulle risorse in Aurora DSQL
Block Public Access (BPA) è una funzionalità che identifica e impedisce l'associazione di policy basate sulle risorse che garantiscono l'accesso pubblico ai cluster Aurora DSQL tra i tuoi account. AWS Con BPA, puoi impedire l'accesso pubblico alle tue risorse Aurora DSQL. BPA esegue controlli durante la creazione o la modifica di una policy basata sulle risorse e aiuta a migliorare il livello di sicurezza con Aurora DSQL.
Il BPA utilizza il [ragionamento automatico](https://aws.amazon.com/what-is/automated-reasoning/) per analizzare l’accesso concesso dalla policy basata su risorse e avvisa l’utente se tali autorizzazioni vengono rilevate al momento della gestione di una policy basata su risorse. L’analisi verifica l’accesso a tutte le istruzioni della policy basata su risorse, alle azioni e al set di chiavi di condizione utilizzate nelle policy.
**Importante**
BPA aiuta a proteggere le risorse impedendo che l'accesso pubblico venga concesso tramite le politiche basate sulle risorse direttamente collegate alle risorse Aurora DSQL, come i cluster. Oltre ad attivare il BPA, controlla attentamente le seguenti policy per verificare che non concedano l’accesso pubblico:
Politiche basate sull'identità collegate ai principali associati (ad esempio, ruoli IAM) AWS
Politiche basate sulle risorse collegate alle AWS risorse associate (ad esempio, AWS chiavi Key Management Service (KMS))
È necessario assicurarsi che il [principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) non includa una voce `*` o che una delle chiavi di condizione specificate limiti l’accesso dei principali alla risorsa. Se la policy basata sulle risorse concede l'accesso pubblico al cluster su più account AWS , Aurora DSQL impedirà all'utente di creare o modificare la policy fino a quando le specifiche all'interno della policy non saranno corrette e considerate non pubbliche.
È possibile rendere una policy non pubblica specificando uno o più principi all’interno del blocco del `Principal`. Il seguente esempio di policy basata su risorse blocca l’accesso pubblico specificando due principali.
```
{
"Effect": "Allow",
"Principal": {
"AWS": [
"123456789012",
"111122223333"
]
},
"Action": "dsql:*",
"Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/cluster-id"
}
```
Inoltre, le policy che limitano l’accesso specificando determinate chiavi di condizione non sono considerate pubbliche. Oltre alla valutazione del principale specificato nella policy basata su risorse, vengono utilizzate le seguenti [chiavi di condizione attendibili](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) per completare la valutazione di una policy basata su risorse per l’accesso non pubblico:
+ `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`
Inoltre, affinché una policy basata su risorse non sia pubblica, i valori del nome della risorsa Amazon (ARN) e le chiavi di stringa non devono contenere caratteri jolly o variabili. Se la propria policy basata su risorse utilizza la chiave `aws:PrincipalIsAWSService`, è necessario assicurarsi di aver impostato il valore della chiave su true.
La policy seguente limita l’accesso all’utente `Ben` nell’account specificato. La condizione rende il `Principal` vincolato e non lo considera pubblico.
```
{
"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"
}
}
}
```
L’esempio seguente di una policy basata su risorse non pubblica limita `sourceVPC` a utilizzare l’operatore `StringEquals`.
```
{
"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"
]
}
}
}
]
}
```
# Operazioni dell'API Aurora DSQL e politiche basate sulle risorse
Le policy basate sulle risorse in Aurora DSQL controllano l'accesso a specifiche operazioni API. Le seguenti sezioni elencano tutte le operazioni dell'API Aurora DSQL organizzate per categoria, con un'indicazione di quali supportano le politiche basate sulle risorse.
La colonna *Supporta RBP* indica se l'operazione dell'API è soggetta alla valutazione delle politiche basate sulle risorse quando una policy è collegata al cluster.
## Etichetta APIs
| Operazione API | Description | Supporta RBP |
| --- | --- | --- |
| [ListTagsForResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_ListTagsForResource.html) | Elenca i tag per una risorsa Aurora DSQL | Sì |
| [TagResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_TagResource.html) | Aggiunge tag a una risorsa Aurora DSQL | Sì |
| [UntagResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UntagResource.html) | Rimuove i tag da una risorsa Aurora DSQL | Sì |
## Gestione dei cluster APIs
| Operazione API | Description | Supporta RBP |
| --- | --- | --- |
| [CreateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_CreateCluster.html) | Crea un nuovo cluster | No |
| [DeleteCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_DeleteCluster.html) | Elimina un cluster | Sì |
| [GetCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetCluster.html) | Recupera informazioni su un cluster | Sì |
| [GetVpcEndpointServiceName](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetVpcEndpointServiceName.html) | Recupera il nome del servizio endpoint VPC per un cluster | Sì |
| [ListClusters](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_ListClusters.html) | Elenca i cluster presenti nel tuo account | No |
| [UpdateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UpdateCluster.html) | Aggiorna la configurazione di un cluster | Sì |
## Proprietà multiregionale APIs
| Operazione API | Description | Supporta RBP |
| --- | --- | --- |
| [AddPeerCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_AddPeerCluster.html) | Aggiunge un cluster peer a una configurazione multiregionale | Sì |
| [PutMultiRegionProperties](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutMultiRegionProperties.html) | Imposta proprietà multiregionali per un cluster | Sì |
| [PutWitnessRegion](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutWitnessRegion.html) | Imposta la regione di riferimento per un cluster multiregionale | Sì |
## Politica basata sulle risorse APIs
| Operazione API | Description | Supporta RBP |
| --- | --- | --- |
| [DeleteClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_DeleteClusterPolicy.html) | Elimina la politica basata sulle risorse da un cluster | Sì |
| [GetClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetClusterPolicy.html) | Recupera la politica basata sulle risorse per un cluster | Sì |
| [PutClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutClusterPolicy.html) | Crea o aggiorna la politica basata sulle risorse per un cluster | Sì |
## AWS Fault Injection Service APIs
| Operazione API | Description | Supporta RBP |
| --- | --- | --- |
| [InjectError](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_InjectError.html) | Inietta errori per i test di iniezione in caso di guasto | No |
## Backup e ripristino APIs
| Operazione API | Description | Supporta RBP |
| --- | --- | --- |
| [GetBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetBackupJob.html) | Recupera informazioni su un job di backup | No |
| [GetRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetRestoreJob.html) | Recupera informazioni su un processo di ripristino | No |
| [StartBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StartBackupJob.html) | Avvia un processo di backup per un cluster | Sì |
| [StartRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StartRestoreJob.html) | Avvia un processo di ripristino da un backup | No |
| [StopBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StopBackupJob.html) | Interrompe un processo di backup in esecuzione | No |
| [StopRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StopRestoreJob.html) | Interrompe un processo di ripristino in esecuzione | No |
# Utilizzo dei ruoli collegati al servizio in Aurora DSQL
[Aurora DSQL utilizza ruoli collegati ai servizi AWS Identity and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) Un ruolo collegato al servizio è un tipo di ruolo IAM univoco collegato direttamente ad Aurora DSQL. I ruoli collegati ai servizi sono predefiniti da Aurora DSQL e includono tutte le autorizzazioni richieste dal servizio per chiamare Servizi AWS per conto del cluster Aurora DSQL.
I ruoli collegati al servizio semplificano la configurazione dei piani di dimensionamento perché permettono di evitare l’aggiunta manuale delle autorizzazioni necessarie. Quando si crea un cluster, Aurora DSQL crea automaticamente un ruolo collegato al servizio per conto dell’utente. È possibile eliminare il ruolo collegato al servizio solo dopo aver eliminato tutti i cluster. Così facendo, le risorse di Aurora DSQL restano protette, perché non è possibile rimuovere inavvertitamente le autorizzazioni necessarie per l’accesso alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati al servizio, consulta [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cercare i servizi che riportano **Sì** nella colonna **Ruolo associato ai servizi**. Scegliere **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato al servizio per tale servizio.
I ruoli collegati al servizio sono disponibili in tutte le Regioni Aurora DSQL supportate.
## Autorizzazioni del ruolo collegato al servizio per Aurora DSQL
Aurora DSQL utilizza il ruolo collegato al servizio denominato: consente ad `AWSServiceRoleForAuroraDsql` Amazon Aurora DSQL di creare e gestire risorse per tuo conto. AWS Questo ruolo collegato ai servizi è collegato alle seguenti policy gestite: [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDsqlServiceLinkedRolePolicy.html).
**Nota**
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato al servizio è necessario configurare le relative autorizzazioni. Potrebbe essere visualizzato il messaggio di errore seguente: `You don't have the permissions to create an Amazon Aurora DSQL service-linked role`. Se viene visualizzato questo messaggio, assicurarsi che le autorizzazioni seguenti siano abilitate:
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateDsqlServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": "dsql.amazonaws.com"
}
}
}
]
}
```
Per maggiori informazioni, consulta [Autorizzazioni del ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions.html).
## Creare un ruolo collegato al servizio
Non è necessario creare manualmente un ruolo collegato ai DSQLService LinkedRolePolicy servizi Aurora. Aurora DSQL crea il ruolo collegato al servizio per conto dell’utente. Se il ruolo DSQLService LinkedRolePolicy collegato al servizio Aurora è stato eliminato dall'account, Aurora DSQL crea il ruolo quando si crea un nuovo cluster Aurora DSQL.
## Modifica di un ruolo collegato al servizio
Aurora DSQL non consente di modificare il ruolo collegato al servizio Aurora. DSQLService LinkedRolePolicy Dopo aver creato un ruolo collegato al servizio, non è possibile modificarne il nome, perché potrebbero farvi riferimento diverse entità. Tuttavia, puoi modificare la descrizione del ruolo utilizzando la console IAM, la AWS Command Line Interface (AWS CLI) o l'API IAM.
## Eliminazione di un ruolo collegato al servizio
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, consigliamo di eliminare il ruolo. In questo modo non sarà più presente un’entità non utilizzata che non viene monitorata e gestita attivamente.
Prima di poter eliminare un ruolo legato a un servizio per un account, è necessario arrestare ed eliminare qualsiasi cluster nell’account.
Puoi utilizzare la console IAM AWS CLI, l'o l'API IAM per eliminare un ruolo collegato al servizio. Per maggiori informazioni, consulta [Creazione di un ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#delete-service-linked-role) nella Guida per l’utente di IAM.
## Regioni supportate per i ruoli collegati al servizio di Aurora DSQL
Aurora DSQL supporta l’utilizzo di ruoli collegati al servizio in tutte le Regioni in cui il servizio è disponibile. Per maggiori informazioni, consulta [Regioni ed endpoint di AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# Utilizzo di chiavi di condizione IAM con Amazon Aurora DSQL
Quando si concedono le autorizzazioni in Aurora DSQL, è possibile specificare le condizioni che determinano il modo in cui una policy di autorizzazione viene applicata. Di seguito sono illustrati esempi di come è possibile utilizzare le chiavi di condizione nelle policy di autorizzazioni IAM di Aurora DSQL.
## Esempio 1: concedere l'autorizzazione per creare un cluster in uno specifico Regione AWS
Le seguenti policy concedono l’autorizzazione a creare cluster nelle Regioni Stati Uniti orientali (Virginia settentrionale) e Stati Uniti orientali (Ohio). Questa policy utilizza l’ARN della risorsa per limitare le Regioni consentite, quindi Aurora DSQL può creare cluster solo se tale ARN è specificato nella sezione `Resource` della policy.
------
#### [ 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"
}
]
}
```
------
## Esempio 2: concedere l'autorizzazione a creare un cluster multiregionale in s specifici Regione AWS
Le seguenti policy concedono l’autorizzazione a creare cluster multi-Regione nelle Regioni Stati Uniti orientali (Virginia settentrionale) e Stati Uniti orientali (Ohio). Questa policy utilizza l’ARN della risorsa per limitare le Regioni consentite, quindi Aurora DSQL può creare cluster multi-Regione solo se questo ARN è specificato nella sezione `Resource` della policy. Tenere presente che la creazione di cluster multi-Regione richiede anche le autorizzazioni `PutMultiRegionProperties`, `PutWitnessRegion` e `AddPeerCluster` in ciascuna Regione specificata.
------
#### [ 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/*"
]
}
]
}
```
------
## Esempio 3: concessione dell’autorizzazione per creare un cluster multi-Regione con una Regione testimone specifica
La seguente policy utilizza una chiave di condizione `dsql:WitnessRegion` di Aurora DSQL e consente a un utente di creare cluster multi-Regione con una Regione testimone negli Stati Uniti occidentali (Oregon). Se non si specifica la condizione `dsql:WitnessRegion`, è possibile utilizzare qualsiasi Regione come Regione testimone.
------
#### [ 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"
]
}
}
}
]
}
```
------
# Risposta agli incidenti in Amazon Aurora DSQL
Per AWS, la sicurezza ha la massima priorità. Come parte del modello di responsabilità condivisa del AWS cloud, AWS gestisce un data center, una rete e un'architettura software che soddisfa i requisiti delle organizzazioni più sensibili alla sicurezza. AWS è responsabile di qualsiasi risposta agli incidenti relativi al servizio SQL di Amazon Aurora. Inoltre, in qualità di AWS cliente, condividi la responsabilità di mantenere la sicurezza nel cloud. Ciò significa che puoi controllare la sicurezza che scegli di implementare dagli AWS strumenti e dalle funzionalità a cui hai accesso. Inoltre, l’utente è responsabile della risposta agli incidenti relativi alla sua parte del modello di responsabilità condivisa.
Stabilendo una linea di base di sicurezza che soddisfi gli obiettivi delle applicazioni eseguite nel cloud, l’utente è in grado di rilevare deviazioni a cui è possibile rispondere. Per comprendere l’impatto che la risposta agli incidenti e le tue scelte hanno sugli obiettivi aziendali, ti invitiamo a consulta le seguenti risorse:
+ [AWS Guida alla risposta agli incidenti di sicurezza](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
+ [AWS Le migliori pratiche per la sicurezza, l'identità e la conformità](https://aws.amazon.com/architecture/security-identity-compliance/)
+ [White paper sulla prospettiva di sicurezza del AWS Cloud Adoption Framework (CAF)](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html)
[Amazon GuardDuty](https://aws.amazon.com/guardduty/) è un servizio gestito di rilevamento delle minacce che monitora continuamente i comportamenti dannosi o non autorizzati per aiutare i clienti a proteggere i carichi di lavoro Account AWS e identificare attività potenzialmente sospette prima che si trasformino in un incidente. Monitora attività come chiamate API insolite o implementazioni potenzialmente non autorizzate, indicando possibili compromissioni di account o risorse o ricognizioni da parte di malintenzionati. Ad esempio, Amazon GuardDuty è in grado di rilevare attività sospette in Amazon Aurora APIs DSQL, ad esempio un utente che accede da una nuova posizione e crea un nuovo cluster.
# Convalida della conformità per Amazon Aurora DSQL
Per sapere se un Servizio AWS programma rientra nell'ambito di specifici programmi di conformità, consulta Servizi AWS la sezione [Scope by Compliance Program Servizi AWS](https://aws.amazon.com/compliance/services-in-scope/) e scegli il programma di conformità che ti interessa. Per informazioni generali, consulta Programmi di [AWS conformità Programmi](https://aws.amazon.com/compliance/programs/) di di .
È possibile scaricare report di audit di terze parti utilizzando AWS Artifact. Per ulteriori informazioni, consulta [Scaricamento dei report in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
La vostra responsabilità di conformità durante l'utilizzo Servizi AWS è determinata dalla sensibilità dei dati, dagli obiettivi di conformità dell'azienda e dalle leggi e dai regolamenti applicabili. Per ulteriori informazioni sulla responsabilità di conformità durante l'utilizzo Servizi AWS, consulta la [Documentazione AWS sulla sicurezza](https://docs.aws.amazon.com/security/).
# Resilienza in Amazon Aurora DSQL
L'infrastruttura AWS globale è costruita attorno a zone di disponibilità ( Regioni AWS AZ). Regioni AWS forniscono più zone di disponibilità fisicamente separate e isolate, collegate con reti a bassa latenza, ad alto throughput e altamente ridondanti. Con le zone di disponibilità è possibile progettare e gestire applicazioni e database che eseguono automaticamente il failover tra zone di disponibilità senza interruzioni. Le zone di disponibilità sono più disponibili, tolleranti ai guasti e scalabili rispetto alle infrastrutture a data center singolo o multiplo tradizionali. Aurora DSQL è progettato in modo da poter sfruttare l'infrastruttura AWS regionale fornendo al contempo la massima disponibilità del database. Per impostazione predefinita, i cluster a Regione singola in Aurora DSQL offrono una disponibilità Multi-AZ, che offre tolleranza ai principali guasti dei componenti e alle interruzioni dell’infrastruttura che potrebbero influire sull’accesso a una zona di disponibilità completa. I cluster multi-Regione offrono tutti i vantaggi della resilienza Multi-AZ, pur garantendo una disponibilità del database estremamente costante, anche nei casi in cui la Regione AWS dovesse risultare inaccessibile ai client delle applicazioni.
Per ulteriori informazioni sulle Regioni AWS zone di disponibilità, consulta [AWS Global](https://aws.amazon.com/about-aws/global-infrastructure/) Infrastructure.
Oltre all'infrastruttura AWS globale, Aurora DSQL offre diverse funzionalità per supportare le esigenze di resilienza e backup dei dati.
## Backup e ripristino
Aurora DSQL supporta il backup e il ripristino con. Console di backup AWSÈ possibile eseguire un backup e un ripristino completi per i cluster a Regione singola e multi-Regione. Per maggiori informazioni, consultare [Backup e ripristino per Amazon Aurora DSQLBackup e ripristino](backup-aurora-dsql.md).
## Replica
In base alla progettazione, Aurora DSQL esegue il commit di tutte le transazioni di scrittura in un registro delle transazioni distribuito e replica in modo sincrono tutti i dati di registro impegnati nelle repliche di archiviazione degli utenti in tre repliche. AZs I cluster multi-Regione offrono funzionalità complete di replica interregionale tra Regioni di lettura e scrittura.
Una Regione testimone designata supporta le scritture relative ai soli log delle transazioni e non consuma spazio di archiviazione. Le Regioni testimone non dispongono di un endpoint. Ciò significa che le Regioni testimone archiviano solo i registri delle transazioni crittografati, non richiedono alcuna amministrazione o configurazione e non sono accessibili dagli utenti. Se la regione di riferimento viene compromessa, non vi è alcun impatto sulla disponibilità del cluster. Le transazioni di scrittura potrebbero subire un lieve aumento della latenza fino al ripristino della regione di riferimento.
I log delle transazioni e l’archiviazione degli utenti di Aurora DSQL sono distribuiti con tutti i dati presentati agli elaboratori delle query di Aurora DSQL come un unico volume logico. Aurora DSQL divide, unisce e replica automaticamente i dati in base all’intervallo di chiavi primarie del database e ai modelli di accesso. Aurora DSQL dimensiona automaticamente le repliche di lettura, sia verso l’alto che verso il basso, in base alla frequenza di accesso in lettura.
Le repliche dell’archiviazione del cluster sono distribuite su un parco di sistemi di archiviazione multi-tenant. Se un componente o un’AZ vengono danneggiati, Aurora DSQL reindirizza automaticamente l’accesso ai componenti sopravvissuti e ripara in modo asincrono le repliche mancanti. Una volta che Aurora DSQL corregge le repliche danneggiate, le aggiunge automaticamente al quorum di archiviazione e le rende disponibili per il cluster.
## Elevata disponibilità
Per impostazione predefinita, i cluster a Regione singola e multi-Regione in Aurora DSQL sono attivi e non è necessario effettuare manualmente il provisioning, configurare o riconfigurare alcun cluster. Aurora DSQL automatizza completamente il ripristino del cluster, eliminando la necessità delle tradizionali operazioni di failover primario-secondario. La replica è sempre sincrona e viene eseguita in modalità multipla AZs, quindi non vi è alcun rischio di perdita dei dati a causa del ritardo della replica o del failover su un database secondario asincrono durante il ripristino in caso di errore.
I cluster a regione singola forniscono un endpoint ridondante Multi-AZ che consente automaticamente l'accesso simultaneo con una forte coerenza dei dati su tre. AZs Ciò significa che le repliche di storage degli utenti su ognuna di queste tre applicazioni restituiscono AZs sempre lo stesso risultato a uno o più lettori e sono sempre disponibili per ricevere scritture. Questa forte coerenza e resilienza Multi-AZ sono disponibili in tutte le Regioni per i cluster multi-Regione di Aurora DSQL. Ciò significa che i cluster multi-Regione forniscono due endpoint regionali fortemente coerenti, in modo che i client possano leggere o scrivere indiscriminatamente in entrambe le Regioni senza ritardi di replica al momento del commit.
Aurora DSQL offre una disponibilità del 99,99% per i cluster a Regione singola e del 99,999% per i cluster multi-Regione.
## Test di iniezione di guasti
Amazon Aurora DSQL si integra con AWS Fault Injection Service (AWS FIS), un servizio completamente gestito per l'esecuzione di esperimenti di iniezione di errori controllati per migliorare la resilienza di un'applicazione. Utilizzando AWS FIS, puoi:
+ Creare modelli di esperimenti che definiscono scenari di errore specifici
+ Eseguire l’iniezione di guasti (elevati tassi di errore di connessione al cluster) per convalidare i meccanismi di gestione e ripristino degli errori delle applicazioni
+ Verifica il comportamento delle applicazioni in più regioni per convalidare lo spostamento del traffico delle applicazioni tra un momento e l'altro Regioni AWS quando Regione AWS si verificano alti tassi di errore di connessione
Ad esempio, in un cluster multi-Regione che copre gli Stati Uniti orientali (Virginia settentrionale) e gli Stati Uniti orientali (Ohio), è possibile eseguire un esperimento negli Stati Uniti orientali (Ohio) per verificare gli errori in tali aree mentre gli Stati Uniti orientali (Virginia settentrionale) continuano le normali operazioni. Questo test controllato consente di identificare e risolvere potenziali problemi prima che influiscano sui carichi di lavoro di produzione.
Per un elenco completo delle [azioni AWS FIS supportate, consulta gli obiettivi](https://docs.aws.amazon.com/fis/latest/userguide/action-sequence.html#action-targets) delle azioni nella *guida per l'AWS FIS utente*.
*Per informazioni sulle azioni DSQL di Amazon Aurora disponibili in, AWS FIS consulta il riferimento alle azioni [DSQL di Aurora](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dsql-actions-reference) nella Guida per l'utente.AWS FIS *
Per iniziare a eseguire esperimenti di iniezione di guasti, consulta [Pianificazione degli esperimenti di AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.html) nella *Guida per l’utente di AWS FIS *.
# Sicurezza dell’infrastruttura in Amazon Aurora DSQL
In quanto servizio gestito, Amazon Aurora DSQL è protetto dalle procedure di sicurezza di rete AWS globali descritte nelle [Best Practices for Security, Identity](https://aws.amazon.com/architecture/security-identity-compliance) and Compliance.
Si utilizzano chiamate API AWS pubblicate per accedere ad Aurora DSQL attraverso la rete. I client devono supportare Transport Layer Security (TLS) 1.2 o versioni successive. I client devono, inoltre, supportare le suite di cifratura con PFS (Perfect Forward Secrecy), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
Inoltre, le richieste devono essere firmate utilizzando un ID chiave di accesso e una chiave di accesso segreta associata a un principale IAM. In alternativa è possibile utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) per generare credenziali di sicurezza temporanee per sottoscrivere le richieste.
# Gestione e connessione ai cluster SQL di Amazon Aurora tramite AWS PrivateLink
Con AWS PrivateLink Amazon Aurora DSQL, puoi effettuare il provisioning degli endpoint Amazon VPC di interfaccia (endpoint di interfaccia) nel tuo Amazon Virtual Private Cloud. Questi endpoint sono accessibili direttamente dalle applicazioni locali tramite Amazon VPC Direct Connect e/o in un altro modo di peering Regione AWS tramite Amazon VPC. Utilizzando AWS PrivateLink e interfacciando gli endpoint, puoi semplificare la connettività di rete privata dalle tue applicazioni ad Aurora DSQL.
Le applicazioni all’interno di Amazon VPC possono accedere ad Aurora DSQL utilizzando gli endpoint di interfaccia Amazon VPC senza richiedere indirizzi IP pubblici.
Gli endpoint dell'interfaccia sono rappresentati da una o più interfacce di rete elastiche (ENIs) a cui vengono assegnati indirizzi IP privati dalle sottoreti del tuo Amazon VPC. Le richieste ad Aurora DSQL tramite endpoint di interfaccia rimangono sulla rete. AWS Per maggiori informazioni su come connettere il VPC Amazon alla rete on-premises, consulta la [Guida per l’utente di Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/) e la [Guida per l’utente della VPN di AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html).
Per informazioni generali sugli endpoint di interfaccia, consulta [Accedere a un AWS servizio utilizzando un endpoint Amazon VPC con interfaccia](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) nella [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink)Guida per l'utente.
## Tipi di endpoint Amazon VPC per Aurora DSQL
Aurora DSQL richiede due diversi tipi di endpoint. AWS PrivateLink
1. *Endpoint di gestione* - Questo endpoint viene utilizzato per operazioni amministrative, come `get`, `create`, `update`, `delete` e `list` sui cluster Aurora DSQL. Consulta [Gestione dei cluster Aurora DSQL utilizzando AWS PrivateLink](#managing-dsql-clusters-using-privatelink).
1. *Endpoint di connessione* - Questo endpoint viene utilizzato per la connessione ai cluster Aurora DSQL tramite client PostgreSQL. Per informazioni, consulta [Connessione ai cluster Aurora DSQL tramite AWS PrivateLink](#privatelink-connecting-clusters).
## Considerazioni sull'utilizzo AWS PrivateLink per Aurora DSQL
Le considerazioni relative ad Amazon VPC valgono per AWS PrivateLink Aurora DSQL. Per ulteriori informazioni, consulta [Accedere a un AWS servizio utilizzando un endpoint e [AWS PrivateLink quote](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html) VPC di interfaccia](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#vpce-interface-limitations) nella Guida. AWS PrivateLink
## Gestione dei cluster Aurora DSQL utilizzando AWS PrivateLink
È possibile utilizzare AWS Command Line Interface o AWS Software Development Kit (SDKs) per gestire i cluster Aurora DSQL tramite gli endpoint dell'interfaccia Aurora DSQL.
### Creazione di un endpoint Amazon VPC
Per creare un endpoint di interfaccia Amazon VPC, consulta Creare [un endpoint Amazon VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) nella Guida. AWS PrivateLink
```
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 \
```
Per utilizzare il nome DNS regionale predefinito per le richieste API Aurora DSQL, non disabilitare il DNS privato quando si crea l’endpoint dell’interfaccia Aurora DSQL. Quando il DNS privato è abilitato, le richieste al servizio Aurora DSQL effettuate direttamente dal tuo Amazon VPC verranno risolte automaticamente nell’indirizzo IP privato dell’endpoint Amazon VPC, anziché nel nome DNS pubblico. Quando il DNS privato è abilitato, le richieste di Aurora DSQL effettuate direttamente dal tuo Amazon VPC verranno risolte automaticamente nell’endpoint Amazon VPC.
Se il DNS privato non è abilitato, utilizzate i `--endpoint-url` parametri `--region` and con AWS CLI i comandi per gestire i cluster Aurora DSQL tramite gli endpoint dell'interfaccia Aurora DSQL.
### Recupero dell’elenco dei cluster tramite un URL di endpoint
Nell'esempio seguente, sostituisci il nome DNS Regione AWS `us-east-1` e il nome DNS dell'`vpce-1a2b3c4d-5e6f.dsql.us-east-1.vpce.amazonaws.com`ID dell'endpoint Amazon VPC con le tue informazioni.
```
aws dsql --region us-east-1 --endpoint-url https://vpce-1a2b3c4d-5e6f.dsql.us-east-1.vpce.amazonaws.com list-clusters
```
### Operazioni API
Fai riferimento alla [Guida di riferimento delle API di Aurora DSQL](CHAP_api_reference.md) per la documentazione sulla gestione delle risorse in Aurora DSQL.
### Gestione delle policy degli endpoint
Testando e configurando accuratamente le policy degli endpoint Amazon VPC, puoi contribuire a garantire che il cluster Aurora DSQL sia sicuro, conforme e allineato ai requisiti di governance e controllo degli accessi specifici della tua organizzazione.
**Esempio: policy di accesso ad Aurora DSQL completa**
Le seguenti policy garantiscono l’accesso completo a tutte le azioni e le risorse di Aurora DSQL tramite l’endpoint Amazon VPC specificato.
```
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": "*"
}
]
}'
```
**Esempio: policy di accesso ad Aurora DSQL con restrizioni**
La seguente policy consente solo queste operazioni su Aurora DSQL.
+ `CreateCluster`
+ `GetCluster`
+ `ListClusters`
Tutte le altre operazioni Aurora DSQL vengono negate.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"dsql:CreateCluster",
"dsql:GetCluster",
"dsql:ListClusters"
],
"Resource": "*"
}
]
}
```
------
## Connessione ai cluster Aurora DSQL tramite AWS PrivateLink
Una volta che l' AWS PrivateLink endpoint è configurato e attivo, puoi connetterti al tuo cluster Aurora DSQL utilizzando un client PostgreSQL. Le istruzioni di connessione riportate di seguito descrivono i passaggi per creare il nome host corretto per la connessione tramite l'endpoint. AWS PrivateLink
### Configurazione di un endpoint di connessione AWS PrivateLink
******Fase 1: recupero del nome del servizio del proprio cluster**
Quando crei un AWS PrivateLink endpoint per la connessione al cluster, devi prima recuperare il nome del servizio specifico del cluster.
------
#### [ AWS CLI ]
```
aws dsql get-vpc-endpoint-service-name \
--region us-east-1 \
--identifier your-cluster-id
```
Risposta di esempio
```
{
"serviceName": "com.amazonaws.us-east-1.dsql-fnh4"
}
```
Il nome del servizio include un identificatore, come `dsql-fnh4` nell’esempio. Questo identificatore è necessario anche per creare il nome host per la connessione al cluster.
------
#### [ 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);
```
------
**Fase 2: creazione dell’endpoint Amazon VPC**
Utilizzando il nome del servizio ottenuto nel passaggio precedente, crea un endpoint Amazon VPC.
**Importante**
Le istruzioni di connessione riportate di seguito funzionano solo per la connessione ai cluster quando il DNS privato è abilitato. Non utilizzare il flag `--no-private-dns-enabled` durante la creazione dell’endpoint, poiché ciò impedirà il corretto funzionamento delle istruzioni di connessione riportate di seguito. Se di disabilita il DNS privato, sarà necessario creare il proprio record DNS privato con wildcard che punti all’endpoint creato.
------
#### [ 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
```
**Risposta di esempio**
```
{
"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 ]
Usa un URL endpoint per 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);
```
------
**Configurazione aggiuntiva durante la connessione Direct Connect tramite peering Amazon VPC**
Potrebbero essere necessarie alcune configurazioni aggiuntive per connettersi ai cluster Aurora DSQL utilizzando un endpoint di AWS PrivateLink connessione da dispositivi locali tramite peering Amazon VPC o. Direct Connect Questa configurazione non è necessaria se l'applicazione è in esecuzione nello stesso Amazon VPC dell'endpoint. AWS PrivateLink Le voci DNS private create sopra non verranno risolte correttamente al di fuori dell'Amazon VPC dell'endpoint, ma puoi creare i tuoi record DNS privati che si risolvono nell'endpoint di connessione. AWS PrivateLink
Crea un record DNS CNAME privato che punti al nome di dominio completo dell'endpoint. AWS PrivateLink Il nome di dominio del record DNS creato deve essere costruito con i seguenti componenti:
1. L’identificatore del servizio dal nome del servizio. Ad esempio: `dsql-fnh4`
1. Il Regione AWS
Crea il record DNS CNAME con un nome di dominio nel seguente formato: `*.service-identifier.region.on.aws`
Il formato del nome di dominio è importante per due motivi:
1. Il nome host utilizzato per connettersi ad Aurora DSQL deve corrispondere al certificato del server di Aurora DSQL quando si utilizza la modalità SSL. `verify-full` Ciò garantisce il massimo livello di sicurezza della connessione.
1. Aurora DSQL utilizza la parte relativa all'ID del cluster del nome host utilizzata per connettersi ad Aurora DSQL per identificare il cluster di connessione.
Se non è possibile creare record DNS privati, è comunque possibile connettersi ad Aurora DSQL. Per informazioni, consulta [Connessione a un cluster Aurora DSQL utilizzando un AWS PrivateLink endpoint senza DNS privato](#connecting-cluster-id-option).
### Connessione a un cluster Aurora DSQL utilizzando un endpoint di connessione AWS PrivateLink
Una volta che l' AWS PrivateLink endpoint è configurato e attivo (verifica che lo `State` sia`available`), puoi connetterti al tuo cluster Aurora DSQL utilizzando un client PostgreSQL. Per istruzioni sull'uso di AWS SDKs, puoi seguire le guide in [Programmazione con Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/programming-with.html). È necessario modificare l’endpoint del cluster in modo che corrisponda al formato del nome host.
#### Costruzione del nome host
Il nome host per la connessione è AWS PrivateLink diverso dal nome host DNS pubblico. È necessario costruirlo utilizzando i seguenti componenti.
1. `Your-cluster-id`
1. L’identificatore del servizio dal nome del servizio. Ad esempio: `dsql-fnh4`
1. Il. Regione AWS Ad esempio: `us-east-1`
Utilizzare il seguente formato: `cluster-id.service-identifier.region.on.aws`
**Esempio: connessione tramite 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
```
#### Connessione a un cluster Aurora DSQL utilizzando un AWS PrivateLink endpoint senza DNS privato
Le istruzioni di connessione riportate sopra si basano su record DNS privati. Se la tua applicazione è in esecuzione nello stesso Amazon VPC dell' AWS PrivateLink endpoint, i record DNS vengono creati automaticamente. In alternativa, se ti connetti da dispositivi locali tramite peering Amazon VPC oppure Direct Connect, puoi creare i tuoi record DNS privati. Tuttavia, la configurazione dei record DNS non è sempre possibile a causa delle restrizioni di rete imposte dai team di sicurezza. Se l'applicazione deve connettersi tramite Direct Connect o da un Amazon VPC peered e la configurazione dei record DNS non è possibile, puoi comunque connetterti ad Aurora DSQL.
Aurora DSQL utilizza la parte relativa all'ID del cluster del nome host per identificare il cluster di connessione, ma se la configurazione del record DNS non è possibile, Aurora DSQL supporta la specificazione del cluster di destinazione utilizzando l'opzione di connessione. `amzn-cluster-id` Con questa opzione, è possibile utilizzare il nome di dominio completo dell' AWS PrivateLink endpoint come nome host durante la connessione.
**Importante**
Quando ci si connette con il nome di dominio o l'indirizzo IP completamente qualificato dell' AWS PrivateLink endpoint, la modalità SSL non è supportata. `verify-full` Per questo motivo, è preferibile configurare un DNS privato.
**Esempio: specificazione dell'opzione di connessione con l'ID del cluster utilizzando 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
```
### Risoluzione dei problemi con AWS PrivateLink
#### Problemi e soluzioni comuni
La tabella seguente elenca i problemi e le soluzioni comuni relativi a AWS PrivateLink con Aurora DSQL.
| Problema | Possibile causa | Soluzione |
| --- | --- | --- |
| Timeout di connessione | Gruppo di sicurezza non configurato correttamente | Utilizza il sistema di analisi della reperibilità Amazon VPC per assicurarti che la configurazione della rete consenta il traffico sulla porta 5432. |
| Errore di risoluzione del DNS | DNS privato non abilitato | Verifica che l’endpoint Amazon VPC sia stato creato con DNS privato abilitato. |
| Errori di autenticazione | Credenziali errate o token scaduto | Genera un nuovo token di autenticazione e verificare il nome utente. |
| Il nome del servizio non è stato trovato | ID del cluster non corretto | Ricontrolla l'ID del cluster e Regione AWS quando recuperi il nome del servizio. |
### Risorse correlate
Per maggiori informazioni, consulta le seguenti risorse:
+ [Guida per l’utente di Amazon Aurora DSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-dsql.html)
+ [Documentazione di AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)
+ [Accedi ai servizi tramite AWSAWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)
# Analisi della configurazione e delle vulnerabilità in Amazon Aurora DSQL
AWS gestisce le attività di sicurezza di base come l'applicazione di patch al sistema operativo guest (OS) e al database, la configurazione del firewall e il disaster recovery. Queste procedure sono state riviste e certificate dalle terze parti appropriate. Per ulteriori dettagli, consulta le seguenti risorse :
+ [Modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [Amazon Web Services: panoramica dei processi di sicurezza (whitepaper)](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf)
# Prevenzione del confused deputy tra servizi
Il problema confused deputy è un problema di sicurezza in cui un’entità che non dispone dell’autorizzazione per eseguire un’azione può costringere un’entità maggiormente privilegiata a eseguire l’azione. Nel frattempo AWS, l'impersonificazione tra servizi può portare al confuso problema del vicesceriffo. La rappresentazione tra servizi può verificarsi quando un servizio (il *servizio chiamante*) effettua una chiamata a un altro servizio (il *servizio chiamato*). Il servizio chiamante può essere manipolato per utilizzare le proprie autorizzazioni e agire sulle risorse di un altro cliente, a cui normalmente non avrebbe accesso. Per evitare ciò, AWS fornisce strumenti per poterti a proteggere i tuoi dati per tutti i servizi con entità di servizio a cui è stato concesso l’accesso alle risorse del tuo account.
Consigliamo di utilizzare le chiavi di contesto delle condizioni globali [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) e [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) nelle policy delle risorse per limitare le autorizzazioni con cui Amazon Aurora DSQL fornisce un altro servizio alla risorsa. Utilizzare `aws:SourceArn` se si desidera consentire l’associazione di una sola risorsa all’accesso tra servizi. Utilizzare `aws:SourceAccount` se si desidera consentire l’associazione di qualsiasi risorsa in tale account all’uso tra servizi.
Il modo più efficace per proteggersi dal problema “confused deputy” è quello di utilizzare la chiave di contesto della condizione globale `aws:SourceArn` con l’ARN completo della risorsa. Se non si conosce l’ARN completo della risorsa o si scelgono più risorse, utilizzare la chiave di contesto della condizione globale `aws:SourceArn` con caratteri jolly (`*`) per le parti sconosciute dell’ARN. Ad esempio, `arn:aws:dsql:*:123456789012:*`.
Se il valore `aws:SourceArn` non contiene l’ID account, ad esempio un ARN di un bucket Amazon S3, è necessario utilizzare entrambe le chiavi di contesto delle condizioni globali per limitare le autorizzazioni.
Il valore di `aws:SourceArn` deve essere ResourceDescription.
L’esempio seguente mostra il modo in cui puoi utilizzare le chiavi di contesto delle condizioni globali `aws:SourceArn` e `aws:SourceAccount` in Aurora DSQL per prevenire il problema confused deputy.
------
#### [ 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"
}
}
}
}
```
------
# Best practice di sicurezza di Aurora DSQL
Aurora DSQL fornisce una serie di funzionalità di sicurezza da valutare durante lo sviluppo e l’implementazione delle policy di sicurezza. Le seguenti best practice sono linee guida generali e non rappresentano una soluzione di sicurezza completa. Poiché queste best practice potrebbero non essere appropriate o sufficienti per l’ambiente, sono da considerare come considerazioni utili anziché prescrizioni.
**Topics**
+ [Best practice relative alla sicurezza di rilevamento per Aurora DSQL](best-practices-security-detective.md)
+ [Best practice relative alla sicurezza preventiva per Aurora DSQL](best-practices-security-preventative.md)
# Best practice relative alla sicurezza di rilevamento per Aurora DSQL
Oltre ai seguenti modi per utilizzare in modo sicuro Aurora DSQL, [consulta](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) Sicurezza AWS Well-Architected Tool in per scoprire come le tecnologie cloud migliorano la tua sicurezza.
** CloudWatch Allarmi Amazon**
Utilizzando Amazon CloudWatch alarms, controlli una singola metrica per un periodo di tempo specificato. Se la metrica supera una determinata soglia, viene inviata una notifica a un argomento o una policy di Amazon SNS. AWS Auto Scaling CloudWatch gli allarmi non richiamano azioni perché si trovano in uno stato particolare. È necessario invece cambiare lo stato e mantenerlo per un numero di periodi specificato.
**Tagging delle risorse di Aurora DSQL per identificazione e automazione**
Puoi assegnare metadati alle tue AWS risorse sotto forma di tag. Ogni tag è una semplice etichetta composta da una chiave definita dal cliente e un valore facoltativo che può semplificare la gestione, la ricerca e il filtro delle risorse.
Il tagging consente l’implementazione di gruppi controllati. Anche se non ci sono tipi di tag inerenti, è possibile suddividere le risorse in base a scopo, proprietario, ambiente o altri criteri. Di seguito vengono mostrati alcuni esempi:
+ Sicurezza - Utilizzato per determinare requisiti quali la crittografia.
+ Riservatezza - Un identificatore per il livello di riservatezza dei dati specifico supportato da una risorsa.
+ Ambiente - Utilizzato per differenziare tra infrastruttura di sviluppo, test e produzione.
Puoi assegnare metadati alle tue AWS risorse sotto forma di tag. Ogni tag è una semplice etichetta composta da una chiave definita dal cliente e un valore facoltativo che può semplificare la gestione, la ricerca e il filtro delle risorse.
Il tagging consente l’implementazione di gruppi controllati. Anche se non ci sono tipi di tag inerenti, i tag consentono di suddividere le risorse in base a scopo, proprietario, ambiente o altri criteri. Di seguito vengono mostrati alcuni esempi.
+ Sicurezza - Utilizzato per determinare requisiti quali la crittografia.
+ Riservatezza - Un identificatore per il livello di riservatezza dei dati specifico supportato da una risorsa.
+ Ambiente Utilizzato per differenziare tra infrastruttura di sviluppo, test e produzione.
Per ulteriori informazioni, consulta [Best practice per l' AWS etichettatura](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) delle risorse.
# Best practice relative alla sicurezza preventiva per Aurora DSQL
Oltre ai seguenti modi per utilizzare in modo sicuro Aurora DSQL, [consulta](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) Sicurezza AWS Well-Architected Tool in per scoprire come le tecnologie cloud migliorano la tua sicurezza.
**Utilizza i ruoli IAM per autenticare l’accesso ad Aurora DSQL.**
Gli utenti, le applicazioni e gli altri utenti Servizi AWS che accedono ad Aurora DSQL devono includere AWS credenziali valide nell'API e nelle AWS richieste. AWS CLI Non è necessario archiviare AWS le credenziali direttamente nell'applicazione o nelle istanze EC2. Si tratta di credenziali a lungo termine che non vengono ruotate automaticamente. L’eventuale compromissione di queste credenziali ha un impatto significativo sul business. Un ruolo IAM ti consente di ottenere chiavi di accesso temporanee da utilizzare per accedere Servizi AWS a risorse e risorse.
Per ulteriori informazioni, consulta [Autenticazione e autorizzazione per Aurora DSQL](authentication-authorization.md).
**Utilizza le policy IAM per l’autorizzazione di base di Aurora DSQL.**
Quando si concedono le autorizzazioni, si decide gli utenti che le riceveranno, quali API di Aurora DSQL ottengono le autorizzazioni e le operazioni specifiche da consentire su tali risorse. L’implementazione del privilegio minimo è fondamentale per ridurre i rischi di sicurezza e l’impatto che può risultare da errori o intenzioni dannose.
Collega policy di autorizzazione ai ruoli IAM e concedi autorizzazioni per eseguire operazioni su risorse Aurora DSQL. Sono disponibili anche [limiti delle autorizzazioni per le entità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html), che consentono di impostare le autorizzazioni massime che una policy basata sull’identità può concedere a un’entità IAM.
Analogamente alle [best practice per gli utenti root Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html), non utilizzare il `admin` ruolo in Aurora DSQL per eseguire operazioni quotidiane. Consigliamo invece di creare ruoli del database personalizzati per gestire e connettersi al cluster. Per maggiori informazioni, consulta [Accesso ad Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html) e [Informazioni sull’ autenticazione e l’autorizzazione per Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html).
**Utilizzo di `verify-full` in ambienti di produzione.**
Questa impostazione verifica che il certificato del server sia firmato da un’autorità di certificazione affidabile e che il nome host del server corrisponda al certificato.
**Aggiornamento del client PostgreSQL**
Aggiorna regolarmente il tuo client PostgreSQL alla versione più recente per beneficiare dei miglioramenti della sicurezza. Si consiglia di utilizzare PostgreSQL versione 17.