Saltar al contenido
Budger

CÓMO PROTEGE DLR

Lo que hacemos con tu información, sin letra pequeña.

Esta es la página que te mostramos cuando nos preguntas por la seguridad de nuestros sistemas. Cada punto dice lo que hacemos hoy; lo que todavía no está, lo decimos también.

Ver el estado en vivoReportar una falla

PRÁCTICAS

Lo que hacemos con cada sistema de DLR.

Lo que aún no está igual en todos los sistemas va marcado como POR CONFIRMAR: preferimos decirlo.

Tus datos se quedan contigo

  • En los sistemas con varias empresas, cada consulta va filtrada por empresa: lo de otra responde como si no existiera.
  • A la consola de Budger solo llegan eventos de seguridad limpios: la IP truncada, nunca un correo, nunca un documento.
  • Los respaldos de Budger se guardan en el almacenamiento del dueño de los datos, cifrados con su llave.

Cifrado

  • Todo el tráfico va por HTTPS; Budger revisa el certificado de cada sistema cada 6 horas.
  • Credenciales de integraciones y datos sensibles cifrados con AES-256-GCM en Aurix, Skiper y Asento.
  • Contraseñas guardadas con hash: nadie del equipo puede leerlas.

Accesos

  • Permisos por rol verificados en el servidor en cada petición, no solo en la pantalla.
  • Límite de intentos por cuenta y por IP en cada inicio de sesión.
  • Nada se cambia en producción sin una aprobación explícita: qué se cambia, cómo se deshace y un respaldo antes.

Respaldos

  • Copia diaria de las bases de producción; la misma práctica en todos los sistemas: por confirmar.
  • Restauración de prueba en cada copia con @budger/backup en todos los sistemas: por confirmar.
  • Antes de cada cambio en producción se toma un respaldo, y después se prueba que el sistema sigue funcionando.

Respuesta a incidentes

  • La consola de Budger abre un incidente en cuanto un sistema deja de responder y lo cierra cuando vuelve.
  • Cada evento lleva su categoría de la Taxonomía Única de Incidentes de la SFC, lista para reportar.
  • Tiempo de respuesta comprometido por escrito con cada cliente: por confirmar.

Desarrollo seguro

  • Todo cambio que toca dinero, permisos o datos de clientes pasa por una revisión dedicada.
  • budger scan revisa librerías, secretos en el código y en el historial, y la configuración en vivo.
  • Se compila fuera de los servidores de producción y se revisa el paquete antes de subirlo.

PRINCIPIOS

Las reglas que Budger no rompe.

  1. 01

    Nunca tumba tu app

    Si la licencia vence, la consola se cae o una regla falla, Budger pasa a observar. Nunca bloquea todo. Solo la autenticación falla cerrada, porque dejar entrar a cualquiera sería peor.

  2. 02

    Primero observa, después bloquea

    Toda instalación arranca en modo observar: ves lo que Budger habría frenado sin que frene nada. Pasar a bloquear es una decisión tuya, explícita.

  3. 03

    Tus datos se quedan contigo

    Los respaldos van a tu almacenamiento, cifrados con tus llaves. A la consola solo llegan eventos de seguridad ya limpios de datos personales.

  4. 04

    Cada control tiene nombre propio

    Cada protección tiene un identificador BGR y está mapeada a los marcos que te piden. Nada de «seguridad» en abstracto.

  5. 05

    Sin licencias que te amarren

    Los paquetes no llevan código GPL ni AGPL. Las herramientas externas con otras licencias se llaman como programas aparte.

  6. 06

    Hecho para lo que ya usas

    Node 20.19 o superior y Bun 1.2 o superior, con módulos ESM y CommonJS y tipos de TypeScript incluidos.

HABLA CON NOSOTROS

¿Tu equipo de compras pregunta por seguridad?

Te mandamos el detalle de cómo protegemos el sistema que usas.

Desde
Barranquilla, Colombia
Respuesta
En horario hábil de Colombia