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?
Respuestas:
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 premiotodos 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.
fuente
Utilice las consultas previamente firmadas de Amazon S3 para servir los objetos S3 directamente a los usuarios después de realizar la validación de usuario que desee. Este método crea una URL de tiempo limitado a la que puede redirigir a los usuarios.
fuente
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.
fuente