Descripción general del control de acceso

Tú controlas quién tiene acceso a tus depósitos y objetos de Cloud Storage y qué nivel de acceso tienen.

Elige entre acceso uniforme y detallado

Cuando creas un bucket, debes decidir si quieres aplicar permisos con acceso uniforme o detallado.

  • Uniforme (recomendado): El Acceso uniforme a nivel de bucket te permite usar solo Identity and Access Management (IAM) para administrar los permisos. IAM aplica permisos a todos los objetos que se encuentran dentro del bucket, o a grupos de objetos con prefijos de nombre comunes. IAM también te permite usar funciones que no están disponibles cuando trabajas con las LCA, como las carpetas administradas, las Condiciones de IAM, el uso compartido restringido del dominio y la federación de identidades de personal.

  • Detallado: La opción detallada te permite usar IAM y las Listas de control de acceso (LCA) para administrar los permisos. Las LCA son un sistema de control de acceso heredado de Cloud Storage diseñado para la interoperabilidad con Amazon S3. Las LCA también te permiten especificar el acceso por objeto.

    Debido a que el acceso detallado requiere que coordines entre dos sistemas de control de acceso diferentes, hay una mayor probabilidad de exposición inadvertida de datos y es más complicado auditar quién tiene acceso a los recursos. En particular, si tienes objetos que contienen datos sensibles, como información de identificación personal, te recomendamos almacenar esos datos en un bucket con un acceso uniforme a nivel de bucket habilitado.

Usa los permisos de IAM con LCA

Cloud Storage ofrece dos sistemas para otorgar permiso a los usuarios a fin de acceder a tus buckets y objetos: IAM y las listas de control de acceso (LCA). Estos sistemas actúan en paralelo: para que un usuario pueda acceder a un recurso de Cloud Storage, solo es necesario que uno de los sistemas le otorgue permisos. Por ejemplo, si la política de IAM de tu bucket solo permite que algunos usuarios lean datos del objeto en el bucket, pero uno de los objetos en el bucket tiene una LCA que lo hace legible de forma pública, entonces ese objeto específico se expone al público.

En la mayoría de los casos, IAM es el método recomendado para controlar el acceso a los recursos. IAM controla los permisos en todo Google Cloud y te permite otorgarlos a nivel de bucket y proyecto. Debes usar IAM para cualquier permiso que se aplique a varios objetos en un bucket a fin de reducir los riesgos de exposición no deseada. Si quieres usar IAM de manera exclusiva, habilita el acceso uniforme a nivel de bucket para inhabilitar las LCA en los recursos de Cloud Storage.

Las LCA controlan los permisos solo para los recursos de Cloud Storage y tienen opciones de permisos limitadas, pero te permiten otorgar permisos por objetos individuales. Es muy probable que quieras usar las LCA para los siguientes casos prácticos:

  • Personalizar el acceso a objetos individuales dentro de un bucket.
  • Migrar datos desde Amazon S3.

Opciones de control de acceso adicionales

Además de IAM y las LCA, las siguientes herramientas están disponibles para ayudarte a controlar el acceso a los recursos:

URLs firmadas (autenticación de cadena de consulta)

Usa las URLs firmadas para otorgar acceso de lectura o escritura a un objeto por tiempo limitado a través de una URL que generes. Cualquier persona con quien compartas la URLs puede acceder al objeto durante el tiempo que especifiques, sin importar si tiene una cuenta de usuario o no.

Puedes usar las URL firmadas además de IAM y las LCA. Por ejemplo, puedes usar IAM para otorgar acceso a un bucket a unas pocas personas y, a continuación, crear una URL firmada que permita a otras personas acceder a un recurso específico dentro del bucket.

Aprende a crear URL firmadas:

Documentos de políticas firmados

Usa documentos de políticas firmados para especificar qué se puede subir a un bucket. Los documentos de política permiten un mayor control sobre el tamaño, el tipo de contenido y otras características de carga en comparación con las URL firmadas. Los propietarios del sitio web pueden usarlos para permitir que los visitantes suban archivos a Cloud Storage.

Puedes usar los documentos de política firmados además de IAM y las LCA. Por ejemplo, puedes usar IAM para permitir que los miembros de tu organización suban cualquier objeto. Luego, puedes crear un documento de política firmado que permita a los visitantes del sitio web subir solo objetos que cumplan criterios específicos.

Reglas de seguridad de Firebase

Usa las Reglas de seguridad de Firebase a fin de proporcionar un control de acceso detallado y basado en atributos a las aplicaciones web y para dispositivos móviles mediante el SDK de Firebase para Cloud Storage. Por ejemplo, puedes especificar quién sube o descarga objetos, qué tan grande puede ser un objeto o cuándo puede descargarse.

Prevención del acceso público

Usa la prevención del acceso público para restringir el acceso público a tus buckets y objetos. Cuando habilitas la prevención del acceso público, los usuarios que obtienen acceso a través de allUsers y allAuthenticatedUsers no pueden acceder a los datos.

Límites de acceso a las credenciales

Usa Límites de acceso a las credenciales a fin de restringir los permisos que están disponibles para un token de acceso de OAuth 2.0. Primero, define un límite de acceso a las credenciales que especifique a qué bucket s puede acceder el token, así como un límite superior en los permisos que están disponibles en ese bucket. Luego, puedes crear un token de acceso de OAuth 2.0 y cambiarlo por uno nuevo que respete el límite de acceso a las credenciales.

Filtrado de IP del bucket

Usa el filtrado de IP del bucket para restringir el acceso a tu bucket según la dirección IP de origen de la solicitud. El filtrado de IP del bucket agrega una capa de seguridad, ya que evita que las redes no autorizadas accedan a tu bucket y a sus datos. Puedes configurar una lista de rangos de direcciones IP permitidos, incluidas las direcciones IP públicas, los rangos de direcciones IP públicas y las direcciones IP dentro de tu nube privada virtual. Se bloquearán todas las solicitudes que se originen en una dirección IP que no esté en tu lista. Como resultado, solo los usuarios autorizados pueden acceder a tu bucket.

Prácticas recomendadas para IAM y LCA

Las políticas de IAM y LCA requieren que la administración activa sea eficaz. Antes de otorgar acceso a un bucket, objeto o carpeta administrada a otros usuarios, asegúrate de saber con quién deseas compartir el recurso y qué roles quieres que tengan cada una de esas personas. Con el tiempo, es posible que los cambios en la administración del proyecto, los patrones de uso y la propiedad de la organización requieran que modifiques la configuración de IAM o LCA en buckets y proyectos, en especial si administras Cloud Storage en una organización grande o para un grupo grande de usuarios. A medida que evalúes y planifiques tu configuración de control de acceso, ten en cuenta las siguientes prácticas recomendadas:

  • Usa el principio de privilegio mínimo cuando otorgues acceso a tus buckets, objetos o carpetas administradas.

    El principio de privilegio mínimo es un lineamiento de seguridad para otorgar acceso a tus recursos. Cuando otorgas acceso según este principio, otorgas los privilegios mínimos necesarios para que un usuario realice su tarea asignada. Por ejemplo, si deseas compartir archivos con alguien, debes otorgarle el rol de IAM de visualizador de objetos de almacenamiento o el permiso de LCA READER, y no el rol de IAM de administrador de almacenamiento o el permiso de LCA OWNER.

  • Evita otorgar roles de IAM con el permiso setIamPolicy u otorgar el permiso de LCA OWNER a personas que no conoces.

    Otorgar el permiso de IAM setIamPolicy o el permiso de LCA OWNER permite que un usuario cambie los permisos y controle los datos. Debes usar roles con estos permisos solo cuando quieras delegar el control administrativo sobre objetos, buckets y carpetas administradas.

  • Ten cuidado con la forma en la que otorgas permisos para usuarios anónimos.

    Los tipos de principal allUsers y allAuthenticatedUsers solo se deben usar cuando sea aceptable que cualquier persona en Internet lea y analice tus datos. Si bien estos alcances son útiles para algunas aplicaciones y situaciones, en general, no es una buena idea otorgar a todos los usuarios ciertos permisos, como los permisos de IAM setIamPolicy, update, create o delete, o el permiso de LCA OWNER.

  • Asegúrate de delegar el control administrativo de tus depósitos.

    Debes asegurarte de que otros miembros del equipo aún puedan administrar tus recursos en caso de que un individuo con acceso de administrador abandone el grupo.

    Para evitar que los recursos se vuelvan inaccesibles, puedes realizar alguna de las siguientes acciones:

    • Otorga el rol de IAM de administrador de almacenamiento en tu proyecto a un grupo en lugar de a una persona.

    • Otorga el rol de IAM de administrador de almacenamiento en tu proyecto a al menos dos personas.

    • Otorga el permiso de LCA OWNER para tu bucket a al menos dos personas.

  • Presta atención al comportamiento interoperable de Cloud Storage.

    Cuando usas la API de XML para acceso interoperable con otros servicios de almacenamiento, como Amazon S3, el identificador de la firma determina la sintaxis de LCA. Por ejemplo, si la herramienta o biblioteca que usas realiza una solicitud a Cloud Storage para recuperar las LCA y la solicitud usa el identificador de firma de otro proveedor de almacenamiento, entonces Cloud Storage muestra un documento XML con la sintaxis de LCA del proveedor de almacenamiento correspondiente. Si la herramienta o biblioteca que usas realiza una solicitud a Cloud Storage para que aplique las LCA y la solicitud usa el identificador de firma de otro proveedor de almacenamiento, entonces Cloud Storage espera recibir un documento XML con la sintaxis de LCA del proveedor de almacenamiento correspondiente.

    Si deseas obtener más información sobre el uso de la API de XML para interoperabilidad con Amazon S3, consulta Migración simple desde Amazon S3 a Cloud Storage.

¿Qué sigue?