El problema del pañuelo con el cifrado

Cuando hablamos con los clientes sobre seguridad, a menudo escuchamos el requisito de «más cifrado». Lo cual tiene sentido, ¿no? Después de todo, con los algoritmos de encriptación de hoy en día, cualquiera que sea capaz de robar datos encriptados realmente no puede hacer nada con ellos sin preguntarle a una supercomputadora, que luego estaría ocupada descifrando durante los próximos 7 millones de años (solo para llegar a la respuesta «42 ”). Bueno, desafortunadamente no es tan fácil.

Y cuando digo que el cifrado no es fácil, ni siquiera me refiero a las diferencias entre el cifrado asimétrico y el simétrico o los diferentes tipos de algoritmos de cifrado (hablaremos de ellos en futuras publicaciones). Ni siquiera entraré en los detalles de las diferentes capas donde el cifrado es importante. Más bien, para los fines de este artículo, me gustaría ver el cifrado desde la perspectiva de la aplicación.

En primer lugar, es importante comprender que, como es comprensible, a los proveedores les gusta promocionar su solución como si tuviera un cifrado superior. La realidad es bastante diferente, sin embargo. Una razón para esto es la estandarización del cifrado, una segunda razón se puede encontrar dentro de la naturaleza de la arquitectura de aplicaciones actual y la tercera razón ni siquiera tiene que ver con el cifrado o incluso con la tecnología.

La primera razón se cubre rápidamente: cualquier solución tecnológica hoy en día no existe en el vacío. Por el contrario, en un mundo altamente conectado, las soluciones deben poder comunicarse, incluso cuando se trata de datos cifrados. Por lo tanto, la mayor parte del cifrado está estandarizado y presionado en acrónimos de tres letras, como TLS, SSL o AES.

En segundo lugar, ver el cifrado desde la perspectiva de la aplicación: obviamente sería mejor si la aplicación pudiera procesar datos incluso cuando está cifrado y solo los valores descifrados se mostrarían en la interfaz de usuario (cifrado del lado de la interfaz de usuario). Dicho de otra manera: sería genial que la aplicación supiera que

PQPM7aCOxurcuhlI7Exdjw==

multiplicado con

BrDwPV2s6Xri6jndOt4NYg==

es igual

O0HrSmCSBNW6ugKA7N2ZMg==

¿Ya ves el problema? Cualquier aplicación sabe que 6 x 7 = 42: el mismo ejemplo que usé anteriormente, pero encriptado. Sin embargo, para poder realizar este cálculo, la aplicación necesita conocer la clave con la que se encriptó el texto sin formato.

Nota al margen: en teoría, esto es incluso posible sin que la aplicación conozca la clave. El término para esto es «cifrado homomórfico», pero está a años luz de ser comercialmente viable.

En otras palabras: la aplicación, en algún momento, necesita cifrar los datos y, para hacerlo, requiere la clave de cifrado. Hasta aquí la teoría, ahora veamos qué significa esto en una arquitectura de solución típica actual.

La verdadera pregunta que los clientes deben hacerse es: ¿De quién quieren protegerse y cómo recuperan sus valiosos datos los malos actores o quiénes son estos malos actores de todos modos? Algunos ejemplos:

• Si implementa el cifrado del sistema de archivos y el volumen de la base de datos (a menudo denominado «cifrado de datos transparente» o TDE), está protegiéndose contra el administrador de la infraestructura (es decir, no podrán ver los datos en texto sin formato). Sin embargo, el administrador de la base de datos o el administrador de la aplicación aún podrán ver los datos.
• Si desea evitar que el administrador de la base de datos vea los datos, deberá implementar el cifrado del lado de la aplicación. Esto encripta los datos dentro de la base de datos pero es transparente para la aplicación. En otras palabras, dependiendo de sus derechos de acceso, los usuarios de la aplicación aún podrían ver los datos.
• Si desea asegurarse absolutamente de que el administrador de la aplicación tampoco vea ningún dato, deberá recurrir al cifrado del lado de la interfaz de usuario que mencioné anteriormente, que, sin embargo, hace que el procesamiento de datos sea imposible.

Y ahora finalmente estamos llegando al meollo del asunto.

El cifrado del lado de la aplicación significa que los datos cifrados se envían a la aplicación y permanecerán cifrados hasta que la aplicación realmente use los datos. Si se utilizan los datos, la aplicación los descifrará, procesará y volverá a cifrar después de su uso. Este proceso particular, simplificado, requiere dos cosas:

1. La base de datos debe soportarlo.
2. La aplicación necesita (una función) para soportarla.

Las bases de datos modernas, como SQL Server, Oracle Database o SAP HANA brindan este soporte, y si tuviera que escribir una nueva aplicación sobre cualquiera de estas bases de datos, también puede implementar este soporte en el lado de la aplicación.

Sin embargo, las aplicaciones complejas (MS Dynamics, Oracle ERP y también SAP ERP) que existían antes de que las bases de datos admitieran ese tipo de cifrado no admiten el cifrado del lado de la aplicación.

¿Es posible implementar tal función en una aplicación «envejecida»? Seguro que lo es, pero es simplemente demasiado esfuerzo: estas aplicaciones complejas contienen millones de líneas de códigos, con una cantidad similar de dependencias dentro del código, por lo que probablemente llevaría años, incluso para corporaciones del tamaño de Microsoft, Oracle o SAP. para implementar el cifrado completo del lado de la aplicación.

Sin embargo, a veces escucha la frase «Microsoft (u Oracle) pueden proporcionar este nivel de cifrado». Y puede que te sorprenda que vea esta frase como cierta, lo que nos lleva a la tercera razón, que no es de naturaleza tecnológica sino semántica. Por ejemplo: si me preguntan “puedes pasarme un Kleenex, por favor”, y te doy un pañal, te sorprenderás, porque “Kleenex” se ha convertido en sinónimo de pañuelo. La empresa detrás de Kleenex, sin embargo, también produce pañales. El mismo escenario se aplica aquí: si (al menos en un contexto empresarial) alguien se refiere a «Oracle», se está refiriendo al producto de base de datos de Oracle en la mayoría de los casos. Por otro lado, cuando alguien dice «SAP» se refiere a la aplicación; lo que es peor, la mayoría de las veces cuando alguien menciona «HANA», la mayoría de las veces se refiere a la aplicación «SAP S/4HANA» en lugar de la base de datos.

Sin embargo, si compara manzanas con manzanas y naranjas con naranjas, necesitará comparar las bases de datos entre sí y las aplicaciones comerciales entre sí. El resultado se puede ver en la siguiente tabla:

Capacidades de cifrado de proveedores y soluciones seleccionados

Como puede ver, en objeción cercana, casi no hay diferencias entre los diferentes productos, al menos en lo que respecta al cifrado.

La moraleja de la historia es simple: no pida «más encriptación», sino pregúntese primero contra quién quiere protegerse. Y si se enfrenta a afirmaciones sobre las posibilidades de encriptación de soluciones específicas, asegúrese de no comparar manzanas con naranjas.

En general, la seguridad debe abordarse de manera integral. El cifrado puede ser parte de la solución, pero no es una panacea. En muchos contextos, las autorizaciones, registros y auditorías adecuados son más efectivos y apropiados.