Seguridad #

EthicsPortal gestiona datos sensibles de informantes. Esta página documenta las medidas técnicas y organizativas específicas que tenemos implantadas. Está dirigida a responsables de cumplimiento, delegados de protección de datos y equipos jurídicos que evalúan la plataforma.

Última actualización: 2026-08-28.

Cifrado de los datos #

Todos los campos sensibles se cifran en reposo mediante Rails ActiveRecord Encryption con cifrado no determinista (cada cifrado produce un texto cifrado único, lo que impide el análisis de patrones).

El cifrado no determinista significa que estos campos no pueden consultarse por valor a nivel de base de datos. Incluso con acceso total a la base de datos, un atacante no puede buscar un nombre concreto de informante entre los registros.

Todas las conexiones a EthicsPortal usan HTTPS/TLS. Las solicitudes HTTP sin cifrar se redirigen.

Anonimato y privacidad #

Direcciones IP #

EthicsPortal no registra la dirección IP de un informante con las comunicaciones, los mensajes ni los registros de auditoría, y los registros de la aplicación del canal de denuncia no contienen direcciones IP.

La limitación de tasa en el canal de denuncia (presentación de comunicaciones, consulta de casos, mensajería) se basa en un hash SHA-256 con clave y truncado de la IP de la solicitud. El hash es seudónimo, no anónimo: no puede leerse como una dirección, pero cualquiera que disponga del secreto de la aplicación podría comprobar direcciones candidatas contra él. Se usa solo durante la ventana de limitación (10 minutos como máximo) y se guarda en una caché de tamaño limitado.

El proxy TLS situado delante de la aplicación mantiene sus propios registros de conexión, que incluyen direcciones IP. No están vinculados a las comunicaciones. Se guardan en un único archivo de registro de 10 MB que se sobrescribe continuamente, actualmente en pocas horas; las instantáneas del servidor de 7 días descritas en copias de seguridad pueden contener una copia.

Eliminación de metadatos de los archivos #

Los archivos subidos se depuran automáticamente de metadatos identificativos antes de su almacenamiento:

La eliminación de metadatos se realiza en el lado del servidor antes del almacenamiento. Para los tipos de archivo gestionados por exiftool, depende de que esté presente la herramienta de producción estándar.

Análisis antivirus #

Todos los archivos subidos se analizan automáticamente en busca de malware mediante ClamAV , un motor antivirus de código abierto. El análisis se realiza en el lado del servidor en un proceso en segundo plano tras la subida. Los archivos que no han superado el análisis quedan bloqueados para su entrega, y los archivos infectados se eliminan automáticamente.

Los archivos se analizan en la infraestructura de EthicsPortal: no se envían datos de archivos a servicios de análisis de terceros.

Anonimato del gestor #

Los informantes nunca ven los nombres reales ni las direcciones de correo de las personas que gestionan su comunicación. Todos los mensajes de los gestores se muestran como «Gestor del caso». Esto protege la identidad del gestor y previene la ingeniería social.

Sin seguimiento #

EthicsPortal no usa cookies de seguimiento de terceros, píxeles publicitarios ni scripts de huella digital. Usamos Cloudflare Web Analytics solo en las páginas de presentación. No instala cookies analíticas, pero Cloudflare puede tratar metadatos de solicitud, incluidas direcciones IP, como se describe en el Aviso de privacidad . El canal de denuncia no tiene analítica.

Estado actual de las garantías #

EthicsPortal no reclama actualmente una certificación acreditada ISO 27001 en este sitio. Tampoco publica actualmente una auditoría independiente de terceros de la arquitectura de anonimato. Si esto cambia, el alcance y la fecha se publicarán aquí.

Materiales de revisión de seguridad #

Los clientes que requieran materiales de revisión de compras o jurídica pueden solicitarlos durante el proceso de compras. Los materiales disponibles pueden incluir un DPA firmado, pruebas registrales y fiscales, un cuestionario de seguridad cumplimentado y respuestas por escrito que cubran los procedimientos de copia de seguridad y restauración, el acceso privilegiado a producción y la gestión de la respuesta a incidentes.

Control de acceso #

La autorización se aplica a nivel de aplicación mediante políticas de Pundit .

• Los gestores no pueden ver comunicaciones a las que no están asignados ni en las que no participan. Los participantes los añade expresamente un administrador o el asignatario principal (por ejemplo, para implicar a jurídico o RR. HH.).
• Los informantes no tienen cuenta de usuario: acceden a su comunicación mediante un identificador del expediente (WB-XXXX-XXXX) más un código de acceso de 6 dígitos que eligen al presentarla.
• Cada acción de controlador comprueba la autorización. Los intentos de acceso no autorizado se bloquean y se registran.

Autenticación de dos factores #

Las cuentas de gestores y administradores pueden activar la autenticación de dos factores basada en TOTP mediante cualquier aplicación de autenticación estándar (Google Authenticator, 1Password, Authy y alternativas compatibles). Una vez activada, el inicio de sesión requiere tanto la credencial principal como un código rotativo de 6 dígitos.

Los informantes también se autentican con dos factores: el identificador del expediente (algo que poseen) y el código de acceso que eligieron al presentar la comunicación (algo que conocen). El código de acceso se almacena únicamente como un resumen bcrypt y no puede recuperarse. La bandeja de seguimiento y la publicación de mensajes están protegidas por sesión tras esta comprobación, de modo que un identificador del expediente filtrado por sí solo no puede leer la comunicación ni suplantar al informante.

Ciclo de vida de la sesión #

Cada sesión autenticada registra last_seen_at en cada solicitud (con antirrebote). Los usuarios pueden revisar sus sesiones activas, ver cuándo estuvo activa cada una por última vez, revocar cualquier sesión individualmente o cerrar todas las demás sesiones a la vez desde la configuración de la cuenta.

Las sesiones expiran automáticamente tras 14 días de inactividad. La siguiente solicitud de una sesión inactiva destruye el registro del lado del servidor, borra la cookie y obliga a una nueva autenticación mediante un enlace mágico nuevo. Un trabajo nocturno barre las sesiones abandonadas con el mismo tiempo de espera, de modo que user_agent e ip_address no se conservan más allá de la ventana de inactividad, ni siquiera cuando el usuario no vuelve nunca.

La autenticación con enlace mágico limita el alcance del impacto de las sesiones de larga duración: una cookie de sesión robada no proporciona una credencial reutilizable, y la nueva autenticación requiere acceso al correo electrónico.

Acceso de los miembros y baja #

El acceso a la organización se aplica en la frontera de la solicitud. Cuando se desactiva a un miembro:

• El acceso a la organización se rechaza de inmediato, incluso en URL previamente guardadas como favoritas.
• Las asignaciones de comunicaciones abiertas se anulan.
• Se eliminan las participaciones.
• Se conserva el historial del registro de auditoría atribuible al miembro.
• Se notifica al miembro desactivado.
• La reactivación no restaura automáticamente el acceso anterior a los casos.

El último administrador activo y el propietario de la organización no pueden desactivarse. Todos los eventos de desactivación y reactivación se escriben en el registro de auditoría en modo solo anexión.

Las pertenencias sin huella de cumplimiento (sin entradas en el registro de auditoría, sin asignaciones, sin participaciones) se eliminan de forma definitiva al retirarlas; las pertenencias con huella se desactivan de forma reversible para que el registro de auditoría siga siendo resoluble.

Supresión de la cuenta #

Cuando un miembro cierra su propia cuenta, su correo electrónico se sustituye por una dirección no enrutable y se eliminan definitivamente sus credenciales de dos factores, sesiones, tokens de API y preferencias. Si nunca actuó dentro de una organización, el registro se elimina. En caso contrario, su nombre y foto permanecen asociados a los expedientes y al registro de auditoría, mientras que sus pertenencias se desactivan para conservar la atribución exigida por las obligaciones de registro.

Limitación de tasa #

Los puntos de acceso del portal público están sujetos a limitación de tasa para prevenir abusos y ataques de enumeración:

La limitación de tasa usa el hash con clave de la IP descrito más arriba: no se almacena ninguna dirección IP para ello.

Auditoría y cumplimiento #

Registro de auditoría en modo solo anexión #

Cada acción en EthicsPortal se registra con:

• Marca de tiempo (UTC)
• Actor (qué usuario o proceso del sistema realizó la acción)
• Tipo de acción (comunicación creada, estado cambiado, mensaje enviado, gestor asignado, comunicación vista, comunicación exportada, comunicación suprimida, etc.)

Las entradas del registro de auditoría son de solo anexión. Ningún usuario, incluidos los administradores de la organización, puede editar una entrada ni eliminar una de forma selectiva: los disparadores de PostgreSQL rechazan la modificación y el truncado a nivel de base de datos. Las entradas solo se eliminan por el ciclo de retención o cuando se elimina la propia organización, y la intervención privilegiada en la base de datos sigue siendo un riesgo residual documentado (registro de riesgos R-08 ). El registro de auditoría completo se incluye en las exportaciones de expedientes en PDF para revisión normativa.

Conservación de los datos #

Las organizaciones configuran su propio período de conservación: 12, 24, 36, 48 o 60 meses tras el cierre de una comunicación. Cuando el período de conservación expira, la comunicación y todos los datos asociados (mensajes, adjuntos, entradas del registro de auditoría) se suprimen automática y permanentemente mediante un trabajo en segundo plano.

Esto satisface los requisitos de limitación del plazo de conservación del RGPD (art. 5(1)(e)) y las obligaciones de conservación de registros de la Directiva 2019/1937 (art. 17-18).

Protección CSRF #

Todos los envíos de formularios están protegidos contra la falsificación de solicitudes entre sitios mediante los tokens CSRF integrados de Rails.

Ciclo de vida de desarrollo seguro #

EthicsPortal sigue un ciclo de vida de desarrollo documentado para los cambios que tocan el Servicio. Las fases se indican aquí para que un revisor de compras pueda asociarlas a los controles A.8.25-A.8.29 de la norma ISO/IEC 27001:2022 (consulte el mapa de controles para la correspondencia completa).

Gestión de dependencias y parches #

EthicsPortal no despliega componentes de software al final de su vida útil. La aplicación se ejecuta sobre versiones con soporte activo de Rails, Ruby, PostgreSQL y el sistema operativo subyacente; las versiones de seguridad upstream se aplican de forma continua.

Las dependencias se analizan de forma continua en la integración continua:

• Brakeman señala las vulnerabilidades específicas de Rails en cada cambio.
• bundler-audit comprueba el Gemfile con la Ruby Advisory Database en cada cambio y de nuevo a diario, de modo que los avisos recién divulgados se detectan incluso cuando no ha cambiado ningún código.
• importmap audit analiza las importaciones de JavaScript en busca de vulnerabilidades conocidas en cada cambio y de nuevo a diario.
• Dependabot abre solicitudes de incorporación de cambios semanalmente para las gemas de Ruby y las GitHub Actions desactualizadas, agrupadas por actualizaciones de versión menor/parche.

Los componentes que alcanzan el final de su vida útil upstream se sustituyen o actualizan antes de que se cierre su ventana de soporte.

Infraestructura #

• Todo el tratamiento central de denuncias y datos de casos se realiza dentro de la Unión Europea.
• No se almacenan números de tarjetas de crédito ni credenciales de pago en los servidores de EthicsPortal. Todos los datos de pago los gestiona Stripe.
• Mailjet se usa para el correo electrónico transaccional (notificaciones a los gestores, no dirigidas a los informantes). Mailjet tiene su sede en Francia y trata todos los datos dentro de la UE.
• El sitio de presentación se sirve a través de Cloudflare (CDN, Estados Unidos); el portal de denuncias y el portal de los gestores no. Este tratamiento separado del sitio público y sus garantías de transferencia se describen en el Aviso de privacidad .

Copias de seguridad y restauración #

EthicsPortal opera dos capas de copia de seguridad complementarias, ambas conservadas dentro de la UE:

Objetivos de recuperación. El objetivo de punto de recuperación (RPO) es de 24 horas. El objetivo de tiempo de recuperación (RTO) es de 4 horas. Estos objetivos también figuran en el acuerdo de nivel de servicio .

Pruebas de restauración. Una prueba de restauración se ejecuta automáticamente cada mes mediante un flujo de trabajo de CI que restaura el último volcado en un entorno desechable, y a demanda mediante bin/backup-restore-test. La actualidad de las copias de seguridad se supervisa de forma continua (alerta si el volcado más reciente tiene más de 36 horas).

Cifrado. Hetzner Object Storage no cifra objetos en reposo de forma predeterminada, por lo que los volcados de la base de datos se cifran antes de salir del servidor: GnuPG simétrico AES-256, con la contraseña en poder únicamente del proceso de copia y depositada fuera de la máquina. Los campos cifrados por la aplicación siguen cifrados por separado dentro del volcado. Los archivos adjuntos siguen siendo una brecha abierta: se suben sin cifrado del lado del servidor y no se incluyen en el volcado.

Revisión operativa #

Algunos materiales operativos se comparten durante la revisión de compras en lugar de publicarse en su totalidad en la web abierta, porque contienen detalles de infraestructura y de respuesta más apropiados para una divulgación controlada.

Entre los temas disponibles a petición durante el proceso de compras se incluyen:

• Resumen del acceso privilegiado a producción
• Flujo de trabajo de respuesta a incidentes y contactos de escalado
• Respuestas de continuidad de negocio y de baja/exportación del cliente

Divulgación responsable #

Si descubre una vulnerabilidad de seguridad en EthicsPortal, comuníquela a security@ethicsportal.eu . Le pedimos que:

1. No divulgue públicamente la vulnerabilidad antes de que hayamos tenido ocasión de abordarla.
2. Proporcione detalles suficientes para que podamos reproducir y corregir el problema.
3. No acceda ni modifique los datos de otros clientes.

Acusaremos recibo de su comunicación en un plazo de 2 días laborables y nos esforzaremos por resolver las vulnerabilidades confirmadas con prontitud.

Sin programa de recompensas. No remuneramos los informes de vulnerabilidades ni firmamos acuerdos de confidencialidad, aceptamos condiciones comerciales o mantenemos llamadas como requisito previo para recibir un informe. Envíe el activo afectado, los pasos de reproducción y el impacto que haya constatado a la dirección indicada.

Última actualización: 30 de septiembre de 2026