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.
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.
No hay comentarios:
Publicar un comentario
Por favor deja tu comentario, es valioso.