Protéger les données au repos et en mouvement
Les applications de base de données qui mettent à jour et interrogent les tables peuvent avoir besoin de sécuriser les données entrant dans ces tables ou extraites de celles-ci. Les données sensibles doivent être protégées à l'entrée du tableau, une fois dans le tableau ou à la sortie. Dans tous les cas, l'objectif est d'empêcher les personnes non autorisées d'accéder à certaines valeurs de lignes ou de colonnes considérées comme sensibles.
Pour les données de forme normale (structurées) dans les bases de données relationnelles, l'utilitaire de masquage de données autonome IRI FieldShield, ou sa bibliothèque compatible de fonctions de masquage appelables, peut prendre en charge les scénarios ci-dessus, offrant de nombreuses options à la fois statiques (persistantes, au repos) et dynamiques (au repos). -transit) options de masquage des données. Si vous avez également des valeurs PII/PHI flottant de manière aléatoire dans des colonnes RDB semi-structurées et non structurées (comme text, C/BLOB, XML/JSON), consultez cet article sur l'approche IRI DarkShield.
Cet article parlera des options de FieldShield, cependant, puisque la plupart des utilisateurs de RDB sont concernés par la recherche et le masquage des valeurs de colonne fixes. Les utilisateurs de FieldShield peuvent classer, localiser et masquer les données dans les tables de base de données et, pour les utilisateurs de l'application, exécuter via :
- un masquage statique des données sur les tables de production et un démasquage dynamique par les utilisateurs autorisés de l'application
- fonctions de masquage intégrées dans les tâches de transformation, de nettoyage ou de création de rapports compatibles avec les métadonnées
- un système de suppression dynamique des données basé sur un proxy
- via une API SDK, ou un système, appel d'un programme
- in situ, via des procédures SQL utilisant une bibliothèque personnalisée
Si vos données se trouvent dans des bases de données NoSQL telles que MongoDB, Cassandra, Elasticsearch ou MarkLogic, FieldShield gère les collections structurées, tandis que DarkShield gère les collections structurées et non structurées.
Par défaut - et la façon dont l'interface graphique IRI Workbench présente FieldShield aux utilisateurs finaux et aux administrateurs de base de données - une ou plusieurs tables complètes sont généralement sécurisées avec des fonctions de masquage des données statiques (telles que le chiffrement, la rédaction, la pseudonymisation) conformément aux règles métier. Le choix de chaque "bouclier de champ (colonne)" doit être basé sur la sécurité, le réalisme, la réversibilité et peut-être des considérations de CPU ou de stockage.
L'approche statique fonctionne bien lorsque les données sont au repos. Soit la table source peut être protégée, soit une nouvelle table cible ou un nouveau fichier avec des protections appliquées peut être créé. Les applications qui récupèrent les données protégées n'ont pas à se soucier de la sécurité car leurs sources de données ont été pré-protégées. Les programmes FieldShield conçus pour protéger les données au repos peuvent également être planifiés ou appelés dans des tâches par lots pour des mises à jour régulières.
Cependant, dans un environnement en temps réel où les lignes mises à jour nécessitent une protection dynamique, les fonctions FieldShield doivent être intégrées dans le flux de données de l'application. Il existe plusieurs approches à envisager :
1) Votre programme appelle FieldShield
La base de données et d'autres programmes qui récupèrent ou envoient des données nouvelles ou modifiées dans des tables peuvent les transmettre à une fonction d'API de chiffrement, de hachage, d'encodage ou de masquage FieldShield en C, Java ou .NET. Vous pouvez également transmettre les données en mouvement dans un programme FieldShield autonome via un canal ou une procédure d'entrée. Chacune de ces méthodes peut remplir des cibles avec des fonctions de protection (ou de révélation) au niveau de la colonne appliquées.
2) FieldShield ne protège que les mises à jour
Les programmes FieldShield peuvent également être personnalisés via les fonctions /QUERY et /UPDATE, ou pour filtrer conditionnellement uniquement les nouveaux enregistrements, où les lignes à protéger répondent à des critères spécifiques, comme la nouveauté. Les appels d'API permettraient une logique métier encore plus granulaire et faciliteraient davantage de conditions de "vitesse" (ou de latence) des données - par exemple, plus de masquage des données en temps réel - car ces besoins peuvent être exprimés via l'application et définis par sa logique. Consultez cet exemple PL/SQL de masquage en temps réel basé sur un déclencheur.
3) Capturez et protégez les deltas dans CoSort (FieldShield Parent)
Les tâches de capture de données modifiées (CDC) peuvent également être programmées dans le langage de contrôle de tri (SortCL) de CoSort, après quoi seules les insertions, les mises à jour, les suppressions ou les lignes inchangées sélectionnées peuvent être transmises aux tables ou aux fichiers avec des protections de colonne appliquées lorsque cela se produit. Les utilisateurs de CoSort ont toutes les fonctions de protection FieldShield à leur disposition, il est donc possible de masquer uniquement les données modifiées dans ce paradigme de rapport en masse.
4) Interceptions de requête basées sur un proxy
IRI fournit désormais un pilote spécial « JDBC SQL Trail » pour les applications à utiliser qui filtre les requêtes de base de données pour les utilisateurs autorisés et les tables et colonnes particulières. Ceux qui ne sont pas exemptés de la définition de la politique DDM ne verront que les valeurs entièrement ou partiellement masquées en vol vers cette application spécialement connectée à partir de la base de données, qui reste démasquée au repos.
5) Intégrations personnalisées
IRI peut travailler avec votre DBA ou votre programmeur d'application pour concevoir une solution sur mesure qui implique des éléments de ce qui précède, ou pour fournir des bibliothèques FieldShield que vos procédures SQL peuvent invoquer in situ comme celles-ci pour protéger ou révéler (chiffrer ou déchiffrer) une requête résultats, tables de requêtes, vues matérialisées, etc.
Contactez-nous pour obtenir de l'aide sur l'intégration d'une fonction de masquage dynamique des données comme la rédaction ou le chiffrement préservant le format dans votre application.
