Saltar al contenido

Temas

Superficie de ataque

Todos los puntos por los que un atacante puede entrar, afectar o sacar datos de un sistema, y cómo inventariarlos y reducirlos.

FundamentosEn progreso 8 min de lectura1 oct 2026#superficie-de-ataque#asm#hardening#principios

Un atacante no necesita entender tu arquitectura entera: le basta con una puerta que responda. Un puerto que alguien abrió “solo para probar”, un endpoint de debug que nadie retiró, un rol IAM de un proyecto cancelado. Cada pieza que existe y es alcanzable es una oportunidad. La superficie de ataqueSuperficie de ataqueConjunto de puntos por los que un atacante puede entrar, causar un efecto o extraer datos de un sistema. es el conjunto de esas oportunidades, y reducirla es uno de los controles más baratos y efectivos que existen: lo que no existe no se puede explotar.

Qué es exactamente#

NIST la define como el conjunto de puntos en el límite de un sistema, de un componente o de un entorno por los que un atacante puede intentar entrar, provocar un efecto o extraer datos. La guía de OWASP la descompone en cuatro partes:

  • Todos los caminos de entrada y salida de datos y comandos: puertos, APIs, formularios, colas, ficheros que se procesan.
  • El código que protege esos caminos: autenticación, autorización, validación.
  • Los datos valiosos que hay detrás: PII, secretos, claves.
  • El código que protege esos datos: cifrado, controles de acceso, auditoría.

Fíjate en que la salida también cuenta: un servicio que puede hacer peticiones arbitrarias a Internet ofrece un camino de exfiltración.

Reducir la superficie de ataque de Citas
CITASAPIcontenedoresBDPostgreSQL443CDN + WAF22SSH al bastión5432Base de datos/adminPanel de administración/debugEndpoint de pruebasbucketAdjuntos públicosAtacanteescáner6puntos de entradaexpuestospunto de entradaexpuesto← única entrada

Paso 1 de 6Inventario

No puedes reducir lo que no ves. Estos son todos los puntos por los que alguien de fuera puede interactuar hoy con Citas.

Tipos de superficie#

Tipo Ejemplos en Citas
Digital, red y aplicación El dominio público servido por la CDN, la API, el balanceador de carga, los formularios de reserva, los webhooks entrantes
Digital, plano de control cloud Usuarios y roles de identidad (IAM), relaciones de confianza entre cuentas, el rol de CI/CD federado vía OIDC, la consola del proveedor
Digital, cadena de suministro Dependencias npm, imágenes base de contenedor, acciones de GitHub de terceros
Física Portátiles del equipo, un servidor NAS en la oficina de una clínica
Social El soporte que puede resetear contraseñas, el phishing a administradores de clínicas

También importa desde dónde se mira. La superficie externa es lo que ve un desconocido desde Internet. La interna es lo que ve alguien que ya está dentro: una tarea comprometida, un empleado o un proveedor. Una base de datos en una subred aislada no forma parte de la superficie externa, pero sí de la interna de cualquier tarea que pueda conectarse a ella.

Inventariar antes de reducir#

No puedes proteger lo que no sabes que existe. La gestión de superficie de ataque (Attack Surface Management, ASM) consiste en descubrir de forma continua todo lo expuesto y compararlo con lo que debería estarlo. Todo proveedor ofrece piezas para esto; conviene reconocerlas por lo que hacen, no por su nombre comercial:

  • Inventario de recursos y reglas de cumplimiento que marcan configuraciones peligrosas (SSH abierto a todo Internet, almacenamiento público).
  • Analizador de accesos: detecta recursos compartidos fuera de tu organización (almacenes de objetos, roles, claves) y permisos que nadie usa.
  • Escaneo de vulnerabilidades en imágenes de contenedor y máquinas, y la alcanzabilidad de red de esas máquinas.
  • Agregador de hallazgos (CSPM) que los compara con estándares de referencia.

Cada capacidad recibe un nombre distinto en cada nube, pero es la misma idea:

Capacidad AWS Azure Google Cloud
Inventario de recursos + reglas AWS Config Azure Policy / Resource Graph Cloud Asset Inventory
Análisis de accesos externos y sin usar IAM Access Analyzer Entra Permissions Management IAM Recommender / Policy Analyzer
Escaneo de vulnerabilidades Amazon Inspector Defender for Cloud Artifact Analysis
Agregación de hallazgos (CSPM) Security Hub Microsoft Defender for Cloud Security Command Center

Sea cual sea el proveedor, una búsqueda que conviene ejecutar en cualquier cuenta nueva es listar las reglas de entrada abiertas a todo Internet. En AWS, con la CLI:

Terminal · ejemplo en AWS
# Grupos de seguridad con reglas de entrada abiertas a todo Internet
aws ec2 describe-security-groups \
--filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
--query 'SecurityGroups[].{id:GroupId,nombre:GroupName,puertos:IpPermissions[].FromPort}' \
--output table

Medirla#

No existe una cifra universal, pero sí criterios para ordenar qué reducir primero. Para cada punto de entrada, valora:

  • Exposición: ¿alcanzable desde Internet, desde la red privada o solo localmente?
  • Autenticación: ¿anónimo, con un usuario cualquiera o solo para administradores?
  • Privilegio: ¿qué puede hacer quien lo explote? Un endpoint que ejecuta con el rol de la tarea vale lo que vale ese rol.
  • Datos: ¿qué hay detrás? PII, secretos o nada sensible.

Un endpoint anónimo, público y con acceso a PII va primero. Michael Howard formalizó esta idea en Microsoft con el Relative Attack Surface Quotient: no se trata de contar puertas, sino de ponderarlas.

Reducirla#

La reducción tiene tres movimientos: eliminar lo que sobra, restringir quién alcanza lo que queda y endurecer lo que debe seguir expuesto.

  1. Cerrar acceso directo a la infraestructura

    Ni SSH ni RDP ni puertos de bases de datos abiertos a 0.0.0.0/0. Para administrar, usa un servicio de acceso por agente (como Session Manager de AWS) que no necesita puertos de entrada y deja registro de auditoría.

  2. Bloquear el acceso público al almacenamiento a nivel de cuenta

    Así un almacén de objetos nuevo no puede volverse público por error. La SPA se sirve con una CDN y control de acceso al origen, sin almacén público expuesto.

  3. Proteger el endpoint de metadatos de las máquinas

    El servicio de metadatos de una instancia entrega credenciales a quien lo consulta desde la propia máquina; sin protección, un SSRF deja que un atacante las robe (el camino que llevó a la fuga de Capital One). La mitigación es exigir un token de sesión obtenido con una petición previa, lo que frena la mayoría de esos ataques. En AWS esto es IMDSv2:

    ejemplo en AWS (Terraform)
    metadata_options {
    http_endpoint = "enabled"
    http_tokens = "required" # IMDSv2 obligatorio
    http_put_response_hop_limit = 1
    }
  4. Cortar las salidas innecesarias

    Con endpoints privados hacia los servicios del proveedor (almacén de objetos, gestor de secretos, registro de contenedores, colas), las tareas de Citas hablan con esos servicios sin salir a Internet, y los grupos de seguridad de salida dejan de ser 0.0.0.0/0.

  5. Podar identidades y confianza

    Elimina usuarios y claves que nadie usa (los informes de credenciales y el analizador de accesos te dicen cuáles) y acota las relaciones de confianza al mínimo.

  6. Adelgazar lo que despliegas

    Imágenes base mínimas (distroless), sin herramientas de depuración en producción, sin dependencias huérfanas y sin rutas de debug.

La confianza del rol de despliegue merece un ejemplo (en AWS), porque es un error muy común:

Vulnerable

Seguro

trust-policy.json
{
"Effect": "Allow",
"Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:mi-org/*"
}
}
}
trust-policy.json
{
"Effect": "Allow",
"Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
"StringLike": {
"token.actions.githubusercontent.com:sub":
"repo:mi-org/citas:ref:refs/heads/main"
}
}
}

Con la primera versión, cualquier repositorio de la organización (incluido uno que cree un becario) puede desplegar en producción. Con la segunda, solo la rama main del repositorio de Citas.

Citas, antes y después#

Punto de entrada Antes Después
Web CDN + WAF Igual: es la única entrada pública
SSH (22) Bastión abierto a 0.0.0.0/0, metadatos sin protección Eliminado: acceso por agente
PostgreSQL (5432) Base de datos gestionada con acceso público “temporal” Subred aislada, solo desde el grupo de seguridad de la API
/admin Público, con usuario y contraseña Grupo del proveedor de identidad con MFA + acceso privado
/debug Olvidado en producción Eliminado del código
Almacén citas-adjuntos Política pública para descargas Bloqueo de acceso público + URLs prefirmadas

Tu turno

Explica la superficie de ataque con un ejemplo de tu trabajo actual

Haz un inventario rápido (30 minutos) de un sistema de tu trabajo, tanto la superficie externa como la interna y la del plano de control.

  • ¿Qué puntos de entrada son públicos? ¿Cuáles deberían serlo?
  • ¿Hay puertos de administración, endpoints de prueba o almacenes alcanzables desde fuera?
  • ¿Qué identidades (usuarios, roles, claves, tokens de CI) pueden tocar ese sistema? ¿Cuántas se usan de verdad?
  • ¿Qué salidas a Internet tiene? ¿Las necesita todas?
  • Elige un punto para eliminar esta semana y uno para restringir.
superficie-mi-trabajo.md
Sistema: ...
| Punto de entrada | Exposición (Internet/red privada/local) | Autenticación | Datos detrás | Acción (eliminar/restringir/endurecer) |
| ---------------- | ------------------------------- | ------------- | ------------ | -------------------------------------- |
| | | | | |

Reto

Pones un WAF delante de la API. ¿Has reducido la superficie de ataque?

▸Mostrar solución

No. El punto de entrada sigue existiendo y sigue siendo público: has añadido un control sobre él, que reduce la probabilidad de explotarlo. Reducir la superficie es eliminar o restringir puntos de entrada; endurecer es protegerlos mejor. Las dos cosas suman, pero no son lo mismo.

Reto

¿Un rol IAM que nadie ha usado en 6 meses forma parte de la superficie de ataque?

▸Mostrar solución

Sí, de la del plano de control. Si alguien consigue asumirlo, por una relación de confianza demasiado amplia o por credenciales de quien puede asumirlo, obtiene sus permisos. Además, como nadie lo usa, su actividad destacaría menos en una revisión. El analizador de accesos de la nube genera hallazgos de acceso no utilizado precisamente para podarlos.

En resumen#

  • La superficie de ataque es todo punto por el que alguien puede entrar, causar un efecto o sacar datos: red, aplicación, plano de control, cadena de suministro, física y personas.
  • Distingue superficie externa e interna, y no olvides la salida.
  • Inventaria de forma continua (inventario de recursos, análisis de accesos, escaneo de vulnerabilidades y agregación de hallazgos) antes de decidir.
  • Pondera, no cuentes: exposición, autenticación, privilegio y datos.
  • Reduce en tres movimientos: eliminar, restringir y endurecer. Lo que queda se protege con el resto de principios.

Referencias#

Notas relacionadas

ESC
↑↓ para navegar↵ para abriresc para cerrar