Legal · ALMC SHIELD

Medidas de Seguridad — Abuse Shield

Versión 1.0.1 En vigor desde 2026-05-28 Idioma ES

Resumen de medidas de seguridad — Abuse Shield

Este documento describe las medidas técnicas y organizativas implementadas en el servicio Abuse Shield para proteger la confidencialidad, integridad y disponibilidad de los datos tratados. Se actualiza periódicamente.

1. Cifrado

  • En tránsito: TLS 1.2 / 1.3 obligatorio en todos los endpoints públicos y de API. HSTS preload habilitado.
  • En reposo:
    • API keys de cliente: cifradas con AES-256 mediante Crypt::encryptString de Laravel y la clave maestra APP_KEY. Solo se guarda un hash SHA-256 para búsqueda eficiente.
    • Tokens de proveedores externos (AbuseIPDB, IPInfo): cifrados igual.
    • Webhook secrets: cifrados igual.
    • Bases de datos: cifrado a nivel de tablespace InnoDB activable según requisitos del cliente.
    • Backups: cifrados con clave gestionada por separado del entorno productivo.

2. Autenticación y control de acceso

  • Autenticación de la API mediante Authorization: Bearer <api_key>. Lookup en O(1) sobre el hash SHA-256 indexado.
  • Periodo de gracia de 24 h en la rotación de keys para permitir actualización progresiva en todos los nodos sin interrupciones.
  • Panel cliente y panel superadmin protegidos por autenticación de sesión Laravel con timeouts de inactividad configurables. MFA disponible para cuentas SaaS y obligatorio para administradores de ALMC.
  • Sudoers del agente limitado a 4 subcomandos de fail2ban-client: nada más.

3. Aislamiento del agente

El agente Python almc-shield que se instala en los servidores del cliente:

  • Corre como usuario sistema almc-shield sin privilegios de root.
  • Vive en un venv Python aislado en /opt/almc-shield/venv/: no afecta al Python del sistema ni a otras aplicaciones.
  • Unit systemd con hardening estricto: ProtectSystem=strict, NoNewPrivileges, PrivateTmp, ProtectHome, RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX, CapabilityBoundingSet= vacío, MemoryMax=128M, TasksMax=32.
  • Cero puertos abiertos: el agente solo realiza conexiones HTTPS salientes a almc.es:443. No acepta tráfico entrante.
  • Idempotency-Key determinístico (SHA-256 de los IDs del batch) para que un reintento tras un fallo intermedio no genere reports duplicados en el servidor.

4. Validación de entrada

  • Direcciones IP: validación estricta con FILTER_FLAG_NO_PRIV_RANGE + FILTER_FLAG_NO_RES_RANGE; se rechazan rangos privados, loopback, link-local, multicast.
  • Nombres de jail: regex ^[a-z0-9_-]{1,64}$ para prevenir inyección.
  • Timestamps: solo se aceptan dentro de la ventana [-7 días, +5 minutos].
  • Tamaño máximo de payload: 256 KB; máximo 500 bans por batch.
  • Webhook URLs: HTTPS obligatorio; bloqueamos resoluciones a IPs privadas para evitar SSRF.

5. Rate limiting y protección contra abuso

  • Rate limit per-tenant y per-IP en todos los endpoints (Laravel throttle sobre Redis).
  • Heurísticas anti-envenenamiento que detectan tenants reportando IPs de la whitelist global, volúmenes anómalos, IPs de su propio ASN, etc.
  • Cuarentena automática de tenants sospechosos: sus reports siguen aceptándose en su blocklist privado pero no contribuyen al feed global hasta revisión humana.
  • Anti-SSRF en webhook salientes: validación de URL HTTPS y rechazo de hosts privados.

6. Trazabilidad y auditoría

  • Audit log inmutable (ab_audit_log) con 365 días de retención que registra: rotaciones de API key, cambios de estado de IPs, suspensiones de tenants, modificaciones de whitelist, publicación de docs legales y demás acciones sensibles.
  • Logs estructurados en JSON listos para ingesta en un SIEM externo.
  • Métricas Prometheus en /admin/metrics/abuse-shield para integración con sistemas de observabilidad del cliente.

7. Continuidad y recuperación

  • Backups completos diarios + backups de tablas críticas cada 6 h.
  • Prueba mensual de restauración documentada.
  • El agente local tiene outbox persistente en SQLite WAL que sobrevive reinicios y caídas de red prolongadas (configurable, por defecto 100 MB / 7 días).
  • El servidor central re-aplica IPs al jail dedicado almc-blocklist automáticamente tras detectar un reinicio de fail2ban (mecanismo de re-hidratación con detección triple: PID watch + IP-count drop + canary IP).

8. Gestión de incidentes y vulnerabilidades

  • Procedimiento documentado de respuesta a brechas con notificación a la AEPD en menos de 72 h (ver /breach-proc).
  • Política de gestión de vulnerabilidades publicada en /vuln-mgmt con canal de responsible disclosure: security@almc.es.
  • SLAs de remediación por severidad: críticas < 72 h, altas < 7 días, medias < 30 días.

9. Compliance roadmap

Estado actual: cumplimos RGPD y aplicamos buenas prácticas de seguridad equivalentes a ASVS L2. Hoja de ruta de certificaciones:

  • Fase actual: RGPD + audit log + cifrado + MFA admin + backups.
  • 3-9 meses: SIEM self-hosted (Wazuh), SAST/DAST/SCA en CI/CD, pentest externo anual, ISO 27001 readiness assessment.
  • 9-18 meses: certificación ISO 27001 o Esquema Nacional de Seguridad (ENS) Medio, según necesidades comerciales.

10. Contacto de seguridad

Para reportar una vulnerabilidad o cualquier preocupación de seguridad: security@almc.es

Versión 1.0.1 — vigente desde la fecha de publicación. Documento mantenido por el equipo de seguridad de ALMC y versionado desde el panel administrativo /marino/saas/abuse-shield/legal.