Según Simson L. Garfinkel del Laboratorio de Tecnología de la Información de la División de Acceso a la Información del NIST,
La desidentificación no es una técnica única, sino una colección de enfoques, algoritmos y herramientas que se pueden aplicar a diferentes tipos de datos con diferentes niveles de efectividad. En general, la protección de la privacidad mejora a medida que se emplean técnicas de desidentificación más agresivas, pero queda menos utilidad en el conjunto de datos resultante.
-Desidentificación de información personal, NISTIR 8053
El enmascaramiento de datos estáticos (SDM) es el término reconocido por la industria para estos diversos medios de desidentificar elementos de datos en reposo. Los elementos suelen ser valores de columna de base de datos o de campo de archivo sin formato que se consideran confidenciales; en la industria de la salud, se les conoce como identificadores clave. Específicamente en riesgo se encuentran la información de identificación personal (PII), la información de salud protegida (PHI), los números de cuenta principales (PAN), los secretos comerciales u otros valores confidenciales.
El producto de seguridad centrado en datos de "punto de partida" IRI FieldShield, o el producto IRI CoSort y la plataforma IRI Voracity que incluyen las mismas capacidades, brindan múltiples funciones de descubrimiento de datos y SDM para múltiples fuentes de datos. Las funciones de enmascaramiento por campo/columna disponibles incluyen:
- múltiples algoritmos de cifrado (y descifrado) compatibles con NSA Suite B y FIPS, incluida la conservación de formato cifrado
- hash SHA-1 y SHA-2
- ASCII de-ID (codificación de bits)
- codificación y decodificación binaria
- difuminación o acumulación de datos (anonimización)
- generación o selección aleatoria
- redacción (ofuscación de caracteres)
- seudonimización reversible y no reversible
- lógica de expresión personalizada (cálculo/reproducción aleatoria)
- filtrado o eliminación (omisión) de valores parciales o condicionales
- reemplazo de valor personalizado
- desplazamiento de bytes y funciones de cadena
- tokenización (para PCI)
También puede "hacer rodar su propia" función de enmascaramiento de datos externos. Esto le permite llamar a una rutina de nivel de campo escrita de forma personalizada en tiempo de ejecución en lugar de una incorporada.
La pregunta sigue siendo, ¿qué función de enmascaramiento debo usar (en cada elemento)? Eso depende de las necesidades y reglas de su negocio, así como de las leyes de privacidad de datos aplicables. A nivel técnico, eso generalmente significa decidir cómo debe aparecer el texto cifrado resultante (datos enmascarados), si debe ser reversible o único, qué tan seguro es y, posiblemente, qué tipo de recursos informáticos y tiempo están disponibles para el proceso. . Veamos estos criterios de decisión comunes en detalle:
Apariencia (Realismo)
¿Los datos recién enmascarados deberían parecerse más o menos a los datos originales? ¿Qué pasa con su tamaño y formato? La seudonimización y el cifrado que conserva el formato son las dos formas más comunes de
conservar la apariencia de los nombres propios y los números de cuenta o de teléfono de dígitos alfa, respectivamente. Pero el enmascaramiento de subcadenas (a/k/a redacción de campo parcial, por ejemplo, XXX-XX-1234) puede estar bien para cosas como SSN. Piense en la persistencia y visualización de los datos para análisis, etc.
Relacionado con esto, la apariencia y el realismo del texto cifrado también pueden determinar la usabilidad de los resultados. Los destinos de la tabla de la aplicación y la base de datos (utilidad de carga) pueden requerir que el formato de los datos no solo cumpla con estructuras predefinidas, sino que continúe trabajando en consultas u otros contextos operativos posteriores.
En otras palabras, si se requieren datos enmascarados que son bonitos y/o datos funcionales, no opte por la redacción completa, la aleatorización, el hash o el cifrado directo (que amplía y ofusca los resultados). Es posible que pueda salirse con la suya con ajustes más pequeños como el envejecimiento y la manipulación de subcadenas, pero considere el impacto de estas elecciones en sus otros criterios de decisión...
Reversibilidad (Reidentificación)
¿Necesita restaurar los datos originales? La respuesta a eso puede depender de si está dejando los datos de origen solos, como lo haría en el enmascaramiento de datos dinámicos, o si está escribiendo los datos enmascarados en nuevos objetivos. En esos casos, la respuesta es no.
Si la respuesta es no, es posible que aún necesite realismo, en cuyo caso la seudonimización irreversible puede ser su mejor opción. Si es no y la apariencia no importa, vaya con la redacción de caracteres. Y si ninguno de los dos es cierto, considere la eliminación total de la columna de origen del destino.
Cuando la respuesta es afirmativa, se indican funciones de enmascaramiento de datos IRI como cifrado, seudonimización reversible o tokenización, codificación o ASCII re-ID (codificación de bits). En casos de uso más avanzados, es posible que también necesite una inversión diferencial; es decir, cuando diferentes destinatarios del mismo objetivo están autorizados a ver cosas diferentes en el mismo conjunto de datos. En tales casos, se pueden implementar claves de cifrado privadas, scripts de trabajo de revelación específicos del usuario o incluso aplicaciones personalizadas.
Singularidad (Coherencia)
¿Es necesario reemplazar siempre el mismo valor original por el mismo valor de reemplazo, pero diferente? ¿Los datos se unirán o agruparán por los valores de reemplazo? Si es así, entonces el algoritmo de reemplazo elegido debe producir resultados que sean únicos y repetibles para preservar la integridad referencial a pesar del enmascaramiento que se haya producido.
Esto se puede lograr mediante el cifrado cuando se usa el mismo algoritmo y frase de contraseña (clave) contra el mismo texto sin formato. La clasificación de datos y los asistentes de protección de tablas cruzadas en IRI Workbench IDE para FieldShield, Voracity, etc. facilitan esto a través de la aplicación de tablas cruzadas (o más global) de la regla de enmascaramiento coincidente. De esta forma, el mismo valor de texto sin formato siempre obtiene el mismo resultado de texto cifrado independientemente de su ubicación.
Sin embargo, la seudonimización es más complicada aquí debido a la escasez de nombres de reemplazo únicos, nombres originales duplicados y cambios ( inserciones, actualizaciones o eliminaciones) a los valores originales en las tablas o archivos de origen. IRI abordó el problema de la seudonimización consistente de tablas cruzadas en este ejemplo de flujo de trabajo de Voracity.
Fuerza (Seguridad)
Una mirada a los algoritmos dentro de cada función puede ayudarlo a determinar su "capacidad de craqueo" relativa y evaluarla en comparación con otras consideraciones de texto cifrado, como la apariencia y la velocidad. Por ejemplo, la función AES256 de IRI es más potente que la opción AES128, SHA2 es más potente que SHA1 y todas son más potentes que las funciones de codificación/descodificación base64 y desidentificación/reidentificación ASCII.
Por definición, las funciones reversibles suelen ser más débiles que las que no se pueden invertir. Por ejemplo, el método de seudonimización irreversible (conjunto de búsqueda en el extranjero) de IRI es más seguro que su método de seudonimización reversible (conjunto original codificado). Dicho esto, el algoritmo de cifrado AES-256 puede ser muy difícil de descifrar cuando también se ha perdido la clave.
Una seguridad aún más fuerte es, por supuesto, la omisión, seguida de la ofuscación de caracteres (redacción), que son irreversibles. Pero la desventaja es la falta de usabilidad. En el contexto de puerto seguro de HIPAA, cumple la eliminación de identificadores clave. Sin embargo, si necesita usar alguna parte de los datos de origen para análisis, investigación, marketing o demostración, necesitará una función de enmascaramiento y un experto para determinar (y certificar) que su(s) técnica(s) tiene(n) un valor estadístico bajo. probabilidad de reidentificación.
Ya que estamos en el tema de la desidentificación de HIPAA, recuerde que también puede haber un riesgo asociado con los llamados cuasi identificadores (como el código postal y la edad). Esos valores se pueden usar junto con otros conjuntos de datos para establecer un rastro de reidentificación y, por lo tanto, también vale la pena enmascararlos en muchos casos; el si y el cómo están sujetos a estas mismas consideraciones.
Cómputo (Rendimiento)
Una de las cosas buenas del enfoque de enmascaramiento de datos, incluso cuando se involucran algoritmos de cifrado intensivos en computación, es que su sobrecarga en relación con el cifrado general (de una red completa, base de datos, archivo/sistema, unidad de disco) es mucho menor. Solo los elementos de datos (valores de columna) que usted designe para protección deben incorporarse, procesarse y devolverse desde la función de enmascaramiento.
En general, cuanto más complejo (y fuerte) sea el algoritmo, más tiempo llevará aplicarlo. Las velocidades de enmascaramiento de datos también dependerán de la cantidad de funciones aplicadas, la cantidad de columnas y filas de la base de datos, la cantidad de restricciones de búsqueda a respetar en el proceso (para la integridad referencial), el ancho de banda de la red, RAM, E/S, procesos concurrentes y pronto.
El siguiente cuadro no científico desglosa la mayoría de los atributos descritos anteriormente para una referencia conveniente, para algunas (¡pero no todas!) categorías funcionales de enmascaramiento de datos IRI admitidas, y en general solo en términos relativos. ¡No hace falta decir que IRI renuncia a cualquier garantía de idoneidad o responsabilidad por este gráfico!
Funciones de enmascaramiento de datos IRI (en FieldShield y Voracity)
Ya sea que utilice funciones de enmascaramiento de datos IRI integradas o funciones personalizadas que defina, la idea es aplicarlas en función de sus reglas comerciales a filas o columnas específicas y/o en tablas. Y lo hará a través de reglas de enmascaramiento de datos que puede definir, almacenar y reutilizar. También es posible (y preferible) aplicar estas funciones de enmascaramiento de datos contra datos clasificados automáticamente como reglas por conveniencia y consistencia. Y puede aprovechar varios de ellos en aplicaciones de enmascaramiento de datos dinámicos a través de una llamada a la API.
Los usuarios de FieldShield (o Voracity) pueden crear, ejecutar y administrar sus trabajos de enmascaramiento de datos en una GUI gratuita de última generación, basada en Eclipse.™ O pueden editar y ejecutar scripts 4GL compatibles y autodocumentados que definen su datos de origen/objetivo y funciones de enmascaramiento, y ejecute esos scripts en la línea de comando.
Para obtener más información, consulte https://www.iri.com/solutions/data-masking o comuníquese con su representante de IRI.
