¿Cómo soluciono los errores 403 Access Denied (Acceso denegado) de Amazon S3?

Última actualización: 19-11-2021

Mis usuarios intentan acceder a los objetos de mi bucket de Amazon Simple Storage Service (Amazon S3), pero Amazon S3 devuelve el error 403 Access Denied (Acceso denegado). ¿Cómo puedo solucionar este error?

Descripción corta

Para solucionar los errores Access Denied (Acceso denegado) de Amazon S3, verifique lo siguiente:

  • Propiedad del bucket y del objeto
  • Política del bucket o políticas de usuario de AWS Identity and Access Management (IAM)
  • Límites de permisos de IAM
  • Configuración de Amazon S3 Block Public Access
  • Credenciales para acceder a Amazon S3
  • Credenciales de seguridad temporales
  • Política de punto de enlace de Amazon Virtual Private Cloud (Amazon VPC)
  • Política de punto de acceso de Amazon S3
  • Objeto que falta o con un carácter especial
  • Cifrado de AWS Key Management Service (AWS KMS)
  • Pago por solicitante habilitado en el bucket
  • Política de control de servicios de AWS Organizations

Nota: También puede utilizar el documento de automatización AWSSupport-TroubleshootS3PublicRead en AWS Systems Manager. Este documento de automatización lo ayuda a diagnosticar problemas de lectura de objetos del bucket público de S3 que especifique.

Resolución

Propiedad del bucket y del objeto

Para los errores AccessDenied de las solicitudes GetObject o HeadObject, compruebe si el objeto también es propiedad del propietario del bucket. Además, verifique si el propietario del bucket tiene permisos de lectura o de lista de control de acceso (ACL) de control total.

De forma predeterminada, un objeto de S3 es propiedad de la cuenta de AWS que lo cargó. Esto es verdadero incluso cuando el bucket es propiedad de otra cuenta. Si otras cuentas pueden cargar objetos a su bucket, verifique a qué cuenta pertenecen los objetos a los que sus usuarios no pueden acceder:

1.    Ejecute el comando list-buckets de AWS Command Line Interface (AWS CLI) para obtener el ID canónico de Amazon S3 de su cuenta:

aws s3api list-buckets --query Owner.ID

Nota: Si recibe errores al ejecutar comandos de AWS CLI, asegúrese de que utiliza la versión más reciente de AWS CLI.

2.    Ejecute el comando list-objects para obtener el ID canónico de Amazon S3 de la cuenta propietaria del objeto al que los usuarios no pueden acceder:

aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix exampleprefix

Consejo: Puede utilizar el comando list-objects para verificar varios objetos.

3.    Si los ID canónicos no coinciden, el propietario del bucket no es el propietario del objeto. El propietario del objeto puede otorgarte el control total del objeto al ejecutar el comando put-object-acl:

aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg --acl bucket-owner-full-control

4.    Después de que el propietario del objeto cambie la ACL del objeto a bucket-owner-full-control, el propietario del bucket puede acceder al objeto. Sin embargo, el cambio de la ACL por sí solo no cambia la propiedad del objeto. Para cambiar el propietario del objeto por la cuenta del bucket, ejecute el comando cp desde la cuenta del bucket para copiar el objeto sobre sí mismo.

Para copiar todos los objetos nuevos en un bucket de otra cuenta, establezca una política de bucket que requiera que los objetos se carguen con la ACL bucket-owner-full-control. A continuación, habilite y establezca la propiedad de objetos de S3 como propietario del bucket preferido en la consola de administración de AWS. El propietario del objeto se cambia automáticamente al propietario del bucket cuando el objeto se carga con la ACL bucket-owner-full-control.

Para obtener permisos continuos entre cuentas, cree un rol de IAM en su cuenta con permisos para su bucket. A continuación, conceda a otra cuenta de AWS el permiso para asumir ese rol de IAM. Para obtener más información, consulte Tutorial: Delegación del acceso entre cuentas de AWS mediante roles de IAM.

Política de bucket o políticas de usuario de IAM

Revise la política de bucket o las políticas de usuario de IAM asociadas para ver si hay declaraciones que puedan denegar el acceso de forma incorrecta. Verifique si hay declaraciones de denegación incorrectas, acciones que faltan o espaciado incorrecto en una política:

1.    Compruebe las declaraciones de denegación para ver qué condiciones bloquean el acceso según lo siguiente:
autenticación multifactor (MFA)
claves de cifrado
dirección IP específica
puntos de enlace de la VPC o VPC específicos
usuarios o roles específicos de IAM

Verifique que las solicitudes a su bucket cumplan las condiciones de la política de bucket o de las políticas de IAM. De lo contrario, se le denegará el acceso.

Nota: Si necesita MFA y los usuarios envían solicitudes a través de la AWS CLI, asegúrese de que los usuarios configuren la AWS CLI para utilizar MFA.

Por ejemplo, en la siguiente política de bucket, Statement1 permite el acceso público para descargar objetos (s3:GetObject) desde DOC-EXAMPLE-BUCKET. Sin embargo, Statement2 deniega explícitamente a todos el acceso a la descarga de objetos de DOC-EXAMPLE-BUCKET a no ser que la solicitud provenga del punto de enlace de la VPC vpce-1a2b3c4d. En este caso, la declaración de denegación tiene prioridad. Esto significa que se niega el acceso a los usuarios que intentan descargar objetos desde fuera de vpce-1a2b3c4d.

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Principal": "*"
    },
    {
      "Sid": "Statement2",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-1a2b3c4d"
        }
      },
      "Principal": "*"
    }
  ]
}

2.    Verifique que la política de bucket o las políticas de IAM permitan las acciones de Amazon S3 que sus usuarios necesitan. Por ejemplo, la siguiente política de bucket no incluye el permiso para la acción s3:PutObjectAcl. Si el usuario de IAM intenta modificar la lista de control de acceso (ACL) de un objeto, el usuario obtiene un error Access Denied (Acceso denegado).

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1234567890123",
      "Action": [
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:user/Dave"
        ]
      }
    }
  ]
}

3.    Verifique que no haya espacios adicionales ni ARN incorrectos en la política de bucket o en las políticas de usuarios de IAM. Por ejemplo, la siguiente política de IAM tiene un espacio extra en el nombre de recurso de Amazon (ARN) arn:aws:s3::: DOC-EXAMPLE-BUCKET/*. Debido al espacio, el ARN se evalúa incorrectamente como arn:aws:s3:::%20DOC-EXAMPLE-BUCKET/*. Esto significa que el usuario de IAM no tiene permisos para los objetos correctos.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1234567890123",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3::: DOC-EXAMPLE-BUCKET/*"
    }
  ]
}

Límites de permisos de IAM

Revise los límites de permisos de IAM establecidos en las identidades de IAM que intentan acceder al bucket. Confirme que los límites de los permisos de IAM permitan el acceso a Amazon S3.

Configuración de Amazon S3 Block Public Access

Si recibe errores Access Denied (Acceso denegado) en solicitudes de lectura pública que tienen permiso de acceso, verifique la configuración de Amazon S3 Block Public Access del bucket. Revise la configuración de S3 Block Public Access tanto de la cuenta como del bucket. Esta configuración puede anular los permisos de acceso público de lectura. Amazon S3 Block Public Access puede aplicarse a buckets individuales o a cuentas de AWS.

Credenciales para acceder a Amazon S3

Revise las credenciales que sus usuarios han configurado para acceder a Amazon S3. Los SDK de AWS y la AWS CLI deben configurarse para utilizar las credenciales del usuario o el rol de IAM con acceso a su bucket.

Para la AWS CLI, ejecute el comando configure para verificar las credenciales configuradas:

aws configure list

Si los usuarios acceden a su bucket a través de una instancia de Amazon Elastic Compute Cloud (Amazon EC2), verifique que la instancia esté utilizando el rol correcto. Conéctese a la instancia y, a continuación, ejecute el comando get-caller-identity:

aws sts get-caller-identity

Credenciales de seguridad temporales

Si los usuarios reciben errores Access Denied (Acceso denegado) de las credenciales de seguridad temporales concedidas mediante AWS Security Token Service (AWS STS), revise la política de sesiones asociada.

Cuando un administrador crea credenciales de seguridad temporales mediante la llamada a la API AssumeRole o el comando assume-role, puede pasar políticas específicas de sesión de forma opcional. Los permisos de una sesión son la intersección de las políticas de sesión y las políticas basadas en identidades de la entidad de IAM (usuario o rol) que se utiliza para crear la sesión. Para obtener más información sobre las políticas de sesión, consulte los tipos de políticas.

Para buscar las políticas de sesión asociadas a los errores Access Denied (Acceso denegado) de Amazon S3, busque los eventos de AssumeRole en el historial de eventos de AWS CloudTrail. Asegúrese de buscar los eventos de AssumeRole en el mismo periodo de tiempo que las solicitudes fallidas de acceso a Amazon S3. A continuación, revise el campo requestParameters de los registros de CloudTrail pertinentes para cualquier parámetro policy o policyArns. Confirme que el ARN de política o la política asociada concede los permisos necesarios de Amazon S3.

Por ejemplo, el siguiente fragmento de un registro de CloudTrail muestra que las credenciales temporales incluyen una política de sesión en línea que otorga permisos s3:GetObject a DOC-EXAMPLE-BUCKET:

"requestParameters": {
        "roleArn": "arn:aws:iam::123412341234:role/S3AdminAccess",
        "roleSessionName": "s3rolesession",
        "policy": "{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n  {\n  \"Effect\": \"Allow\",\n           
         \"Action\": [\n   \"s3:GetObject\"\n ],\n    \"Resource\": [\n \"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*\"\n  ]\n   }  }\n    ]\n}\n"
    }

Política de punto de enlace de Amazon VPC

Si los usuarios acceden a su bucket con una instancia EC2 enrutada a través de un punto de enlace de la VPC, consulte la política de punto de enlace de la VPC. Asegúrese de que la política de punto de enlace de la VPC incluya los permisos correctos para acceder a los objetos y los buckets de S3.

Por ejemplo, la siguiente política de punto de enlace de la VPC permite el acceso solo a DOC-EXAMPLE-BUCKET. Los usuarios que envían solicitudes a través de este punto de enlace de la VPC no pueden acceder a ningún otro bucket.

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1234567890123",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Principal": "*"
    }
  ]
}

Política de punto de acceso de Amazon S3

Si utiliza un punto de acceso de Amazon S3 para administrar el acceso al bucket, revise la política de IAM del punto de acceso. Los permisos otorgados en una política de punto de acceso solo son efectivos si la política del bucket subyacente también permite el mismo acceso. Confirme que la política del bucket y la política del punto de acceso otorgan los permisos correctos.

Objeto que falta o con un carácter especial

Verifique si el objeto solicitado existe en el bucket. Tenga en cuenta también que un objeto que tiene un carácter especial (como un espacio) requiere un manejo especial para recuperar el objeto. De lo contrario, la solicitud no encuentra el objeto y Amazon S3 asume que el objeto no existe. Como resultado, recibe un error Access Denied (Acceso denegado) (en lugar de errores 404 Not Found [No encontrado]) si no tiene los permisos adecuados de s3:ListBucket.

Ejecute el comando head-object de la AWS CLI para verificar si existe un objeto en el bucket:

aws s3api head-object --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg

Si el objeto existe en el bucket, el error Access Denied (Acceso denegado) no está enmascarando ningún error 404 Not Found (No encontrado). Compruebe otros requisitos de configuración para resolver el error Access Denied (Acceso denegado).

Si el objeto no existe en el bucket, el error Access Denied (Acceso denegado) está enmascarando un error 404 Not Found (No encontrado). Resuelva el problema relacionado con el objeto que falta.

Cifrado de AWS KMS

Tenga en cuenta lo siguiente sobre el cifrado de AWS KMS (SSE-KMS):

  • Si un usuario de IAM no puede acceder a un objeto para el que el usuario tiene permisos completos, verifique si el objeto está cifrado por SSE-KMS. Puede utilizar la consola de Amazon S3 para ver las propiedades del objeto, que incluyen la información de cifrado del objeto en el servidor.
  • Si el objeto está cifrado por SSE-KMS, asegúrese de que la política de claves de KMS concede al usuario de IAM los permisos mínimos necesarios para utilizar la clave. Por ejemplo, si el usuario de IAM utiliza la clave solo para descargar un objeto de S3, el usuario de IAM debe tener permisos kms:Decrypt. Para obtener más información, consulte Permite el acceso a la cuenta de AWS y habilita las políticas de IAM.
  • Si la identidad y la clave de IAM están en la misma cuenta, los permisos de kms:Decrypt deben concederse mediante la política de claves. La política de claves debe hacer referencia a la misma identidad de IAM que la política de IAM.
  • Si el usuario de IAM pertenece a una cuenta diferente a la cuenta de la clave de AWS KMS, estos permisos también deben concederse en la política de IAM. Por ejemplo, para descargar los objetos cifrados SSE-KMS, se deben especificar los permisos kms:Decrypt tanto en la política de claves como en la política de IAM. Para obtener más información sobre el acceso entre cuentas entre el usuario de IAM y la clave de KMS, consulte Permitir a los usuarios de otras cuentas utilizar una clave KMS.

Pago por solicitante habilitado en el bucket

Si su bucket tiene habilitado el pago por solicitante, los usuarios de otras cuentas deben especificar el parámetro request-payer cuando envíen solicitudes a su bucket. De lo contrario, esos usuarios reciben un error Access Denied (Acceso denegado). Para verificar si el pago por solicitante está habilitado, puede utilizar la consola de Amazon S3 para ver las propiedades de su bucket.

El siguiente ejemplo de comando de la AWS CLI incluye el parámetro correcto para acceder a un bucket compartido entre cuentas con pago por solicitante:

aws s3 cp exampleobject.jpg s3://DOC-EXAMPLE-BUCKET/exampleobject.jpg --request-payer requester

Política de control de servicios de AWS Organizations

Si está utilizando AWS Organizations, verifique las políticas de control de servicios para asegurarse de que el acceso a Amazon S3 esté permitido. Las políticas de control de servicios especifican los permisos máximos de las cuentas afectadas. Por ejemplo, la siguiente política deniega explícitamente el acceso a Amazon S3 y da lugar a un error Access Denied (Acceso denegado).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "*"
        }
    ]
}

Para obtener más información sobre las características de AWS Organizations, consulte Habilitar todas las características en la organización.


¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?