Documentazione dell'infrastruttura Oracle Cloud

Replica dei segreti

Informazioni sulla replica dei segreti in tutte le aree.

È possibile replicare i segreti tra le aree per i motivi riportati di seguito.

  • Disaster recovery: la replica dei segreti garantisce la loro accessibilità in caso di interruzioni regionali. I sistemi con funzionalità di standby, failover e switchover potrebbero richiedere segreti disponibili per i sistemi in standby.
  • Disponibilità: se si utilizza un segreto in più aree, la replica del segreto in altre aree semplifica l'accesso e l'aggiornamento del segreto nelle aree in cui è necessario. Assicurarsi di seguire le linee guida di sicurezza dell'organizzazione per quanto riguarda l'uso di un segreto in più aree.

Funzionamento della replica

Quando si crea un segreto in un vault, è possibile replicarlo in un massimo di altre 3 aree. È inoltre possibile abilitare la replica dopo aver creato un segreto modificando il segreto. Quando crei le repliche di un segreto, specifichi l'area di destinazione, il vault di destinazione all'interno di tale area e la chiave di cifratura da utilizzare per il segreto. I segreti di replica e le versioni dei segreti utilizzano gli stessi OCID delle versioni dei segreti e dei segreti di origine. I segreti di replica vengono conteggiati insieme ai segreti di origine ai fini dei limiti regionali della tenancy sui segreti.

Quando si abilita la replica, OCI replica quanto riportato di seguito.

  • Il contenuto segreto
  • Metadati e impostazioni del segreto
  • Versioni del segreto

La replica è di sola lettura e non può essere modificata. Quando si modifica o si elimina un segreto di origine, l'operazione di modifica o eliminazione viene applicata anche alle repliche del segreto. La disabilitazione della funzione in un segreto con repliche comporta l'eliminazione delle repliche. È inoltre possibile eliminare le repliche singolarmente conservando il segreto di origine modificando il segreto di origine.

È possibile utilizzare le richieste di lavoro per monitorare le operazioni di replica tra più aree di avanzamento. Per informazioni dettagliate sull'uso delle richieste di lavoro con il servizio segreto, vedere Richieste di lavoro segrete.

Per gestire le repliche segrete, attenersi alle istruzioni riportate di seguito.

Importante

I segreti non vengono replicati automaticamente durante la replica del vault. È necessario gestire la replica dei segreti a livello della risorsa segreta. Per informazioni sulla replica del vault, vedere Replica di vault e chiavi.

Inoltro di scrittura per operazioni di aggiornamento su segreti di replica

Facoltativamente, è possibile abilitare l'inoltro di scrittura per i segreti replicati utilizzando l'API o l'interfaccia CLI. Sebbene i segreti replicati siano di sola lettura, l'inoltro di scrittura consente di indirizzare un segreto replicato per un'operazione di scrittura e di applicare automaticamente l'operazione prima al segreto di origine, quindi tramite aggiornamenti asincroni, applicati a tutte le repliche del segreto di origine.

Ad esempio, se nell'area orientale degli Stati Uniti (Ashburn) è presente un segreto di origine replicato nell'area orientale del Giappone (Tokyo), è possibile eseguire l'aggiornamento del segreto di replica nell'area orientale del Giappone (Tokyo). La richiesta di aggiornamento viene quindi inoltrata al segreto di origine nell'area orientale degli Stati Uniti (Ashburn) ed eseguita automaticamente su tale segreto. Dopo l'aggiornamento del segreto di origine, la richiesta di aggiornamento viene applicata automaticamente a tutte le repliche del segreto di origine, inclusa la replica in Japan East (Tokyo).

Limiti

Le seguenti limitazioni si applicano alla funzione di inoltro in scrittura per garantire la sicurezza dei segreti:

  • Non è possibile utilizzare l'inoltro di scrittura per le seguenti operazioni:

    • pianificazione dell'eliminazione di un segreto
    • annullamento dell'eliminazione di un segreto
    • aggiornamento della configurazione di replica del segreto di origine
  • Quando si crea un nuovo segreto, è possibile abilitare l'inoltro di scrittura, ma non è possibile specificare il vault di un'area remota in cui memorizzare il segreto di origine utilizzando la funzionalità di inoltro di scrittura.
  • Poiché l'operazione di scrittura viene eseguita in modo asincrono e gli aggiornamenti vengono applicati per la prima volta al segreto di origine, è previsto un ritardo tra l'avvio dell'aggiornamento sulla replica e il completamento dell'aggiornamento nell'area della replica. È possibile monitorare l'avanzamento dell'aggiornamento utilizzando le richieste di lavoro. Per informazioni dettagliate sull'uso delle richieste di lavoro con il servizio segreto, vedere Richieste di lavoro segrete.
  • L'entità che richiede l'aggiornamento nell'area della replica deve essere autorizzata per eseguire l'aggiornamento nell'area del segreto di origine e nell'area in cui risiede la replica.
  • Non è possibile abilitare l'inoltro di scrittura in OCI Console. Per abilitare l'inoltro in scrittura, utilizzare le API CreateSecret e UpdateSecret o i comandi CLI per queste operazioni. Nelle API, impostare isWriteForwardEnabled su true per abilitare la funzione.

Criterio IAM necessario

Utilizzare le informazioni sulle autorizzazioni in questa sezione per consentire agli utenti o ai principal delle risorse di configurare la replica tra più aree dei segreti.

Autorizzazioni necessarie per configurare la replica

Per creare o aggiornare una configurazione di replica segreta (replicationConfig), un utente o un principal risorsa deve disporre dell'autorizzazione SECRET_REPLICATE_CONFIGURE. Questo è incluso nel verbo manage secrets.

Per creare un segreto con replica abilitata, assicurarsi che l'utente o il principal risorsa disponga di tutte le autorizzazioni seguenti:

  • SECRET_CREATE, KEY_ENCRYPT, KEY_DECRYPT, VAULT_CREATE_SECRET (per l'utilizzo dell'API CreateSecret o la creazione di segreti nella console o in altre interfacce).
  • SECRET_REPLICATE_CONFIGURE

Per aggiornare o rimuovere una configurazione di replica, assicurarsi che l'utente o il principal risorsa disponga di tutte le autorizzazioni riportate di seguito.

  • SECRET_UPDATE (per utilizzare l'API UpdateSecret o aggiornare i segreti nella console o in altre interfacce).
  • SECRET_REPLICATE_CONFIGURE

Criteri di esempio

Il criterio di esempio riportato di seguito contiene istruzioni che coprono tutte le risorse necessarie per abilitare la replica tra più aree per segreti nuovi o esistenti.

Allow group Admins to manage secrets in compartment CompartmentName # for granting SECRET_CREATE, SECRET_UPDATE, SECRET_REPLICATE_CONFIGURE
Allow group Admins to use keys in compartment CompartmentName       # for granting KEY_ENCRYPT, KEY_DECRYPT
Allow group Admins to use vaults in compartment CompartmentName     # for granting VAULT_CREATE_SECRET
Nota

I verbi di autenticazione nel criterio di esempio (manage secrets, use keys, use vaults) contengono anche altre autorizzazioni non elencate in questo argomento. Rivedere i dettagli per le combinazioni di verbo e tipo di risorsa quando si scrivono i criteri IAM per i segreti.

Autorizzazioni necessarie ai principal risorsa per consentire la replica dei segreti tra più aree

Quando la replica è abilitata su un segreto, è necessario fornire al principal risorsa le autorizzazioni pertinenti nel contesto dell'area di destinazione per consentire l'esecuzione della replica.

Impostazione di un gruppo dinamico

Si consiglia di impostare un gruppo dinamico per i segreti che verranno replicati per semplificare la gestione dei criteri. Di seguito è riportata una regola di corrispondenza di esempio.

All {resource.type = 'vaultsecret', resource.compartment.id = '<compartment ID>'}

Per ulteriori informazioni sulle regole di corrispondenza dei gruppi dinamici, vedere Scrittura delle regole di corrispondenza per definire i gruppi dinamici.

Scrivere la politica

La replica dei segreti richiede che il principal risorsa vaultecret appartenente al segreto disponga delle autorizzazioni per creare e gestire il segreto replica nell'area di destinazione. Queste autorizzazioni sono SECRET_CREATE, KEY_ENCRYPT, KEY_DECRYPT, VAULT_CREATE_SECRET e SECRET_REPLICATE.

Si noti che SECRET_REPLICATE è un'autorizzazione utilizzata solo per la funzione di replica tra più aree. Quando concesso, SECRET_REPLICATE consente a un principal risorsa vaultecret di creare una replica nell'area di destinazione.

Criterio di esempio per il principal risorsa vaultsecret

Allow dynamic-group VaultSecretDG to use secret-replication in compartment CompartmentName # for granting SECRET_REPLICATE
Allow dynamic-group VaultSecretDG to manage secrets in compartment CompartmentName         # for granting SECRET_CREATE
Allow dynamic-group VaultSecretDG to use vaults in compartment CompartmentName             # for granting VAULT_CREATE_SECRET
Allow dynamic-group VaultSecretDG to use keys in compartment CompartmentName               # for granting KEY_ENCRYPT, KEY_DECRYPT
Nota

  • I verbi di autenticazione nel criterio di esempio (manage secrets, use keys, use vaults) contengono anche altre autorizzazioni non elencate in questo argomento. Rivedere i dettagli per le combinazioni di verbo e tipo di risorsa quando si scrivono i criteri IAM per i segreti.
  • Queste autorizzazioni devono essere concesse nel contesto dell'area di destinazione. Ad esempio, se si limita l'accesso utilizzando la variabile di contesto dell'ID vault, assicurarsi che la variabile specificata sia l'ID vault dell'area di destinazione.
  • Se il compartimento o il segreto utilizza tag definite, assicurarsi di concedere anche l'autorizzazione use tag-namespaces al gruppo dinamico vaultecret.