Overview of permissions and access control - Object Storage Service: Central de Documentação do Alibaba Cloud

Seleção rápida

Escolha o mecanismo de controle de permissões com base no seu cenário:

Cenário	Solução recomendada
Manter os dados privados e bloquear acessos não autorizados	Defina a Bucket ACL como `private`, que é a configuração padrão.
Autorizar vários usuários a acessar um bucket específico	Use a Bucket Policy.
Gerenciar centralmente todos os recursos acessíveis a um usuário	Anexe a RAM policy ao usuário.
Compartilhar recursos com outras contas Alibaba Cloud	Use a Bucket Policy ou Use a RAM role for cross-account access to OSS.
Conceder a várias aplicações ou equipes acessos diferentes ao mesmo bucket	Use o Access Point para fornecer um endpoint e uma política independentes para cada aplicação ou equipe.
Definir limites de permissão centralmente em cenários de múltiplas contas, como aplicar o Block Public Access	Adote a Control Policy.
Publicar recursos estáticos legíveis por qualquer pessoa	Configure a Bucket ACL como `public-read` e use a Hotlink protection para evitar o uso não autorizado dos recursos. Essa configuração não terá efeito se o Block Public Access estiver ativado para a conta ou para o bucket.
Evitar exposição de dados causada por configuração incorreta	Ative o Block Public Access. A autorização pública configurada via ACL ou bucket policy deixará de ter efeito.
Acessar o OSS via JavaScript no navegador	configure CORS rules para o bucket. O CORS controla apenas o acesso cross-origin do navegador e não concede nem nega permissões de acesso.

Como o OSS avalia permissões

O OSS avalia cada solicitação com base nos mecanismos de controle de permissões aplicáveis: ACLs, bucket policies, políticas do Resource Access Management (RAM), control policies do Resource Directory e access point policies (AP policies). Cada mecanismo é descrito em Métodos de controle de permissões.

O serviço utiliza um processo de autorização diferente para cada tipo de solicitação:

Solicitações assinadas — Após validar a assinatura, o OSS avalia a control policy do Resource Directory (se houver), a RAM policy, a bucket policy e a ACL.
Solicitações anônimas — O OSS verifica se a control policy do Resource Directory (se houver), a bucket policy e a ACL permitem acesso público.

Toda avaliação retorna um dos seguintes resultados:

Allow — Uma política concede acesso explicitamente.
Explicit Deny — Uma política nega acesso explicitamente. O Explicit Deny tem a maior prioridade.
Implicit Deny — Nenhuma política concede acesso; portanto, a solicitação é negada.

Ao configurar mais de um mecanismo, as seguintes regras se aplicam:

Múltiplos tipos de política — É possível usar uma bucket policy, uma RAM policy e uma control policy simultaneamente. O OSS avalia todas as políticas aplicáveis e permite a solicitação somente quando todas elas a autorizarem. Uma control policy define um limite de permissão, em vez de conceder acesso por si só.
Prioridade da ACL de objeto — A ACL de um objeto tem prioridade maior que a ACL do bucket. Se você não especificar uma ACL de objeto, ele herdará a ACL do bucket.
Solicitações via access point — Quando um usuário acessa um bucket por meio de um access point, o resultado combinado da avaliação da RAM policy e da bucket policy deve ser Allow, e a AP policy também deve resultar em Allow.
Block Public Access — Com o Block Public Access ativado, qualquer autorização pública configurada via ACL ou bucket policy perde o efeito.

Para consultar o processo completo de autorização, veja Details of OSS authorization.

Métodos de controle de permissões

ACL

Uma ACL determina se um recurso do OSS é público ou privado por meio de níveis de permissão predefinidos.

A Bucket ACL controla as permissões de acesso padrão de um bucket, enquanto a object ACL gerencia as permissões de um único objeto e possui prioridade superior. Caso nenhuma ACL de objeto seja especificada, o objeto herdará a ACL do bucket. A tabela a seguir descreve os níveis de permissão suportados.

Nível de permissão	Aplica-se a	Efeito
`private`	ACL de bucket e ACL de objeto	Os dados são privados. Somente o proprietário do recurso ou usuários autorizados podem acessá-los.
`public-read`	ACL de bucket e ACL de objeto	Qualquer pessoa pode ler os dados. Apenas o proprietário do recurso ou usuários autorizados podem gravar neles.
`public-read-write`	ACL de bucket e ACL de objeto	Todos podem ler e gravar os dados.
`default`	ACL de objeto	O objeto herda a ACL do bucket.

A ACL suporta apenas níveis de permissão predefinidos e não permite especificar principais autorizados ou condições. Para um controle mais granular, utilize uma bucket policy ou uma RAM policy.

Bucket policy

A Bucket Policy é uma política de autorização configurada em um bucket que define quem pode acessar os recursos contidos nele. Essa política pode autorizar usuários RAM, outras contas Alibaba Cloud e usuários anônimos, além de impor condições como restrições de endereço IP, VPC e horário.

Uma única bucket policy pode autorizar vários usuários a acessar o mesmo bucket, eliminando a necessidade de configurar uma política separada para cada usuário.

Tutoriais: Dual access control with VPC and bucket policies | Share data across departments based on a bucket policy

RAM policy

A RAM policy é uma política de autorização vinculada a uma identidade de usuário. Ela define quais recursos do OSS esse usuário pode acessar, sendo ideal para gerenciar centralmente as permissões de um usuário ou aplicação em vários buckets.

O OSS fornece políticas de sistema, como AliyunOSSFullAccess e AliyunOSSReadOnlyAccess, prontas para uso, além de suportar políticas personalizadas. As funções RAM habilitam o acesso entre contas e a autorização temporária via STS.

Tutoriais: Use a RAM role for cross-account access to OSS | Control OSS access with RAM policies

Control policy

Uma control policy é uma política de controle de acesso baseada na hierarquia de recursos do Resource Directory, como pastas ou membros, usada principalmente para definir limites de permissão. Em cenários de gerenciamento de múltiplas contas, uma control policy personalizada pode aplicar restrições centralizadas às políticas de segurança de bucket das contas membros, como exigir a ativação do Block Public Access. Para mais detalhes, consulte Control Policy.

Access Point

O Access Point oferece um endpoint de acesso independente para um bucket. Quando várias aplicações ou equipes precisam acessar o mesmo bucket com permissões distintas, crie um access point separado para cada parte e use uma access point policy (AP policy) para gerenciar suas permissões. Essa abordagem evita a manutenção de regras complexas em uma única bucket policy.

Cada access point possui um endpoint independente, uma AP policy e configurações próprias de restrição de rede. Uma solicitação recebida por um access point é avaliada pela AP policy, além da RAM policy e da bucket policy. Para conhecer as regras de avaliação, consulte Como o OSS avalia permissões.

Acesso temporário

Dois métodos fornecem acesso temporário aos recursos do OSS:

Autorização temporária STS — Uma função RAM possibilita o acesso entre contas e a autorização temporária via STS.
URL assinada — Oferece maior segurança que a proteção contra hotlink, pois o campo Referer no cabeçalho de uma solicitação HTTP pode ser falsificado.

Comparação entre métodos de controle de permissões

A tabela abaixo compara os métodos de controle de permissões oferecidos pelo OSS:

Método	Local de configuração	Perspectiva de gerenciamento	Granularidade e condições	Requisitos de configuração
ACL	No bucket ou em um único objeto	Focada no recurso: se ele é público ou privado	Apenas níveis de permissão predefinidos. Não permite especificar principais autorizados ou condições.	Somente o proprietário do bucket pode definir ou modificar sua ACL.
Bucket policy	No bucket	Focada no recurso: quem pode acessar os recursos nele contidos	Principais autorizados, ações, recursos e condições como restrições de IP, VPC e horário	Mais simples de configurar que uma RAM policy, com opção de configuração gráfica no console. Proprietários de buckets podem conceder permissões diretamente sem precisar de permissões operacionais no RAM.
RAM policy	Em uma identidade RAM	Focada na identidade: quais recursos do OSS ela pode acessar	Ações e recursos para a identidade, com condições opcionais. Suporta políticas de sistema e personalizadas. Não exige o elemento `Principal`.	Requer permissões operacionais no RAM.
Control policy	Em cada nível da hierarquia de recursos no Resource Directory, como pasta ou membro	Focada na governança organizacional: restringe limites de permissão centralizadamente em todo o Resource Directory	Limites de permissão para contas membros, com condições opcionais. Não exige o elemento `Principal`.	Gerenciada no Resource Directory.
AP policy	Em um access point	Focada no endpoint: permissões separadas para cada aplicação ou equipe que acessa o mesmo bucket	Ações, recursos, principais e condições para solicitações recebidas pelo access point. Restrições de rede são configuradas separadamente.	Gerenciada no access point.

Utilize as diretrizes a seguir para escolher entre os métodos:

Autorizar vários usuários a acessar o mesmo recurso — A bucket policy é mais eficiente, pois uma única política especifica a lista de usuários permitidos.
Gerenciar todas as permissões de recursos de um único usuário — A RAM policy oferece uma abordagem mais intuitiva.
Conceder acesso anônimo — Dentre os tipos de política, apenas a bucket policy suporta acesso anônimo. A ACL também permite acesso anônimo nos níveis public-read e public-read-write.
Restringir permissões em várias contas — A control policy restringe centralmente os limites de permissão. Ela limita o que as contas membros podem fazer, em vez de conceder acesso.
Separar o acesso para múltiplas aplicações ou equipes — A AP policy mantém as permissões de cada parte independentes e evita regras complexas em uma única bucket policy.

Sintaxe da política de autorização

A bucket policy, a RAM policy, a control policy e a AP policy são definidas no formato JSON. A tabela a seguir descreve os elementos principais:

Elemento	Descrição
`Effect`	O efeito da autorização: `Allow` ou `Deny`.
`Principal`	O principal autorizado. A RAM policy e a control policy não exigem este elemento.
`Action`	A operação autorizada, como `oss:GetObject`.
`Resource`	O escopo dos recursos autorizados.
`Condition`	A condição sob a qual a política entra em vigor. Este elemento é opcional.

Para a descrição completa da sintaxe e a lista de Actions, consulte OSS authorization syntax and elements.

Proteção de segurança

Block Public Access

Ao ativar o Block Public Access, qualquer autorização pública configurada via ACL ou bucket policy deixa de ter efeito. As permissões de acesso público existentes são ignoradas e novas permissões desse tipo não podem ser criadas. Isso previne a exposição de dados causada por configurações incorretas.

É possível configurar o Block Public Access no nível da conta (aplicando-se a todos os buckets), bem como nos níveis de bucket, access point e object FC access point. A prioridade decresce nessa ordem, tornando a configuração no nível da conta a de maior prioridade.

Se você armazena dados sensíveis e não precisa de acesso anônimo, ative o Block Public Access no nível da conta.

Importante

O Block Public Access e o acesso público são mutuamente exclusivos. Se o Block Public Access estiver ativado para a conta, o bucket ou o access point, uma ACL public-read ou uma bucket policy pública não terão efeito. Verifique as configurações do Block Public Access antes de publicar recursos publicamente.

Proteção contra hotlink

A Hotlink protection valida a origem das solicitações HTTP, como os cabeçalhos Referer e User-Agent, para impedir que sites não autorizados referenciem seus recursos do OSS. Configure essa proteção usando listas de permissões, listas de bloqueios ou expressões regulares. Uma lista de permissões autoriza apenas domínios específicos, enquanto uma lista de bloqueios nega domínios determinados. Utilize a proteção contra hotlink para evitar o uso não autorizado de recursos como imagens e vídeos.

Como o campo Referer pode ser falsificado, prefira usar uma URL assinada para maior segurança, que é um método de acesso temporário.

Compartilhamento de recursos de origem cruzada (CORS)

Por padrão, o navegador impede que o JavaScript em uma página web acesse recursos em um nome de domínio diferente. Após configure CORS rules, o OSS retorna cabeçalhos cross-origin na resposta para que o navegador permita a solicitação. O CORS aplica-se a cenários como uploads diretos de arquivos pelo frontend e recuperação de recursos.

O CORS resolve apenas a restrição de mesma origem dos navegadores. Ele não concede nem nega permissões de acesso; portanto, configure o CORS além de um mecanismo de controle de permissões, e não como substituto.

Referências

Os tópicos a seguir fornecem mais informações sobre permissões e controle de acesso no OSS: