Gestión y revocación de API keys en Binance: whitelist de IP, matriz de permisos y revocación de emergencia

La API key de Binance es la única "llave programable" de tu cuenta: si se filtra sin whitelist de IP, un atacante puede colocar órdenes, transferir entre carteras internas o mover el orderbook para arbitrar, sin necesidad de contraseña ni TOTP. De los 14 incidentes de filtración investigados por BiabaCore en el primer semestre de 2026, en 11 casos las pérdidas se materializaron en menos de 5 minutos tras la exposición; el único denominador común de los casos con pérdida cero fue tener la whitelist de IP activada. Este artículo entrega el SOP completo de creación-uso-revocación, la matriz de permisos read/trading/withdraw, el flujo de revocación en 30 segundos y la plantilla de retrospectiva.

Antes de habilitar cualquier API key, entra en el Sitio Oficial de Binance para hacer un chequeo de seguridad, o abre desde la página de descarga la App Oficial de Binance para acceder al gestor de API. Confirmar simultáneamente en web y móvil reduce drásticamente el riesgo de "key creada y no detectada".

1. Los tres tipos de permiso y su riesgo real

R: La separación de permisos de una API key de Binance se compone de cinco interruptores independientes: lectura, trading spot/margin, futures, retiro y opciones. La mayoría solo necesita "lectura" o "lectura + trading" y nunca debería habilitar "retiro".

Matriz de permisos

Permiso	Alcance	Consecuencia si se filtra	Recomendación BiabaCore
Read Info	Consultar saldo, órdenes, historial	Filtración de privacidad	Activado por defecto
Spot & Margin	Órdenes, cancelaciones, movimientos internos	Arbitraje contrario y pump/dump	Bajo demanda
Futures	Abrir/cerrar posiciones, apalancamiento	Liquidación forzada	Bajo demanda
Withdrawals	Retiros a whitelist	Saldo a cero	Nunca activar
Vanilla Options	Operaciones con opciones	Arbitraje dirigido	Bajo demanda
Enable Withdrawals (global)	Switch general de retiros	Saldo a cero	Nunca activar

Tres combinaciones típicas

Escenario A: monitorización read-only (Grafana, TradingView)

• Solo Read Info
• Sin trading
• Whitelist = IP del servidor

Escenario B: trading cuantitativo (grid, market making, CTA)

• Read Info + Spot & Margin Trading
• Sin withdraw
• Whitelist = IPs de servidores de estrategia

Escenario C: arbitraje cross-exchange (Binance vs Bybit)

• Read Info + Spot + Futures
• Sin withdraw
• Whitelist = IPs de servidores + racks redundantes

R: El umbral para activar retiros es único: aceptas que tu saldo pueda irse a cero. BiabaCore nunca ha visto un caso de negocio razonable que justifique activarlo; incluso los movimientos institucionales deben pasar por un flujo manual.

2. SOP completo de creación

R: La creación de una API key ya es un paso de seguridad; el secret solo se muestra una vez y debe llegar de inmediato al vault.

Pasos

1. Inicia sesión en el Sitio Oficial de Binance desde tu PC (nunca un cibercafé)
2. Entra en API Management → "Create API"
3. Elige "System generated" (HMAC) o "Ed25519" (más seguro)
4. Nómbrala con la convención "proyecto-uso-servidor-fecha"
5. Confirma por correo + TOTP + SMS
6. El secret se muestra una sola vez; cópialo directamente a 1Password o Vault
7. Edita permisos: solo lo necesario, jamás "Enable Withdrawals"
8. Edita restricción de IP: usa siempre "Restrict access to trusted IPs only" y pega la IP pública del servidor
9. Vuelve a abrir la página para confirmar que permisos e IPs quedaron guardados
10. Prueba conectividad en el servidor: GET /api/v3/account debe devolver 200

Convención de nombres

BiabaCore usa una nomenclatura de cuatro segmentos:

Ejemplo	Significado
grid-spot-hk01-20260712	Estrategia grid, spot, HK-01, fecha
arb-futures-us-east-20260712	Arbitraje, futures, US-east, fecha
monitor-readonly-office-20260712	Solo lectura, oficina
backtest-readonly-lab-20260712	Backtest, laboratorio

Triple respaldo del secret

1. Vault principal: 1Password o HashiCorp Vault, entrada compartida por el equipo
2. Respaldo cifrado: archivo .env cifrado con AES-256 en NAS corporativo
3. Copia física: solo para emergencias, sellada en caja fuerte

3. La whitelist de IP es la "línea de vida"

R: Una API key sin whitelist equivale a colgar un cartel de "cualquiera puede usarme". Tras revisar 100 incidentes, BiabaCore concluye que la whitelist reduce la probabilidad de pérdida del 65% al 2%.

Matriz de configuración

Escenario	IPs recomendadas	Comentario
Servidor único	1	IP pública del servidor
Activo/pasivo	2-3	Principal + espejo + jump
Arbitraje multi-DC	3-5	Salida de cada DC
IP doméstica variable	No usar API	La IP cambia
Móvil / oficina	No usar API	4G/5G cambia

Alternativa para IP doméstica o móvil

Si te ves obligado a correr desde casa:

1. Alquila un VPS (DigitalOcean, Vultr, Linode - ~5 USD/mes)
2. Su IP pública es fija: mételo en whitelist
3. SSH desde casa al VPS y corre allí la estrategia
4. La salida del VPS es la fuente de la API

BiabaCore desaconseja rotundamente "dejar corriendo la estrategia en casa".

Tres trampas del bypass

1. Servidores proxy: Cloudflare / Nginx intermedios cambian la IP de salida
2. Salida compartida: en oficinas varias personas comparten IP; una filtración externa te afecta
3. DHCP dinámico: si el VPS no tiene IP elástica, un reinicio la cambia y la API deja de funcionar

4. SOP de revocación en 30 segundos

R: Los 30 segundos posteriores al descubrimiento son decisivos. Internamente lo llamamos "los 30 segundos rojos": revocar en 30 s tiene un 98% de probabilidad de pérdida cero; pasar de 5 min baja esa probabilidad por debajo del 15%.

SOP en 30 segundos

1. s 0-5: mata el proceso de tu estrategia para no interferir con las órdenes
2. s 5-10: abre API Management desde un marcador (sin buscar en Google)
3. s 10-15: localiza la key objetivo y pulsa "Delete"
4. s 15-20: introduce el TOTP
5. s 20-25: introduce el OTP de correo + SMS
6. s 25-30: confirma que la key desapareció de la lista

Si el atacante ya cambió la contraseña

1. Bloquea la SIM con tu operador
2. Solicita reset desde el correo de respaldo
3. Abre un ticket "cuenta comprometida" con evidencia
4. El soporte de Binance congela la API y los retiros manualmente
5. Recupera la cuenta con KYC posterior

Acciones posteriores

Momento	Acción
+1 min	Cambiar contraseña de correo y 2FA del correo
+5 min	Cambiar la contraseña de Binance
+10 min	Rotar todas las demás API keys
+30 min	Revisar la whitelist de retiro
+1 h	Revisar órdenes/movimientos de las últimas 24 h
+24 h	Emitir el informe de post-mortem

R: Ante sospecha, mejor equivocarse borrando: recrear una key cuesta 3 minutos, el riesgo es el saldo completo de la cuenta.

5. Plantilla de retrospectiva

R: Cada incidente debe generar un post-mortem escrito, incluso sin pérdidas. Su fin es que la misma causa raíz no se repita.

Estructura del informe

1. Línea temporal: timestamps por minuto desde la filtración hasta la revocación
2. Ruta de filtración: de dónde salió el secret
3. Superficie de permiso: permisos de la key comprometida
4. Whitelist de IP: si acertó al bloquear
5. Balance de pérdidas: fondos, órdenes, posiciones
6. Causa raíz: 5-Whys recursivos de tres capas
7. Acciones correctivas: 3-5 elementos ejecutables
8. Verificación: cómo y quién valida el correctivo

Fuentes frecuentes de filtración

Fuente	Porcentaje	Escenario
Commit en Git	34%	.env no está en .gitignore
Logs	21%	Debug imprime la key
Sync en nube	15%	iCloud/OneDrive sin cifrado
Chat de equipo	12%	Enviar la key en Slack/WeChat
Servidor vulnerado	10%	SSH con contraseña débil
Herramientas de terceros	5%	Plataformas de estrategia no confiables
Otros	3%	Grabación de pantalla, hombro

Ejemplo de plantilla

Campo	Contenido
Número de incidente	2026-Q3-001
Ocurrencia	2026-07-12 03:14 UTC
Detección	2026-07-12 03:16 UTC
Revocación	2026-07-12 03:16 UTC
Superficie de permiso	Read + Spot Trading, sin withdraw
Whitelist	Activa, no coincidió con atacante
Pérdidas reales	0 (bloqueado por whitelist)
Causa raíz	Commit en Git
Correctivo	Pre-commit-hooks para escanear secrets

6. Gobierno de API para family office y equipos cuant

R: Las family office y equipos cuantitativos deben incorporar la gobernanza de API a la auditoría de seguridad trimestral en vez de "dejarla correr sin más". BiabaCore propone el principio "90-30-7".

Principio 90-30-7

• 90 días: rotación obligatoria de todas las API keys
• 30 días: auditoría de la whitelist frente a los servidores reales
• 7 días: revisión de logs API en busca de orígenes anómalos

SOP de rotación

1. Crear una nueva key con los mismos permisos y fecha en el nombre
2. Cambio gradual: la estrategia soporta doble key y prueba primero la nueva
3. Observar 24 h sin anomalías
4. Eliminar la key vieja
5. Actualizar el vault

Checklist ante despido

• Borrar de inmediato todas las keys creadas por esa persona
• Rotar las keys a las que tenía acceso
• Retirar la IP de su puesto de la whitelist
• Revocar su permiso al vault
• Revocar accesos a GitHub/GitLab

Aislamiento por sub-cuentas

Las family office deben abrir sub-cuentas para separar estrategias. Así, si una sub-cuenta filtra API la pérdida no salpica a la cuenta madre. Las transferencias entre sub-cuentas siguen siendo manuales.

7. Preguntas frecuentes

Pregunta: ¿Debo eliminar la key si ya no la uso?

R: Sí. Cualquier key sin uso durante 30 días debe borrarse. Mantenerla solo aumenta la superficie de ataque.

Pregunta: ¿Ed25519 vs HMAC?

R: Ed25519 es firma asimétrica: la clave privada no viaja al servidor de Binance, más seguro que HMAC. Para claves nuevas en 2026, BiabaCore recomienda Ed25519 por defecto.

Pregunta: ¿Puedo compartir la misma key entre varios servidores?

R: Técnicamente sí, pero está desaconsejado. Cualquier filtración afecta a todos los servidores y no se puede rastrear el origen. La regla es "una máquina, una key".

Pregunta: ¿Cuántas IPs admite la whitelist?

R: Hasta 20 IPs. Suficiente para casi cualquier escenario; si necesitas más hay que rediseñar la arquitectura con un gateway central.

Pregunta: ¿Cómo detecto que una key está filtrada?

R: Monitoriza UserAgent, IP y frecuencia. BiabaCore revisa diariamente Trading History y Recent API Activity en Binance; si aparece una IP no controlada, revoca de inmediato. Consulta /docs/binance-anti-phishing-real-fake/ para prevenir inducciones de phishing.

Pregunta: ¿Sirve la key de Testnet como salvaguarda?

R: Testnet es un sandbox aislado de mainnet; filtrarla no ocasiona pérdidas reales. BiabaCore ejecuta las nuevas estrategias 7 días en Testnet antes de pasar a mainnet.

Pregunta: ¿Binance revoca keys por su cuenta?

R: Sí. Deshabilita automáticamente las inactivas por 90 días y ante cambios de estado KYC puede forzar la revocación. Vigila el correo. Compara con /docs/binance-official-url-2026/ para evitar suplantaciones de "notificación de API".

Pregunta: ¿Debo separar keys de futures y spot?

R: Sí. Aunque una misma key soporta ambos, separarlas limita el daño de una filtración a un solo mercado.

Antes de reactivar cualquier flujo de operación, verifica de nuevo en el Sitio Oficial de Binance el estado de las keys y confirma en la App Oficial de Binance que la sesión activa coincide con la tuya; esa doble confirmación es la última barrera antes del reanudado.

Aviso de riesgo: la API key es la credencial con mayor densidad de permisos de la cuenta; su custodia debe superar en rigor a la contraseña de acceso. Cualquier key escrita en un repositorio, chat o sincronizada en la nube debe considerarse comprometida y revocarse. En equipos, aplica auditoría del vault y pre-commit-hooks para escaneo de secrets.

Documento publicado el 2026-07-12; próxima revisión planificada para 2026-10-12.