Seguridad operativa en Verifactu: certificado y entornos

Respuesta rápida

En Verifactu, el certificado electrónico cualificado se utiliza para autenticar la comunicación con la AEAT. La FAQ oficial sobre firma explica que la remisión autenticada y segura cubre el tratamiento previsto para los registros, de modo que el SIF Verifactu no tiene que añadir una firma electrónica explícita del registro como sí ocurre en la modalidad no verificable. La seguridad real depende además de permisos, custodia, auditoría y separación de entornos; no basta con “subir un certificado”.

Esta pieza es un checklist operativo. La guía de custodia del certificado ya cubre cifrado, envolvente y rotación del PKCS#12.

El certificado no es la factura

Conviene separar:

Elemento	Para qué sirve
Certificado electrónico	Autenticar el canal de remisión ante la AEAT.
Registro de facturación	Datos estructurados de alta o anulación.
Huella	Control criptográfico de datos definidos del registro.
Firma de una factura PDF	Una decisión distinta, que no se deduce por usar Verifactu.

La remisión autenticada no autoriza a describir el certificado como “firma de cada PDF”. Tampoco evita que el sistema conserve registros, respuestas y evidencias operativas.

Cinco controles de acceso

1. Cuenta que puede cargar el certificado

Solo un rol explícito debe poder asociar, sustituir o eliminar credenciales de un obligado. El soporte no debería pedir el archivo o la contraseña por correo, chat o una incidencia sin autenticación.

2. Cuenta que puede emitir

Separar “configurar credencial” de “crear factura”. Una persona que gestiona una integración puede no necesitar ver el material secreto ni acceder a todas las series.

3. Cuenta que puede anular

La anulación y la rectificación cambian el historial fiscal. Exige autorización, motivo, relación con la factura original y registro de quién ejecutó la operación.

4. Cuenta que puede exportar

Exportar registros y respuestas debe quedar auditado y limitado. No exportes contraseñas, claves privadas ni tokens en un CSV de soporte.

5. Cuenta de emergencia

Documenta el procedimiento de recuperación, quién lo aprueba y cómo se revoca después. Una cuenta de emergencia permanente es una puerta trasera operativa.

Separación de sandbox y producción

El entorno de pruebas debe mantener separados:

• certificado y contraseña;
• API keys y secretos de webhook;
• series y numeración;
• tenants y NIF;
• endpoints y listas de permitidos;
• respuestas, logs y métricas;
• tareas de reintento y colas.

Una prueba que genera un registro con el certificado real no es un sandbox seguro. La guía de sandbox y pruebas existente explica el aislamiento de datos y credenciales con más detalle.

Auditoría que no filtra secretos

Un log operativo debe permitir responder “qué ocurrió” sin guardar el certificado. Registra, como mínimo:

• tenant y obligado;
• entorno;
• versión del SIF y del esquema;
• actor o servicio que inició la operación;
• factura, serie y evento externo;
• tipo de registro y estado;
• timestamp y duración;
• versión de clave o referencia de secreto, nunca su valor;
• código de error y correlación.

No registres el contenido completo de la clave privada, la contraseña, el payload sin minimizar o el token de autorización. Para depurar, usa un payload redactado y un identificador de correlación.

Validez y rotación

Antes de una remisión, el sistema debe comprobar que el certificado puede usarse en ese entorno y no está caducado, revocado o todavía no válido. La revisión de validez no debe escribir material secreto en un archivo temporal ni dejarlo en una traza.

La rotación tiene dos partes:

1. preparar y validar el nuevo certificado;
2. cambiar el secreto activo sin perder la trazabilidad de qué versión firmó o autenticó cada operación.

Si una rotación falla, no borres el único material útil antes de haber validado la nueva referencia. El artículo existente de custodia segura detalla la envolvente de cifrado y el borrado.

Incidencia de conectividad

Que la red falle no debe disparar una nueva factura automáticamente. Guarda la operación fiscal, limita los reintentos, verifica si la AEAT recibió el registro y reconcilia antes de repetir. La guía de estados y errores separa transporte, HTTP, resultado por registro y duplicado.

Un plan de continuidad debe indicar:

• quién puede pausar el envío;
• cómo se conserva la cola;
• cuándo se reintenta;
• cómo se detecta un duplicado;
• cómo se informa de un registro pendiente;
• qué evidencia se entrega al asesor.

Estado de VeriFactu Fácil

VeriFactu Fácil está en prelanzamiento. La web describe una custodia prevista y una separación de entornos, pero todavía no hay una consola pública que permita cargar certificados. No envíes credenciales al equipo por canales informales: espera al flujo autenticado cuando se abra el servicio.

Ver la declaración responsable y el papel del productor →