Object Storage Service:Authorization process

Cuando OSS recibe una solicitud no anónima, la evalúa con base en el resultado de autenticación, las políticas de sesión basadas en roles, las políticas basadas en identidad (políticas de RAM), las políticas de bucket, las listas de control de acceso (ACL) de objetos y las ACL de bucket para determinar si se permite o se deniega la solicitud.

El diagrama de flujo muestra tres resultados posibles:

• Allow: la política aplicable permite la solicitud.

• Explicit Deny: la política aplicable rechaza explícitamente la solicitud.

• Implicit Deny: no existe ninguna política aplicable o ninguna genera un resultado de Allow o Explicit Deny.

OSS evalúa una solicitud no anónima en el siguiente orden:

1. OSS verifica la identidad de la solicitud.

   OSS compara la firma incluida en la solicitud con la firma calculada por el servidor de OSS.

   • Las firmas no coinciden: OSS deniega la solicitud.

   • Las firmas coinciden: OSS comprueba si la solicitud está sujeta a políticas de sesión basadas en roles.

2. OSS comprueba si aplican políticas de sesión basadas en roles.

   Sí: OSS evalúa la solicitud con base en las políticas de sesión.

   • Explicit Deny o Implicit Deny: OSS deniega la solicitud.

   • Allow: OSS continúa con la verificación de las políticas de RAM y las políticas de bucket.

   No: OSS omite la evaluación de políticas de sesión y procede con las políticas de RAM y las políticas de bucket.

3. OSS evalúa las políticas de RAM y las políticas de bucket.

   Las políticas de RAM son políticas de control de acceso basadas en identidad que determinan qué identidades pueden acceder a sus recursos de OSS. OSS define el resultado según quién envió la solicitud:

   • Par de AccessKey de una cuenta de Alibaba Cloud: OSS deniega implícitamente la solicitud.

   • Par de AccessKey de un usuario de RAM o credenciales de Security Token Service (STS) utilizadas para acceder a un bucket que no pertenece a la cuenta de Alibaba Cloud ni al propietario del usuario de RAM: OSS deniega implícitamente la solicitud.

   • En otros casos, OSS invoca a RAM para autenticar la solicitud. OSS admite la autenticación por cuenta y por resource group del bucket, y determina si permite, deniega explícitamente o deniega implícitamente la solicitud según el resultado obtenido.

   Las políticas de bucket son políticas de autorización basadas en recursos. El propietario del bucket puede usar estas políticas para otorgar permiso a usuarios de RAM u otras cuentas de Alibaba Cloud para realizar operaciones en el bucket o en recursos específicos dentro de este.

   • No hay política de bucket configurada: OSS deniega implícitamente la solicitud.

   • Existe una política de bucket: OSS comprueba si la solicitud coincide con la política y devuelve Allow, Explicit Deny o Implicit Deny.

4. OSS revisa el resultado combinado en busca de un Explicit Deny.

   Si alguna política genera un Explicit Deny, OSS deniega la solicitud. De lo contrario, OSS comprueba si alguna política genera un Allow.

   1. OSS busca un resultado de Allow en las políticas de RAM y en las políticas de bucket.

      Si alguna política genera un Allow, OSS permite la solicitud. En caso contrario, OSS verifica el origen de la solicitud.

   2. OSS verifica el origen de la solicitud.

      Las solicitudes de API de administración se deniegan. Las solicitudes de API de datos continúan hacia la evaluación de ACL.

      Las operaciones de API de administración incluyen operaciones de servicio como GetService (ListBuckets), operaciones de bucket como PutBucket y GetBucketLifecycle, y operaciones de LiveChannel como PutLiveChannel y DeleteLiveChannel.

      Las operaciones de API de datos incluyen operaciones de objetos como PutObject y GetObject.

5. OSS evalúa la ACL del objeto y la ACL del bucket.

   Al revisar la ACL del objeto, OSS determina si el solicitante es el propietario del bucket y si la solicitud corresponde a una operación de lectura o escritura. Para más información, consulte PutBucketAcl.

   • Allow: OSS permite la solicitud.

   • Deny: OSS deniega la solicitud.

   Si la ACL del objeto está configurada para heredar la configuración del bucket, OSS recurre a la ACL del bucket.

   Al revisar la ACL del bucket, OSS determina si el solicitante es el propietario del bucket. Para más información, consulte PutBucketAcl.

   • Allow: OSS permite la solicitud.

   • Deny: OSS deniega la solicitud.

Para las solicitudes anónimas, OSS omite por completo la autenticación, las políticas de sesión basadas en roles y las políticas de RAM. La decisión se basa exclusivamente en las políticas de bucket, las ACL de objetos y las ACL de bucket.

OSS evalúa una solicitud anónima en el siguiente orden:

1. OSS evalúa las políticas de bucket.

   • Deny: OSS deniega la solicitud.

   • Allow: OSS permite la solicitud.

   • Ignore (ninguna política coincide): OSS procede con la evaluación de ACL.

2. OSS evalúa la ACL del objeto y la ACL del bucket.

   • La ACL del objeto es privada: OSS deniega la solicitud.

   • La ACL del objeto es public-read o public-read-write: OSS permite la solicitud.

   • La ACL del objeto está configurada para heredar la configuración del bucket: OSS revisa la ACL del bucket.

     • La ACL del bucket es public-read o public-read-write: OSS permite la solicitud.

     • La ACL del bucket es privada: OSS deniega la solicitud.