Resource Access Management:FAQ about AccessKey pairs

O que é um par de AccessKey?

Um par de AccessKey consiste em um AccessKey ID e um AccessKey secret, usados juntos para autenticar requisições programáticas para a Alibaba Cloud.

• AccessKey ID: O identificador público e exclusivo do seu par de AccessKey.

• AccessKey secret: A chave privada usada para assinar requisições de API. A assinatura verifica a autenticidade e a integridade da requisição. Mantenha seu AccessKey secret em total sigilo.

Quais tipos de pares de AccessKey estão disponíveis?

• Par de AccessKey da conta Alibaba Cloud (Não recomendado)

  Este par de AccessKey pertence à conta Alibaba Cloud. Por padrão, ele tem permissões totais sobre todos os recursos da conta. Se for comprometido, o risco à segurança será extremamente alto. Recomendamos fortemente que você não crie nem use um par de AccessKey para a sua conta Alibaba Cloud.

• Par de AccessKey de usuário RAM (Recomendado)

  Este par de AccessKey pertence a um usuário RAM, que você deve criar primeiro. O par de AccessKey herda as permissões do usuário RAM, o que possibilita o gerenciamento de acesso com privilégio mínimo. Como prática recomendada, atribua um usuário RAM e um par de AccessKey separados para cada aplicativo independente. Isso evita permissões excessivas e reduz o impacto caso as credenciais sejam comprometidas.

Um par de AccessKey da conta Alibaba Cloud tem, por padrão, permissões totais sobre todos os recursos da conta, o que equivale a permissões de administrador. Ele pode chamar APIs de qualquer serviço em cloud, como Short Message Service, Elastic Compute Service e Object Storage Service, sem necessidade de autorização separada.

Posso usar o mesmo par de AccessKey em vários dispositivos ao mesmo tempo?

Sim. Um par de AccessKey tem a função exclusiva de autenticar e assinar requisições de API, não estando vinculado a um dispositivo específico. Você pode usar o mesmo par de AccessKey para chamar APIs da Alibaba Cloud a partir de vários servidores simultaneamente.

Para reduzir o risco de vazamentos, siga o princípio do privilégio mínimo e atribua um usuário RAM e um par de AccessKey separados para cada aplicativo de negócios.

Quais informações posso visualizar após criar um par de AccessKey?

Após criar um par de AccessKey, é possível visualizar o AccessKey ID, o status, o último serviço em cloud utilizado, a hora do último uso e a hora de criação. Para visualizar as informações do par de AccessKey de um usuário RAM, consulte Visualize as informações sobre os pares de AccessKey de um usuário RAM.

Posso visualizar um AccessKey ID após a criação?

Sim.

Posso visualizar um AccessKey secret após a criação?

Não. Não é possível visualizar nem modificar um AccessKey secret após a criação. Para reduzir o risco de vazamentos, o sistema exibe os secrets de AccessKey para contas Alibaba Cloud e usuários RAM apenas no momento da criação. Armazene-os com segurança.

Se um AccessKey secret for perdido ou precisar ser substituído, crie um novo par de AccessKey. Após armazenar o novo AccessKey secret com segurança, desative ou exclua o par de AccessKey antigo.

Como determinar se um par de AccessKey ainda está em uso?

Para determinar se um par de AccessKey ainda está em uso, visualize a hora do último uso no console ou chame a API correspondente.

• Página de gerenciamento de AccessKey

  Ao fazer logon com uma conta Alibaba Cloud, visualize a hora do último uso dos pares de AccessKey dessa conta. Ao fazer logon como um usuário RAM, visualize a hora do último uso dos pares de AccessKey desse usuário RAM.

• Console do RAM

  Ao fazer logon com uma conta Alibaba Cloud ou como um usuário RAM com permissões de administrador, visualize a hora do último uso dos pares de AccessKey de todos os usuários RAM. Para obter instruções, consulte Visualize as informações sobre os pares de AccessKey de um usuário RAM.

• a operação de API para visualizar a hora do último uso do par de AccessKey

  Chame esta operação de API para visualizar a hora do último uso de um par de AccessKey de conta Alibaba Cloud ou de usuário RAM.

Posso modificar um AccessKey ID após a criação?

Não. Não é possível modificar um AccessKey ID. Você só pode desativar, ativar ou excluir um par de AccessKey.

Um par de AccessKey excluído pode ser restaurado?

O RAM fornece uma lixeira. Quando você exclui o par de AccessKey de um usuário RAM, o sistema move o par para a lixeira. É possível restaurar os pares de AccessKey na lixeira.

O sistema mantém os pares de AccessKey na lixeira por 30 dias. Após esse período, o sistema os remove permanentemente de forma automática. Você também pode excluir permanentemente um par de AccessKey da lixeira. Não é possível restaurar um par de AccessKey excluído permanentemente.

Para obter mais informações, consulte the recycle bin documentation.

O que fazer se houver suspeita de vazamento de um par de AccessKey?

Siga o procedimento em Handle a suspected AccessKey pair leak.

Como encontrar a conta proprietária de um par de AccessKey?

Um par de AccessKey é uma credencial de acesso programático sensível. A Alibaba Cloud não fornece um serviço que permita identificar o proprietário de um par de AccessKey arbitrário.

Se você precisar dessa informação, use um dos seguintes métodos para encontrar o proprietário de um par de AccessKey dentro do seu escopo autorizado:

• Faça logon no console do RAM com sua conta Alibaba Cloud. Na página Users, insira o AccessKey ID na caixa de pesquisa. Se você tiver várias contas Alibaba Cloud, repita a pesquisa em cada conta.

• Ao usar o serviço de diretório de recursos e ative uma trilha de várias contas no ActionTrail, os eventos dos membros são encaminhados ao Log Service ou Object Storage Service. Pesquise a propriedade do AccessKey nos logs de auditoria.

O que fazer ao receber o erro "There is a risk of leakage of this AccessKey."?

Este erro indica que o par de AccessKey usado para autenticação está sob proteção restritiva. Siga o procedimento em Restrictive protection of AccessKey pairs.

O que fazer ao receber o código de erro InvalidAccessKeyId.AccessPolicyDenied?

O erro InvalidAccessKeyId.AccessPolicyDenied também indica que uma política de ACL de rede negou o par de AccessKey. Trate-o da mesma forma que o AccessKeyId.AccessPolicyDenied:

• Verifique as políticas de ACL de rede no nível do AccessKey e no nível da conta.

• Adicione o endereço IP de origem da requisição à lista de permissões.

• Se não for possível determinar o endereço IP de origem, crie um novo par de AccessKey para testes e solução de problemas.

Por que continuo recebendo alertas de anomalia após a desativação ou exclusão de um par de AccessKey?

É normal continuar recebendo alertas de segurança após a desativação ou exclusão de um par de AccessKey. Os motivos comuns incluem o seguinte:

• Os alertas são baseados na análise de modelos comportamentais: O sistema de detecção de segurança analisa o tráfego subjacente e os modelos de comportamento em tempo real. Mesmo que um par de AccessKey tenha sido desativado, um vazamento anterior ou o uso por um invasor pode fazer com que o sistema envie alertas com base em padrões de comportamento históricos.

• Diferenças no escopo de consulta de logs: Por padrão, os operation records do console exibem apenas alguns logs de operações de gravação. As chamadas para operações de leitura, como QueryAccountBalance, podem não ser exibidas. Para visualizar os detalhes completos das chamadas, use um dos seguintes métodos:

  • Faça logon no console do RAM e visualize as notificações de mensagens no console em Security Information.

  • Use o ActionTrail para consultar logs completos de eventos de operação.

• Tratamento de alertas históricos: Se você confirmou que o par de AccessKey está desativado e um novo par de AccessKey está em uso, um alerta pode estar relacionado a um evento de chamada histórico que ocorreu antes da desativação. Ignore o alerta após a verificação.

• Investigação de falsos positivos: Se você suspeitar que um alerta é um falso positivo, use o ActionTrail para consultar os registros de chamadas específicos do par de AccessKey e verificar se ocorreram chamadas anômalas.

Por que a localização do IP em um alerta de anomalia de par de AccessKey difere dos resultados de consultas de terceiros?

As informações de localização de IP nos alertas de segurança da Alibaba Cloud e no ActionTrail têm como base o banco de dados de endereços IP interno da Alibaba Cloud. Este banco de dados difere dos bancos de dados que ferramentas de terceiros usam, como a pesquisa de IP do Baidu. Portanto, o mesmo endereço IP pode ter localizações geográficas diferentes, como China (Hong Kong) na Alibaba Cloud e Singapore em uma ferramenta de terceiros.

Se as localizações de IP diferirem, use o resultado identificado pela Alibaba Cloud como referência oficial.

Por que continuo recebendo alertas de anomalia de par de AccessKey após a exclusão de um usuário RAM ou o cancelamento de uma conta Alibaba Cloud?

O procedimento de tratamento varia de acordo com o cenário:

• Usuário RAM excluído

  O par de AccessKey no alerta pode não pertencer ao usuário RAM excluído. Pode ser outro par de AccessKey que permanece ativado na conta Alibaba Cloud. Faça logon com a conta Alibaba Cloud e abra a página de gerenciamento de AccessKey para verificar o proprietário do AccessKey ID no alerta e, em seguida, desative ou exclua o par de AccessKey anômalo.

• Conta Alibaba Cloud cancelada

  Após o cancelamento de uma conta Alibaba Cloud, o sistema remove automaticamente todos os recursos da conta, incluindo os pares de AccessKey. Nenhuma ação manual é necessária. Se você ainda receber alertas após o cancelamento ou descobrir que um par de AccessKey continua utilizável, verifique o seguinte:

  • O processo de cancelamento da conta foi totalmente concluído. O sistema não remove os recursos se o processo de cancelamento estiver incompleto.

  • O par de AccessKey no alerta pertence a outra conta Alibaba Cloud que não foi cancelada.

As chamadas nos alertas de anomalia de par de AccessKey são exclusivamente chamadas de API ou envolvem logon no console?

Todas as chamadas nos alertas de anomalia de par de AccessKey são exclusivamente chamadas de API e não envolvem logon no console.

Os pares de AccessKey servem apenas para acesso programático aos serviços da Alibaba Cloud por meio de APIs, CLI e SDKs. Eles não permitem fazer logon no Alibaba Cloud Management Console. O logon no console usa a senha da conta ou outro método de autenticação e não tem relação com os pares de AccessKey.

Quando o par de AccessKey de um usuário RAM chama uma API, os logs do ActionTrail exibem o nome do usuário RAM. Este é um comportamento normal de rastreamento de identidade. O ActionTrail registra o evento de chamada correspondente, independentemente de a chamada de API ser bem-sucedida ou falhar.

A política de ACL de rede do AccessKey é compatível com uma lista de bloqueios de IP?

A política de ACL de rede do AccessKey é compatível apenas com o modo de lista de permissões de IP e não permite a configuração direta de lista de bloqueios de IP. Após ativar essa política, apenas os endereços IP na lista de permissões podem usar o par de AccessKey associado para chamar APIs.

Para restringir o acesso de endereços IP específicos aos recursos de serviços em cloud, use um dos seguintes métodos:

• Configure uma política de controle de acesso no console do serviço em cloud de destino. Por exemplo, o Object Storage Service permite a configuração de uma lista de bloqueios de IP em uma política de bucket para negar requisições de endereços IP especificados.

• Ative a política de ACL de rede do AccessKey no RAM e adicione apenas os endereços IP permitidos à lista de permissões. O sistema nega automaticamente os endereços IP fora da lista de permissões, o que fornece indiretamente o efeito de uma lista de bloqueios de IP.

É normal receber alertas de anomalia após configurar uma política de ACL de rede do AccessKey?

Sim. Após ativar uma política de ACL de rede do AccessKey, o sistema bloqueia as chamadas de API de endereços IP fora da lista de permissões e retorna o erro AccessPolicyDenied. O sistema não executa as chamadas, mas o sistema de detecção de segurança ainda registra as tentativas bloqueadas e aciona alertas.

Esse alerta indica que um endereço IP não confiável tentou usar seu par de AccessKey para acessar serviços em cloud, mas a política de ACL de rede bloqueou a requisição de forma eficaz. Este é um comportamento de proteção de segurança esperado e não significa que a chamada foi bem-sucedida.

O que fazer se eu não conseguir adicionar um endereço IP a uma política de ACL de rede do RAM ou enviar a política?

Se você não conseguir adicionar um endereço IP ou enviar a política de ACL de rede, verifique os seguintes itens:

• Política de rede pública: Certifique-se de que o formato do endereço IP esteja correto. O sistema aceita um único endereço IP e notação CIDR, como 192.168.1.0/24. Se você precisar apenas restringir as fontes de acesso à rede pública, adicione explicitamente os endereços IP de destino permitidos em vez de confiar na opção "Allow all public network access".

• Política de VPC: Insira o ID de uma VPC existente. Verifique o ID da VPC no console de VPC. Um ID de VPC inexistente ou formatado incorretamente causa falha no envio.

• Tipos de rede que não exigem restrições: Se você não usar um tipo de rede, como uma VPC, poderá deixar sua política não configurada para evitar falhas de validação causadas por valores inválidos.

Alterar o nome de logon ou o nome de exibição de um usuário RAM altera o par de AccessKey?

Não. O AccessKey ID e o AccessKey secret permanecem inalterados, e as chamadas de API, SDK e CLI continuam funcionando. Use o novo nome de logon para fazer logon no console. Se scripts, single sign-on, políticas ou sistemas internos fizerem referência ao nome de logon antigo, atualize-os. Apenas desativar ou excluir o par de AccessKey, ou excluir o usuário RAM, invalida o par de AccessKey.