2011-06-18 12 views
10

quisiera proteger a mis documentos s3 por detrás de los carriles aplicación de tal manera que si voy a:aplicación Rails para la obtención de documentos S3

www.myapp.com/attachment/5 que debe autenticar al usuario antes de mostrar/descargando el documento.

He leído preguntas similares en stackoverflow pero no estoy seguro de haber llegado a conclusiones.

Por lo que he leído, hay varias cosas que puede hacer para "proteger" sus documentos S3.

1) Ofender la URL. He hecho esto. Creo que esto es algo bueno que hacer, así que nadie puede adivinar la URL. Por ejemplo, sería fácil "recorrer" la URL si sus URL S3 son obvias: https://s3.amazonaws.com/myapp.com/attachments/1/document.doc. Tener una URL como: https://s3.amazonaws.com/myapp.com/7ca/6ab/c9d/db2/727/f14/document.doc parece mucho mejor. Esto es ideal pero no resuelve el problema de pasar URL por correo electrónico o sitios web.

2) Utilizar una dirección URL que expira como se muestra aquí: Rails 3, paperclip + S3 - Howto Store for an Instance and Protect Access Para mí, sin embargo, esto no es una gran solución ya que la URL está expuesto (aunque solo sea por un corto período de tiempo) y otro usuario podría quizás con el tiempo volver a utilizar el URL rápidamente Debe ajustar el tiempo para permitir la descarga sin proporcionar demasiado tiempo para copiar. Simplemente parece una solución incorrecta.

3) Proxy la descarga del documento a través de la aplicación. Al principio intenté simplemente usar send_file: http://www.therailsway.com/2009/2/22/file-downloads-done-right, pero el problema es que estos archivos solo pueden ser archivos estáticos/locales en su servidor y no se sirven a través de otro sitio (S3/AWS). Sin embargo, puedo usar send_data y cargar el documento en mi aplicación y enviar inmediatamente el documento al usuario. El problema con esta solución es obvio: el doble de ancho de banda y el doble de tiempo (para cargar el documento en mi aplicación y luego volver al usuario).

Estoy buscando una solución que brinde la seguridad total del n. ° 3 pero no requiere el ancho de banda adicional y el tiempo de carga. Parece que Basecamp está "protegiendo" documentos detrás de su aplicación (a través de la autenticación) y asumo que otros sitios están haciendo algo similar, pero no creo que estén usando mi solución n. ° 3.

Las sugerencias serían muy apreciadas.

ACTUALIZACIÓN:

Fui con una cuarta solución:

4) Utilizar políticas depósito de Amazon para controlar el acceso a los archivos en función de remitente: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?UsingBucketPolicies.html

actualización de nuevo:

El pozo # 4 se puede solucionar fácilmente mediante la herramienta de desarrollo de navegadores. Así que aún estoy en busca de una solución sólida.

Respuesta

0

Yo votaría por el número 3, es el único enfoque verdaderamente seguro. Porque una vez que pasa al usuario a la URL S3 que es válida hasta su hora de vencimiento. Un usuario astuto podría usar ese agujero, la única pregunta es, ¿afectará eso a su aplicación? ¿Quizás podría establecer que el tiempo de caducidad sea menor, lo que minimizaría el riesgo? Echa un vistazo a un extracto de este post: Accessing private objects from a browser

Todos los objetos privados son accesibles a través de un autenticado GET solicitud a los servidores S3 . Puede generar un url autenticado por un objeto como este :

S3Object.url_for('beluga_baby.jpg', 'marcel_molina') 

Por defecto URLs autentificadas expiran después de 5 minutos se generaron.

opciones de caducidad se pueden especificar ya sea con un tiempo absoluto desde la época con el: expira opciones, o con un número de segundos en relación con ahora con los: opciones expires_in:

+0

Gracias por la publicación. ¿No es esa mi solución # 2? Sé que es viable, pero parece que no es un enfoque verdaderamente seguro. Por alguna razón, siento que deja un agujero (incluso si es bastante pequeño). ¿Alguna sugerencia sobre cómo implementar mi # 3 sin el problema del doble ancho de banda? –

+0

Bueno, es lo más seguro posible. Es posible que pueda usar un proxy inverso de algún tipo para obtener esto, pero el ancho de banda se usará en algún lugar con esto. Solo establecería el tiempo de espera en 1 min. –

+0

Tenía la esperanza de que me faltaba alguna solución relacionada con algún plugin de apache en el que pudiera redirigirse en función de la autenticación de RoR. ¿El tiempo de espera (sin importar cuán pequeña sea la ventana que intente establecer) aún permite cierto nivel de inseguridad? .... Sin embargo, estoy de acuerdo en que esta puede ser la única respuesta. Si nadie más responde, estableceré la tuya como la respuesta correcta. Gracias. –

0

tengo estado en el proceso de intentar hacer algo similar por bastante tiempo ahora. Si no desea usar el ancho de banda dos veces, entonces la única manera de que esto sea posible es permitir que S3 lo haga. Ahora estoy totalmente contigo sobre la URL expuesta. ¿Pudiste encontrar alguna alternativa?

He encontrado algo que podría ser útil en este sentido - http://docs.aws.amazon.com/AmazonS3/latest/dev/AuthUsingTempFederationTokenRuby.html

Una vez que un usuario se conecta, una sesión de AWS con su IP como parte de la política de AWS deben ser creados y entonces este puede ser utilizado para generar las URL firmadas. Entonces, en caso de que alguien más tome la URL, la firma no coincidirá ya que la fuente de la solicitud será una IP diferente. Avíseme si esto tiene sentido y es lo suficientemente seguro.

Cuestiones relacionadas