View a markdown version of this page

AWS CloudHSM L'utilisateur ou la politique du SDK client 5 contient des valeurs incohérentes - AWS CloudHSM
Résoudre les valeurs utilisateur incohérentesRésoudre les valeurs de politique MTL incohérentes

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS CloudHSM L'utilisateur ou la politique du SDK client 5 contient des valeurs incohérentes

AWS CloudHSM ne synchronise pas automatiquement les utilisateurs ou les politiques (tels que les paramètres MTL) entre les HSM d'un cluster. La CLI CloudHSM effectue au mieux la synchronisation de ces opérations entre les HSM, mais des incohérences peuvent toujours se produire. Cette page explique comment identifier et résoudre les incohérences tant pour les utilisateurs que pour les politiques.

Résoudre les valeurs utilisateur incohérentes

La user list commande du SDK AWS CloudHSM client 5 renvoie une liste de tous les utilisateurs et de leurs propriétés dans votre cluster. Si l'une des propriétés d'un utilisateur possède la valeur « incohérente », cet utilisateur n'est pas synchronisé au sein de votre cluster. Cela signifie que l'utilisateur existe avec des propriétés différentes sur les différents HSM du cluster. En fonction de la propriété incohérente, différentes étapes de réparation peuvent être effectuées.

Le tableau suivant indique les étapes permettant de résoudre les incohérences pour un seul utilisateur. Si un même utilisateur présente plusieurs incohérences, résolvez-les en suivant ces étapes de haut en bas. Si plusieurs utilisateurs présentent des incohérences, parcourez cette liste pour chaque utilisateur, en résolvant complètement les incohérences pour cet utilisateur avant de passer au suivant.

Note

Pour effectuer ces étapes, vous devez idéalement être connecté en tant qu'administrateur. Si votre compte administrateur n'est pas cohérent, suivez ces étapes en vous connectant à l'administrateur et en répétant les étapes jusqu'à ce que toutes les propriétés soient cohérentes. Une fois que votre compte administrateur est cohérent, vous pouvez continuer à utiliser cet administrateur pour synchroniser les autres utilisateurs du cluster.

Propriété incohérente Exemple de sortie d'une liste d'utilisateurs Implication Méthode de récupération
Le « rôle » de l'utilisateur est « incohérent » 
{
"username": 
"test_user",    
"role": "inconsistent",    
"locked": "false",    
"mfa": [],     
"cluster-coverage": "full"
}
 Cet utilisateur est un utilisateur CryptoUser sur certains HSM, et un administrateur sur d'autres HSM. Cela peut se produire si deux SDK tentent de créer le même utilisateur, en même temps, avec des rôles différents. Vous devez supprimer cet utilisateur et le recréer avec le rôle souhaité.

  1. Connectez-vous en tant qu'administrateur.

  2. Supprimez l'utilisateur sur tous les HSM :

    user delete --username <user's name> --role admin

    user delete --username <user's name> --role crypto-user

  3. Créez l'utilisateur avec le rôle souhaité :

    user create --username <user's name> --role <desired role>
La « couverture du cluster » de l'utilisateur est « incohérente » 
{
"username": "test_user",    
"role": "crypto-user",    
"locked": "false",    
"mfa": [],     
"cluster-coverage": "inconsistent"
}

Cet utilisateur existe sur un sous-ensemble de HSM du cluster. Cela peut se produire en cas de réussite partielle de user create ou de réussite partielle de user delete.

Vous devez terminer votre opération précédente, en créant ou en supprimant cet utilisateur de votre cluster.

Si l'utilisateur ne doit pas exister, procédez comme suit :

  1. Connectez-vous en tant qu'administrateur.

  2. Exécutez cette commande :

    user delete --username<user's name> --role admin

  3. Maintenant, exécutez la commande suivante :

    user delete --username<user's name> --role crypto-user

Si l'utilisateur doit exister, procédez comme suit :

  1. Connectez-vous en tant qu'administrateur.

  2. Exécutez la commande suivante :

    user create --username <user's name> --role <desired role>

Le paramètre « verrouillé » de l'utilisateur est « incohérent » ou « vrai » 
{
"username": 
"test_user",    
"role": "crypto-user",    
"locked": inconsistent,    
"mfa": [],     
"cluster-coverage": "full"
}

Cet utilisateur est bloqué sur un sous-ensemble de HSM.

Cela peut se produire si un utilisateur utilise le mauvais mot de passe et se connecte uniquement à un sous-ensemble de HSM du cluster.

Vous devez modifier les informations d'identification de l'utilisateur pour garantir la cohérence au sein du cluster.

Si l'utilisateur a activé la MFA, procédez comme suit :

  1. Connectez-vous en tant qu'administrateur.

  2. Exécutez la commande suivante pour désactiver temporairement la MFA :

    user change-mfa token-sign --username <user's name> --role <desired role> --disable

  3. Modifiez le mot de passe de l'utilisateur afin qu'il puisse se connecter à tous les HSM :

    user change-password --username <user's name> --role <desired role>

Si la MFA doit être activée pour l'utilisateur, procédez comme suit :

  1. Demandez à l'utilisateur de se connecter et de réactiver la MFA (cela l'obligera à signer des jetons et à fournir sa clé publique dans un fichier PEM) :

    user change-mfa token-sign --username <user's name> --role <desired role> —token <File>

Le statut de la MFA est « incohérent » 
{    
"username": "test_user",    
"role": "crypto-user",    
"locked": "false",    
"mfa": [
  {            
   "strategy": "token-sign",
   "status": "inconsistent"
   }    
],     
"cluster-coverage": "full"
}

Cet utilisateur possède différents indicateurs MFA sur les différents HSM du cluster.

Cela peut se produire si une opération MFA ne s'est terminée que sur un sous-ensemble de HSM.

Vous devez réinitialiser le mot de passe de l'utilisateur et l'autoriser à réactiver la MFA.

Si l'utilisateur a activé la MFA, procédez comme suit :

  1. Connectez-vous en tant qu'administrateur.

  2. Exécutez la commande suivante pour désactiver temporairement la MFA :

    user change-mfa token-sign --username <user's name> --role <desired role> --disable

  3. Vous devrez également modifier le mot de passe de l'utilisateur afin qu'il puisse se connecter à tous les HSM :

    user change-password --username <user's name> --role <desired role>

Si la MFA doit être activée pour l'utilisateur, procédez comme suit :

  1. Demandez à l'utilisateur de se connecter et de réactiver la MFA (cela l'obligera à signer des jetons et à fournir sa clé publique dans un fichier PEM) :

    user change-mfa token-sign --username <user's name> --role <desired role> —token <File>

Résoudre les valeurs de politique MTL incohérentes

À l'instar des utilisateurs, les politiques MTL (ancres de confiance et niveau d'application) ne sont pas automatiquement synchronisées entre les HSM. La CLI CloudHSM effectue une synchronisation optimale lorsque vous exécutez des commandes mTLS, mais des incohérences peuvent toujours se produire. Vous pouvez vérifier l'état de synchronisation de votre configuration mTLS à l'aide des commandes suivantes.

Vérifiez la synchronisation des ancres de confiance de MTL

Exécutez la cluster mtls list-trust-anchors commande pour vérifier l'état de synchronisation de vos ancres de confiance. Dans le résultat, chaque ancre de confiance possède un cluster-coverage champ. Si la valeur est « complète », l'ancre de confiance est présente sur tous les HSM. Si la valeur n'est pas « complète », l'ancre de confiance n'est pas synchronisée entre tous les HSM du cluster. 

{
  "error_code": 0,
  "data": {
    "trust_anchors": [
      {
        "certificate-reference": "0x01",
        "certificate": "<PEM Encoded Certificate>",
        "cluster-coverage": "full"
      }
    ]
  }
}

Si une ancre de confiance présente une couverture de cluster incohérente, réexécutez la commande d'enregistrement ou de désenregistrement pour terminer l'opération :

  • Pour terminer l'enregistrement d'une ancre de confiance absente de certains HSM :

    cluster mtls register-trust-anchor --path <path-to-certificate>

  • Pour terminer le désenregistrement d'une ancre de confiance qui doit être supprimée :

    cluster mtls deregister-trust-anchor --certificate-reference <certificate-reference>

Pour plus d'informations sur la configuration du protocole MTL, consultez la section Configuration du protocole TLS mutuel entre le client et. AWS CloudHSM