Preguntas de entrevista de Cloud Security Engineer

No. La nube funciona con un modelo de responsabilidad compartida: el proveedor asegura la infraestructura subyacente («seguridad de la nube»), pero tú sigues siendo responsable de tus datos, la gestión de identidades y accesos, la configuración y — en IaaS — el sistema operativo y los parches («seguridad en la nube»). La gran mayoría de las brechas en la nube son errores de configuración del cliente, como buckets públicos e IAM demasiado permisivo, no fallos del proveedor. Suponer que el proveedor asegura tus datos es justamente cómo ocurren esas brechas.

No. El NAT (y el PAT) asigna direcciones privadas a una IP pública y, como efecto secundario, descarta las conexiones entrantes no solicitadas porque no existe ninguna correspondencia para ellas. Eso no es una política de seguridad — no hay inspección, ni reglas, ni registro — y la travesía de NAT, el hole punching y el C2 iniciado en salida pasan sin problema. El NAT es una herramienta de direccionamiento; aun así necesitas un cortafuegos real. «NAT = cortafuegos» es la idea equivocada.

Un modelo de terceros es una dependencia de cadena de suministro: verifica que provenga de una fuente de confianza con sumas de verificación/firmas coincidentes, que su licencia permita tu uso, y que el formato de archivo no ejecute código arbitrario al cargarse (prefiere serialización segura frente a formatos tipo pickle). «Se carga» y «velocidad de descarga» no dicen nada sobre la confianza, y suponer que los modelos públicos son seguros ignora los riesgos reales de envenenamiento y deserialización.

SSLv3, TLS 1.0 y RC4 están rotos u obsoletos y permiten ataques de downgrade y descifrado, así que desactívelos y exija TLS 1.2 o 1.3 con suites de cifrado fuertes y con forward secrecy, aceptando la rara pérdida de clientes muy antiguos. Dejarlos activos por compatibilidad mantiene la debilidad explotable. Añadir un segundo certificado o pasar a uno autofirmado no elimina los protocolos débiles, y el autofirmado daña la confianza sin arreglar la criptografía.

Las cuentas de servicio sin usar y con permisos excesivos son objetivos preferentes y una gran superficie de ataque. Inventaríelas, desactive o elimine las no usadas (vigilando roturas), ajuste las supervivientes al mínimo privilegio y dé a cada una un propietario y una revisión recurrente. Dejarlas es un riesgo permanente, darles acceso admin general maximiza el radio de impacto, y consolidar todo en una sola cuenta compartida destruye el mínimo privilegio y la rendición de cuentas.

Como los firewalls evalúan las reglas de arriba abajo, una regla any/any amplia cerca de la parte superior cortocircuita todas las reglas inferiores y permite todo el tráfico — el firewall deja en la práctica de aplicar nada. Reemplácela por reglas explícitas de mínimo privilegio para los flujos realmente necesarios, ordenadas para que los permisos y denegaciones específicos surtan efecto, terminando en una denegación por defecto. Llamarla eficiente es erróneo, moverla al final aún puede ocultar la denegación por defecto, y renombrarla no cambia nada de lo que permite.

Sin registros de auditoría del plano de control estás ciego ante quién hizo qué a nivel de nube, y la detección, la forense y el cumplimiento dependen de ese registro. Activa CloudTrail de inmediato, a nivel de organización, entregando a un bucket separado, con acceso controlado y resistente a manipulación (inmutable). Decir que no importa mientras nada vaya mal ignora que no tendrías historial cuando algo vaya mal. Esperar a un incidente significa que las primeras acciones decisivas ya quedan sin registrar e irrecuperables. Los registros de aplicación no capturan la actividad de API, IAM ni consola del plano de control.

Los puertos de administración abiertos a todo Internet se escanean y atacan por fuerza bruta en minutos, así que la solución es reducir la superficie de ataque: restringe el ingreso del security group a CIDR de administración conocidos o VPN, o elimina por completo el tráfico entrante usando un bastión o SSM Session Manager. Mover SSH a un puerto no estándar es seguridad por oscuridad que los escáneres vencen de forma trivial. Una contraseña más fuerte no reduce la superficie expuesta ni detiene el credential stuffing. Confiar en un firewall de host ignora la superficie de ataque que el security group anuncia abiertamente a Internet.

Los datos de clientes expuestos públicamente son una exposición activa: remedia primero el acceso activando Block Public Access y corrigiendo la política del bucket y la política IAM para detener la fuga en curso. Luego extrae los registros de acceso (S3 server access logs / eventos de datos de CloudTrail) para evaluar qué se alcanzó realmente y activa los procesos de brecha y notificación según la política. Abrir un ticket para el próximo sprint deja datos regulados expuestos durante días. Copiar los datos a otro sitio crea una segunda copia pero deja el bucket original abierto. Renombrar no cambia nada de sus permisos.

Los secretos deben vivir en un almacén gestionado con control de acceso, auditoría y rotación, inyectados en runtime, nunca versionados en el control de código. Usa un gestor de secretos (AWS Secrets Manager, HashiCorp Vault) y elimina los valores versionados del historial, luego rótalos porque deben tratarse como comprometidos. El base64 es codificación, no protección: cualquiera puede decodificarlo. Un repo privado sigue propagando el secreto a todos con acceso de clonación, además de los sistemas de CI y los forks. Compilarlo en el binario solo oculta un secreto que sigue siendo trivial de extraer.

Una clave estática incrustada en una imagen se filtra con facilidad y vive para siempre, así que la solución es eliminar por completo la credencial de larga duración: adjunta un rol IAM mediante un perfil de instancia, que entrega credenciales temporales rotadas automáticamente sin nada incrustado. La rotación manual cada 90 días sigue dejando un secreto de larga duración en la AMI entre rotaciones. Mover la clave a una variable de entorno no la hace menos estática ni menos filtrada. Enviarla por correo al equipo de operaciones propaga la exposición a buzones y archivos.

El cambio manual en la consola es deriva de configuración: el próximo terraform apply puede revertir en silencio el arreglo, y el cambio además se saltó la revisión y la auditoría. Reconcílialo codificando el cambio en Terraform, ejecutando plan/apply para que el código y la realidad coincidan, y añadiendo salvaguardas contra cambios ad hoc en la consola (acceso a consola con mínimo privilegio, SCP, detección de deriva). No hacer nada deja una mina para el próximo apply. Borrar el estado de Terraform es destructivo y puede dejar recursos huérfanos o duplicados. Abandonar Terraform tira por la borda la reproducibilidad, la revisión y los rastros de auditoría.

Un rol de instancia con privilegios excesivos convierte cualquier fallo a nivel de aplicación —especialmente un SSRF que alcanza el servicio de metadatos de la instancia— en una toma de control total de la cuenta, porque el atacante hereda las credenciales del rol. Sustituye el comodín por las acciones mínimas y los ARN de recursos que la carga de trabajo usa realmente, y exige IMDSv2 para endurecer el endpoint de metadatos. Una VPC no restringe el IAM en absoluto. Una sola regla de denegación es un juego del topo que deja todo lo demás permitido. Un balanceador de carga es irrelevante para el alcance del daño de la credencial.

Mínimo privilegio más acceso justo-a-tiempo: concede los permisos mínimos necesarios, acotados en el tiempo y registrados, para que depurar sea posible sin un admin permanente que se convierte en un riesgo duradero y un punto ciego de auditoría. Un cluster-admin permanente viola el mínimo privilegio y amplía el radio de impacto de cualquier compromiso. Una negación total bloquea el trabajo legítimo e invita a apaños paralelos arriesgados. Compartir la credencial común de la cuenta de servicio admin destruye la rendición de cuentas — las acciones no se pueden atribuir a una persona.

Trata cualquier secreto subido como quemado: revócalo y rótalo primero, porque los bots rastrean los commits públicos en segundos, luego revisa CloudTrail en busca de abusos y purga el secreto del historial. Borrar el commit no sirve de nada — la clave ya está clonada, bifurcada y cacheada por terceros. Hacer el repo privado deja una clave ya filtrada y activa en manos de los atacantes. Añadir el archivo al .gitignore no cambia nada para un secreto ya commiteado.

Parte de una imagen base mínima y de confianza (distroless o slim) para reducir la superficie de ataque, escanea las imágenes en busca de CVE conocidas en la CI y en el registro, fija y verifica los digests de las imágenes, ejecuta con un usuario no-root y evita incrustar secretos. Firma las imágenes y aplica políticas de admisión para que solo se ejecuten imágenes escaneadas y firmadas. Reconstruye con regularidad para que las capas base parcheadas se propaguen.

El cifrado en tránsito (TLS) protege los datos que se mueven por la red frente a la escucha y la manipulación; aplica TLS en todas partes y rechaza el texto plano. El cifrado en reposo protege los datos almacenados en discos y copias de seguridad, normalmente mediante claves gestionadas por KMS usando cifrado por sobre. Ambos son controles básicos, pero ninguno detiene una solicitud autorizada pero maliciosa — el servicio descifra de forma transparente para los llamantes válidos — así que el control de acceso sigue siendo lo más importante.

Un usuario es una identidad de larga duración con credenciales permanentes; un rol es una identidad sin credenciales permanentes que cualquier principal de confianza puede asumir para obtener tokens de corta duración; una política es el documento JSON que concede permisos, adjunto a cualquiera de los dos. El privilegio mínimo significa preferir roles a usuarios, acotar las políticas a acciones y recursos específicos, y conceder solo lo que una tarea necesita — y luego revisar y depurar con el tiempo.

IMDS es un endpoint link-local (169.254.169.254) que da a una instancia sus metadatos, incluidas las credenciales temporales de su rol IAM adjunto. El SSRF puede engañar al servidor para que recupere esa URL y filtre esas credenciales. IMDSv2 exige un PUT para obtener un token de sesión de corta duración, fija un TTL/límite de saltos de IP por defecto de 1, y rechaza solicitudes con ciertas cabeceras — de modo que un simple GET de SSRF ya no puede alcanzarlo.

El RBAC controla qué pueden hacer las identidades contra la API de Kubernetes — los Roles y ClusterRoles conceden verbos sobre recursos, vinculados a sujetos vía RoleBindings — y debe seguir el privilegio mínimo, evitando cluster-admin y comodines. Las políticas de red controlan el tráfico de pod a pod, que permite todo por defecto hasta que aplicas un default-deny y luego permites explícitamente los flujos requeridos. Juntos limitan el radio de impacto si un pod o token se ve comprometido.

CloudTrail registra cada llamada a la API en la cuenta — quién hizo qué, cuándo, desde dónde — dándote el rastro de auditoría con autoridad para investigaciones y cumplimiento. GuardDuty es un servicio gestionado de detección de amenazas que analiza CloudTrail, los flujos de VPC y los registros de DNS para sacar a la luz hallazgos como la exfiltración de credenciales o la minería de criptomonedas. CloudTrail es la fuente de verdad que debes proteger; GuardDuty convierte esa telemetría en alertas accionables.

Los errores clásicos son ACL públicas o políticas de bucket que permiten acceso anónimo o a todos los usuarios de AWS, principales demasiado amplios o acciones con comodín, ausencia de cifrado por defecto y falta de registro. Se previenen activando Block Public Access a nivel de cuenta, usando políticas IAM/bucket con privilegio mínimo, exigiendo cifrado por defecto y TLS, y activando el registro de accesos y reglas de Config para detectar desviaciones.

Almacena los secretos en un servicio gestionado dedicado (Secrets Manager, Parameter Store, Vault), cifrados con una clave de KMS, y concede el acceso mediante roles IAM para que las cargas de trabajo los recuperen en tiempo de ejecución con credenciales de corta duración. Nunca incrustes secretos en el código, las imágenes de contenedor o archivos .env versionados. Añade rotación automática, políticas de clave acotadas y registro de auditoría para que cada recuperación sea rastreable.

Los security groups son cortafuegos con estado adjuntos a instancias/ENI: solo tienen reglas de permitir, y el tráfico de retorno de un flujo permitido se autoriza automáticamente. Las network ACL son filtros sin estado en el límite de la subred: tienen reglas ordenadas de permitir y denegar, y debes permitir explícitamente el tráfico de retorno en los puertos efímeros. Los security groups son el control principal; las NACL añaden barreras gruesas a nivel de subred, como bloquear un rango de IP.

El proveedor asegura la nube en sí — centros de datos físicos, hardware, el hipervisor y los servicios gestionados que ejecuta. Tú aseguras lo que pones en la nube — tus datos, identidades, configuraciones, el parcheo del SO cuando corresponda, y los controles de acceso. La línea exacta se desplaza: con IaaS eres dueño desde el SO hacia arriba, con SaaS eres dueño sobre todo de los datos y el acceso.

La CI/CD es de alto valor porque guarda las credenciales de despliegue y ejecuta código no confiable. Los riesgos incluyen dependencias y acciones de build comprometidas, secretos filtrados o demasiado amplios, acciones de terceros mutables, y runners o confianza OIDC con privilegios excesivos. Redúcelos con dependencias fijadas y verificadas, federación OIDC de corta duración en vez de claves de larga duración, privilegio mínimo acotado a repos/ramas concretos, runners efímeros aislados, y artefactos firmados con procedencia rastreada (SLSA).

La aplicación redirige al usuario al servidor de autorización para iniciar sesión y dar consentimiento. El servidor redirige de vuelta con un código de autorización de corta duración. El backend de la aplicación intercambia luego ese código (más su secreto de cliente) en el endpoint de token por un token de acceso, sobre un canal trasero de servidor a servidor. Esto mantiene los tokens fuera del navegador/la URL. Los clientes públicos añaden PKCE para vincular el código al solicitante original.

El SSO centraliza la autenticación en un proveedor de identidad (IdP). Cuando un usuario visita un proveedor de servicio (la app), la app redirige al IdP; el usuario inicia sesión una vez, y el IdP devuelve una aserción o token firmado que avala su identidad. SAML lo lleva como una aserción XML firmada; OIDC lo lleva como un token de identidad JSON firmado montado sobre OAuth 2.0. La app confía en la firma del IdP en lugar de manejar las contraseñas ella misma.

La firma vincula criptográficamente un artefacto con su productor, para que los consumidores puedan verificar que no fue manipulado ni sustituido. La procedencia son metadatos firmados que describen cómo, dónde y a partir de qué fuente se construyó el artefacto. Juntas — mediante herramientas como Sigstore para la firma sin claves y el framework SLSA para los niveles de procedencia — permiten a quien despliega verificar que una imagen proviene del pipeline y la fuente esperados, frustrando la manipulación y los ataques de sustitución de dependencias.

Escanea las imágenes en busca de CVE conocidas en paquetes del SO y bibliotecas de la app, además de configuraciones erróneas y secretos incrustados, tanto en el momento del build como de forma continua en el registro — porque aparecen nuevas CVE después de construir una imagen. Usa imágenes base mínimas o distroless para reducir la superficie de ataque, fija y referencia las imágenes base por digest, y ejecuta el contenedor como no-root. El escaneo es necesario pero no sustituye a la protección en runtime.

El escaneo de IaC analiza estáticamente definiciones de Terraform, CloudFormation, Kubernetes y similares contra una política para detectar configuraciones erróneas — buckets S3 públicos, grupos de seguridad abiertos, cifrado ausente — antes de que se aprovisionen. Como la misma plantilla aprovisiona muchos recursos, corregirla una vez evita la deriva repetida, y detectarlo antes de aplicar es mucho más barato que remediar recursos cloud en producción. Las herramientas incluyen Checkov, tfsec y KICS, idealmente aplicadas como barreras de policy-as-code.

Trata el pipeline como infraestructura de producción: contiene las credenciales para entregar código y llegar a producción, así que comprometerlo evita todos los controles posteriores. Endurécelo con runners aislados y efímeros; tokens de mínimo privilegio y corta duración (federación OIDC en vez de secretos de larga duración); ramas protegidas y config de pipeline revisada; acciones de terceros fijadas por digest; y registro de auditoría completo. El pipeline es un objetivo de primer nivel, no fontanería.

Un SBOM es un inventario legible por máquina de cada componente, biblioteca y dependencia de un software, con versiones e idealmente hashes. Importa porque cuando aparece una nueva vulnerabilidad, puedes consultar tus SBOM para responder al instante a «¿estamos afectados y dónde?» en lugar de improvisar. Los dos estándares dominantes son SPDX y CycloneDX, y los SBOM son cada vez más exigidos por la normativa y las compras.

El mínimo privilegio significa que cada usuario, proceso y servicio recibe solo el acceso mínimo necesario para su tarea, y nada más. Limita el radio de impacto de una cuenta comprometida, reduce el riesgo de amenaza interna y disminuye la superficie de ataque. Se aplica mediante acceso basado en roles, revisiones de acceso periódicas y elevación justo a tiempo.

La MFA exige dos o más factores de autenticación de categorías diferentes — algo que sabes (contraseña), algo que tienes (teléfono/token), algo que eres (biometría). Ayuda porque un atacante que roba un factor, como una contraseña, aún no puede iniciar sesión sin los demás. La MFA resistente al phishing como FIDO2 es la más fuerte.

Un firewall controla el tráfico entre zonas de red permitiéndolo o denegándolo según reglas. Un firewall sin estado evalúa cada paquete de forma aislada frente a las reglas; un firewall con estado rastrea el estado de las conexiones para permitir el tráfico de retorno de las sesiones que autorizó. Los firewalls de nueva generación añaden conocimiento de la capa de aplicación.

El acceso condicional hace que la decisión de acceso dependa del contexto en lugar de una regla fija. Evalúa señales —quién es el usuario, el cumplimiento del dispositivo, la ubicación, la aplicación y una puntuación de riesgo calculada por detección de anomalías— y responde de forma proporcional: permitir, bloquear o exigir un refuerzo como MFA o un dispositivo conforme. El acceso basado en riesgo es la variante dinámica donde una señal de riesgo en tiempo real impulsa la política.

La federación de identidades establece confianza entre un proveedor de identidad (IdP) que autentica usuarios y proveedores de servicios (partes de confianza) que consumen esa autenticación. El IdP verifica al usuario y emite una aserción o token firmado; el proveedor de servicios confía en él en lugar de gestionar sus propias credenciales. Esto habilita el SSO entre dominios y el control centralizado, pero concentra el riesgo: si comprometes el IdP, comprometes todo lo que confía en él.

El acceso justo a tiempo concede privilegios elevados solo cuando se necesitan, por un tiempo limitado, normalmente con aprobación; luego expiran automáticamente, de modo que no hay privilegio permanente que robar. Las cuentas de emergencia (break-glass) son la excepción deliberada: cuentas de emergencia muy privilegiadas, normalmente inactivas, bloqueadas tras controles estrictos y fuertes alertas, usadas solo cuando fallan las vías de acceso normales. El JIT reduce la superficie de ataque cotidiana; el break-glass garantiza que aún puedes entrar durante una crisis.

El RBAC concede permisos mediante roles asignados a usuarios: sencillo de razonar pero propenso a la explosión de roles a medida que se multiplican los casos límite. El ABAC evalúa políticas sobre atributos del usuario, el recurso, la acción y el entorno, por lo que escala a decisiones finas y contextuales a costa de complejidad. La mayoría de los sistemas maduros los combinan: roles para concesiones generales, atributos y políticas para los detalles condicionales.

SCIM (System for Cross-domain Identity Management) es una API REST/JSON y un esquema estándar para crear, actualizar y eliminar cuentas de usuario en todas las aplicaciones. Conectado a un sistema de RR. HH. o a un IdP, automatiza el ciclo de vida joiner-mover-leaver: las cuentas y los permisos se aprovisionan en la contratación, se ajustan en el cambio de rol y —lo más importante— se desaprovisionan en la salida, eliminando las cuentas huérfanas que tanto gustan a los atacantes.

Mantén los access tokens de corta duración (minutos) para que uno robado expire rápido, y usa refresh tokens de mayor duración para obtener nuevos access tokens sin volver a pedírselo al usuario. Rota los refresh tokens en cada uso y detecta la reutilización de un token ya consumido como señal de robo, revocando la cadena. El objetivo es equilibrar la limitación de la ventana de un token comprometido frente a no obligar a los usuarios a reautenticarse constantemente.

Zero Trust descarta la suposición de que estar dentro de la red te hace de confianza. Cada petición a un recurso se autentica y autoriza por sus propios méritos —verificando identidad, salud del dispositivo y contexto— mediante un policy decision point, concediendo acceso de mínimo privilegio por sesión. No hay zona interna de confianza; la ubicación de red de una petición es solo una señal más, no un pase libre.

Reducir la superficie de ataque (eliminar paquetes y servicios sin uso), forzar SSH solo por clave sin inicio de sesión root, mantener el sistema parcheado, ejecutar un cortafuegos de denegación por defecto que exponga solo los puertos necesarios, aplicar privilegios mínimos mediante sudo y permisos de archivos, habilitar auditd y registro centralizado, y añadir monitorización de integridad más un MAC como SELinux o AppArmor.

El privilegio mínimo significa que cada usuario, proceso o servicio obtiene solo el acceso mínimo necesario para su tarea, y nada más. Reduce el radio de impacto de cualquier compromiso o error. Se aplica con acceso basado en roles, elevación just-in-time, revisiones de acceso periódicas y la eliminación de derechos de administrador permanentes.

Nunca codifiques secretos en el código fuente ni los subas a git. Guárdalos en un gestor de secretos o bóveda dedicada, inyéctalos en tiempo de ejecución, acota el acceso con privilegios mínimos, rótalos con regularidad y prefiere credenciales dinámicas de corta duración frente a las estáticas persistentes. Audita cada acceso.

Forzar TLS en todas partes, autenticar cada solicitud (p. ej. tokens OAuth2/OIDC) y autorizar por objeto para que los usuarios solo alcancen sus propios datos. Añade validación de entradas, limitación de tasa y cuotas, validación de esquema y registro exhaustivo. El fallo de API más común es la autorización a nivel de objeto rota, así que comprueba la propiedad en cada acceso a un recurso.

La segmentación divide una red en zonas aisladas para que una brecha en una no pueda alcanzar libremente a las demás, limitando el movimiento lateral. Zero trust va más allá: elimina por completo la confianza implícita basada en la ubicación de red, autenticando y autorizando cada solicitud venga de donde venga — la microsegmentación es una forma de implementarlo.

El SSRF engaña a un servidor para que realice peticiones HTTP (u otras) a un destino elegido por el atacante, abusando de la posición de red del servidor para alcanzar servicios internos tras el cortafuegos. En la nube es especialmente grave porque el servicio de metadatos de instancia (por ejemplo, 169.254.169.254) puede devolver credenciales IAM, convirtiendo un SSRF en un compromiso de la cuenta en la nube.