viernes, 29 de septiembre de 2017

Mejores prácticas de enmascaramiento de datos


Muchas organizaciones arriesgan inadvertidamente la información cuando rutinariamente copian datos de producción sensibles o regulados en entornos que no son de producción. Como resultado, los datos en el entorno de no producción se han convertido cada vez más en el blanco de los delincuentes y pueden ser robados. Al igual que las brechas de datos en entornos de producción, las violaciones de datos en entornos no productivos pueden causar millones de euros en sanciones y causar daños irreparables a la reputación y la marca.

Con Oracle Data Masking, la información sensible y valiosa puede ser reemplazada por valores realistas. Esto permite que los datos se utilicen con seguridad en no producción e incumplimiento con requisitos regulatorios como Sarbanes-Oxley, PCI DSS, HIPAA y en breve la GDPR.
Este artículo describe las mejores prácticas para implementar Oracle Data Masking para proteger la información confidencial en bases de datos Oracle y otras bases de datos heterogéneas como IBM DB2, Microsoft SQL Server.
Las empresas comparten datos de sus aplicaciones de producción con otros usuarios para una variedad de necesidades empresariales.
  • Las empresas minoristas comparten datos de puntos de venta con los investigadores de mercado para analizar los patrones de compra de los clientes.
  • Las organizaciones farmacéuticas o de salud comparten los datos de los pacientes con los investigadores médicos para evaluar la eficacia de los ensayos clínicos o los tratamientos médicos.
  • Las empresas para mantenerse competitivas requieren una funcionalidad nueva y mejorada en las aplicaciones de producción existentes. Como resultado, los desarrolladores de aplicaciones requieren un entorno que imita cerca de la producción para crear y probar la nueva funcionalidad asegurando que la funcionalidad existente no se rompa.
Como resultado de lo anterior, las organizaciones copian datos confidenciales de clientes y consumidores en entornos que no son de producción y muy pocas compañías hacen algo para proteger estos datos, incluso cuando comparten con terceros.

Enmascarar datos en entornos no productivos.

Las organizaciones han tomado estas amenazas en serio y se han propuesto abordar estas cuestiones tan pronto como sea posible conocer las ramificaciones. A pesar de esto, la idea de eliminar información sensible del entorno de no producción parece ser sencilla, pero puede plantear serios desafíos en varios aspectos.
Identificación de información confidencial.
  • ¿Qué define la información sensible?
  • ¿Dónde reside?
  • ¿Cómo se hace referencia?

El desafío también se convierte en mantener el conocimiento de metadatos de la arquitectura de la aplicación a lo largo de su ciclo de vida.
El proceso de enmascaramiento ha de ser tal que la integridad de la aplicación se vuelve primordial. Como ejemplo, enmascarar una parte de la dirección de un cliente, como zip sin considerar la ciudad y el estado, puede hacer que la aplicación sea inutilizable. Por lo tanto el desarrollo o la prueba se vuelven si no imposible, no confiable.La auditoría es otro desafío que se considera seriamente. Saber quién cambió qué y cuándo se convierte en un importante requisito de control de negocios para demostrar el cumplimiento de las regulaciones y leyes.

Para implementar estos controles, se ha de instaurar:

El desafío se convierte en separaciones de deberes, permisos basados en roles y la capacidad de reportar sobre estas actividades.

Las bases de datos se están volviendo muy grandes y la frecuencia de solicitudes para un entorno seguro no relacionado con la producción ha aumentado drásticamente a lo largo de los años. La razón de este aumento es que las empresas desarrollen aplicaciones nuevas y mejores que presten servicios a sus clientes a un ritmo más rápido para mantenerse competitivas. Un proceso de enmascaramiento debe tener un rendimiento aceptable y confiabilidad.

Y, finalmente, tener una solución flexible que puede evolucionar con la aplicación y extenderse a otras aplicaciones dentro de una empresa se convierte en un reto importante para abordar.

La solución más común: scripts de base de datos. A primera vista, una ventaja del enfoque de scripts de base de datos parecería que se refieren específicamente a las necesidades de privacidad de una base de datos específica para la que fueron diseñados. Pueden incluso haber sido ajustados por un DBA para correr en su más rápido

Veamos los problemas con este enfoque.
  • Reutilización: No hay capacidades comunes en un script que pueden ser fácilmente apalancadas en otras bases de datos.
  • Transparencia: Como los scripts tienden a ser programas monolíticos, los auditores no tienen transparencia en los procedimientos de enmascaramiento utilizados en los scripts. Los auditores encontrarían extremadamente difícil ofrecer cualquier recomendación sobre si el proceso de enmascaramiento incorporado en un guión es seguro y ofrece a la empresa el grado apropiado de protección.
  • Mantenimiento: cuando se actualizan estas aplicaciones empresariales, se pueden agregar nuevas tablas y columnas que contienen datos confidenciales como parte del proceso de actualización. Con un enfoque basado en secuencias de comandos, todo el guión tiene que ser revisado y actualizado para acomodar nuevas tablas y columnas agregadas como parte de un parche de aplicación o una actualización.

Implementación de la máscara de datos

Con estos desafíos empresariales en mente, Oracle ha desarrollado un enfoque integral de 4 pasos para implementar el enmascaramiento de datos a través de Oracle Data Masking Pack llamado: Find, Assess, Secure y Test (F.A.S.T). Estos pasos son:

  • Buscar: Esta fase implica la identificación y catalogación de datos sensibles o regulados en toda la empresa. Normalmente llevado a cabo por analistas de negocios o de seguridad, el objetivo de este ejercicio es crear una lista exhaustiva de elementos de datos confidenciales específicos de la organización y descubrir las tablas, columnas y relaciones asociadas a las bases de datos empresariales que contienen los datos confidenciales.
  • Evaluar: En esta fase, los desarrolladores o DBAs en conjunto con los analistas de negocios o de seguridad identifican los algoritmos de enmascaramiento que representan las técnicas óptimas para reemplazar los datos sensibles originales. Los desarrolladores pueden aprovechar la biblioteca de enmascaramiento existente o ampliarla con sus propias rutinas de enmascaramiento.
  • Seguro: Este y el siguiente paso pueden ser iterativos. El administrador de seguridad ejecuta el proceso de enmascaramiento para proteger los datos confidenciales durante las pruebas de enmascaramiento. Una vez que el proceso de enmascaramiento ha finalizado y se ha verificado, el DBA entrega el entorno a los probadores de aplicaciones.
  • Prueba: En el paso final, los usuarios de producción ejecutan procesos de aplicación para probar si los datos enmascarados resultantes pueden ser entregados a otros usuarios que no producen. Si las rutinas de enmascaramiento necesitan ser ajustadas aún más, el DBA restaura la base de datos al estado pre-enmascarado, corrige los algoritmos de enmascaramiento y vuelve a ejecutar el proceso de enmascaramiento.