Política de seguridad de la información

Traducción de cortesía. La versión en inglés es la que rige.

Esta política explica cómo LFW protege los sistemas que opera y los sistemas de los clientes en los que trabaja. Está escrita para un revisor de seguridad y describe la práctica, no la intención.

Versión 1.0, 6 de octubre de 2026. Forma parte de las prácticas publicadas en la página de confianza, junto con la política de control de acceso, el plan de respuesta a incidentes y la política de uso aceptable.

1. Alcance y responsable

La política abarca LFW.com, el Portal del cliente en my.lfw.com, el sitio de administración del personal, el servidor en el que funcionan, los equipos de trabajo de LFW y el acceso de LFW a los sistemas de los clientes.

Leland Fiegel, fundador de LFW, es el responsable de esta política y su único miembro del personal al 27 de septiembre de 2026. Cuando un control depende de una segunda persona, esta política lo dice en lugar de dar a entender que existe.

2. Dónde funcionan los sistemas de LFW

Las aplicaciones propias de LFW funcionan en un servidor de Hetzner en Ashburn, Virginia, detrás de Cloudflare. El firewall del servidor acepta tráfico web solo desde los rangos de direcciones de Cloudflare, de modo que el servidor no es accesible directamente desde internet en los puertos web.

El acceso por SSH es solo con llave; se rechazan el inicio de sesión con contraseña y las contraseñas vacías. La aplicación, su base de datos y su índice de búsqueda escuchan en la dirección de loopback. fail2ban bloquea las direcciones tras varias conexiones fallidas.

Los visitantes llegan al sitio por TLS 1.3 con una política HSTS de un año; se rechazan TLS 1.0 y 1.1. El tráfico entre Cloudflare y el servidor también va cifrado.

El sitio de administración del personal y el Portal del cliente son orígenes separados (admin.lfw.com y my.lfw.com). Un script inyectado en una página pública no puede actuar como un miembro del personal o un cliente con sesión iniciada, porque ninguna de las dos cookies de sesión llega al sitio público.

3. La aplicación

Cada página envía una política de seguridad de contenido que autoriza scripts y estilos por hash, sin permitir scripts en línea, junto con los encabezados estándar: sin detección del tipo MIME, una política de referencia estricta y una política de permisos que niega la cámara, el micrófono y la ubicación.

Cada escritura en la aplicación se verifica según el origen del que proviene, y los puntos de acceso públicos tienen un límite de solicitudes por dirección. El tipo de los archivos subidos se determina inspeccionando sus bytes, nunca por lo que declara el remitente; se rechaza SVG; una solicitud puede llevar tres archivos de hasta ocho megabytes cada uno.

Los enlaces privados (informes, cotizaciones, invitaciones) usan tokens aleatorios de al menos 72 bits. Los secretos se guardan en un solo archivo en el servidor, limitado al administrador del servidor y a la cuenta de servicio. El repositorio no contiene secretos.

4. Construcción y publicación

Cada versión se construye en un contenedor desechable que no contiene llaves, ni archivos privados, ni acceso al servidor. Los scripts de instalación de dependencias están desactivados; solo se recompilan dos paquetes nativos, por nombre.

La construcción falla ante un error de lint, un error de muro de texto o de uso de mayúsculas, una regla de componente duplicada, una vulnerabilidad conocida de severidad alta en cualquiera de los dos árboles de dependencias de producción, o una prueba fallida.

Se rechaza una versión de una dependencia publicada hace menos de siete días. Las versiones envenenadas normalmente se retiran dentro de ese plazo, así que la espera es el control.

Una versión se activa completa, después de que la nueva versión responde a sus verificaciones de rutas públicas y protegidas, y la versión anterior se conserva para poder revertir.

5. Copias de respaldo

El directorio de datos del servidor, las bases de datos, los secretos y la configuración se respaldan con restic: cifrados y deduplicados, una vez al día y en cada publicación. Solo el administrador del servidor puede leer las copias de respaldo.

Cada base de datos se copia con la función de respaldo en línea propia de SQLite antes de guardarse, de modo que cada instantánea es coherente. El repositorio se verifica cada semana.

Retención: las diez instantáneas más recientes, 30 diarias, 26 semanales, 24 mensuales y 10 anuales. También se guarda una copia cifrada del repositorio fuera de la cuenta de alojamiento, en un bucket privado de Cloudflare R2.

Las copias de respaldo del sitio de un cliente son las del proveedor de alojamiento. LFW verifica periódicamente que se ejecuten y restaura a partir de ellas cuando hace falta, como indica el anexo de gestión.

6. Registros y monitoreo

El servidor web registra cada solicitud con su dirección de origen. El Portal del cliente guarda un historial de solo anexión de los cambios en solicitudes y documentos, registra cada vez que el personal ve la cuenta de un cliente y registra cada token de inicio de sesión al usarse, para que ninguno pueda reutilizarse.

LFW Monitor revisa LFW.com todos los días igual que revisa los sitios de los clientes: accesibilidad, enlaces rotos, velocidad, TLS, registros de autenticación de correo, la política de seguridad de contenido y los demás encabezados de seguridad. La disponibilidad se verifica cada minuto, y el pie de cada página la informa.

En el sitio de un cliente, LFW Activity Logs registra quién cambió qué dentro de WordPress y cuándo, para que un incidente pueda reconstruirse junto con los registros de acceso del proveedor de alojamiento.

7. Sitios de los clientes

LFW acepta un sitio solo si cuenta con tres cosas: un alojamiento administrado a nombre del cliente, un firewall dentro de WordPress (Wordfence Premium) con licencia para el sitio, y Cloudflare delante del alojamiento con su firewall de aplicaciones web y su mitigación de DDoS activados.

El núcleo de WordPress, los temas y los plugins se actualizan cada mes desde control de versiones, con verificaciones automáticas tras cada publicación. Una versión de seguridad se aplica antes del ciclo mensual. Entre actualizaciones, los firewalls bloquean los ataques conocidos, incluidos los ataques contra una falla hecha pública antes de que exista su corrección.

8. Revisión de los sistemas propios de LFW

LFW revisó LFW.com, sus puntos de acceso, el servidor, el DNS y la autenticación de correo, y el repositorio el 16 de septiembre de 2026, mediante inspección y pruebas sin autenticación de su propia infraestructura. No se encontró ninguna vulnerabilidad que un visitante sin autenticar pudiera aprovechar.

El único hallazgo moderado, permisos de archivo que permitían a una segunda cuenta de servicio del servidor leer las bases de datos de LFW, se corrigió el mismo día y ahora lo vigila una prueba. Los demás hallazgos eran mejoras de endurecimiento, aceptadas tal como están, y se registran en privado.

Todavía no se ha encargado ninguna prueba de penetración independiente de los sistemas de LFW. Cuando el contrato de un cliente exige una prueba del sitio del cliente, LFW la organiza e informa el resultado.

9. Cómo reportar un problema

Los reportes de seguridad se envían a security@lfw.com, indicado en security.txt (en inglés). La política de divulgación de vulnerabilidades, con su alcance, sus reglas y su compromiso de puerto seguro, está publicada en lfw.com/security.

Una persona responde en un plazo de dos días hábiles. Horario laboral: De lunes a viernes, de 9 a. m. a 5 p. m., hora del Este (de 6 a. m. a 2 p. m., hora del Pacífico), excepto los feriados federales. No ofrecemos atención fuera de ese horario ni guardias.

10. Lo que esta política no afirma

LFW no tiene ningún informe SOC 2 ni ISO 27001 y no se ajusta a ningún marco de referencia con nombre. No afirma tener cifrado de disco para la base de datos en producción de su servidor, criptografía validada según FIPS ni un sistema de detección de intrusiones en la red.

Esta política cambia de forma abierta: la versión y la fecha indicadas arriba cambian cuando ella cambia, y el texto anterior permanece en el historial del repositorio.