Resource Access Management:FAQ about AccessKey pairs

¿Qué es un par de AccessKey?

Un par de AccessKey se compone de un AccessKey ID y un AccessKey secret. Ambos elementos se usan en conjunto para autenticar las solicitudes programáticas dirigidas a Alibaba Cloud.

• AccessKey ID: identificador público y único del par de AccessKey.

• AccessKey secret: clave privada que se utiliza para firmar las solicitudes de API. La firma comprueba la autenticidad y la integridad de la solicitud. Debe mantener el AccessKey secret bajo estricta confidencialidad.

¿Qué tipos de pares de AccessKey están disponibles?

• Par de AccessKey de la cuenta de Alibaba Cloud (no recomendado)

  Este par de AccessKey pertenece a la cuenta de Alibaba Cloud. De forma predeterminada, tiene permisos totales sobre todos los recursos de la cuenta. Si se ve comprometido, el riesgo de seguridad es extremadamente alto. Se recomienda encarecidamente no crear ni utilizar un par de AccessKey para su cuenta de Alibaba Cloud.

• Par de AccessKey de usuario de RAM (recomendado)

  Este par de AccessKey pertenece a un usuario de RAM, el cual debe crearse previamente. El par hereda los permisos de dicho usuario, lo que permite gestionar el acceso con el principio de mínimo privilegio. Como práctica recomendada, asigne un usuario de RAM y un par de AccessKey independientes para cada aplicación. Esto evita otorgar permisos excesivos y reduce el radio de impacto si las credenciales se ven comprometidas.

¿Qué información puedo consultar sobre un par de AccessKey?

Puede view an AccessKey pair's metadata, incluido su AccessKey ID, estado, fecha de creación y datos del último uso.

¿Puedo consultar un AccessKey ID después de crearlo?

Sí.

¿Puedo consultar un AccessKey secret después de crearlo?

No. Por motivos de seguridad, el AccessKey secret solo se puede consultar o descargar en el momento de su creación. Tampoco es posible modificarlo. Si pierde el AccessKey secret o necesita reemplazarlo, la única opción es crear un nuevo par de AccessKey. Asegúrese de copiar y guardar el nuevo AccessKey secret antes de cerrar el cuadro de diálogo de creación, ya que no podrá recuperarlo después.

¿Cómo compruebo si un par de AccessKey está en uso?

Revise la fecha del último uso del par de AccessKey en la consola o mediante la API.

• Página de AccessKey

  Tras iniciar sesión con una cuenta de Alibaba Cloud o como usuario de RAM, consulte la fecha del último uso de sus propios pares de AccessKey.

• Consola de RAM

  Como administrador de RAM, consulte la fecha del último uso de los pares de AccessKey de cualquier usuario de RAM en su cuenta. View the information about AccessKey pairs of a RAM user.

• Operación de API GetAccessKeyLastUsed

  Invoque esta operación para obtener mediante programación la fecha del último uso de un par de AccessKey.

¿Puedo cambiar un AccessKey ID?

No. Los AccessKey ID son inmutables.

¿Puedo restaurar un par de AccessKey eliminado?

Sí, en el caso de los usuarios de RAM. Cuando elimina el par de AccessKey de un usuario de RAM, este se traslada a una papelera de reciclaje.

Los pares de AccessKey eliminados permanecen en la papelera durante 30 días y se pueden restaurar dentro de ese periodo. Una vez purgado un par de AccessKey, no es posible recuperarlo.

Para obtener más información, consulte Delete a RAM user's AccessKey.

¿Qué debo hacer si se filtra un par de AccessKey?

Para obtener más información, consulte AccessKey leak response plan.

¿Las tareas asíncronas ya enviadas continúan ejecutándose después de eliminar un par de AccessKey?

Sí. Las tareas asíncronas (como la creación de instancias o de instantáneas) enviadas con el par de AccessKey siguen ejecutándose y no se ven afectadas por la eliminación. Estas tareas podrían generar cargos adicionales. Revise su facturación después de eliminar el par de AccessKey.

¿Un par de AccessKey deja de ser válido inmediatamente después de eliminarlo?

Existe un retraso de propagación. Las operaciones de la API de RAM rechazan de inmediato un par de AccessKey eliminado, pero servicios en la nube como ECS pueden tardar entre 10 segundos y varias decenas de segundos en reconocer la eliminación. Durante este retraso, el par eliminado aún sirve para invocar operaciones de API y crear recursos. Después de eliminar un par de AccessKey filtrado, se recomienda usar ActionTrail para buscar llamadas inusuales dentro de la ventana de propagación.

¿Cómo identifico qué cuenta es propietaria de un par de AccessKey?

Por motivos de seguridad, Alibaba Cloud no proporciona un servicio público para identificar al propietario de un AccessKey ID.

Para determinar quién posee un AccessKey ID dentro de su organización, utilice uno de los siguientes métodos:

• En la consola de RAM, vaya a la página Users y busque el AccessKey ID. Si gestiona varias cuentas, repita la búsqueda en cada una de ellas.

• Si su organización utiliza Resource Directory, enable a multi-account trail en ActionTrail y luego consulte los registros de auditoría agregados con el AccessKey ID para identificar al propietario.

¿Por qué recibo el error "There is a risk of leakage of this AccessKey"?

Alibaba Cloud detectó una posible filtración y colocó el par de AccessKey bajo protección restrictiva. Resuelva esta situación siguiendo los pasos descritos en Restrictive protection of AccessKey pairs.

¿Por qué sigo recibiendo alertas de llamadas anómalas después de deshabilitar o eliminar un par de AccessKey?

La detección de seguridad de Alibaba Cloud analiza el tráfico subyacente y los modelos de comportamiento en tiempo real. Incluso después de deshabilitar un par de AccessKey, se pueden seguir enviando alertas en los siguientes casos:

• Filtración previa a la deshabilitación: si el par de AccessKey se filtró o se aprovechó indebidamente antes de deshabilitarlo, el sistema continúa marcando el comportamiento anómalo asociado.

• Diferencias en la consulta de registros: la página Operation Records de la consola solo muestra ciertas operaciones de escritura de forma predeterminada. Es posible que las llamadas de API de tipo lectura (como QueryAccountBalance) no aparezcan. Para ver el historial completo de llamadas, revise los mensajes internos de la consola en la página Security Information de la consola de RAM, o bien consulte ActionTrail para obtener los registros de auditoría completos.

• Gestión de alertas históricas: si ya comprobó que el par de AccessKey está deshabilitado y que se utiliza uno de reemplazo, es probable que la alerta corresponda a un evento histórico. Una vez verificado, puede ignorarla sin problema.

• Investigación de falsos positivos: si sospecha que se trata de un falso positivo, use ActionTrail para consultar los registros de llamada específicos asociados a la alerta y compruebe si realmente ocurrió una llamada anómala.

¿Por qué la ubicación de IP en una alerta de anomalía de AccessKey difiere de los resultados de herramientas externas?

La información de ubicación de IP en las alertas de seguridad de Alibaba Cloud y en los registros de auditoría de ActionTrail se basa en la base de datos interna de direcciones IP de Alibaba Cloud. Esta información puede diferir de la ubicación geográfica que muestran herramientas de terceros, como la búsqueda de IP de Baidu. Por ejemplo, una dirección IP podría identificarse como Hong Kong (China) en Alibaba Cloud, pero aparecer como Singapur en una herramienta externa.

Utilice el resultado de identificación de Alibaba Cloud como referencia oficial.

¿Por qué sigo recibiendo alertas de anomalías de AccessKey después de eliminar un usuario de RAM o cancelar el registro de una cuenta de Alibaba Cloud?

Usuario de RAM eliminado

Es posible que el par de AccessKey marcado en la alerta no pertenezca al usuario de RAM eliminado, sino que siga activo bajo la cuenta de Alibaba Cloud (cuenta raíz). Inicie sesión con la cuenta raíz y revise la página de gestión Security Information para identificar y gestionar el par de AccessKey señalado.

Cuenta de Alibaba Cloud dada de baja

Después de cancelar el registro de una cuenta, el sistema limpia automáticamente todos los recursos asociados, incluidos los pares de AccessKey. No se requiere ninguna acción manual. Si continúa recibiendo alertas o nota que un par de AccessKey sigue funcionando, compruebe que el proceso de cancelación de la cuenta finalizó por completo. También verifique si el par de AccessKey pertenece a otra cuenta que no se ha dado de baja.

¿Las llamadas registradas en las alertas de anomalías de AccessKey se originan por API o por inicio de sesión en la consola?

Los pares de AccessKey se utilizan exclusivamente para el acceso programático mediante API, CLI y SDK. No sirven para iniciar sesión en la consola. Todas las llamadas de interfaz registradas en las alertas de anomalías se originan por acceso programático, no por un inicio de sesión en la consola.

Cuando se invoca una API con el par de AccessKey de un usuario de RAM, los registros de auditoría de ActionTrail muestran el nombre de dicho usuario. Este es el mecanismo normal de trazabilidad de identidad y aplica independientemente de si la llamada resulta exitosa o falla.

¿Qué debo hacer cuando una directiva de restricción de acceso de red deniega una llamada de API?

Cuando se configura una directiva de restricción de acceso de red para un par de AccessKey o una cuenta de Alibaba Cloud, se deniegan las llamadas de API provenientes de direcciones IP que no estén en la lista de permitidos. En estos casos, se pueden devolver los siguientes códigos de error:

• AccessKeyId.AccessPolicyDenied

• InvalidAccessKeyId.AccessPolicyDenied

Ambos códigos indican que una directiva de restricción de acceso bloqueó el par de AccessKey. Para resolver este problema:

1. Inicie sesión en la consola de RAM y revise las directivas de restricción de acceso de red a nivel de AccessKey y de cuenta.

2. Agregue la dirección IP de origen a la lista de permitidos de la directiva correspondiente.

3. Si el problema persiste, cree un nuevo par de AccessKey para pruebas y determine si la restricción se aplica a nivel de AccessKey o de cuenta.

¿La directiva de restricción de acceso de red de AccessKey admite listas de bloqueados de IP?

No. La directiva de restricción de acceso de red de AccessKey solo admite el modo de lista de permitidos y no permite configurar directamente una lista de bloqueados de IP.

Para impedir que direcciones IP específicas accedan a servicios en la nube como OSS, considere las siguientes alternativas:

• Configure una lista de bloqueados de IP en la consola del servicio en la nube de destino. Por ejemplo, configure una lista de bloqueados de IP en la consola de OSS para aplicar restricciones exclusivas de este servicio.

• Habilite la directiva de restricción de acceso de red de AccessKey en RAM y agregue únicamente las direcciones IP autorizadas. Este enfoque basado en listas de permitidos bloquea de manera efectiva el acceso desde cualquier dirección IP que no esté incluida.

¿Es normal recibir alertas de llamadas anómalas después de configurar restricciones de acceso de red para AccessKey?

Sí. Al habilitar una directiva de restricción de acceso de red, se bloquean las llamadas de API provenientes de direcciones IP fuera de la lista de permitidos y se devuelve un error AccessPolicyDenied. Sin embargo, el intento bloqueado genera igualmente una alerta de seguridad.

Recibir una alerta no significa que la llamada haya tenido éxito. Indica que una dirección IP no autorizada intentó acceder al recurso y que el intento se bloqueó correctamente. Este es el comportamiento esperado de protección de seguridad.

¿Qué debo hacer si falla la adición de una dirección IP o VPC a la directiva de restricción de acceso de red de RAM?

Si no se puede enviar la configuración de la directiva, revise los siguientes puntos:

• Directiva de red pública: asegúrese de que el formato de la dirección IP sea correcto. Si necesita restringir el acceso a la red pública, agregue explícitamente las direcciones IP de destino en lugar de depender de la opción "Allow all public network access".

• Directiva de VPC: el ID de VPC debe corresponder a una instancia de VPC existente. Compruebe el ID de VPC en la consola de VPC. Un ID de VPC incorrecto o inexistente provoca errores al enviar la configuración.

• Tipos de directiva innecesarios: si no utiliza un tipo de red específico (por ejemplo, si no cuenta con ninguna VPC), omita la configuración de la directiva correspondiente para evitar errores de validación innecesarios.

Solución de problemas de denegaciones inesperadas

Message: The specified parameter "AccessKeyId.AccessPolicyDenied" is not valid.

Message: code: 400, Specified access key denied due to access policy. 

¿Cambiar el nombre de inicio de sesión o de visualización de un usuario de RAM modifica el AccessKey?

No. El AccessKey ID y el AccessKey secret permanecen sin cambios, por lo que las llamadas mediante API, SDK o CLI siguen funcionando. Para iniciar sesión en la consola se requiere el nuevo nombre de inicio de sesión. Actualice los scripts, la configuración de SSO, las directivas o los sistemas internos que hagan referencia al nombre anterior. El AccessKey solo deja de ser válido si se deshabilita, si se elimina o si se elimina el usuario de RAM.