Una guía completa sobre protección de información confidencial en el IBM i (AS/400 – iSeries) por medio de métodos de tokenización, cifrado (encriptación) y anonimización de datos. Útil para empresas que necesitan conocer estrategias de protección de datos y evaluar cuál de los 3 métodos es mejor para su operación.
A lo largo de los años, las estrategias para explotar brechas de seguridad y violar información confidencial se han vuelto más complicadas de evitar. Por otro lado, los requisitos para el cumplimiento de regulaciones de seguridad siguen evolucionando y exigiendo más complejidad a nuestras estrategias de seguridad en e IBM i.
Sin duda, es fundamental contar con soluciones de seguridad sofisticadas para evitar ser víctimas de ciberataques, así como para el cumplimiento de regulaciones. Sin embargo, constantemente se pierde de vista la estrategia de seguridad, y la estrategia no es lo mismo que la solución.
Hay diferentes métodos con los que podemos proteger nuestros datos, algunos pueden ser más efectivos que otros y todo dependerá de la operación de nuestro negocio. Al final, nadie conoce más la operación de nuestra empresa que nosotros mismos que estamos ahí en el día a día. Algunas operaciones tienen más actividad en su IBM i por staff interno, algunas otras por clientes o proveedores. Las variables son innumerables.
Para el caso de protección de datos, existen principalmente 3 estrategias que añaden una capa de seguridad infalible a nuestra información: tokenización, cifrado y anonimización. Las 3 pueden parecer lo mismo pero no lo son, conocerlas y entender sus diferencias es fundamental para determinar nuestra estrategia de protección de datos.
El método de cifrado de información es el enfoque más tradicional y típico en las estrategias de protección de datos en el IBM i o cualquier sistema. Todos estamos familiarizados incluso con aplicaciones personales, como la de nuestro banco, en el que la información se muestra algo así: “Tarjeta: **** **** **** 3759”. Esto significa que la información encriptada elimina los riesgos de exposición accidental de información sensible por parte de usuarios, y además le quita el valor a los datos en caso de que sean robados por algún ataque de malware.
Esa información en asteriscos no puede ser consultada por usuarios finales de la aplicación, ni por empleados de la compañía hasta un cierto nivel, y descifrarlos (o desencriptarlos) requiere de algoritmos especiales y datos secretos conocidos como llaves o claves. Los datos cifrados no le sirven a nadie si no se tiene la capacidad de descifrarlos. Lo importante que hay que entender sobre el cifrado es que consta de dos elementos fundamentales: algoritmos y claves.
El cifrado se puede usar para proteger datos en reposo (at rest) o datos en movimiento (at motion). Los datos en reposo en IBM i que son candidatos para el cifrado incluyen cualquier tipo de dato confidencial, ya sea que esos datos residan en campos específicos dentro de un archivo de base de datos, en bases de datos enteras, en archivos de guardado (save files), en archivos en cola o en cintas de respaldo.
Los datos en movimiento se refieren a los datos que se transfieren a través de una red de un sistema a otro (interno o externo). Esto puede hacerse mediante SFTP (Protocolo seguro de transferencia de archivos SSH), FTPS (FTP sobre SSL), Telnet cifrado o HTTPS.
Independientemente de si los datos deben cifrarse en reposo o en movimiento, necesitarás una solución que proporcione el tipo específico de cifrado que requieres. La solución debe incluir la implementación de un algoritmo de cifrado aprobado, como Advanced Encryption Standard (AES), la generación de claves (o llaves) fuertes de cifrado, así como una sofisticada gestión y protección de las claves.
Es importante mencionar que los algoritmos y la gestión de claves cumpla con el National Institute of Standards and Technology (NIST). Este instituto es de E.U.A., pero sin importar el país en donde te encuentres, es un buen marco de referencia ya que se garantiza que los algoritmos empleados están constantemente actualizados para no ser víctimas de hackeos y nuevas técnicas de ciberataques.
Las 2 desventajas de mayor peso de cifrar datos en el IBM i es que tiene impacto en el rendimiento de nuestros equipos ya que, al agregar una capa extra a los datos, el uso de CPU para consultar esos datos es mayor. Por otro lado, al cifrar información los campos pierden su naturaleza, lo que puede afectar a los equipos de desarrollo. Por ejemplo, si se cifra algún número, ese campo pierde su naturaleza como valor numérico, lo que puede afectar nuestros desarrollos.
| Ventajas | Desventajas |
| Tecnología madura con altos estándares de seguridad. | Afecta el performance de los equipos ya que se agrega una capa extra a los datos. |
| Cumple con requisitos establecidos por regulaciones como PCI DSS, HIPAA y más. | Puede impactar negativamente los desarrollos nativos en el IBM i. |
| Protección de datos a diferentes niveles, desde usuarios finales hasta administradores. | Una mala gestión de llaves puede poner en riesgo toda la información. |
Aquí te compartimos un artículo con aspectos relevantes que debes considerar antes de la implementación de una estrategias de cifrado. Cifrar información en el IBM i tiene elementos que pueden afectar la operación de los usuarios si no se hace correctamente, así como mermar el rendimiento de tus equipos POWER:
Un enfoque diferente para proteger información confidencial, es por medio del remplazo sustancial de los datos con valores diferentes a los reales llamados “tokens”. Se utiliza constantemente para remplazar información real de datos como tarjetas de crédito, números de cuenta, y otros datos personales. Para el caso de tokenización, en lugar de ver el dato con asteríscos (o bloqueado con otro símbolo similar), veremos el dato como debe ser, pero con valores falsos.
La información tokenizada es más difícil de identificar por parte de los cibercriminales, en el extremo caso de que se roben información, se estarían llevando información falsa sin saberlo.
Todo esto ocurriendo principalmente en sistemas y bases de datos productivas. La tokenización no funciona por medio de algoritmos ni claves, funciona por medio del almacenamiento de un ‘baúl’ de datos reales que se asegura y encripta en un sistema externo. De esta forma, se protege al 100% la información en producción, ya que si se roban la información no existe manera de ‘crackearla’ ya que no hay algoritmos ni llaves que descifrar para obtener los valores reales.
No tener información confidencial real en los sistemas productivos ayuda considerablemente a cumplir regulaciones de seguridad. Como la información sensible no se encuentra en sistemas productivos, no es necesario someterlo a requisitos estrictos para cumplir con regulaciones.
Cuando la información real necesita ser consultada o retribuida, la soluciones de seguridad como Assure Encryption pueden enmascarar una porción de los valores con asteriscos o ‘X’ dependiendo los privilegios del usuario que los consulte. La solución también mantiene una gestión sencilla y segura entre la información tokenizada y el baúl donde se respalda de forma segura la información real.
Además de la protección de información en sistemas productivos, la tokenización también puede ser utilizada en ambientes de pruebas, desarrollo, buisness inteligence, y otros entornos no productivos. Principalmente porque los datos mantienen su formato y naturaleza. Sin embargo, en estos ambientes internos a la compañía se recomienda mejor utilizar anonimización, y a más adelante veremos por qué.
Una de las desventajas a considerar de la tokenización, es que el impacto en recursos de computo de nuestros equipos POWER es aún mayor que en el caso del cifrado de datos. Esto ocurre porque son más los recursos necesarios para mantener y gestionar la relación entre los tokens y los datos reales en el baúl de seguridad.
| Ventajas | Desventajas |
Los tokens no mantienen relación con algoritmos, por lo que son ‘inhackeables’. | No cuenta con el mismo prestigio y reconocimiento por regulaciones a comparación del cifrado. |
| La información confidencial no se almacena en sistemas productivos. | El impacto en el uso de CPU es mayor ya que se requiere más recursos para mantener la relación entre los tokens y la información real en el baúl de seguridad. |
| La necesidad y riesgo de gestionar llaves de cifrado se elimina. |
Existen circunstancias en las que las compañías pueden remplazar la información real de forma permanente. Por supuesto, únicamente en sistemas como pruebas, desarrollo o control de calidad (QA); sacando de la ecuación la información en sistemas productivos. Para estos casos la mejor opción es la anonimización de datos.
La anonimización simplemente sustituye la información real por datos falsos que no tienen valor. Por ejemplo, un campo de tarjetas de crédito mantiene su naturaleza en cuanto a que sea un valor numérico, pero los datos serían remplazados por otros totalmente falsos. Es similar a la tokenización, pero la gran diferencia es que una vez anonimizados los datos, ya no hay forma de recuperar la información real. Es por tal motivo que la anonimización no suele utilizarse en sistemas productivos.
El hecho de remplazar información de forma permanente hace sentido ya que las brechas de seguridad pueden existir en todos los sistemas y a todos los niveles. La información puede estar en riesgo tanto en elementos internos como externos; así como la información puede ser robada por ataques de malware, también puede ser robada o expuesta accidentalmente por personal interno de la compañía.
Las empresas suelen dedicar menos esfuerzos de seguridad a sistemas internos que a los externos, es normal que las medidas de seguridad estén implementadas únicamente en sistemas productivos y no en otros como desarrollo, QA y demás. Sin embargo, la información almacenada en los sistemas internos también puede ser víctima de hackeos.
Un ejemplo muy claro son los equipos de desarrollo, ya que para poder desarrollar aplicaciones necesitan tener acceso a la información, bases de datos, archivos confidenciales y demás. La información estaría totalmente expuesta para los equipos de desarrollo si no se cifra, tokeniza o anonimiza. El problema es que si la información se cifra, los datos estarían perdiendo sus atributos, lo que imposibilitaría su manejo por parte de los equipos de desarrollo. Lo que nos deja con las opciones de tokenización o anonimización.
En cuanto a la tokenización, el inconveniente sería que los recursos de computo utilizados serían mayores. Y por lo general los sistemas de desarrollo o QA tienen menos poder de cómputo que los sistemas productivos, a menos que se desee elevar los recursos de estos equipos pero realmente no es la mejor opción. Lo ideal es anonimizar la información, para que los equipos de desarrollo y operaciones de los sistemas internos puedan trabajar sin afectaciones, eliminando por completo el riesgo de robo de información en estos sistemas.
| Ventajas | Desventajas |
| Los datos anonimizados correctamente no mantienen relación con los datos reales, por lo que son ‘inhackeables’. | No se recomienda utilizar en sistemas productivos. |
| No impacta en el rendimiento de los sistemas en los que se anonimiza. | No cumple con ninguna regulación que requiera protección de datos en sistemas productivos. |
| Los datos mantienen su naturaleza para poder ser utilizados por equipos internos. |
Si quieres saber más sobre anonimización, te recomendamos este webinar:
En TIMWare contamos con soluciones para poder cifrar, tokenizar o anonimizar datos.
Podemos ayudarte a determinar cuál es la mejor opción de acuerdo a lo que necesitas y acompañarte en el proceso de implementación de las estrategias de seguridad. Contamos con más de 30 años de experiencia en operaciones IBM i (anteriomente AS400 – iSeries). Solicita una consultaría sin costo aquí.
