Casi todas las conversaciones sobre seguridad giran en torno a redes y antivirus, pero lo que busca un atacante suele estar dentro de una aplicación: la facturación en Sage 200 o a3ERP, el CRM con todos los clientes, la tienda en PrestaShop con pedidos y direcciones, el portal donde los pacientes descargan sus informes. Y dentro de esas aplicaciones las puertas suelen estar abiertas de forma muy banal: todos los usuarios con perfil de administrador «porque así no piden permisos», la integración con la tienda funcionando con la cuenta del gerente, una clave del TPV virtual de Redsys escrita en un fichero de configuración que está en un repositorio compartido con la agencia. Revisamos las aplicaciones de negocio desde dentro: quién puede hacer qué, con qué credenciales hablan entre ellas y qué se comprueba antes de publicar una versión nueva.
Trabajamos tanto con aplicaciones de mercado (ERP, CRM, tiendas online, software de gestión de clínicas) como con desarrollos propios. En los desarrollos propios, coordinamos con su equipo o con la agencia que los mantiene.
Revisamos los permisos dentro del ERP, del CRM o de Holded: quién puede modificar precios, anular facturas, exportar la base de clientes o cambiar el IBAN de un proveedor. Los perfiles se definen por puesto y se asignan desde el directorio cuando la aplicación lo permite.
Cada conexión automática, como la tienda con el ERP, el ERP con el banco o el CRM con la herramienta de correo masivo, tiene su propia cuenta de servicio con los permisos justos, y no la del gerente ni la de la persona que la configuró.
Sacamos claves de API, contraseñas de bases de datos y credenciales del TPV virtual de ficheros de configuración y repositorios, y las llevamos a un gestor de secretos como Azure Key Vault o al almacén de la propia plataforma, con rotación periódica.
Doble factor y, cuando es posible, inicio de sesión único con Entra ID o Google para el back office de PrestaShop, el CRM y los paneles de proveedores. Una contraseña menos que se pueda filtrar.
Inventario de librerías, plugins y módulos de terceros, con alertas sobre versiones vulnerables. En PrestaShop y WooCommerce, los módulos abandonados son una de las vías de entrada más frecuentes.
Que quede constancia de quién cambió un precio, anuló un pedido o modificó los datos bancarios de un proveedor. Es la base para detectar un fraude interno o el clásico engaño del cambio de cuenta bancaria.
No detenemos el desarrollo ni la operación. Los cambios en roles y credenciales se hacen por bloques y con la persona que usa cada aplicación a mano.
Lista de aplicaciones de negocio, sus usuarios, sus integraciones y dónde están guardadas las credenciales. Suele aparecer alguna integración que nadie recordaba.
Primero las cuentas de integración con demasiados permisos y las claves expuestas: se crean cuentas nuevas, se rotan las claves y se retiran las antiguas.
Rediseño de perfiles con cada responsable de área y aplicación progresiva, empezando por finanzas y administración.
Si hay desarrollo propio, incorporamos al proceso de publicación la revisión de dependencias y de secretos, junto con su equipo o su agencia.
Uno de los fraudes más habituales en pymes no necesita malware: basta con cambiar un IBAN. Si cualquier usuario del ERP puede modificar los datos bancarios de un proveedor sin que nadie lo apruebe ni quede registro, el próximo pago puede acabar en otra cuenta. Separar quién cambia los datos y quién los aprueba cuesta una tarde de configuración.
Sí, en coordinación con él. Definimos con usted qué debe poder hacer cada puesto, y el distribuidor o Apply lo aplica según quién conozca mejor su versión. Lo importante es que la decisión sobre permisos sea de su empresa y quede por escrito.
No. Aquí revisamos configuración, permisos y credenciales desde dentro, con acceso completo. Una prueba de penetración ataca la aplicación desde fuera para encontrar fallos explotables; forma parte de nuestro servicio de pruebas de penetración y tiene sentido antes de publicar una aplicación nueva o tras un cambio grande.
En parte, sí. El reglamento de Verifactu exige garantizar la integridad, la trazabilidad y la inalterabilidad de los registros de facturación, lo que implica controlar quién puede modificarlos y dejar huella de cada cambio. Revisamos esos controles técnicos; la adaptación funcional del programa corresponde a su equipo de desarrollo o a su proveedor.
Que tengan cuentas nominativas, con doble factor y con los permisos que necesitan para su trabajo, no los de superadministrador. Y que se desactiven cuando termine el encargo. Es uno de los hallazgos más habituales: accesos de agencias que dejaron de trabajar con la tienda hace años.
Cuéntenos qué ERP, CRM o tienda online usa y cómo se conectan entre sí. Le respondemos con las comprobaciones que haríamos primero.
Hemos recibido su solicitud
Tendrá respuesta en un día laborable. Si nos avisa de una avería que tiene parado a su equipo, la tratamos con prioridad.
No encontramos esa ciudad. Revise cómo está escrita o elija la capital de provincia más cercana: como trabajamos en remoto, el servicio es el mismo en cualquier punto de España.
