CompTIA SY0-701: Seguridad de Cloud, Virtualización y Contenedores — Guía de estudio

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Forma parte de la CompTIA Security+ SY0-701 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de CompTIA, o realiza tests cronometrados en ExamRoll.io.

Las empresas modernas rara vez operan en un único centro de datos autónomo. Las cargas de trabajo se extienden por proveedores de nube pública, clústeres de virtualización privados, orquestadores de contenedores y funciones efímeras sin servidor (serverless). Cada capa de abstracción cambia el modelo de amenazas, la superficie de control y, de manera crítica, quién es responsable de qué controles de seguridad.

El modelo de responsabilidad compartida

Cada proveedor de nube importante publica un modelo de responsabilidad compartida que divide las tareas de seguridad entre el cliente y el proveedor de servicios en la nube (CSP). La línea divisoria cambia según el nivel de servicio.

En la Infraestructura como Servicio (IaaS) —Amazon EC2, Azure Virtual Machines, Google Compute Engine—, el CSP asegura las instalaciones físicas, el hardware, el hipervisor y la infraestructura de red. Todo lo que está por encima del hipervisor pertenece al cliente: el sistema operativo invitado, la aplicación de parches, los firewalls basados en host, el middleware, el entorno de ejecución, el código de la aplicación, la configuración de identidades y los propios datos. Si una empresa despliega una base de datos MySQL en una instancia EC2, asegurar esa base de datos es responsabilidad exclusiva del cliente.

En la Plataforma como Servicio (PaaS) —AWS RDS, Azure App Service, Google App Engine—, el proveedor gestiona además el sistema operativo, la aplicación de parches del motor de la base de datos y el entorno de ejecución. El cliente sigue siendo responsable del código de la aplicación, la clasificación de los datos, los controles de acceso, las reglas de exposición de la red y la gestión de identidades.

En el Software como Servicio (SaaS) —Microsoft 365, Salesforce, Workday—, el proveedor se encarga de casi toda la pila tecnológica. Las responsabilidades restantes del cliente no son triviales: el aprovisionamiento y desaprovisionamiento de cuentas, la aplicación de MFA, la clasificación de datos, los permisos para compartir, la configuración de DLP y la integración con el proveedor de identidades corporativo. Un sitio de SharePoint mal configurado que expone datos de nóminas a «Todos» no es una brecha de seguridad de Microsoft, sino del administrador del tenant.

Un error persistente es creer que migrar a la nube transfiere toda la responsabilidad de la seguridad al proveedor. Las brechas de datos que involucran buckets de S3 mal configurados, clústeres de Elasticsearch expuestos y claves de API filtradas casi universalmente se deben a errores del lado del cliente, no a una vulneración del CSP.

Virtualización y riesgo del hipervisor

La virtualización agrupa el hardware físico en sistemas invitados lógicos utilizando un hipervisor. Los hipervisores de Tipo 1 (bare-metal) como VMware ESXi, Microsoft Hyper-V y KVM se ejecutan directamente sobre el hardware. Los hipervisores de Tipo 2 (alojados) como VirtualBox se ejecutan sobre un sistema operativo de propósito general y no son adecuados para cargas de trabajo de producción.

Las amenazas dominantes específicas de la virtualización son el escape de VM (VM escape) y la vulneración del hipervisor (hypervisor compromise). El escape de VM ocurre cuando código malicioso dentro de un sistema invitado rompe su límite de virtualización y se ejecuta en el hipervisor o en una VM adyacente. Ejemplos históricos incluyen CVE-2015-3456 (VENOM, en el controlador de disquete de QEMU) y varias vulnerabilidades de VMware Tools. Debido a que un solo hipervisor puede alojar cientos de cargas de trabajo en múltiples zonas de confianza, un escape exitoso proporciona un acceso desproporcionado.

Las mitigaciones incluyen la aplicación rigurosa de parches al hipervisor, la minimización de las adiciones de invitado y del hardware emulado no utilizado, la separación de cargas de trabajo por sensibilidad en clústeres distintos y el aislamiento del plano de gestión. El servidor vCenter, las interfaces de gestión de ESXi y las API del clúster deben residir en una red de gestión dedicada, accesible únicamente desde jump hosts privilegiados con MFA.

Otras preocupaciones incluyen la proliferación de VM (VM sprawl) (VM huérfanas y sin parches que se acumulan con el tiempo) y la reutilización de recursos (resource reuse), donde la memoria o el almacenamiento de una VM retirada no se borra correctamente (puesta a cero) antes de asignarse a otro tenant.

Contenedores, microservicios y el kernel compartido

Los contenedores empaquetan una aplicación con sus dependencias pero, a diferencia de las VM, comparten el kernel del sistema operativo anfitrión. Docker, containerd y CRI-O gestionan los ciclos de vida de los contenedores; Kubernetes los orquesta a escala. Este aislamiento ligero es una ventaja —arranque en milisegundos, empaquetado denso—, pero también el riesgo principal.

El aislamiento de contenedores no es equivalente al aislamiento de VM. Una vulnerabilidad del kernel explotada desde dentro de un contenedor puede comprometer el host y todos los demás contenedores en él. Los namespaces (PID, red, montaje, UTS, IPC, usuario) y los cgroups proporcionan aislamiento, pero son construcciones de software que comparten una única superficie de ataque.

La seguridad de los contenedores requiere controles a lo largo de todo el ciclo de vida:

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Las imágenes deben ser escaneadas en busca de vulnerabilidades antes del despliegue (Trivy, Snyk, Clair), construidas a partir de imágenes base mínimas (distroless o Alpine) y extraídas únicamente de registros de confianza con la firma de imágenes aplicada (Cosign, Notary). Las herramientas de protección en tiempo de ejecución (Falco, Aqua, Sysdig) monitorizan el comportamiento de los contenedores y alertan sobre anomalías como la ejecución de procesos o conexiones de red inesperadas.

Postura de seguridad en la nube e IAM

El IAM de la nube difiere del Active Directory local (on-premises) en aspectos importantes. En AWS, las políticas de IAM son documentos JSON adjuntos a usuarios, grupos o roles, y el permiso efectivo es la intersección de las políticas basadas en la identidad y las políticas basadas en recursos, donde una denegación explícita (deny) siempre prevalece:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

Las herramientas de gestión de la postura de seguridad en la nube (CSPM) escanean continuamente las configuraciones de la nube comparándolas con benchmarks de seguridad (CIS AWS Foundations, NIST), señalando buckets de S3 públicos, grupos de seguridad demasiado permisivos, registros de CloudTrail desactivados y volúmenes EBS sin cifrar. Los agentes de seguridad de acceso a la nube (CASB) se sitúan entre los usuarios y los servicios en la nube, aplicando políticas de DLP, políticas de acceso y detección de amenazas para aplicaciones SaaS.

← Seguridad de Aplicaciones y Web · Todos los dominios · Seguridad de Datos →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →