Gestione dei segreti
Creare e gestire segreti del vault, tag segrete e regole segrete.
Con l'importanza di utilizzare i servizi cloud OCI, è importante memorizzare, recuperare e gestire i segreti nel proprio vault digitale. I segreti possono essere password, certificati, chiavi SSH o token di autenticazione utilizzati per la connessione ai servizi e ai sistemi OCI. La memorizzazione dei segreti in OCI Vault ha una sicurezza maggiore rispetto alla memorizzazione in un codice o in un file di configurazione. L'applicazione comunica con OCI Secret Management per recuperare il segreto e connettersi al servizio di destinazione.
Oracle Cloud Infrastructure Secret Management ti consente di proteggere facilmente i dati sensibili come chiavi API, password e chiavi di cifratura utilizzando i segreti. Offre una solida soluzione per creare, archiviare, gestire e accedere a questi segreti in modo sicuro. Lo storage centralizzato che fornisce sfrutta i moduli di sicurezza hardware (HSM) e il controllo dell'accesso granulare per salvaguardare la sicurezza e l'integrità delle informazioni critiche. Utilizza OCI Secret Management per eliminare l'incorporamento di segreti direttamente nelle applicazioni e ridurre la superficie di attacco e rafforzare la sicurezza generale di un'applicazione.
Generazione e rotazione automatica dei segreti
Quando un segreto viene generato, viene aggiornato periodicamente. È possibile aggiornare un segreto manualmente o impostarlo automaticamente. La generazione automatica e la rotazione dei segreti eliminano il peso di impostare il segreto manualmente e ruotarlo utilizzando gli script, ma fornisce invece un modo efficiente per gestire i segreti dalla creazione, rotazione ed eliminazione.
La funzione di generazione automatica dei segreti supporta l'uso di modelli per la generazione dei segreti. Con la rotazione automatica del segreto, è possibile impostare l'intervallo segreto da 1 a 12 mesi. La funzione si integra con i servizi Autonomous Database e Function, consentendo di aggiornare un segreto utilizzato nel codice Autonomous Database o Functions. In OCI Functions, la rotazione automatica dei segreti consente di ruotare facilmente una credenziale ed eseguire il codice come parte del processo di rotazione. La funzione di rotazione dei segreti di automazione è disponibile anche per i segreti creati manualmente.
Replica tra più aree dei segreti
È possibile replicare un segreto in un massimo di tre aree di destinazione. Le repliche sono di sola lettura ed ereditano le modifiche apportate al segreto di origine. Per ulteriori informazioni, vedere Replica di segreti.
Vantaggi dell'utilizzo della rotazione automatica dei segreti
- Maggiore sicurezza: l'aggiornamento regolare dei segreti riduce al minimo l'impatto delle credenziali compromesse che portano a una violazione dei dati.
- Efficienza operativa: l'automazione di attività manuali come la creazione, la rotazione di un segreto consente di risparmiare tempo ed efficienza.
- Conformità regolamentata: Aderisci a molti standard che regolano la conformità per la rotazione segreta e l'automazione.
- Riduzione dell'errore umano: l'automazione di attività ripetitive riduce la possibilità di errori umani per rafforzare la sicurezza.
Generazione segreto
È possibile generare un segreto per passphrase, chiavi SSH e byte. Tutti i segreti generati da OCI Vault sono conformi a FIPS e sicurezza. È possibile generare un segreto utilizzando la console, l'API o l'interfaccia CLI OCI. Quando si genera un segreto, è necessario fornire il contesto segreto e definire il modello di segreto. Il contesto segreto definisce il tipo di segreto e la struttura del segreto. In base al tipo di segreto selezionato; Vault supporta diversi modelli di generazione dei segreti.
PASSPHRASE
: genera password con una lunghezza massima di 32 caratteri. Per le password predefinite del servizio di database OCI, la lunghezza massima dei caratteri è 30.SSH_KEY
: Genera coppie di chiavi RSA di lunghezza 2048, 3072 e 4096. La chiave privata viene memorizzata nel formato PKCS#8 PEM e la chiave pubblica viene memorizzata nel formato X.509 PEM.BYTES
: genera 512 e 1024 byte che sono segreti binari dei reclami FIPS. I byte sono codice base64.
Tipi di segreti e modelli predefiniti
PASSPHRASE
- Modelli supportati:
SECRETS_DEFAULT_PASSWORD
eDBAAS_DEFAULT_PASSWORD
- Segnaposto nel modello segreto:
%GENERATED_PASSPHRASE%
- Esempio:
{"user": "abc", "pwd": "%GENERATED_PASSPHRASE%"}
- Modelli supportati:
-
SSH_KEY
- Modelli supportati:
RSA_2048
,RSA_3072
,RSA_4096
- Segnaposto nel modello segreto:
%GENERATED_PUBLIC_KEY%
,%GENERATED_PRIVATE_KEY%
- Esempio:
{"publicKey": "%GENERATED_PRIVATE_KEY%", "privateKey": "%GENERATED_PRIVATE_KEY%"} → {"publicKey": "-----BEGIN PUBLIC KEY-----\nBase64 encoded public key\n-----END PUBLIC KEY-----", "privateKey":"-----BEGIN PRIVATE KEY-----\nBase64 encoded private key\n-----END PRIVATE KEY-----"}
- Modelli supportati:
BYTES
- Modelli supportati:
BYTES_512
,BYTES_1024
- Segnaposto nel modello segreto:
%GENERATED_BYTES%
- Esempio:
{"host": "abc", "hostLuksKey": "%GENERATED_BYTES%"} → {"host": "abc", "hostLuksKey": "generatedbyteshere=="}
- Modelli supportati:
Versioni dei segreti e stati di rotazione
Informazioni sulle versioni dei segreti vault, sugli stati di rotazione e sull'impatto della limitazione delle versioni dei segreti.
La comprensione delle versioni segrete del vault e degli stati di rotazione consente di tenere traccia e gestire i contenuti segreti per rimanere conformi a qualsiasi limite, rotazione o altre regole o normative.
Per informazioni sui concetti di base dei segreti, incluse le versioni segrete e gli stati di rotazione, vedere Concetti di gestione di chiavi e segreti. Per informazioni sull'utilizzo delle versioni segrete, vedere Gestione dei segreti.
Funzioni di rotazione
Le funzioni di rotazione sono responsabili della rotazione dei segreti nel servizio segreto. Espandere la sezione seguente per conoscere i quattro passaggi di una funzione di rotazione e per visualizzare il codice del gestore di funzioni di esempio
Le funzioni di rotazione includevano i seguenti quattro passaggi:
VERIFY_CONNECTION
: verifica la connessione al sistema di destinazione utilizzando le credenziali esistenti memorizzate nel segreto.CREATE_PENDING_VERSION
: crea una nuova versione del segreto in sospeso nel segreto.UPDATE_TARGET_SYSTEM
: aggiorna il sistema di destinazione con le credenziali memorizzate nella versione del segreto in sospeso creata nel secondo passo.PROMOTE_PENDING_VERSION
: aggiorna lo stato del segreto da in sospeso a corrente.
Gestore funzioni:
L'handler di funzioni deve contenere la logica per chiamare il passo di rotazione appropriato in base al parametro del passo. Ciò può essere ottenuto utilizzando istruzioni condizionali IF ELSE o switch case. L'handler di funzioni genera un errore se viene fornito un parametro passo non valido.
Input:
Il gestore di funzioni prevede un singolo parametro: SecretRotationInput
. secretRotationInput
è un POJO (Plain-old java object) contenente i parametri necessari per la rotazione, inclusi secretId(String), step(String) e currentVersionNo(Long).
- secretId: identificativo del segreto o OCID
- passo: il passo di rotazione (deve essere
VERIFY_CONNECTION
,CREATE_PENDING_VERSION
,UPDATE_TARGET_SYSTEM
oPROMOTE_PENDING_VERSION
) - currentVersionNo: il numero della versione del segreto
CURRENT
SecretRotationInput POJO
@Getter
@Setter
@ToString(callSuper = true)
@JsonInclude(JsonInclude.Include.NON_NULL)
@AllArgsConstructor
@Builder(toBuilder = true)
public static class SecretRotationInput {
private String step;
private Long versionNo;
private String secretId;
}
Codice del gestore di funzioni di esempio:
public static class SecretRotationOutput {
int responseCode;
Long currentVersionNo;
String returnMessage;
}
public SecretRotationOutput handleRequest(SecretRotationInput input) {
switch(input.getStep()) {
case "VERIFY_CONNECTION":
return verifyConnection(input.getSecretId());
case "CREATE_PENDING_VERSION":
return createNewPendingVersion(input.getSecretId());
case "UPDATE_TARGET_SYSTEM":
return updateTargetSystem(input.getSecretId(), input.getVersionNo());
case "PROMOTE_PENDING_VERSION":
return promotePendingVersion(input.getSecretId(), input.getVersionNo());
default:
log.error("Secret Rotation: invalid rotation step");
return SecretRotationOutput.builder()
.responseCode(400)
.currentVersionNo(null)
.returnMessage("INVALID STEP")
.build();
}
}
Fase 1: VERIFY_CONNECTION
Questo passo verifica la connessione al sistema di destinazione.
- Input: questo metodo prevede solo il parametro
SecretId
. - Output: questo metodo restituisce
SecretRotationOutput
. - Logic: la funzione tenta prima di tutto di recuperare la versione
PENDING
e verificare la connessione con essa. Gestisce lo scenario di errore in cui il precedente nuovo tentativo non è riuscito a promuovere la versionePENDING
, ma la versione è stata applicata al sistema. Se ha successo, restituisce la risposta di successo. In caso di errore, recuperare la versione corrente e controllare la connessione. In caso affermativo, restituire il codice di risposta riuscita insieme al numero di versione corrente. Se non riesce, restituisce l'errore.
Pseudo codice per VERIFY_CONNECTION
pseudo code for verifyConnection:
Check if "PENDING" secret version exists
If it exist, verify connection
If succeeds, then return success.
Fetch the "CURRENT" secret version
Verify connection with "CURRENT" secret version
If succeeds, return success and the current version number in the response.
If not, return SecretRotationOutput with appropriate error code and message.
Fase 2: CREATE_PENDING_VERSION
Genera una nuova versione del segreto in sospeso.
- Input: questo metodo accetta anche il parametro
secretId
. - Output: questo metodo restituisce
SecretRotationOutput
. -
Logic: questo metodo verifica prima l'esistenza di una versione segreta in stato
PENDING
. Se non esiste, viene generata una nuova versione del segretoPENDING
. Tuttavia, se ne esiste già uno, il passo restituisce la risposta riuscita. È inoltre possibile utilizzare il campo dei metadati segreti per memorizzare dettagli aggiuntivi sulla struttura del segreto e utilizzare la stessa struttura durante la creazione di una nuova versione del segreto. È inoltre possibile utilizzare la funzione di generazione automatica del servizio segreto per generare automaticamente il contenuto del segreto. La generazione automatica consente di scrivere funzioni più generiche.
Pseudo codice per CREATE_PENDING_VERSION
pseudo code for createPendingVersion:
Try to get the pending version
If it succeeds, return success
Else create a new secret version in "PENDING" state and then return success
Codice di esempio:
// Constructor
public void constructorClass() {
secretsDpClient = SecretsClient.builder()
.region(region)
.configuration(configuration)
.build(auth_provider);
secretsCpClient = VaultsClient.builder()
.region(region)
.configuration(configuration)
.build(auth_provider);
}
private String createNewPassword() {
// This method must contains the logic to generate the new secret content
}
private SecretRotationOutput createNewPendingVersion(SecretRotationInput input) {
// Make sure the given secret exist
Secret secret = secretsCpClient.getSecret(GetSecretRequest.builder()
.secretId(input.getSecretId())
.build()).getSecret();
// Now try to get the pending secret version, if that fails, create a new one
try {
GetSecretBundleRequest getSecretBundleRequest = GetSecretBundleRequest.builder()
.secretId(input.getSecretId())
.stage(GetSecretBundleRequest.Stage.Pending)
.build();
secretsDpClient.getSecretBundle(getSecretBundleRequest);
return SecretRotationOutput.builder()
.responseCode(200)
.returnMessage("Successfully retrieved the pending secret version")
.build();
} catch (BmcException bmc) {
// Create a new pending version
UpdateSecretDetails updateSecretDetails = secret.getIsAutoGenerationEnabled() ? UpdateSecretDetails.builder()
.secretContent(Base64SecretContentDetails.builder()
.stage(SecretContentDetails.Stage.Pending)
.build())
.build() : UpdateSecretDetails.builder()
.secretContent(Base64SecretContentDetails.builder()
.content(createNewPassword())
.stage(SecretContentDetails.Stage.Pending)
.build())
.build();
secretsCpClient.updateSecret(UpdateSecretRequest.builder()
.secretId(input.getSecretId())
.updateSecretDetails(updateSecretDetails)
.build()).getSecret();
log.info("Successfully added a new version with 'PENDING' stage for secretId {}", input.getSecretId());
return SecretRotationOutput.builder()
.responseCode(200)
.returnMessage("Pending version created successfully")
.currentVersionNo(input.getVersionNo())
.build();
}
}
Passo 3: UPDATE_TARGET_SYSTEM
Imposta il segreto in sospeso nel sistema di destinazione.
- Input: questo metodo accetta
currentVersionNo
esecretId
. - Output: questo metodo restituisce anche
SecretRotationOutput
. - Logic: questo metodo tenta innanzitutto di eseguire il login al sistema di destinazione con la versione del segreto
PENDING
e restituisce un risultato positivo. Gestisce anche lo scenario di errore in cui il precedente nuovo tentativo non è riuscito a promuovere la versione in sospeso, ma la versione è stata applicata correttamente al sistema. In caso contrario, tenta di eseguire il login con la versione del segretoCURRENT
. Se la versione del segreto corrente riesce, la passwordPENDING
viene impostata come password utente nel sistema di destinazione.
Pseudo codice per UPDATE_TARGET_SYSTEM
Pseudo code for updateTargetSystem:
Fetch the "PENDING" secret version
Check the connection with Pending version
It it works return success and the pending version number in the response
Fetch the "CURRENT" secret version
Check the connection with it
If it works
Update the target system with "PENDING" version
Verify that target system is updated.
if yes then return success and the pending version number in the response
else return the appropriate error code and the error message
If not, return SecretRotationOutput with appropriate error code and message.
Codice di esempio:
private SecretRotationOutput updateTargetSystem(String secretId, Long currentVersionNo) {
// Get the pending secret version
SecretBundle pendingSecretBundle = secretsDpClient.getSecretBundle(GetSecretBundleRequest.builder()
.secretId(secretId)
.stage(GetSecretBundleRequest.Stage.Pending)
.build()).getSecretBundle();
// First try to login with the pending secret, if it succeeds, return
Connection conn = getConnection(pendingSecretBundle);
if(conn) {
log.info("Updated the target system with pending version");
return SecretRotationOutput.builder()
.responseCode(200)
.returnMessage("Successfully update target service")
.currentVersionNo(pendingSecretBundle.getVersionNumber())
.build();
}
SecretBundle currentSecretBundle = secretsDpClient.getSecretBundle(GetSecretBundleRequest.builder()
.versionNumber(currentVersionNo)
.secretId(secretId)
.build()).getSecretBundle();
conn = getConnection(currentSecretBundle);
if(conn) {
// Write logic to update the target system and check the connection with the updated password
} else {
log.error("Unable to log into system using the current version");
return SecretRotationOutput.builder()
.returnMessage("Unable to log into system using the current version")
.responseCode(400)
.build();
}
}
Fase 4: PROMOTE_PENDING_VERSION
Terminare la rotazione contrassegnando il segreto in sospeso come corrente.
- Input: questo metodo accetta
currentVersionNo
esecretId
. - Output: questo metodo restituisce anche
SecretRotationOutput
. - Logic: chiamare il servizio segreto per promuovere la versione
PENDING
inCURRENT
.UpdateRequest
deve specificare la versione da promuovere inCURRENT
.
Pseudo codice per PROMOTE_PENDING_VERSION
pseudo code for promotePendingVersion:
Make updateSecret Api call to promote the specified version to "CURRENT"
Codice di esempio:
private SecretRotationOutput promotePendingVersion(String secretId, Long versionNo) {
try {
Secret secret = secretsCpClient.updateSecret(UpdateSecretRequest.builder()
.secretId(secretId)
.updateSecretDetails(UpdateSecretDetails.builder()
.currentVersionNumber(versionNo)
.build())
.opcRequestId(UUID.randomUUID().toString())
.build()).getSecret();
log.info("Successfully promoted the version number {} to 'CURRENT'", versionNo);
return SecretRotationOutput.builder()
.responseCode(200)
.currentVersionNo(secret.getCurrentVersionNumber())
.returnMessage("Successfully promoted the pending version")
.build();
} catch (BmcException bmc) {
log.error("Fail to promote the pending version. SecretId: {}, pendingVersionNo: {}. {}", secretId, versionNo, bmc.getMessage());
return SecretRotationOutput.builder()
.returnMessage(bmc.getMessage())
.responseCode(bmc.getStatusCode())
.build();
}
}
Stati rotazione
Le versioni dei segreti possono avere più di uno stato di rotazione alla volta. Quando esiste una sola versione del segreto, ad esempio la prima volta che si crea un segreto, la sua versione viene contrassegnata automaticamente sia come corrente che come più recente. La versione più recente di un segreto contiene i contenuti dei segreti caricati per l'ultima volta nel vault. Se hai bisogno di trovare quale versione segreta ha materiale segreto caricato più di recente, puoi utilizzare lo stato "più recente" per farlo.
Quando si caricano nuovi contenuti dei segreti per la rotazione dei segreti, è possibile contrassegnare la versione del segreto come in sospeso. Ciò consente di caricare il materiale segreto nel caveau senza metterlo immediatamente in uso. È possibile continuare a utilizzare la versione del segreto attuale finché non si è pronti a promuovere una versione del segreto in sospeso sullo stato corrente. Ciò in genere si verifica dopo aver prima ruotato le credenziali sulla risorsa o sul servizio di destinazione. Si noti che è necessario considerare gli effetti della rotazione segreta sulle applicazioni e le risorse che si basano sul segreto. La modifica della versione del segreto corrente potrebbe impedire a un'applicazione o a una risorsa che la richiede di recuperare la versione del segreto prevista dal vault.
Le versioni segrete possono anche essere contrassegnate come precedenti. In questo modo sarà possibile eseguire facilmente il rollback di un segreto a una versione precedente. Potrebbe essere necessario eseguire questa operazione quando un segreto viene ruotato per errore o quando si ripristina un backup di una risorsa che deve riprendere utilizzando una versione segreta precedente. Una versione del segreto contrassegnata come precedente è la versione contrassegnata come corrente direttamente prima della rotazione più recente. Per eseguire il rollback a una versione precedente, aggiornare il segreto per specificare il numero di versione del segreto desiderato.
Finché una versione del segreto non è stata eliminata, è possibile aggiornare il segreto per utilizzare la versione passata del segreto. Quando si aggiorna il segreto, la versione del segreto selezionata viene contrassegnata come corrente. Ciò ha lo stesso effetto della promozione di una versione del segreto su corrente.
È possibile eliminare solo le versioni dei segreti contrassegnate come deprecate. Una versione del segreto non più valida è una versione non contrassegnata come corrente, in sospeso o precedente. Ciò consente di evitare le circostanze in cui è possibile eliminare una versione segreta necessaria in un secondo momento (ad esempio, quando si ripristina un database di cui è stato eseguito il backup in precedenza). Una versione del segreto contrassegnata come non più valida può essere contrassegnata come corrente per restituirla all'uso attivo.
Limitazione versione
I limiti alle versioni segrete si applicano sia alle versioni di un segreto in uso che alle versioni non più valide, incluse quelle pianificate per l'eliminazione. Per informazioni sui limiti relativi al numero di versioni per un determinato segreto e alle versioni segrete in una tenancy, vedere Limiti del servizio.
Informazioni preliminari
Prima di iniziare, è consigliabile leggere Regole segrete e Versioni segrete e stati di rotazione per comprendere meglio le implicazioni dell'utilizzo di regole, versioni segrete e stati di rotazione delle versioni segrete.
Criteri IAM necessari
Per utilizzare Oracle Cloud Infrastructure, un amministratore deve essere membro di un gruppo a cui è stato concesso l'accesso di sicurezza in un criterio da un amministratore della tenancy. Questo accesso è necessario, indipendentemente dal fatto che si stia utilizzando la console o l'API REST con un SDK, un'interfaccia CLI o unaltro strumento. Se viene visualizzato un messaggio che informa che non si dispone dell'autorizzazione o che non si è autorizzati, verificare con l'amministratore della tenancy il tipo di accesso di cui si dispone e il compartimento in cui funziona l'accesso.
Per gli amministratori:
- Il criterio Consenti agli amministratori della sicurezza di gestire vault, chiavi e segreti consente al gruppo specificato di eseguire qualsiasi operazione con vault, chiavi e segreti.
- Il criterio Creare un criterio per abilitare le chiavi di cifratura consente al gruppo specificato di eseguire tutte le operazioni con i segreti in un vault specifico.
- Il criterio Consenti agli utenti di leggere, aggiornare e ruotare tutti i segreti consente al gruppo specificato di leggere, aggiornare e ruotare tutti i segreti in qualsiasi vault nella tenancy.
- Per ulteriori informazioni sulle autorizzazioni o se è necessario scrivere criteri più restrittivi per i segreti, vedere Dettagli per il servizio Vault.
Se non si ha familiarità con i criteri, vedere Gestione dei domini di Identity e Criteri comuni.
Segreti di applicazione tag
Applica tag alle risorse per organizzarle in base alle esigenze aziendali. È possibile applicare le tag quando si crea una risorsa ed è possibile aggiornare una risorsa in un secondo momento per aggiungere, rivedere o rimuovere le tag. Per informazioni generali sull'applicazione delle tag, vedere Tag risorsa.
Monitoraggio delle risorse
Puoi monitorare lo stato, la capacità e le prestazioni delle risorse Oracle Cloud Infrastructure utilizzando metriche, allarmi e notifiche. Per ulteriori informazioni vedere Monitoraggio e Notifiche.
Spostamento delle risorse in un altro compartimento
È possibile spostare i segreti da un compartimento a un altro. Dopo aver spostato un segreto in un nuovo compartimento, i criteri configurati per il compartimento vengono applicati immediatamente e influiscono sull'accesso alle versioni dei segreti e dei segreti. Lo spostamento di un segreto non influisce sull'accesso al vault a cui è associato un segreto. Allo stesso modo, puoi spostare un vault da un compartimento all'altro indipendentemente dallo spostamento di uno qualsiasi dei suoi segreti. Per ulteriori informazioni, vedere Gestione dei compartimenti.