Selon Simson L. Garfinkel du laboratoire de technologie de l'information de la division d'accès à l'information du NIST,
La désidentification n'est pas une technique unique, mais un ensemble d'approches, d'algorithmes et d'outils qui peuvent être appliqués à différents types de données avec différents niveaux d'efficacité. En général, la protection de la vie privée s'améliore à mesure que des techniques d'anonymisation plus agressives sont utilisées, mais moins d'utilité reste dans l'ensemble de données résultant.
-Annulation de l'identification des informations personnelles, NISTIR 8053
Le masquage de données statiques (SDM) est le terme reconnu par l'industrie pour désigner ces divers moyens d'anonymisation des éléments de données au repos. Les éléments sont généralement des valeurs de colonne de base de données ou de champ de fichier plat qui sont considérées comme sensibles ; dans le secteur de la santé, ils sont appelés identifiants clés. Les informations personnelles identifiables (PII), les informations médicales protégées (PHI), les numéros de compte principaux (PAN), les secrets commerciaux ou d'autres valeurs sensibles sont particulièrement menacés.
Le produit de sécurité centré sur les données « point de départ » IRI FieldShield — ou le produit IRI CoSort et la plate-forme IRI Voracity qui incluent les mêmes fonctionnalités — fournit plusieurs fonctions de découverte de données et de SDM pour plusieurs sources de données. Les fonctions de masquage par champ/colonne disponibles incluent :
- plusieurs algorithmes de chiffrement (et de déchiffrement) compatibles NSA Suite B et FIPS, y compris la préservation du format cryptage
- Hachage SHA-1 et SHA-2
- Dé-ID ASCII (brouillage de bits)
- encodage et décodage binaire
- Floutage ou regroupement des données (anonymisation)
- génération ou sélection aléatoire
- masquage (obscurcissement des caractères)
- pseudonymisation réversible et non réversible
- logique d'expression personnalisée (calcul / mélange)
- filtrage ou suppression de valeurs conditionnelles/partielles (omission)
- remplacement de la valeur personnalisée
- décalage d'octets et fonctions de chaîne
- tokénisation (pour PCI)
Vous pouvez également "rouler votre propre" fonction de masquage des données externes. Cela vous permet d'appeler une routine personnalisée au niveau du champ lors de l'exécution au lieu d'une routine intégrée.
La question demeure, quelle fonction de masquage dois-je utiliser (sur chaque article) ? Cela dépend des besoins et des règles de votre entreprise, ainsi que des lois applicables en matière de confidentialité des données. Au niveau technique, cela signifie généralement décider comment le texte chiffré résultant (données masquées) doit apparaître, s'il doit être réversible ou unique, à quel point il est sécurisé et éventuellement, quel type de ressources de calcul et de temps sont disponibles pour le processus. . Examinons en détail ces critères de décision courants :
Apparence (réalisme)
Les données nouvellement masquées doivent-elles ressembler plus ou moins aux données d'origine ? Qu'en est-il de sa taille et de son format ? La pseudonymisation et le chiffrement préservant le format sont les deux moyens les plus courants de
conserver l'apparence des noms propres et des numéros de compte ou de téléphone alphanumériques, respectivement. Mais le masquage de sous-chaîne (a/k/a caviardage partiel de champ, par exemple, XXX-XX-1234) peut être très bien pour des choses comme les SSN. Pensez à la persistance et à l'affichage des données pour l'analyse, etc.
En relation avec cela, l'apparence et le réalisme du texte chiffré peuvent également déterminer la facilité d'utilisation des résultats. Les cibles d'application et de table de base de données (utilitaire de chargement) peuvent exiger que le format des données soit non seulement conforme aux structures prédéfinies, mais continue de fonctionner dans des requêtes ou d'autres contextes opérationnels en aval.
En d'autres termes, si des données masquées qui sont jolies et/ou des données fonctionnelles sont requises, n'optez pas pour la rédaction complète, la randomisation, le hachage ou le chiffrement direct (qui élargit et obscurcit les résultats). Vous pourrez peut-être vous en tirer avec de petits ajustements comme le vieillissement et la manipulation de sous-chaînes, mais considérez l'impact de ces choix sur vos autres critères de décision…
Réversibilité (ré-identification)
Besoin de restaurer les données d'origine ? La réponse à cela peut dépendre du fait que vous laissez les données source seules, comme vous le feriez dans le masquage dynamique des données, ou du moment où vous écrivez les données masquées vers de nouvelles cibles. Dans ces cas, la réponse est non.
Si la réponse est non, vous aurez peut-être encore besoin de réalisme, auquel cas une pseudonymisation irréversible peut être votre meilleur pari. Si ce n'est pas le cas et que l'apparence n'a pas d'importance, optez pour la rédaction de caractères. Et si ni l'un ni l'autre n'est vrai, envisagez de supprimer purement et simplement la colonne source de la cible.
Lorsque la réponse est oui, les fonctions de masquage des données IRI telles que le cryptage, la pseudonymisation réversible ou la tokenisation, le codage ou la réidentification ASCII (brouillage des bits) sont indiquées. Dans des cas d'utilisation plus avancés, vous pouvez également avoir besoin d'une inversion différentielle ; c'est-à-dire lorsque différents destinataires d'une même cible sont autorisés à voir différentes choses dans le même ensemble de données. Dans de tels cas, des clés de chiffrement privées, des scripts de tâche de révélation spécifiques à l'utilisateur ou même des applications personnalisées peuvent être déployés.
Unicité (cohérence)
La même valeur d'origine doit-elle toujours être remplacée par la même valeur de remplacement, mais différente ? Les données vont-elles être jointes ou regroupées par les valeurs de remplacement ? Si tel est le cas, l'algorithme de remplacement choisi doit produire des résultats uniques et reproductibles afin de préserver l'intégrité référentielle malgré le masquage qui s'est produit.
Cela peut être réalisé grâce au cryptage lorsque le même algorithme et la même phrase de passe (clé) sont utilisés avec le même texte en clair. Les assistants de classification des données et de protection de table croisée dans l'IDE IRI Workbench pour FieldShield, Voracity, etc. facilitent cela grâce à l'application de table croisée (ou plus globale) de la règle de masquage correspondante. De cette façon, la même valeur de texte en clair obtient toujours le même résultat de texte chiffré quel que soit son emplacement.
La pseudonymisation est cependant plus délicate ici, en raison d'un manque de noms de remplacement uniques, de noms originaux en double et de changements ( insertions, mises à jour ou suppressions) aux valeurs d'origine dans les tables ou fichiers source. IRI a résolu le problème de la pseudonymisation cohérente des tables croisées dans cet exemple de flux de travail Voracity.
Force (Sécurité)
Un regard sur les algorithmes à l'intérieur de chaque fonction peut vous aider à déterminer leur "crackabilité" relative et à l'évaluer par rapport aux autres considérations de texte chiffré comme l'apparence et la vitesse. Par exemple, la fonction AES256 d'IRI est plus puissante que l'option AES128, SHA2 est plus puissante que SHA1 et toutes sont plus puissantes que les fonctions d'encodage/décodage base64 et de dé-ID/ré-ID ASCII.
Par définition, les fonctions réversibles sont généralement plus faibles que celles qui ne peuvent pas être inversées. Par exemple, la méthode de pseudonymisation irréversible (ensemble de recherche étranger) d'IRI est plus sûre que sa méthode de pseudonymisation réversible (ensemble original brouillé). Cela dit, l'algorithme de chiffrement AES-256 peut également être très difficile à déchiffrer lorsque la clé a été perdue.
Une sécurité encore plus forte est bien sûr l'omission, suivie de l'obscurcissement des caractères (masquage), qui sont irréversibles. Mais l'inconvénient est le manque de convivialité. Dans le contexte de la sphère de sécurité HIPAA, la suppression des identifiants de clé est conforme. Si vous avez besoin d'utiliser une partie des données sources à des fins d'analyse, de recherche, de marketing ou de démonstration, vous aurez besoin d'une fonction de masquage à la place et d'un expert pour déterminer (et certifier) que votre ou vos techniques ont une faible valeur statistique. probabilité de ré-identification.
Pendant que nous parlons de l'anonymisation HIPAA, n'oubliez pas qu'il peut également y avoir un risque associé aux soi-disant quasi-identifiants (comme le code postal et l'âge). Ces valeurs peuvent être utilisées conjointement avec d'autres ensembles de données pour établir une piste de réidentification et valent donc également la peine d'être masquées dans de nombreux cas ; si et comment sont soumis à ces mêmes considérations.
Calcul (Performances)
L'un des avantages de l'approche de masquage des données - même lorsque des algorithmes de chiffrement intensifs en calcul sont impliqués - est que sa surcharge par rapport au chiffrement à grande échelle (d'un réseau entier, d'une base de données, d'un fichier/système, d'un lecteur de disque) est bien inférieure. Seuls les éléments de données (valeurs de colonne) que vous désignez pour la protection doivent être ingérés, traités par et renvoyés par la fonction de masquage.
En général, plus l'algorithme est complexe (et fort), plus il sera long à appliquer. Les vitesses de masquage des données dépendront également du nombre de fonctions appliquées, du nombre de colonnes et de lignes de la base de données, du nombre de contraintes de recherche à respecter dans le processus (pour l'intégrité référentielle), de la bande passante du réseau, de la RAM, des E/S, des processus simultanés et bientôt.
Le tableau non scientifique suivant décompose la plupart des attributs décrits ci-dessus pour une référence pratique, pour certaines catégories fonctionnelles de masquage de données IRI prises en charge (mais pas toutes !), et généralement en termes relatifs uniquement. Inutile de dire qu'IRI décline toute garantie d'adéquation ou de responsabilité pour ce tableau !
Fonctions de masquage des données IRI (dans FieldShield et Voracity)
Que vous utilisiez des fonctions de masquage de données IRI intégrées ou des fonctions personnalisées que vous définissez, l'idée est de les appliquer en fonction de vos règles métier à des lignes ou des colonnes spécifiques et/ou à travers des tables. Et vous le ferez grâce à des règles de masquage des données que vous pouvez définir, stocker et réutiliser. Il est également possible (et préférable) d'appliquer ces fonctions de masquage des données aux données classées automatiquement en tant que règles pour plus de commodité et de cohérence. Et vous pouvez en exploiter plusieurs dans des applications de masquage dynamique des données via un appel d'API.
Les utilisateurs de FieldShield (ou Voracity) peuvent créer, exécuter et gérer vos tâches de masquage de données dans une interface graphique gratuite de pointe, basée sur Eclipse.™ Ou ils peuvent éditer et exécuter des scripts 4GL compatibles et auto-documentés définissant leur données source/cible et fonctions de masquage, et exécutez ces scripts sur la ligne de commande.
Pour plus d'informations, consultez https://www.iri.com/solutions/data-masking ou contactez votre représentant IRI.
