Preguntas de entrevista de Cloud

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.

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.

Recuperar del lado del servidor URLs controladas por el atacante es Server-Side Request Forgery (SSRF): permite alcanzar servicios internos o el endpoint de metadatos del cloud para robar credenciales. Mitíguelo con una allow-list de hosts y esquemas permitidos, bloqueando rangos privados y link-local (revisando de nuevo tras cada redirección) y endureciendo el acceso a metadatos con IMDSv2. Decir que no hay riesgo ignora el acceso que concede la petición, y un spinner de carga o una caché no cambian nada sobre dónde puede conectarse el servidor.

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.

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.

La cadena de suministro de LLM abarca modelos base, variantes fine-tuneadas, datasets, embeddings, plugins, librerías y la plataforma de alojamiento, cada uno un lugar para introducir riesgo. Las amenazas incluyen descargar pesos de modelo manipulados o con backdoor, fine-tunes maliciosos, datasets envenenados o con licencia contaminada, plugins vulnerables o sobreprivilegiados, y repos de modelos con typosquatting. Defensas: obtener modelos de registros de confianza, verificar integridad y procedencia, mantener un AI bill of materials, escanear y fijar dependencias, verificar plugins y aplicar mínimo privilegio a todo lo que el modelo integre.

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 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.

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.

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.

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.

El modelado de amenazas responde a cuatro preguntas: qué estamos construyendo, qué puede salir mal, qué hacemos al respecto y si hicimos un buen trabajo. Diagramas el sistema (a menudo un diagrama de flujo de datos con fronteras de confianza), enumeras amenazas con un marco como STRIDE, priorizas por riesgo y asignas mitigaciones. PASTA añade un matiz centrado en el riesgo y el atacante; los árboles de ataque descomponen un único objetivo. Hacerlo en tiempo de diseño es mucho más barato que parchear producción.

La gestión de vulnerabilidades es un ciclo continuo: descubrir activos y vulnerabilidades (escaneo, inventario de activos), priorizar por riesgo real (CVSS más explotabilidad, exposición y criticidad de los activos — marcos como EPSS y SSVC ayudan), remediar o mitigar, verificar la corrección e informar sobre tendencias y SLA. El escaneo es la parte fácil; la disciplina está en priorizar y cerrar el ciclo para que el riesgo realmente baje con el tiempo.

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.

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.