Seguridad en Transloadit

Transloadit usa UUIDv4 sin guiones para generar estos ID aleatoriamente. Adivinar, o generar un UUID que coincida con uno de los nuestros, sería tan probable como generar una colisión. Esto es tan improbable que no se considera un vector de ataque viable.

Como mantenemos alrededor de cinco millones de Assemblies en almacenamiento activo en cualquier momento dado, las probabilidades de generar una colisión son, ciertamente, cinco millones de veces mayores. Dicho esto, como aplicamos rate limiting de 250 operaciones por minuto, a las máquinas aún les tomaría más tiempo del que la humanidad ha existido en la Tierra generar suficientes UUIDs para tener una probabilidad del 50% de que uno de ellos coincida con un UUID que Transloadit haya generado alguna vez. Consideramos que esto está lejos de ser un vector de ataque viable.

Para los archivos, la ventana se vuelve aún más pequeña, ya que los eliminamos después de 24 horas. Aquí se describen algunas razones por las que elegimos hacer esto.

Más allá de adivinar archivos o URLs de Assembly, por supuesto es preocupante que estas direcciones puedan filtrarse de alguna manera. Consideramos que un ID de Assembly y una URL de archivo son privados. Son un secreto compartido entre Transloadit, nuestro cliente y, según tu integración, el usuario final específico para quien el cliente está proporcionando los archivos y ejecutando la Assembly en tu nombre.

Esta comunicación entre estas partes ocurre mediante HTTPS, para el cual tenemos calificación A+ en SSL Labs en todos los aspectos. Si se usa HTTPS para la integración con Transloadit y con el usuario final en cualquier solicitud involucrada, las URLs de Assemblies y archivos no pueden filtrarse más allá de estas partes de confianza, hasta el punto de convertirse en un vector de ataque viable.

Luego está Transloadit como parte de confianza. Nuestra política es que solo los miembros de confianza de nuestro equipo central tienen acceso a estos archivos con fines de depuración. Recibimos millones de archivos todos los días y para nosotros son solo UUIDs hasta que un cliente nos pide revisar algo más de cerca.

Ejecutamos todos nuestros procesos como usuarios sin privilegios, inyectando secretos, así que si un atacante ha obtenido esos secretos, eso significa que de alguna manera consiguió acceso root a nuestras máquinas. En este caso, cifrar los buckets de archivos no sería suficiente, ya que con las credenciales adquiridas para obtener acceso completo al bucket, casi con certeza el atacante también tendría acceso a nuestras claves de descifrado, como ocurre cuando consideramos que Amazon ha sido hackeado. Por suerte, tanto Amazon como Transloadit ponemos un foco muy alto en mantener nuestros sistemas seguros. Pero es cierto que cualquiera que te dé aquí una garantía de seguridad del 100%, en realidad, no entiende del todo la seguridad, y harías bien en mantenerte alejado.

Nuestra plataforma es altamente volátil en el sentido de que hoy tendremos 1000 servidores online que mañana ya no estarán. Intentar mantener tus firewalls actualizados a este ritmo es buscar conexiones caídas.

No canalizamos las conexiones salientes (por ejemplo, /sftp/store, Notifications o /http/import) a través de un solo punto por razones de rendimiento y SPOF. Usar una flota de proxies que escalen junto con la carga nos devuelve al mismo problema, y usar NAT tiene limitaciones prohibitivas en términos de rendimiento. La compensación de nuestra decisión de priorizar la máxima fiabilidad y throughput es que nuestras IPs salientes cambian rápidamente.

Si quieres que almacenemos archivos en tu bucket de S3, se recomienda guardar las credenciales en un Template de tu cuenta. Mantenemos este Template cifrado en nuestra base de datos.

Las claves necesarias para descifrarlas son inyectadas en la memoria del proceso por otro usuario del sistema. Esto significa que, si alguien pudiera explotar el usuario bajo el cual ejecutamos nuestros procesos de API o sitio web, aun así no podría acceder a las claves. Si intentara cambiar nuestro código para mostrar o enviar las credenciales, tendría que reiniciar el servicio (no permitido para ese usuario) y acceder a los archivos de claves (también no permitido).

Si nuestros servidores obtienen acceso root por parte de un atacante, la historia es diferente. Por eso usamos firewalls, claves SSH protegidas y limitamos nuestro sudo, pero como cualquier experto te dirá, la seguridad al 100% es un mito y es mejor prepararse para lo peor.

Por eso recomendamos crear políticas IAM que solo tengan permisos Put y List sobre tus buckets (para una lista precisa y actualizada de los permisos requeridos, consulta la documentación de S3 Store), y permitir que Transloadit las use solo para escritura. Así, si tus credenciales alguna vez fueran robadas y los criminales lograran descifrarlas también, aun así solo podrían agregar más archivos a este bucket en particular, hasta que lo notemos e intervengamos.

Si bien, como dijimos, la seguridad al 100% es un mito, nuestra filosofía de seguridad es hacer que sea lo más difícil posible para cualquiera obtener acceso a tus credenciales y a las claves necesarias para descifrarlas y, si logran adquirirlas, hacer que sean lo más inútiles posible.

Primero que nada, para la autenticación de firmas y todo lo demás que necesita ser seguro, no usamos MD5. Proporcionamos hashes MD5 para archivos como una forma de detectar duplicados de fuentes confiables, así como para otros fines en los que no hay un caso de uso que recompense el vector de ataque de calcular hashes con colisiones.

Como MD5 es más rápido de calcular y aún más ampliamente disponible que, por ejemplo, SHA1, se hizo una concesión deliberada al proporcionar hashes MD5 para los resultados de encoding. No hace falta decir que, dado que MD5 no es seguro, no deberías usar estos hashes como componentes para nada que sea sensible a la seguridad en tu aplicación.