Mitiga los 10 riesgos principales de OWASP 2025 en Google Cloud

En este documento, se identifican los servicios y las estrategias de mitigación que pueden ayudarte a defenderte de los ataques a nivel de la aplicación que se describen en OWASP Top 10:2025. Google Cloud OWASP Top 10:2025, creado por la Fundación Open Web Application Security (OWASP), es una lista de los 10 principales riesgos de seguridad en un ciclo de vida de desarrollo de software (SDLC). Aunque ningún servicio puede garantizar una protección completa contra estos riesgos, aplicar estos servicios cuando tengan sentido en tu arquitectura puede contribuir a una solución sólida de seguridad multicapa.

La infraestructura de Google está diseñada para ayudarte a compilar, implementar y operar servicios con controles de seguridad sólidos. Google administra la seguridad física y operativa, la encriptación de datos en reposo y en tránsito, y muchas otras protecciones fundamentales de la infraestructura. Para heredar estos beneficios, debes implementar tus aplicaciones en Google Cloud, pero es posible que debas tomar medidas adicionales para proteger tu aplicación contra ataques específicos.

Nota: Aunque Google Cloud proporciona defensas sólidas de perímetro y tiempo de ejecución, la seguridad es una responsabilidad compartida. Para mitigar los riesgos de OWASP de manera eficaz, es necesario integrar la seguridad en una etapa temprana del ciclo de vida de desarrollo de software (SDLC). Usa los siguientes servicios junto con marcos de trabajo de programación seguros de forma predeterminada, capacitación periódica para desarrolladores y modelado de amenazas proactivo.

Matriz de cumplimiento

Los servicios de Google Cloud que se enumeran en la siguiente tabla pueden ayudar a defenderte de los 10 riesgos de seguridad principales que se identifican en OWASP Top 10:2025:

Categoría OWASP Top 10:2025	Controles primarios Google Cloud y de Wiz
A01: Control de acceso dañado	Access Context Manager, Agent Gateway, Agent Identity, Apigee, Google Cloud Armor, Firebase App Check, Firebase Security Rules, Cloud Next Generation Firewall (Cloud NGFW), Identity-Aware Proxy (IAP), Identity and Access Management (IAM), Organization Policy Service, VPC Service Controls, Wiz Cloud
A02: Configuración incorrecta de la seguridad	Access Context Manager, Cloud Asset Inventory, Google Security Operations, Organization Policy, Security Command Center Premium, VPC Service Controls, Wiz Cloud
A03: Fallas en la cadena de suministro de software	Artifact Registry, Assured Open Source Software (Assured OSS), Autorización Binaria, Cloud Build, Cloud Deploy, Cloud Workstations, CodeMender, Wiz Code
A04: Fallas criptográficas	Apigee, Certificate Authority Service, Certificate Manager, Cloud Key Management Service, Cloud Load Balancing, Cloud Workstations, Confidential Computing, Organization Policy, Secret Manager, Sensitive Data Protection, Wiz Cloud
A05: Inserción	Apigee, Cloud Armor, CodeMender, Reglas de seguridad de Firebase, Cloud Next Generation Firewall (Cloud NGFW), Model Armor, Security Command Center Premium, VirusTotal, Wiz Code
A06: Diseño no seguro	Apigee, CodeMender, Mandiant, Wiz Cloud
A07: Fallas de autenticación	Access Context Manager, Agent Identity, Apigee, Cloud Armor, Cloud Identity, Verificación de aplicaciones de Firebase, Firebase Authentication, Google Cloud Fraud Defense, IAM (Privileged Access Manager, federación de identidades para cargas de trabajo y Workforce Identity Federation), IAP, Identity Platform, Security Command Center Premium, Secret Manager, Titan Security Keys, Wiz Code
A08: Fallas de integridad de software o datos	Artifact Analysis, Assured OSS, Autorización Binaria, Cloud Armor, Cloud Build, Cloud Deploy, Verificación de aplicaciones de Firebase, Security Command Center Premium, VirusTotal, Wiz Defend
A09: Errores de registro y alertas de seguridad	Aprobación de acceso y Transparencia de acceso, Apigee, Google SecOps, Cloud Logging, Cloud Monitoring, Sensitive Data Protection, Wiz Defend
A10: Manejo inadecuado de condiciones excepcionales	Cloud Armor, Cloud Load Balancing, Error Reporting, Model Armor

Servicios deGoogle Cloud

En las siguientes secciones, se describen las prácticas recomendadas de OWASP Top 10 para los servicios principales deGoogle Cloud .

Aprobación de acceso y Transparencia de acceso

Transparencia de acceso y Aprobación de acceso permiten verificar el acceso de los proveedores de servicios en la nube. Con la Transparencia de acceso, puedes registrar el motivo de cada acceso que realice el personal de Google. La Aprobación de acceso te permite aprobar o descartar las solicitudes de acceso del personal de Google que trabaja para brindar asistencia a tu servicio.

Se aplica a A09: Errores de registro y alertas de seguridad.

Revisa las siguientes prácticas recomendadas:

• Automatiza el proceso de aprobación de acceso. Para ello, configura la Aprobación de acceso para que envíe los metadatos de las solicitudes de aprobación de acceso entrantes a un tema de Pub/Sub. Crea una suscripción a Pub/Sub que envíe la carga útil de JSON a tu extremo de webhook personalizado (como un servicio autenticado de Cloud Run, funciones de Cloud Run o una puerta de enlace de API empresarial) para su procesamiento.
• Considera los registros de Transparencia de acceso como telemetría de seguridad crítica. Crea métricas basadas en registros y políticas de alertas en Monitoring para marcar tu centro de operaciones de seguridad (SecOps) si el personal de Google accede a recursos sensibles sin un ticket de asistencia activo correspondiente.
• Exporta los registros de Transparencia de acceso directamente a Google SecOps o a tu SIEM empresarial centralizado.
• Crea una política de cumplimiento para auditar tus transmisiones de registros con regularidad y verificar que los eventos de acceso de emergencia de auto_approved se correlacionen con un incidente documentado de alta gravedad.
• Para el control criptográfico, usa Key Access Justifications para forzar al sistema a solicitar de forma programática una aprobación de desencriptación de la clave.

Access Context Manager

Access Context Manager es el motor de acceso adaptado al contexto deGoogle Cloud. Access Context Manager te permite definir niveles de acceso basados en atributos (como rangos de direcciones IP del cliente, postura de seguridad del dispositivo y ubicación geográfica) para IAP, los Controles del servicio de VPC y IAM.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A02: Configuración incorrecta de seguridad
• A07: Fallas de autenticación

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Crea niveles de seguridad reutilizables y jerárquicos para la política de acceso de tu organización. Crea niveles de acceso básicos para probar atributos estándar. Para condiciones complejas y multifactoriales, implementa niveles de acceso personalizados para evaluar estados avanzados del dispositivo y señales de extremos de terceros.
• Usa Endpoint Verification o Chrome Enterprise Core para aplicar restricciones a nivel del dispositivo, como la encriptación de disco completo, un bloqueo de pantalla activo y una versión aprobada del sistema operativo.
• Para proteger los repositorios de datos valiosos con los Controles del servicio de VPC, agrega niveles de acceso a tus reglas de entrada de los Controles del servicio de VPC. Si se filtra una clave de cuenta de servicio, un atacante no puede usar solo la clave para consultar BigQuery o Cloud Storage desde una dirección IP pública no autorizada o una máquina no confiable.
• Para extender la protección de confianza cero a las aplicaciones web y los túneles administrativos de VM, conecta niveles de acceso directamente a tus recursos protegidos con IAP.

Revisa las siguientes prácticas recomendadas para A02: Configuración de seguridad incorrecta:

• Implementa políticas de acceso con alcance que estén vinculadas a carpetas específicas para delegar la administración de políticas locales a equipos de proyectos individuales y aislar sus cambios del resto de la organización.
• Para evitar que las reglas de entrada huérfanas se conviertan en puertas traseras silenciosas, revisa y quita periódicamente los rangos de IP retirados, las subredes de socios vencidas y los atributos de dispositivos obsoletos.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Usa vinculaciones de acceso del usuario para establecer duraciones máximas estrictas de las sesiones. Configura la política de reautenticación para que requiera SECURITY_KEY (FIDO2 o WebAuthn). Para aplicar restricciones más estrictas a los entornos de alto riesgo, configura scopedAccessSettings para anular las duraciones de sesión predeterminadas de las aplicaciones sensibles.

Agent Gateway y Agent Identity

Agent Gateway y Agent Identity proporcionan aplicación de políticas de red, administración del ciclo de vida de la identidad y autenticación criptográfica dedicadas para agentes de IA y flujos de trabajo basados en agentes.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A07: Fallas de autenticación

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• En entornos con sistemas multiagente, herramientas de MCP externas o canalizaciones autónomas, usa Agent Gateway como un punto de aplicación de políticas y red dedicado para ayudar a mitigar las fallas en el control de acceso de los agentes.
• Configura políticas de autorización detalladas para las identidades de los agentes y restringe el acceso a las herramientas y la recuperación de datos solo a los recursos necesarios para el flujo de trabajo específico del agente.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Para autenticar agentes autónomos e integraciones de herramientas sin incorporar contraseñas o claves de API estáticas, genera y asigna una identidad de agente a cada agente.
• Configura la identidad del agente para emitir un certificado X.509 como credenciales del agente. Estos certificados ayudan a evitar el robo de tokens, de modo que, si se intercepta un token de acceso, este no se pueda usar desde otros entornos.

Apigee

Apigee proporciona mecanismos centralizados a nivel de la puerta de enlace que usan proxies de API para aplicar estándares criptográficos, validar cargas útiles firmadas y encriptar datos de aplicaciones en tránsito y en reposo. Al actuar como puerta de enlace de proxy inverso para el tráfico de la API, Apigee ejecuta verificaciones de límites y estructura para ayudar a validar las cargas útiles. Apigee proporciona políticas integradas de autenticación de API, OAuth y verificación de tokens web JSON (JWT) para establecer límites de identidad sólidos. Apigee incluye varias formas de realizar el registro, la supervisión, el manejo de errores y el registro de auditoría.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A04: Fallas criptográficas
• A05: Inyección
• A06: Diseño no seguro
• A07: Fallas de autenticación
• A09: Errores de registro y alertas de seguridad

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Usa proxies de API para completar las siguientes tareas:

  • Intercepta las solicitudes en las que un atacante intenta acceder a los registros de otro usuario manipulando las variables de ID en la ruta de acceso de la solicitud a la API.

  • Bloquea a los clientes estándar para que no ejecuten métodos administrativos restringidos ni operaciones con privilegios elevados.

• Para el plano de administración de la API, aplica controles de acceso, autenticación y almacenamiento de secretos con mapas de clave-valor encriptados, Secret Manager o secretos de Kubernetes (solo en implementaciones híbridas).

• Usa políticas de OAuth y tokens JWT para verificar firmas. Asigna extremos y acciones sensibles a permisos de OAuth detallados y de alto privilegio (por ejemplo, delete:account o write:billing). Usa la política de OAuthV2 para validar estos permisos en el punto de entrada de la API y devolver un código de estado HTTP 403 Forbidden a cualquier cliente que no tenga los permisos correctos.

• Habilita Advanced API Security para analizar el tráfico en busca de patrones de comportamiento anómalos y comenzar a aplicar acciones de seguridad.

Revisa las siguientes prácticas recomendadas para A04: Fallas criptográficas:

• Encripta los datos sensibles en tu aplicación y aplica una validación criptográfica estricta antes de que el tráfico llegue a tu aplicación de backend. Configura tu entorno de Apigee con claves de encriptación administradas por el cliente (CMEK) con Cloud KMS.
• Usa TLS unidireccional y bidireccional para encriptar la información sensible a nivel del protocolo. Para las integraciones comerciales de servidor a servidor o de alto riesgo, configura TLS mutua (mTLS) en la puerta de enlace de entrada de Apigee.
• Usa las políticas de VerifyJWT y VerifyJWS para exigir que los tokens entrantes tengan una firma criptográfica válida antes de que se procese la solicitud. Usa técnicas estándar de OAuth y considera implementar HMAC, hash de carga útil, validación de estado o nonce, y clave de prueba para el intercambio de código (PKCE) para proteger criptográficamente cada solicitud.
• Enmascara los datos sensibles para que se encripten y oculten cuando uses la herramienta de depuración de Apigee.

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Implementa políticas de protección contra amenazas de Apigee para sanear los parámetros de entrada y bloquear los intentos de inyección de SQL, NoSQL y comandos en la capa de puerta de enlace:
  • JSONThreatProtection
  • XMLThreatProtection
  • RegularExpressionProtection
  • SOAPMessageValidation

Revisa las siguientes prácticas recomendadas para A06: Diseño no seguro:

• Valida las solicitudes entrantes con la política OASValidation para los mensajes de solicitud o respuesta entrantes con la especificación de OpenAPI.
• Implementa la política de SpikeArrest y la política de Quota para mitigar los aumentos repentinos de tráfico y la sobrecarga del backend.
• Usa reglas de manejo de fallas para interceptar errores de backend (como una falla en la base de datos) y reescribirlos en respuestas HTTP genéricas.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Implementa la validación de claves de API para tus APIs orientadas a desarrolladores, de modo que Apigee pueda verificar si la clave de API de una aplicación cliente está presente, es válida y está autorizada para acceder al recurso de la API solicitado.
• Para evitar el robo de tokens de sesión y los ataques de reproducción, implementa la Demostración de prueba de posesión (DPoP). DPoP vincula los tokens a la clave pública del remitente para mitigar la reproducción de tokens.
• Combina los límites de velocidad de SpikeArrest con la integración de reCAPTCHA Enterprise para proteger los extremos de generación de tokens y de acceso contra ataques automatizados de fuerza bruta.

Revisa las siguientes prácticas recomendadas para A09: Errores de registro y alertas de seguridad:

• Transmite de forma asíncrona metadatos estructurados de transacciones de API a Logging o a SIEM de terceros. Adjunta tu política de MessageLogging a PostClientFlow, que se ejecuta después de que se entrega la respuesta al cliente.
• Centraliza los registros de auditoría de la plataforma para hacer un seguimiento de las modificaciones en los proxies de API, las credenciales y los entornos de implementación. Para evitar que las modificaciones no autorizadas del proxy pasen desapercibidas, integra Apigee con los Registros de auditoría de Cloud. Para obtener más información, consulta Registros de auditoría de Apigee y Registros de auditoría de la administración de la API de Apigee.
• Configura alertas de Advanced API Security en Monitoring para notificar a los equipos de SecOps sobre las campañas de scraping automatizadas, el abuso de credenciales y las regresiones de la puntuación de seguridad.
• Para proteger las variables proporcionadas por el usuario en las plantillas de mensajes de registro, inclúyelas en la función escapeJSON().
• Si transmites metadatos de registros a un SIEM externo, configura la política MessageLogging para que use Syslog a través de TLS (puerto TCP 6514) y, así, encriptar tus datos en tránsito.

Artifact Registry y Artifact Analysis

Artifact Registry es un único lugar para que tu organización administre imágenes de contenedores y paquetes de lenguajes. Artifact Analysis proporciona análisis de vulnerabilidades integrados, generación de listas de materiales de software (SBOM) y almacenamiento de metadatos para los artefactos almacenados en Artifact Registry.

Se aplica a lo siguiente:

• A03: Fallas en la cadena de suministro de software
• A08: Fallas de integridad de software o datos

Revisa las siguientes prácticas recomendadas para A03: Fallas en la cadena de suministro de software:

• Configura políticas de limpieza para borrar imágenes de versiones candidatas obsoletas, sin etiquetar o sin versiones después de un período de retención predefinido, lo que reduce la superficie de ataque y ayuda a evitar la implementación de imágenes heredadas vulnerables.
• Configura repositorios virtuales con prioridades de repositorios de nivel superior que prioricen los repositorios de artefactos internos por sobre los registros públicos para protegerte contra ataques de confusión de dependencias.
• Aplica etiquetas de imagen inmutables o implementa estrictamente por resumen criptográfico (sha256:...) para evitar ataques de mutación de etiquetas.

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Habilita el análisis automático de vulnerabilidades y la generación de SBOM en Artifact Analysis para detectar CVEs críticas antes de la implementación.
• Integra los metadatos de Artifact Analysis con las certificaciones de la autorización binaria para bloquear la implementación de imágenes que no superen los umbrales de seguridad.

Assured OSS

Assured OSS te permite incorporar los paquetes de OSS que Google valida y usa en tus propios flujos de trabajo de desarrollador.

Se aplica a lo siguiente:

• A03: Fallas en la cadena de suministro de software
• A08: Fallas de integridad de software o datos

Revisa las siguientes prácticas recomendadas para A03: Fallas en la cadena de suministro de software:

• Configura repositorios remotos para que apunten de forma ascendente a Assured OSS.
• Verifica que las bibliotecas de código abierto en tus compilaciones contengan una firma de Google válida y un registro verificable de procedencia de compilación de SLSA. Configura puntos de control de calidad en Cloud Build para verificar estas certificaciones antes de compilar los archivos binarios de la aplicación.
• Configura los administradores de paquetes (como pip.conf, settings.xml o build.gradle) en tus imágenes base de Cloud Workstations para que apunten solo a tus repositorios internos de Assured OSS.
• Usa los metadatos que genera Assured OSS para determinar si una CVE divulgada recientemente en un paquete de código abierto se puede aprovechar en tu contexto de implementación específico.

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Promueve la integridad de los paquetes en las canalizaciones de compilación configurando repositorios virtuales upstream en Artifact Registry para aplicar firmas criptográficas verificadas por Google.
• Usa el nivel Premium de Assured OSS (parte de Security Command Center Premium) para automatizar el aprovisionamiento de repositorios, acceder a paquetes de JavaScript (npm) seleccionados y obtener acceso a metadatos de paquetes y notificaciones de vulnerabilidades.

Autorización binaria

La Autorización binaria verifica la integridad de los contenedores para que solo se implementen imágenes de contenedor confiables. Puedes crear políticas para permitir o denegar implementaciones en función de la presencia o ausencia de certificaciones. La Autorización binaria aplica políticas a nivel del clúster, por lo que puedes configurar políticas diferentes para entornos diferentes.

Se aplica a lo siguiente:

• A03: Fallas en la cadena de suministro de software
• A08: Fallas de integridad de software o datos

Revisa las siguientes prácticas recomendadas para A03: Fallas en la cadena de suministro de software:

• Configura canalizaciones de implementación para hacer referencia a imágenes de contenedor y aplicarlas por su resumen criptográfico SHA-256 único e inmutable (como @sha256).
• Implementa la Validación continua de la Autorización binaria en tus clústeres de GKE para supervisar los Pods activos en función de la política de tu plataforma y generar alertas en Logging si los contenedores en ejecución ya no cumplen con los requisitos.

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Aplica la generación de certificación automatizada en tus canalizaciones de Cloud Build o GitHub Actions. Crea requisitos de certificación progresiva para que las imágenes pasen por puertas de validación secuenciales a medida que se acercan a la producción.
• Para los incidentes de producción de alta gravedad, habilita las implementaciones de emergencia de breakglass. Configura políticas de alertas de Monitoring en eventos de registro de auditoría de breakglass para notificar a tu equipo de Operaciones de seguridad cuando se produzca una omisión de admisión.

Administrador de certificados y servicios de CA

Certificate Authority Service (servicio de CA) simplifica la implementación y administración de autoridades certificadoras (CA) privadas. El Administrador de certificados proporciona aprovisionamiento, renovación y administración centralizados de certificados TLS para Cloud Load Balancing y Cloud CDN.

Se aplica a A04: Fallas criptográficas.

Revisa las siguientes prácticas recomendadas:

• Usa CA Service para automatizar la emisión y la administración del ciclo de vida de los certificados privados. Implementa entidades certificadoras raíz e intermedias respaldadas por Cloud HSM para proteger las claves privadas y usa plantillas de certificados para aplicar políticas criptográficas (como longitudes mínimas de claves y usos de claves extendidos permitidos).
• Habilita los Registros de auditoría de Cloud para supervisar los eventos administrativos de alto riesgo (como la revocación de la CA, las actualizaciones de políticas o un aumento repentino en las solicitudes de certificados). Dirige las alertas a Google SecOps para detectar posibles amenazas internas o canalizaciones de CI/CD vulneradas.
• Configura el Administrador de certificados para que use certificados administrados por Google vinculados con autorizaciones de DNS. Administrador de certificados valida la propiedad del dominio, emite el certificado X.509 y controla las renovaciones 30 días antes del vencimiento.
• Adjunta mapas de certificados a proxies HTTPS de destino para habilitar la selección dinámica y la rotación de certificados sin necesidad de reiniciar los proxies ni volver a configurar balanceador de cargas.
• Para los microservicios internos o el balanceo de cargas híbrido, configura mapas de certificados para emitir certificados privados directamente desde un grupo de CA privado del servicio de CA.
• Configura mapas de certificados para que coincidan las solicitudes entrantes de indicación de nombre del servidor (SNI) con certificados específicos.

Cloud Asset Inventory

Cloud Asset Inventory te permite supervisar tu infraestructura en Google Cloud para detectar infraestructura de TI no autorizada o huérfana.

Se aplica a A02: Configuración incorrecta de seguridad.

Revisa las siguientes prácticas recomendadas:

• Configura notificaciones para recibir alertas de recursos en ejecución inesperados que podrían estar protegidos de forma inadecuada o usar software obsoleto.
• Usa el Analizador de políticas de IAM para descubrir controles de acceso mal configurados, como buckets de almacenamiento públicos con el permiso allUsers, roles de cuentas de servicio con privilegios excesivos o identidades huérfanas.
• Exporta instantáneas de recursos a BigQuery para auditar las configuraciones de infraestructura a lo largo del tiempo y mantener un registro de cumplimiento de referencia en entornos de varios proyectos.

Cloud Armor

Cloud Armor es un firewall de aplicación web (WAF) adaptable que implementas en el perímetro de tu Google Cloud red Google Cloud para ayudar a protegerte contra ataques DSD y bloquear cargas útiles de inyección de SQLi o XSS. Cloud Armor incluye reglas de WAF preconfiguradas para defenderse de las vulnerabilidades de OWASP Top 10, limitar la superficie de ataque de tus extremos de autenticación y bloquear las credenciales comprometidas.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A05: Inyección
• A07: Fallas de autenticación
• A08: Fallas de integridad de software o datos
• A10: Manejo inadecuado de condiciones excepcionales

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Aplica reglas de WAF preconfiguradas, como evaluatePreconfiguredWaf('lfi-stable'), para bloquear las inclusiones de archivos locales y los ataques de salto de directorio.
• Aplica controles de acceso geográficos (también conocidos como geovallas) configurando una regla de política de seguridad que coincida con el tráfico entrante según el código de país de origen con el atributo origin.region_code.
• Bloquea las direcciones IP maliciosas conocidas con un feed de inteligencia contra amenazas.
• Escribe una regla de coincidencia para restringir el acceso externo a URLs sensibles (como /admin, /login o /config).
• Habilita la normalización de rutas de Cloud Armor en tu balanceador de cargas, lo que obliga a Cloud Armor a decodificar y estandarizar las URLs entrantes antes de evaluar tus políticas de seguridad.

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Detecta y bloquea la inyección de SQL (sqli-v422-stable), las secuencia de comandos entre sitios (xss-v422-stable), la inyección de comandos PHP (php-v422-stable) y la inyección de Java (java-v422-stable) en el perímetro de la red.
• Ajusta las reglas de WAF preconfiguradas a diferentes niveles de sensibilidad para abordar los falsos positivos antes de configurar las reglas para rechazar el tráfico de forma activa.
• Habilita la regla de ejecución de código remoto (RCE) y la regla de inclusión de archivos remotos (RFI) preconfiguradas (rce-v422-stable y rfi-v422-stable, respectivamente) para detectar técnicas adicionales y complejas de inyección de comandos.
• Para ataques de inserción que no sean de SQL o PHP, crea reglas personalizadas. Las reglas personalizadas te permiten bloquear solicitudes cuando se usan palabras clave o patrones de escape específicos en los protocolos en la ruta de la solicitud o consulta.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Restringe el acceso a los extremos de autenticación y administración a las direcciones IP o los países autorizados.
• Habilita evaluatePreconfiguredWaf para interceptar y bloquear solicitudes diseñadas para aprovechar vulnerabilidades de estado de sesión y secuestro de sesión.
• Usa la API de securityPolicies.patchRule para bloquear cualquier solicitud entrante que contenga un parámetro comprometido en la cadena de consulta o los encabezados en el borde de la red.

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Restringe los extremos que aceptan objetos serializados de alto riesgo de fuentes no confiables a un conjunto de direcciones IP de confianza con una regla de denegación similar a la siguiente:

  request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')
  

• Implementa reglas personalizadas para inspeccionar las palabras clave del cuerpo de la solicitud en busca de patrones de ejecución específicos del idioma y firmas de deserialización no seguras.

Revisa las siguientes prácticas recomendadas para el cargo A10: Mishandling of Exceptional Conditions:

• Habilita la Protección adaptable de Google Cloud Armor en tus políticas de seguridad para establecer patrones de tráfico normales como referencia, configurar alertas sobre anomalías de capa 7 y generar reglas de WAF segmentadas con firmas de ataque.
• Configura reglas de límite de frecuencia de Cloud Armor en los extremos críticos (por ejemplo, las APIs de /login, /checkout o de búsqueda). Las reglas de limitación de frecuencia limitan las solicitudes según la dirección IP del cliente o el encabezado HTTP (por ejemplo, limitan a los clientes a 100 solicitudes por minuto) y devuelven un código de estado HTTP 429 Too Many Requests.
• Establece la regla predeterminada de prioridad más baja en tu política de seguridad de Cloud Armor como Deny (código de estado: 403 o 404).

Cloud Build y Cloud Deploy

Cloud Build y Cloud Deploy proporcionan una canalización de integración continua y entrega continua (CI/CD) integrada y segura enGoogle Cloud. Cloud Build compila artefactos con provenance verificable de SLSA y certificaciones criptográficas, y Cloud Deploy administra lanzamientos progresivos, aprobaciones de destino y verificaciones automatizadas en GKE y Cloud Run.

Se aplica a lo siguiente:

• A03: Fallas en la cadena de suministro de software
• A08: Fallas de integridad de software o datos

Revisa las siguientes prácticas recomendadas para A03: Fallas en la cadena de suministro de software:

• Configura requestedVerifyOption: VERIFIED en tu archivo cloudbuild.yaml para requerir procedencia verificable.
• Implementa grupos privados de Cloud Build que se intercambien con tu red de VPC privada para compilaciones empresariales sensibles.
• Configura activadores de compilación para que se ejecuten en cuentas de servicio dedicadas administradas por el usuario. Otorga a estas cuentas de servicio solo los permisos de IAM mínimos necesarios (como escritor de Artifact Registry [roles/artifactregistry.writer] y escritor de registros [roles/logging.logWriter]).
• Exige aprobaciones manuales en los activadores de Cloud Build que segmentan entornos de etapa de pruebas o producción.
• Restringe las herramientas de compilación de CI (como Cloud Build, GitHub Actions o GitLab) al rol de Cloud Deploy Releaser (roles/clouddeploy.releaser) para que las canalizaciones de compilación solo puedan crear versiones.
• Para solicitar aprobaciones manuales, configura tu manifiesto de canalización de entrega (delivery-pipeline.yaml) con requireApproval: true en tus destinos de etapa de pruebas y producción.
• Configura entornos de ejecución con cuentas de servicio específicas del destino (por ejemplo, una cuenta de servicio con permisos limitados al espacio de nombres de la etapa de pruebas y una cuenta de servicio independiente y auditada para la producción).
• Implementa hooks personalizados para ejecutar aserciones de seguridad fuera de banda durante el ciclo de vida del lanzamiento. Usa hooks previos a la implementación para verificar si los clústeres de destino satisfacen los valores de referencia de cumplimiento y hooks posteriores a la implementación para iniciar análisis automatizados de vulnerabilidades en los extremos de contenedores activos.

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Integra Cloud Build con Cloud KMS y Artifact Analysis para crear y firmar certificaciones criptográficas cuando las pruebas de unidades y las pruebas de análisis estático se completen correctamente.
• Usa resúmenes criptográficos SHA-256 inmutables (por ejemplo, golang@sha256:...) en los pasos del compilador en cloudbuild.yaml.
• Almacena las configuraciones de compilación en repositorios con control de versión protegidos por reglas de protección de ramas (como exigir revisiones de dos personas en las solicitudes de extracción). Restringe los permisos de modificación de activadores a los administradores de plataformas autorizados que usan cuentas de servicio administradas por el usuario.
• Promueve manifiestos de implementación idénticos y renderizados previamente, y resúmenes de imágenes de contenedor inmutables en las etapas de destino sin permitir que las canalizaciones de CI alteren los manifiestos entre la etapa de pruebas y la producción.
• Define tareas de verificación de implementación automatizadas dentro de tu manifiesto skaffold.yaml. Cloud Deploy ejecuta estos contenedores de verificación después de que se implementan los Pods para ejecutar verificaciones de estado dinámicas, pruebas de integración y aserciones de contrato de API.
• Usa estrategias de implementación de versiones canary. Si falla una prueba de verificación de Skaffold o si la supervisión detecta umbrales de anomalías durante una fase de lanzamiento Canary, Cloud Deploy detiene el lanzamiento y revierte el tráfico a la última versión buena conocida.
• Configurar clústeres de GKE y Cloud Run para aplicar políticas de Autorización Binaria Cuando Cloud Deploy aplica los manifiestos, el controlador de admisión de destino verifica de forma criptográfica los resúmenes de las imágenes de contenedor y rechaza los artefactos no confiables.

Cloud Identity y llaves de seguridad Titan

Cloud Identity proporciona administración centralizada de identidades, ciclo de vida de credenciales y acceso en Google Cloudy Google Workspace. Las llaves de seguridad Titan son dispositivos de seguridad basados en hardware y resistentes al phishing que usan criptografía de clave pública basada en los estándares FIDO2 o WebAuthn.

Se aplica a A07: Fallas de autenticación.

Revisa las siguientes prácticas recomendadas:

• Para protegerte contra los ataques de phishing de persona en el medio (PITM), configura la verificación en 2 pasos (2SV) y establece el método permitido como Solo llaves de seguridad (FIDO2, WebAuthn o llaves de seguridad Titan).
• Configura el inicio de sesión único (SSO) basado en SAML 2.0 o OIDC con tu proveedor de identidad corporativo junto con el aprovisionamiento automático.
• Establece la política de duración de la sesión en un umbral máximo bajo para obligar a los usuarios a volver a autenticarse de forma periódica.Google Cloud
• Registra las llaves de seguridad Titan como llaves de acceso para habilitar la autenticación sin contraseña, lo que reduce significativamente los riesgos de ataques de fuerza bruta y de vulneración de credenciales.
• Exige la 2FA con llaves de seguridad Titan para tus identidades privilegiadas (como los propietarios de proyectos, los administradores de facturación y los equipos de SecOps) aplicando políticas de llaves de seguridad en Cloud Identity. Inscribe a los usuarios de alto riesgo en el Programa de Protección Avanzada.

Cloud KMS

Cloud KMS administra claves criptográficas simétricas y asimétricas para servicios Google Cloud compatibles y en tus propias aplicaciones. Puedes generar, usar, rotar y destruir claves criptográficas para la encriptación simétrica, la firma asimétrica, la encriptación asimétrica y la firma de MAC.

Se aplica a A04: Fallas criptográficas.

Revisa las siguientes prácticas recomendadas:

• Usa Autokey de Cloud KMS para automatizar el aprovisionamiento y la asignación. Con Autokey, no necesitas aprovisionar llaveros de claves, claves y cuentas de servicio con anticipación. En cambio, las claves y los llaveros de claves se generan a pedido como parte de la creación de recursos.
• Usa claves de Cloud KMS para encriptar cargas útiles sensibles antes de que se envíen a buckets de almacenamiento o bases de datos. Puedes usar la API o las bibliotecas cliente de Cloud KMS para usar tus claves de Cloud KMS para la encriptación del cliente.
• Verifica la integridad de los datos de extremo a extremo validando las sumas de verificación durante el tránsito.
• Para cargas de trabajo estrictas de cumplimiento y regulatorias, almacena y ejecuta tus operaciones criptográficas con Cloud HSM. Cloud HSM almacena tus claves en módulos de seguridad de hardware validados según el nivel 3 del estándar FIPS 140-3.
• Configura programas de rotación de claves automática en un período determinado (por ejemplo, cada 90 días).

Cloud Load Balancing

Cloud Load Balancing es un servicio administrado, definido por software y completamente distribuido que distribuye el tráfico de usuarios en varias instancias y regiones de backend.

Se aplica a lo siguiente:

• A04: Fallas criptográficas
• A10: Manejo inadecuado de condiciones excepcionales

Revisa las siguientes prácticas recomendadas para A04: Fallas criptográficas:

• Configura y asigna políticas de SSL personalizadas al frontend de tu balanceador de cargas para restringir las negociaciones a TLS 1.3 o a perfiles seguros de TLS 1.2, y para inhabilitar conjuntos de cifrado débiles.

Revisa las siguientes prácticas recomendadas para el cargo A10: Mishandling of Exceptional Conditions:

• Configura tu balanceador de cargas de aplicaciones externo con páginas de respuesta de error personalizadas para interceptar los códigos de error del backend y entregar respuestas de error estandarizadas en HTML o JSON.
• Implementa servicios de backend multirregionales con conmutación por error entre regiones para que el tráfico se pueda redireccionar a regiones secundarias si se producen interrupciones o fallas del sistema no controladas.

Google Cloud Observability (Logging, Monitoring y Error Reporting)

Google Cloud Observability proporciona administración de registros de pila completa con Logging, métricas y alertas con Monitoring, y seguimiento de fallas de aplicaciones en tiempo real con Error Reporting.

Se aplica a lo siguiente:

• A09: Errores de registro y alertas de seguridad
• A10: Manejo inadecuado de condiciones excepcionales

Revisa las siguientes prácticas recomendadas para A09: Errores de registro y alertas de seguridad:

• Habilita los registros de acceso a los datos para los repositorios de datos valiosos (como Cloud Storage, BigQuery y Spanner) que almacenan datos sensibles. Los registros de acceso a los datos te permiten auditar cada evento de lectura, escritura y consulta de datos sensibles.
• Aplica el bloqueo del bucket y las políticas de retención para el bucket de registro personalizado, de modo que se impida que los atacantes o los administradores no autorizados borren los registros para ocultar sus actividades.
• Usa receptores agregados para recopilar y enrutar las entradas de registro a un único repositorio central para tus equipos de SecOps. Configura receptores agregados de interceptación para evitar almacenar registros de gran volumen, como los registros de acceso a los datos, en más de un lugar.
• Configura políticas de alertas basadas en registros para los indicadores críticos de vulneración, como los errores de IAM de permiso denegado, las creaciones inesperadas de claves de API o los cambios repentinos en la configuración del firewall.
• Implementa políticas de alertas basadas en registros en el Explorador de registros o en Monitoring. Especifica filtros exactos que se dirijan a eventos de gravedad alta, como modificaciones no autorizadas de políticas de IAM o revocaciones de claves de KMS, de modo que se genere una notificación de incidente cuando se ingrese una entrada de registro coincidente.
• Crea métricas de contador basadas en registros en Logging para convertir las entradas de registro coincidentes en datos de series temporales. Luego, crea una política de alertas basada en métricas en Monitoring que inicie un incidente cuando la tasa supere un umbral específico (por ejemplo, más de 50 intentos de acceso fallidos en cinco minutos).
• Configura políticas de alertas basadas en registros que supervisen las llamadas administrativas a la API de Cloud Logging y generen alertas sobre modificaciones inesperadas en los receptores de exportación de registros o sobre eliminaciones de bucket.
• Configura canales de notificaciones con plantillas de documentación claras. Incluye vínculos directos a la consulta del Explorador de registros, procedimientos operativos estándar (SOP) para el ingeniero de guardia y pasos de corrección explícitos para ayudar a contener rápidamente los incidentes.

Revisa las siguientes prácticas recomendadas para el cargo A10: Mishandling of Exceptional Conditions:

• Integra los SDKs de Error Reporting directamente en el código de tu aplicación o configura Logging para analizar formatos de excepción JSON estructurados.
• Configura los canales de notificación de Error Reporting o las políticas de alertas de Monitoring para notificar a tus equipos de SecOps cuando aparezca una nueva clase de excepción.

Cloud NGFW

Cloud NGFW es un servicio de firewall administrado que permite la inspección con estado y el control de aplicaciones de capa 7 para el tráfico de norte a sur y de este a oeste.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A05: Inyección

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Aplica la microsegmentación de red con políticas de firewall de red globales y etiquetas de recursos administradas por IAM para aislar los niveles de aplicaciones de backend y restringir la comunicación este-oeste entre subredes.
• Usa listas de inteligencia contra amenazas que mantiene Google en las reglas de firewall para bloquear las conexiones entrantes que se originan en agentes maliciosos conocidos, servidores de C2 y botnets comprometidas.

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Configura el servicio de detección y prevención de intrusiones con un grupo de perfiles de seguridad que rechace las amenazas que coincidan con las firmas de inyección de SQL, inyección de comandos del SO y aprovechamiento de ejecución de código remoto.
• Configura la inspección de TLS de Cloud NGFW para desencriptar el tráfico HTTPS entrante y saliente, aplicar verificaciones de firmas de inserción de IPS a la carga útil de texto simple y volver a encriptar la sesión antes de la entrega al backend.
• Aplica reglas de firewall de salida basadas en FQDN en las bases de datos de backend y las subredes de Compute. Restringe las conexiones externas a dominios externos aprobados y predefinidos para evitar que las aplicaciones vulnerables creen shells inversos no autorizados.
• Habilita el registro de reglas de firewall en los perfiles de prevención de amenazas y enruta estos registros a Google SecOps para correlacionar las firmas de inyección de red bloqueadas con la telemetría a nivel del host, lo que permite identificar las cargas de trabajo objetivo para la aplicación de parches prioritaria.

Cloud Workstations

Cloud Workstations proporciona entornos de desarrollo administrados en Google Cloud con seguridad integrada y personalizaciones.

Se aplica a lo siguiente:

• A03: Fallas en la cadena de suministro de software
• A04: Fallas criptográficas

Revisa las siguientes prácticas recomendadas para A03: Fallas en la cadena de suministro de software:

• Crea imágenes de contenedores básicos personalizados almacenadas en Artifact Registry que preinstalen herramientas de seguridad, extensiones de desarrolladores de confianza y tiempos de ejecución de lenguajes aprobados.
• Implementa tus clústeres de estaciones de trabajo con entrada y salida de IP privadas, y dentro de un perímetro de Controles del servicio de VPC.
• Configura Cloud Workstations para enrutar el tráfico de la sesión a través del IAP. Exige que los desarrolladores se autentiquen con credenciales corporativas con la autenticación de varios factores (MFA) habilitada y aplica roles con privilegios mínimos (por ejemplo, Usuario de Cloud Workstations (roles/workstations.user)).
• Configura estaciones de trabajo con límites de tiempo de espera bajos (por ejemplo, detención automática después de dos horas de inactividad). Cuando se reinicia una estación de trabajo, Cloud Workstations extrae la imagen del contenedor más reciente con parches de seguridad para que los desarrolladores puedan trabajar en un entorno limpio.

Revisa las siguientes prácticas recomendadas para A04: Fallas criptográficas:

• Configura tu estación de trabajo para encriptar los discos persistentes conectados con CMEK.

CodeMender

CodeMender es un agente de ingeniería de IA autónomo y especializado. CodeMender puede aplicar parches a las vulnerabilidades recién descubiertas y reescribir el código heredado existente para abordar las vulnerabilidades existentes. Puedes instalar y configurar CodeMender en Gemini Enterprise Agent Platform.

Se aplica a lo siguiente:

• A03: Fallas en la cadena de suministro de software
• A05: Inyección
• A06: Diseño no seguro

Revisa las siguientes prácticas recomendadas para A03: Fallas en la cadena de suministro de software:

• Integra la CLI de CodeMender en los espacios de trabajo locales de los desarrolladores y las canalizaciones de CI/CD para analizar los módulos objetivo, verificar la capacidad de explotación y detectar las debilidades de seguridad antes de que se confirme el código.
• Importa informes de análisis de composición de software (SCA) y de vulnerabilidades de dependencias en CodeMender para ejecutar verificaciones de exploits de prueba de concepto y filtrar los falsos positivos antes de la revisión del desarrollador.

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Ejecutamos la generación automática de parches en zonas de pruebas locales aisladas para reescribir la lógica vulnerable (por ejemplo, para sanear las entradas). Verifica que las pruebas de unidades se aprueben y que las PoC ya no sean explotables antes de crear solicitudes de extracción.

Revisa las siguientes prácticas recomendadas para A06: Diseño no seguro:

• Refactoriza la lógica de código arquitectónico heredado o no seguro con el motor de parches iterativo de CodeMender, que proporciona restricciones de codificación explícitas para aplicar patrones de diseño seguros en todos los módulos de la aplicación.
• Mantén la revisión humana para las solicitudes de extracción y las diferencias generadas por CodeMender para verificar que los cambios propuestos se alineen con tus lineamientos de programación segura.

Confidential Computing

Confidential Computing ayuda a proteger los datos en uso manteniéndolos encriptados en la memoria mientras se procesan. Con los entornos de ejecución confiable (TEE) basados en hardware, Confidential Computing ayuda a garantizar que el hipervisor, el sistema operativo host o los administradores de infraestructura no puedan acceder a tus datos sensibles ni a tus claves criptográficas.

Se aplica a A04: Fallas criptográficas.

Revisa las siguientes prácticas recomendadas:

• Usa Confidential VMs o Confidential Google Kubernetes Engine Nodes para cargas de trabajo altamente sensibles (como PII, registros financieros o pesos de modelos de IA propietarios).
• Cuando varias organizaciones deben agrupar datos sensibles para el análisis o el entrenamiento de IA (sin exponer los datos sin procesar entre sí), usa Confidential Space para aplicar la certificación criptográfica y el aislamiento de datos.

Firebase (Firebase Authentication, Verificación de aplicaciones de Firebase y reglas de seguridad de Firebase)

Firebase proporciona controles de seguridad enfocados en los desarrolladores en cuanto a identidad, certificación de clientes y acceso a bases de datos. Firebase Authentication controla la identidad del usuario y la administración de sesiones, App Check valida la integridad de la app cliente y las reglas de seguridad de Firebase aplican el control de acceso basado en atributos y la validación de esquemas para Firestore y Cloud Storage.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A05: Inyección
• A07: Fallas de autenticación
• A08: Fallas de integridad de software o datos

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Limita las lecturas y escrituras al ID del usuario autenticado en las reglas de seguridad de Firebase. Nunca uses reglas predeterminadas permisivas, como allow read, write: if true;.
• Para los roles administrativos, usa los SDKs de Firebase Admin para establecer reclamaciones personalizadas en los tokens de ID de los usuarios y valida esas reclamaciones en tus reglas de seguridad en lugar de permitir escrituras de perfil del cliente.
• Aplica App Check en las reglas de seguridad de Firebase para bloquear el acceso de clientes no autenticados o suplantados en la capa de la base de datos.

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Aplica la validación estructural de cargas útiles en las reglas de seguridad verificando los tipos de campos de documentos entrantes, las longitudes de cadenas y los tamaños de objetos para rechazar cargas útiles de escritura mal formadas o maliciosas antes de la transferencia a la base de datos.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Actualiza a Firebase Authentication con Identity Platform para habilitar protecciones empresariales, como la MFA con TOTP y las funciones de bloqueo.
• Verifica los tokens de ID de Firebase en tu backend con el SDK de Firebase Admin antes de otorgar acceso a los datos sensibles de la aplicación.
• Usa el proveedor de depuración para generar tokens de depuración temporales y con alcance para tus desarrolladores y canalizaciones de CI/CD en entornos de etapa de pruebas.

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Aplicar proveedores de certificación respaldados por hardware para verificar la integridad del cliente Configura la Verificación de aplicaciones para usar Play Integrity de Android y App Attest de Apple.
• Implementa el software intermedio de verificación de tokens de Verificación de aplicaciones en los backends de la API de Cloud Run y API de Kubernetes Engine para rechazar las solicitudes que se originan en claves de API extraídas, secuencias de comandos automatizadas o entornos emulados.

Fraud Defense

Fraud Defense es una plataforma unificada para la defensa contra fraudes y abusos, que incluye protección contra bots, cuentas y transacciones para la Web. reCAPTCHA, una oferta que forma parte de Fraud Defense, filtra los bots y otras formas de automatización y tráfico masivo mediante la puntuación del nivel de riesgo de los intentos de acceso.

Se aplica a A07: Fallas de autenticación.

Revisa las siguientes prácticas recomendadas:

• Integra reCAPTCHA con tu WAF existente, como Google Cloud Armor, para emitir desafíos automatizados o bloquear el tráfico de bots de alto riesgo antes de que las solicitudes lleguen a los extremos de autenticación.
• Defiende las cuentas en los endpoints de acceso, restablecimiento de contraseñas y renovación de sesiones. Obtén puntuaciones de riesgo de apropiación de cuentas (ATO) basadas en las velocidades de acceso del usuario y las huellas digitales del dispositivo.
• Defiéndete del fraude de cargos telefónicos por SMS en los formularios de registro y de 2FA evaluando los perfiles de riesgo de los números de teléfono antes de enviar mensajes SMS salientes.
• Para reducir los falsos positivos y entrenar modelos de evaluación de riesgos específicos del sitio, anota y envía comentarios sobre las transacciones con regularidad.
• Verifica las contraseñas durante los flujos de acceso de usuarios y creación de cuentas para detectar si las credenciales enviadas aparecen en las bases de datos de violación de la seguridad de los datos de terceros en la Web.

Google SecOps

Google Security Operations es una plataforma de operaciones de seguridad que combina el análisis de telemetría de seguridad (SIEM), la organización, automatización y respuesta de seguridad (SOAR) y la inteligencia contra amenazas de Mandiant de primera línea en una sola plataforma.

Se aplica a lo siguiente:

• A02: Configuración incorrecta de seguridad
• A09: Errores de registro y alertas de seguridad

Revisa las siguientes prácticas recomendadas para A02: Configuración de seguridad incorrecta:

• Transfiere los hallazgos de Security Command Center a Google SecOps para combinar los hallazgos de configuración incorrecta estática (por ejemplo, PUBLIC_BUCKET_ACL o CMEK_DISABLED) con la telemetría de red y firewall en tiempo real.
• Crea guías de respuesta de SOAR automatizadas para ejecutar acciones de contención.
• Usa Gemini para acelerar la clasificación de errores de configuración y recibir resúmenes sintetizados de los recursos mal configurados, los roles de IAM adjuntos y la orientación paso a paso para la corrección.

Revisa las siguientes prácticas recomendadas para A09: Errores de registro y alertas de seguridad:

• Normaliza la telemetría de registros en el modelo de datos unificado (UDM) para habilitar la búsqueda y la correlación rápidas y estandarizadas en múltiples nubes sin la sobrecarga del análisis de registros sin procesar.
• Escribe reglas de detección de YARA-L 2.0 para supervisar los cambios de configuración de alto riesgo, como la inhabilitación del Acceso al SO, el borrado de receptores de Logging o las modificaciones en los perímetros de los Controles del servicio de VPC.
• Usa las detecciones seleccionadas de Applied Threat Intelligence para evaluar tus datos de eventos en comparación con los datos de Mandiant Threat Intelligence.
• Usa Gemini en Google SecOps para generar reglas de detección de YARA-L a partir de descripciones en lenguaje natural y resumir cronogramas de incidentes complejos y de varias etapas en resúmenes ejecutivos de incidentes.

Identity-Aware Proxy

IAP crea una capa de autorización central para las aplicaciones a las que se accede a través de HTTPS y conexiones TCP administrativas. IAP verifica la identidad y el contexto del usuario antes de otorgar acceso a los recursos de Cloud Run, App Engine, Compute Engine, GKE y locales.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A07: Fallas de autenticación

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Aplica controles de acceso detallados a aplicaciones web, VMs, Google Cloud APIs y aplicaciones de Google Workspace según la identidad del usuario, la pertenencia a un grupo y el contexto de la solicitud.
• Integra Agent Gateway para aplicar controles de acceso a las identidades de tus agentes.
• Usa el reenvío de TCP de IAP para establecer túneles HTTPS encriptados a tus instancias de backend y quitar los extremos SSH (puerto 22) y RDP (puerto 3389) orientados a Internet.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Autentica a los usuarios que acceden a interfaces administrativas y aplicaciones web a través de IAP con identidades aprovisionadas en IAM o Cloud Identity.
• Verifica la aserción del JWT firmado dentro del encabezado x-goog-iap-jwt-assertion en la capa de la aplicación. Valida la firma con las claves públicas de Google y verifica que la reclamación del público (aud) coincida con el ID de tu servicio de backend.
• Para evitar que los atacantes eludan la autenticación de IAP, configura los parámetros de entrada de Cloud Run para permitir solo el tráfico interno y de Cloud Load Balancing, y bloquea el acceso público directo a las URLs de tu contenedor de backend. En el caso de las VMs o los nodos de GKE, configura reglas de firewall de VPC para aceptar solo el tráfico de entrada que se origine en los rangos de IP del balanceador de cargas.

Identity and Access Management

Identity and Access Management (IAM) te permite administrar el acceso detallado a los servicios y recursos en Google Cloud. IAM incluye funciones como las siguientes:

• Privileged Access Manager, que administra la elevación de privilegios temporal y a pedido para recursos Google Cloud sensibles
• La federación de identidades para cargas de trabajo permite que las cargas de trabajo accedan a los recursos de Google Cloud con una identidad federada.
• Federación de identidades de personal, que permite a los usuarios acceder a recursos de Google Cloud con una identidad federada

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A07: Fallas de autenticación

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Usa roles predefinidos o personalizados (no roles básicos) para restringir los permisos a necesidades específicas de recursos o usuarios.
• Restringe los permisos para otorgar los roles de usuario de cuenta de servicio (roles/iam.serviceAccountUser) y creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator).
• Usa el Recomendador de IAM para analizar los registros de uso activos de tu organización y quitar las cuentas con privilegios excesivos.
• Escribe condiciones de IAM en tus vinculaciones de roles para agregar autorización adaptada al contexto y restringir el acceso por fecha, hora del día o dirección IP de origen.
• Implementa políticas de límite de acceso de la entidad (PAB) para definir las organizaciones, las carpetas o los proyectos a los que puede acceder un conjunto de entidades. Si un atacante roba una sesión activa o si se otorgan accidentalmente funciones de IAM amplias a una cuenta de servicio, PAB bloquea el acceso si el recurso especificado está fuera del límite designado de la identidad.
• Adjunta políticas de denegación de IAM a nivel de la organización o de la carpeta para bloquear permisos de alto riesgo (como iam.serviceAccountKeys.create o resourcemanager.projects.delete).
• Cuando configures reglas de denegación de IAM, declara un grupo de seguridad de breakglass dedicado en la lista exceptionPrincipals. Usa etiquetas de recursos en tus condiciones de rechazo (como resource.matchTag('env', 'prod')) para que se bloqueen las acciones destructivas en los recursos de producción y, al mismo tiempo, se permita la flexibilidad operativa de los desarrolladores en los proyectos de zona de pruebas de desarrollo.

Revisa las siguientes prácticas recomendadas para A07: Authentication Failures que se aplican a Privileged Access Manager:

• Convierte los roles administrativos críticos (como Propietario [roles/owner], Administrador de la organización [roles/resourcemanager.organizationAdmin] y Administrador de seguridad [roles/iam.securityAdmin]) de vinculaciones estáticas de IAM en derechos de Privileged Access Manager. Configura estos derechos para que requieran una justificación operativa antes de que se otorgue la elevación.
• Para los entornos de producción, configura políticas de derechos de Privileged Access Manager con aprobadores obligatorios, como un grupo central de SecOps o líderes de equipo.
• Configura la duración máxima en los derechos de Privileged Access Manager para que sea el período operativo realista más corto (por ejemplo, dos horas para el mantenimiento estándar y 30 minutos para las acciones de breakglass). Una vez que vence el temporizador,Google Cloud quita la vinculación temporal del rol de IAM.
• Administra la infraestructura de Terraform con recursos de IAM no autorizados (por ejemplo, google_project_iam_member o google_folder_iam_member en lugar de google_project_iam_policy o google_project_iam_binding). Esta práctica evita que se sobrescriban tus canalizaciones de Terraform o que se desincronice la vinculación temporal de roles de Privileged Access Manager mientras un administrador corrige activamente un incidente.
• Habilita los registros de auditoría de Cloud en Privileged Access Manager para registrar las acciones de derechos y los eventos de vencimiento. Transfiere estos registros a Google SecOps para recibir alertas sobre patrones de elevación sospechosos, como varias solicitudes de elevación fuera de horario o solicitudes repetidas desde ubicaciones geográficas inesperadas.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación que se aplican a la federación de identidades de personal:

• Implementa grupos de identidades para cargas de trabajo con SAML 2.0 o OpenID Connect (OIDC) para federar proveedores de identidad externos conGoogle Cloud.
• Configura la duración de la sesión en tu grupo de identidades de personal para limitar la vida útil de los tokens de usuarios federados.
• Aplica condiciones de atributos en los proveedores de identidad de personal para mitigar la falsificación de tokens de IdP de múltiples arrendatarios o la suplantación de identidad entre organizaciones.
• Asigna membresías de grupos externos para asignar roles de IAM a conjuntos de principales de grupos federados (por ejemplo, principalSet://iam.googleapis.com/.../attribute.group/security-engineers).

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación que se aplican a la federación de identidades para cargas de trabajo:

• Crea grupos y proveedores de identidades para cargas de trabajo para cargas de trabajo externas. Usa tokens de OIDC de corta duración y cámbialos de forma dinámica con el servicio de tokens de seguridad por tokens de acceso temporales que vencen en minutos.
• Aplica condiciones de atributos en los proveedores de identidad de cargas de trabajo para que las plataformas externas de múltiples usuarios no puedan autenticarse en tu grupo desde repositorios o cuentas no autorizados.
• Vincula roles de IAM directamente a conjuntos de principales específicos que se filtran por atributos asignados personalizados.
• Cuando configures el acceso de la carga de trabajo, otorga roles de IAM directamente al identificador principalSet:// federado en el recurso de destino.
• Para aplicar la federación de identidades para cargas de trabajo, establece la restricción constraints/iam.disableServiceAccountKeyCreation en tu organización.

Identity Platform

Identity Platform es la plataforma de administración de identidades y accesos de clientes (CIAM) para los clientes de Google Cloud . Identity Platform proporciona autenticación con compatibilidad con varios protocolos a través de SDKs y APIs. Identity Platform admite la MFA, la integración con servicios de autenticación de terceros y el seguimiento de actividades auditables.

Se aplica a A07: Fallas de autenticación.

Revisa las siguientes prácticas recomendadas:

• Habilita la MFA en toda tu base de usuarios. Prioriza los métodos resistentes al phishing, como TOTP (apps de autenticación) o WebAuthn (biometría y llaves de seguridad).
• Implementa funciones de bloqueo de Cloud Run con activadores de beforeCreate y beforeSignIn para ejecutar código de seguridad personalizado antes de que se guarde un usuario o se emita un token. Esta práctica te permite bloquear dominios de correo electrónico desechables, restringir direcciones IP o exigir la verificación de correos electrónicos.
• Realiza la integración con reCAPTCHA Enterprise para evaluar las solicitudes de acceso, registro y restablecimiento de contraseña en busca de tráfico de bots, intentos de uso excesivo de credenciales y abuso automatizado.
• Configura políticas de contraseñas para aplicar longitudes mínimas de caracteres, exigir complejidades de caracteres específicas (como números y símbolos) y bloquear secuencias predecibles.
• Si usas la MFA basada en el teléfono, configura las regiones de SMS y habilita la defensa de reCAPTCHA contra SMS para limitar los mensajes de verificación a los códigos de país en los que residen tus usuarios objetivo.

Soluciones de asesoramiento sobre seguridad de la IA de Mandiant

Las soluciones de asesoramiento sobre la seguridad de la IA de Mandiant pueden evaluar las arquitecturas de software, los procesos comerciales y las implementaciones en la nube propuestos en las primeras etapas del ciclo de vida del desarrollo. Al aplicar la inteligencia sobre amenazas de primera línea al diseño de tu sistema, los consultores de Mandiant ayudan a exponer fallas lógicas ocultas, límites de confianza faltantes y riesgos arquitectónicos antes de que se escriba una sola línea de código.

Se aplica a A06: Diseño no seguro.

Revisa las siguientes prácticas recomendadas:

• Contrata a los consultores de Mandiant antes de que comience el desarrollo para completar talleres de arquitectura y, luego, implementar controles de seguridad desde el principio.
• Colabora con expertos en modelado de amenazas para crear diagramas de flujo de datos de tu aplicación. Define dónde los datos sensibles cruzan los límites de confianza para identificar dónde se deben aplicar controles estrictos de autenticación, encriptación y validación.
• Utiliza marcos de trabajo estructurados para el modelado de amenazas (como STRIDE) durante tus talleres de arquitectura. Los consultores de Mandiant pueden ayudar a priorizar los defectos de diseño descubiertos en función de la capacidad de explotación en el mundo real y el impacto en el negocio.
• Establece valores de referencia seguros para la administración de la IA en flujos de trabajo con agentes y en implementaciones de LLM, y define límites de confianza claros entre los agentes de IA, los servidores de MCP y las fuentes de datos de backend empresariales.

Model Armor

Model Armor está diseñado para analizar las instrucciones, las respuestas y las llamadas a herramientas de MCP del LLM. Model Armor inspecciona las cargas útiles de la IA generativa para ayudar a detectar y bloquear la inyección de instrucciones, los intentos de jailbreak, las URLs maliciosas, el contenido tóxico y la filtración de datos sensibles.

Se aplica a lo siguiente:

• A05: Inyección
• A10: Manejo inadecuado de condiciones excepcionales

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Implementa políticas de Model Armor de forma intercalada en la capa de API Gateway con la integración de Apigee o Agent Gateway para analizar las instrucciones entrantes y las respuestas salientes del modelo antes de que el tráfico llegue a los motores de inferencia o a los tiempos de ejecución de herramientas.
• Configura la configuración mínima a nivel de la organización o la carpeta para crear parámetros de referencia de seguridad obligatorios que los equipos de proyectos individuales no puedan omitir.
• Crea plantillas de Model Armor personalizadas con umbrales de confianza ajustados (por ejemplo, LOW_AND_ABOVE o MEDIUM_AND_ABOVE) para la detección de inyección de instrucciones y jailbreaks en extremos públicos.
• Habilita la detección de URLs maliciosas y el análisis de archivos y PDFs en tu plantilla de Model Armor para verificar las URLs incorporadas en las bases de datos de inteligencia contra amenazas de Google. Descarta las instrucciones que contienen software malicioso o vectores de phishing antes de la ejecución.
• Habilita Sensitive Data Protection en tu plantilla de Model Armor para inspeccionar el tráfico de salida del modelo. Configura la desidentificación o el enmascaramiento automatizados para reemplazar los datos sensibles detectados por marcadores de posición antes de que la respuesta salga del límite.

Revisa las siguientes prácticas recomendadas para el cargo A10: Mishandling of Exceptional Conditions:

• Configura el código de tu aplicación para interceptar los veredictos de MATCH_FOUND y devolver una respuesta genérica, de modo que el sistema no ejecute la instrucción de forma predeterminada ni exponga los registros de seguimiento de excepciones sin procesar.
• Implementa una arquitectura de cierre ante fallas (segura ante fallas) en el código de tu aplicación para rechazar las instrucciones entrantes de IA generativa si las llamadas a la API de Model Armor encuentran tiempos de espera de red, límites de frecuencia o errores HTTP 5xx no controlados.

Política de la organización

La política de la organización te brinda un control centralizado y programático sobre los recursos de tu organización Google Cloud .

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A02: Configuración incorrecta de seguridad
• A04: Fallas criptográficas

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Aplica constraints/storage.publicAccessPrevention para anular las políticas de IAM o las LCA a nivel del bucket que intentan otorgar acceso a allUsers o allAuthenticatedUsers.
• Aplica constraints/iam.allowedPolicyMemberDomains para restringir las vinculaciones de políticas de IAM estrictamente a tus IDs de cliente verificados de Google Workspace o Cloud Identity.
• Aplica constraints/iam.disableServiceAccountKeyCreation en las carpetas de producción para evitar que los usuarios descarguen claves de cuentas de servicio, lo que obliga a los equipos de ingeniería a adoptar alternativas de corta duración, como la federación de identidades para cargas de trabajo.
• Aplicaconstraints/iam.automaticIamGrantsForDefaultServiceAccountspara que Google Cloud no otorgue automáticamente el rol permisivo de Editor (roles/editor) a las cuentas de servicio predeterminadas.
• Para los requisitos que no se cubren con las restricciones predefinidas, implementa restricciones personalizadas para aplicar configuraciones de recursos detalladas. Considera restringir la creación de VM solo a familias de máquinas aprobadas, limitar los tamaños de aprovisionamiento de disco persistente o exigir configuraciones específicas de etiquetas de firewall de red.

Revisa las siguientes prácticas recomendadas para A02: Configuración de seguridad incorrecta:

• Usa constraints/compute.requireShieldedVm para requerir una VM protegida, lo que ayuda a proteger las VMs contra rootkits de kernel, bootkits y alteraciones del firmware.
• Aplica constraints/compute.requireOsLogin para exigir que las instancias de Linux usen el Acceso al SO, que vincula el acceso SSH directamente a las identidades de IAM y la 2SV del usuario.
• Aplica constraints/compute.disableSerialPortAccess para bloquear las conexiones interactivas a la consola en serie en todos los proyectos.
• Aplicar constraints/compute.skipDefaultNetworkCreation para que no se cree la red de VPC predeterminada, lo que obliga a los equipos a compilar VPC personalizadas con subredes dedicadas y políticas de firewall estrictas
• Aplica constraints/sql.restrictPublicIp para que las instancias de Cloud SQL solo reciban direcciones IP internas privadas RFC 1918 y usa constraints/compute.vmExternalIpAccess para restringir las direcciones IPv4 públicas en las VMs.
• Aplica constraints/gcp.resourceLocations para restringir la creación de recursos a regiones Google Cloud autorizadas.

Revisa las siguientes prácticas recomendadas para A04: Fallas criptográficas:

• Para exigir el uso de CMEK, aplica constraints/gcp.restrictNonCmekServices en la organización o la carpeta de nivel superior, establece el tipo de política en Deny y enumera los servicios Google Cloud compatibles. Antes de aplicar la restricción, verifica que el agente de servicio de cada servicio de destino exista y que se le haya otorgado el rol de encriptador/desencriptador de CryptoKey de Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) en los llaveros de claves pertinentes.
• Aplica constraints/gcp.restrictCmekCryptoKeyProjects para restringir la selección de claves a proyectos dedicados de Cloud KMS.

Secret Manager

Secret Manager permite que las aplicaciones y las canalizaciones accedan a los valores de los secretos con nombre en función de los permisos otorgados con IAM. Cuando está habilitada, las interacciones con Secret Manager crean un registro de auditoría que puedes usar para ayudarte con las necesidades de análisis forense y cumplimiento.

Se aplica a lo siguiente:

• A04: Fallas criptográficas
• A07: Fallas de autenticación

Revisa las siguientes prácticas recomendadas para A04: Fallas criptográficas:

• Encripta secretos valiosos con CMEK para controlar, rotar o revocar las claves de encriptación principales que unen tus cargas útiles de secretos.
• Usa sumas de verificación de integridad de datos para mantener y verificar la integridad de los datos de tu secreto cuando agregues y accedas a versiones del secreto.
• Replica secretos en varias regiones para lograr alta disponibilidad y recuperación ante desastres en las zonas de implementación geográficas.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Quita los valores sensibles, como las claves de API, del código fuente, los archivos .env y las configuraciones de compilación de contenedores, y almacena las credenciales en Secret Manager. Recupera valores desencriptados en el tiempo de ejecución con las bibliotecas cliente deGoogle Cloud , los controladores de CSI de Secret Store de GKE o las vinculaciones de secretos de Cloud Run.
• Aplica vinculaciones de políticas de IAM directamente a secretos individuales específicos, lo que otorga a los microservicios el rol de Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) solo en los secretos específicos que requieren.
• Configura programaciones de rotación automáticas en Secret Manager. Cuando comienza un intervalo de rotación, Secret Manager publica una notificación de SECRET_ROTATE en un tema de Pub/Sub designado. Configura un servicio o una función de Cloud Run para leer la notificación, generar un nuevo valor de secreto, agregar la nueva versión a Secret Manager y destruir la versión retirada.
• Habilita los Registros de auditoría de Cloud en Secret Manager para hacer un seguimiento de los eventos de creación, destrucción y acceso a cargas útiles de versiones de secretos. Dirige estos registros a Google SecOps para que se generen alertas sobre eventos de acceso sospechosos, como una cuenta de servicio hackeada que accede a secretos fuera del horario operativo estándar o intenta leer recursos secretos no aprobados.

Security Command Center Premium

Security Command Center Premium te permite encontrar y abordar parámetros de configuración incorrectos de seguridad y amenazas activas en el tiempo de ejecución, incluidos los errores de identificación y autenticación, en tu entorno Google Cloudy tus aplicaciones web. El servicio de Web Security Scanner puede supervisar las vulnerabilidades de las aplicaciones, incluidas las vulnerabilidades de entidades externas XML (XXE), con análisis diseñados para abarcar los controles de OWASP Top 10.

Se aplica a lo siguiente:

• A02: Configuración incorrecta de seguridad
• A05: Inyección
• A07: Fallas de autenticación
• A08: Fallas de integridad de software o datos

Revisa las siguientes prácticas recomendadas para A02: Configuración de seguridad incorrecta:

• Aplica frameworks integrados (como las comparativas de CIS o NIST) con el Administrador de cumplimiento para evaluar tus configuraciones de nube en función de los frameworks de seguridad regulatorios y las comparativas de la industria.
• Habilita la Administración de derechos de la infraestructura de nube para administrar las identidades que tienen acceso a los recursos en tus implementaciones en la nube y mitigar las posibles vulnerabilidades que resulten de errores de configuración.
• Revisa y corrige los resultados de Web Security Scanner para corregir los encabezados de seguridad de respuesta HTTP mal configurados, los encabezados de origen CORS no válidos y la publicación de contenido mixto.

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Habilita servicios como Virtual Machine Threat Detection y Container Threat Detection. Estos servicios analizan la memoria del hipervisor y los eventos del kernel en busca de secuencias de comandos maliciosas, shells inversos y software malicioso instalado (con los detectores Se ejecutó un archivo binario agregado y Se cargó una biblioteca agregada).
• Configura Web Security Scanner para supervisar las aplicaciones en ejecución en busca de fallas de secuencias de comandos entre sitios (XSS) y de inyección de SQL (SQLi).
• Integra los hallazgos de Security Command Center en Google SecOps o en SIEM de terceros para la clasificación automatizada y la respuesta ante incidentes.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Supervisa tus transmisiones de Logging para detectar ataques basados en credenciales con los detectores Brute Force: SSH y Persistence: IAM Anomalous Grant.
• Usa los controles de Cloud Use Multifactor or Passwordless Authentication, Set Application Restriction on API Keys y Require Rotation of API Key para detectar cuándo no se usa la MFA y supervisar el uso de las claves de API.
• Corrige los resultados de Fuga de ID de sesión configurando los backends web para que almacenen tokens de sesión en cookies HTTP con marcas HttpOnly y Secure.

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Configura Web Security Scanner para analizar los extremos web en busca de errores de ejecución basados en firmas y generar un hallazgo de gravedad alta STRUTS_INSECURE_DESERIALIZATION si una aplicación ejecuta una versión vulnerable de Apache Struts.
• Para corregir el hallazgo STRUTS_INSECURE_DESERIALIZATION, actualiza la versión de la biblioteca del framework vulnerable o implementa Assured OSS para extraer un reemplazo verificado por Google.

Protección de datos sensibles

Sensitive Data Protection te permite analizar cualquier dato sensible potencialmente almacenado en buckets, bases de datos, instrucciones de IA generativa o cargas útiles de aplicaciones de transmisión para ayudar a evitar filtraciones de información no deseadas. Si se identifican datos no permitidos, Sensitive Data Protection puede marcar o ocultar esos datos.

Se aplica a lo siguiente:

• A04: Fallas criptográficas
• A09: Errores de registro y alertas de seguridad

Revisa las siguientes prácticas recomendadas para A04: Fallas criptográficas:

• Habilita el descubrimiento de datos sensibles para analizar continuamente tus recursos de almacenamiento y bases de datos, generar perfiles de datos y registrar métricas para los informes de auditoría.
• Usa la encriptación de preservación de formato, el hash criptográfico o la asignación de tokens basada en claves para desidentificar los datos sensibles.
• Implementa plantillas de desidentificación reutilizables y administradas de forma central para aplicar políticas coherentes de inspección y enmascaramiento criptográfico en todos los equipos de desarrollo.
• Analiza las cargas útiles de las instrucciones para ayudar a evitar que los datos corporativos sensibles o la IIP se filtren en las canalizaciones de entrenamiento de la IA generativa.

Revisa las siguientes prácticas recomendadas para A09: Errores de registro y alertas de seguridad:

• Configura tu receptor de registros de Logging para enviar registros de la aplicación a un tema de Pub/Sub. Adjunta un suscriptor de Cloud Run que use la API de Sensitive Data Protection para analizar y desidentificar la carga útil del registro antes de escribir registros limpios en tu bucket final de Logging.
• Usa filtros de exclusión en tus receptores de Logging para enrutar solo los registros no estructurados de alto riesgo (como errores de aplicación sin procesar, cargas útiles de registro de usuarios y registros de transacciones) a través de la canalización de saneamiento.

VirusTotal

La API de VirusTotal es una plataforma de inteligencia sobre amenazas y análisis de archivos que analiza archivos, URLs, dominios y direcciones IP sospechosos para detectar software malicioso, troyanos y cargas útiles maliciosas. La integración de la API de VirusTotal en las canalizaciones de transferencia de archivos te permite analizar las cargas no confiables antes de que los sistemas de aplicaciones procesen los archivos.

Se aplica a lo siguiente:

• A08: Fallas de integridad de software o datos
• A05: Inyección

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Implementa reglas personalizadas de coincidencia de firmas de YARA-X para analizar las estructuras de archivos entrantes en busca de patrones binarios y textuales maliciosos conocidos, lo que permite detectar variantes mutadas de software malicioso.

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Usa el módulo de análisis privado de VirusTotal para analizar las cargas sensibles de forma aislada y no compartir los archivos subidos con terceros.
• Implementa el control de excepciones y la limitación de frecuencia de la API en tu código de transferencia para detectar los códigos de estado HTTP 429 Too Many Requests.

Controles del servicio de VPC

Los Controles del servicio de VPC te permiten crear perímetros alrededor de tus recursos de Google Cloud para ayudar a evitar el robo de datos y mitigar los ataques de falsificación de solicitudes del servidor (SSRF). Los Controles del servicio de VPC rechazan las llamadas a la API que cruzan los límites del perímetro, a menos que las reglas de entrada y salida lo permitan de forma explícita.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A02: Configuración incorrecta de seguridad

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Incluye servicios críticos (como Cloud Storage, BigQuery, Spanner y Agent Platform) en un perímetro de servicio para restringir el acceso a la API a las redes de VPC autorizadas y las identidades de confianza.
• Configura reglas del perímetro de salida en recursos sin servidores para bloquear el robo de datos no autorizado que se produce por llamadas a la API salientes a destinos externos que no pertenecen al perímetro.
• Restringe el acceso a la API entre perímetros y organizaciones con reglas explícitas de entrada y salida que especifiquen las identidades de los llamantes, las APIs de destino y las fuentes de proyectos aprobadas.

Revisa las siguientes prácticas recomendadas para A02: Configuración de seguridad incorrecta:

• Agrupa los proyectos en perímetros dedicados organizados por nivel de seguridad del entorno (por ejemplo, un perímetro de producción). Usa los servicios accesibles desde la VPC para restringir qué APIs internas de Google se pueden invocar dentro del perímetro.
• Enruta las solicitudes salientes a la API desde las cargas de trabajo sin servidores a través de la red de VPC. Configura los servicios y las funciones de Cloud Run para que usen la salida de VPC directa o un conector de Acceso a VPC sin servidores con la entrada configurada estrictamente como solo interna.
• Vincula los niveles de acceso de Access Context Manager a tus reglas de entrada del perímetro que evalúan una combinación de subredes IP corporativas, reclamos de identidad autenticados y señales de estado del dispositivo de Endpoint Verification.
• Mantén un proceso administrativo de breakglass previamente aprobado para la respuesta ante incidentes de emergencia y configura alertas de Monitoring sobre cualquier evento inesperado de incumplimiento del perímetro.

Servicios de Wiz

En las siguientes secciones, se describen las prácticas recomendadas del Top 10 de OWASP para los servicios de Wiz que se integran conGoogle Cloud.

Wiz Code

Wiz Code extiende la seguridad en la nube a los flujos de trabajo de los desarrolladores y las canalizaciones de CI/CD. Wiz Code correlaciona la telemetría del código a la nube, analiza la infraestructura como código (IaC), analiza las dependencias (SCA), detecta las credenciales expuestas y realiza pruebas estáticas de seguridad de aplicaciones (SAST).

Se aplica a lo siguiente:

• A03: Fallas en la cadena de suministro de software
• A05: Inyección
• A07: Fallas de autenticación

Revisa las siguientes prácticas recomendadas para A03: Fallas en la cadena de suministro de software:

• Integra la CLI de Wiz en las canalizaciones de CI/CD para bloquear las solicitudes de extracción y evitar que se combinen si introducen CVE críticos, secretos expuestos o errores graves de configuración de IaC en ramas protegidas.
• Genera y exporta una SBOM para cada compilación y, así, mantén la visibilidad continua de la cadena de suministro en Wiz Cloud.
• Implementa extensiones del IDE de Wiz Code para proporcionar comentarios a los desarrolladores en tiempo real, detectar paquetes vulnerables, claves de API codificadas y errores de sintaxis antes de confirmar el código.
• Integra Wiz Code con CodeMender en canalizaciones de CI/CD para generar, probar y enviar solicitudes de extracción cuando se detecten dependencias de terceros vulnerables.

Revisa las siguientes prácticas recomendadas para A05: Inyección:

• Bloquear la combinación de solicitudes de extracción si el analizador de SAST detecta que la entrada del usuario no confiable fluye hacia las consultas de la base de datos o los comandos del SO sin la sanitización adecuada.
• Integra el complemento de Wiz Code en los IDE de desarrolladores para proporcionar alertas en tiempo real si los desarrolladores escriben patrones de ejecución de comandos o consulta en SQL no seguros o concatenados.
• Cuando Wiz Code marca una falla de inyección, enruta los registros de seguimiento del flujo de datos a CodeMender para que redacte un parche de corrección verificado.

Revisa las siguientes prácticas recomendadas para A07: Fallas de autenticación:

• Implementa el análisis automatizado de secretos en los IDE de los desarrolladores, los hooks locales de preconfirmación y las canalizaciones de CI/CD para detectar credenciales expuestas.
• Para mitigar el robo de credenciales, reemplaza las credenciales estáticas de larga duración por tokens dinámicos de corta duración y acceso vinculado a la identidad (como la federación de identidades para cargas de trabajo o la autenticación basada en OIDC).
• Implementa un manual de tácticas automatizado de respuesta ante incidentes para quitar los secretos detectados del código, las variables de entorno y los registros de compilación.

Wiz Cloud

Wiz Cloud analiza entornos de múltiples nubes para identificar errores de configuración de seguridad, exposiciones de datos sensibles y riesgos de identidad. Con el Wiz Security Graph, Wiz Cloud correlaciona los factores de riesgo en todas las capas de infraestructura para destacar las rutas de ataque críticas.

Se aplica a lo siguiente:

• A01: Control de acceso dañado
• A02: Configuración incorrecta de seguridad
• A04: Fallas criptográficas
• A06: Diseño no seguro

Revisa las siguientes prácticas recomendadas para A01: Control de acceso dañado:

• Realiza un seguimiento de las rutas de elevación de privilegios complejas y de varios saltos en los roles y las políticas de IAM, y las marca para identificar dónde podrían moverse los atacantes de forma lateral o elevar sus privilegios.
• Asigna permisos de acceso activos en cuentas de usuario, cuentas de servicio y agentes de IA a almacenes de datos críticos, y revoca los derechos con privilegios excesivos.
• Integra los hallazgos de derechos de identidad con las plataformas de organización para reemplazar las vinculaciones permanentes de roles administrativos por acceso justo a tiempo (JIT).
• Supervisa y visualiza el movimiento de datos para detectar cuándo se copia o sincroniza la PII de producción en entornos de desarrollo o etapa de pruebas no seguros.

Revisa las siguientes prácticas recomendadas para A02: Configuración de seguridad incorrecta:

• Evalúa y prioriza el riesgo de configuración de la nube correlacionando los errores de configuración con múltiples factores de ataque a través de Wiz Security Graph.
• Aplica marcos de cumplimiento integrados (como OWASP Top 10, CIS Benchmarks y NIST) para medir la configuración de la nube en comparación con los estándares de la industria.
• Integra el analizador de la CLI de Wiz en las canalizaciones de CI/CD para revisar compilaciones o corregir parámetros de configuración erróneos de IaC antes de la implementación.

Revisa las siguientes prácticas recomendadas para A04: Fallas criptográficas:

• Prioriza la corrección de las bases de datos y los buckets de almacenamiento que contengan credenciales de texto sin formato, claves sin hash o datos sensibles almacenados sin encriptación.
• Ejecuta el descubrimiento de datos de Wiz Cloud en los directorios de entrenamiento de IA, las bases de datos de vectores y las canalizaciones de RAG para verificar que los datos propietarios y la PII se redacten antes de la transferencia al LLM.
• Analiza los entornos para identificar los activos de datos no administrados y borrar los datos redundantes para minimizar la superficie de ataque.

Revisa las siguientes prácticas recomendadas para A06: Diseño no seguro:

• Indica a Wiz Red Agent que analice las interfaces arquitectónicas lógicas y simule rutas de ataque para encontrar fallas de diseño no seguras antes de la implementación en producción.
• Pasa el contexto validado de la cadena de ataque de Wiz Red Agent a CodeMender para identificar las causas raíz y generar solicitudes de extracción arquitectónicas probadas.

Wiz Defend

Wiz Defend proporciona detección y respuesta en la nube (CDR), protección del tiempo de ejecución de cargas de trabajo y seguridad de admisión de Kubernetes. Wiz Defend supervisa la actividad del plano de control, detecta anomalías en el tiempo de ejecución, aplica políticas de admisión de contenedores y activa la contención automatizada.

Se aplica a lo siguiente:

• A08: Fallas de integridad de software o datos
• A09: Errores de registro y alertas de seguridad

Revisa las siguientes prácticas recomendadas para A08: Fallas de integridad de software o datos:

• Configura las reglas de admisión de Wiz Defend para inspeccionar y rechazar los manifiestos de implementación de Kubernetes que intenten ejecutar contenedores con privilegios de administrador, solicitar espacios de nombres de red del host o habilitar privileged: true.
• Configura webhooks de admisión de seguridad críticos con failurePolicy: Fail (fail-closed) en producción para bloquear contenedores no confiables si no se puede acceder al webhook.

Revisa las siguientes prácticas recomendadas para A09: Errores de registro y alertas de seguridad:

• Exporta Google Cloud registros de auditoría a un receptor de registros en un tema de Pub/Sub para que Wiz Defend pueda transferir y analizar las actividades del plano de control y los eventos de cargas de trabajo.
• Implementa el sensor de tiempo de ejecución de Wiz en clústeres de GKE y VMs de Compute Engine de alto valor para detectar amenazas de tiempo de ejecución, exploits en la memoria y vulneraciones activas.
• Automatiza las guías de contención para inhabilitar de inmediato las cuentas de servicio de IAM comprometidas o aislar las cargas de trabajo comprometidas.
• Usa Wiz Blue Agent para investigar las detecciones en el entorno de ejecución, correlacionar la telemetría de procesos en tiempo real y el contexto de identidad para determinar las causas raíz y los activos afectados.

Mantén el cumplimiento con OWASP Top 10:2025

Wiz incluye un marco de trabajo de cumplimiento de OWASP Top 10 2025 que te permite evaluar y supervisar tu postura. El marco de trabajo de cumplimiento de OWASP Top 10 2025 asigna las políticas integradas de Wiz a las categorías de riesgo de OWASP pertinentes y crea hallazgos si un control no cumple con los requisitos. Puedes hacer un seguimiento de tu puntuación de cumplimiento a lo largo del tiempo. Si es necesario, puedes personalizar el marco de cumplimiento de OWASP Top 10 2025 para satisfacer los requisitos de tu empresa.

¿Qué sigue?

Revisa el catálogo de prácticas recomendadas de seguridad para conocer más prácticas recomendadas.