Gestion des clés secrètes
Créer et gérer des clés secrètes de coffre, des balises secrètes et des règles de clé secrète.
Avec l'importance de l'utilisation des services cloud OCI, il est important de stocker, d'extraire et de gérer les clés secrètes dans son coffre numérique. Les clés secrètes peuvent être un mot de passe, des certificats, des clés SSH ou des jetons d'authentification que vous utilisez pour vous connecter aux services et systèmes OCI. Le stockage des clés secrètes dans OCI Vault offre une sécurité supérieure à celle du stockage dans un fichier de code ou de configuration. L'application communique avec OCI Secret Management pour extraire la clé secrète et se connecter au service cible.
Oracle Cloud Infrastructure Secret Management vous permet de protéger facilement des données sensibles telles que des clés d'API, des mots de passe et des clés de cryptage à l'aide de clés secrètes. Il offre une solution robuste pour créer, stocker, gérer et accéder à ces secrets en toute sécurité. Le stockage centralisé qu'il fournit tire parti des modules de sécurité matériels (HSM) et du contrôle d'accès granulaire pour protéger la sécurité et l'intégrité des informations critiques. Utilisez OCI Secret Management pour éliminer l'intégration de secrets directement dans les applications, réduire la surface d'attaque et renforcer la sécurité globale d'une application.
Génération et rotation automatiques de clés secrètes
Lorsqu'une clé secrète est générée, elle est mise à jour régulièrement. Vous pouvez mettre à jour une clé secrète manuellement ou la définir automatiquement. La génération et la rotation automatiques des clés secrètes éliminent la charge de définir une clé secrète manuellement et de la faire pivoter à l'aide de scripts, mais fournissent un moyen efficace de gérer les clés secrètes à partir de la création, de la rotation et de la suppression.
La fonction de génération automatique de clé secrète prend en charge l'utilisation de modèles pour la génération de clé secrète. Avec la rotation de clé secrète automatique, vous pouvez définir un intervalle de clé secrète de 1 à 12 mois. La fonctionnalité s'intègre aux services Autonomous Database et Function, ce qui vous permet de mettre à jour une clé secrète utilisée dans le code Autonomous Database ou Functions. Dans OCI Functions, la rotation automatique des clés secrètes vous permet de faire pivoter facilement des informations d'identification et d'exécuter du code dans le cadre du processus de rotation. La fonction de rotation des clés secrètes d'automatisation est également disponible pour les clés secrètes créées manuellement.
Réplication inter-région de clés secrètes
Vous pouvez répliquer une clé secrète dans jusqu'à trois régions de destination. Les répliques sont en lecture seule et héritent des modifications apportées à la clé secrète source. Pour plus d'informations, reportez-vous à Réplication de clés secrètes.
Avantages de la rotation automatique des clés secrètes
- Sécurité renforcée : La mise à jour régulière de vos secrets minimise l'impact des informations d'identification compromises conduisant à une violation de données.
- Efficacité opérationnelle : L'automatisation des tâches manuelles telles que la création, la rotation d'un secret permet de gagner du temps et de l'efficacité.
- Conformité réglementée : Adhérez à de nombreuses normes qui réglementent la conformité pour la rotation secrète et l'automatisation.
- Réduction des erreurs humaines : l'automatisation des tâches répétitives réduit les risques d'erreurs humaines pour renforcer la sécurité.
Génération de clés secrètes
Vous pouvez générer une clé secrète pour les phrases de passe, les clés SSH et les octets. Toutes les clés secrètes générées par OCI Vault sont conformes à FIPS et à la sécurité. Vous pouvez générer une clé secrète à l'aide de la console, de l'API ou de l'interface de ligne de commande OCI. Lorsque vous générez une clé secrète, vous devez fournir le contexte de clé secrète et définir le modèle de clé secrète. Le contexte secret définit le type et la structure de la clé secrète. En fonction du type de clé secrète que vous sélectionnez ; Vault prend en charge différents modèles de génération de clé secrète.
PASSPHRASE
: génère des mots de passe d'une longueur maximale de 32 caractères. Pour les mots de passe par défaut du service OCI Database, la longueur maximale en caractères est de 30.SSH_KEY
: génère des paires de clés RSA de longueur 2048, 3072 et 4096. La clé privée est stockée au format PEM PKCS#8 et la clé publique au format PEM X.509.BYTES
: génère une clé secrète binaire de plainte FIPS de 512 et 1024 octets. Les octets sont du code base64.
Types de clé secrète et modèles par défaut
PASSPHRASE
- Modèles pris en charge :
SECRETS_DEFAULT_PASSWORD
etDBAAS_DEFAULT_PASSWORD
- Espace réservé dans le modèle de clé secrète :
%GENERATED_PASSPHRASE%
- Exemple :
{"user": "abc", "pwd": "%GENERATED_PASSPHRASE%"}
- Modèles pris en charge :
-
SSH_KEY
- Modèles pris en charge :
RSA_2048
,RSA_3072
,RSA_4096
- Espace réservé dans le modèle de clé secrète :
%GENERATED_PUBLIC_KEY%
,%GENERATED_PRIVATE_KEY%
- Exemple :
{"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-----"}
- Modèles pris en charge :
BYTES
- Modèles pris en charge :
BYTES_512
,BYTES_1024
- Espace réservé dans le modèle de clé secrète :
%GENERATED_BYTES%
- Exemple :
{"host": "abc", "hostLuksKey": "%GENERATED_BYTES%"} → {"host": "abc", "hostLuksKey": "generatedbyteshere=="}
- Modèles pris en charge :
Versions de clé secrète et états de rotation
Découvrez les versions de clé secrète de coffre, les états de rotation et l'impact de la limitation de version de clé secrète.
La compréhension correcte des versions de clé secrète et des états de rotation vous aidera à suivre et à gérer les contenus de clé secrète afin de rester en conformité avec les limites, la rotation ou d'autres règles ou réglementations applicables.
Pour connaître les concepts élémentaires de clé secrète, notamment les versions et les statuts de rotation, reportez-vous à Concepts relatifs à l'administration des clés et des clé secrètes. Pour plus d'informations sur l'utilisation des versions de clé secrète, reportez-vous à Gestion des clés secrètes.
Fonctions de rotation
Les fonctions de rotation sont responsables de la rotation des clés secrètes dans le service secret. Développez la section suivante pour en savoir plus sur les quatre étapes d'une fonction de rotation et pour voir un exemple de code de gestionnaire de fonctions
Les fonctions de rotation comprenaient les quatre étapes suivantes :
VERIFY_CONNECTION
: vérifie la connexion au système cible à l'aide des informations d'identification existantes stockées dans la clé secrète.CREATE_PENDING_VERSION
: crée une version de clé secrète en attente dans la clé secrète.UPDATE_TARGET_SYSTEM
: met à jour le système cible avec les informations d'identification stockées dans la version de clé secrète en attente créée à la deuxième étape.PROMOTE_PENDING_VERSION
: met à jour l'état de la clé secrète de En attente à En cours.
Gestionnaire de fonctions :
Le gestionnaire de fonctions doit contenir la logique permettant d'appeler l'étape de rotation appropriée en fonction du paramètre d'étape. Pour ce faire, vous pouvez utiliser des instructions conditionnelles IF ELSE ou switch case. Le gestionnaire de fonctions génère une erreur si un paramètre d'étape non valide est fourni.
Entrée :
Le gestionnaire de fonctions attend un seul paramètre : SecretRotationInput
. secretRotationInput
est un objet POJO (Java uni) contenant les paramètres requis pour la rotation, notamment secretId(String), step(String) et currentVersionNo(Long).
- secretId : OCID ou identificateur de clé secrète
- étape : étape de rotation (doit être
VERIFY_CONNECTION
,CREATE_PENDING_VERSION
,UPDATE_TARGET_SYSTEM
ouPROMOTE_PENDING_VERSION
) - currentVersionNo : numéro de la version de clé secrète
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;
}
Exemple de code de gestionnaire de fonctions :
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();
}
}
Etape 1 : VERIFY_CONNECTION
Cette étape vérifie la connexion au système cible.
- Entrée : cette méthode attend uniquement le paramètre
SecretId
. - Sortie : cette méthode génère la sortie
SecretRotationOutput
. - Logique : la fonction tente d'abord d'extraire la version
PENDING
et de vérifier la connexion avec celle-ci. Cette option gère le scénario d'échec dans lequel la nouvelle tentative précédente n'a pas réussi à promouvoir la versionPENDING
, mais la version a été appliquée au système. Si elle réussit, renvoyez la réponse de succès. En cas d'échec, extrayez la version actuelle et vérifiez la connexion. Si cela réussit, renvoyez le code de réponse de succès avec le numéro de version actuel. En cas d'échec, renvoyez l'erreur.
Pseudo-code pour 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.
Etape 2 : CREATE_PENDING_VERSION
Génère une nouvelle version de clé secrète en attente.
- Entrée : cette méthode accepte également le paramètre
secretId
. - Sortie : cette méthode génère la sortie
SecretRotationOutput
. -
Logique : cette méthode vérifie d'abord l'existence d'une version de clé secrète à l'état
PENDING
. S'il n'en existe pas, une nouvelle version de clé secrètePENDING
est générée. Toutefois, s'il en existe déjà un, l'étape renvoie la réponse de réussite. Vous pouvez également utiliser le champ de métadonnées de clé secrète pour stocker des détails supplémentaires sur la structure de clé secrète et utiliser la même structure lors de la création d'une version de clé secrète. Vous pouvez également utiliser la fonctionnalité de génération automatique du service de clé secrète pour générer automatiquement le contenu de clé secrète. La génération automatique vous permet d'écrire des fonctions plus génériques.
Pseudo-code pour 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
Exemple de code :
// 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();
}
}
Etape 3 : UPDATE_TARGET_SYSTEM
Définit la clé secrète en attente dans le système cible.
- Entrée : cette méthode accepte les valeurs
currentVersionNo
etsecretId
. - Sortie : cette méthode génère également le fichier
SecretRotationOutput
. - Logique : cette méthode tente d'abord de se connecter au système cible avec la version de clé secrète
PENDING
et revient en cas de réussite. Cette option gère également le scénario d'échec dans lequel la nouvelle tentative précédente n'a pas réussi à promouvoir la version en attente mais la version a été appliquée avec succès au système. En cas d'échec, il tente de se connecter avec la version de clé secrèteCURRENT
. Si la version de clé secrète en cours réussit, elle définit le mot de passePENDING
comme mot de passe utilisateur dans le système cible.
Pseudo-code pour 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.
Exemple de code :
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();
}
}
Etape 4 : PROMOTE_PENDING_VERSION
Terminez la rotation en marquant la clé secrète en attente comme étant en cours.
- Entrée : cette méthode accepte les valeurs
currentVersionNo
etsecretId
. - Sortie : cette méthode génère également le fichier
SecretRotationOutput
. - Logique : appelez le service de clé secrète pour promouvoir la version
PENDING
versCURRENT
.UpdateRequest
doit indiquer la version à promouvoir versCURRENT
.
Pseudo-code pour PROMOTE_PENDING_VERSION
pseudo code for promotePendingVersion:
Make updateSecret Api call to promote the specified version to "CURRENT"
Exemple de code :
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();
}
}
Etats de rotation
Les versions de clé secrète peuvent avoir plusieurs états de rotation à la fois. S'il n'existe qu'une seule version, par exemple lorsque vous créez une clé confidentielle, la version est automatiquement marquée comme en cours et comme dernière. La dernière version d'une clé secrète contient le contenu de la clé secrète qui a été téléchargée en dernier vers le coffre. Si vous devez trouver la dernière version de clé secrète téléchargée, vous pouvez utiliser le statut "dernier" pour ce faire.
Lorsque vous téléchargez de nouveaux contenus de clé secrète pour la rotation de clé secrète, vous pouvez marquer la version de clé secrète comme en attente. Vous pouvez ainsi télécharger les informations de clé secrète vers le coffre sans les mettre immédiatement en service. Vous pouvez continuer à utiliser la version d'une clé secrète en cours tant que vous n'êtes pas prêt à promouvoir la version d'une clé secrète en attente vers le statut en cours. Cela se produit généralement après que vous avez effectué la rotation des informations d'identification sur la ressource ou le service cible. Notez que vous devez prendre en compte les effets de la rotation de clé secrète sur les applications et les ressources qui dépendent de la clé secrète. La modification de quelle version de clé secrète est en cours peut empêcher une application ou une ressource qui en avait besoin d'extraire la version de clé secrète attendue à partir du coffre.
Les versions de clé secrète peuvent également être marquées comme précédentes. Cela vous permet de restaurer facilement une clé secrète vers une version précédente. Vous devrez peut-être effectuer cette opération lorsqu'une clé secrète fait l'objet d'une rotation par erreur ou lors de la restauration d'une sauvegarde d'une ressource qui doit reprendre à l'aide d'une ancienne version de clé secrète. Une version de clé secrète marquée comme précédente est la version qui a été marquée comme en cours directement avant la rotation la plus récente. Pour annuler et revenir à une version précédente, vous devez mettre à jour la clé secrète pour indiquer le numéro de version souhaité.
Tant qu'une version de clé secrète n'a pas été supprimée, vous pouvez mettre à jour la clé secrète pour utiliser cette version antérieure. Lorsque vous mettez à jour la clé secrète, le numéro de version que vous sélectionnez est marqué comme en cours. Cela revient à promouvoir une version de clé secrète vers l'état En cours.
Vous pouvez uniquement supprimer les versions de clé secrète qui sont marquées comme en phase d'arrêt. Une version d'une clé secrète en phase d'abandon n'est pas en cours, ni en attente, ni une versionprécédente. Cela vous évite de supprimer une version d'une clé secrète dont vous pourriez avoir besoin ultérieurement (par exemple, lors d'une restauration d'une base de données sauvegardée auparavant). Une version de clé secrète marquée dans un état autre que En phase d'annulation peut être définie surEn cours pour la renvoyer vers une utilisation active.
Limitation de version
Les limites s'appliquent aux versions de clé secrète en cours d'utilisation et aux versions en phase d'abandon, y compris celles qui ont été planifiées pour suppression. Afin d'obtenir des informations sur les limites relatives au nombre de versions pour une clé secrète et pour les versions de clé secrète dans une location, reportez-vous àLimites du service.
Avant de commencer
Avant de commencer, nous vous recommandons de lire les règles de clé secrète et les versions de clé secrète et états de rotation afin de mieux comprendre les implications liées à l'utilisation des règles, des versions de clé secrète et des états de rotation.
Stratégie IAM requise
Pour utiliser Oracle Cloud Infrastructure, un administrateur doit être membre d'un groupe auquel un administrateur de location a accordé un accès de sécurité dans une stratégie . Cet accès est requis, que vous utilisiez la console ou l'API REST avec un kit SDK, une interface de ligne de commande ou un autre outil. Si un message vous informe que vous n'avez pas d'autorisation ou que vous n'êtes pas autorisé, vérifiez auprès de l'utilisateur le type d'accès qui vous est accordé et le compartiment dans lequel vous travaillez.
Pour les administrateurs :
- La stratégie Autoriser les administrateurs de sécurité à gérer des coffres, des clés et des clés secrètes permet au groupe indiqué d'effectuer toutes les opérations possibles sur les coffres, les clés et les clés secrètes.
- La stratégie Créer une stratégie pour activer les clés de cryptage permet au groupe indiqué d'effectuer toutes les opérations avec les clés secrètes d'un coffre spécifique.
- La stratégie Autoriser les utilisateurs à lire et à mettre à jour toutes les clés secrètes, et à en effectuer la rotation permet au groupe indiqué d'effectuer des opérations de lecture, de mise à jour et de rotation pour toutes les clés secrètes des coffres de la location.
- Pour plus d'informations sur les droits d'accès ou si vous devez élaborer des stratégies plus restrictives pour les clés secrètes, reportez-vous à Détails du service Vault.
Si vous ne connaissez pas les stratégies, reportez-vous à Gestion des domaines d'identité et à Stratégies courantes.
Balisage de clés secrètes
Appliquez des balises aux ressources afin de les organiser selon les besoins de votre entreprise. Vous pouvez appliquer des balises lorsque vous créez une ressource, et mettre à jour une ressource ultérieurement pour ajouter, réviser ou enlever des balises. Pour obtenir des informations générales sur l'application de balises, reportez-vous à Balises de ressource.
Surveillance des ressources
Vous pouvez surveiller l'état, la capacité et les performances des ressources Oracle Cloud Infrastructure à l'aide de mesures, d'alarmes et de notifications. Pour plus d'informations, reportez-vous à Monitoring et à Notifications.
Déplacement de ressources vers un autre compartiment
Vous pouvez déplacer des clés secrètes d'un compartiment vers un autre. Une fois que vous avez déplacé une clé secrète vers un nouveau compartiment, les stratégies configurées pour le compartiment s'appliquent immédiatement et affectent l'accès à cette clé secrète ainsi qu'à ses versions. Le déplacement d'une clé secrète n'a aucune incidence sur l'accès au coffre auquel une clé secrète est associée. Vous pouvez également déplacer un coffre d'un compartiment à un autre indépendamment du déplacement de ses clés secrètes. Pour plus d'informations, reportez-vous à Gestion des compartiments.