A medida que el mundo se vuelve cada vez más impulsado por los datos, el manejo seguro de los datos de los usuarios es más crítico que nunca.
Como desarrolladores, nuestro trabajo ya es lo suficientemente difícil: lidiar con sistemas altamente complejos y frágiles con múltiples puntos de falla mientras traducimos los deseos humanos en interfaces de usuario y backends. A la tarea se suma una consideración emergente y esencial: la seguridad de los datos. Y por una buena razón: nosotros, como clientes, nos enfadamos si nuestros datos se utilizan indebidamente (por lo que es justo que brindemos a nuestros usuarios una experiencia segura y agradable), y los gobiernos y las empresas lo exigen para su cumplimiento.
Tabla de contenido
La seguridad de los datos como pasar la pelota
Lo que hace que la seguridad sea más difícil es que tiene varias capas y se convierte en responsabilidad de todos. En un equipo de nube moderno, varios equipos controlan directamente la entrada/salida de datos: desarrolladores, administradores de bases de datos, administradores de sistemas (gente de DevOps, por así decirlo), usuarios administrativos privilegiados, etc. Estos roles/equipos pueden cerrar rápidamente los ojos y pensar en la seguridad de los datos como un problema de los demás. Aún así, la realidad es que tienen sus propios mundos de los que ocuparse, ya que un administrador de la base de datos no puede controlar el lado de la seguridad de la aplicación, una persona de DevOps no puede hacer absolutamente nada con respecto al acceso al back office, etc.
Desarrolladores y seguridad de datos
Dicho todo esto, los desarrolladores tienen la mayor superficie de acceso cuando se trata de datos: construyen cada parte de la aplicación; se conectan a varios servicios de back-end; los tokens de acceso al ferry de ida y vuelta; tienen todo el clúster de la base de datos para leer/escribir a sus órdenes; las aplicaciones que escriben tienen acceso incuestionable a todas las partes del sistema (por ejemplo, una aplicación de Django en producción tiene todos los privilegios para volcar o borrar toda la colección S3 de los últimos diez años), y así sucesivamente. Como resultado, la mayor posibilidad de descuido o descuido en términos de seguridad existe en el nivel del código fuente y es responsabilidad directa del desarrollador.
Ahora, la seguridad de los datos es una madriguera de conejo sin fondo, y no hay forma de que pueda rascar la superficie en una sola publicación. Sin embargo, quiero cubrir la terminología esencial que los desarrolladores deben conocer para mantener sus aplicaciones seguras. Piense en ello como App Data Security 101.
¡Empecemos!
hash
Si desea una definición muy rigurosa, siempre hay Wikipedia, pero en términos simples, hashing es el proceso de convertir datos a otra forma, donde la información es ilegible. Por ejemplo, utilizando el conocido (y muy inseguro) proceso de Codificación Base64, la cadena «¿Está mi secreto a salvo contigo?» se puede convertir («hash») a «SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/». Si comienza a escribir su diario personal en formato Base64, por ejemplo, ¡no hay forma de que su familia pueda leer sus secretos (a menos que sepan cómo decodificar de Base64)!
Esta idea de codificar los datos se usa cuando se almacenan contraseñas, números de tarjetas de crédito, etc., en aplicaciones web (de hecho, debería usarse en todo tipo de aplicaciones). La idea, por supuesto, es que en el caso de una violación de datos, el atacante no debería poder usar las contraseñas, números de tarjetas de crédito, etc., para causar daños reales. Se utilizan algoritmos altamente robustos y sofisticados para realizar este hashing; algo como Base64 será una broma y cualquier atacante lo romperá instantáneamente.
El hashing de contraseñas utiliza una técnica criptográfica conocida como hash unidireccional, lo que significa que, si bien es posible cifrar los datos, no es posible descifrarlos. Entonces, ¿cómo sabe la aplicación que es tu contraseña cuando inicias sesión? Bueno, utiliza el mismo proceso y compara la forma codificada de lo que acaba de ingresar como contraseña con la forma codificada almacenada en la base de datos; si coinciden, ¡puede iniciar sesión!
Ya que estamos en el tema de los hashes, aquí hay algo interesante. Si alguna vez descarga software o archivos de Internet, es posible que le hayan dicho que verifique los archivos antes de usarlos. Por ejemplo, si desea descargar Ubuntu Linux ISO, la página de descarga le mostrará una opción para verificar su descarga; si hace clic en él, se abrirá una ventana emergente:
La ventana emergente le dice que ejecute un comando, que esencialmente va a codificar todo el archivo que acaba de descargar y comparar el resultado con la cadena hash que ve en la página de descarga: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Esta conversión se realiza mediante el Algoritmo SHA256cuya mención se puede ver en las partes finales del comando: shasum -a 256 –check.
La idea es que si el hash producido a través de su verificación es diferente, esto significa que alguien se ha entrometido con su descarga y le ha proporcionado un archivo comprometido.
Algunos nombres familiares que escuchará en el dominio del hashing de contraseñas son MD5 (inseguro y ahora desaparecido), SHA-1 y SHA-2 (familias de algoritmos, de las cuales SHA-256 es miembro, al igual que SHA-512), SCRIPT, BCRYPT, etc.
Salazón
Todos los tipos de seguridad son un juego del gato y el ratón: el ladrón aprende el sistema actual y se le ocurre una grieta novedosa, que se nota, y los fabricantes de cerraduras mejoran su juego, y así sucesivamente. La criptografía no es una excepción. Si bien convertir hashes nuevamente en contraseñas se ha vuelto imposible, los atacantes han desarrollado técnicas sofisticadas que combinan conjeturas inteligentes con pura potencia de cálculo; como resultado, nueve veces diez, pueden predecir la contraseña correcta, dado solo el hash.
«Señor. ¡¿Rumpelstiltskin, supongo?!”
Como resultado, se ha desarrollado la técnica de la salazón. Todo lo que significa es que el cálculo hash de una contraseña (o cualquier dato) se realizará en función de una combinación de dos cosas: los datos en sí, así como una nueva cadena aleatoria que el atacante no puede adivinar. Entonces, con salado, si queremos codificar la contraseña superman009, primero seleccionaríamos una cadena aleatoria como «sal», digamos, bCQC6Z2LlbAsqj77 y luego realizaríamos el cálculo de hash en superman009-bCQC6Z2LlbAsqj77. El hash resultante se desviará de las estructuras habituales producidas por el algoritmo, lo que reducirá enormemente el alcance de la ingeniería inversa inteligente o las conjeturas.
Tanto Hashing como Salting son dominios increíblemente complicados y evolucionan constantemente. Entonces, como desarrollador de aplicaciones, nunca tratamos directamente con ellos. Pero nos ayudaría mucho si supiéramos esto y pudiéramos tomar mejores decisiones. Por ejemplo, si mantiene un marco PHP antiguo y ve que usa hashes MD5 para las contraseñas, sabe que es hora de insertar otra biblioteca de contraseñas en el proceso de creación de la cuenta de usuario.
Llaves
Encontrará el término «claves» a menudo en el contexto del cifrado. Hasta ahora, hemos estado cubriendo el hash de contraseñas o el cifrado unidireccional, donde convertimos los datos de manera irreversible y destruimos la forma original. Esta es una mala idea para el uso práctico diario: ¡un documento escrito y enviado por correo electrónico de manera tan segura que nunca se puede leer no sirve de nada! Por lo tanto, queremos encriptar los datos de modo que queramos que la información esté abierta con el remitente y el receptor, pero mientras se transfiere o mientras se almacena, debe ser ilegible.
Para ello existe en criptografía el concepto de “clave”. Es exactamente lo que parece: la llave de una cerradura. La persona que posee la información la codifica utilizando un secreto llamado clave. A menos que el receptor/atacante tenga esta clave, es imposible descifrar los datos, sin importar cuán sofisticados puedan ser sus algoritmos.
Teclas giratorias
Si bien las claves hacen que el cifrado sea posible y confiable, conllevan los riesgos que conllevan las contraseñas: una vez que alguien conoce la clave, todo el juego termina. Imagine un escenario en el que alguien piratea alguna parte de un servicio como GitHub (aunque sea por unos segundos) y puede obtener un código de 20 años. Dentro del código, también encuentran las claves criptográficas utilizadas para cifrar los datos de la empresa (práctica horrible para almacenar claves junto con el código fuente, ¡pero te sorprendería la frecuencia con la que esto sucede!). Si la empresa no se ha molestado en cambiar sus claves (al igual que las contraseñas), la misma clave puede usarse para causar estragos.
Como resultado, la práctica de cambiar las claves con frecuencia ha evolucionado. Esto se denomina rotación de claves y, si utiliza un proveedor respetable de PaaS en la nube, debería estar disponible como un servicio automatizado.
Crédito de la imagen: AWS
Por ejemplo, AWS tiene un servicio dedicado para esto llamado Servicio de administración de claves de AWS (KMS). Un servicio automatizado le ahorra la molestia de cambiar y distribuir claves entre todos los servidores y es una obviedad en estos días cuando se trata de grandes implementaciones.
Criptografía de clave pública
Si toda la charla anterior sobre el cifrado y las claves le hace pensar que es muy engorroso, tiene razón. Mantener las claves seguras y pasarlas para que solo el receptor pueda ver los datos se topa con problemas logísticos que no habrían permitido que prosperaran las comunicaciones seguras de hoy. Pero todo gracias a la criptografía de clave pública, podemos comunicarnos o realizar compras en línea de forma segura.
Este tipo de criptografía fue un gran avance matemático y es la única razón por la que Internet no se está desmoronando por el miedo y la desconfianza. los detalles del algoritmo son intrincados y altamente matemáticos, por lo que solo puedo explicarlo conceptualmente aquí.
Crédito de la imagen: Fundación Frontera Electrónica
La criptografía de clave pública se basa en el uso de dos claves para procesar la información. Una de las claves se llama Clave privada y se supone que debe permanecer privada contigo y nunca compartirse con nadie; el otro se llama Public Key (de donde proviene el nombre del método) y se supone que debe publicarse públicamente. Si le estoy enviando datos, primero necesito obtener su clave pública, cifrar los datos y enviárselos; por su parte, puede descifrar los datos utilizando su combinación de clave privada y clave pública. Mientras no revele accidentalmente su clave privada, puedo enviarle datos encriptados que solo usted puede abrir.
La belleza del sistema es que no necesito saber tu clave privada, y cualquiera que intercepte el mensaje no puede hacer nada para leerlo aunque tenga tu clave pública. Si se pregunta cómo es esto posible, la respuesta más corta y menos técnica proviene de las propiedades de la multiplicación de números primos:
Es difícil para las computadoras factorizar números primos grandes. Por lo tanto, si la clave original es muy grande, puede estar seguro de que el mensaje no se podrá descifrar ni siquiera en miles de años.
Seguridad de la capa de transporte (TLS)
Ahora sabe cómo funciona la criptografía de clave pública. Este mecanismo (conocer la clave pública del receptor y enviarle datos encriptados usando eso) es lo que está detrás de toda la popularidad de HTTPS y es lo que hace que Chrome diga: «Este sitio es seguro». Lo que sucede es que el servidor y el navegador cifran el tráfico HTTP (recuerde, las páginas web son cadenas de texto muy largas que los navegadores pueden interpretar) con las claves públicas del otro, lo que da como resultado HTTP seguro (HTTPS).
Crédito de la imagen: Mozilla Es interesante notar que el cifrado no ocurre en la capa de transporte como tal; la modelo OSI no dice nada sobre el cifrado de datos. Es solo que la aplicación (en este caso, el navegador) cifra los datos antes de entregarlos a la capa de transporte, que luego los deja en su destino, donde se descifran. Sin embargo, el proceso involucra la capa de transporte y, al final del día, todo da como resultado un transporte seguro de datos, por lo que el término vago «seguridad de la capa de transporte» se ha mantenido.
Incluso puede encontrar el término Capa de conexión segura (SSL) en algunos casos. Es el mismo concepto que TLS, excepto que SSL se originó mucho antes y ahora se canceló a favor de TLS.
Cifrado de disco completo
A veces las necesidades de seguridad son tan intensas que nada puede dejarse al azar. Por ejemplo, los servidores gubernamentales donde se almacenan todos los datos biométricos de un país no se pueden aprovisionar y ejecutar como servidores de aplicaciones normales, ya que el riesgo es demasiado alto. No es suficiente para estas necesidades que los datos estén encriptados solo cuando se transfieren; también debe cifrarse cuando está en reposo. Para esto, se utiliza el cifrado de disco completo para cifrar la totalidad de un disco duro para garantizar que los datos estén seguros incluso cuando se violan físicamente.
Es importante tener en cuenta que Full Disk Encryption debe realizarse a nivel de hardware. Eso es así porque si encriptamos todo el disco, el sistema operativo también está encriptado y no puede ejecutarse cuando se inicia la máquina. Por lo tanto, el hardware debe comprender que el contenido del disco está encriptado y debe realizar el descifrado sobre la marcha a medida que pasa los bloques de disco solicitados al sistema operativo. Debido a este trabajo adicional que se realiza, Full Disk Encryption da como resultado lecturas/escrituras más lentas, lo que los desarrolladores de dichos sistemas deben tener en cuenta.
Encriptado de fin a fin
Con las continuas pesadillas de privacidad y seguridad de las grandes redes sociales en estos días, nadie ignora el término «cifrado de extremo a extremo», incluso si no tienen nada que ver con la creación o el mantenimiento de aplicaciones.
Anteriormente vimos cómo Full Disk Encryption proporciona la mejor estrategia a prueba de balas, pero para el usuario cotidiano, no es conveniente. Quiero decir, imagina que Facebook quiere que los datos del teléfono que genera y almacena en tu teléfono sean seguros, pero no puede tener acceso a encriptar todo tu teléfono y bloquear todo lo demás en el proceso.
Por esta razón, estas empresas han comenzado el cifrado de extremo a extremo, lo que significa que los datos se cifran cuando la aplicación los crea, almacena o transfiere. En otras palabras, incluso cuando los datos llegan al destinatario, están completamente encriptados y solo se puede acceder a ellos desde el teléfono del destinatario.
Crédito de la imagen: Google
Tenga en cuenta que el cifrado de extremo a extremo (E2E) no tiene ninguna garantía matemática como lo hace la criptografía de clave pública; es solo un cifrado estándar donde la clave se almacena con la empresa, y sus mensajes son tan seguros como la empresa decide.
Conclusión 👩🏫
Es probable que ya haya oído hablar de la mayoría de estos términos. Tal vez incluso todos ellos. Si es así, lo animo a revisar su comprensión de estos conceptos, así como a realizar una evaluación de qué tan en serio los toma. Recuerde, la seguridad de los datos de las aplicaciones es una guerra que necesita ganar cada vez (y no solo una vez), ya que incluso una sola infracción es suficiente para destruir industrias enteras, carreras e incluso vidas.