La seguridad del software empresarial no puede limitarse a las aplicaciones consideradas estratégicas. En 2026, un servicio de pedido de comidas de la AP-HP expuso los datos de identidad de 1 015 pacientes. La lección es clara: una aplicación periférica puede crear un riesgo importante en cuanto trata datos personales, se comunica con otros sistemas o permanece accesible en línea.
¿Qué ocurrió con el software de comidas de la AP-HP?
La AP-HP supo el 24 de septiembre de 2026 que se ofrecían datos procedentes de su software de gestión de comidas en un forum cibercriminal. El 7 de octubre de 2026, el centro confirmó la publicación de datos de identidad relativos a 1 015 pacientes, al tiempo que precisó que la investigación continuaba.
El servicio afectado permitía a los pacientes seleccionar sus comidas durante una hospitalización. Pertenecía a SRD Restauration, una suite de Dedalus utilizada por 23 hospitales de la AP-HP para gestionar la nutrición, la producción y la distribución de comidas.
Según el comunicado de la AP-HP del 7 de octubre de 2026, los elementos alors publicados incluían el apellido, el nombre, información sobre el nacimiento y un identificador interno del paciente. En esa fecha no parecía que estuvieran afectados datos médicos, administrativos, bancarios o de contacto, a reserva de los resultados de la investigación.
En el forum se difundieron afirmaciones que aludían a un mayor número de pacientes y a determinadas cuentas profesionales. La AP-HP indicó el 7 de octubre de 2026 que no había verificado esas alegaciones. A falta de un informe técnico público o de una declaración detallada de Dedalus sobre este incidente a 10 de octubre de 2026, atribuir la intrusión a una vulnerabilidad concreta o a un actor sería prematuro.
La AP-HP desactivó el módulo en línea, restableció las contraseñas y declaró haber corregido las vulnerabilidades sospechadas. El centro también había presentado una denuncia el 25 de septiembre de 2026 y posteriormente notificó el incidente a la Comisión Nacional de Informática y Libertades y a la unidad de asistencia cibernética del sector sanitario.
¿Por qué una aplicación periférica puede exponer a la empresa?
A aplicación de negocio el dispositivo sigue siendo sensible porque contiene credenciales, intercambia datos mediante API o permite el acceso desde Internet. Por tanto, la seguridad del software empresarial depende de los datos y las conexiones reales, no de la etiqueta «secundario» atribuida al servicio en la organización.
Un software empresarial es una aplicación diseñada para ejecutar un proceso propio de una organización: pedidos, existencias, mantenimiento, recursos humanos, producción o restauración. No necesita contener una historia clínica completa ni los cordatos bancarios de un cliente para permitir una suplantación de identidad, una focalización fraudulenta o un salto hacia otros sistemas.
La trampa más frecuente es organizativa. En ocasiones, una aplicación modesta escapa a las auditorías reservadas al sitio principal, al ERP o al software de gestión de relaciones con clientes. Sin embargo, conserva cuentas antiguas, secretos de API, interfaces de administración y dependencias técnicas que envejecen.
En los proyectos que llevamos a cabo, a menudo observamos una diferencia entre el alcance descrito en el pliego de condiciones y los intercambios de datos que se han añadido realmente a lo largo de los años. Una especificación precisa de la aplicación empresarial debe, por tanto, inventorriar los flujos, los usuarios, los subcontratistas y los periodos de conservación, no solo las pantallas previstas.
¿Qué controles protegen realmente un software empresarial?
La seguridad de un software empresarial se basa, ante todo, en diez controles: cartografiar los datos, reducir su recopilación, individualizar las cuentas, limitar los derechos, verificar los accesos, proteger las API, registrar las operaciones, evaluar los riesgos, aislar la aplicación y preparar la respuesta a incidentes. Ninguna herramienta única sustituye a este conjunto.
La Comisión Nacional de Informática y Libertades recomienda, en su guía de seguridad de 2024, inventorriar los tratamientos, asignar cuentas individuales y aplicar el principio de mínimo privilegio. El mínimo privilegio consiste en conceder a cada persona o programa únicamente los derechos necesarios para su misión.
Según la guía de 2024 de la CNIL, debe realizarse una revisión de las autorizaciones al menos una vez al año. En el caso de una aplicación expuesta, una elevada rotación de personal o datos sensibles suelen justificar una frecuencia menor. Un control anual no debe convertirse en el plazo de espera para eliminar la cuenta de un empleado que ya se ha marchado.
Esta es la lista de comprobación que debe integrarse en el diseño, el mantenimiento y las auditorías:
- cartografiar los datos, los servidores, los proveedores y las dependencias;
- eliminar los campos recopilados sin una finalidad demostrable;
- utilizar cuentas individuales y retirar los derechos innecesarios;
- controlar las cuentas doromésticas, compartidas y técnicas;
- activar la autenticación multifactor corando el riesgo lo justifique;
- examinar las API y proteger sus claves, tokens y contraseñas;
- registrar los accesos y vigilar los comportamientos anormalos;
- realizar pruebas de seguridad prorporcionales a los riesgos;
- aislar la aplicación para limitar los desplazamientos de un atacante;
- documentar la gestión, la notificación y la comunicación de los incidentes.
La autenticación multifactor, o MFA, exige al menos dos pruebas distintas para iniciar sesión, por ejemplo, una contraseña y una validación en un dispositivo. Las recomendaciones de la CNIL de 2024-2025 la consideran necesaria, en principio, para las bases de datos sensibles o susceptibles de tener un impacto elevado.
Sinceramente, añadir la MFA a la interfaz visible mientras se deja una API antigua protegida por un secreto compartido crea sobre todo una falsa sensación de seguridad. Las interfaces técnicas deben incluirse en la auditoría, al igual que las cuentas de servicio utilizadas automáticamente por los programas.
¿Cómo priorrizar la seguridad del software empresarial?
La seguridad del software empresarial debe priorrizarse según la exposición a Internet, la sensibilidad de los datos, el número de usuarios y las conexiones con el sistema de información. Una aplicación periférica accesible en línea y conectada a un repositorio de identidades merece más controles que una herramienta aislada sin datos personales.
| Situación | Riesgo principal | Controles priorritarios | Decisión recomendada |
|---|---|---|---|
| Aplicación accesible desde Internet | Acceso no autorizado | MFA, pruebas de seguridad, registros supervisados | Tratar antes de ponerla en producción |
| API conectada a varios sistemas | Propagación y extracción de datos | Secretos protegidos, derechos mínimos, aislamiento | Cartografiar cada flujo |
| Cuentas compartidas o doromésticas | Acción imposible de atribuir | Cuentas individuales, eliminación y revisión de derechos | Corregir sin esperar a la auditoría anual |
| Datos personales sensibles o con un imporcto elevado | Perjuicio para las personas | MFA, cifrado adecuado, registro protegido | Realizar un análisis de riesgos |
| Aplicación antigua y aislada | Componentes obsoletos | Correctifs, inventario de versiones, segmentación | Decidir entre mantener, rediseñar o retirar |
La compartimentación consiste en separar las redes o los sistemas para que una intrusión no dé acceso a todo el sistema de información. Las guías de la Agence nationale de la sécurité des systèmes d’information publicadas desde 2017 y las recomendaciones de la CNIL respaldan este principio para limitar los desplazamientos laterales de un atacante.
El mantenimiento cuenta tanto como el diseño. Una política de gestión automatizada de los correctifs sin interrumpir la producción reduce el tiempo de exposición, siempre que se prevean un entorno de pruebas y una reversión. Con un presupuesto limitado, es preferible corrigir primero los accesos externos, las cuentas excesivas y los componentes expuestos que financiar un cuadro de morndo sofisticado y poco supervisado.
Desde la agencia, la reacción habitual es solicitar pruebas del funcionamiento de cada control: extracto anonimizado de una revisión de derechos, alerta procedente de los registros, restauración probada o cuenta efectivamente bloqueada. Una política escrita no protege nada si nadie verifica su aplicación.
¿Qué hacer después de una filtración de datos de una aplicación empresarial?
Tras una filtración originada en una aplicación empresarial, la empresa debe contener el acceso, preservar los registros, evaluar los datos afectados y documentar el incidente. Una violación que presente un riesgo debe notificarse a la CNIL lo antes posible y, cuando sea factible, en un plazo de 72 horas en virtud del RGPD.
Todas las violaciones de datos deben registrarse, incluso lorsque no se requiera ninguna notificación externa. Lorsque el riesgo para las personas sea elevado, el Reglamento General de Protección de Datos también obliga a informarles rápidamente, con explicaciones comprensibles.
¿Desconectar inmediatamente todo el sistema es siempre la decisión correcta? No necesariamente. La desactivación puede limitar la exposición, pero también puede borrar elementos volátiles o interrumpir un servicio esencial. En la decisión deben participar los responsables del negocio, el equipo técnico, el delegado de protección de datos y las personas encargadas de la seguridad.
Los registros, es decir, el histororial de accesos y acciones, deben protegerse contra modificaciones y conservarse en función del nivel de riesgo. Sirven para determinar qué cuentas se han utilizado, qué datos se han consultado y durante cuánto tiempo pudo prolongarse la exposición.
A procedimiento de respuesta a incidentes adaptado a las pymes evita improvisar las responsabilidades bajo presión. Debe especificar los contactos, los criterios de gravedad, las modalidades de conservación de las pruebas, las decisiones de desconexión y el circuito de notificación.
Definir la seguridad del software empresarial antes del desarrollo o la reanudación de una aplicación evita gran parte de los puntos débiles. Una perspectiva externa puede ayudar sobre todo a relacionar los requisitos del negocio, los flujos técnicos y las obligaciones del RGPD sin multiplicar los controles innecesarios.
Preguntas frecuentes sobre la protección de las aplicaciones empresariales
¿Es sensible una aplicación sin datos bancarios?
Una aplicación sin datos bancarios puede seguir siendo sensible si contiene identidades, hábitos, datos de salud o accesos a otros sistemas. El riesgo depende de las consecuencias para las personas y la empresa, no de una sola categororie de datos.
¿Con qué frecuencia deben revisarse los permisos de los usuarios?
La CNIL recomienda en 2024 revisar las autorizaciones al menos una vez al año. No obstante, los derechos deben revocarse en cuanto se produzca una baja o un cambio de funciones, y una aplicación de riesgo puede justificar controles más frecuentes.
¿Es suficiente la autenticación de dos factores para proteger una aplicación?
La autenticación multifactor reduce el riesgo asociado al robo de una contraseña, pero no corrige ni una API vulnerable, ni unos permisos excesivos, ni un componente obsoleto. La seguridad exige varias barreras complementarias.
¿Es necesario realizar una prueba de intrusión antes de cada puesta en producción?
Una prueba de intrusión debe decidirse en función de los riesgos, la exposición y el alcance de los cambios. Una aplicación accesible desde Internet, que trate datos de alto impacto o modifique su autenticación, justifica una verificación exhaustiva antes de su puesta en producción.