Almacenamiento y acceso público en Google Cloud

En Cloud Storage el acceso público se concede a dos principales especiales: allUsers, que es cualquiera en internet sin identificarse, y allAuthenticatedUsers, que es cualquier persona con una cuenta de Google, de cualquier organización. El segundo engaña: parece restringido porque pide iniciar sesión, pero no lo está.

La prevención de acceso público (public access prevention) es un ajuste del bucket que impide que esos dos principales accedan. Tiene dos estados: enforced, puesto en el propio bucket, e inherited, que deja la decisión a la restricción de la organización storage.publicAccessPrevention aplicada en el proyecto, la carpeta o la organización. Aplica a las políticas de IAM y a las listas de control de acceso, y lo que bloquea lo bloquea aunque la política ya tenga la concesión: la concesión sigue escrita, pero queda anulada. Por eso un bucket puede mostrar allUsers en su política y no estar expuesto, y otro puede estar expuesto con una política que a simple vista parece normal.

La pregunta de revisión no es solo si hay un principal público en la política, sino si la prevención efectiva lo deja pasar.

Un bucket de Cloud Storage puede dar acceso por dos caminos: IAM, que es el normal en el resto de Google Cloud, y las listas de control de acceso (ACL), heredadas de los primeros tiempos del servicio y que se pueden poner objeto por objeto. Con dos puertas, es más difícil saber quién entra.

El acceso uniforme a nivel de bucket (uniform bucket-level access) desactiva las ACL: a partir de ahí solo los permisos de IAM del bucket conceden acceso, y las llamadas para leer o cambiar ACL fallan con un error. Para una revisión es una buena señal: un bucket sin acceso uniforme obliga a mirar las ACL de sus objetos además de su política. Existe también una restricción de la organización para exigirlo en los buckets nuevos.

En AWS el control equivalente a mirar es el bloqueo de acceso público de S3, con cuatro ajustes que se aplican por bucket, por cuenta o desde la organización; en Azure es el nivel de acceso público del contenedor. Los tres atacan lo mismo con nombres distintos.

Abre el laboratorio. En el escritorio hay cuatro documentos: la política de datos de la empresa, el inventario de buckets, el árbol de recursos y el estado de la restricción en cada nodo. Para saber si un bucket está expuesto no basta con la columna de principales públicos: hay que ver en qué proyecto vive, en qué carpeta cuelga ese proyecto y qué dice la restricción en esa rama.

Busca entre los buckets de clasificación Restringido el que hoy puede leer cualquier persona con una cuenta de Google.

Un bucket público no es siempre un hallazgo: el catálogo de la web debe serlo. El hallazgo es el acceso que la clasificación del dato no permite. Con las mismas tres fuentes, cuenta los buckets que están hoy realmente abiertos y a los que su clasificación no les permite estarlo. No cuentes los que tienen una concesión pública pero una prevención efectiva que la anula, ni el que es público por diseño.

Cerrar los dos buckets de hoy es lo urgente; lo importante es que el próximo no nazca abierto. En Google Cloud la forma de hacerlo es la restricción de la organización, que al aplicarse en un nodo de la jerarquía llega a todo lo que cuelga de él. Si un proyecto necesita de verdad un bucket público, como el del portal, se documenta una excepción en ese proyecto en lugar de dejar la puerta abierta en toda la organización. En AWS la idea equivalente es activar el bloqueo de acceso público a nivel de la organización o de la cuenta; en Azure, restringir por política el nivel de acceso de los contenedores.