Security and Trust Principles in Google Cloud

Resumen

Para un líder de negocio, la seguridad deja de ser un tema técnico en el momento en que se traduce en ingresos perdidos, contratos que no se firman, sanciones regulatorias o reputación erosionada. Un incidente de seguridad no afecta solo a un servidor: afecta la continuidad operativa, la confianza del cliente y la capacidad de la organización para competir en mercados donde el cumplimiento es un requisito de entrada. Este tema construye el marco conceptual con el que Google Cloud aborda la confianza (trust): cómo se define la seguridad en un entorno de nube pública, qué lenguaje se usa para hablar de amenazas y controles, y por qué el modelo de responsabilidad compartida transforma la naturaleza del riesgo sin eliminarlo.

El primer eje es el panorama de amenazas cibernéticas actuales. El ataque promedio ya no es una intrusion aislada de un hacker individual: es un proceso industrializado que combina phishing automatizado, ransomware como servicio, botnets y explotación de vulnerabilidades conocidas antes de que las organizaciones parchen sus sistemas. Las implicaciones de negocio de ese panorama son directas: paradas de producción, pagos de rescate, litigios, costes de notificación y pérdida de clientes corporativos que exigen evidencias de control antes de firmar. La volatilidad del panorama exige que la seguridad sea una capacidad continua de la organización, no un proyecto con fecha de fin.

El segundo eje es la comparación entre la seguridad on-premises y la seguridad en la nube. En infraestructura propia, el control físico del datacenter es de la organización; en la nube pública, el proveedor asume el control físico y gran parte del control de la infraestructura, mientras el cliente mantiene el control de identidad, configuración y datos. Ese desplazamiento no reduce la responsabilidad del cliente: la concentra donde más impacto tiene, en el acceso y en la configuración.

El tercer eje es el vocabulario. Control, compliance, confidentiality, integrity y availability son los atributos que un auditor y un CISO discuten; threat, vulnerability, phishing, malware, ransomware, DDoS y man-in-the-middle son las categorías con las que se describe el riesgo. Dominar ese vocabulario es lo que permite a un Digital Leader participar en una conversación de riesgo sin depender exclusivamente del equipo técnico, y es exactamente lo que el examen evalúa.

Un último punto de encuadre: este tema es la base sobre la que se apoyan los siguientes del dominio. IAM y cumplimiento, cifrado y gestión de claves, seguridad de red y perímetro, y los principios de confianza y residencia de datos de Google Cloud se entienden mejor cuando se parte del lenguaje común de amenazas, atributos y responsabilidad compartida que se construye aquí.

El enfoque del material es deliberadamente ejecutivo: se prioriza la capacidad de razonar y decidir ante un escenario de riesgo sobre la memorización de productos. Cuando se nombran herramientas concretas de Google Cloud, se hace para anclar un concepto en un mecanismo verificable, no para convertir el tema en un catálogo. El objetivo final es que un líder pueda liderar la conversación de seguridad con su equipo técnico, con auditoría y con clientes, usando el lenguaje correcto y esperando el nivel de evidencia correcto de cada parte.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Describir el panorama actual de amenazas cibernéticas y traducir cada categoría de amenaza a su implicación de negocio (coste operativo, reputacional, regulatorio y contractual).
Comparar el modelo de seguridad on-premises con el de la nube pública, identificando qué controles asume el proveedor y cuáles permanecen bajo responsabilidad del cliente.
Explicar el modelo de responsabilidad compartida de Google Cloud y su efecto sobre la distribución del riesgo en una migración.
Definir y diferenciar los atributos de control, compliance, confidentiality, integrity y availability, y relacionarlos con decisiones de negocio concretas.
Distinguir con precisión los términos de seguridad que el examen utiliza: threat, vulnerability, exploit, attack surface, breach y risk.
Explicar las categorías de amenaza más frecuentes: phishing, malware, ransomware, DDoS, man-in-the-middle, spyware, troyanos, gusanos, botnets e ingeniería social.
Reconocer la función de la defensa en profundidad y por qué ningún control aislado sostiene un programa de seguridad.
Identificar los componentes de visibilidad de seguridad de Google Cloud, en particular Security Command Center, y su papel en la gestión del riesgo.
Argumentar, ante un stakeholder de negocio, por qué la seguridad en la nube se gobierna con identidad, configuración y evidencia, y no con perímetro físico.
Anticipar los errores más frecuentes al evaluar la seguridad de una carga de trabajo en la nube.

Contenido Principal

Subtema 1: Panorama de amenazas cibernéticas y sus implicaciones de negocio

Una amenaza cibernética (cyber threat) es cualquier circunstancia o actor con capacidad potencial de causar daño a un activo digital. El riesgo, en cambio, es la combinación de la probabilidad de que esa amenaza se materialice con el impacto que tendría. Esta distinción importa en negocio: un CISO gestiona amenazas técnicas; un líder de negocio gestiona riesgo, es decir, impacto en la operación, en el balance y en la relación con el cliente.

El panorama actual tiene cuatro rasgos que cambian la conversación ejecutiva:

Industrialización del ataque. Grupos de atacantes operan como empresas: especialización por fase (acceso inicial, movimiento lateral, exfiltración), herramientas reutilizables y ransomware entregado bajo modelo de suscripción (ransomware-as-a-service). Un atacante no necesita ser experto para explotar una vulnerabilidad; necesita comprar el kit.
Superficie de ataque ampliada. La adopción de trabajo remoto, APIs públicas, dispositivos IoT y multi-cloud multiplica los puntos de entrada. Cada recurso nuevo en la nube es un activo que debe ser configurado con seguridad; una cuenta mal configurada expuesta a internet es, en la práctica, un servidor en el perímetro de la organización.
El factor humano sigue siendo el vector dominante. El phishing y la ingeniería social siguen entre los vectores iniciales más frecuentes. La automatización permite campañas dirigidas a gran escala, y la sofisticación de los mensajes (deepfakes de voz, suplantación de ejecutivos) eleva el coste de no formar a las personas. Un solo clic en un correo spear phishing dirigido a un administrador puede entregar credenciales que abren toda la infraestructura, por lo que la formación y la 2SV son controles de negocio, no gastos de cumplimiento.
El impacto es de negocio, no solo técnico. Un ransomware que detiene la producción produce pérdida de ingresos por hora, coste de recuperación, exposición a cláusulas de SLA, y en sectores regulados, obligaciones de notificación. Un robo de datos produce daño reputacional que se mide en renovaciones de contrato perdidas, no solo en multas. La distinción entre impacto técnico e impacto de negocio es la que convierte un informe de incidente en una decisión ejecutiva.

Categoría de amenaza	Qué es	Impacto de negocio típico	Palanca de respuesta
Ransomware	Cifrado de activos con exigencia de pago	Parada operativa, coste de recuperación, daño reputacional	Copias inmutables, segmentación, gestión de parches, IAM
Phishing / ingeniería social	Engaño para obtener credenciales o ejecutar acciones	Robo de identidad corporativa, fuga de datos	2SV, formación, Cloud Identity, detección de amenazas
Malware	Software malicioso (troyanos, gusanos, spyware)	Compromiso de endpoints y servidores, espionaje	Endpoint protection, hardening, actualizaciones
DDoS	Saturación del servicio con tráfico masivo	Indisponibilidad, pérdida de ingresos, daño de marca	Google Cloud Armor, load balancing, diseño elástico
Man-in-the-middle	Intercepción o alteración de comunicaciones	Robo de credenciales y datos en tránsito	TLS, mTLS, VPN, autenticación fuerte
Explotación de vulnerabilidades	Uso de un fallo de software (incluidas zero-day)	Acceso no autorizado, movimiento lateral	Parches, gestión de vulnerabilidades, Security Command Center

Es útil distinguir además el perfil del atacante según su motivación, porque de él depende la naturaleza del riesgo esperado:

Ciberdelincuencia orientada al beneficio. Ransomware, robo de credenciales, fraude. Es el perfil dominante y el que explica la mayoría de los incidentes de media y gran empresa.
Amenazas patrocinadas por Estados. Espionaje industrial, interferencia, objetivo de valor estratégico. Requiere controles reforzados y cultura de reporte, y afecta sobre todo a sectores críticos.
Activistas y hacktivistas. Defacement, denegación de servicio con mensaje. El impacto es principalmente reputacional y de disponibilidad temporal.
Amenazas internas e inadvertidas. Errores humanos, configuraciones expuestas, accesos no revocados. Son el vector más frecuente y el más barato de mitigar con proceso y automatización.

La lectura ejecutiva de esta tabla es que la seguridad no se compra como producto único: se compone. Cada fila pide una palanca distinta, y la ausencia de cualquiera de ellas crea un camino de ataque que un adversario con recursos encontrará. Además, la cadena de valor del daño casi nunca termina en el incidente técnico: continúa en la interrupción del negocio, en la obligación de informar a clientes y autoridades, en la investigación forense y en la retención de clientes que reevalúan al proveedor después de un incidente público.

Tres cifras conceptuales ayudan a enmarcar el tema sin inventar datos: el coste de un incidente no es el rescate (cuando lo hay), sino la suma de downtime, recuperación, notificación, litigio, aumento de primas de seguros y pérdida de ingresos futuros; el tiempo de detección (mean time to detect) es tan crítico como el tiempo de respuesta, porque un atacante que permanece oculto semanas multiplica el daño; y la mayoría de los incidentes graves involucran credenciales válidas o configuraciones incorrectas, no exploits exóticos. Un líder que entiende estos tres puntos deja de preguntar "¿cuánto cuesta el antivirus?" y empieza a preguntar "¿en cuánto tiempo detectamos y contamos el acceso no autorizado".

Concepto de riesgo	Definición	Ejemplo de negocio	Consecuencia si se ignora
Downtime	Periodo en el que el servicio no está disponible	Caída del canal de ventas online	Ingresos perdidos por hora, SLA incumplido
Recuperación	Restauración de datos y sistemas tras un incidente	Restaurar copias tras ransomware	Horas o días de operación degradada
Notificación	Obligación legal/contractual de informar a afectados	Fuga de datos de clientes	Coste legal, pérdida de confianza
Litigio y sanciones	Demanda o multa regulatoria	Incumplimiento de normativa de protección de datos	Impacto directo en el resultado
Pérdida de reputación	Abandono de clientes tras un incidente público	No renovación de contratos corporativos	Impacto recurrente en ingresos

Subtema 2: Seguridad en la nube frente a seguridad on-premises

En el modelo on-premises, la organización es dueña de todo el stack: edificio, rack, servidores, red, hipervisor, sistema operativo, aplicación y datos. El perímetro de seguridad es en gran parte físico y de red: quién entra al datacenter, qué firewall protege el borde, qué VLAN segmenta cada sistema. Ese modelo da control total y responsabilidad total; su límite es la capacidad de la organización para sostener especialistas, parches y vigilancia 24/7.

En la nube pública, el proveedor opera la infraestructura física y la capa de virtualización. Google Cloud, por ejemplo, diseña sus datacenters, sus servidores y su software de seguridad, y aplica controles de acceso físico, cifrado de infraestructura y monitoreo continuo. El cliente, en cambio, controla quién accede a los recursos (IAM), cómo están configurados (redes, firewalls, cifrado, exposición pública), qué datos almacena y cómo los usa.

El modelo que describe esta distribución es la responsabilidad compartida (shared responsibility): el proveedor es responsable de la seguridad de la nube (infraestructura, hardware, red física, virtualización); el cliente es responsable de la seguridad en la nube (configuración, identidad, datos, aplicaciones, accesos). Un error conceptual frecuente —y una fuente habitual de preguntas de examen— es asumir que estar en la nube elimina la responsabilidad del cliente. No la elimina: la reubica.

Dimensión	On-premises	Google Cloud (nube pública)
Control físico del datacenter	Total, del cliente	Del proveedor, auditado y reportado
Hardware y red física	Compra y ciclo de vida del cliente	Diseñado y operado por Google
Hipervisor y virtualización	Responsabilidad del cliente	Responsabilidad del proveedor
Identidad y accesos (IAM)	Cliente	Cliente
Configuración de red y firewalls	Cliente	Cliente
Datos, cifrado y claves	Cliente (salvo gestión de claves delegada)	Cliente, con opciones de gestión gestionada
Cumplimiento y auditoría	El cliente debe demostrar todo	El proveedor publica certificaciones y reportes; el cliente demuestra su configuración

La consecuencia estratégica es clara: en la nube, el riesgo del cliente se concentra en la configuración y en el acceso. La buena noticia es que esos dos vectores se pueden gobernar con políticas automatizadas, evidencia auditable y herramientas de la propia plataforma.

El escenario híbrido añade una tercera capa de complejidad: cuando parte de la carga vive on-premises y parte en la nube, conviven dos modelos de control y dos cadenas de suministro de parches. El riesgo deja de ser solo técnico y se vuelve de integración: identidades federadas mal configuradas, VPN con políticas demasiado abiertas, copias de datos que cruzan el perímetro sin cifrado. En un entorno multicloud, se duplican además las políticas de acceso y la supervisión. Por eso, en la evaluación de un caso de uso, la pregunta de seguridad no es solo "¿dónde corre?", sino "¿quién administra el acceso en cada entorno y con qué evidencia unificamos la supervisión?".

Ejemplo Práctico

Un líder de negocio que evalúa la madurez de seguridad de su organización puede inspeccionar la postura real sin pedir un informe externo. Verificar la política de IAM del proyecto muestra quién tiene acceso de alto privilegio:

gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role, bindings.members)"

Revisar las cuentas de servicio activas ayuda a detectar identidades de máquina con permisos heredados o abandonadas:

gcloud iam service-accounts list \
  --format="table(email, disabled, displayName)"

Consultar las reglas de firewall expuestas a internet conecta la postura con la superficie de ataque real:

gcloud compute firewall-rules list \
  --format="table(name, network, direction, sourceRanges, allowed)"

Una regla de entrada con origen 0.0.0.0/0 sobre un puerto administrativo no es un hallazgo teórico: es una puerta abierta que un escáner encuentra en minutos. Estas tres consultas bastan para iniciar una conversación ejecutiva de riesgo con datos propios.

Subtema 3: Control, compliance, confidentiality, integrity y availability

Estos cinco atributos estructuran cualquier conversación de seguridad con un regulador, un auditor o un cliente corporativo. No son sinónimos, y el examen espera poder distinguirlos.

Control es la capacidad de la organización de determinar y limitar quién puede hacer qué sobre un activo. En la nube se ejerce con jerarquía de recursos, IAM, políticas de red y segmentación. Sin control, el resto de los atributos no se pueden sostener, porque no hay forma de saber quién accedió ni de impedir accesos no deseados. El control no es solo técnico: incluye procesos de aprobación, revisión de accesos y separación de funciones.

Compliance (cumplimiento) es la capacidad de demostrar, con evidencia, que los controles se aplican y que las obligaciones legales, regulatorias y contractuales se respetan. La diferencia entre control y compliance es sustancial: tener un control no prueba su aplicación. Compliance exige registros (logs), reportes y un ciclo de revisión. En la práctica, esto se traduce en la existencia de políticas documentadas, evidencia de que se aplican (audit logs), y la capacidad de producir un informe ante un regulador o un auditor en un plazo razonable.

Confidentiality (confidencialidad) es garantizar que la información solo sea accesible para quienes están autorizados. Se sostiene con cifrado, control de acceso, clasificación de datos y separación de entornos. Una fuga de datos es una falla de confidencialidad. La clasificación de datos (público, interno, confidencial, restringido) es el primer paso para aplicar controles proporcionales: no todos los datos merecen el mismo nivel de protección, y tratarlos igual genera coste innecesario o riesgo evitable.

Integrity (integridad) es garantizar que la información no sea alterada de forma no autorizada, ni en reposo ni en tránsito ni durante su procesamiento. En negocio, la integridad es lo que hace confiable un reporte financiero o un registro clínico; un dato manipulado puede causar decisiones incorrectas peores que un dato perdido. La integridad se sostiene con cifrado, firmas digitales, control de versiones, y registros de auditoría que permitan reconstruir qué cambió, quién lo cambió y cuándo.

Availability (disponibilidad) es garantizar que los sistemas y los datos estén accesibles cuando se necesiten, con el nivel de servicio acordado. Se trabaja con redundancia entre zonas y regiones, backups, load balancing y planes de recuperación. Un ransomware es, en el fondo, un ataque a la disponibilidad (y frecuentemente también a la integridad y la confidencialidad). La disponibilidad no es solo "que el servidor esté encendido": implica tolerancia a fallos, capacidad elástica, y un objetivo de tiempo de recuperación (RTO) y de punto de recuperación (RPO) definidos con el negocio, no asumidos por el equipo técnico.

Atributo	Pregunta de negocio	Falla típica	Herramientas de referencia en Google Cloud
Control	¿Quién puede hacer qué sobre nuestros activos?	Cuentas con permisos excesivos	IAM, jerarquía de recursos, políticas
Compliance	¿Podemos demostrar el cumplimiento ante un auditor?	Sin logs ni evidencia de revisión	Audit logs, Compliance Reports Manager
Confidentiality	¿Quién puede leer los datos?	Bucket o base de datos expuesto	Cifrado, IAM, Secret Manager, DLP
Integrity	¿Los datos están completos y sin alterar?	Manipulación en tránsito o en reposo	TLS, checksums, control de versiones, audit logs
Availability	¿El servicio está disponible cuando se necesita?	Fallo de una zona, saturación, ransomware	Zonas y regiones, backups, Cloud Armor, load balancing

En sectores regulados —banca, seguros, salud, sector público— estos atributos no son voluntarios: se traducen en obligaciones concretas. La confidencialidad y la integridad de los datos de cliente suelen estar respaldadas por normativa de protección de datos; la disponibilidad, por planes de continuidad del negocio con objetivos de tiempo de recuperación; el control y el compliance, por obligaciones de auditoría y de conservación de evidencia. Un Digital Leader debe poder mapear cada requisito regulatorio a uno de estos atributos y, a partir de ahí, al control técnico y organizativo que lo sostiene. Ese mapeo es el puente entre el lenguaje del regulador y el lenguaje de la plataforma.

Vale la pena subrayar una relación que el examen explota: compliance no es un atributo técnico, sino la capacidad de demostrar los demás. Una organización puede tener cifrado (confidencialidad), firewalls (control) y backups (disponibilidad) y aun así incumplir, si no puede producir evidencia de quién accedió, cuándo y con qué resultado. Por eso la auditoría y los logs no son un añadido: son el mecanismo que convierte los controles en confianza demostrable ante terceros.

Subtema 4: El vocabulario de amenazas que el examen utiliza

El examen no pide que seas un analista de seguridad; pide que entiendas el lenguaje con el que se describe el riesgo y que sepas asociar cada término con una respuesta de negocio. Estas son las distinciones críticas que aparecen con más frecuencia en las preguntas de este dominio.

El primer grupo de términos describe la mecánica del ataque:

Threat (amenaza) es el actor o el evento con potencial de daño (un grupo de ransomware, una tormenta que inunda un datacenter). Vulnerability (vulnerabilidad) es una debilidad explotable (una versión sin parche, un puerto abierto, una credencial por defecto). Exploit es la técnica o el código que aprovecha esa vulnerabilidad. Risk (riesgo) combina probabilidad e impacto. Un examen típico presenta un escenario y pide identificar cuál de estos elementos se describe.
Attack surface (superficie de ataque) es el conjunto de puntos donde un atacante puede intentar entrar o extraer datos. Reducir la superficie de ataque —cerrar puertos, eliminar cuentas huérfanas, no exponer servicios innecesarios— es una de las acciones de mayor retorno de un programa de seguridad.
Phishing es la suplantación de una entidad de confianza por correo, mensaje o sitio web para obtener credenciales o provocar una acción. Spear phishing es dirigido a una persona o grupo concreto con información contextual; whaling apunta a ejecutivos. Smishing usa SMS y vishing usa voz.
Malware es el término general para software malicioso. Dentro de él: ransomware (cifra o secuestra datos y exige pago), spyware (espía la actividad), troyano (se aparenta software legítimo), gusano (se propaga sin intervención del usuario) y rootkit (oculta su presencia a nivel profundo del sistema).
DDoS (distributed denial of service) consiste en saturar un servicio con tráfico desde muchos orígenes, con el objetivo de hacerlo inaccesible. No busca robar datos; busca degradar o tumbar la disponibilidad, a menudo como cobertura de otro ataque o como forma de extorsión.
Man-in-the-middle (MitM) es la intercepción silenciosa entre dos partes que creen comunicarse directamente. El atacante puede leer, alterar o reenviar tráfico. La respuesta estructural es el cifrado de extremo a extremo con autenticación (TLS), no solo cifrar sino verificar con quién se habla.
Zero-day es una vulnerabilidad explotada antes de que exista parche disponible. Breach (brecha) es el resultado de un acceso no autorizado materializado; no toda vulnerabilidad produce una brecha, y no toda brecha empieza por una vulnerabilidad técnica: puede empezar por una credencial robada.
Insider threat (amenaza interna) proviene de personas con acceso legítimo —empleados, contratistas, partners— que usan ese acceso de forma abusiva, deliberada o por error. La respuesta no es solo técnica: incluye least privilege, revisión de accesos, separación de funciones y cultura de reporte. El riesgo de amenaza interna no se elimina con tecnología; se mitiga con diseño de permisos mínimos, monitoreo de accesos anómalos y un clima organizacional donde reportar un error sea más seguro que ocultarlo.
Credential stuffing es el uso automatizado de credenciales filtradas en otros sitios contra los servicios de la organización. La respuesta estructural es la autenticación multifactor (2SV) y el bloqueo de reutilización de contraseñas, no solo la complejidad de la contraseña.
Shadow IT describe recursos y servicios adoptados por el negocio sin supervisión de TI (SaaS no aprobado, buckets personales, integraciones con IA). Es una fuente de riesgo de confidentiality y compliance porque los datos de la empresa se procesan fuera de los controles corporativos; la respuesta combina descubrimiento de activos, política y habilitación de alternativas aprobadas, no solo prohibición.

Una regla práctica para el examen: cuando una pregunta describa un síntoma (un servicio inaccesible, datos cifrados con extorsión, un correo que pide credenciales, un tráfico alterado), la respuesta correcta casi siempre pide emparejar el síntoma con la categoría de amenaza y con la palanca de control correspondiente. Cuando la pregunta describa un término, pide la definición precisa y su distinción más cercana.

Un segundo grupo de términos que el examen usa con frecuencia describe el contexto del ataque más que el mecanismo. Perímetro hace referencia a la frontera tradicional entre red interna y externa; en la nube moderna el perímetro se desplaza hacia la identidad, lo que explica por qué BeyondCorp y los modelos de acceso sin VPN definen un perímetro lógico basado en identidad y contexto, no en la ubicación de red. Hardening es el proceso de reducir la superficie de ataque de un sistema eliminando funciones innecesarias y aplicando configuraciones seguras por defecto. Segregation of duties (separación de funciones) evita que una única persona pueda iniciar y autorizar una transacción crítica, control que un auditor revisa de forma rutinaria. Audit log es el registro inmutable de quién hizo qué y cuándo, y es la evidencia que sostiene compliance. Estos términos aparecen en preguntas de escenario donde se pide identificar qué control faltó, no solo qué herramienta debía existir.

Subtema 5: Defensa en profundidad y visibilidad del riesgo

La defensa en profundidad (defense in depth) es el principio de aplicar múltiples capas de control de forma que el fallo de una sola no implique el compromiso total. En la nube, esas capas típicas son: identidad y autenticación; red privada y segmentación; cifrado en tránsito y en reposo; configuración segura de la infraestructura; monitoreo y detección; y respuesta a incidentes. Ninguna capa es suficiente por sí sola; el valor está en la combinación y en la reducción del daño posible si una capa cae.

Para gobernar la seguridad con evidencia, Google Cloud ofrece Security Command Center como plataforma de visibilidad del riesgo: inventario de activos, detección de configuraciones inseguras, hallazgos (findings) de vulnerabilidades y amenazas, y métricas de postura de seguridad. Para un líder de negocio, el valor no es la herramienta en sí, sino la conversación que habilita: cuántos activos están expuestos, cuántos hallazgos críticos hay abiertos, cuánto tarda la organización en cerrarlos.

Conviene detenerse en el significado de negocio de cada capa de la defensa en profundidad, porque es así como se justifica la inversión ante un comité financiero:

Capa de identidad. Quién entra y con qué nivel de confianza. Autenticación fuerte, 2SV, IAM con least privilege, service accounts con rotación de claves. Es la primera barrera en un mundo sin perímetro: el acceso legítimo robado no dispara los alertas clásicas de intrusión.
Capa de red. Qué recursos pueden comunicarse entre sí. VPC privadas, subredes segmentadas, reglas de firewall con mínimo necesario, Private Google Access. Su valor de negocio es contener el daño: si un componente se compromete, la segmentación impide que el atacante se mueva libremente.
Capa de datos. Cómo se protege el activo en sí. Cifrado en reposo y en tránsito, gestión de claves, Secret Manager para credenciales, clasificación y prevención de pérdida de datos. Incluso si otra capa falla, un activo cifrado y bien segmentado tiene un valor residual de explotación mucho menor. La clasificación de datos permite aplicar controles proporcionales y facilita la respuesta ante incidentes: saber qué dato está afectado determina la obligación de notificación y el impacto de negocio real.
Capa de aplicación y configuración. Cómo se despliega y se mantiene. Hardening, gestión de dependencias, despliegues automatizados, revisión de configuraciones. La mayoría de las brechas en la nube se originan aquí, no en ataques a la infraestructura del proveedor. Una configuración incorrecta de un servicio gestionado es una vulnerabilidad legítima, y la automatización de la revisión de configuraciones es una de las inversiones de seguridad de mayor retorno.
Capa de monitoreo y respuesta. Cuánto tarda la organización en detectar y contener. Logs, alertas, Security Command Center, runbooks de respuesta. La detección rápida no evita el incidente inicial, pero transforma un evento mayor en un evento controlado.

Ejemplo Práctico

La postura de seguridad se gestiona con evidencia, no con intención. Un ciclo básico de revisión trimestral se apoya en tres consultas de lectura: activos, hallazgos y exposición de red.

Listar los recursos activos muestra la superficie que debe ser protegida:

gcloud asset search-all-resources \
  --scope=projects/PROJECT_ID \
  --format="table(assetType, name, location)"

Consultar los hallazgos de seguridad activos da la postura del momento, ordenada por severidad:

gcloud scc findings list "organizations/ORG_ID" \
  --filter="state=ACTIVE" \
  --format="table(category, severity, eventTime)"

Verificar la exposición de red de las instancias conecta la postura con el riesgo de negocio inmediato:

gcloud compute instances list \
  --format="table(name, zone, networkInterfaces[].network, networkInterfaces[].accessConfigs[].natIP)"

Una dirección IP pública sobre una instancia que no necesita exposición directa es un hallazgo accionable: cada exposición corregida reduce la superficie de ataque y elimina una ruta potencial de compromiso. El hábito de revisar estos tres informes convierte la seguridad en una métrica de gestión, no en una sensación.

Como síntesis del tema, la confianza en la nube se construye con tres piezas que un líder debe poder nombrar y defender ante un cliente o un auditor: un modelo claro de responsabilidad compartida, un conjunto de controles en capas aplicados de forma continua, y evidencia auditable de que esos controles funcionan. Cuando cualquiera de las tres piezas falta, la conversación de trust se estanca; cuando las tres están, la seguridad deja de ser un obstáculo para el negocio y se convierte en un argumento de venta.

Este marco es transversal a todo el dominio de trust & security: los siguientes temas —identidad y cumplimiento, cifrado y claves, seguridad de red, y los principios de confianza de Google Cloud— se entienden y se razonan mejor partiendo del lenguaje común de amenazas, atributos y responsabilidad compartida que aquí se establece. Un líder que domina este vocabulario puede participar en la conversación de riesgo con igualdad de condiciones frente a un CISO, un auditor o un cliente corporativo con requisitos estrictos.

Temas relacionados: Identity, Access Management and Compliance, Encryption, Key Management and Data Protection, Network Security, VPC and Perimeter Defense, Compliance, Data Sovereignty and Data Residency.

Errores Comunes

Los errores siguientes aparecen con frecuencia en la evaluación de riesgo y en la preparación del examen. Reconocerlos y saber la respuesta correcta es tan importante como conocer los conceptos, porque el examen explota precisamente estas confusiones en sus opciones de respuesta.

Error: Asumir que al migrar a la nube la seguridad "la resuelve el proveedor" y que no se requieren controles del lado del cliente. → Solución: Aplicar el modelo de responsabilidad compartida desde el diseño: el proveedor protege la infraestructura de la nube, pero la organización controla identidad, configuración de red, exposición pública, gestión de datos y clasificación. Revisar estos controles antes de mover datos reales.
Error: Confundir vulnerability con threat o con risk. → Solución: Usar la cadena completa: threat (actor o evento con potencial de daño) + vulnerability (debilidad explotable) + exploit (técnica de aprovechamiento) = risk (probabilidad × impacto). Formular siempre la pregunta de negocio: ¿qué se pierde si esto ocurre y con qué probabilidad?
Error: Tratar la seguridad como un proyecto de una sola vez al migrar. → Solución: Gobernarla como capability continua: revisiones de permisos, gestión de parches, revisión de hallazgos, pruebas de recuperación y formación periódica. En la nube, la configuración cambia a diario; un control correcto hoy puede no serlo mañana. Un bucket correctamente privado puede volverse público por un cambio de configuración, y una cuenta de servicio con permisos adecuados puede heredar privilegios si se le asigna un nuevo rol sin revisión. La disciplina de revisión periódica es lo que sostiene la postura de seguridad en el tiempo.
Error: Responder a DDoS con medidas únicamente de red perimetral, ignorando la elasticidad y la capa de aplicación. → Solución: Combinar mitigación gestionada (Google Cloud Armor delante de un load balancer), diseño elástico y limitación de tasa en APIs. La disponibilidad se protege con arquitectura, no solo con un firewall. Además, conviene distinguir entre un DDoS deliberado y un pico legítimo de tráfico (campaña de marketing, lanzamiento de producto): las respuestas son distintas. El primero necesita mitigación activa de tráfico malicioso; el segundo, capacidad elástica y un plan de escalamiento predefinido para no confundir un éxito comercial con un ataque.
Error: Priorizar únicamente la confidencialidad y descuidar integridad y disponibilidad. → Solución: Evaluar los tres atributos del triángulo CIA en cada caso de uso: un ransomware ataca la disponibilidad y a menudo la integridad; un dato manipulado sin pérdida de acceso puede causar un daño de negocio mayor que una caída breve, y medir el éxito del programa con indicadores de riesgo (activos expuestos, hallazgos críticos abiertos, tiempo de detección), no con el número de herramientas desplegadas.

Puntos para el Examen

🎯 Punto clave 1: La responsabilidad compartida es el marco dominante de este dominio. El proveedor es responsable de la seguridad de la nube (hardware, red física, virtualización, datacenters); el cliente es responsable de la seguridad en la nube (IAM, configuración, datos, aplicaciones). Las preguntas suelen presentar escenarios donde el cliente delega de más o asume de menos.

🎯 Punto clave 2: Distingue con precisión threat, vulnerability, exploit, attack surface y risk. El examen usa estos términos en opciones de respuesta casi intercambiables si no se conocen las definiciones; la distinción correcta suele determinar la respuesta correcta.

🎯 Punto clave 3: Los atributos control, compliance, confidentiality, integrity y availability se evalúan en contexto: una fuga de datos es un problema de confidentiality; una manipulación de registros es de integrity; un ransomware es de availability (y frecuentemente de los tres); la ausencia de evidencia auditable es de compliance.

🎯 Punto clave 4: Memoriza la asociación amenaza → respuesta. Phishing se combate con 2SV y formación; ransomware con backups inmutables, segmentación y gestión de accesos; DDoS con Cloud Armor y load balancing; MitM con TLS y autenticación; vulnerabilidades con parches ySecurity Command Center. Las preguntas presentan el síntoma y piden la palanca.

🎯 Punto clave 5: La defensa en profundidad es un principio, no un producto. Cuando una pregunta mencione "capas de seguridad" o "no depender de un solo control", la respuesta correcta apunta a la combinación de identidad, red, cifrado, configuración y monitoreo, no a la adquisición de una herramienta aislada. Cada capa reduce la probabilidad de compromiso total, y el valor de negocio está en la reducción acumulada del riesgo, no en la perfección de una sola capa.

Recursos Externos

Google Cloud security overview — Visión general de cómo Google Cloud aborda la seguridad de la infraestructura y los servicios.
Security best practices en el Architecture Framework — Principios de diseño seguro aplicados a workloads en la nube.
Security Command Center — Plataforma de inventario de activos, hallazgos y gestión de la postura de seguridad.
Google Cloud security whitepaper — Documento de referencia sobre el modelo de seguridad de la infraestructura de Google Cloud, incluyendo el diseño de datacenters, la gestión de identidad y los principios de responsabilidad compartida.
Prácticas recomendadas de seguridad — Guía operativa de controles y patrones para entornos productivos, organizada por área de responsabilidad del cliente.

Autoevaluación Rápida

Pregunta: Un responsable de negocio dice: "Google ya se encarga de la seguridad, nosotros solo subimos datos". ¿Qué responde un Digital Leader? Respuesta: Que el modelo es de responsabilidad compartida. Google protege la infraestructura de la nube (datacenters, hardware, red física, virtualización), pero la organización es responsable de la seguridad en la nube: quién accede (IAM), cómo está configurada la red, si hay datos expuestos públicamente, cómo se clasifican y se cifran los datos y cómo se responde a incidentes. La migración traslada parte del riesgo; no lo elimina. La analogía útil para un stakeholder no técnico es la de un edificio: el propietario del edificio (Google) asegura la estructura, las cerraduras de las entradas comunes y la vigilancia del perímetro; el inquilino (el cliente) decide quién tiene llave de su oficina, qué documentos deja sobre la mesa y a quién le da acceso.
Pregunta: ¿Cuál es la diferencia entre vulnerability y threat, y por qué importa en una conversación de negocio? Respuesta: La vulnerability es una debilidad explotable (software sin parche, puerto abierto); la threat es el actor o evento con potencial de daño (grupo de ransomware, insider). Importa porque el riesgo de negocio solo aparece cuando ambos se combinan con un impacto: una vulnerabilidad sin amenaza asociada es deuda técnica; una amenaza sin vulnerabilidad explotable no se materializa. La gestión de riesgo prioriza donde ambos convergen. En la práctica, esto significa que un CISO debe trabajar con el equipo de riesgo de negocio para asignar probabilidad e impacto a cada combinación vulnerability-threat, y no tratar por igual un hallazgo técnico aislado y un riesgo de negocio concreto y cuantificable.
Pregunta: Un sitio web corporativo queda inaccesible por tráfico masivo distribuido desde miles de IPs. ¿Qué categoría de amenaza es y qué control de negocio se argumenta? Respuesta: Es un ataque DDoS, orientado a la disponibilidad. El control estructural combina mitigación gestionada con Google Cloud Armor delante de un load balancing, un diseño elástico que absorbe picos y limitación de tasa en APIs. El argumento de negocio es que la disponibilidad del canal digital se protege con arquitectura y con servicios gestionados, no solo con un firewall perimetral propio.
Pregunta: ¿Por qué la integridad de los datos es un atributo de negocio y no solo un detalle técnico? Respuesta: Porque un dato alterado sin autorización puede provocar decisiones incorrectas (pagos fraudulentos, reportes financieros falsos, registros clínicos manipulados) incluso si el sistema sigue "disponible" y el dato sigue "confidencial". La integridad sostiene la confianza en la información; sin ella, los sistemas analíticos y transaccionales pierden valor, y el impacto puede ser mayor que el de una caída temporal.
Pregunta: ¿Qué papel juega Security Command Center en un programa de seguridad de negocio? Respuesta: Aporta visibilidad y evidencia: inventario de activos, hallazgos de configuraciones inseguras y amenazas, y métricas de postura que permiten gestionar el riesgo con indicadores (hallazgos críticos abiertos, tiempo de remediación, activos expuestos) en lugar de impresiones. Para un líder, es la base de la conversación trimestral de riesgo con auditoría y con el comité de dirección. Sin esa visibilidad, la organización opera a ciegas: cree que es más segura de lo que es, y descubre la exposición cuando ya es un incidente, no cuando era un hallazgo corregible. La herramienta no sustituye el juicio de riesgo; lo alimenta con datos concretos y accionables que permiten priorizar donde el impacto de negocio es mayor.