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

Les mesures se composent des TOM applicatives de Datenmaske (un SMSI propre certifié ISO/IEC 27001 est en préparation, objectif 2027) ainsi que des TOM d'infrastructure du prestataire d'hébergement netcup (centre de données à Nuremberg ; le centre de données est certifié ISO/IEC 27001 — uniquement Data-Center). Les principaux lieux de traitement se situent dans l'Union européenne : hébergement chez netcup à Nuremberg ainsi que Microsoft Azure pour l'OCR et un étage de repli NER technique dans des régions UE configurées. Des conventions conformes à l'Art. 28 DSGVO sont conclues avec les sous-traitants (projet de modèle voir /avv).

Remarque : Les mesures décrites ici concernent l'application Datenmaske existante (couche générale DSGVO/Art. 32). Elles ne couvrent pas le traitement de secrets professionnels protégés au titre du § 203 StGB ; celui-ci est réservé à une édition de produit distincte.

1. Chiffrement (transmission et stockage)

• Transmission des données chiffrée par TLS (HTTPS) pour toutes les connexions entre le navigateur, l'API publique et l'infrastructure applicative ; les protocoles en clair non chiffrés sont exclus.
• Stockage sur des serveurs UE avec chiffrement au niveau du disque assuré par l'infrastructure d'hébergement (netcup, centre de données de Nuremberg). Remarque : il n'existe pas de chiffrement applicatif au niveau du champ pour des colonnes individuelles de la base de données ; le chiffrement des données au repos est garanti au niveau de l'infrastructure.
• L'intégralité de la transmission des documents transite exclusivement par des connexions chiffrées.

2. Contrôle d'accès et contrôle d'accès aux données

• Authentification par mot de passe liée à la session via des cookies HttpOnly sécurisés ; aucun accès sans mot de passe ni accès maître universel.
• Séparation stricte des locataires au niveau des enregistrements : toutes les données applicatives (documents, propositions de caviardage, actions, journaux d'audit, paramètres) sont stockées séparément par utilisateur authentifié et lues exclusivement pour le propriétaire autorisé.
• La fonction d'administration est protégée triplement et entièrement désactivée en production (l'interface répond par un 404, son existence n'est pas divulguée).
• L'API publique est authentifiée exclusivement via des clés API personnalisées ; les clés sont stockées uniquement sous forme de hachage à sens unique et ne sont pas reconstituables.
• Journalisation d'audit exhaustive pour le téléversement, l'examen des propositions, la caviardage, l'export et la suppression, par utilisateur et par document.

3. Gestion des clés

• Les clés API sont stockées exclusivement sous forme de hachage à sens unique ; le texte en clair est affiché une seule fois lors de la création, puis n'est plus reconstituable.
• Un identifiant court de clé (préfixe et premiers caractères) sert à la reconnaissance en cas de support, sans divulguer la clé elle-même.
• Avant toute persistance des journaux d'erreurs et de contexte, les valeurs associées à des noms de clés sensibles (par ex. Secret, Password, Token, API-Key) sont automatiquement et récursivement supprimées.
• Les mots de passe sont stockés au moyen de fonctions de hachage à sens unique usuelles du secteur ; les jetons de session sont rotationnés régulièrement.
• Cinq clés API au maximum par utilisateur, révocables à tout moment et avec date d'expiration optionnelle.

4. Réponse aux incidents (gestion des incidents)

• Recensement centralisé des incidents et erreurs, structuré par horodatage et par source (par ex. authentification, e-mail, webhook, OCR, détection, caviardage, export).
• Les erreurs côté serveur sont automatiquement écrites dans le recensement des incidents.
• Les erreurs de traitement dans les flux e-mail, webhook, export et OCR sont signalées via une fonction d'erreur centrale.
• La consultation des incidents n'est possible que localement, via l'outil d'administration triple protégé et désactivé en production.
• L'information contractuelle du responsable du traitement en cas de violations de la protection des données à caractère personnel conformément à l'Art. 33 DSGVO est consignée dans l'AVV.

5. Sauvegarde, restauration et disponibilité

• Mesures de disponibilité et de sauvegarde au niveau de l'infrastructure conformément au périmètre de prestations convenu avec le partenaire d'hébergement netcup (centre de données de Nuremberg ; uniquement Data-Center — aucune certification de l'application Datenmaske). Datenmaske n'exploite pas de sauvegarde documentaire applicative distincte.
• Côté application, Datenmaske pratique une suppression active des données plutôt qu'une sauvegarde applicative : les documents téléversés sont automatiquement supprimés physiquement après expiration du délai de conservation (30 jours par défaut, configurable).
• Les journaux d'audit sont conservés sans contenu documentaire ; la conservation spécifique à l'offre (Starter 30 / Solo 180 / Professional 180 / Business 365 jours) est fixée par enregistrement et appliquée automatiquement.
• Concepts d'alimentation de secours et de climatisation dans le centre de données (netcup).
• Séparation des environnements de production et de développement.

6. Mesures d'intégrité spécifiques à la caviardage

• Suppression physique irréversible du texte caviardé du PDF (suppression du flux de contenu) — pas de simple superposition visuelle ; le texte n'est plus structurellement présent dans le document.
• Vérification en échec contrôlé (fail-closed) : après la caviardage, le document est automatiquement revérifié afin de confirmer que les textes marqués ne sont plus extractibles. Si la vérification n'est pas possible, elle échoue au lieu de simuler un succès.
• Lors de l'export, toutes les métadonnées (titre, auteur, date de création, entre autres) sont supprimées.
• Pour les documents numérisés (basés sur l'OCR), la vérification est limitée à la couche texte ; la couche de pixels n'est pas vérifiée automatiquement. Les utilisateurs sont invités à procéder à un contrôle manuel (limitation connue, durcissement en cours).
• Journal de caviardage distinct sous forme de PDF autonome avec sommes de contrôle SHA-256 doubles (original et fichier caviardé) pour chaque transaction d'export.

7. Gestion des vulnérabilités et cycle de vie du logiciel

• Surveillance continue des dépendances logicielles concernant les vulnérabilités de sécurité connues au moyen d'analyses de dépendances ainsi que l'épinglage (pinning) des paquets critiques.
• Exigences strictes de qualité et de typage du code avec des contrôles statiques automatisés comme porte obligatoire de pré-commit et de fusion (merge gate).
• Revue de code avant chaque fusion plus inspection statique manuelle du code. Remarque : il n'existe actuellement pas de pipeline SAST/DAST automatisé au sens d'un programme DevSecOps SOC-2 ; les mesures sont manuelles, complétées par l'analyse de dépendances.
• La détection IA standard est auto-hébergée ; Azure est utilisé pour l'OCR et, optionnellement, comme étage de repli NER technique. En cas d'échec de la détection externe ou auto-hébergée, il subsiste la détection basée sur des règles et l'utilisateur doit examiner les propositions manuellement.

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 .