Glosario

En ABAC los permisos se expresan con atributos —en AWS, etiquetas— en lugar de listas explícitas de recursos. Una única política puede decir «puedes actuar sobre los recursos cuyo equipo coincide con el tuyo» usando condiciones como aws:PrincipalTag/equipo frente a aws:ResourceTag/equipo.

Su ventaja es que escala sin reescribir políticas: al crear un recurso nuevo con la etiqueta correcta, quien ya tiene el atributo obtiene acceso automáticamente. A cambio, exige gobernar bien las etiquetas (quién puede ponerlas y cambiarlas), porque quien controla un tag controla el acceso.

La excessive agency (LLM06 del OWASP Top 10 for LLM Applications) es el daño que un agente puede causar cuando se le concede demasiada funcionalidad (herramientas que no necesita), demasiados permisos (credenciales amplias en esas herramientas) o demasiada autonomía (actúa sin confirmación humana). El problema no es que el modelo “quiera” hacer daño, sino que una entrada manipulada o una alucinación se traduzcan en acciones con consecuencias: borrar datos, enviar dinero, cambiar permisos.

Se mitiga con mínimo privilegio aplicado al agente: dale solo las herramientas imprescindibles, con el alcance mínimo, y exige aprobación humana para las acciones irreversibles o sensibles. Es la razón por la que la identidad y la autorización del agente (quién es y qué puede hacer cada herramienta) son el control central de la seguridad de agentes.

Un agente de IA es un LLM metido en un bucle: recibe un objetivo, pide una herramienta (tool calling), la orquestación la ejecuta y le devuelve el resultado, y el modelo decide el siguiente paso hasta terminar o agotar un límite. Puede planificar, mantener memoria entre pasos y actuar con autoridad delegada: permisos sobre sistemas reales.

Esa autonomía es lo que lo distingue de un chatbot y lo que multiplica su superficie de ataque: memoria envenenada, abuso de herramientas, exfiltración a través de llamadas legítimas y fallos en cascada entre agentes. Necesita su propia identidad, herramientas con alcance mínimo y un límite de pasos. Ver Amenazas de agentes, MCP y MITRE ATLAS.

Un LLM genera el texto más plausible, no el más verdadero. Cuando no sabe, no calla: inventa con el mismo aplomo con que acierta. Eso es una alucinación, y en seguridad importa porque las personas tienden a confiar en una respuesta bien redactada. Es el núcleo de LLM09:2025 (Misinformation), y se vuelve un ataque cuando un adversario puede predecir qué se inventa el modelo, como en el slopsquatting.

Amazon Bedrock AgentCore es un conjunto de servicios modulares para llevar agentes a producción con independencia del framework (LangGraph, CrewAI, Strands…) y del modelo. Sus módulos clave para seguridad son AgentCore Identity (identidad propia del agente y vault de tokens con credenciales delegadas OAuth), AgentCore Gateway (convierte APIs y funciones Lambda en herramientas y conecta con servidores MCP) y AgentCore Observability (trazas y métricas de cada acción).

La autorización de herramientas se controla con Policy in AgentCore, que evalúa políticas en lenguaje Cedar sobre el Gateway (GA marzo 2026). El AgentCore Code Interpreter ejecuta en un sandbox aislado el código que genera el agente.

Amazon Bedrock Guardrails aplica políticas sobre lo que entra y sale de un modelo, con independencia del modelo usado. Incluye filtros de contenido (odio, insultos, violencia, conducta indebida y prompt attack), temas prohibidos, filtros de palabras, filtros de información sensible (bloquea o enmascara PII) y comprobaciones de fundamentación contextual contra alucinaciones.

En 2025 sumó Automated Reasoning checks (verificación lógica de las respuestas frente a una política) y niveles de detección multilingües. Para un agente es la capa que mira el contenido que Cedar no inspecciona.

Amazon Detective no genera alertas: investiga las que ya tienes. Ingiere de forma continua eventos de CloudTrail, VPC Flow Logs, los hallazgos de GuardDuty y los logs de auditoría de EKS, y los une en un grafo de comportamiento (behavior graph) que relaciona identidades, recursos e IPs a lo largo del tiempo.

Cuando abres un hallazgo, Detective te muestra la línea base de esa identidad, qué hizo antes y después, desde qué IPs y con qué volumen, para responder rápido a “¿esto es normal para este principal?”. Reduce el trabajo manual de correlacionar logs durante el triaje.

EventBridge recibe eventos de los servicios de AWS, de tus propias aplicaciones y de SaaS, y los entrega a destinos según reglas con un patrón de evento (event pattern) en JSON. Es el pegamento de la auto-remediación: un hallazgo de GuardDuty o un evento de CloudTrail dispara una regla que invoca Lambda, Step Functions o SNS.

El patrón coincide por campos del evento (source, detail-type, detail.severity, detail.type…). Para reaccionar a hallazgos usas "source": ["aws.guardduty"] con "detail-type": ["GuardDuty Finding"] y filtras por severidad o tipo. EventBridge era antes CloudWatch Events; el bus por defecto recibe los eventos de los servicios de AWS.

Combina inteligencia de amenazas (IPs maliciosas, Tor) con modelos de anomalías por identidad. Ejemplos de hallazgos: Stealth:IAMUser/CloudTrailLoggingDisabled o Exfiltration:S3/AnomalousBehavior.

S3 Protection analiza eventos de datos de S3 sin que tengas que activarlos en tu propio trail. Para tus consultas y tu forense sí los necesitas en el trail.

Amazon Inspector descubre y escanea automáticamente tus cargas de trabajo sin agentes que mantener a mano: instancias EC2, imágenes de contenedor en ECR y funciones Lambda (dependencias y, con el escaneo de código, el propio código). Correlaciona el inventario de software con bases de CVEs y marca lo explotable.

Cada hallazgo lleva una puntuación de riesgo (Inspector score) que ajusta el CVSS con contexto —si el recurso es accesible desde internet, si hay exploit conocido— para que priorices lo que de verdad importa. Publica sus hallazgos en Security Hub.

Amazon Macie descubre y clasifica datos sensibles en S3. Mantiene un inventario de tus buckets y aplica managed data identifiers (y, si quieres, identificadores personalizados por regex) para detectar PII, datos financieros y credenciales dentro de los objetos.

Trabaja de dos formas: automated sensitive data discovery, que evalúa a diario el inventario y muestrea objetos para dar visibilidad amplia, y los sensitive data discovery jobs, análisis dirigidos y repetibles sobre buckets concretos. Genera findings (hallazgos de datos sensibles) con un esquema estándar que puedes enrutar a Security Hub o EventBridge. Para analizar objetos cifrados con una KMS key, la key policy debe permitir que Macie la use.

Amazon Security Lake centraliza datos de seguridad —CloudTrail, VPC Flow Logs, Route 53 Resolver query logs, hallazgos de Security Hub y fuentes de terceros— en un data lake sobre S3 que vive en tu cuenta. Automáticamente normaliza las fuentes al esquema abierto OCSF y las almacena en Apache Parquet, particionado y listo para consultar.

Una vez normalizado, consultas el mismo modelo con Athena, OpenSearch o tu SIEM sin reinventar un parser por fuente. Gestiona retención, rotación y ciclo de vida, y se integra con AWS Organizations para una vista multicuenta.

Técnica de modelado de amenazas popularizada por Bruce Schneier en 1999. La raíz es el objetivo del atacante; los nodos OR son alternativas y los AND, pasos que hacen falta todos; las hojas son acciones concretas.

Al asignar atributos a las hojas (coste, habilidad, posible/imposible) y propagarlos hacia arriba (en coste: OR = mínimo, AND = suma) se obtiene el camino crítico, el más barato para el atacante, que es donde conviene mitigar primero.

La ASR (attack success rate) es la métrica habitual en la literatura de jailbreaks. Dos números de ASR rara vez son comparables: cambia quién juzga si la respuesta fue dañina, cuántos intentos se permiten (por intento o «al menos uno de n») y qué modelo y defensas se evalúan (con o sin clasificadores de producción).

AWS Audit Manager automatiza la recopilación de evidencia para auditorías. En lugar de capturar manualmente configuraciones y registros, crea una assessment a partir de un framework (marco) y recoge evidencia de forma continua de servicios como CloudTrail, AWS Config, Security Hub y llamadas a la API.

Trae frameworks predefinidos alineados con estándares conocidos (CIS AWS Foundations Benchmark, SOC 2, PCI DSS, NIST, GDPR y otros) y permite crear marcos personalizados. Cada control del marco se asocia a data sources que producen la evidencia, que Audit Manager organiza, versiona y empaqueta en un assessment report listo para entregar al auditor. Resuelve el problema de la evidencia dispersa y manual: la convierte en un flujo continuo y trazable.

Los eventos de gestión (crear, modificar o borrar recursos) se registran por defecto y el historial de eventos guarda 90 días. Los eventos de datos (p. ej. GetObject en S3) son de alto volumen y hay que activarlos explícitamente en un trail o event data store.

Para detección y forense se usa un trail organizacional que entrega a una cuenta de archivo de logs aislada, con validación de integridad activada.

AWS Config mantiene un grabador de configuración (configuration recorder) que toma una instantánea de cada recurso cada vez que cambia, guardando el historial de “cómo estaba este recurso el martes”. Sobre ese estado aplica reglas (managed o personalizadas con Lambda) que marcan cada recurso como COMPLIANT o NON_COMPLIANT.

Las reglas se agrupan en conformance packs (plantillas de cumplimiento desplegables como una unidad) y pueden disparar remediación automática mediante documentos de SSM Automation. Config es postura: te dice cómo están configurados tus recursos, no detecta actividad maliciosa en tiempo real.

AWS Control Tower automatiza la creación de una landing zone: una organización de AWS multi-cuenta bien estructurada, con cuentas de gestión, de seguridad/auditoría y de archivo de logs, SSO vía IAM Identity Center y una línea base de registro y cifrado ya montada.

Su mecanismo de gobierno son los controles (el término antiguo era guardrails). Hay tres tipos: preventivos, que impiden acciones y se implementan con Service Control Policies (SCP); detectivos, que detectan desviaciones y se implementan con reglas de AWS Config; y proactivos, que bloquean recursos no conformes antes de aprovisionarlos usando CloudFormation Hooks. Cada control se expresa como «obligatorio», «fuertemente recomendado» o «electivo», y Control Tower informa de la conformidad de cada cuenta en un panel único.

Una KMS key (antes CMK) vive dentro del servicio, respaldada por HSMs validados FIPS 140, y nunca se exporta en texto plano. En lugar de cifrar datos directamente, lo normal es usarla como KEK en envelope encryption: cifra pequeñas data keys que a su vez cifran los datos.

El acceso lo gobierna sobre todo la key policy (política basada en recurso de la propia clave): sin una declaración que lo permita, los permisos IAM por sí solos no bastan. Por eso un administrador IAM todopoderoso puede quedarse sin acceso a una llave. Para delegación temporal y programática existen los grants.

AWS Network Firewall es un cortafuegos de red gestionado que despliegas en subredes de firewall dedicadas y a cuyo endpoint rediriges el tráfico de la VPC mediante tablas de rutas. Soporta grupos de reglas stateless (filtrado rápido por 5-tupla) y stateful, estos últimos compatibles con Suricata, lo que permite inspección por dominio (SNI/Host), firmas IDS/IPS y filtrado de protocolos.

Opera por debajo de la capa 7 de aplicación que cubre el WAF: es el control para egreso controlado, segmentación entre VPCs e inspección este-oeste, no un sustituto del WAF ni de los security groups.

Secrets Manager almacena secretos cifrados con KMS y los entrega bajo demanda vía API, de modo que la aplicación los recupera en tiempo de ejecución en lugar de llevarlos en variables de entorno o en el código. El acceso se controla con IAM y con la key policy de la llave que los cifra, y cada recuperación queda en CloudTrail.

Su rasgo distintivo es la rotación automática: para muchas bases de datos usa una función Lambda que crea una versión nueva (AWSPENDING), cambia la credencial en el motor, la prueba y mueve la etiqueta AWSCURRENT a la versión nueva (la vieja pasa a AWSPREVIOUS). La aplicación siempre pide AWSCURRENT, así que recoge la credencial nueva sin cambios de código y la filtrada deja de funcionar.

Security Hub CSPM es la consola única de postura: normaliza en el formato ASFF (AWS Security Finding Format) los hallazgos de GuardDuty, Inspector, Config, Macie y herramientas de terceros, y los deduplica y correlaciona.

Ejecuta estándares de controles automatizados —AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, PCI DSS, NIST SP 800-53— apoyándose en Config, y calcula una puntuación de seguridad por estándar que sube a medida que resuelves hallazgos. Con un administrador delegado en la cuenta de seguridad agrega toda la organización.

En 2025 AWS renombró el producto de postura como Security Hub CSPM y lanzó un AWS Security Hub unificado (sin sufijo, GA en diciembre de 2025) que correlaciona esas señales en exposiciones y rutas de ataque.

La AWS Security Reference Architecture (SRA) es la guía holística de AWS para estructurar y operar los servicios de seguridad en una organización de AWS Organizations. No es un servicio: es un conjunto de recomendaciones y código de ejemplo que describe dónde colocar cada control.

Su recomendación central es separar responsabilidades en cuentas dedicadas: una cuenta de gestión (management) solo para facturación y gobierno, una cuenta de Security Tooling (a veces llamada security/audit) que concentra la administración de los servicios de seguridad, y una cuenta de Log Archive que recibe de forma inmutable los logs de toda la organización (CloudTrail, Config, VPC Flow Logs). La SRA insiste en usar administradores delegados: en lugar de operar Security Hub, GuardDuty, Config o IAM Access Analyzer desde la cuenta de gestión (muy privilegiada), se delega su administración a la cuenta de Security Tooling.

BOLA (Broken Object Level Authorization) es el riesgo número uno del OWASP API Security Top 10. Ocurre cuando un endpoint autentica quién eres pero no comprueba que el objeto que pides (/citas/123) te pertenece: cambiando el id por el de otro usuario, obtienes sus datos.

Es la versión por API de lo que en aplicaciones clásicas se llama IDOR (Insecure Direct Object Reference). La defensa es comprobar la propiedad o el permiso sobre cada objeto en cada petición, en el servidor, a partir de la identidad del token y no de parámetros que el cliente controla.

Cedar es un lenguaje de autorización de código abierto (Apache-2.0, publicado por AWS en 2023) para expresar quién puede hacer qué sobre qué recurso, con semántica default-deny y forbid-wins: una regla forbid siempre gana a un permit. Soporta control de acceso por roles (RBAC) y por atributos (ABAC).

En agentes, Policy in AgentCore usa el lenguaje Cedar para autorizar qué herramienta puede invocar un agente y con qué parámetros declarados. Como servicio gestionado para aplicaciones generales, Amazon Verified Permissions también evalúa políticas Cedar de forma centralizada.

También llamado criptografía de clave pública. Cada parte tiene una clave pública (que reparte) y una clave privada (que guarda). Resuelve la distribución de claves: puedes cifrar un mensaje para alguien usando su clave pública sin haber compartido antes ningún secreto. Las familias habituales son RSA y la criptografía de curva elíptica (ECC), que logra la misma seguridad con claves mucho más cortas.

Es órdenes de magnitud más lento que el simétrico, así que no se usa para cifrar datos masivos: se usa para intercambiar o transportar una clave de sesión simétrica y para firmas digitales.

El algoritmo de referencia es AES (128/256 bits). Se usa siempre en un modo de operación: evita ECB (filtra patrones) y prefiere un modo AEAD como AES-GCM, que además de confidencialidad aporta integridad y autenticación en una sola operación.

Su punto débil no es el algoritmo sino la distribución de claves: ¿cómo le haces llegar la clave al otro extremo sin que nadie la intercepte? Ese problema es justo lo que resuelve el cifrado asimétrico, y por eso casi todos los sistemas reales combinan ambos (cifrado híbrido).

Los CIS Benchmarks son recomendaciones prescriptivas de configuración para más de 25 familias de productos (Linux, Windows, AWS, Kubernetes…), mantenidas por el Center for Internet Security. Cada recomendación indica el riesgo, cómo auditarla y cómo remediarla.

Se organizan en perfiles: Level 1 es una base práctica que reduce la superficie de ataque sin apenas impacto en el funcionamiento ni el rendimiento; Level 2 es defense in depth para entornos donde la seguridad es crítica y puede afectar a la funcionalidad. El antiguo Level 3 se sustituyó por un perfil STIG. CIS publica además las CIS Hardened Images (AMIs ya endurecidas) y los CIS Controls, que son el marco de controles de alto nivel.

CloudTrail Lake guarda los eventos en un event data store inmutable y los deja consultables con SQL durante una retención larga (hasta años), sin montar tú tablas de Athena ni particiones. Es la herramienta natural para el forense: reconstruir qué hizo una identidad entre dos fechas con una sola consulta.

El dialecto es un subconjunto de SQL basado en Trino (antes PrestoSQL). Las consultas van contra el identificador del event data store (SELECT … FROM <event-data-store-id> WHERE eventTime > '…') y pueden cruzar cuentas y regiones de una organización.

CNAPP (Cloud-Native Application Protection Platform) es una categoría acuñada por Gartner que agrupa en una sola plataforma capacidades que antes eran productos separados: CSPM (gestión de la postura de configuración cloud), CWPP (protección de cargas de trabajo), CIEM (gestión de derechos de identidad), escaneo de IaC y de vulnerabilidades, y a menudo detección de rutas de ataque.

Su valor es la correlación: en vez de ver una alerta de configuración y otra de vulnerabilidad por separado, una CNAPP conecta «este bucket expuesto + esta identidad con permisos excesivos + esta CVE» en una ruta de ataque priorizada. Wiz y Prisma Cloud (Palo Alto) son ejemplos conocidos de CNAPP multicloud; funcionan sobre AWS, Azure y GCP a la vez.

Un conformance pack agrupa varias reglas de AWS Config (y sus remediaciones opcionales) en una sola plantilla YAML que despliegas de golpe en una cuenta o, vía AWS Organizations, en toda la organización.

AWS publica packs de muestra alineados con marcos conocidos (CIS, PCI DSS, NIST, FSBP). Al desplegarlos obtienes una puntuación de cumplimiento agregada del pack y puedes ver qué reglas fallan sin cablear cada una a mano. Es la forma práctica de operar postura a escala con Config.

El confused deputy aparece cuando un intermediario con autoridad —un servicio de terceros o un servicio de AWS— es engañado para usar su permiso en beneficio de un atacante. El atacante no tiene acceso directo, pero aporta el objetivo (el ARN de tu rol o recurso) y deja que el «diputado» ponga el permiso.

Se cierra condicionando la confianza al origen real de la petición. Para terceros que asumen un rol se usa un External ID único y secreto en la trust policy; para servicios de AWS que actúan sobre tus recursos se usan aws:SourceArn y aws:SourceAccount en la resource policy, de modo que una petición desde otro origen deja de cumplir la condición.

El control de admisión es el último filtro de la API de Kubernetes: cuando llega una petición (crear un Deployment, por ejemplo), tras pasar autenticación y autorización (RBAC) entran los admission controllers, antes de escribir el objeto en etcd. Hay controladores mutating (pueden modificar el objeto, p. ej. inyectar un sidecar o un securityContext) y validating (lo aceptan o lo rechazan).

Los controladores dinámicos se conectan con ValidatingWebhookConfiguration y MutatingWebhookConfiguration, que redirigen las peticiones a un servicio externo como Kyverno u OPA Gatekeeper. Es el punto de aplicación ideal para políticas de seguridad —exigir imágenes firmadas, prohibir privilegios, forzar runAsNonRoot— porque actúa sobre todo lo que entra al clúster, venga de un pipeline o de un kubectl apply manual.

Crescendo es un jailbreak multi-turno descrito por investigadores de Microsoft (Russinovich et al., USENIX Security 2025). Empieza con preguntas benignas sobre el tema y, turno a turno, hace referencia a lo que el propio modelo dijo antes para pedir un poco más cada vez, sin enunciar nunca el objetivo malicioso de forma explícita.

Funciona porque las defensas por mensaje evalúan momentos aislados y no la trayectoria. Detalle en jailbreak multi-turno.

Puede dirigirse a la red y al transporte (inundaciones de paquetes, ataques de reflexión y amplificación) o a la aplicación (miles de peticiones HTTP legítimas en apariencia). Las fuentes suelen ser botnets de dispositivos comprometidos.

En AWS, Shield Standard protege sin coste adicional frente a los ataques de red más comunes. Shield Advanced, las reglas rate-based del WAF, el autoescalado y CloudFront ayudan contra los de aplicación.

Viene de la estrategia militar: varias líneas sucesivas en lugar de una sola muralla. En seguridad combina personas, tecnología y operaciones en capas como edge, red, cómputo, aplicación, datos, identidad y monitorización.

Las capas solo suman si fallan por motivos distintos. Dos controles que se saltan con la misma técnica cuentan como uno.

La destilación (Hinton et al., 2015) entrena un modelo alumno con las respuestas, a menudo las probabilidades completas, de un modelo maestro, para conseguir casi su calidad con una fracción del coste. Es práctica habitual y legítima cuando el maestro es tuyo o tienes licencia. El ataque es la misma técnica con el maestro ajeno: la extracción de modelo. La mayoría de proveedores prohíben en sus términos usar las salidas de su API para entrenar modelos competidores.

Notación clásica: rectángulos para entidades externas, círculos para procesos, dos líneas paralelas para almacenes de datos y flechas con nombre para los flujos. Los límites de confianza se dibujan con líneas discontinuas.

A diferencia de un diagrama de arquitectura, un DFD se centra en qué datos se mueven y entre quién, no en qué servicios hay desplegados.

El DNS convierte nombres legibles en direcciones IP. Un resolver recibe la consulta del cliente y la resuelve recursivamente: pregunta a un servidor raíz, luego al del TLD (.com, .app) y por último al servidor autoritativo del dominio, que devuelve el registro. La respuesta se guarda en caché durante el TTL para no repetir el proceso.

Por ser un protocolo que casi siempre se deja salir, el DNS es también un vector: se usa para exfiltrar datos codificados en los nombres consultados (tunneling). En AWS, Route 53 Resolver DNS Firewall filtra las consultas salientes de la VPC y el query logging deja rastro para detectarlo.

EKS Pod Identity es la forma más reciente y sencilla de dar credenciales de AWS a un pod, análoga a los instance profiles de EC2. En lugar de un proveedor OIDC por clúster, defines una asociación que mapea un rol IAM a un service account dentro de un namespace, y añades a la política de confianza del rol el principal de servicio pods.eks.amazonaws.com.

Un Pod Identity Agent corre como DaemonSet en cada nodo: el servicio EKS Auth asume el rol y el agente entrega las credenciales temporales solo a los pods de ese nodo que usan el service account asociado. Ventajas frente a IRSA: un único principal reutilizable entre clústeres, separación de responsabilidades (todo se configura en EKS e IAM, sin tocar OIDC) y menos carga de STS. No está disponible en Fargate ni en nodos Windows; ahí sigues usando IRSA.

Un embedding es la traducción de un texto a una lista de números (un vector) generada por un modelo, de forma que textos con significado parecido quedan cerca en ese espacio. Un vector store guarda los embeddings de tus documentos troceados y, dada una pregunta, devuelve los fragmentos más cercanos. Es el motor de búsqueda del RAG.

Desde seguridad, el vector store es una base de datos más con tus documentos dentro, y se protege igual: control de acceso, cifrado, aislamiento por cliente. Además, los embeddings no son anónimos: con técnicas de inversión se puede reconstruir parte del texto original, así que filtrar un índice es filtrar sus documentos.

El patrón que usa AWS KMS para cifrar sin que la clave maestra toque nunca los datos. KMS genera una data key: te devuelve una copia en claro y otra cifrada con la KEK (la KMS key). Cifras el objeto con la data key en claro, la borras de memoria y guardas la data key cifrada junto al dato.

Para leer, envías la data key cifrada a KMS, que la descifra con la KEK y te la devuelve en claro para descifrar el objeto. Así escalas a terabytes sin llamar a KMS por cada byte, limitas la exposición de la clave maestra y centralizas el control de acceso y la auditoría en una sola llave.

En el envenenamiento de memoria el atacante consigue que el sistema guarde algo malicioso (un «hecho», una preferencia, una instrucción) en su historial, resumen o memoria a largo plazo. Más tarde, cuando el sistema lo recupera y lo trata como cierto, cambia su comportamiento. A diferencia de la inyección de prompt de un solo turno, el daño es persistente y diferido, y puede alcanzar a otras sesiones o usuarios. Es la categoría ASI06 del Top 10 for Agentic Applications. Detalle en Envenenamiento de memoria.

El EU AI Act (Reglamento (UE) 2024/1689) es la primera regulación horizontal de la inteligencia artificial. Adopta un enfoque basado en el riesgo: cuanto mayor es el riesgo del sistema de IA para la salud, la seguridad o los derechos fundamentales, más obligaciones impone.

Define cuatro niveles. Riesgo inaceptable: prácticas prohibidas (por ejemplo, social scoring gubernamental o manipulación dañina). Alto riesgo: sistemas en ámbitos sensibles (sanidad, empleo, infraestructuras críticas, biometría) que exigen gestión de riesgos, gobernanza de datos, registro de eventos, supervisión humana, transparencia y evaluación de conformidad. Riesgo limitado: obligaciones de transparencia (avisar de que interactúas con una IA o de que un contenido es sintético). Riesgo mínimo: la mayoría de aplicaciones, sin obligaciones nuevas. Hay reglas específicas para la IA de propósito general (GPAI). La aplicación es escalonada: entró en vigor en agosto de 2024, las prohibiciones aplican desde febrero de 2025, las obligaciones de GPAI desde agosto de 2025 y el grueso de obligaciones de alto riesgo se escalona hasta 2027–2028.

En la extracción de modelo el atacante usa la API de la víctima como oráculo: manda entradas, guarda las respuestas y entrena su propio modelo con esos pares. Mecánicamente es destilación, pero sin permiso del dueño del maestro. Roba propiedad intelectual (años de datos y cómputo por el precio de las consultas) y facilita otros ataques, porque con una copia local se pueden preparar ejemplos adversarios o sondear la privacidad sin límite de consultas. Detalle en Extracción de modelo.

La federación OIDC permite que una carga de trabajo externa —por ejemplo un workflow de GitHub Actions— obtenga credenciales de AWS sin almacenar ninguna access key. El proveedor de identidad emite un token OIDC firmado que describe quién pide acceso (repositorio, rama, entorno); AWS STS valida ese token contra la trust policy de un rol y, si las condiciones coinciden, devuelve credenciales temporales de corta vida.

La clave de seguridad está en las condiciones de la trust policy: token.actions.githubusercontent.com:sub fija el repositorio y la rama exactos, y aud fija la audiencia. Así desaparecen las llaves de larga duración que pueden filtrarse en el código, y el acceso queda ligado a una identidad verificable en cada ejecución.

Firmar una imagen es adjuntarle una firma criptográfica que demuestra quién la construyó y que no se ha alterado desde entonces. En el despliegue, un verificador comprueba esa firma contra una identidad de confianza y rechaza cualquier imagen sin firmar o manipulada.

La herramienta de referencia es cosign (proyecto Sigstore). Admite firma con un par de claves o, mejor, firma keyless: una identidad OIDC obtiene un certificado efímero de Fulcio y la firma se registra en el log de transparencia Rekor. En AWS, AWS Signer ofrece un flujo equivalente integrado. Firmar y verificar corta los ataques en los que un atacante sustituye una imagen legítima por una comprometida en el registro o en tránsito.

El emisor calcula el hash del documento y lo “cifra” con su clave privada: eso es la firma. Cualquiera que tenga su clave pública puede verificarla recalculando el hash y comprobando que coincide. Si el documento se altera, o si la firma no proviene de esa clave privada, la verificación falla.

Aporta tres garantías a la vez: integridad (no se ha modificado), autenticidad (viene de quien dice) y no repudio (el firmante no puede negarlo). Es la base de los certificados TLS, la firma de código y los JWT firmados con RS256/ES256.

Es la categoría LLM07:2025 del OWASP Top 10 for LLM. Extraer el system prompt casi siempre es posible con insistencia, así que se asume que acabará siendo público. Lo que lo convierte en vulnerabilidad es lo que contenía: credenciales, topología interna o reglas de permisos. Detalle en Fuga del system prompt.

Debe cumplir tres propiedades: resistencia a preimagen (no se puede volver de la salida a la entrada), resistencia a segunda preimagen y resistencia a colisiones (no se pueden encontrar dos entradas con el mismo hash). El estándar actual es SHA-256 (familia SHA-2); MD5 y SHA-1 están rotos porque se saben generar colisiones.

Un hash no es cifrado: no tiene clave y no se “descifra”. Se usa para verificar integridad, para firmas digitales y, con sal y una KDF lenta, para guardar contraseñas.

Un grant es una forma alternativa a la key policy y a IAM de otorgar permiso sobre una KMS key. Se usa sobre todo para delegación programática y temporal: un servicio de AWS (EBS, RDS, Lambda) o un principal crea un grant que permite unas operaciones concretas (Decrypt, GenerateDataKey…), opcionalmente restringidas por un encryption context, y después lo revoca.

Los grants resuelven un problema de las políticas: son aditivos y de grano fino sin tener que reescribir la key policy en cada operación, y encajan con el principio de least privilege porque conceden justo lo necesario durante justo el tiempo necesario. Para crearlos, el principal necesita a su vez permiso (kms:CreateGrant), normalmente limitado con la condición kms:GrantIsForAWSResource.

Un guardrail es un control externo al modelo que revisa lo que entra (instrucciones maliciosas, datos personales, temas fuera de alcance) o lo que sale (secretos, contenido prohibido, formato inválido). Puede ser una lista de bloqueo, un clasificador entrenado o un modelo que actúa de juez; cada uno cambia latencia por precisión. Ningún guardrail aislado es suficiente: se apilan en cascada. Ver guardrails de entrada y salida.

Endurecer (hardening) un host o un servicio significa llevarlo de su configuración por defecto —pensada para funcionar, no para resistir— a una configuración mínima y segura: desinstalar paquetes y servicios que no se usan, cerrar puertos, aplicar mínimo privilegio, cifrar, parchear y activar auditoría.

Se apoya en guías como los CIS Benchmarks o las STIG del DoD, y en la nube se combina con una baseline inmutable (golden AMI) para que cada instancia nazca ya endurecida. El hardening es prevención: reduce las oportunidades del atacante, pero se complementa con detección y respuesta, porque ninguna configuración elimina el riesgo por completo.

IAM cubre la autenticación (demostrar quién eres) y la autorización (qué puedes hacer). En AWS, el servicio IAM gestiona usuarios, roles y políticas JSON que se evalúan en cada llamada a la API firmada con SigV4.

Conceptos clave en AWS: políticas basadas en identidad y en recurso, roles asumibles con credenciales temporales (STS), permission boundaries y, a nivel de organización, SCPs que limitan lo máximo que puede concederse en una cuenta.

IAM Access Analyzer razona sobre tus políticas basadas en recurso para encontrar accesos externos: recursos (buckets, roles, claves KMS, colas…) que son accesibles desde fuera de tu zona de confianza, quizá sin querer. También detecta accesos no usados —roles, permisos y credenciales sin actividad reciente— que solo amplían el radio de impacto.

Además valida políticas contra más de cien comprobaciones de seguridad antes de desplegarlas y puede generar una política de permisos mínimos a partir de la actividad real que CloudTrail registró para una identidad. Es la vía práctica para llegar al mínimo privilegio sin adivinar la lista de acciones.

IAM Identity Center (antes AWS SSO) centraliza el acceso de las personas a múltiples cuentas de la organización. Los usuarios se autentican contra tu proveedor de identidad (Entra ID, Okta, Google…) y reciben credenciales temporales; no hay usuarios IAM ni access keys de larga duración que robar.

El acceso se modela con permission sets: plantillas de permisos que se asignan a grupos sobre cuentas concretas y se materializan como roles asumibles vía STS. Es la base de un acceso humano federado, temporal y auditable, y la pieza sobre la que se construyen soluciones de acceso elevado just-in-time.

Un agente autónomo no debe heredar las credenciales de la persona que lo lanza: necesita su propia identidad de workload, con permisos mínimos y auditables por separado. Así, si lo manipulan, el radio de impacto queda acotado a lo que ese agente puede hacer, y CloudTrail atribuye cada acción al agente, no al humano.

AgentCore Identity provee esa identidad, más un vault de tokens y credenciales delegadas OAuth para que el agente actúe en nombre del usuario sobre servicios externos sin almacenar secretos de larga duración en su código.

El Instance Metadata Service (IMDS) de EC2 responde en 169.254.169.254 y expone, entre otras cosas, las credenciales temporales del rol de la instancia. IMDSv1 respondía a cualquier GET, lo que lo hacía alcanzable por SSRF.

IMDSv2 obliga a obtener primero un token de sesión con una petición PUT (cabecera X-aws-ec2-metadata-token-ttl-seconds) y a enviarlo en cada GET. Como un SSRF simple no puede emitir un PUT ni leer la respuesta del token, y el límite de saltos (hop limit) por defecto impide que la petición se reenvíe, IMDSv2 corta el camino que llevó a la fuga de Capital One. Conviene exigirlo (HttpTokens=required).

En un ataque de inferencia de pertenencia (membership inference) el atacante tiene un registro y una forma de consultar el modelo, y quiere saber un solo bit: ¿estaba este registro en el entrenamiento? Se apoya en que los modelos tratan distinto lo que vieron (menor pérdida, más confianza). Es una violación de privacidad por sí misma cuando la pertenencia es sensible (p. ej. «este paciente está en el dataset de una clínica oncológica»). Detalle en Inferencia de pertenencia.

La infraestructura como código (IaC) describe los recursos de un sistema —redes, bases de datos, roles, reglas de firewall— en ficheros declarativos que se versionan, se revisan en pull requests y se aplican de forma repetible. Herramientas típicas en AWS son Terraform/OpenTofu, AWS CloudFormation y CDK.

Para seguridad, la IaC es una oportunidad enorme: si la infraestructura es código, puedes escanearla antes de que exista. Un bucket público o un security group abierto se detectan en el pull request, no en producción. El mismo fichero que crea el recurso es el artefacto que auditas, revisas y corriges.

En la inversión de modelo el atacante parte de una etiqueta o de datos parciales y usa el modelo para reconstruir lo que falta: optimiza una entrada hasta que el modelo la clasifica con altísima confianza en una clase, y lo que resulta se parece a los datos de esa clase (por ejemplo, un rostro). Se distingue de la inferencia de pertenencia, que responde sí/no sobre un registro que el atacante ya tiene. Detalle en Inversión de modelo.

En la inyección indirecta el atacante no habla con el modelo directamente: deja instrucciones ocultas en un recurso que sabe que el agente leerá —una página web, un PDF, un correo, un ticket, un comentario de código, la descripción de un producto—. Cuando el agente recupera ese contenido para “razonar” sobre él, trata las instrucciones incrustadas como órdenes legítimas.

Es especialmente peligrosa en agentes con herramientas y memoria: una sola web envenenada puede lograr que el agente exfiltre datos, llame a una API o escriba en su memoria una instrucción persistente. El principio de defensa es tratar todo el contenido recuperado como datos no confiables, nunca como instrucciones, y combinar separación de contextos, mínimo privilegio, aprobación humana y filtrado de la salida.

La inyección SQL ocurre cuando una aplicación construye una consulta mezclando código SQL con entrada del usuario sin separarlos. El atacante envía valores como ' OR 1=1-- que cambian la lógica de la consulta: leer datos de otros usuarios, saltarse la autenticación, extraer tablas enteras con UNION o incluso escribir y borrar.

La defensa correcta no es filtrar caracteres sino usar consultas parametrizadas (prepared statements), que envían la estructura y los datos por canales separados, de modo que la entrada nunca se interpreta como código.

IRSA (IAM Roles for Service Accounts) fue la primera forma nativa de dar a un pod de EKS sus propias credenciales de AWS sin depender del rol del nodo. Cada clúster expone un proveedor OIDC; al anotar un service account con el ARN de un rol (eks.amazonaws.com/role-arn), el webhook de EKS inyecta un token proyectado y las variables que los SDK de AWS usan para llamar a sts:AssumeRoleWithWebIdentity.

La política de confianza del rol condiciona el sub al service account y namespace concretos (system:serviceaccount:<ns>:<sa>), de modo que solo ese workload puede asumirlo. A diferencia de EKS Pod Identity, IRSA requiere un proveedor OIDC por clúster y editar la política de confianza por cada clúster, pero sigue siendo la opción válida en Fargate, donde Pod Identity no está disponible.

ISO/IEC 27001 es la norma internacional para establecer, operar y mejorar de forma continua un Sistema de Gestión de Seguridad de la Información (SGSI / ISMS). Es certificable: un organismo acreditado audita tu SGSI y emite un certificado, a diferencia de marcos solo orientativos como el NIST CSF.

El cuerpo principal de la norma exige un enfoque de gestión del riesgo (contexto, liderazgo, planificación, evaluación de riesgos, tratamiento, mejora). Su Anexo A lista los controles de referencia; en la versión 27001:2022 son 93 controles agrupados en cuatro temas (organizativos, de personas, físicos y tecnológicos), alineados con ISO/IEC 27002:2022. La clave es que exige elegir y justificar controles según tu riesgo, no aplicar una lista fija.

Un jailbreak es un prompt (o una conversación) diseñado para que un LLM ignore las restricciones aprendidas en su entrenamiento de seguridad (RLHF, Constitutional AI, etc.) y produzca contenido que normalmente rechazaría. Ataca al modelo, no a la aplicación que lo rodea.

Se distingue de la inyección de prompt, que explota que una aplicación concatena texto confiable con texto no confiable. Los jailbreaks funcionan porque el rechazo es una tendencia estadística aprendida, no una regla impuesta: ver qué es un jailbreak.

Toda KMS key lleva exactamente una key policy: una política basada en recurso que vive pegada a la propia llave. A diferencia de un bucket o una cola, la key policy no es opcional ni secundaria; es el documento que gobierna el acceso. Sin una declaración en la key policy que permita a un principal (directamente, o habilitando las políticas IAM de la cuenta), ningún permiso IAM por sí solo basta para usar la llave.

La declaración por defecto Enable IAM User Permissions da al principal de cuenta arn:aws:iam::<cuenta>:root la acción kms:*. Ese principal no es el usuario root: representa a la cuenta y significa “delega estos permisos en las políticas IAM de la cuenta”. Si borras esa declaración, las políticas IAM dejan de tener efecto sobre la llave y solo mandan los principals nombrados explícitamente en la key policy.

Kyverno es un motor de políticas nativo de Kubernetes (proyecto CNCF). A diferencia de OPA Gatekeeper, no usa un lenguaje aparte como Rego: las políticas son recursos de Kubernetes en YAML, lo que facilita versionarlas con Git. Puede validar (aceptar/rechazar), mutar (añadir o cambiar campos), generar recursos y verificar firmas de imágenes para seguridad de la cadena de suministro.

Corre como webhook de admisión dinámico. Una regla de validación puede operar en modo Audit (solo reporta) o Enforce (bloquea). En versiones recientes la acción se fija por regla con validate.failureAction: Enforce; el antiguo campo de nivel de política validationFailureAction quedó obsoleto desde la 1.13. Casos típicos: exigir runAsNonRoot, prohibir latest, requerir límites de recursos o imágenes solo de registros de confianza como ECR.

Ejemplos típicos en AWS: Internet frente al borde (CloudFront, ALB), el borde frente a la VPC privada, la aplicación frente a la capa de datos, una cuenta frente a otra o el pipeline de CI/CD frente a producción.

No son solo fronteras de red: también hay límites cuando cambia la identidad con la que se ejecuta algo, el tenant de los datos o el nivel de privilegio de un proceso.

Un LLM (Large Language Model) es una red neuronal entrenada con enormes cantidades de texto para una sola tarea: dado un fragmento de texto, predecir el siguiente token. Repitiendo esa predicción token a token produce respuestas, resúmenes, código o llamadas a herramientas.

Para seguridad importan tres propiedades. No tiene estado: cada llamada empieza de cero y la “memoria” es el historial que la aplicación le reenvía. Solo ve texto: instrucciones y datos llegan por el mismo canal, la raíz de la inyección de prompt. Y no es determinista ni fiable: puede alucinar y puede ser manipulado, así que nunca debe ser quien decida si una acción está autorizada. Ver la anatomía de un sistema de IA.

Toda petición firmada a una API de AWS parte de un deny implícito: nada se permite salvo que una política lo permita. AWS reúne todas las políticas aplicables —SCP y RCP de Organizations, políticas basadas en recurso, basadas en identidad, permission boundary y session policy— y primero busca un Deny explícito: si lo encuentra en cualquiera de ellas, la respuesta final es deny.

Si no hay deny, comprueba que exista un Allow en cada capa requerida. El permiso efectivo es la intersección de todas: que falte un Allow basta para denegar. La regla de oro es que un Deny explícito, en cualquier política, vence a cualquier Allow.

El Model Context Protocol (MCP) es un estándar abierto, impulsado por Anthropic, que define una forma común de exponer herramientas, recursos y prompts a un modelo: un servidor MCP publica capacidades (leer un repositorio, consultar una base de datos, enviar un correo) y el agente (el cliente) las descubre y las invoca. Resuelve el problema de integración N×M: una sola interfaz en lugar de un conector a medida por cada herramienta.

Esa capa de conexión es también una nueva superficie de ataque. Un servidor MCP malicioso o comprometido puede describir herramientas engañosas, inyectar instrucciones en sus respuestas (tool poisoning), pedir permisos excesivos o exfiltrar lo que el agente le pasa. Por eso el OWASP GenAI publica riesgos específicos de MCP, y la defensa pasa por tratar los servidores de terceros como código no confiable: fijar versiones, revisar las definiciones de herramientas, aislar la ejecución y aplicar mínimo privilegio y aprobación humana en las llamadas.

Un modelo de lenguaje no guarda su corpus como una base de datos, pero puede memorizar secuencias concretas: un teléfono, una clave de API, un trozo de código con licencia. Lo hace más cuanto mayor es el modelo, cuanto más se repite el dato y cuanto más se entrena. Es la base de los ataques de extracción de datos de entrenamiento: si el modelo lo memorizó, un atacante con acceso de consulta puede lograr que lo escupa.

Una contraseña robada no basta si además se exige un segundo factor, por ejemplo una llave FIDO2/WebAuthn, una app TOTP o una passkey.

No todos los factores protegen igual: los códigos por SMS o los TOTP pueden capturarse con phishing en tiempo real, mientras que FIDO2 y las passkeys están ligadas al dominio y resisten el phishing. En AWS se recomienda MFA para todas las personas, empezando por el usuario root.

Principio formulado por Saltzer y Schroeder (1975): todo programa y todo usuario debería operar con el conjunto mínimo de privilegios necesario para hacer su trabajo.

Su objetivo práctico es reducir el radio de impacto: si una credencial se roba o un servicio se compromete, el daño queda limitado a lo poco que esa identidad podía hacer. En AWS se aplica con políticas IAM acotadas por acción, recurso y condición, permission boundaries, SCPs y acceso temporal.

ATLAS (Adversarial Threat Landscape for AI Systems, antes …for Artificial-Intelligence Systems) es el “ATT&CK de la IA”: una matriz pública de tácticas (el objetivo del adversario) y técnicas (cómo lo consigue) aplicadas a sistemas de machine learning y, cada vez más, a IA generativa y agentes. Reutiliza la estructura y buena parte de las tácticas de MITRE ATT&CK y añade las propias de la IA.

Su matriz incluye tácticas específicas de IA como AI Model Access (acceso al modelo) y AI Attack Staging (preparar el ataque: envenenar datos, crear adversarial examples, robar o replicar el modelo), junto a las heredadas de ATT&CK (Reconnaissance, Initial Access, Execution, Exfiltration, Impact…). Cada técnica se documenta con casos reales, lo que la convierte en un lenguaje común para threat intel, red teaming y detección de amenazas contra IA.

Mantenida por MITRE y organizada en matrices (Enterprise, Mobile, ICS). Cada técnica documenta cómo la usan grupos reales, cómo mitigarla y cómo detectarla.

Se usa como lenguaje común entre threat intel, detección, red team y arquitectura: en lugar de “nos atacaron”, dices “T1078.004 seguido de T1580 y T1530”.

Ejercicio de diseño que responde a cuatro preguntas: ¿en qué trabajamos?, ¿qué puede salir mal?, ¿qué vamos a hacer al respecto? y ¿lo hicimos suficientemente bien?

Se apoya en un modelo del sistema, normalmente un diagrama de flujo de datos con sus límites de confianza, y produce amenazas concretas, mitigaciones con dueño y riesgos aceptados de forma explícita.

El modelo TCP/IP organiza la comunicación en cuatro capas: enlace (Ethernet, Wi-Fi), Internet (IP, direccionamiento y enrutamiento), transporte (TCP y UDP, puertos y fiabilidad) y aplicación (HTTP, DNS, TLS). Al enviar, cada capa envuelve los datos de la de arriba añadiendo su cabecera (encapsulación); al recibir, cada capa quita la suya (desencapsulación).

Es más operativo que el modelo OSI de siete capas, que se usa sobre todo como vocabulario de referencia (“esto es un problema de capa 7”). Entender qué capa toca cada control —un security group filtra en L4, un WAF en L7— es lo que hace legibles los logs y las reglas de red.

Tras el acceso inicial, el atacante rara vez está ya donde quiere. Reutiliza credenciales, abusa de relaciones de confianza o explota servicios internos para pasar de una máquina o identidad a otra. En MITRE ATT&CK es la táctica Lateral Movement (TA0008).

Se frena con segmentación, mínimo privilegio, autenticación entre servicios (mTLS, IAM) y eliminando la confianza implícita por estar «dentro» de la red, que es la idea central de zero trust.

NAT traduce direcciones IP al vuelo. En SNAT (source NAT) se reescribe la IP de origen: es lo que hace un NAT gateway para que las instancias de una subred privada salgan a Internet con una IP pública, sin ser accesibles desde fuera. En DNAT (destination NAT) se reescribe la IP de destino, como en el reenvío de puertos.

En AWS, las subredes privadas no tienen ruta directa a Internet; su tráfico saliente pasa por un NAT gateway en una subred pública. En los VPC Flow Logs esto se ve comparando srcaddr (la IP tras la traducción) con pkt-srcaddr (la IP privada original).

Una network ACL se aplica a nivel de subred y filtra todo el tráfico que entra o sale de ella. Es stateless: no recuerda conexiones, así que debes permitir explícitamente tanto la ida como la vuelta. En la práctica eso obliga a permitir el rango de puertos efímeros (1024-65535) en el sentido del retorno.

A diferencia del security group, admite reglas allow y deny, se evalúan por número de regla (de menor a mayor, la primera que coincide gana) y es un buen sitio para bloqueos amplios (una IP o un rango concreto). La NACL por defecto permite todo; una personalizada deniega todo hasta que añadas reglas.

El NIST Cybersecurity Framework (CSF) es un marco voluntario, independiente de tecnología, que ayuda a organizaciones de cualquier tamaño a entender, gestionar y comunicar su riesgo de ciberseguridad. No prescribe controles concretos: ofrece un lenguaje común de resultados (outcomes).

La versión 2.0 (publicada en febrero de 2024) organiza esos resultados en seis funciones: Govern (gobierno del riesgo, nueva en 2.0 y situada en el centro), Identify (conocer activos y riesgos), Protect (salvaguardas), Detect (detección de eventos), Respond (respuesta a incidentes) y Recover (recuperación). Cada función se descompone en categorías y subcategorías que puedes mapear a controles técnicos concretos de tu nube.

Se consigue con registros de auditoría que identifican al actor, la acción, el recurso y el momento, almacenados donde nadie (ni un administrador) pueda alterarlos, por ejemplo un bucket S3 con Object Lock en modo compliance. Las firmas digitales también aportan no repudio.

Es la propiedad que viola la “R” de STRIDE.

El Open Cybersecurity Schema Framework (OCSF) es un estándar abierto que define una taxonomía y un esquema comunes para los eventos de seguridad (autenticación, actividad de red, actividad de API, hallazgos…). Su objetivo es que logs de orígenes muy distintos encajen en el mismo modelo, de modo que una regla o una consulta valga para todos sin un parser por producto.

Es agnóstico de proveedor (nació de una colaboración de la industria, con AWS entre los impulsores). Amazon Security Lake lo adopta como formato de normalización, lo que facilita llevar los datos a cualquier herramienta que entienda OCSF.

OWASP (Open Worldwide Application Security Project) es una comunidad abierta que produce documentación, estándares y herramientas de seguridad de aplicaciones de uso libre. Sus proyectos más conocidos son el OWASP Top 10 (riesgos web), el OWASP API Security Top 10, el ASVS (estándar de verificación) y las Cheat Sheets.

El Top 10 es una lista de concienciación basada en datos de la industria, no una certificación ni un checklist de cumplimiento: sirve para orientar prioridades, no para declarar una aplicación “segura” por haberlo repasado.

El OWASP Top 10 for LLM Applications es el equivalente del clásico Top 10 web, pero para sistemas construidos sobre modelos de lenguaje. Lo mantiene el proyecto OWASP GenAI Security y la edición vigente es la de 2025, con identificadores estables LLM01:2025 … LLM10:2025.

Encabeza la lista la prompt injection (LLM01) y la acompañan la revelación de información sensible, la cadena de suministro, el envenenamiento de datos y modelos, el manejo inseguro de la salida, la agencia excesiva, la fuga del system prompt, las debilidades de vectores y embeddings, la desinformación y el consumo sin límites. Como su primo web, agrupa categorías de riesgo, no vulnerabilidades concretas, y sirve de vocabulario común para razonar por dónde rompe una aplicación de IA.

Pacu es un framework de explotación de AWS mantenido por Rhino Security Labs. Está organizado en módulos que cubren fases posteriores al acceso inicial: enumeración de permisos, escalada de privilegios, persistencia, movimiento lateral y exfiltración. Funciona sobre credenciales que ya tienes, no para entrar.

Desde el punto de vista defensivo es útil porque cada módulo deja un rastro conocido en CloudTrail: entender qué llamadas a la API genera un intento de escalada ayuda a escribir las detecciones que lo delatan.

Como cualquier herramienta ofensiva, se usa exclusivamente contra cuentas propias y con autorización escrita, idealmente en un laboratorio aislado como CloudGoat o IAM Vulnerable. Usarla contra infraestructura ajena es un delito.

Un perímetro de datos (data perimeter) es un conjunto de barandillas preventivas que impone tres garantías a escala de organización: que solo identidades confiables accedan a tus recursos, que esas identidades solo accedan a recursos confiables y que el acceso ocurra únicamente desde redes confiables.

Se construye combinando tres tipos de política: Service Control Policies (SCP), que limitan lo que las identidades de tu organización pueden hacer; Resource Control Policies (RCP), políticas a nivel de organización que se aplican sobre los recursos (por ejemplo, para que un bucket S3 solo sea accesible por principales de tu propia organización); y políticas de VPC endpoint, que controlan qué principales y recursos pueden alcanzarse a través de los endpoints de tu red. Juntas atajan la exfiltración hacia cuentas externas y el acceso desde identidades o redes no confiables.

Una permission boundary es una política gestionada que se adjunta a un rol o usuario para marcar el techo de lo que esa identidad podrá hacer jamás. No concede nada por sí misma: el permiso efectivo es la intersección entre la política de identidad y la boundary. Si una acción está en la política pero no en la boundary, se deniega.

Su uso clásico es la delegación segura: puedes dejar que un equipo cree sus propios roles siempre que les imponga una boundary, garantizando que ningún rol que creen supere ese límite. No debe confundirse con las SCP, que limitan a nivel de cuenta en vez de a una identidad concreta.

Una autoridad de certificación (CA) firma certificados que vinculan una clave pública a un nombre (un dominio, una persona, un servicio). Tu sistema confía en un conjunto de CA raíz; un certificado de servidor se valida siguiendo la cadena de confianza desde él hasta una de esas raíces. Para pedir un certificado se envía una CSR (Certificate Signing Request) con la clave pública y la identidad.

En AWS, ACM emite y renueva certificados públicos gratis para ALB, CloudFront y API Gateway, y AWS Private CA actúa como CA privada para certificados internos (mTLS, dispositivos).

Los Pod Security Standards definen tres perfiles acumulativos: privileged (sin restricciones), baseline (bloquea escaladas conocidas: sin hostNetwork/hostPID/hostIPC, sin contenedores privilegiados, sin hostPath) y restricted (hardening completo: runAsNonRoot, allowPrivilegeEscalation: false, seccompProfile RuntimeDefault, capabilities reducidas a drop: ALL).

Se aplican con Pod Security Admission (PSA), el controlador integrado y estable desde Kubernetes 1.25 (sustituyó a PodSecurityPolicy). Se activa poniendo etiquetas en el namespace, pod-security.kubernetes.io/<modo>: <perfil>, con tres modos: enforce (rechaza el pod), audit (lo anota en el log de auditoría) y warn (avisa al usuario). Un patrón de despliegue gradual es enforce: baseline junto a warn: restricted y audit: restricted. Para reglas más finas que las tres plantillas fijas se usa un controlador de admisión como Kyverno u OPA Gatekeeper.

Policy as code consiste en expresar las reglas de seguridad y cumplimiento —«ningún bucket público», «cifrado obligatorio», «nada de 0.0.0.0/0 en el puerto 22»— como código que una máquina evalúa de forma automática y repetible, en lugar de como un documento que alguien revisa a mano.

El patrón más general es Open Policy Agent (OPA) con su lenguaje Rego, y Conftest para aplicarlo a ficheros de configuración. Herramientas como Checkov o Trivy traen además catálogos de reglas listas para Terraform, CloudFormation y Kubernetes. Al integrarse en el pipeline, una política puede romper el build cuando una configuración la incumple, convirtiendo una decisión de seguridad en una comprobación objetiva y versionada.

La privacidad diferencial limita cuánto puede influir un único registro en el resultado. Aplicada al entrenamiento (DP-SGD) recorta el gradiente de cada ejemplo y suma ruido, con un presupuesto ε que cuantifica la fuga: cuanto menor, más privacidad y menos precisión. Es la única defensa con garantía formal contra la inferencia de pertenencia y la memorización, a costa de utilidad y de coste de cómputo.

La prompt injection explota que un LLM procesa instrucciones y datos en el mismo canal de texto: no hay una frontera robusta entre “lo que te mando hacer” y “el contenido sobre el que trabajas”. Si un atacante consigue colar texto que el modelo interpreta como una orden, puede desviar su comportamiento: saltarse las reglas del sistema, revelar el prompt, o —si el modelo es un agente con herramientas— ejecutar acciones en nombre del atacante.

Es directa cuando el propio usuario manipula el prompt (por ejemplo, un jailbreak), e indirecta cuando las instrucciones viajan ocultas en un documento, una web o un correo que el modelo lee y obedece. Es el riesgo número uno del OWASP Top 10 for LLM Applications (LLM01) y no tiene una solución única: se mitiga en profundidad con separación de datos e instrucciones, mínimo privilegio en las herramientas, aprobación humana y filtrado de salida.

Prowler es una plataforma open source que automatiza la evaluación de seguridad y cumplimiento de un entorno cloud (CSPM). Ejecuta cientos de comprobaciones de configuración y las mapea a marcos como CIS, NIST, PCI-DSS o el propio AWS Foundational Security Best Practices, y señala lo que está mal configurado.

Su alcance va más allá de AWS: también cubre Azure, GCP, Kubernetes y Microsoft 365, entre otros. Creado por Toni de la Fuente, el proyecto vive bajo la organización prowler-cloud, y existe además una oferta gestionada, Prowler Cloud.

En un ejercicio ofensivo-defensivo, Prowler y herramientas afines como ScoutSuite cubren el lado de postura: no simulan un ataque, sino que te dicen qué puertas están abiertas antes de que alguien las pruebe. Es el complemento preventivo de la validación de detecciones.

Un proxy inverso se sitúa delante de los servidores de aplicación y atiende las peticiones de los clientes como si fuera el servidor final. A diferencia de un forward proxy (que representa al cliente hacia Internet), el proxy inverso representa al servidor hacia los clientes. Termina TLS, reparte carga, cachea contenido y es el punto natural para inspeccionar y filtrar tráfico.

En AWS actúan como proxy inverso CloudFront, el Application Load Balancer y AWS WAF: concentran la entrada, ocultan las IP privadas del backend y aplican controles de borde antes de que la petición llegue a la API.

Un puerto es un identificador de 0 a 65535 que la capa de transporte usa para entregar el tráfico al proceso correcto. Los well-known (0-1023) corresponden a servicios estándar: 80 (HTTP), 443 (HTTPS), 53 (DNS), 22 (SSH). La combinación IP + puerto es un socket, y la 5-tupla (IP y puerto de origen, IP y puerto de destino, protocolo) identifica una conexión.

Filtrar por puerto es el control de red más básico: un security group que solo permite el 443 reduce la superficie de ataque. En los Flow Logs, srcport y dstport te dicen qué servicio se intentó alcanzar.

El purple teaming no es un tercer equipo, sino una forma de trabajar: el equipo rojo simula técnicas de adversario y el azul observa si sus detecciones reaccionan, en el mismo ejercicio y de forma colaborativa. Cada técnica que se cuela sin alerta se convierte en una regla nueva, y luego se vuelve a probar.

A diferencia de un pentest clásico, cuyo objetivo es demostrar que se puede entrar, el purple teaming mide qué ves y qué no ves en tus logs. El entregable no es una lista de vulnerabilidades, sino un mapa de cobertura de detección: técnica → evento → regla → respuesta, probado y no asumido.

Se hace siempre sobre infraestructura propia y con autorización, normalmente en una cuenta de laboratorio aislada. Herramientas como Stratus Red Team facilitan detonar técnicas concretas de forma segura y reversible.

Es la pregunta «si esto cae, ¿qué más cae con ello?». Una credencial con permisos de administrador tiene un radio de impacto de toda la cuenta; un rol que solo puede escribir en un prefijo de un bucket, apenas ese prefijo.

Se reduce con mínimo privilegio, separación en cuentas y entornos, segmentación de red, credenciales temporales y límites como permission boundaries o SCPs.

RAG (Retrieval-Augmented Generation) resuelve que el modelo no conozca tus documentos. Antes de llamarlo, la aplicación convierte la pregunta en un embedding, busca en un vector store los fragmentos más parecidos y los añade al contexto. El modelo responde “con” esos fragmentos, lo que reduce las alucinaciones y permite citar fuentes.

También abre riesgos propios (LLM08 y LLM04 del OWASP Top 10 for LLM): documentos envenenados que inyectan instrucciones, fuga de datos entre clientes si el índice no se particiona, y recuperación sin control de acceso. La regla es autorizar antes de recuperar (solo los fragmentos que el usuario puede ver) y tratar todo lo recuperado como contenido no confiable.

RBAC es el autorizador por defecto de la API de Kubernetes. Un Role (ámbito de namespace) o ClusterRole (ámbito de clúster) enumera verbos (get, list, create, delete…) sobre recursos (pods, secrets, deployments…). Un RoleBinding o ClusterRoleBinding une ese rol a un sujeto: un usuario, un grupo o un ServiceAccount.

RBAC es puramente aditivo: no existen reglas de denegación, así que el least privilege se consigue concediendo lo mínimo, no quitando. Los errores típicos son usar cluster-admin por comodidad, montar el service account default con permisos amplios o conceder verbos peligrosos como secrets:list, pods/exec o create sobre rolebindings (que permite escalar privilegios). En AWS, RBAC se integra con identidades IAM a través de EKS access entries o el aws-auth.

Las Resource Control Policies (disponibles desde noviembre de 2024) son la contraparte de las SCP centrada en los recursos. Mientras una SCP limita lo que pueden hacer las identidades dentro de tus cuentas, una RCP limita quién puede acceder a tus recursos, incluidos principals externos a tu organización. Como las SCP, solo recortan y nunca conceden.

Son útiles para imponer de forma central reglas como «ningún bucket de la org es accesible desde fuera de la organización» o para blindar el confused deputy con aws:SourceOrgID. Cubren un conjunto de servicios en expansión (S3, STS, KMS, SQS, Secrets Manager y más), no afectan a la cuenta de gestión y no restringen los service-linked roles.

El reconocimiento (recon) es la fase en la que el atacante construye su lista de objetivos: qué hosts existen, qué puertos responden, qué software es y qué devuelven sus APIs. Puede ser pasivo (buscadores como Shodan, certificados, repositorios públicos) o activo (escanear y consultar los servicios).

En sistemas de IA el objetivo cambia: además de servidores web y bases de datos aparecen servidores de modelos, registros de modelos, bases vectoriales y notebooks, con puertos y APIs poco habituales. Ver Mapa de la infraestructura de IA. En MITRE ATLAS es la táctica Reconnaissance.

El red team de LLM diseña y ejecuta casos de ataque contra tus propios sistemas autorizados —nunca contra terceros— y mide cuáles tienen éxito. A diferencia de un eval de calidad, busca romper la aplicación: inyección directa e indirecta, abuso de herramientas, fuga de prompt del sistema y exfiltración de datos.

Herramientas habituales: promptfoo (evaluación y red team dirigido a tu app), garak (escáner de vulnerabilidades de NVIDIA) y PyRIT (framework de red team de Microsoft). Cada hallazgo se mapea a un marco como OWASP Top 10 for Agentic Applications (ASI01–ASI10).

Un registro de modelos (MLflow Model Registry, SageMaker Model Registry, Vertex AI Model Registry…) es el inventario de los modelos de una organización: versión, etapa (staging, production, archived), métricas, autor y la URI del artefacto en el almacenamiento (por ejemplo un bucket S3).

Desde seguridad es un objetivo de reconocimiento de primer nivel: un registro abierto describe todo el portafolio de ML y apunta a dónde están los archivos del modelo. Además, quien pueda escribir en él puede sustituir un modelo en producción.

La guía de respuesta a incidentes de seguridad de AWS se apoya en el modelo de NIST SP 800-61 y lo organiza en tres bloques: preparación, operaciones (detección, análisis, contención, erradicación y recuperación) y actividad posterior al incidente (lecciones aprendidas). Es un bucle: cada incidente mejora la preparación del siguiente.

En la nube, la preparación tiene elementos propios: acceso de ruptura (break-glass), una cuenta forense aislada, permisos pre-aprobados y runbooks escritos. Lo que no esté listo antes del incidente te costará horas en caliente.

En la práctica se estima con escalas sencillas (alto/medio/bajo) y una matriz impacto × probabilidad que ordena el trabajo.

Las cuatro respuestas clásicas son mitigar (añadir controles), transferir (seguro, proveedor), evitar (no construir la funcionalidad) y aceptar. Aceptar es legítimo solo si es explícito: con responsable, justificación y fecha de revisión. Lo que queda tras aplicar los controles es el riesgo residual.

Block Public Access (BPA) es una red de seguridad que se superpone a las ACLs y a las bucket policies: aunque alguien escriba una política pública, BPA puede ignorarla o rechazarla. Son cuatro ajustes independientes: BlockPublicAcls e IgnorePublicAcls (sobre ACLs públicas), BlockPublicPolicy (rechaza políticas públicas nuevas) y RestrictPublicBuckets (bloquea el acceso público y entre cuentas de buckets con política pública).

Se aplican a varios niveles —cuenta, bucket, access point y organización (vía AWS Organizations)— y S3 hace cumplir la combinación más restrictiva de todos ellos. Desde abril de 2023 los buckets nuevos nacen con los cuatro ajustes activados. La recomendación (y el control S3.8 de Security Hub) es tenerlos activados a nivel de cuenta para que ningún bucket nuevo pueda volverse público por error.

Object Lock implementa almacenamiento WORM sobre S3: protege versiones de objetos frente a borrado o sobrescritura. Requiere versionado activado y se gobierna con dos mecanismos combinables: un periodo de retención (con fecha de expiración) y un legal hold (sin fecha, hasta que se retire explícitamente).

Hay dos modos de retención. En governance, solo los principals con el permiso s3:BypassGovernanceRetention pueden alterar o saltarse el bloqueo. En compliance, nadie —ni siquiera el usuario root de la cuenta— puede borrar ni acortar la retención hasta que expire; el único modo de eliminar el objeto antes es cerrar la cuenta. Por eso es la base para logs de auditoría y backups inmutables resistentes a ransomware.

Un SBOM (Software Bill of Materials) es la lista completa de componentes que lleva dentro un artefacto: librerías, versiones, licencias y dependencias transitivas. Se genera de forma automática durante el build con herramientas como Syft, y se publica en formatos estándar como SPDX o CycloneDX.

Su valor aparece cuando se descubre una vulnerabilidad nueva: en lugar de adivinar qué imágenes usan la librería afectada, consultas los SBOM y sabes en minutos qué está expuesto. Es la base de una respuesta rápida ante incidentes de cadena de suministro (como fue el caso de Log4Shell) y un requisito cada vez más habitual en contratos y normativas.

Una Service Control Policy es una barandilla de AWS Organizations que acota el máximo de lo que las identidades (roles y usuarios) de una cuenta pueden hacer, por muy permisivas que sean sus políticas IAM. Una SCP nunca concede permisos: solo recorta, y el permiso efectivo es la intersección entre la SCP y el resto de políticas.

Requiere tener habilitadas all features en la organización. No afecta a la cuenta de gestión y es la herramienta típica para imponer controles globales (proteger CloudTrail, limitar regiones, impedir acciones peligrosas) incluso frente a un administrador comprometido.

Un security group se asocia a la interfaz de red (ENI) de un recurso —instancia, tarea de Fargate, endpoint, base de datos— y filtra tráfico de entrada y salida. Es stateful: si permites una conexión de entrada, la respuesta sale sin necesidad de una regla explícita (y viceversa). Solo admite reglas allow; lo que no está permitido se deniega de forma implícita.

Las reglas se evalúan como un conjunto (no hay orden ni prioridad) y pueden referenciar rangos CIDR, otros security groups o prefix lists gestionadas. Es el control más cercano al recurso, complementario a la NACL, que actúa en el borde de la subred.

Cuando un binario tiene el bit setuid activado (chmod u+s, aparece como rws en la columna del propietario), el proceso que lo ejecuta adopta el UID efectivo del dueño del fichero en vez del UID del usuario que lo invoca. passwd lo usa de forma legítima: un usuario normal necesita escribir en /etc/shadow, que es de root.

El mismo mecanismo es un vector de escalada de privilegios: un binario setuid-root con una vulnerabilidad, o uno colocado por un atacante, concede root a cualquiera. setgid hace lo análogo con el grupo. Por eso el hardening audita y minimiza los binarios setuid (find / -perm -4000) y prefiere capabilities concretas o sudo con reglas acotadas.

Sigma es a los logs lo que YARA es a los ficheros: una forma común y legible de expresar una detección (logsource + detection) que luego se traduce al lenguaje de cada backend con sigma-cli / pySigma. Escribes la regla una vez y la despliegas en Splunk, OpenSearch, Athena o tu plataforma.

Es la base de la detección como código: las reglas viven en Git, se revisan en pull requests y se prueban. El repositorio SigmaHQ incluye reglas para CloudTrail (logsource: { product: aws, service: cloudtrail }) que casan sobre eventSource y eventName, por ejemplo para StopLogging o cambios de política IAM.

Variante del typosquatting: en vez de apostar a que alguien se equivoque al teclear, el atacante apuesta a que el modelo se invente un nombre. Si un asistente de código recomienda con frecuencia un paquete que no existe, el atacante lo publica (con malware) y espera a que los desarrolladores lo instalen siguiendo la sugerencia. Se ataca la confianza en la IA, no un fallo del software. Ver Explotación de la confianza.

SLSA (Supply-chain Levels for Software Artifacts, se pronuncia «salsa») es un marco que mide y mejora la integridad de cómo se construye el software. Su Build track define niveles crecientes: Build L1 exige que exista provenance (una descripción de cómo y con qué entradas se construyó el artefacto); Build L2 exige una plataforma de build gestionada que firme esa provenance; Build L3 añade builds endurecidos y aislados, con la clave de firma fuera del alcance de los pasos definidos por el usuario.

La provenance firmada permite a quien despliega verificar que un artefacto salió de verdad del pipeline esperado y no de la máquina de un atacante. SLSA no reemplaza al SBOM ni a la firma de imágenes: los complementa, poniendo el foco en la confianza del proceso de build.

A diferencia del phishing masivo, el spear phishing se dirige a una persona o equipo con datos reales (su cargo, sus proyectos, su jefe). Es la base del fraude del directivo (BEC, business email compromise). Los LLM lo abaratan: redactan correos impecables, imitan el estilo de alguien y adaptan el mensaje al contexto, de modo que las señales clásicas (faltas, plantillas genéricas) dejan de ser fiables. Detalle en Ingeniería social con LLM.

SSH (Secure Shell) cifra la sesión de administración remota y autentica al servidor y al cliente. El demonio sshd escucha por defecto en el puerto 22. La autenticación recomendada es por par de claves (el servidor guarda la clave pública; el usuario conserva la privada), no por contraseña, que es vulnerable a fuerza bruta.

Endurecer sshd_config es un clásico del hardening: deshabilitar el login de root (PermitRootLogin no), prohibir contraseñas (PasswordAuthentication no) y limitar usuarios y orígenes. En AWS, SSM Session Manager permite prescindir de SSH por completo: administra la instancia sin abrir el puerto 22, sin bastión y sin gestionar claves, con control por IAM y registro de sesiones.

En un ataque SSRF (Server-Side Request Forgery) la aplicación toma una URL de la entrada del usuario y la solicita desde el servidor. El atacante aprovecha que el servidor está dentro de la red para que pida recursos internos: metadatos de la nube, servicios en subredes privadas o puertos locales.

Es la vulnerabilidad web más ligada a la nube porque puede alcanzar el Instance Metadata Service (169.254.169.254) y leer las credenciales temporales del rol de la instancia. Se mitiga con IMDSv2, listas de permitidos de salida (egress allow-list) y no confiar nunca en la entrada para construir URLs.

Stratus Red Team es una herramienta open source de Datadog para adversary emulation en la nube: detona técnicas de ataque autocontenidas y granulares que generan actividad maliciosa real y controlada, pensada para comprobar si tus detecciones la ven.

Cada técnica está mapeada a una táctica de MITRE ATT&CK (Defense Evasion, Persistence, Credential Access, Exfiltration…) y sigue un ciclo de vida claro: warmup prepara los prerequisitos con Terraform, detonate ejecuta la acción maliciosa y cleanup deshace todo. Cubre AWS, Azure, GCP, Entra ID y Kubernetes.

Es la pieza ofensiva típica de un ejercicio de purple teaming: te deja ejecutar, por ejemplo, aws.defense-evasion.cloudtrail-stop o aws.persistence.iam-backdoor-user en una cuenta de laboratorio y verificar que tu regla salta, sin escribir tú el ataque ni dejar recursos huérfanos.

Spoofing viola la autenticación, Tampering la integridad, Repudiation el no repudio, Information disclosure la confidencialidad, Denial of service la disponibilidad y Elevation of privilege la autorización.

Se aplica sobre un diagrama de flujo de datos, preguntando a cada elemento solo las categorías que le corresponden (STRIDE por elemento).

Incluye puertos, APIs, formularios y colas, pero también el plano de control cloud (usuarios, roles y relaciones de confianza), la cadena de suministro, los dispositivos físicos y las personas.

Reducirla (eliminar, restringir y endurecer puntos de entrada) es uno de los controles más baratos: lo que no existe no se puede explotar.

syslog (RFC 5424) define cómo los programas y el kernel emiten mensajes de log, cada uno con una facility (auth, cron, kernel…) y una severity (de debug a emergency). Implementaciones como rsyslog o syslog-ng los escriben en /var/log y pueden reenviarlos por red a un colector central.

En las distribuciones modernas, systemd-journald recoge los logs en un formato binario estructurado (consultable con journalctl) y suele reenviarlos a syslog. Centralizar estos registros fuera del host es clave para detección e investigación: si un atacante compromete la máquina, no debe poder borrar la única copia de sus propias huellas.

El system prompt es el texto que escribe el equipo que construye la aplicación para definir cómo debe comportarse el modelo: “eres el asistente de pacientes de la clínica, responde solo sobre citas, no des diagnósticos”. Va en un campo propio de la API y el modelo le da más peso que al resto del contexto.

Pero no es un control de seguridad. El modelo puede desobedecerlo por error o porque una inyección de prompt lo convence, y su contenido puede filtrarse (LLM07, system prompt leakage). Por eso nunca debe contener secretos ni ser el único sitio donde vive una regla de autorización: lo que el prompt pide, el código lo tiene que imponer.

Las tácticas son las columnas de la matriz ATT&CK. En la versión v19, Enterprise tiene 15, tras dividir Defense Evasion en Stealth (TA0005) y Defense Impairment (TA0112).

Una misma técnica puede servir a varias tácticas: usar cuentas válidas (T1078) sirve para entrar, persistir, escalar y pasar desapercibido.

Las técnicas son las celdas de la matriz. Las subtécnicas concretan la variante: Valid Accounts (T1078) es la técnica; Cloud Accounts (T1078.004) es la subtécnica específica de cloud.

Cada técnica incluye ejemplos de procedimientos, mitigaciones (M1xxx) y una estrategia de detección (DETxxxx) con analíticas (ANxxxx).

Responder a una alerta es reactivo: una regla salta y actúas. Cazar es lo contrario: partes de una hipótesis (“si una clave fue robada, veríamos reconocimiento seguido de descargas”) y consultas los datos para confirmarla o descartarla. Encuentras lo que ninguna regla preexistente estaba buscando.

En la nube, el terreno de caza son CloudTrail (Lake o Athena), VPC Flow Logs y DNS, idealmente normalizados en Security Lake (OCSF). El valor compuesto está en el bucle: cada hipótesis que resulta cierta se convierte en una detección guardada (regla Sigma, query de Security Lake), de modo que la caza de hoy es la alerta automática de mañana.

Combina las dos criptografías: un handshake asimétrico (intercambio de claves efímeras ECDHE y validación del certificado del servidor) acuerda una clave de sesión simétrica, y a partir de ahí todos los datos viajan cifrados con AEAD (p. ej. AES-GCM). Las claves efímeras aportan forward secrecy: comprometer la clave privada del servidor no descifra sesiones pasadas.

TLS 1.3 simplificó el handshake a 1-RTT y eliminó lo inseguro (RSA estático, RC4, SHA-1, renegociación, compresión). El cliente valida el certificado contra una CA de confianza antes de enviar nada sensible.

Un LLM no lee letras ni palabras sino tokens: fragmentos de texto de longitud variable (una palabra corta, una sílaba, un signo) que el tokenizador convierte en números. Como regla aproximada, en inglés un token ronda las tres cuartas partes de una palabra; en español suele haber algo más de tokens por palabra.

Todo se mide en tokens: el tamaño de la ventana de contexto, el límite de salida (maxTokens) y la factura del proveedor, que cobra por tokens de entrada y de salida. Por eso un atacante que fuerza conversaciones largas o bucles de herramientas ataca tu presupuesto (LLM10, unbounded consumption), y por eso los límites de tokens y de pasos son un control de seguridad, no solo de coste. No confundir con los tokens de autenticación (JWT, OAuth).

Con tool calling (o function calling), la aplicación describe al modelo un catálogo de herramientas (nombre, descripción y esquema de argumentos) y el modelo puede responder, en lugar de con texto, con un JSON que pide ejecutar una de ellas: buscar_citas(fecha="jueves"). El modelo no ejecuta nada. Es el código de la aplicación quien valida la petición, la ejecuta con sus credenciales y le devuelve el resultado para que siga razonando.

Ese punto es la frontera más crítica de un agente: donde el texto generado por una máquina se convierte en una acción real. Los controles viven ahí: lista cerrada de herramientas, validación estricta de argumentos, identidad tomada de la sesión y no del modelo, mínimo privilegio y aprobación humana para lo irreversible.

Acrónimo de Confidentiality, Integrity, Availability. Confidencialidad: solo acceden quienes están autorizados. Integridad: la información no se altera indebidamente y los cambios son detectables y atribuibles. Disponibilidad: el sistema y los datos están accesibles cuando se necesitan.

NIST (FIPS 199) propone valorar el impacto de perder cada propiedad por separado. Las tres a menudo compiten entre sí.

Término popularizado por Simon Willison para describir cuándo un agente de IA es explotable por inyección de prompt de forma práctica: (1) lee datos privados, (2) lee contenido que controla un tercero y (3) puede enviar información al exterior (un enlace, una imagen, un correo, una petición HTTP). Quitar cualquiera de las tres patas rompe la cadena de exfiltración. Detalle y casos reales en despliegue seguro y salida.

Las tácticas son el porqué, las técnicas el cómo y los procedimientos la implementación concreta que usa un grupo (comandos, herramientas, orden).

Detectar TTPs es más duradero que detectar indicadores (IPs, hashes): un atacante cambia de IP en segundos, pero cambiar de comportamiento le cuesta mucho más.

El vector describe cómo entra o actúa el atacante, mientras que la superficie de ataque es el conjunto de todos los puntos por los que podría hacerlo.

Un mismo objetivo puede alcanzarse por varios vectores; en un árbol de ataque, cada camino desde las hojas hasta la raíz es un escenario que combina uno o varios vectores.

La ventana de contexto es lo único que el modelo “sabe” en una llamada, además de lo aprendido en su entrenamiento. La aplicación la rellena en cada petición con el system prompt, el historial de la conversación, los documentos recuperados por RAG, las definiciones de herramientas, sus resultados y la pregunta del usuario. Tiene un tamaño máximo en tokens, y lo que no cabe se recorta o se resume.

Su importancia para seguridad es que todo comparte el mismo canal: tus instrucciones y un documento no confiable acaban como una única secuencia de tokens, sin una frontera robusta entre “órdenes” y “datos”. De ahí nace la inyección de prompt. Decidir qué entra en el contexto, con qué permisos se recuperó y cómo se delimita el contenido externo es una de las primeras líneas de defensa.

Un VPC endpoint permite que los recursos de tu VPC lleguen a servicios de AWS sin pasar por internet, un NAT gateway ni una gateway de internet. Hay dos tipos. El gateway endpoint añade una ruta en la tabla de rutas y solo existe para S3 y DynamoDB; no tiene coste. El interface endpoint, basado en AWS PrivateLink, crea una ENI con IP privada en tus subredes y da acceso a la mayoría de servicios y a servicios de terceros; se factura por hora y por datos.

A un endpoint le puedes asociar una endpoint policy para restringir qué acciones y recursos se permiten a su través, lo que ayuda a prevenir exfiltración hacia buckets ajenos.

Un VPC Flow Log captura metadatos de cada flujo de red de una interfaz, agregados en intervalos. El formato por defecto (versión 2) incluye srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action y log-status. El campo action vale ACCEPT o REJECT según lo permitieran los security groups y las NACL.

Son de metadatos, no de contenido: no capturan el payload, así que no ves qué datos viajaron ni descifran TLS. Sirven para saber quién habló con quién y correlacionar con detecciones (GuardDuty), no para inspección profunda. Para eso necesitas captura de paquetes (traffic mirroring).

Un WAF evalúa cada petición contra reglas: firmas de ataques conocidos (SQLi, XSS), listas de IPs, geolocalización y límites de tasa. En AWS se asocia a CloudFront, a un ALB, a API Gateway o a otros recursos, y ofrece grupos de reglas gestionadas.

Es un control de borde útil, pero se puede evadir con payloads ofuscados: complementa la validación y las consultas parametrizadas en la aplicación, no las sustituye.

El Cross-Site Scripting (XSS) es una inyección en la que el atacante consigue que una aplicación devuelva HTML o JavaScript controlado por él, que el navegador de la víctima ejecuta como si viniera del sitio legítimo. Permite robar cookies de sesión, falsificar acciones del usuario o montar phishing dentro de la página real.

Se distingue entre XSS reflejado, almacenado y basado en DOM. La defensa clave es el output encoding contextual (escapar al escribir en HTML, atributos, JS o URL), reforzado con una Content Security Policy y cookies HttpOnly.

«Nunca confíes, verifica siempre». En lugar de un perímetro que separa una red interna «de confianza» del exterior, zero trust trata cada acceso a cada recurso como si viniera de una red hostil.

NIST SP 800-207 describe la arquitectura: un punto de decisión de políticas (PDP, formado por el Policy Engine y el Policy Administrator) evalúa cada solicitud y un punto de aplicación (PEP) la permite o la bloquea. No es un producto: es una forma de diseñar el acceso.