View a markdown version of this page

AWS CloudHSM El usuario o la política del SDK 5 del cliente contienen valores incoherentes - AWS CloudHSM
Resolver valores de usuario incoherentesResuelva los valores incoherentes de la política mTL

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

AWS CloudHSM El usuario o la política del SDK 5 del cliente contienen valores incoherentes

AWS CloudHSM no sincroniza automáticamente los usuarios o las políticas (como la configuración de mTLS) entre los HSM de un clúster. La CLI de CloudHSM realiza al máximo la sincronización de estas operaciones entre los HSM, pero aún pueden producirse inconsistencias. En esta página, se describe cómo identificar y resolver las incoherencias tanto para los usuarios como para las políticas.

Resolver valores de usuario incoherentes

El user list comando del AWS CloudHSM Client SDK 5 devuelve una lista de todos los usuarios y las propiedades de los usuarios del clúster. Si alguna de las propiedades de un usuario tiene el valor "incoherente «, este usuario no está sincronizado en todo el clúster. Esto significa que el usuario existe con propiedades diferentes en los distintos HSM del clúster. En función de qué propiedad no sea coherente, se pueden tomar diferentes medidas de reparación.

En la siguiente tabla se incluyen los pasos para resolver las incoherencias en el caso de un solo usuario. Si un solo usuario tiene varias incoherencias, resuélvalas siguiendo estos pasos de principio a fin. Si hay varios usuarios con incoherencias, revise esta lista para cada usuario y resuelva por completo las incoherencias de ese usuario antes de pasar al siguiente.

nota

Para realizar estos pasos, lo ideal es iniciar sesión como administrador. Si su cuenta de administrador no es coherente, siga estos pasos: inicie sesión con el administrador y repita los pasos hasta que todas las propiedades sean coherentes. Una vez que su cuenta de administrador sea coherente, puede usar esa cuenta de administrador para sincronizar a otros usuarios del clúster.

Propiedad incoherente Ejemplo de salida de una lista de usuarios Implicación Método de recuperación
El «rol» del usuario es «incoherente» 
{
"username": 
"test_user",    
"role": "inconsistent",    
"locked": "false",    
"mfa": [],     
"cluster-coverage": "full"
}
 Este usuario es administrador CryptoUser en algunos HSM y administrador en otros HSM. Esto puede ocurrir si dos SDK intentan crear el mismo usuario, al mismo tiempo y con roles diferentes. Debe eliminar este usuario y volver a crearlo con el rol deseado.

  1. Inicie sesión como administrador.

  2. Elimine el usuario en todos los HSM:

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

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

  3. Cree el usuario con el rol deseado:

    user create --username <user's name> --role <desired role>
La «cobertura de clúster» del usuario es «incoherente» 
{
"username": "test_user",    
"role": "crypto-user",    
"locked": "false",    
"mfa": [],     
"cluster-coverage": "inconsistent"
}

Este usuario existe en un subconjunto de HSM del clúster. Esto puede suceder si un user create lo ha conseguido parcialmente o si un user delete lo ha hecho parcialmente.

Debe finalizar la operación anterior, ya sea creando o quitando este usuario del clúster.

Si el usuario no debería existir, siga estos pasos:

  1. Inicie sesión como administrador.

  2. Ejecute este comando:

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

  3. Ahora, ejecute el siguiente comando:

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

Si el usuario debería existir, siga estos pasos:

  1. Inicie sesión como administrador.

  2. Use el siguiente comando:

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

El parámetro «bloqueado» del usuario es «incoherente» o «verdadero» 
{
"username": 
"test_user",    
"role": "crypto-user",    
"locked": inconsistent,    
"mfa": [],     
"cluster-coverage": "full"
}

Este usuario está bloqueado en un subconjunto de HSM.

Esto puede ocurrir si un usuario utiliza una contraseña incorrecta y solo se conecta a un subconjunto de HSM del clúster.

Debe cambiar las credenciales del usuario para que sean coherentes en todo el clúster.

Si el usuario tiene la MFA activada, siga estos pasos:

  1. Inicie sesión como administrador.

  2. Utilice el siguiente comando para desactivar temporalmente la MFA:

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

  3. Cambie la contraseña del usuario para que pueda iniciar sesión en todos los HSM:

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

Si MFA debe estar activo para el usuario, siga estos pasos:

  1. Haga que el usuario inicie sesión y vuelva a habilitar la MFA (esto requerirá que firme los tokens y proporcione su clave pública en un archivo PEM):

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

El estado de la MFA es «incoherente» 
{    
"username": "test_user",    
"role": "crypto-user",    
"locked": "false",    
"mfa": [
  {            
   "strategy": "token-sign",
   "status": "inconsistent"
   }    
],     
"cluster-coverage": "full"
}

Este usuario tiene diferentes marcadores de MFA en los diferentes HSM del clúster.

Esto puede suceder si una operación de MFA solo se completa en un subconjunto de HSM.

Debe restablecer la contraseña del usuario y permitir que vuelva a activar la MFA.

Si el usuario tiene la MFA activada, siga estos pasos:

  1. Inicie sesión como administrador.

  2. Utilice el siguiente comando para desactivar temporalmente la MFA:

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

  3. También tendrá que cambiar la contraseña del usuario para que pueda iniciar sesión en todos los HSM:

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

Si la MFA debe estar activa para el usuario, siga estos pasos:

  1. Haga que el usuario inicie sesión y vuelva a habilitar la MFA (esto requerirá que firme los tokens y proporcione su clave pública en un archivo PEM):

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

Resuelva los valores incoherentes de la política mTL

Al igual que los usuarios, las políticas de mTLS (bases de confianza y nivel de cumplimiento) no se sincronizan automáticamente entre los HSM. La CLI de CloudHSM realiza una sincronización óptima cuando se ejecutan comandos mTLS, pero pueden producirse incoherencias. Puede comprobar el estado de sincronización de la configuración de mTLS mediante los siguientes comandos.

Compruebe si los mTLS confían en la sincronización de ancl

Ejecute el cluster mtls list-trust-anchors comando para comprobar el estado de sincronización de sus anclas de confianza. En la salida, cada ancla de confianza tiene un cluster-coverage campo. Si el valor es «completo», el ancla de confianza está presente en todos los HSM. Si el valor no es «completo», el anclaje de confianza no está sincronizado en todos los HSM del clúster. 

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

Si un ancla de confianza tiene una cobertura de clústeres incoherente, vuelva a ejecutar el comando de registro o anulación del registro para completar la operación:

  • Para terminar de registrar un ancla de confianza que falta en algunos HSM:

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

  • Para terminar de anular el registro de un ancla de confianza que se debe eliminar:

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

Para obtener más información sobre la configuración de los MTL, consulte Configurar el TLS mutuo entre el cliente y. AWS CloudHSM