OCA
[18.0] l10n_es_aeat: Gestión de certificados
Desde 18.0, Odoo incluye un módulo llamado certificate, que permite almacenar y gestionar certificados criptográficos. Utiliza principios parecidos a los que tenemos en l10n.es.aeat.certificate, y las mismas librerías para extraer las claves, pero con una diferencia principal: la clave del certificado original se guarda con el propio modelo, en lugar de solicitarse en un wizard que luego termina borrándose.
¿Qué os parece realizar el cambio a la gestión de certificados estándar de Odoo? ¿Veis algún riesgo?
ping @AaronHForgeFlow @JordiBForgeFlow @etobella @ValentinVinagre @acysos @rubencr7 @fuentes73
A ver, esto es complicado. La verdad es que lo primero seria pensar si necesitamos seguir usando los certificados como ficheros y que ventaja nos da eso. Si alguien accede al servidor, al final lo tiene todo, con lo que tenerlo en como fichero no nos da más seguridad a no ser que tengamos la BBDD desacoplada del servidor de Odoo. Por lo tanto, yo creo que podemos usar el sistema de Odoo directamente ya que no hay una ventaja directa.
De todas formas, estaría bien ver otras opiniones, por que tal vez se me escapa algo de por que se hizo así en su día.
Haciendo una revisión en diagonal, veo luces y sombras: Luces:
- Nos ha pasado que ciertos clientes tienen "intranquilidad" en traspasar certificados electrónicos y contraseñas... así que sería una opción para que el propio usuario lo pueda gestionar y no necesite al implantador(hasta cierto punto).
- Si Odoo proporciona un sistema parecido o compatible, lo ideal es utilizarlo, menos que mantener.
Sombras:
- ¿Que dirección tomará Odoo con esto?
- ¿La exportación propia de Odoo puede dar información del certificado? ¿está protegido?
- Elimina la opción de poder tener el certificado externamente ¿sería posible realizar la ampliación? Si se hace... ¿vale la pena?
En conclusión no me parece mal ir por el camino de Odoo, pero haría una ampliación para poder optar también a la utilización del certificado como hasta ahora. ¿Como lo veis?
Odoo usa los certificados para el mismo propósito que se usa en la localización, por ejemplo en su módulo de facturae lo usa, así que sí creo que es un "feature" que está solapado con el módulo del l10n_es_aeat. Sin embargo el módulo certificate es bastante nuevo y creo que le van a hacer cambios puesto que a mi modo de ver presenta algunas vulnerabilidades:
- La contraseña para desencriptar el fichero .pfx o p12 se guarda directamente en la tabla certificate_certificate:
- El contenido del fichero .pem extraído se guarda directamente en la tabla del ir_attachment:
Creo que aunque son funcionalidades que se solapan esperaría a que Odoo las hiciera más estable. Podríamos hacer el esfuerzo de mejorar la seguridad ahora para que luego Odoo lo arregle en la siguiente versión.
Yo en el PR de migración ya he quitado el commit que hacía la migración al nuevo modelo.
Odoo usa los certificados para el mismo propósito que se usa en la localización, por ejemplo en su módulo de facturae lo usa, así que sí creo que es un "feature" que está solapado con el módulo del l10n_es_aeat. Sin embargo el módulo certificate es bastante nuevo y creo que le van a hacer cambios puesto que a mi modo de ver presenta algunas vulnerabilidades:
- La contraseña para desencriptar el fichero .pfx o p12 se guarda directamente en la tabla certificate_certificate:
- El contenido del fichero .pem extraído se guarda directamente en la tabla del ir_attachment:
Creo que aunque son funcionalidades que se solapan esperaría a que Odoo las hiciera más estable. Podríamos hacer el esfuerzo de mejorar la seguridad ahora para que luego Odoo lo arregle en la siguiente versión.
Yo en el PR de migración ya he quitado el commit que hacía la migración al nuevo modelo.
¿y si se valora para v19 a ver que cambios realizan? yo por el momento mantendría el de OCA como está.
Para mí lo ideal seria:
- Guardar el contenido fichero .p12 en una variable de entorno en el servidor
- Guardar el password asociado en un lugar seguro, que puede ser uno de los siguientes: a) Variable de entorno, también en el servidor b) En un servicio externo como Google KMS, AWS Secrets Manager, Hashicorp Vault... que limitan quién puede acceder a estas claves (por ejemplo, aplicando restricción por IP)
Por lo que entiendo ahora la arquitectura del modulo l10n_es_aeat guarda la clave privada en la base de datos, de modo que esa clave acaba estando en todos los backups de la base de datos y acaban replicandose en entornos de staging con facilidad.
Creo que estas dos ventajas que señalaba @ValentinVinagre son importantes:
- Nos ha pasado que ciertos clientes tienen "intranquilidad" en traspasar certificados electrónicos y contraseñas... así que sería una opción para que el propio usuario lo pueda gestionar y no necesite al implantador(hasta cierto punto).
- Si Odoo proporciona un sistema parecido o compatible, lo ideal es utilizarlo, menos que mantener.
Sobre el primer punto, pensad que para que un usuario mande la contraseña del certificado a su implantador, tiene que usar un canal adicional, que perfectamente puede ser un vector de ataque adicional.
Pero sin contar con ese, básicamente existen 3 vectores de ataque. Comparemos:
| Sistema antiguo de OCA | Sistema nuevo de Odoo | |
|---|---|---|
| Acceso elevado a Odoo | Vulnerable. | Vulnerable. |
| Acceso elevado a Postgres | Seguro, ya que no hay datos. | Seguro, salvo que también consigas acceso al filestore. |
| Acceso elevado al filestore | Vulnerable. | Seguro, salvo que también consigas acceso a Posgres. |
Así pues, antes estábamos poniendo toda la seguridad en el filestore. Ahora, una parte se almacena en Postgres y otra en el filestore. A mi modo de ver, estamos incrementando la seguridad puesto que un atacante necesitará vulnerar 2 accesos diferentes para desbloquear el certificado.
Por supuesto, un acceso elevado a Odoo es vulnerable en todos los sentidos y siempre lo será, por diseño, porque:
- Odoo necesita desbloquear la clave. Por tanto, de un modo u otro, necesita tener la contraseña.
- Un usuario con privilegios puede escribir una acción de servidor y hacer lo que quiera.
Más contexto a considerar:
- El almacenamiento en texto plano de contraseñas en Odoo ya se hace en otros sitios, como los servidores de correo entrante/saliente.
- OCA puede crear módulos que mejoren la seguridad de
certificatemediante almacenar la contraseña en otro backend, ya sea el filestore, vault, bitwarden, etc. Esa mejora sería transparente a lo que hagal10n_eso similares, ya que actuaría a otro nivel.
Por lo tanto, para mí lo mejor que podemos hacer es adoptar certificate.
@moduon MT-9954
Los que trabajaron en la migración de la localización los Spanish OCA Days no estaban convencidos del cambio, así que por el momento se ha dejado como estaba. Se puede evaluar en la siguiente versión, o en medio de ésta con scripts de migración, aunque implicaría un cambio de dependencias.