Resource Access Management:AccessKey leak response plan

Medidas de segurança do Alibaba Cloud

O Alibaba Cloud fortalece continuamente a segurança dos services de cloud e ajuda a proteger sua conta e seus ativos. Se o Alibaba Cloud detectar, com base em inteligência externa, que seu par de AccessKey foi exposto publicamente, ele o notificará prontamente pelos canais de contato cadastrados. Para proteger a segurança dos seus negócios e dados, o Alibaba Cloud também aplica proteção restritiva a esse par de AccessKey, bloqueando a chamada de APIs de alto risco de determinados services de cloud. Para obter mais detalhes, consulte AccessKey pair restrictive protection.

Resposta manual a uma suspeita de vazamento de um par de AccessKey da conta do Alibaba Cloud (conta raiz)

• Confirme que o par de AccessKey não está mais em uso, acesse a página de gerenciamento de AccessKey e desative e exclua o par de AccessKey diretamente.

• Confirme que o par de AccessKey está em uso, acesse a página de gerenciamento de AccessKey e rotacione o par de AccessKey.

  Primeiro, crie um novo par de AccessKey e armazene o AccessKey secret com segurança. Substitua o par de AccessKey original pelo novo. Confirme que tudo está funcionando normalmente, desative e exclua o par de AccessKey antigo.

Resposta manual a uma suspeita de vazamento de um par de AccessKey de usuário RAM

• Confirme que o par de AccessKey não está mais em uso, acesse o console do RAM e desative e exclua diretamente o par de AccessKey do usuário RAM. Para obter instruções, consulte Disable a RAM user's access key e Delete a RAM user's AccessKey.

  Ao desativar um par de AccessKey, o sistema exige que você conclua a autenticação de segurança (autenticação multifator, MFA). O status do par de AccessKey muda para Disabled somente após o sucesso da autenticação. Se o par de AccessKey tiver sido usado nos últimos 60 dias, o sistema exibirá um alerta informando que desativá-lo pode interromper suas operações. Confirme que nenhuma operação depende do par de AccessKey antes de continuar.

• Confirme que o par de AccessKey está em uso e você pode rotacioná-lo diretamente, rotacione-o o mais rápido possível.

  Crie um novo par de AccessKey. O sistema exibe a caixa de diálogo Scenarios. Selecione seu cenário real entre CLI, Local Development, ECS, ACK, Third-party Application e Other. Crie um novo par de AccessKey e armazene o AccessKey secret com segurança. Substitua o par de AccessKey original pelo novo. Confirme que tudo está funcionando normalmente, desative e exclua o par de AccessKey antigo. Para obter instruções, consulte Rotate an AccessKey for a RAM user.

  Exclua um par de AccessKey e insira manualmente o AccessKey ID para concluir uma segunda confirmação. Se o par de AccessKey estiver desativado há menos de sete dias, o sistema exibirá um alerta informando que excluí-lo pode interromper suas operações. Confirme que nenhuma operação depende do par de AccessKey antes de continuar. Um par de AccessKey excluído não é destruído imediatamente. Ele é movido para a lixeira, retido por 30 dias e, em seguida, removido automaticamente. Para restaurar o par de AccessKey, faça isso dentro do período de retenção.

• Confirme que o par de AccessKey está em uso, mas você não consegue rotacioná-lo facilmente no curto prazo, siga as etapas mostradas na figura a seguir para reduzir o impacto do uso indevido. Conclua a rotação o mais rápido possível depois disso.

  

  Etapa 1: Reduzir as permissões do par de AccessKey

  Identifique primeiro o seu cenário de negócios. Sem interromper as operações atuais, reduza as permissões do par de AccessKey suspeito o mais rápido possível. Restrinja permissões de alto risco para diminuir o risco de danos às suas operações e ao faturamento. Não revogue essa política restritiva até você desativar e excluir o par de AccessKey.

  As permissões de alto risco recomendadas para restrição incluem: impedir que o usuário RAM crie novos usuários RAM ou conceda permissões no RAM, bloquear a liberação de recursos do ecs, RDS, OSS e SLS, e bloquear o envio de SMS.

  O exemplo a seguir mostra uma política personalizada que nega ações de alto risco. Avalie o impacto dela cuidadosamente e ajuste-a de acordo com as necessidades das suas operações.

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": [
          "ram:AddUserToGroup",
          "ram:AttachPolicyToGroup",
          "ram:AttachPolicyToRole",
          "ram:AttachPolicyToUser",
          "ram:ChangePassword",
          "ram:CreateAccessKey",
          "ram:CreateLoginProfile",
          "ram:CreatePolicyVersion",
          "ram:CreateRole",
          "ram:CreateUser",
          "ram:DetachPolicyFromUser",
          "ram:PassRole",
          "ram:SetDefaultPolicyVersion",
          "ram:UpdateAccessKey",
          "ram:SetPasswordPolicy",
          "ram:UpdateRole",
          "ram:UpdateLoginProfile",
          "ram:UpdateUser"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "ecs:DeleteInstance",
          "ecs:DeleteInstances",
          "ecs:DeregisterManagedInstance",
          "ecs:ReleaseDedicatedHost"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "rds:DeleteAccount",
          "rds:DeleteDatabase",
          "rds:DeleteDBInstance",
          "rds:DestroyDBInstance"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "oss:DeleteBucket",
          "oss:DeleteObject",
          "oss:PutBucketAcl",
          "oss:PutBucketPolicy"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "log:DeleteLogStore",
          "log:DeleteProject",
          "log:PutProjectPolicy",
          "log:DeleteProjectPolicy"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Deny",
        "Action": [
          "dysms:CreateProductNew",
          "dysms:CreateSmsTemplateNew",
          "dysms:AddSmsTemplate",
          "dysms:SendSms",
          "dysms:SendBatchSms"
        ],
        "Resource": "*"
      }
    ]
  }

  Para obter instruções, consulte Create a custom policy e Manage RAM user permissions.

  Defina claramente as permissões de negócios necessárias para o par de AccessKey e remova todas as permissões desnecessárias.

  Etapa 2: Ativar o MFA para o usuário RAM

  Como prática recomendada, ative a autenticação multifator (MFA) para todos os usuários RAM na sua conta do Alibaba Cloud (conta raiz) que acessam o console.

  1. Exija o MFA para que os usuários RAM na conta raiz façam logon no console.

     Para obter instruções, consulte Manage RAM user logon settings.

  2. Vincule um dispositivo MFA ao usuário.

     Para obter instruções, consulte Bind an MFA device for a RAM user.

  Etapa 3: Verificar operações anormais do AccessKey

  Verifique se o par de AccessKey vazado apresenta operações anormais e investigue se outras identidades são suspeitas de vazamento. Concentre-se em endereços IP de source anormais e em operações de criação ou exclusão de recursos que suas operações não requerem.

  Investigue as seguintes operações perigosas durante o período de vazamento:

  • Alterações de identidade e permissão: criação de usuários RAM (CreateUser), criação de pares de AccessKey (CreateAccessKey), associação de políticas de acesso (AttachPolicyToUser), criação de funções (CreateRole) e ativação de logon no console (CreateLoginProfile). Eventos como CreateLoginProfile, AttachPolicyToUser e CreateUser normalmente indicam que um invasor está criando contas de backdoor ou escalando privilégios. Preste muita atenção aos endereços IP de source e UserAgents dessas chamadas.

  • Exclusão e liberação de recursos: exclusão de instâncias do ECS (DeleteInstance), exclusão de instâncias do RDS (DeleteDBInstance) e exclusão de buckets do OSS (DeleteBucket).

  • Exfiltração de dados: modificação das permissões de acesso ao bucket do OSS (PutBucketAcl), modificação das políticas do bucket do OSS (PutBucketPolicy) e operações semelhantes.

  • Comportamento de chamada anormal: grande número de solicitações de API em um curto período, operações a partir de endereços IP ou regiões incomuns e operações em lote fora do horário comercial.

  Para verificar: No console do RAM, encontre a lista de AccessKey do usuário RAM e visualize os registros de operação na lista. Alternativamente, na página AccessKey audit do console do ActionTrail, insira o AccessKey ID diretamente para consultar os registros de operação.

  Além do ActionTrail, você pode acessar o console do Security Center e visualize os detalhes dos alertas de vazamento de AccessKey, incluindo os nomes dos usuários RAM criados maliciosamente e os endereços IP de source anormais.

  O recurso de auditoria de AccessKey do ActionTrail mostra todas as chamadas de API de um par de AccessKey especificado nos últimos 90 dias, incluindo o horário da chamada, o nome da ação, o endereço IP de source e o service de cloud acessado. Para obter instruções, consulte Use ActionTrail to monitor the use of AccessKeys.

  Nota

  Para logs de operações do plano de dados que não estão conectados ao ActionTrail, como os do OSS e SLS, use o recurso de log de cada service de cloud para consultá-los.

  Confirme o AccessKey ID específico vazado por meio das notificações enviadas para seu e-mail seguro e mensagens internas. Se a notificação contiver apenas um AccessKey e nenhum outro alerta, geralmente apenas esse par de AccessKey vazou.

  Investigue ainda mais se outros usuários RAM e pares de AccessKey apresentam operações anormais além do par de AccessKey com risco de vazamento conhecido. Se você encontrar comportamentos anormais, confirme com a pessoa responsável se ela realizou as operações. Se houver suspeita de vazamento, trate-o da seguinte forma:

  • Se o usuário RAM precisar continuar em uso, altere imediatamente a senha dele e ative a autenticação multifator (MFA).

  • Se o usuário RAM não foi criado legitimamente, ou se for confirmado como um usuário ocioso que não é mais necessário, exclua-o. Um usuário RAM excluído é movido para a lixeira. Monitore se suas operações são afetadas. Em caso afirmativo, você pode restaurar o usuário RAM rapidamente.

  • Para operações anormais de um par de AccessKey, primeiro restrinja suas permissões e, em seguida, rotacione-o.

  Identificar o escopo de uso do par de AccessKey

  Os endereços IP de source registrados pelo ActionTrail refletem apenas as chamadas de eventos de gerenciamento conectados, como as operações de gerenciamento do OSS GetService e GetBucketInfo. As operações do plano de dados que não estão conectadas ao ActionTrail, como uploads e downloads de objetos do OSS, não são registradas por padrão. Portanto, a lista de IPs de source sozinha não revela o escopo completo de uso do par de AccessKey. Antes de desativar ou excluir o par de AccessKey original, verifique a configuração do AccessKey em cada um dos seguintes ambientes:

  • Máquinas de desenvolvimento local: variáveis de ambiente do desenvolvedor, arquivos de configuração do SDK e arquivos de credenciais do CLI.

  • Pipelines de CI/CD: variáveis de ambiente de jobs de compilação, armazenamentos de credenciais e scripts de implantação.

  • Aplicativos de terceiros e SaaS: credenciais concedidas a plataformas externas que chamam APIs do Alibaba Cloud.

  • Contêineres e imagens: camadas de imagem de contêiner, secrets do Kubernetes e credenciais em modelos de orquestração.

  • Jobs agendados e scripts de operações: entradas crontab do servidor, scripts de backup e coletores de monitoramento.

  • Serviços de mensagens e notificações: aplicações que fazem chamadas, como aplicativos que usam o Short Message Service para enviar mensagens de texto.

  Depois de substituir todos esses ambientes pelo novo par de AccessKey e confirmar que suas operações estão funcionando normalmente, desative ou exclua o par de AccessKey original. Isso evita interrupções nas operações causadas por uma aplicação não atualizada.

  Etapa 4: Verificar cobranças anormais

  Em Despesas e Custos, verifique se há cobranças anormais. Com base nos resultados da etapa anterior, tome medidas de proteção direcionadas para os services afetados.

Por que meu par de AccessKey é detectado como vazado mesmo estando armazenado em um repositório privado, Nacos ou banco de dados offline?

Mesmo quando você acredita que seu par de AccessKey está armazenado com segurança, ele ainda pode ser detectado ou roubado das seguintes formas comuns:

• Repositórios de código: se um repositório privado foi público anteriormente, recebeu fork, ou um colaborador enviou o código para outro local, o par de AccessKey ainda pode ser detectado por services de varredura.

• Centros de configuração (como o Nacos): se o centro de configuração não tiver controle de acesso, tiver vulnerabilidades ou o servidor tiver sido comprometido, os pares de AccessKey armazenados em texto simples podem ser roubados.

• Armazenamento offline: se o aplicativo ou script que lê o par de AccessKey se conectar à internet para chamar APIs, a chave poderá ser interceptada durante a transmissão ou gravada em um log.

• Vulnerabilidades de aplicativos: vulnerabilidades de execução remota de código (RCE) ou leitura arbitrária de arquivos podem permitir que invasores roubem pares de AccessKey de arquivos de configuração no servidor.

Para evitar vazamentos futuros:

• gerencie credenciais usando a ferramenta Credentials em vez de embutir pares de AccessKey no código.

• configure restrições de acesso à rede (lista de permissões de IP) para pares de AccessKey.

• Evite gravar pares de AccessKey diretamente no código-source ou em arquivos de configuração.

Diretrizes de uso seguro para usuários RAM após um vazamento

Após o vazamento do par de AccessKey da sua conta do Alibaba Cloud (conta raiz), siga estas diretrizes para restaurar o uso seguro:

1. Crie um usuário RAM separado: não use a conta raiz para crie pares de AccessKey. No console do RAM, crie um usuário RAM separado e conceda a ele apenas as permissões mínimas necessárias. Ao criá-lo, observe os seguintes pontos validados:

   • Selecione a caixa de seleção I confirm that I must create an AccessKey pair e você deve concluir a autenticação de segurança (autenticação multifator, MFA) para continuar a criação.

   • O AccessKey secret é exibido apenas uma vez durante a criação. Depois de fechar a caixa de diálogo, você não poderá visualizá-lo novamente. Salve-o com segurança imediatamente.

   • Ao conceder permissões, a permissão AdministratorAccess é marcada como alto risco. Siga o princípio do menor privilégio e conceda apenas as permissões mínimas que o usuário RAM precisa para os services necessários (como AliyunOSSReadOnlyAccess) e evite conceder AdministratorAccess.

   • A menos que seu cenário exija chamadas sem senha de longo prazo, o console recomenda o uso de credenciais temporárias STS Token em vez de um par de AccessKey permanente para reduzir ainda mais o risco de vazamento.

2. Escopo de permissão do par de AccessKey: um par de AccessKey de um usuário RAM tem apenas as permissões dentro do escopo das políticas de acesso associadas. Ele não herda todas as permissões da conta raiz.

3. Verifique a configuração do AccessKey no seu código: verifique todos os parâmetros de configuração do AccessKey no seu código e remova os pares de AccessKey em texto simples. Se o seu código foi enviado para uma plataforma de hospedagem de código de terceiros, como o GitHub, você pode usar o recurso AccessKey pair leak detection do Security Center para verificar a exposição.

4. Armazene credenciais com segurança: use variáveis de ambiente ou o Key Management Service (KMS) para armazenar pares de AccessKey e evite embuti-los no código. Para obter instruções, consulte Best practices for accessing Alibaba Cloud OpenAPI.

Posso solicitar a desativação de emergência de um par de AccessKey que pertence a uma conta diferente?

Devido à proteção de privacidade e ao isolamento de permissões, o Alibaba Cloud não pode desativar diretamente, com base em um relatório de vazamento, um par de AccessKey que não pertence à conta na qual você fez logon. Trate a situação da seguinte forma:

1. Se você conhecer a conta proprietária do par de AccessKey, entre em contato com o titular da conta e peça que ele trate do problema.

2. Se você tiver acesso à conta proprietária do par de AccessKey, poderá usar a API DeleteAccessKey ou o console do RAM e exclua-o você mesmo.

3. Para pares de AccessKey vazados que pertencem a outras contas às quais você não tem acesso, coordene o tratamento por meio de canais legais ou de conformidade de segurança.