Política de Seguridad de la Información

1. Alcance y responsable

Esta política define cómo Spedis Consulting SRL protege la confidencialidad, la integridad, la autenticidad y la disponibilidad de la información que trata INDESY eFact. Aplica al servicio de emisión, a los servicios de recepción y aprobación comercial, a la base de datos, al almacenamiento de los documentos fiscales, al código fuente y a los proveedores que intervienen en su operación.

El Gerente General de Spedis Consulting SRL es el responsable de la seguridad de la información de INDESY eFact. La política se revisa al menos una vez al año y cada vez que cambian la infraestructura o la normativa de facturación electrónica, o que un incidente lo aconseja.

2. Principios

• Mínimo privilegio: cada persona, proceso y credencial tiene solo el acceso que necesita.
• Aislamiento entre clientes: la información de un contribuyente nunca es visible para otro.
• Integridad del documento fiscal: un e-CF firmado, un acuse o una representación impresa no se modifican ni se borran.
• Trazabilidad: toda operación sensible deja constancia de quién la hizo, cuándo y por qué.
• Defensa en profundidad: ningún control depende de uno solo.

3. Acceso y aislamiento

• Cada sistema que se integra con INDESY eFact usa una llave de acceso propia, con un rol que limita lo que puede hacer. Las llaves se guardan solo como una huella criptográfica, se muestran una sola vez al crearlas y pueden revocarse en cualquier momento.
• La base de datos aplica seguridad a nivel de fila en modo forzado: cada consulta queda limitada a la cuenta que la origina. Las pruebas automáticas verifican ese aislamiento en cada cambio del software.
• Las pocas operaciones administrativas que necesitan ver más de una cuenta exigen nombrar a la persona y el motivo, y quedan registradas antes de ejecutarse.
• El acceso administrativo a la infraestructura está restringido al responsable del servicio y se hace solo con llave criptográfica, sin contraseñas. La base de datos no está expuesta a Internet.

4. Custodia de los certificados digitales

• El certificado digital de cada emisor y su contraseña se guardan con cifrado de sobre: AES-256-GCM con una llave de datos única, protegida a su vez por una llave maestra que vive en un servicio de gestión de llaves y nunca sale de él.
• Lo cifrado para un emisor no puede descifrarse como si fuera de otro.
• El certificado solo se descifra en memoria, en el momento de firmar. Ni el certificado ni su contraseña aparecen en registros, respuestas o mensajes de error.

5. Comunicaciones y firma

• Todos los servicios se publican solo por HTTPS, con certificados que se renuevan automáticamente.
• Los e-CF, los acuses y las aprobaciones comerciales se firman con XMLDSig (RSA-SHA256) con el certificado del propio emisor, según la Descripción Técnica de la DGII.
• Los documentos que llegan de otros emisores se aceptan solo si su firma es válida, y las sesiones de los servicios de recepción se autentican con semilla firmada y token con vencimiento, como establece la DGII.

6. Integridad y conservación de los documentos fiscales

• Cada XML y PDF fiscal se guarda junto con su huella SHA-256, y la base de datos impide modificarlo o borrarlo.
• Cada documento fiscal se copia además a un almacenamiento independiente del servidor, bajo un bloqueo de retención de 10 años: nadie, ni siquiera el administrador, puede sobrescribirla ni borrarla durante ese plazo.
• Al exportar documentos para la DGII, cada archivo se verifica contra su huella y contra su copia resguardada.

7. Infraestructura

• El servicio corre en un servidor dedicado en los Estados Unidos, protegido por dos cortafuegos: desde Internet solo acepta conexiones HTTPS.
• Las actualizaciones de seguridad del sistema operativo se aplican automáticamente.
• Los componentes corren en contenedores aislados, y las credenciales se inyectan solo al ejecutarse, nunca dentro del código.

8. Desarrollo seguro y cambios

• El código fuente vive en un repositorio privado. Todo cambio entra por una revisión y solo se integra si pasan las verificaciones automáticas obligatorias, entre ellas las pruebas de aislamiento entre cuentas.
• El contrato del API está versionado: un cambio que rompa la compatibilidad con los sistemas integrados no se publica en la misma versión.
• El despliegue a producción lo autoriza el Gerente General, solo con todas las verificaciones aprobadas.

9. Trazabilidad y monitoreo

• Las operaciones sensibles quedan en una auditoría que la base de datos no permite modificar ni borrar, con el actor, la fecha y hora, el objeto y el motivo.
• Cada evento de cada comprobante y cada intercambio con la DGII se registran también de forma inmutable.
• Los registros de la aplicación redactan los secretos y los datos sensibles antes de escribirse.
• Monitores externos comprueban continuamente la disponibilidad del servicio, y los errores se notifican al responsable en tiempo real.

10. Incidentes de seguridad

1. Detección y registro de todo incidente, con su hora de inicio.
2. Contención: revocar llaves o credenciales comprometidas y bloquear el acceso afectado.
3. Evaluación del alcance, a partir de la auditoría y la bitácora.
4. Comunicación a los contribuyentes afectados y, cuando el incidente afecte la emisión o la información fiscal, a la DGII.
5. Recuperación según la política de contingencia.
6. Cierre con la causa, la corrección permanente y su prueba automática.

Si detecta un problema de seguridad en INDESY eFact, escríbanos a soporte@indesyefact.com.

11. Proveedores de infraestructura

El tratamiento de los datos personales se explica en la Política de Protección de Datos Personales.