Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Las medidas se componen de las TOM de aplicación de Datenmaske (un SGSI propio certificado según ISO/IEC 27001 está en preparación, objetivo 2027) así como de las TOM de infraestructura del proveedor de hosting netcup (centro de datos en Núremberg; el centro de datos está certificado según ISO/IEC 27001 — únicamente Data-Center). Los principales lugares de tratamiento se encuentran en la Unión Europea: hosting con netcup en Núremberg así como Microsoft Azure para OCR y un nivel técnico de respaldo NER en regiones de la UE configuradas. Con los subencargados de tratamiento existen acuerdos conforme al Art. 28 DSGVO (borrador de modelo véase /avv).

Nota: Las medidas aquí descritas se refieren a la aplicación Datenmaske existente (capa general de DSGVO/Art. 32). No comprenden el tratamiento de secretos profesionales amparados por el § 203 StGB; este está reservado a una edición de producto separada.

1. Cifrado (transmisión y almacenamiento)

• Transmisión de datos cifrada con TLS (HTTPS) para todas las conexiones entre el navegador, la API pública y la infraestructura de la aplicación; los protocolos de texto plano no cifrados están excluidos.
• Almacenamiento en servidores de la UE con cifrado a nivel de disco proporcionado por la infraestructura de hosting (netcup, centro de datos de Núremberg). Nota: No existe un cifrado a nivel de aplicación de columnas individuales de la base de datos; el cifrado de datos en reposo se garantiza a nivel de infraestructura.
• Toda la transmisión de documentos se realiza exclusivamente a través de conexiones cifradas.

2. Control de acceso físico y control de permisos

• Autenticación basada en contraseña y vinculada a la sesión mediante cookies HttpOnly seguras; sin acceso sin contraseña ni acceso maestro universal.
• Separación estricta de inquilinos a nivel de registro: todos los datos de la aplicación (documentos, propuestas de anonimización, acciones, registros de auditoría, ajustes) se almacenan separadamente por usuario autenticado y se consultan exclusivamente para el propietario autorizado.
• La función de administración está protegida triplemente y completamente desactivada en producción (la interfaz responde con 404, no se revela su existencia).
• La API pública se autentica exclusivamente mediante claves API personalizadas; las claves se almacenan únicamente como hash unidireccional y no son reconstruibles.
• Registro de auditoría sin lagunas para carga, revisión de propuestas, anonimización, exportación y eliminación por usuario y documento.

3. Gestión de claves

• Las claves API se almacenan exclusivamente como hash unidireccional; el texto plano se muestra una única vez en el momento de su creación y después no es reconstruible.
• Un identificador breve de la clave (prefijo y primeros caracteres) sirve para su reconocimiento en caso de soporte, sin revelar la clave en sí.
• Antes de toda persistencia de logs de errores y de contexto se eliminan automáticamente y de forma recursiva los valores con nombres de clave sensibles (p. ej. Secret, Password, Token, API-Key).
• Las contraseñas se almacenan con funciones de hash unidireccional habituales en el sector; los tokens de sesión se rotan periódicamente.
• Por usuario como máximo cinco claves API, revocables en cualquier momento y con fecha de caducidad opcional.

4. Respuesta a incidentes (gestión de incidentes)

• Registro centralizado de incidencias y errores, estructurado por marca de tiempo y fuente (p. ej. autenticación, correo electrónico, webhook, OCR, detección, anonimización, exportación).
• Los errores del lado del servidor se escriben automáticamente en el registro de incidentes.
• Los errores de tratamiento en las rutas de correo electrónico, webhook, exportación y OCR se notifican a través de una función de errores centralizada.
• La consulta de incidentes únicamente es posible de forma local a través del instrumento de administración protegido triplemente y desactivado en producción.
• La información contractual al responsable en caso de violaciones de la protección de datos personales conforme al Art. 33 DSGVO está pactada en el AVV.

5. Copia de seguridad, restauración y disponibilidad

• Medidas de disponibilidad y de copia de seguridad a nivel de infraestructura conforme al alcance de prestaciones acordado con el socio de hosting netcup (centro de datos de Núremberg; únicamente Data-Center — sin certificación de la aplicación Datenmaske). Datenmaske no opera una copia de seguridad documental aplicativa separada.
• A nivel de aplicación, Datenmaske opera una supresión activa de datos en lugar de una copia de seguridad aplicativa: los documentos cargados se eliminan físicamente de forma automática tras el vencimiento del plazo de conservación (por defecto 30 días, configurable).
• Los registros de auditoría se conservan sin contenidos documentales; la conservación específica por tarifa (Starter 30 / Solo 180 / Professional 180 / Business 365 días) se fija por registro y se aplica automáticamente.
• Conceptos de alimentación ininterrumpida y climatización en el centro de datos (netcup).
• Separación de los entornos de producción y de desarrollo.

6. Medidas de integridad específicas de la anonimización

• Eliminación física irreversible del texto anonimizado del PDF (eliminación del flujo de contenido) — sin una simple superposición visual; el texto ya no forma parte estructuralmente del documento.
• Verificación fail-closed: tras la anonimización el documento se vuelve a comprobar automáticamente para confirmar que los textos marcados ya no son extraíbles. Si no es posible la verificación, esta fracasa en lugar de simular éxito.
• Al exportar se eliminan todos los metadatos (título, autor, fecha de creación, entre otros).
• En documentos escaneados (basados en OCR) la verificación se limita al nivel de texto; el nivel de píxel no se verifica automáticamente. Se indica a los usuarios que realicen una comprobación manual (limitación conocida, endurecimiento en curso).
• Protocolo de anonimización separado como PDF independiente con sumas de comprobación SHA-256 duales (original y archivo anonimizado) para cada transacción de exportación.

7. Gestión de vulnerabilidades y ciclo de vida del software

• Supervisión continua de las dependencias de software en busca de vulnerabilidades conocidas mediante análisis de dependencias así como fijado (pinning) de paquetes críticos.
• Requisitos estrictos de calidad y tipificación del código con comprobaciones estáticas automatizadas como puerta obligatoria de pre-commit y de merge.
• Revisión de código antes de cada merge más inspección estática manual del código. Nota: Actualmente no existe un pipeline SAST/DAST automatizado en el sentido de un programa DevSecOps SOC-2; las medidas son manuales más análisis de dependencias.
• La detección habitual por IA se autohospeda; Azure se emplea para OCR y, opcionalmente, como nivel técnico de respaldo NER. Si falla la detección externa o autohospedada, permanece la detección basada en reglas y el usuario debe revisar manualmente las propuestas.

Penetrationstest

Kontakt & weiterführende Unterlagen

Den vollständigen Auftragsverarbeitungsvertrag (AVV) samt Anlage zu diesen Maßnahmen sowie die AVV-Änderungshistorie finden Sie auf den entsprechenden Seiten. Einen kompakteren Überblick über Sicherheit & Datenschutz bietet die Seite Sicherheit & Datenschutz .