Object Storage Service:Processo de autorização

Quando o OSS recebe uma solicitação não anônima, ele avalia a solicitação com base no resultado da autenticação, nas políticas de sessão baseadas em função, nas políticas baseadas em identidade (políticas do RAM), nas políticas de bucket, nas listas de controle de acesso (ACLs) de objetos e nas ACLs de bucket para decidir se permite ou nega a solicitação.

O fluxograma mostra três resultados possíveis:

• Allow (Permitir): a solicitação é permitida pela política aplicável.

• Explicit Deny (Negação explícita): a solicitação é explicitamente rejeitada pela política aplicável.

• Implicit Deny (Negação implícita): não existe nenhuma política aplicável ou nenhuma política produz um resultado Allow ou Explicit Deny.

O OSS avalia uma solicitação não anônima na seguinte ordem:

1. O OSS verifica a identidade da solicitação.

   O OSS compara a assinatura na solicitação com a assinatura calculada pelo servidor do OSS.

   • As assinaturas não correspondem: o OSS nega a solicitação.

   • As assinaturas correspondem: o OSS verifica se a solicitação está sujeita a políticas de sessão baseadas em função.

2. O OSS verifica se as políticas de sessão baseadas em função são aplicáveis.

   Sim: o OSS avalia a solicitação com base nas políticas de sessão.

   • Explicit Deny ou Implicit Deny: o OSS nega a solicitação.

   • Allow: o OSS continua verificando as políticas do RAM e as políticas de bucket.

   Não: o OSS ignora a avaliação da política de sessão e prossegue para as políticas do RAM e as políticas de bucket.

3. O OSS avalia as políticas do RAM e as políticas de bucket.

   As políticas do RAM são políticas de controle de acesso baseadas em identidade que controlam quais identidades podem acessar seus recursos do OSS. O OSS determina o resultado com base em quem enviou a solicitação:

   • Par de AccessKey de uma conta do Alibaba Cloud: o OSS nega implicitamente a solicitação.

   • Par de AccessKey de um usuário do RAM ou credenciais do Security Token Service (STS) usadas para acessar um bucket que não pertence à conta do Alibaba Cloud ou ao proprietário do usuário do RAM: o OSS nega implicitamente a solicitação.

   • Para outros casos, o OSS chama o RAM para autenticar a solicitação. O OSS oferece suporte à autenticação por conta e por grupo de recursos do bucket, e determina se a solicitação é permitida, explicitamente negada ou implicitamente negada com base no resultado.

   As políticas de bucket são políticas de autorização baseadas em recursos. O proprietário do bucket pode usar as políticas de bucket para conceder a usuários do RAM ou a outras contas do Alibaba Cloud permissão para realizar operações no bucket ou em recursos específicos dentro dele.

   • Nenhuma política de bucket configurada: o OSS nega implicitamente a solicitação.

   • Política de bucket existente: o OSS verifica se a solicitação corresponde à política e retorna Allow, Explicit Deny ou Implicit Deny.

4. O OSS verifica o resultado combinado em busca de um Explicit Deny.

   Se alguma política produzir um Explicit Deny, o OSS nega a solicitação. Caso contrário, o OSS verifica se alguma política produz um Allow.

   1. O OSS verifica as políticas do RAM e as políticas de bucket em busca de um resultado Allow.

      Se alguma política produzir um Allow, o OSS permite a solicitação. Caso contrário, o OSS verifica a origem da solicitação.

   2. O OSS verifica a origem da solicitação.

      Solicitações da API de gerenciamento são negadas. Solicitações da API de dados prosseguem para a avaliação de ACL.

      As operações da API de gerenciamento incluem operações de serviço, como GetService (ListBuckets), operações de bucket, como PutBucket e GetBucketLifecycle, e operações de LiveChannel, como PutLiveChannel e DeleteLiveChannel.

      As operações da API de dados incluem operações de objetos, como PutObject e GetObject.

5. O OSS avalia a ACL do objeto e a ACL do bucket.

   Ao verificar a ACL do objeto, o OSS determina se o solicitante é o proprietário do bucket e se a solicitação é uma operação de leitura ou gravação. Para obter mais informações, consulte PutBucketAcl.

   • Allow: o OSS permite a solicitação.

   • Deny: o OSS nega a solicitação.

   Se a ACL do objeto estiver definida para herdar do bucket, o OSS recorre à ACL do bucket.

   Ao verificar a ACL do bucket, o OSS determina se o solicitante é o proprietário do bucket. Para obter mais informações, consulte PutBucketAcl.

   • Allow: o OSS permite a solicitação.

   • Deny: o OSS nega a solicitação.

Para solicitações anônimas, o OSS ignora totalmente a autenticação, as políticas de sessão baseadas em função e as políticas do RAM. A decisão é baseada exclusivamente nas políticas de bucket, nas ACLs de objetos e nas ACLs de bucket.

O OSS avalia uma solicitação anônima na seguinte ordem:

1. O OSS avalia as políticas de bucket.

   • Deny: o OSS nega a solicitação.

   • Allow: o OSS permite a solicitação.

   • Ignore (sem política correspondente): o OSS prossegue para a avaliação de ACL.

2. O OSS avalia a ACL do objeto e a ACL do bucket.

   • A ACL do objeto é privada: o OSS nega a solicitação.

   • A ACL do objeto é public-read ou public-read-write: o OSS permite a solicitação.

   • A ACL do objeto está definida para herdar do bucket: o OSS verifica a ACL do bucket.

     • A ACL do bucket é public-read ou public-read-write: o OSS permite a solicitação.

     • A ACL do bucket é privada: o OSS nega a solicitação.