Almacenar y servir archivos de forma segura para múltiples clientes


8

Estamos trabajando en una aplicación web, donde (entre otras características) nuestros usuarios pueden cargar sus archivos. Sin embargo, no podemos almacenar estos archivos en nuestro VPS porque el espacio de almacenamiento es limitado, por lo que decidimos usar S3.

El principal problema es que debemos asegurarnos de que los usuarios solo puedan acceder a sus propios datos. Por lo tanto, mantenemos la lista de archivos en nuestra base de datos y la lista de usuarios que tienen acceso a ellos. Nuestro servidor puede decidir fácilmente si un usuario tiene o no acceso a un archivo. Pero, ¿cómo servir realmente los archivos a los usuarios?

Hay algunas posibilidades que ya he considerado, sin embargo, ninguna de ellas parece ser la mejor.

1. Generando (caducando) URL firmadas con PHP

Este es un enfoque realmente simple, también es rápido pero da como resultado URL muy, muy feas y largas.

Aquí te explicamos cómo hacerlo .

2. URL ofuscadas

Este medio, que mantienen al público archivos de lectura en S3, pero todos los archivos se almacenan en difícil de adivinar como carpetas con el nombre: 24fa0b8ef0ebb6e99c64be8092d3ede20000. Sin embargo, quizás esta no sea la forma más segura de hacerlo. Incluso si nunca puede adivinar el nombre de una carpeta, después de saberlo (porque realmente tiene acceso a él), puede compartir ese enlace con cualquier persona (con cualquier persona no autorizada).

3. Descargue los archivos a través de nuestro servidor

Esto significa que los archivos no son servidos directamente por S3, pero primero nuestro servidor los lee de forma segura y los sirve. Realmente no queremos esto :)

4. Referencia de comprobación

La solución de URLs ofuscadas puede mejorarse "asegurándose" de que la solicitud proviene de nuestro servidor (puede configurar S3 para verificar el referente). Sin embargo, esta sería una solución poco confiable, porque no todos los navegadores envían los datos de referencia, y también pueden ser falsificados.

¿Cuál es una buena manera de servir archivos de Amazon S3 de forma segura para diferentes clientes?


1
¿Por qué te importa la URL fea / larga? No estás haciendo que el usuario lo escriba, ¿verdad?
ceejayoz

Realmente creo que las URL son parte de la experiencia del usuario, y no las queremos demasiado largas y feas :)
Tamás Pap

2
La seguridad y la estabilidad deberían prevalecer sobre las URL bonitas en este caso, diría. Estos no son enlaces permanentes a publicaciones de blog.
ceejayoz

Respuestas:


12

Esto realmente limita con "Hacer mi arquitectura del sistema" para usted, pero sus cuatro ideas son estudios de caso interesantes en seguridad variable, así que veamos sus opciones y veamos cómo les va:


4. Referencia de comprobación

El referente lo proporciona el cliente. Confiar en los datos de autenticación / autorización proporcionados por el cliente prácticamente anula la seguridad (puedo afirmar que me han enviado desde donde espera que venga).
Veredicto: idea TERRIBAD - trivial para evitar.


3. Descargue los archivos a través de nuestro servidor

No es una mala idea, siempre que esté dispuesto a gastar el ancho de banda para que esto suceda, y su servidor sea confiable.
Asumiendo que ya ha resuelto el problema de seguridad para su servidor / aplicación normal, esta es la opción más segura que ha presentado.
Veredicto: buena solución. Muy seguro, pero posiblemente subóptimo si el ancho de banda es un factor.


2. URL ofuscadas

Seguridad a través de la oscuridad ? De Verdad? No.
Ni siquiera voy a analizarlo. Simplemente no.
Veredicto: si el # 4 fue TERRIBAD, esto es TERRIWORSE porque las personas ni siquiera tienen que pasar por el esfuerzo de falsificar un encabezado de referencia. Adivina la cuerda y gana un premio todos los datos!


1. Generando (caducando) URL firmadas con PHP

Esta opción tiene un cociente de aspiración bastante bajo.
Cualquiera puede hacer clic en la URL y analizar los datos, lo cual es un no-no de seguridad, pero puede mitigar esto haciendo que el enlace caduque (siempre que la vida del enlace sea lo suficientemente corta, la ventana de vulnerabilidad es pequeña).
La caducidad de la URL puede incomodar a algunos usuarios que desean conservar el enlace de descarga durante mucho tiempo, o que no obtienen el enlace de manera oportuna, eso es un poco una experiencia de usuario desagradable, pero puede valer la pena. .
Veredicto : no es tan bueno como el n. ° 3, pero si el ancho de banda es una preocupación importante, ciertamente es mejor que el n. ° 4 o n. ° 2.


¿Que debería hacer?

Dadas estas opciones, iría con el n. ° 3: pasar los archivos a través de su propio servidor front-end y autenticar la forma en que normalmente lo hace su aplicación. Asumiendo que su seguridad normal es bastante decente, esta es la mejor opción desde el punto de vista de la seguridad.
Sí, esto significa un mayor uso de ancho de banda en su servidor y más recursos para el intermediario, pero siempre puede cobrar un poco más por eso.


Este es un análisis realmente útil, y estoy muy agradecido por ello. Otro gran beneficio del n. ° 3 es que, debido a que la URL de un archivo nunca cambia, podemos usar mucho el almacenamiento en caché del navegador. Gracias de nuevo por tu tiempo.
Tamás Pap

@TamasPap es una ventaja del # 3 para estar seguro: qué tan grande es la ventaja depende de qué tan agresivamente pueda configurar el almacenamiento en caché (y con qué frecuencia las personas acceden a estos archivos desde máquinas "nuevas").
voretaq7


0

También hay otra forma.

Puede apuntar un AWS CloudFront a su S3 Bucket y usar cookies firmadas para servir contenido de forma segura a sus usuarios finales.

Los usuarios finales deben iniciar sesión en su servidor para obtener las Cookies firmadas que luego se enviarán a CDN mientras acceden a cualquier archivo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.