Seguridad en Lendbox

• Lendbox se ejecuta en Amazon Web Services en la región us-east-1, Estados Unidos. La aplicación, la base de datos y los documentos subidos a Amazon S3 están todos en esa región.
• Los datos se cifran en tránsito mediante TLS 1.3.
• Los datos se cifran en reposo con AES-256. Los volúmenes de almacenamiento de la base de datos y de la aplicación se cifran con cifrado AWS EBS. Los documentos subidos y las copias de seguridad se cifran del lado del servidor en Amazon S3. Las claves de cifrado se gestionan mediante AWS Key Management Service.
• Los clientes pueden exportar todo su conjunto de datos en cualquier momento desde el producto. No hace falta solicitárnoslo.

Al cerrar una cuenta, los datos del cliente se conservan 60 días y después se eliminan de forma permanente. Durante ese periodo la cuenta puede restaurarse a petición.

• La aplicación y la base de datos se ejecutan en infraestructura AWS aislada. Las bases de datos no son accesibles públicamente y no aceptan conexiones desde internet. La capa web la sirve Vercel.
• Todo el tráfico entrante pasa por Cloudflare, que proporciona mitigación de DDoS y un cortafuegos de aplicaciones web.
• Los entornos están separados: producción, staging y desarrollo se ejecutan en infraestructuras distintas sin credenciales compartidas. Desarrollo y staging no contienen datos de producción.

Los controles de esta sección los opera el cliente, no nosotros. La institución los configura por sí misma y puede verificar en cualquier momento qué puede hacer cada miembro del personal.

• Permisos graduados por módulo. Cada módulo puede configurarse por miembro del personal en uno de los seis niveles que se muestran abajo.
• Asignación de roles multisucursal. Una misma cuenta puede tener acceso a varias sucursales y un rol distinto en cada una, de modo que quien es gerente en una sucursal es usuario de solo lectura en otra.
• Separación entre quien solicita y quien aprueba. Las acciones sensibles se reparten entre el miembro del personal que las solicita y el que las aprueba. Los flujos de aprobación son configurables por institución, incluido el número de pasos y qué roles pueden actuar en cada uno.
• Autenticación multifactor. Disponible en cada inicio de sesión y activable de forma independiente por cada usuario y miembro del personal.
• Las sesiones caducan a los 5 días y exigen volver a autenticarse.

• Cada acción realizada en el producto se registra con el usuario que la ejecutó, el registro afectado y una marca de tiempo.
• Los registros de auditoría son de solo anexado. No pueden editarse ni eliminarse desde la aplicación, ni siquiera por los administradores de la institución.
• Los periodos contables cerrados quedan bloqueados frente a modificaciones retroactivas.
• Los administradores de la institución pueden exportar el historial de auditoría en cualquier momento.

El historial de auditoría se conserva durante toda la vida de la cuenta, desde la fecha en que se creó. No hay ventana móvil ni truncamiento.

• Las bases de datos se respaldan cada hora.
• Las copias de seguridad se cifran y se conservan 6 meses.
• Objetivo de punto de recuperación (RPO): 1 hora.

Las restauraciones se prueban cada semana en un entorno que no es de producción. Una copia de seguridad que nunca se ha restaurado no es una copia de seguridad.

• El acceso a los datos de producción está limitado a una sola persona identificada, el fundador. Ningún otro empleado, contratista o tercero posee credenciales de producción. Es una decisión de diseño deliberada: es la menor superficie posible de personas que pueden alcanzar los datos de los clientes.
• El acceso a producción es nominal y está protegido con autenticación multifactor. No se usan cuentas ni credenciales compartidas en ninguna parte de la organización.
• Los secretos y credenciales de la aplicación se gestionan en Doppler. No se almacenan en el control de versiones ni en los equipos de los desarrolladores.
• Continuidad: un procedimiento documentado de emergencia cubre el caso de que la persona que posee las credenciales de producción no esté disponible. Las credenciales de recuperación se custodian en depósito sellado con un segundo tercero identificado, se liberan ante un desencadenante definido y cada uso queda registrado. El procedimiento restablece el acceso de los clientes a sus propios datos; no concede acceso permanente a nadie.

Las vulnerabilidades de seguridad se remedian según plazos basados en la gravedad, contados desde el momento en que se confirma que la vulnerabilidad afecta a Lendbox.

• Las dependencias de la aplicación se supervisan de forma continua con Renovate, que abre automáticamente pull requests de parches a medida que se publican las versiones upstream.
• Las actualizaciones de dependencias se revisan y fusionan en un ciclo semanal. Los avisos con un exploit conocido se saltan ese ciclo y se atienden de inmediato.
• Las imágenes base del sistema operativo y de los contenedores se reconstruyen y redespliegan mensualmente, y de inmediato si se divulga una vulnerabilidad crítica.

Los servicios que aparecen aquí tratan datos por cuenta nuestra bajo contrato.

Se avisa a los clientes por correo electrónico con al menos 30 días de antelación antes de añadir un nuevo subencargado o sustituir uno existente, a la dirección del contacto administrativo de la cuenta.

Componentes autoalojados

Los siguientes se ejecutan en infraestructura que controlamos. Se nombran porque son visibles para cualquiera que inspeccione el producto, pero no son subencargados: ningún tercero recibe datos a través de ellos.

• La salud de la infraestructura y de la aplicación se supervisa de forma continua con Prometheus, Alertmanager y cAdvisor, y las alertas se enrutan a un ingeniero de guardia.
• En caso de incidente de seguridad que afecte a datos de clientes, los clientes afectados son notificados en un plazo de 72 horas desde la confirmación. Las notificaciones indican qué ocurrió, qué datos se vieron afectados, qué hemos hecho para contenerlo y qué acción, si la hubiera, debe tomar el cliente.
• Los incidentes de disponibilidad se publican en la página de estado mientras se están atendiendo, no después de resolverse.

• Escribe a [email protected]. Incluye los pasos para reproducirla.
• Acusamos recibo de cada reporte en un plazo de 3 días hábiles y damos una evaluación de la gravedad y del plazo de corrección previsto en un plazo de 10 días hábiles.
• No emprendemos acciones legales contra investigadores que reportan de buena fe, evitan vulnerar la privacidad y degradar el servicio, y nos dan un plazo razonable para corregir antes de divulgar.
• Nuestros datos de contacto legibles por máquina se publican en /.well-known/security.txt.