A medida que el mundo se basa cada vez más en 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 cambiantes en interfaces de usuario y backends. Agregar a la tarea es una consideración emergente y esencial: seguridad de datos. Y por una buena razón: nosotros, como clientes, nos enfurecemos si nuestros datos se utilizan de forma indebida (por lo que es justo que demos a nuestros usuarios una experiencia segura y agradable), y los gobiernos y las empresas lo exigen por cumplimiento.
La seguridad de los datos como paso de la pelota
Lo que dificulta la seguridad es que tiene varias capas y se convierte en una cuestión de responsabilidad de todos, responsabilidad de nadie. 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 privilegiados de back-office, etc. Estos roles / equipos pueden cerrar los ojos rápidamente 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 cuidar, ya que un administrador de base de datos no puede controlar el lado de la seguridad de la aplicación, un DevOps La persona no puede hacer absolutamente nada sobre el acceso a la oficina administrativa, y así sucesivamente.
Desarrolladores y seguridad de datos
Dicho todo esto, los desarrolladores tienen la mayor superficie de acceso cuando se trata de datos: crean cada parte de la aplicación; se conectan a varios servicios de backend; las fichas de acceso al ferry de ida y vuelta; tienen todo el clúster de la base de datos para leer / escribir a su disposición; las aplicaciones que escriben tienen acceso incuestionable a todas las partes del sistema (por ejemplo, una aplicación Django en producción tiene todos los privilegios para volcar o borrar toda la colección de S3 de los últimos diez años), y así sucesivamente. Como resultado, la mayor probabilidad 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 un agujero de conejo sin fondo, y no hay forma de que pueda ni siquiera arañar 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.
¡Vamos a empezar!
Hashing
Si desea una definición muy rigurosa, siempre hay Wikipedia , pero en términos simples, hash 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 "¿Mi secreto está 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 sepa cómo decodificar desde Base64)!
Esta idea de codificar los datos se usa al almacenar contraseñas, números de tarjetas de crédito, etc., en aplicaciones web (en realidad, 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 hash; algo como Base64 será una broma y se romperá instantáneamente por cualquier agresor.
El hash de contraseña utiliza una técnica criptográfica conocida como hash unidireccional, lo que significa que si bien es posible codificar los datos, no es posible descifrarlos. Entonces, ¿cómo sabe la aplicación que es su contraseña cuando inicia 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, ¡puedes iniciar sesión!
Ya que estamos en el tema de los hash, aquí hay algo interesante. Si alguna vez descarga software o archivos de Internet, es posible que le hayan indicado que verifique los archivos antes de usarlos. Por ejemplo, si desea descargar el Ubuntu ISO de Linux, 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 hacer un hash de todo el archivo que acaba de descargar y comparar el resultado con la cadena de hash que ve en la página de descarga: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Esta conversión se realiza utilizando el Algoritmo SHA256, cuya 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 cheque 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 hash de contraseñas son MD5 (inseguro y ahora desaparecido), SHA-1 y SHA-2 (familias de algoritmos, de los cuales SHA-256 es miembro, al igual que SHA-512), SCRYPT, BCRYPT, etc.
Salting
Todo tipo de seguridad es un juego del gato y el ratón: el ladrón aprende el sistema actual y crea 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 la conversión de hash a contraseñas se ha vuelto imposible, los atacantes con el tiempo han desarrollado técnicas sofisticadas que combinan conjeturas inteligentes con puro poder de cálculo; como resultado, nueve de cada diez veces, pueden predecir la contraseña correcta, solo con el hash.
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 base a una combinación de dos cosas: los datos en sí, así como una nueva cadena aleatoria que el atacante no puede adivinar. Entonces, con la salazón, si queremos hash la contraseña superman009, primero seleccionaríamos una cadena aleatoria como "sal", por ejemplo, bCQC6Z2LlbAsqj77y luego realizar el cálculo hash en superman009-bCQC6Z2LlbAsqj77. El hash resultante se desviará de las estructuras habituales producidas por el algoritmo, reduciendo enormemente el alcance de la inteligencia. ingeniería inversa o conjeturas.
Tanto el hash como el salado son dominios increíblemente complicados y están en constante evolución. Entonces, como desarrollador de aplicaciones, nunca trataríamos directamente con ellos. Pero nos ayudaría mucho si los supiéramos y pudiéramos tomar mejores decisiones. Por ejemplo, si mantiene un viejo Framework PHP y ve que usa hash MD5 para contraseñas, sabe que es hora de insertar otra biblioteca de contraseñas en el proceso de creación de la cuenta de usuario.
Keys
A menudo se encontrará con el término "claves" 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 el formulario 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 cifrar los datos de manera que queramos que la información esté abierta con el remitente y el receptor, pero mientras se transfiere o se almacena, debería ser ilegible.
Para ello, existe el concepto de "clave" en criptografía. Es exactamente lo que parece: la llave de una cerradura. La persona que posee la información la codifica usando un secreto llamado clave. A menos que el receptor / atacante tenga esta clave, es imposible descifrar los datos, sin importar cuán sofisticados sean sus algoritmos.
Rotating Keys
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 hacerse con un código de 20 años. Dentro del código, también encuentran las claves criptográficas que se utilizan para cifrar los datos de la empresa (una práctica horrible para almacenar claves junto con el código fuente, ¡pero se sorprendería de 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 llama rotación de claves, y si está utilizando una nube respetable PaaS proveedor, debe estar disponible como un servicio automatizado.
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.
Public Key Cryptography
Si toda la charla anterior sobre cifrado y claves te hace pensar que es muy engorroso, tienes razón. Mantener las llaves seguras y pasarlas para que solo el receptor pueda ver los datos se topa con problemas logísticos que no habrían permitido que prosperasen las comunicaciones seguras de hoy. Pero todo gracias a la criptografía de clave pública, podemos comunicarnos de forma segura o realizar compras en línea.
Este tipo de criptografía fue un gran avance matemático, y es la única razón por la que Internet no se está derrumbando por el miedo y la desconfianza. los detalles del algoritmo son intrincados y altamente matemáticos, por lo que solo puedo explicarlos conceptualmente aquí.
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 permanecerá privada contigo y nunca se compartirá con nadie; el otro se llama Public Key (de donde proviene el nombre del método) y se supone que se publicará públicamente. Si le estoy enviando datos, primero necesito obtener su clave pública, cifrar los datos y enviárselos; al final, puede descifrar los datos utilizando su combinación de clave privada y clave pública. Siempre que no revele accidentalmente su clave privada, puedo enviarle datos encriptados que solo usted puede abrir.
La belleza del sistema es que no necesito conocer su clave privada, y cualquiera que intercepte el mensaje no puede hacer nada para leerlo aunque tenga su clave pública. Si se pregunta cómo es posible esto, 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.
Transport Layer Security (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 cifrados con ella) 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 encriptan 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 de cada uno, lo que resulta en HTTP seguro (HTTPS).
Crédito de la imagen: Mozilla Es interesante notar que el cifrado no ocurre en la capa de transporte como tal; los 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 que se entreguen 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 suelto de seguridad de la capa de "transporte" se ha quedado.
Incluso podrías encontrarte con el término Secure Socket Layer (SSL) en algunos casos. Es el mismo concepto que TLS, excepto que SSL se originó mucho antes y ahora se ha eliminado a favor de TLS.
Full Disk Encryption
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, cifrado de disco completo se utiliza 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 el cifrado de disco completo debe realizarse a nivel de hardware. Esto es así porque si ciframos todo el disco, el sistema operativo también se cifra y no se puede ejecutar cuando se inicia la máquina. Por lo tanto, el hardware debe comprender que el contenido del disco está cifrado 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 está realizando, Full Disk Encryption da como resultado lecturas / escrituras más lentas, que los desarrolladores de dichos sistemas deben tener en cuenta.
End-to-End Encryption
Con las continuas pesadillas de privacidad y seguridad de las grandes redes sociales en estos días, nadie desconoce el término "cifrado de extremo a extremo", incluso si no tiene nada que ver con la creación o el mantenimiento de aplicaciones.
Vimos anteriormente 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 telefónicos que genera y almacena en tu teléfono sean seguros, pero no puede tener acceso para 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.
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 en el que la clave se almacena con la empresa y sus mensajes están tan seguros como la empresa lo decida.
Conclusión 👩🏫
Probablemente ya haya oído hablar de la mayoría de estos términos. Quizás incluso todos ellos. Si es así, le animo a revisar su comprensión de estos conceptos, así como a realizar una evaluación de la seriedad con que los toma. Recuerde, la seguridad de los datos de las aplicaciones es una guerra que debe ganar cada vez (y no solo una vez), ya que incluso una sola brecha es suficiente para destruir industrias, carreras e incluso vidas enteras.
