Última actualización: 22 de mayo de 2026
En este documento, se identifican posibles vectores de ataque y estrategias de mitigación para la confidencialidad, la integridad y la disponibilidad de los datos en Cloud Storage. El alcance de este informe se limita a tu perspectiva y se enfoca en los riesgos que puedes administrar en tu entorno de Cloud Storage.
Estos modelos de amenazas son una evaluación probabilística basada en los vectores de ataque conocidos actualmente, las suposiciones arquitectónicas y el alcance especificado del sistema en el momento de la publicación. Estos modelos no son exhaustivos y tienen como objetivo servir de referencia para las evaluaciones de seguridad y riesgo de los clientes de Google Cloud, así como orientar las decisiones de reducción de riesgos.
Se identificaron las siguientes amenazas para este servicio:
Detalles de amenazas
En las siguientes secciones, se proporciona información sobre cada amenaza, sus manifestaciones y las mitigaciones recomendadas.
Divulgación de información con una configuración de acceso no segura
Los datos sensibles almacenados en objetos de Cloud Storage pueden quedar expuestos a terceros no autorizados cuando los controles de acceso están mal configurados. La configuración incorrecta de los controles de acceso es uno de los problemas de seguridad en la nube más comunes y con mayor impacto.
| Categoría de STRIDE |
Divulgación de información |
| Táctica de MITRE ATT&CK |
Colección |
| Manifestaciones |
Exposición de buckets públicos: Un bucket de Cloud Storage se hace público cuando se otorgan roles como Storage Object Viewer a las cuentas allUsers o allAuthenticatedUsers en su política de permisos de IAM. Si no se aplica la prevención del acceso público, estos roles exponen todos los objetos a Internet. Fuga de URLs firmadas: Una URL firmada, que actúa como un token de portador temporal, se filtra de forma inadvertida a través de código del cliente, registros o transmisión no segura. Cualquier usuario o aplicación externos que obtengan la URL pueden acceder al objeto de Cloud Storage especificado con los permisos (por ejemplo, de lectura o escritura) hasta que venza la firma de la URL. Permisos de IAM demasiado amplios: Se otorgan permisos amplios (por ejemplo, storage.objects.get o storage.objects.list) a identidades, como una cuenta de usuario o una cuenta de servicio, en muchos buckets cuando las identidades solo requieren acceso a un pequeño subconjunto de datos. Credenciales de identidad comprometidas: Un atacante obtiene las credenciales de una cuenta de usuario o una clave de cuenta de servicio, lo que le permite autenticarse en la API de JSON de Cloud Storage y acceder a todos los datos que la identidad comprometida está autorizada a ver. Configuración incorrecta del balanceador de cargas: Una instancia de Cloud Load Balancing configurada con un bucket de Cloud Storage como backend se puede configurar de forma incorrecta para exponer objetos de forma pública, incluso si el bucket en sí no es público. Esta configuración incorrecta crea una ruta de acceso alternativa, y potencialmente menos segura, a los datos, lo que omite los controles directos de IAM de Cloud Storage. Almacenamiento en caché incorrecto de la CDN: Cuando se usa un bucket de Cloud Storage como backend para Cloud Load Balancing y Cloud CDN, una configuración incorrecta puede hacer que los datos sensibles se almacenen en caché en las ubicaciones perimetrales públicas de Google. Si el servicio de backend no emite los encabezados Cache-Control correctos (por ejemplo, private o no-store), es posible que la CDN entregue el contenido almacenado en caché a usuarios no autorizados, lo que omitirá las verificaciones de IAM del bucket.
|
| Mitigaciones |
Aplica la prevención de acceso público en buckets de almacenamiento individuales o a nivel de proyecto, carpeta u organización con la restricción de política de la organización storage.publicAccessPrevention. Usa el acceso uniforme a nivel de bucket para simplificar los permisos y evitar las LCA heredadas. Configura claves de encriptación administradas por el cliente (CMEK) para proteger los datos con encriptación en reposo. Mantén los tiempos de vencimiento de las URLs firmadas lo más cortos posible. Audita y quita periódicamente las claves de cuentas de servicio vulneradas o sin usar. Implementa los Controles del servicio de VPC para crear un perímetro de servicio y evitar el robo de datos, incluso si se roban las credenciales. Asegúrate de que las políticas de Cloud Armor se apliquen a los balanceadores de cargas que entregan contenido de Cloud Storage para restringir el acceso.
|
Elevación de privilegios con errores de configuración de IAM
Un atacante con permisos de IAM específicos y aparentemente inocuos puede aumentar sus privilegios para obtener un acceso más amplio, incluido el control administrativo sobre los buckets de Cloud Storage y los datos que contienen. Esta amenaza elude la postura de seguridad prevista y vulnera el principio de privilegio mínimo.
| Categoría de STRIDE |
Elevación de privilegios |
| Táctica de MITRE ATT&CK |
Elevación de privilegios |
| Manifestaciones |
Modificación directa de la política: Una identidad, como un usuario o una cuenta de servicio, a la que se le otorga el permiso storage.buckets.setIamPolicy en un bucket de Cloud Storage puede modificar directamente su política de permisos. Esta configuración permite que el atacante se otorgue roles con privilegios elevados, como Storage Admin, lo que lleva a un control completo sobre la configuración y los datos del bucket. Identidad temporal como cuenta de servicio: Una identidad con un rol como roles/iam.serviceAccountUser que contiene el permiso iam.serviceAccounts.actAs en una cuenta de servicio puede adjuntar la cuenta de servicio a otros recursos, como una instancia de Compute Engine, para ejecutar código con la identidad de la cuenta de servicio adjunta. Como alternativa, una identidad con un rol como roles/iam.serviceAccountTokenCreator que tenga permisos, incluido iam.serviceAccounts.getAccessToken, puede generar tokens de acceso para esa cuenta de servicio. Si la cuenta de servicio objetivo tiene permisos elevados en los recursos de Cloud Storage, el atacante hereda esos privilegios de manera efectiva. Generación de URLs firmadas: Una identidad con el permiso iam.serviceAccounts.signBlob en una cuenta de servicio puede generar URLs firmadas de la versión 4. Estas URLs permiten que el atacante cree acceso temporal con token de portador a objetos que la cuenta de servicio puede leer o escribir, lo que podría eludir controles de red más restrictivos o la propia falta de permisos directos de Cloud Storage del atacante.
|
| Mitigaciones |
Sigue el principio de privilegio mínimo. Evita agregar permisos como storage.buckets.setIamPolicy, iam.serviceAccounts.actAs o iam.serviceAccounts.signBlob a los roles, a menos que sea absolutamente necesario. Usa las condiciones de IAM para restringir los permisos a recursos o períodos específicos. Audita periódicamente las políticas de permisos con herramientas como Cloud Asset Inventory para detectar y quitar los permisos excesivos. Asegúrate de que las aplicaciones que controlan URLs firmadas no las registren ni las expongan de una manera en que terceros puedan extraerlas. Por ejemplo, si usas Cloud CDN para almacenar en caché URLs firmadas, configura los encabezados Cache-Control adecuados para evitar el almacenamiento en caché público de objetos sensibles que deben ser privados y autenticados a través de una URL firmada.
|
Alteración o destrucción de datos con permisos excesivos
Un atacante con permisos suficientes puede alterar, dañar o borrar de forma permanente los datos y la configuración dentro del sistema de Cloud Storage, lo que provoca una pérdida de integridad de los datos y disponibilidad.
| Categoría de STRIDE |
Manipulación |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
Manipulación directa de objetos: Una identidad con permisos de storage.objects.create o storage.objects.delete puede reemplazar o destruir objetos individuales de Cloud Storage. Ataque a la política de ciclo de vida: Un atacante con permiso de storage.buckets.update puede modificar la configuración de administración del ciclo de vida de los objetos de un bucket para crear una regla que borre todos los objetos de inmediato o después de un período breve, lo que provocaría la destrucción masiva de datos. Borrado de buckets: Un atacante con privilegios elevados y el permiso storage.buckets.delete puede borrar un bucket completo de Cloud Storage, lo que destruye de inmediato todos los objetos, las configuraciones y las políticas asociadas con él. Secuestro de notificaciones: Un atacante con permiso de storage.buckets.update puede alterar o borrar de forma maliciosa una configuración de notificaciones de Pub/Sub. Este ataque puede cegar los sistemas posteriores que dependen de estos eventos o redireccionar las notificaciones a un tema controlado por el atacante.
|
| Mitigaciones |
Si necesitas almacenamiento inmutable o un período de retención mínimo, configura el bloqueo del bucket para todo el bucket o el bloqueo de objetos para objetos individuales. Configura el control de versiones de objetos y una política de eliminación no definitiva para planificar la recuperación ante reescrituras accidentales o maliciosas en los buckets que contienen datos críticos. Implementa un período de borrado de forma no definitiva especificado que te brinde tiempo suficiente para detectar y recuperar los objetos antes de la eliminación permanente. Habilita los registros de auditoría de acceso a los datos en los buckets que contienen datos críticos para supervisar los patrones de acceso irregulares.
|
Robo de datos con trabajos del Servicio de transferencia de almacenamiento mal configurados
Un atacante con permisos de storagetransfer.transferjobs.create o storagetransfer.transferjobs.update puede crear o modificar un trabajo del Servicio de transferencia de almacenamiento para copiar datos de un bucket de Cloud Storage sensible a un bucket controlado por el atacante en otro proyecto. Este vector de ataque se puede usar para filtrar grandes volúmenes de datos de forma silenciosa y continua, lo que evita la supervisión típica del acceso a los datos que podría enfocarse en llamadas directas a la API, como storage.objects.get.
| Categoría de STRIDE |
Divulgación de información |
| Táctica de MITRE ATT&CK |
Robo de datos |
| Manifestaciones |
Creación de trabajos de transferencia maliciosos: Un atacante con permisos de storagetransfer.transferjobs.create o storagetransfer.transferjobs.update crea o modifica un trabajo del Servicio de transferencia de almacenamiento para copiar datos de un bucket sensible de Cloud Storage a un bucket controlado por el atacante en otro proyecto.
|
| Mitigaciones |
Limita estrictamente los permisos de IAM para storagetransfer.transferjobs.create y storagetransfer.transferjobs.update. Asigna estos permisos solo a los roles que usan las cuentas administrativas de confianza. Implementa un perímetro de Controles del servicio de VPC para restringir la comunicación entre los servicios dentro del perímetro y los servicios fuera del perímetro. Usa condiciones de IAM en los roles que otorgan permisos de trabajos de transferencia para restringir los buckets de origen y destino a ubicaciones conocidas y autorizadas. Supervisa periódicamente los registros de auditoría de Cloud para detectar la creación y modificación de tareas del Servicio de transferencia de almacenamiento. Configura alertas para los trabajos que especifiquen un destino externo o no confiable.
|
Pérdida de acceso a los datos por una administración incorrecta de las dependencias
Los ataques o la mala administración de las dependencias de servicios críticos pueden denegar el acceso legítimo a los datos en Cloud Storage, lo que hace que los datos sean inaccesibles incluso sin comprometer directamente el sistema de almacenamiento en sí.
| Categoría de STRIDE |
Manipulación |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
No disponibilidad de la CMEK: Si un bucket de Cloud Storage está configurado para usar una CMEK, inhabilitar o borrar la clave de Cloud KMS de respaldo hace que todos los objetos encriptados con esa clave sean criptográficamente inaccesibles. El agente de servicio de Cloud Storage no puede realizar el desencriptado, lo que genera una denegación total del servicio para esos datos. Bloqueo malicioso del bucket: Un atacante con permisos de storage.buckets.update puede aplicar un bloqueo del bucket con un período de retención excesivamente largo. Este bloqueo impide el borrado legítimo de datos, lo que puede generar una acumulación de costos significativos e innecesarios, una forma de denegación de servicio financiera.
|
| Mitigaciones |
Implementa políticas de permiso de IAM estrictas y separación de obligaciones para la administración de Cloud KMS. Asegúrate de que las identidades con permiso para administrar buckets de Cloud Storage no tengan también permiso para administrar las claves de Cloud KMS que usan los buckets. Usa mecanismos de prevención de eliminación de claves de Cloud KMS. En el caso del bloqueo de bucket, controla estrictamente el permiso storage.buckets.update y usa la supervisión para generar alertas sobre cambios de configuración inesperados.
|
Ofuscación de la actividad a través de una observabilidad insuficiente
Un atacante puede realizar acciones maliciosas contra los recursos de Cloud Storage sin ser detectado si la auditoría y la supervisión no están configuradas correctamente. La observabilidad insuficiente permite que un atacante oculte sus rastros y evita una respuesta ante incidentes y un análisis forense eficaces.
| Categoría de STRIDE |
Rechazo |
| Táctica de MITRE ATT&CK |
Evasión de defensa |
| Manifestaciones |
Registros de acceso a los datos inhabilitados: Si bien los registros de actividad del administrador siempre están activados, los registros de acceso a los datos, que registran las lecturas y escrituras de objetos, están inhabilitados de forma predeterminada. Si no se habilita de forma explícita, un atacante puede robar o manipular todos los datos de un bucket sin generar registros de auditoría de Cloud para esas acciones, lo que dificulta la detección o investigación de la vulneración. Manipulación del receptor de registros: Un atacante que obtiene los permisos suficientes puede inhabilitar o reconfigurar los receptores de registros que enrutan los registros de auditoría de Cloud, lo que detiene de manera efectiva el flujo de datos relevantes para la seguridad hacia los sistemas de supervisión. Negligencia en la supervisión de métricas: Un atacante realiza actividades lentas y graduales, como la filtración gradual de pequeñas cantidades de datos durante un período prolongado. Es posible que estas acciones no activen alertas de gravedad alta en los registros de auditoría de Cloud, pero crearían patrones anómalos en las métricas de Cloud Monitoring (por ejemplo, tráfico de salida sostenido). Si no se supervisan estas métricas, el atacante puede pasar desapercibido.
|
| Mitigaciones |
Habilita los registros de auditoría de acceso a los datos para todos los buckets que contengan datos sensibles o críticos. Asegúrate de que los registros se enruten a un proyecto de registro centralizado y seguro con permisos estrictamente controlados para evitar la manipulación de los receptores de registros. Configura alertas basadas en registros en Cloud Monitoring o en un SIEM para detectar de forma activa actividades sospechosas, como patrones de acceso anómalos o cambios en las políticas de IAM de permiso. Crea alertas basadas en métricas clave de Cloud Monitoring para detectar desviaciones del comportamiento de referencia. Usa los paneles y los datos de estadísticas integrados de Storage Intelligence de la administración de la postura de seguridad de los datos para proporcionar una supervisión continua de la exposición al riesgo a nivel de objeto y evaluaciones de la postura de seguridad.
|
Envenenamiento de la cadena de suministro con artefactos comprometidos almacenados en Cloud Storage
Si un atacante obtiene acceso de escritura, como storage.objects.create o storage.objects.delete, a un bucket de Cloud Storage que se usa para almacenar artefactos de software (por ejemplo, archivos binarios, imágenes de contenedor o secuencias de comandos de compilación), puede reemplazar los artefactos legítimos por versiones maliciosas. Las canalizaciones de CI/CD, los desarrolladores o los usuarios finales que confían en los artefactos de este bucket ejecutarán inadvertidamente el código comprometido, lo que generará un ataque generalizado a la cadena de suministro.
| Categoría de STRIDE |
Manipulación |
| Táctica de MITRE ATT&CK |
Acceso inicial |
| Manifestaciones |
Reemplazo de binarios: Un atacante reemplaza un binario o una biblioteca de lanzamiento por una versión troyanizada. Cuando este artefacto se incorpora a una compilación o se implementa, el código del atacante se ejecuta en el entorno de destino. Envenenamiento de imágenes de contenedor: Un atacante con acceso a un bucket que se usa como backend para un registro de contenedores (por ejemplo, Artifact Registry) puede manipular capas de imágenes, lo que permite inyectar vulnerabilidades o puertas traseras. Modificación de la secuencia de comandos de compilación: Un atacante modifica las secuencias de comandos de compilación (por ejemplo, cloudbuild.yaml o Makefile) almacenadas en Cloud Storage para alterar el proceso de compilación en sí. Un atacante podría modificar las secuencias de comandos de compilación para filtrar secretos o incorporar una puerta trasera durante la compilación. Envenenamiento de modelos de IA: Un atacante podría intercambiar un punto de control de modelo válido en Cloud Storage por un punto de control malicioso que ejecute código cuando lo cargue un sistema de producción. O bien, un atacante podría modificar los datos en un bucket de Cloud Storage que se usa para el entrenamiento de modelos y, así, insertar puertas traseras o comportamientos maliciosos en el modelo entrenado.
|
| Mitigaciones |
Usa un servicio de administración de artefactos dedicado, como Artifact Registry, que proporciona análisis de vulnerabilidades y un mejor control de acceso. Evita usar buckets estándar de Cloud Storage para almacenar artefactos de software críticos. Implementa la firma digital para todos los artefactos de compilación. Configura canalizaciones de CI/CD para verificar la firma de un artefacto antes de implementarlo, lo que garantiza su integridad y procedencia. Configura el control de versiones de objetos en un bucket para conservar los objetos que se reemplazaron con datos maliciosos.
|
Denegación de servicio basada en costos con inundación de objetos de Cloud Storage o abuso de salida
Un atacante con permisos de creación de objetos en un bucket de escritura pública o mal protegido puede subir una gran cantidad de objetos pequeños, lo que genera costos financieros significativos por las operaciones de clase A y las tarifas de almacenamiento. Como alternativa, un atacante con acceso de lectura a un bucket con la opción "El solicitante paga" inhabilitada puede descargar objetos grandes de forma repetida, lo que genera cargos excesivos por salida de red y, posiblemente, afecta la disponibilidad del servicio para los usuarios legítimos debido a los límites de facturación.
| Categoría de STRIDE |
Denegación del servicio |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
Inundación de objetos: Un atacante usa una secuencia de comandos para crear rápidamente millones de objetos pequeños en un bucket, lo que aumenta los costos operativos y podría afectar las aplicaciones que enumeran o procesan el contenido del bucket. Abuso de salida: En el caso de un bucket que aloja grandes conjuntos de datos públicos, un atacante descarga archivos de forma reiterada, lo que provoca un agotamiento financiero a través de los costos de ancho de banda de salida. Este abuso puede hacer que el proyecto alcance las cuotas de facturación, lo que provoca una denegación del servicio.
|
| Mitigaciones |
Configura alertas de Facturación de Cloud para notificar a los administradores cuando los costos superen un umbral de presupuesto predefinido, lo que te permitirá detectar gastos anómalos de forma anticipada. En el caso de los buckets de acceso público, habilita los pagos del solicitante. Esta función traslada el costo del acceso y la salida de datos al usuario que los descarga, lo que mitiga los ataques basados en costos de salida contra el propietario del bucket. Usa Storage Insights para supervisar la actividad a nivel del objeto. Storage Insights proporciona la visibilidad necesaria para la previsión de costos y la identificación de objetos con mucho tráfico que podrían ser objetivos de abuso de salida.
|
Manipulación de la integridad de los datos a través del abuso del control de versiones de objetos de Cloud Storage
Si bien el control de versiones de objetos es una defensa clave, un atacante con permisos suficientes, como storage.objects.delete o storage.objects.create, puede manipular el historial de objetos para comprometer la integridad de los datos. Pueden borrar la versión actual de un objeto, lo que hace que una versión anterior, potencialmente incorrecta o vulnerable, se convierta en la versión "publicada". Esto se puede usar para revertir parches de seguridad, reintroducir errores o restablecer información desactualizada sin que sea evidente de inmediato, ya que el objeto sigue existiendo.
| Categoría de STRIDE |
Manipulación |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
Reversión del parche de seguridad: Un atacante borra la versión más reciente de un archivo binario de aplicación o de configuración que contiene un parche de seguridad, lo que hace que el sistema vuelva a la versión anterior vulnerable. Corrupción de datos por reversión: En un sistema que depende de Cloud Storage para almacenar el estado o la configuración, un atacante revierte un objeto de configuración crítico a un estado anterior, lo que provoca errores de configuración del servicio o errores de procesamiento de datos. Manipulación de la integridad del modelo de IA: Un atacante podría sobrescribir o revertir un punto de control del modelo de IA almacenado en un bucket de Cloud Storage.
|
| Mitigaciones |
Desarrolla aplicaciones que dependan de versiones específicas de objetos para recuperar el objeto por su número de generación único, no solo por su nombre. Esto garantiza que siempre se recupere la versión correcta. Usa un bloqueo del bucket con una política de retención definida para los datos que requieren almacenamiento inmutable. Configura una política de eliminación no definitiva como una capa adicional de defensa contra la eliminación maliciosa. El control de versiones de objetos no proporciona protección contra la eliminación de bucket.
|
Robo de datos con canalizaciones de Dataflow activadas por Cloud Storage
Si una canalización de Dataflow está configurada para activarse automáticamente cuando se crea un objeto en un bucket de Cloud Storage, un atacante que pueda escribir en ese bucket podría exfiltrar datos. Si la cuenta de servicio del trabajo de Dataflow tiene permisos para acceder a otros datos sensibles y escribir en ubicaciones externas (por ejemplo, otro bucket de Cloud Storage o BigQuery), el atacante puede crear un archivo de entrada que haga que la canalización lea datos sensibles y los escriba en una ubicación controlada por el atacante.
| Categoría de STRIDE |
Divulgación de información |
| Táctica de MITRE ATT&CK |
Robo de datos |
| Manifestaciones |
Exfiltración entre proyectos: Un atacante sube un archivo a un bucket de activación. La canalización de Dataflow, que se ejecuta con una cuenta de servicio privilegiada, lee datos sensibles de un proyecto diferente y escribe el resultado en un bucket público de Cloud Storage especificado por el archivo de entrada del atacante.
|
| Mitigaciones |
Encierra la canalización de Dataflow y sus dependencias de Cloud Storage dentro de un perímetro de Controles del servicio de VPC para evitar que la canalización envíe datos a destinos externos no autorizados. Aplica el principio de privilegio mínimo a la cuenta de servicio del trabajador de Dataflow. Solo debe tener los permisos específicos necesarios para leer desde la fuente y escribir en el destino previsto. Habilita los registros de auditoría de acceso a los datos para los eventos de DATA_WRITE y, así, auditar la actividad sospechosa de la canalización de Dataflow. Habilita el acceso uniforme a nivel del bucket en tu bucket de Cloud Storage para garantizar un control de acceso coherente basado en IAM.
|
Compromiso de integridad a través de la manipulación del estado de IaC en Cloud Storage
Cuando se usan buckets de Cloud Storage para almacenar archivos de estado de infraestructura como código (IaC) (por ejemplo, el archivo terraform.tfstate en Terraform), un atacante con acceso de escritura al bucket de estado puede manipular el archivo de estado. Si se modifica el estado, un atacante puede insertar recursos maliciosos, cambiar parámetros de configuración de seguridad críticos o provocar la destrucción de recursos en la próxima ejecución de IaC. Esta manipulación burla los procesos de revisión de código, ya que el ataque se dirige al estado, no al código en sí.
| Categoría de STRIDE |
Manipulación |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
Inhabilitación del control de seguridad: Un atacante altera el archivo de estado para mostrar un estado impreciso de una regla de firewall o una política de IAM de permiso. Es posible que el siguiente comando Terraform apply no aplique correctamente la configuración segura prevista.
|
| Mitigaciones |
Habilita el control de versiones de objetos en el bucket de Cloud Storage que almacena el archivo de estado. El control de versiones de objetos te permite recuperar el archivo de estado en caso de modificación accidental o maliciosa. Implementa controles estrictos de IAM en el bucket del archivo de estado. Asegúrate de que solo la cuenta de servicio de CI/CD tenga acceso de escritura y de que los desarrolladores tengan acceso de solo lectura como máximo.
|
Elevación de privilegios para secuencias de comandos de inicio o de arranque almacenadas en Cloud Storage
Si una instancia de Compute Engine o un nodo de GKE extrae sus secuencias de comandos de inicio o de arranque de un bucket de Cloud Storage, un atacante con acceso de escritura a ese bucket puede modificar estas secuencias de comandos. Debido a que estos secuencias de comandos suelen ejecutarse con privilegios altos (por ejemplo, como raíz en la VM o con la cuenta de servicio del nodo), el atacante puede insertar comandos para crear usuarios de puerta trasera, filtrar metadatos y tokens de acceso, o instalar software malicioso. Estas acciones permiten que un atacante aumente los privilegios de los permisos de escritura de objetos de Cloud Storage al control total de los recursos de procesamiento.
| Categoría de STRIDE |
Elevación de privilegios |
| Táctica de MITRE ATT&CK |
Elevación de privilegios |
| Manifestaciones |
Robo de metadatos: El atacante agrega comandos como curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/... a la secuencia de comandos de inicio para robar tokens de cuentas de servicio o cualquier otro secreto. Shell inversa: El atacante inyecta un comando para iniciar una shell inversa desde la instancia de procesamiento hasta un servidor controlado por el atacante, lo que le otorga acceso interactivo.
|
| Mitigaciones |
Almacena las secuencias de comandos de inicio en un bucket de Cloud Storage dedicado y estrictamente controlado. Aplica políticas de permisos de IAM de privilegio mínimo para que solo los administradores autorizados o las canalizaciones de CI/CD puedan modificar las secuencias de comandos. Considera una estrategia de clasificación de datos en la que configures etiquetas de recursos en los buckets que se usan para las secuencias de comandos de inicio y utilices el acceso condicional basado en etiquetas de IAM para restringir aún más el acceso. En lugar de extraer secuencias de comandos de Cloud Storage, inclúyelas en imágenes de máquinas personalizadas. Esta estrategia crea un artefacto inmutable que es menos susceptible a las modificaciones en el tiempo de ejecución.
|
Puerta trasera de la cadena de suministro que usa datos de entrenamiento de AA alojados en Cloud Storage
Un atacante con acceso de escritura a un bucket de Cloud Storage que contiene datos de entrenamiento para un modelo de aprendizaje automático puede contaminar el conjunto de datos. Si inyecta datos maliciosos creados con cuidado, el atacante puede crear una puerta trasera en el modelo entrenado. Esta puerta trasera puede hacer que el modelo clasifique de forma incorrecta entradas específicas de una manera que beneficie al atacante y, al mismo tiempo, se comporte de forma normal con los datos generales para evadir la detección. Por ejemplo, el modelo podría aprobar transacciones fraudulentas o eludir las verificaciones de seguridad.
| Categoría de STRIDE |
Manipulación |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
Clasificación errónea segmentada: Un atacante inserta datos envenenados que hacen que un modelo de detección de fraude entrenado siempre clasifique las transacciones de una cuenta controlada por el atacante como legítimas. Evasión del modelo: Un atacante envenena los datos de entrenamiento de un modelo de detección de software malicioso con ejemplos de su software malicioso etiquetados como benignos, lo que provoca que el modelo final ignore sus herramientas específicas.
|
| Mitigaciones |
Implementa controles de acceso sólidos en los buckets de Cloud Storage que contienen datos de entrenamiento. Aplica el principio de privilegio mínimo para otorgar acceso de escritura a estos buckets y realiza auditorías periódicas con herramientas como el Analizador de políticas. Considera una estrategia de clasificación de datos en la que configures etiquetas de recursos en los buckets que se usan para los datos de entrenamiento del AA y agregues condiciones basadas en etiquetas de IAM para restringir aún más el acceso. Audita las modificaciones no autorizadas en los objetos que se usan para los datos de entrenamiento. Configura el control de versiones de objetos, mantén las sumas de verificación y configura los registros de auditoría de acceso a los datos para el evento DATA_WRITE, de modo que se puedan auditar las anomalías de los eventos de creación de objetos relacionados con los datos de entrenamiento. Audita y valida periódicamente los modelos de AA para detectar comportamientos inesperados. Emplea técnicas de pruebas adversarias para detectar puertas traseras o vulnerabilidades ocultas que se hayan introducido durante el entrenamiento. Configura un perímetro de Controles del servicio de VPC para restringir el acceso a recursos sensibles, como datos de entrenamiento y otros servicios involucrados en la creación de modelos, desde fuera del perímetro de confianza.
|
Denegación de servicio con flujos de trabajo de fan-out activados por la creación de objetos en Cloud Storage
Si un flujo de trabajo (por ejemplo, Cloud Run Functions o Workflows) está configurado para activar la creación de objetos en un bucket de Cloud Storage y realizar una tarea que requiere muchos recursos, un atacante con permiso de storage.objects.create puede iniciar un ataque de denegación de servicio. Si sube una gran cantidad de archivos en un período corto (lo que se conoce como activador de fan-out), el atacante puede hacer que el servicio downstream se escale rápidamente, lo que genera un consumo excesivo de recursos, alcanza los límites de simultaneidad o escalamiento, y genera costos significativos, lo que, en última instancia, provoca la falta de disponibilidad del servicio para los usuarios legítimos.
| Categoría de STRIDE |
Denegación del servicio |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
Agotamiento de recursos: Un atacante sube 10,000 archivos pequeños, lo que activa 10,000 invocaciones paralelas de funciones de Cloud Run que agotan la cuota de CPU, la memoria o los límites de frecuencia de la API de nivel inferior del proyecto. DoS basado en costos: El fan-out activa una gran cantidad de ejecuciones en un servicio pagado, lo que genera una factura enorme y una posible suspensión de la cuenta, lo que efectivamente deniega el servicio.
|
| Mitigaciones |
Implementa controles de acceso seguros en los buckets de Cloud Storage que activan flujos de trabajo. Aplica el principio de privilegio mínimo para otorgar acceso de escritura a estos buckets y realiza auditorías periódicas con herramientas como el Analizador de políticas. Establece límites de simultaneidad en Cloud Run Functions basadas en eventos para controlar la cantidad máxima de ejecuciones paralelas y evitar el agotamiento de recursos. Implementa un mecanismo de eliminación de rebotes que, luego, invoca la lógica de procesamiento principal. Un ejemplo de mecanismo de eliminación de rebotes es agregar una tarea a una cola de Cloud Tasks con límites de frecuencia. Este mecanismo ayuda a administrar los aumentos repentinos en el volumen de solicitudes, ya que las distribuye a lo largo del tiempo. Configura un perímetro de Controles del servicio de VPC para restringir el acceso a recursos sensibles, como escribir en un bucket que activa un flujo de trabajo, desde fuera del perímetro de confianza.
|
Movimiento de datos no autorizado con canalizaciones de copias de seguridad respaldadas por Cloud Storage
Las herramientas de copia de seguridad y recuperación ante desastres (DR) suelen usar Cloud Storage como área de etapa de pruebas o destino final para las copias de seguridad. Si un atacante compromete la configuración de esta herramienta, puede redireccionar las copias de seguridad a un bucket de Cloud Storage controlado por el atacante. La cuenta de servicio de copia de seguridad suele tener amplios permisos de lectura en muchas fuentes de datos (por ejemplo, bases de datos o VMs), lo que permite que el atacante filtre grandes volúmenes de datos sensibles manipulando el parámetro de destino del trabajo de copia de seguridad.
| Categoría de STRIDE |
Divulgación de información |
| Táctica de MITRE ATT&CK |
Robo de datos |
| Manifestaciones |
Redireccionamiento del trabajo de copia de seguridad: Un atacante con permisos para editar la configuración de un trabajo de copia de seguridad cambia la ruta de acceso del bucket de Cloud Storage de destino a gs://attacker-public-bucket/. Copia de seguridad entre proyectos: El atacante configura un nuevo trabajo de copia de seguridad dentro de un proyecto vulnerado para leer datos de una fuente sensible y crear una copia de seguridad en un bucket de un proyecto de Google Cloud diferente controlado por el atacante.
|
| Mitigaciones |
Asegúrate de que las cuentas de servicio de la herramienta de copia de seguridad tengan permisos de alcance limitado. Configura las herramientas de copia de seguridad para que solo puedan escribir en buckets de copia de seguridad específicos y designados, y no leer desde ubicaciones arbitrarias. Usa los Controles del servicio de VPC para evitar que los servicios de copia de seguridad accedan a fuentes de datos sensibles y escriban en buckets de Cloud Storage fuera de un perímetro seguro.
|
Omisión de políticas con el uso de LCA heredadas de Cloud Storage en entornos híbridos
Cloud Storage admite dos sistemas de control de acceso mutuamente excluyentes: IAM y LCA heredadas. Cuando se inhabilita el acceso uniforme a nivel del bucket, se evalúan ambos sistemas. Un atacante puede aprovechar esta configuración agregando una LCA heredada (por ejemplo, otorgando acceso a una cuenta de Google personal o a un grupo público) a un objeto, incluso si la política de permiso a nivel del bucket parece restrictiva. Este ataque crea una ruta de acceso oculta que, a menudo, los verificadores de seguridad centrados en IAM no detectan, lo que permite que el atacante eluda las políticas de seguridad previstas.
| Categoría de STRIDE |
Elevación de privilegios |
| Táctica de MITRE ATT&CK |
Evasión de defensa |
| Manifestaciones |
Acceso público a nivel del objeto: Un atacante con el permiso storage.objects.update agrega una LCA de lectura pública a un objeto sensible, lo que lo hace accesible para cualquier persona en Internet y elude una política de permisos restrictiva del bucket. Acceso entre cuentas: Un atacante asigna a su cuenta externa el permiso OWNER en un objeto de configuración crítico con una LCA, lo que le permite modificar el objeto sin que lo detecten las auditorías de IAM.
|
| Mitigaciones |
Habilita el acceso uniforme a nivel de bucket en todos los buckets de Cloud Storage. El acceso uniforme a nivel del bucket inhabilita todas las LCA y garantiza que IAM sea el único método coherente para administrar el acceso, lo que simplifica las auditorías y evita este bypass. Usa la restricción de política de la organización constraints/storage.uniformBucketLevelAccess para aplicar el acceso uniforme a nivel del bucket en todos los buckets nuevos de un proyecto, una carpeta o una organización.
|
Destrucción de datos con canalizaciones de CI/CD vulneradas que tienen como objetivo Cloud Storage
A menudo, las canalizaciones de CI/CD reciben cuentas de servicio con privilegios elevados para administrar la infraestructura y, también, implementar artefactos. Si un atacante vulnera el sistema de CI/CD, puede usar la cuenta de servicio de la canalización para realizar acciones destructivas en Cloud Storage. Un ejemplo de compromiso es que un atacante inyecte código malicioso en una secuencia de comandos de compilación o acceda al orquestador. Este compromiso puede implicar borrar buckets o reemplazar objetos críticos.
| Categoría de STRIDE |
Manipulación |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
Paso de compilación malicioso: Un atacante agrega un paso a una canalización de CI/CD que borra todos los datos. Por ejemplo, el atacante agrega un paso en cloudbuild.yaml que ejecuta un comando como gcloud storage rm -r gs://critical-bucket/. Herencia de privilegios: El atacante usa la cuenta de servicio de la canalización vulnerada, que tiene permisos amplios, para otorgar a su propia cuenta acceso administrativo a los buckets de Cloud Storage para su uso posterior.
|
| Mitigaciones |
Aplica el principio de privilegio mínimo a las cuentas de servicio de CI/CD. Por ejemplo, no asignes permisos de canalización de compilación para borrar buckets de producción. Usa identidades separadas para las diferentes etapas de la canalización, como la compilación, la prueba o la implementación. Protege los buckets críticos de Cloud Storage contra la eliminación habilitando el bloqueo de bucket o el bloqueo de objeto, o bien asegurándote de que la cuenta de servicio de CI/CD no tenga el permiso storage.buckets.delete.
|
Borrado no autorizado de bucket con cuentas de emergencia con privilegios excesivos
Las cuentas de anulación de emergencia o de acceso de emergencia son identidades con privilegios elevados que se usan solo en emergencias. Si estas cuentas no están protegidas y administradas de forma adecuada (por ejemplo, si se filtran las credenciales o el acceso no está limitado por tiempo), un atacante que comprometa una cuenta de emergencia puede realizar acciones muy destructivas. Un riesgo principal es el borrado de buckets completos de Cloud Storage, lo que puede provocar una pérdida de datos catastrófica e irreversible, ya que el borrado de bucket es una acción permanente.
| Categoría de STRIDE |
Elevación de privilegios |
| Táctica de MITRE ATT&CK |
Elevación de privilegios |
| Manifestaciones |
Pérdida catastrófica de datos: Un atacante vulnera una cuenta de emergencia mal administrada y ejecuta una secuencia de comandos para borrar todos los buckets de Cloud Storage en un proyecto. Extorsión: Un atacante obtiene acceso y amenaza con borrar buckets críticos a menos que se pague un rescate.
|
| Mitigaciones |
Implementa el acceso justo a tiempo (JIT) para los procedimientos de emergencia en lugar de usar cuentas con privilegios permanentes. Otorga permisos a pedido por un tiempo limitado y para un propósito específico. Aplica un bloqueo de bucket a los buckets que contengan objetos críticos o un bloqueo de objeto a objetos individuales. Los bloqueos impiden que se borre el bucket y sus objetos, incluso por parte de usuarios con permisos de propietario, durante un período de retención específico.
|
Exfiltración silenciosa de datos con receptores de registros vulnerados que escriben en Cloud Storage
Cloud Logging se puede configurar para exportar registros a un bucket de Cloud Storage. Si un atacante obtiene permisos para modificar un receptor de registros, puede volver a configurarlo para exportar registros sensibles a un bucket de Cloud Storage controlado por el atacante en otro proyecto. La exportación de registros sensibles permite que un atacante filtre de forma silenciosa y continua los datos sensibles que se capturan en los registros.
| Categoría de STRIDE |
Divulgación de información |
| Táctica de MITRE ATT&CK |
Robo de datos |
| Manifestaciones |
Redireccionamiento del receptor de registros: Un atacante modifica la propiedad de destino de un receptor de registros existente para que apunte a su propio bucket de Cloud Storage. Creación de filtros maliciosos: Un atacante crea un receptor con un filtro que se dirige específicamente a los registros que contienen información sensible (por ejemplo, PII o tokens) y los exporta.
|
| Mitigaciones |
Supervisa los registros de auditoría de Cloud para las llamadas a las APIs de CreateSink y UpdateSink. Configura alertas para notificar a los equipos de seguridad sobre cualquier receptor de registros nuevo o modificado para asegurarte de que estén autorizados. Configura un perímetro de Controles del servicio de VPC para mitigar el robo de datos.
|
Habilitación de ransomware con revocación centralizada de CMEK
Cuando los buckets de Cloud Storage se encriptan con CMEK, la disponibilidad de los datos está vinculada a la disponibilidad de la clave. Un atacante que obtiene permisos suficientes en Cloud KMS puede destruir o inhabilitar la clave que se usa para un bucket crítico de Cloud Storage. Esta acción hace que todos los datos del bucket sean criptográficamente inaccesibles, lo que equivale a una forma de destrucción de datos o ransomware, ya que los datos permanecen, pero no se pueden desencriptar.
| Categoría de STRIDE |
Manipulación |
| Táctica de MITRE ATT&CK |
Impacto |
| Manifestaciones |
Destrucción de claves: Un atacante con permiso de cloudkms.cryptoKeyVersions.destroy destruye de forma permanente una versión de clave, lo que imposibilita la recuperación de datos. Inhabilitación de la clave: Un atacante con permiso de cloudkms.cryptoKeyVersions.disable inhabilita una clave, lo que hace que los datos de Cloud Storage sean ilegibles hasta que se vuelva a habilitar la clave. Esta acción puede causar una interrupción prolongada.
|
| Mitigaciones |
Aplicar una duración mínima para el estado de destrucción programada antes de que se puedan destruir las claves de Cloud KMS De forma predeterminada, este período es de 30 días, pero puedes configurar un período de entre 1 y 120 días cuando se crea una clave por primera vez. No puedes modificar este período después de que se borra una clave. Considera aplicar la restricción de la política de la organización constraints/cloudkms.minimumDestroyScheduledDuration para garantizar que no se puedan crear claves con un período de destrucción programada inferior al mínimo esperado. Limita estrictamente el acceso a los roles de administrador de Cloud KMS. Separa las tareas de uso de claves de las de administración de claves para evitar que una sola cuenta vulnerada use y destruya claves. Rota periódicamente las claves de Cloud KMS y elige un período de rotación según los requisitos de sensibilidad o cumplimiento de tu carga de trabajo.
|
Robo de datos con exportaciones de instantáneas o copias de seguridad a Cloud Storage
Muchos servicios de Google Cloud (por ejemplo, Compute Engine o Cloud SQL) permiten crear instantáneas o exportar copias de seguridad a Cloud Storage. Un atacante con permisos para realizar estas operaciones de exportación puede crear una instantánea de un recurso que contenga datos sensibles y guardarla en un bucket de Cloud Storage con permisos laxos, como un bucket público o un bucket compartido con una cuenta externa. Esta acción omite los controles de acceso más estrictos del recurso principal (por ejemplo, las credenciales de la base de datos), ya que ahora se puede acceder a los datos con Cloud Storage IAM.
| Categoría de STRIDE |
Divulgación de información |
| Táctica de MITRE ATT&CK |
Robo de datos |
| Manifestaciones |
Instantánea de disco en un bucket público: Un desarrollador interno con permisos de compute.snapshots.create y storage.objectAdmin crea una instantánea de un disco de VM que contiene secretos y la exporta a un bucket público de Cloud Storage. Exportación de la base de datos: Un atacante con permiso de cloudsql.instances.export exporta una base de datos de producción a un bucket de Cloud Storage en un proyecto controlado por el atacante.
|
| Mitigaciones |
Asegúrate de que los proyectos designados para copias de seguridad y snapshots tengan políticas de IAM y de Controles del servicio de VPC que sean al menos tan estrictas como las de los proyectos de origen para mantener una postura de seguridad coherente. Considera una estrategia de clasificación de datos en la que configures etiquetas de recursos en los buckets que se usan para las copias de seguridad y agregues condiciones de acceso basadas en etiquetas de IAM para restringir aún más el acceso.
|
