ios - servidores - la nube de amazon

Administrar el acceso a los servicios de AWS en clientes de iOS vs servidores de back-end (4)

Al diseñar una aplicación de iOS que interactuará con AWS (por ejemplo, S3 , CloudFront , etc.), ¿cuáles son los pros y los contras de administrar el acceso a estos servicios en el cliente y en el servidor?

Al "administrar el acceso", me refiero a cosas como subir contenido privado a S3, descargar contenido privado a través de Cloudfront.

Por supuesto, cualquier lado que maneje el acceso necesitará almacenar la clave de acceso AWS y acceder al secreto. La seguridad es una de las preocupaciones.

Estoy igualmente interesado en los impactos de esta elección de diseño en el rendimiento y la flexibilidad de cualquiera de las implementaciones.

Por último, ¿existe un argumento para implementar un enfoque híbrido en el que tanto el cliente como el servidor interactúen directamente con AWS , o la implementación generalmente va con uno u otro, pero no con ambos?

La seguridad es la razón principal por la que colocaría toda / la mayoría de la autenticación del servicio AWS en el back-end después de que haya autenticado al usuario.

Otra consideración es la cantidad de tiempo que se tarda en actualizar su aplicación en la Tienda Apple dado su proceso de aprobación. Puede tomar días dependiendo de la cola de la tienda de Apple para que pueda realizar cambios en su aplicación; los cambios en el back-end de AWS se pueden hacer a voluntad.

Además, al diseñar una aplicación para interactuar con los servicios de AWS, siempre asumo que todo lo que se transmite puede verse comprometido y es muy probable que lo utilicen personas que deconstruyeron sus llamadas y las reconstruyeron para satisfacer sus necesidades.

(Por ejemplo, poco después de lanzar una aplicación de entretenimiento fotográfico que carga imágenes y luego aplica filtros, notamos las entradas de registro con identificadores de filtro que no existían en la aplicación proveniente de la misma IP. No tuvieron éxito porque no se autenticaron .)

Espero que ayude.

Por razones de seguridad, es importante mantener sus llaves en un lugar donde no puedan ser manipuladas: eso generalmente significa dejarlas en el servidor.

Piense en sus claves de esta manera: conceden acceso a los recursos de su organización. Al poner sus llaves en un dispositivo móvil, el robo de las llaves afecta sus recursos a nivel de la organización. En su lugar, utilice la autenticación a nivel de usuario en el dispositivo móvil para otorgar acceso a los recursos de AWS a través de un proxy en sus servidores. De esta forma, la pérdida de credenciales de nivel de usuario no genera pérdidas a nivel de organización y es más fácil revocar las credenciales de nivel de usuario.

También mencionas cargas a S3. AWS tiene una buena función llamada publicación prestada en la que su servidor genera credenciales de carga únicas que su dispositivo móvil puede usar para cargar datos en S3, sin tener que transmitir los datos a través de su servidor.

Ejemplo de código Ruby :

presigned_post = bucket.presigned_post(key: key, success_action_status: 201, acl: :public_read)

Además de las otras buenas respuestas, me gustaría hacer un comentario adicional: a diferencia de las aplicaciones web, no puede esperar que todos los usuarios tengan la última versión de su aplicación. Esto significa que cualquier url del servidor que alguna versión de su aplicación llame debe, en principio, permanecer viva para siempre. Esto significa que si desea cambiar la infraestructura de su servidor más adelante (por ejemplo, migrar de AWS a otro host en la nube), no podrá hacerlo, incluso si crea una versión actualizada de su aplicación con URL nuevas, entonces seguirá existiendo algunas aplicaciones no actualizadas que llaman a las URLs antiguas.

Por supuesto, puedes elegir hacer un mecanismo de "actualización forzada" en la aplicación donde no puedas usarlo hasta que lo actualices (esto es común en los juegos multijugador, pero no en muchos otros lugares) o simplemente para que no te importe una minoría de usuarios. de versiones anteriores de su aplicación cuya vida hace miserable (giro de la trama: pueden quedar atrapados en una versión anterior de su aplicación porque su dispositivo no se puede actualizar a la última versión de iOS ).

Pero la mejor solución de IMO es ocultar las URL de AWS detrás de sus propios servidores, por lo que nunca se encontrará con este problema. Es un detalle de implementación que realmente no debe filtrarse en el cliente.

Si bien hay muchos escenarios en los que es posible que desee hacerlo de cualquier manera en general, casi no hay casos en los que desee hacer esto directamente desde el cliente, ya que menciona ios:

Pros para cargar datos desde el lado del servidor a AWS:

Seguridad
Como ya se mencionó en la otra respuesta, tener solicitudes autenticadas inicialmente le ahorraría muchas molestias de los malintencionados y los piratas informáticos si están tratando de romper las cosas. Si los datos son privados y está verdaderamente comprometido con la privacidad, cualquier fuga de datos sería más fácil de prevenir si el sistema está autenticado.
Limitación de velocidad, cuotas de usuario, etc.
La ventaja añadida de los sistemas autenticados es que puede limitar las solicitudes provenientes de fuentes particulares, por ejemplo, usuario, grupo, IP, etc. (cuotas de nivel de aplicación si tiene la intención de compilar varias aplicaciones con la misma arquitectura de sistema). Desarrollar esta inteligencia no es tan fácil cuando se trabaja directamente desde el lado del cliente.
Pista de auditoría
Si necesita hacer un seguimiento de quién cargó qué, cuándo, desde dónde y más información, es mucho más fácil hacer un seguimiento si obtiene la solicitud inicial directamente en su servidor.
Manejo de excepciones en caso de falla
Es bastante posible tener fallas que no habría predicho fácilmente, o fallar un error crítico durante las pruebas de control de calidad. Manejar estos servidores es mucho más eficiente porque está bajo su control. Cuando surgen tales problemas en el lado del cliente, está a merced de que sus clientes puedan actualizar la aplicación. Si se trata de este lado del servidor, se podrían implementar / implementar controles adicionales para muchos de estos errores, lo que limitaría el alcance del error.
Hora de ir a vivir
Nuevamente, como se menciona en la otra respuesta, puede pasar un tiempo hasta que se apruebe su actualización. Esto reduce enormemente su capacidad de respuesta a problemas críticos, y puede ser difícil de mitigar en caso de problemas graves (fuga de información / violación de la privacidad) que provocan pérdidas significativas (confianza financiera / del usuario / calificaciones negativas, etc.)

Los únicos casos en los que creo que le gustaría subir datos directamente del lado del cliente a AWS serían

Cargar grandes cantidades de datos, muy, muy frecuentemente, sin procesamiento directo.
Si cargar una vez cuesta cierta cantidad de ancho de banda y recursos de red, al cargarla dos veces se reclaman el doble de los recursos (una vez desde el client --> server , luego desde el server --> AWS ). Por lo tanto, si carga grandes cantidades de datos con frecuencia (piense en TB diariamente), terminará desperdiciando muchos de sus recursos simplemente copiando datos de un punto a otro. En tales casos, tendrá sentido enviar los datos directamente a S3. Pero para que este enfoque funcione, sus ahorros de costos deberían ser lo suficientemente altos como para anular las preocupaciones sobre seguridad y privacidad, y para la mayoría de las aplicaciones, simplemente no es el caso.
Estás en un jardín amurallado
Básicamente, la aplicación funciona solo para ciertos usuarios previamente identificados, la aplicación simplemente no funciona para nadie más (digamos que usted estaba desarrollando esto para uso interno en una empresa). En esencia, esto significa tener un 100% de confianza en los motivos del usuario final para usar su aplicación.

EDITAR : OP pregunta en los comentarios

¿Qué hay del servidor que proporciona URL / cookies firmadas, y el cliente las utiliza para cargar en S3 o descargar desde Cloudfront. El cliente aún interactúa directamente con AWS pero requiere permisos controlados por el servidor.

A primera vista, me parece que esto es muy factible. Esta publicación de blog proporciona muchos casos de uso (como el suministro de URLs firmadas con comodín para la lectura) en torno al uso de direcciones URL firmadas (aunque los ejemplos están en .NET ) y hay más información disponible en AWS docs .

Como va a manejar el lado del servidor de firmas, puede ocuparse fácilmente de cada uno de los puntos que mencioné anteriormente en mi publicación (la limitación de tarifas, las cuotas de los usuarios, el seguimiento de auditoría, etc. es factible, ya que la solicitud irá inicialmente al servidor ) Como esta respuesta menciona,

La firma de URL ayuda a controlar quién puede acceder a un archivo dado y por cuánto tiempo pueden acceder a él.

En general, esto debería funcionar bien para bastantes casos de uso.