Todos os produtos
Search
Central de documentação

Object Storage Service:Reduza os riscos de acesso não autorizado causados pelo vazamento de pares de AccessKey

Última atualização: Jul 03, 2026

Se os pares de AccessKey de usuários individuais ou corporativos vazarem, pessoas sem permissão para acessar recursos do Object Storage Service (OSS) poderão executar operações nesses recursos, o que compromete a segurança dos dados. Para resolver esse problema, o OSS oferece práticas recomendadas que garantem a proteção das informações.

Importante

As práticas recomendadas a seguir são medidas gerais de segurança, e não soluções completas. Elas servem apenas como referência e podem não ser adequadas aos seus cenários de negócios. Recomendamos manter-se atento às ameaças à segurança de dados e adotar as medidas preventivas necessárias.

Defina a ACL dos seus buckets ou objetos como privada

Não configure a lista de controle de acesso (ACL) dos seus buckets ou objetos como leitura pública ou leitura e gravação públicas, a menos que seu negócio exija que todos os usuários, incluindo anônimos, leiam e gravem dados nos recursos do OSS. Por exemplo, ao definir a ACL de um bucket como leitura pública ou leitura e gravação públicas, as seguintes alterações entram em vigor:

  • Leitura e gravação públicas: Todos os usuários, inclusive anônimos, podem ler e gravar dados nos objetos do bucket.

    Aviso

    Qualquer usuário da internet pode acessar os objetos do bucket e gravar dados nele. Isso pode resultar em vazamento de dados e custos inesperadamente altos. Se alguém gravar dados ou informações proibidas nos objetos do bucket, seus direitos e interesses legítimos poderão ser violados. Recomendamos não definir a ACL do bucket como leitura e gravação públicas, exceto quando estritamente necessário.

  • Leitura pública: Apenas o proprietário do bucket pode gravar dados nos objetos. Outros usuários, incluindo anônimos, conseguem ler o conteúdo armazenado.

    Aviso

    Todos os usuários da internet podem acessar os objetos no bucket, o que pode causar vazamento de dados e gerar cobranças imprevistas. Tenha cautela ao configurar a ACL do bucket como leitura pública.

Buckets ou objetos com acesso de leitura pública ou leitura e gravação públicas podem levar a violações de dados. Por isso, recomendamos definir a ACL do objeto ou do bucket como privada. Com essa configuração, somente o proprietário do bucket tem permissão para ler e gravar dados nos objetos contidos nele. Antes de alterar a ACL do objeto ou do bucket para privada, verifique se essa mudança não afetará suas operações comerciais.

Existem vários métodos para definir a ACL do objeto ou do bucket como privada. Para mais informações, consulte ACLs de bucket e Configurar ACL para objetos.

Não inclua pares de AccessKey em texto simples no código nem armazene localmente pares criptografados

Pares de AccessKey em texto simples inseridos diretamente no código podem vazar junto com ele. Mesmo quando criptografados e armazenados localmente, os pares ainda apresentam riscos, pois o conteúdo criptografado e descriptografado reside na memória e pode ser transferido para outro dispositivo. Aplicativos móveis e softwares em computadores estão particularmente vulneráveis a essas falhas. Para obter dados descriptografados, invasores precisam apenas utilizar técnicas como injeção, API hooking e depuração dinâmica.

Para evitar pares de AccessKey em texto simples no código, utilize plug-ins de segredo gerenciado para SDKs da Alibaba Cloud no servidor. Dessa forma, você impede que os pares vazem juntamente com o source code ou o código compilado. Para mais detalhes sobre os plug-ins de segredo gerenciado para SDKs da Alibaba Cloud, consulte Plug-in de segredo gerenciado para SDKs da Alibaba Cloud.

Importante

Este método não se aplica a clientes. Não incorpore pares de AccessKey em aplicativos cliente.

Acesse o OSS usando um usuário RAM

O par de AccessKey de uma conta Alibaba Cloud possui permissões totais sobre todas as operações de API. Utilizar essas credenciais para realizar tarefas no OSS representa um alto risco. Recomendamos o uso de um usuário RAM para chamar operações de API ou executar rotinas de O&M.

Crie usuários RAM e conceda permissões específicas para gerenciar o acesso aos seus recursos. O RAM ajuda a manter sua conta Alibaba Cloud e senha sob sigilo absoluto em cenários onde múltiplos colaboradores da empresa precisam gerenciar recursos na nuvem de forma conjunta. Além disso, permite atribuir apenas as permissões mínimas necessárias, reforçando a segurança dos dados. Para mais informações, consulte Criar um usuário RAM.

Após criar um usuário RAM, utilize políticas RAM para conceder as permissões adequadas. Assim, é possível gerenciar usuários (como funcionários, sistemas e aplicações) e controlar quais recursos eles podem acessar. Por exemplo, a política RAM abaixo impede que determinados usuários RAM acessem um bucket chamado examplebucket, bem como seus objetos ou diretórios.

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "oss:*",
            "Resource": [
                "acs:oss:*:*:examplebucket",
                "acs:oss:*:*:examplebucket/*"
            ]
        }
    ]
}

Também é possível usar políticas RAM para impedir que usuários excluam diretórios em um bucket ou para autorizar apenas leitura dos recursos. Para mais exemplos, consulte Exemplos comuns de políticas RAM.

Ative a MFA

A autenticação multifator (MFA) é um método eficaz e fácil de usar. Ao ativar a MFA, o login no Alibaba Cloud Management Console exigirá nome de usuário, senha e um código de verificação dinâmico gerado por um dispositivo MFA. Isso bloqueia acessos não autorizados e protege sua conta Alibaba Cloud mesmo em caso de vazamento de senhas.

Ative a MFA para sua conta Alibaba Cloud seguindo as instruções em Vincular um dispositivo MFA a uma conta Alibaba Cloud. Também é possível habilitar a MFA para usuários RAM. Consulte Vincular um dispositivo MFA a um usuário RAM para mais detalhes.

Acesse o OSS com credenciais temporárias fornecidas pelo STS

Utilize o Security Token Service (STS) para gerar credenciais de acesso temporário e autorizar um usuário RAM a acessar seus recursos do OSS por um período determinado. Essa abordagem elimina a necessidade de compartilhar seu par de AccessKey, aumentando significativamente a segurança dos dados.

Para saber como acessar o OSS com credenciais temporárias do STS, consulte Usar credenciais temporárias fornecidas pelo STS para acessar o OSS.

Configure políticas de bucket

Configure políticas de bucket para conceder a outros usuários permissões de acesso a recursos específicos do OSS dentro de um bucket. É possível, por exemplo, permitir que outras contas acessem ou gerenciem todos os recursos ou apenas parte deles. Da mesma forma, você pode atribuir permissões diferentes a distintos usuários RAM da mesma conta.

Ao configurar políticas de bucket, siga o princípio do menor privilégio (PoLP) para minimizar riscos de segurança.

  • Evite conceder acesso a todos os recursos do bucket

    Para prevenir permissões excessivas e acessos indevidos, conceda autorização apenas sobre os caminhos de recursos estritamente necessários.

  • Não permita acesso anônimo

    Contas anônimas conseguem acessar o OSS se receberem um endpoint e o nome de um bucket. No entanto, endpoints podem ser enumerados e nomes de buckets obtidos via URLs dos objetos acessíveis. Portanto, o acesso anônimo eleva os riscos de segurança.

  • Especifique a Action

    Ao configurar uma política de bucket no console do OSS, a opção Action — que oferece quatro operações de autorização predefinidas — serve apenas como atalho e pode não atender plenamente às necessidades do seu negócio. Recomendamos conceder apenas as permissões essenciais através das Configurações Avançadas. Por exemplo, permissões de somente leitura incluem oss:ListObjects e oss:GetObject. Na maioria dos casos, basta a permissão oss:GetObject para baixar um objeto.

  • Ative HTTPS para acesso

    Habilite HTTPS para mitigar problemas como ataques man-in-the-middle e sequestro de domínio. Além disso, navegadores como Google Chrome bloqueiam por padrão o carregamento de recursos HTTP em sites HTTPS. Certifique-se de ativar o HTTPS, pois é a solução mais econômica e eficaz contra diversas vulnerabilidades.

  • Defina endereços IP de origem

    Caso os endereços IP usados para acessar recursos do OSS sejam fixos e conhecidos, recomendamos configurá-los explicitamente na política.

Por exemplo, use uma política de bucket para permitir que o usuário RAM Test baixe todos os objetos do diretório log em examplebucket utilizando SDKs do OSS ou a ferramenta de linha de comando ossutil.

Defina Action como Advanced Settings e selecione oss:GetObject. Configure Effect como Allow. Na seção Condition, escolha HTTPS para Access Method e insira 10.10.10.10 em IP =. Em seguida, clique em OK.