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.
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.
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:
# Grupos de seguridad con reglas de entrada abiertas a todo Internetaws 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 tableMedirla#
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.
-
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. -
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.
-
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 obligatoriohttp_put_response_hop_limit = 1} -
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. -
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.
-
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
{ "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/*" } }}{ "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.
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.