Conexiones HTTPS
El sitio público y la aplicación se sirven mediante TLS. Las solicitudes HTTP se redirigen a la versión segura del dominio y la aplicación usa encabezados de seguridad.
Seguridad por capas
Seguridad y protección de la información
SD Invoice combina controles de red, aplicación, base de datos, almacenamiento y operación para reducir el acceso indebido y recuperar el servicio de forma ordenada.
Prevención y detección
Controles aplicados en distintas capas
Ningún control aislado elimina el riesgo. Por eso se combinan límites técnicos, separación de datos y procedimientos operativos sin afirmar certificaciones que el servicio no posee.
Separación por empresa
Las operaciones se ejecutan dentro del contexto de la empresa y aplican aislamiento también en la capa de base de datos para reducir accesos cruzados.
Credenciales fiscales cifradas
El certificado criptográfico y su contraseña se cifran antes de almacenarse y solo se descifran dentro del flujo autorizado de firma.
Documentos con acceso controlado
Los archivos fiscales se conservan fuera del acceso directo al almacenamiento. La sesión, una llave de API o el flujo público de verificación determinan qué documento puede entregarse.
Roles y permisos
Propietarios, administradores, miembros y roles especializados reciben capacidades según la acción y el módulo. Las llaves de API separan alcances de lectura y escritura.
Límites y trazabilidad
Los accesos sensibles aplican límites de solicitudes. Las operaciones críticas mantienen registros útiles para revisión operativa y diagnóstico.
Respaldos y recuperación
Copias cifradas que se verifican y pueden restaurarse
La base de datos se respalda de forma programada en un archivo cifrado con AES-256 y derivación PBKDF2. El proceso comprueba el dump antes de cifrarlo y vuelve a descifrarlo en flujo para validar la integridad del resultado. La retención local predeterminada es de 30 días.
El procedimiento de recuperación exige un archivo explícito, valida su integridad y requiere confirmación antes de restaurar. Los ensayos se realizan contra un destino aislado; una restauración sobre producción necesita una autorización adicional y revisión previa.
Respuesta a incidentes
Contener, recuperar y aprender
El runbook interno asigna responsables, preserva evidencia y evita improvisar cambios destructivos durante un evento.
1. Identificación
Registrar el momento, alcance aparente, sistemas afectados y fuente de la alerta; clasificar la severidad sin borrar evidencia.
2. Contención
Revocar sesiones o llaves expuestas, aislar el componente afectado y preservar logs, copias y una cronología de decisiones.
3. Erradicación y recuperación
Corregir la causa, rotar secretos cuando corresponda, restaurar desde una copia verificada y validar funciones críticas antes de reabrir.
4. Comunicación y seguimiento
Informar a las partes afectadas y autoridades cuando sea aplicable, documentar impacto y acciones, y convertir hallazgos en mejoras verificables.
Retención y eliminación
Los datos operativos se conservan mientras la cuenta esté activa y por los períodos contractuales o legales aplicables. Al dejar de ser necesarios, se eliminan o anonimizan cuando la normativa y las obligaciones de conservación lo permiten. Los respaldos salen por su ciclo de retención separado.
Leer la política de privacidad →Responsabilidad compartida
Cada empresa debe usar contraseñas únicas, asignar solo los permisos necesarios, retirar accesos que ya no correspondan, proteger sus llaves de API y verificar la información tributaria antes de emitir.
Para reportar un posible incidente, incluí una descripción, fecha, URL o módulo y pasos de reproducción, pero nunca contraseñas, certificados o llaves.
Reportá una situación de seguridad
El correo con asunto específico ayuda a clasificar el reporte. Si involucra datos personales, indicalo sin adjuntar información sensible innecesaria.
Escribir a info@structadefense.com