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-05-17.
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).
| Campo | Cifrado | Determinista |
|---|---|---|
| Descripción de la comunicación | Sí | No |
| Nombre del informante | Sí | No |
| Datos de contacto del informante | Sí | No |
| Cuerpo del mensaje (comunicación informante-gestor) | Sí | No |
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 #
Anonimización de las direcciones IP #
Las rutas del portal (presentación de comunicaciones, consulta de casos, mensajería) usan un hash unidireccional SHA256 de la IP de la solicitud únicamente para la limitación de tasa. El hash no es reversible: no es posible recuperar la IP original a partir del valor almacenado.
A nivel de aplicación, la dirección IP en bruto del informante no se almacena en la base de datos, y los registros de la aplicación de las rutas del portal se depuran para proteger el anonimato del informante.
Eliminación de metadatos de los archivos #
Los archivos subidos se depuran automáticamente de metadatos identificativos antes de su almacenamiento:
| Tipo de archivo | Metadatos eliminados | Método |
|---|---|---|
| Imágenes (JPEG, PNG, TIFF, WebP) | Datos EXIF: coordenadas GPS, modelo de cámara, número de serie del dispositivo, autor, marcas de tiempo | Procesamiento de imágenes Vips |
| Documentos PDF | Autor, aplicación creadora, historial de modificaciones | exiftool en la configuración de producción estándar |
| Archivos de vídeo | GPS, información del dispositivo, software de grabación | exiftool en la configuración de producción estándar |
| Archivos de audio | Dispositivo de grabación, GPS, etiquetas de software | exiftool en la configuración de producción estándar |
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: está libre de cookies, no recopila datos personales y es plenamente conforme con el RGPD. El propio portal de denuncias 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 .
| Rol | Puede ver comunicaciones | Puede gestionar la configuración de la organización | Puede asignar gestores |
|---|---|---|---|
| Administrador | Todas las comunicaciones | Sí | Sí |
| Gestor | Las comunicaciones a las que está asignado o en las que participa | No | No |
- 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.
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:
| Punto de acceso | Límite |
|---|---|
| Presentación de comunicaciones | 5 por cada 10 minutos por IP anonimizada |
| Consulta de casos (identificador del expediente + código de acceso) | 10 por cada 3 minutos por IP anonimizada |
| Envío de mensajes | 10 por cada 3 minutos por IP anonimizada |
La limitación de tasa usa el hash unidireccional de la IP descrito más arriba: no se almacena ninguna IP real.
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. No pueden editarse ni eliminarse por ningún usuario, incluidos los administradores de la organización. 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).
| Fase | Práctica |
|---|---|
| Arquitectura y diseño | Las funciones que introducen nuevos flujos de datos personales, subencargados del tratamiento o ámbitos de autorización se evalúan con arreglo a los compromisos de cifrado, control de acceso y registro de auditoría documentados en esta página antes de su implementación. |
| Revisión de código | Los cambios de producción se revisan con arreglo a una lista de comprobación de seguridad por escrito (cobertura de cifrado, ámbito de autorización, emisión del registro de auditoría, validación de entradas, gestión de secretos) antes del despliegue. El análisis estático se ejecuta en cada cambio y bloquea la fusión si falla. |
| Codificación segura | La base de código usa defensas a nivel de framework de forma predeterminada: consultas parametrizadas mediante ActiveRecord, parámetros estrictos, escape de la salida en las vistas, tokens CSRF, cifrado a nivel de atributo, autorización de Pundit en la frontera del controlador. Las desviaciones requieren una justificación por escrito. |
| Pruebas de seguridad en desarrollo | El análisis estático (Brakeman
, bundler-audit
, importmap audit) se ejecuta en cada cambio. Las pruebas cubren las rutas de autorización, los invariantes de cifrado en reposo, la emisión del registro de auditoría y la aplicación de la limitación de tasa. Consulte la gestión de dependencias y parches
para conocer la cadena de herramientas completa. |
| Separación de entornos | Los entornos de producción y no producción están aislados. No se usan datos personales de producción fuera de producción; los entornos de pruebas y desarrollo usan datos sintéticos. |
| Respuesta a vulnerabilidades | Las comunicaciones se acusan recibo en un plazo de 2 días laborables (véase divulgación responsable ). Objetivos: problemas críticos subsanados en un plazo de 7 días, altos en 30, medios en 90. Los problemas confirmados que afecten a clientes desplegados se comunican a través del registro de incidentes cuando cumplen los criterios de ámbito del registro. |
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 auditanaliza 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 #
| Componente | Proveedor | Ubicación |
|---|---|---|
| Servidor de la aplicación y base de datos | Hetzner | Núremberg, Alemania (UE) |
| Almacenamiento de archivos | Hetzner Object Storage | Núremberg, Alemania (UE) |
| Correo electrónico transaccional | Mailjet | Francia (UE) |
| Procesamiento de pagos | Stripe | UE |
- Todo el tratamiento principal de datos 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. Consulte la página de subencargados del tratamiento para la lista completa y las salvaguardias de transferencia.
Copias de seguridad y restauración #
EthicsPortal opera dos capas de copia de seguridad complementarias, ambas conservadas dentro de la UE:
| Capa | Qué | Dónde | Conservación |
|---|---|---|---|
| Base de datos | Volcados cifrados diarios de PostgreSQL mediante un accesorio de Kamal | Hetzner Object Storage, Núremberg (UE) | 7 días |
| Servidor | Instantáneas completas de disco del host de la aplicación | Hetzner Cloud, Núremberg (UE) | 7 días |
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. Los volcados de la base de datos se cifran en reposo en Hetzner Object Storage; los campos a nivel de aplicación cifrados mediante Rails ActiveRecord Encryption permanecen cifrados 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:
- No divulgue públicamente la vulnerabilidad antes de que hayamos tenido ocasión de abordarla.
- Proporcione detalles suficientes para que podamos reproducir y corregir el problema.
- 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.
Última actualización: