MDH GROUP · BLOG

Requisitos de producción on‑prem para Debentra: checklist de infraestructura, copias de seguridad y seguridad

Situación: Una factura está vencida, nadie ha dado seguimiento, los recordatorios se generan demasiado tarde y las respuestas se pierden en el caos general del correo electrónico. Para empresas medianas esto es algo habitual —y evitable.

← Todos los artículos

Requisitos de producción on‑prem para Debentra: checklist de infraestructura, copias de seguridad y seguridad

Cuando una factura se pierde en la bandeja: por qué infraestructura y seguridad van juntas

Descripción de la situación: Una factura está atrasada, nadie hizo seguimiento, los recordatorios se crean con retraso y las respuestas se pierden en el caos general del correo electrónico. Para las empresas medianas esto es cotidiano —y evitab le. Un flujo de trabajo on‑prem de partidas abiertas estructurado reduce el trabajo manual y preserva la soberanía de los datos. Para que ese tipo de flujo funcione de forma fiable en producción se necesita un dimensionamiento de hardware/VM coordinado, reglas claras de firewall, copias de seguridad fiables y pruebas de recuperación regulares.

Resumen: componentes clave de la checklist

  • Planificación de recursos: dimensionamiento de VM y hardware según la edición y el volumen de transacciones
  • Red y firewall: aperturas mínimas, segmentación y acceso de administrador
  • Estrategia de backup: intervalos, retención, copia fuera del sitio
  • Cifrado y gestión de claves
  • Pruebas de recuperación y monitorización

Por qué esto encaja con Debentra

Debentra se ejecuta como solución auto‑alojada en infraestructura propia. Según la edición (BASIS, PRO, PREMIUM) cambia la necesidad de recursos: PRO automatiza partes de la asignación y los trabajos en segundo plano, PREMIUM integra funciones contables adicionales. La siguiente lista de verificación ayuda a proporcionar la infraestructura adecuada sin renunciar al control de la automatización: las plantillas de recordatorio y el envío siempre pueden quedar sujetos a la aprobación del usuario.

1. Hardware / dimensionamiento de VM (práctico por edición)

Las recomendaciones sirven como punto de partida para configuraciones típicas de empresas medianas. Ajuste los valores según sus volúmenes diarios de facturas/clientes.

BASIS (configuración pequeña, bajo rendimiento)

  • VM única o servidor pequeño: 2 vCPU, 4 GB RAM
  • Almacenamiento: 50–100 GB SSD (preferible NVMe), RAID1 para redundancia
  • BD: puede estar local en la misma VM; para seguridad de rendimiento se recomienda más adelante una VM de BD separada
  • Objetivos RTO/RPO (recomendación): RTO ~24 h, RPO ~24 h

PRO (configuración media, trabajos en segundo plano y automatización)

  • App‑VM: 4 vCPU, 8 GB RAM
  • VM de BD: 2–4 vCPU, 8 GB RAM; pool de almacenamiento separado (200 GB SSD)
  • Almacenamiento: NVMe para la BD (el IOPS es importante), RAID10 para rendimiento + redundancia
  • Nodos worker: se recomienda un worker adicional pequeño (2 vCPU, 4 GB RAM) para tareas en segundo plano
  • Objetivos RTO/RPO: RTO ~8 h, RPO ~1 h

PREMIUM (configuraciones más grandes, contabilidad integrada, mayor disponibilidad)

  • VMs de aplicación (compatibles con clúster): 2× 4–8 vCPU, 16 GB RAM (balanceadas)
  • Clúster de BD: 2–3 nodos con 4 vCPU cada uno, 8–16 GB RAM; almacenamiento NVMe dedicado (500 GB+)
  • Servidor de copias/archivo: VM separada o NAS con alta capacidad y cifrado
  • Objetivos RTO/RPO: RTO ~4 h, RPO ≤15–30 min (WAL‑Shipping / replicación continua)

2. Red y reglas de firewall

Principio mínimo: solo puertos necesarios abiertos, segmentar servicios (DMZ, red de aplicaciones, red de bases de datos), restringir accesos de administración a IPs de confianza.

Reglas recomendadas

  • Puerto 443/tcp (HTTPS): Allow desde Internet hacia Load‑Balancer / Reverse‑Proxy
  • Puerto 80/tcp: Allow desde Internet solo para redirección a 443
  • SSH (22/tcp): Allow solo desde IPs de administradores o VPN (sin apertura general)
  • Puertos de BD (p. ej. 5432/tcp para PostgreSQL): Allow solo desde la red de aplicaciones / VMs de aplicación específicas
  • Transferencia de backup: restringir a conexiones basadas en TLS/SSH (rsync/ssh o SFTP) y servidores de backup autorizados
  • Comunicación interna: microsegmentación entre App y Worker/BD; utilice firewall stateful o Security Groups

Otras indicaciones

Establezca un VLAN de gestión para accesos de administración y monitorización. Desactive servicios innecesarios en servidores de producción y realice escaneos de puertos periódicos.

3. Estrategia de copias de seguridad e intervalos

Las copias de seguridad no son solo archivos — son un proceso. Defina calendarios, pruebas y responsabilidades.

BÁSICO

  • Copia completa: diaria (por la noche)
  • Snapshots incrementales: diarios o cada hora según la carga
  • Retención: 14–30 días
  • Copia offsite: al menos semanal (cifrada)

PRO

  • Copia completa: diaria
  • Incrementos: horarios para BD, snapshots diarios para la aplicación
  • Copia transaccional: WAL‑Backup o similar para recuperación hasta minutos
  • Retención: 30 días + snapshots offsite semanales

PREMIUM

  • Replicación continua (WAL‑Shipping / Streaming Replication)
  • Copias completas diarias + copias diferenciales horarias
  • Retención: 90 días para copias regulares, archivo a largo plazo según necesidad
  • Copias offsite y cifradas: transferencia diaria a ubicación externa

4. Cifrado y gestión de claves

El cifrado debe abordarse de extremo a extremo: en tránsito, en reposo y en las copias de seguridad.

  • TLS: HTTPS con TLS 1.2+ (mejor TLS 1.3), activar HSTS, renovar certificados automáticamente (p. ej. ACME/LetsEncrypt o PKI interna)
  • En reposo: Full‑Disk‑Encryption (LUKS) a nivel de VM o volúmenes LVM cifrados; almacenamiento de BD además sobre almacenamiento cifrado
  • Backups: cifrar con AES‑256; gestionar las claves separadas de las copias de seguridad
  • Gestión de claves: Utilizar un KMS central (p. ej. HashiCorp Vault o KMS corporativo). Evitar claves en claro almacenadas localmente.

5. Pruebas de recuperación, monitorización y operación

Las copias de seguridad que nunca se prueban no valen nada. La monitorización detecta problemas antes de que los procesos de aviso se paralicen.

Pruebas de recuperación

  • BÁSICO: Prueba de restauración completa trimestral (documentar el procedimiento)
  • PRO: Ejercicio de restauración mensual para BD + restauración de aplicaciones por muestreo
  • PREMIUM: Pruebas de restauración semanales en staging, simulación de carga y failover

Monitorización y alertas

  • Supervisar: estado del servicio, latencia de BD, I/O de disco, trabajos de backup, lag de replicación
  • Alertas: errores de backup notificar inmediatamente a los responsables; avisos por uso de disco ≥75%
  • Registros de auditoría: registrar accesos y aprobaciones de recordatorios (para transparencia en el proceso de seguimiento)

Ejemplo práctico: así funciona un entorno de producción

Una empresa mediana despliega Debentra PRO. La arquitectura: Load‑Balancer → VM de aplicación (4 vCPU/8 GB) → VM de BD (2 vCPU/8 GB) → servidor de backup (copias cifradas offsite). El firewall permite 443, 22 solo desde el Admin‑VPN, 5432 solo desde la red de aplicaciones. Backup completo nocturno, incrementos de BD cada hora, prueba de recuperación mensual. Las plantillas de recordatorio se preparan automáticamente; los usuarios deciden sobre la aprobación y el envío —así el equipo mantiene el control.

Consejos de implementación y errores frecuentes

  • Error: exponer el puerto de BD públicamente. Consecuencia: riesgo de ataque innecesario. Solución: permitir solo comunicación interna.
  • Error: backups locales sin copia offsite. Solución: planificar copia offsite cifrada diaria.
  • Error: no realizar pruebas de recuperación. Solución: ejercicios de restauración regulares y documentados con responsables definidos.
  • Error: automatización sin proceso de aprobación. Solución: introducir borradores automáticos + aprobación manual de los recordatorios.

Conclusión y próximos pasos

Un funcionamiento estable y seguro de Debentra on‑prem requiere infraestructura planificable, aperturas de red limitadas, una estrategia de copias de seguridad bien pensada y pruebas de recuperación periódicas. Elija la edición adecuada según su volumen y sus requisitos de disponibilidad: BASIS para implementaciones sencillas, PRO cuando la automatización y el procesamiento en segundo plano son importantes, PREMIUM para mayor disponibilidad y funciones contables integradas. En todos los casos, el control sobre las autorizaciones de recordatorios permanece en el usuario.

Actúe ahora: Revise su arquitectura actual con esta lista de verificación y elija la edición adecuada. Elegir edición

Siguiente paso

Probar Debentra

Vista central y control de procesos para partidas pendientes y pagos con plena soberanía de datos; reduce el trabajo manual de conciliación (PRO) y permite contabilidad integrada (PREMIUM); modelos de instalación y licencias seleccionables.

Elegir edición