Los registros de consentimiento son pruebas. Si pueden perderse, alterarse o filtrarse, no le protegerán en una auditoría. Esta página describe cómo mantiene Cookiesh la seguridad del servicio y de sus datos. Los clientes Enterprise pueden solicitar documentación más detallada y cuestionarios de seguridad cumplimentados en security@cookiesh.eu.
Infraestructura
- La plataforma de Cookiesh se ejecuta en Amazon Web Services en Fráncfort (Alemania), repartida en varias zonas de disponibilidad.
- El script de consentimiento se sirve desde la red global en el edge de Cloudflare, que además absorbe los ataques de denegación de servicio.
- Los entornos de producción, preproducción y desarrollo están completamente separados. Los datos de los clientes nunca se utilizan en pruebas.
- La infraestructura se define como código, se revisa como el código de la aplicación y se despliega de forma automática.
Protección de los datos
- Cifrado en tránsito. Todo el tráfico utiliza TLS 1.2 o superior, con HSTS en todos los dominios de Cookiesh.
- Cifrado en reposo. Las bases de datos, las copias de seguridad y las exportaciones se cifran con AES-256, con claves gestionadas en AWS Key Management Service.
- Minimización de datos. Los registros de consentimiento contienen un ID seudónimo, nunca una dirección IP sin procesar. Los ID de usuario que se pasan a
identify()solo se guardan como hashes con sal. - Residencia en la UE. Los registros de consentimiento se almacenan y se tratan en la UE. Nuestra página de subencargados enumera todos los proveedores que tratan datos personales.
Registros de consentimiento a prueba de manipulaciones
Los registros de consentimiento solo admiten nuevas entradas. Cada registro incluye un hash SHA-256 de su propio contenido y del registro anterior, lo que forma una cadena por sitio. Modificar o eliminar cualquier registro rompe todos los hashes posteriores, así que cualquier manipulación es detectable.
Verificamos automáticamente todas las cadenas cada día. Los clientes Enterprise pueden exportar las pruebas de la cadena y verificarlas por su cuenta.
Seguridad de las aplicaciones
- Todos los cambios de código pasan una revisión por pares antes de integrarse.
- Comprobaciones automáticas analizan cada cambio en busca de dependencias vulnerables, secretos expuestos y fallos de seguridad habituales.
- Una empresa independiente analiza la plataforma en busca de debilidades de seguridad al menos una vez al año, y corregimos los hallazgos según su gravedad.
- El panel admite el inicio de sesión único con SAML 2.0 y exige la autenticación multifactor para los inicios de sesión con contraseña.
Integridad del script
El script de consentimiento se ejecuta en los sitios web de nuestros clientes, así que lo tratamos con especial cuidado:
- Las versiones se compilan en un pipeline aislado y requieren la aprobación de dos ingenieros.
- Las URL versionadas del script admiten hashes de Subresource Integrity (SRI), de modo que los navegadores rechazan cualquier archivo modificado.
- El script funciona con una Content Security Policy estricta. Admite nonces y no utiliza
eval(). - El script no instala ninguna cookie aparte de
cookiesh_consenty no envía datos a terceros.
Control de acceso
- Los empleados solo obtienen acceso a los sistemas de producción cuando su función lo requiere, y cada acceso queda registrado.
- El acceso a producción exige inicio de sesión único con autenticación multifactor basada en hardware.
- Revisamos los permisos de acceso cada trimestre y los retiramos el mismo día en que alguien cambia de función o deja la empresa.
- Los empleados reciben formación en seguridad y privacidad al incorporarse y, después, cada año.
Disponibilidad y copias de seguridad
- Las bases de datos se copian de forma continua, con recuperación a un momento dado de los últimos 30 días.
- Probamos la restauración a partir de las copias de seguridad cada trimestre.
- Si no se puede acceder al servicio de consentimiento, el script recurre a la elección guardada del visitante o, para los visitantes nuevos, al valor por defecto más protector de la región. Nunca falla de forma permisiva.
- Los planes Enterprise incluyen un SLA de disponibilidad del 99,99 %.
Respuesta a incidentes
Contamos con un plan documentado de respuesta a incidentes y con ingenieros de guardia las 24 horas. Si un incidente de seguridad afecta a sus datos, se lo notificaremos sin dilación indebida, y en todo caso en un plazo máximo de 48 horas desde que tengamos conocimiento de él, tal como exige nuestro Acuerdo de Encargo del Tratamiento. Después, le mantendremos informado hasta que el incidente se resuelva.
Divulgación responsable
Si cree que ha encontrado una vulnerabilidad de seguridad en Cookiesh, escriba a security@cookiesh.eu con los detalles y los pasos para reproducirla. Acusaremos recibo de su informe en un plazo de dos días hábiles y le mantendremos informado mientras la corregimos.
No emprenderemos acciones legales contra los investigadores que actúen de buena fe. Eso significa que no accede a datos de otras personas ni los modifica, no degrada el servicio y nos concede un plazo razonable para corregir el problema antes de hacerlo público.