Descripción general de las URL prefirmadas

Una URL prefirmada es un tipo de solicitud HTTP que reconoce el servicio AWS Identity and Access Management (IAM). Lo que diferencia a este tipo de solicitud de todas las demás es el parámetro de consulta AWS X-Amz-Expires. Al igual que con otras solicitudes autenticadas, las solicitudes de URL prefirmadas incluyen una firma. En el caso de las solicitudes de URL prefirmadas, esta firma se transmite en. X-Amz-Signature La firma utiliza las operaciones criptográficas de la versión 4 de Signature para codificar todos los demás parámetros de la solicitud.

Notas

• La versión 2 de Signature se encuentra actualmente en proceso de quedar obsoleta, pero algunas todavía la admiten. Regiones de AWS Esta guía se aplica a la firma de la versión 4 de Signature.

• El servicio de recepción podría procesar encabezados sin firmar, pero el soporte para esa opción es limitado y específico, de acuerdo con las mejores prácticas. A menos que se indique lo contrario, suponga que todos los encabezados deben estar firmados para que se acepte una solicitud.

El X-Amz-Expires parámetro permite procesar una firma como válida con una desviación mayor de la fecha y hora codificada. Aún se están evaluando otros aspectos de la validez de la firma. Las credenciales de firma, si son temporales, no deben caducar en el momento en que se procese la firma. Las credenciales de firma deben adjuntarse a un director de IAM que cuente con la autorización suficiente en el momento del procesamiento.

Las URL prefirmadas son un subconjunto de solicitudes prefirmadas

Una URL prefirmada no es el único método para firmar una solicitud en el futuro. Amazon S3 también admite solicitudes POST, que también suelen estar prefirmadas. Una firma POST prefirmada permite realizar cargas que cumplan con una política firmada y que tenga una fecha de caducidad incluida en dicha política.

Las firmas de las solicitudes pueden estar fechadas en el futuro, aunque esto es poco común. Mientras las credenciales subyacentes sean válidas, el algoritmo de firma no prohíbe las citas futuras. sin embargo, estas solicitudes no se pueden procesar correctamente hasta su período de tiempo válido, lo que hace que las citas futuras no sean prácticas para la mayoría de los casos de uso.

¿Qué permite una solicitud prefirmada?

Una solicitud prefirmada solo puede permitir acciones que estén permitidas por las credenciales que se usaron para firmar la solicitud. Si las credenciales deniegan implícita o explícitamente la acción especificada en la solicitud prefirmada, la solicitud prefirmada se deniega cuando se envía. Esto se aplica a lo siguiente:

• Políticas de sesión asociadas a las credenciales

• Políticas asociadas al principal que está asociado a las credenciales

• Políticas de recursos que afectan a la sesión o al director

• Políticas de control de servicios que afectan a la sesión o al principal

Motivaciones para usar solicitudes prefirmadas

Como ingeniero de seguridad, debe saber qué motiva a los creadores de soluciones a utilizar direcciones URL prefirmadas. Entender lo que es necesario y lo que es opcional le ayudará a comunicarse con los creadores de soluciones. Las motivaciones pueden incluir las siguientes:

• Respaldar un mecanismo de autenticación que no sea de IAM y, al mismo tiempo, beneficiarse de la escalabilidad de Amazon S3. Una de las principales motivaciones es comunicarse directamente con Amazon S3 para aprovechar la escalabilidad integrada que ofrece este servicio. Sin esta comunicación directa, una solución tendría que soportar la carga que supone la retransmisión de los bytes que se envían PutObjecty GetObjectlas llamadas. En función de la carga total, este requisito añade desafíos de escalado que un creador de soluciones podría querer evitar.

  Es posible que otros medios de comunicación directa con Amazon S3, como el uso de credenciales temporales en AWS Security Token Service (AWS STS) o firmas de la versión 4 de Signature fuera de las URL, no sean adecuados para su caso de uso. Amazon S3 identifica a los usuarios mediante AWS credenciales, mientras que las solicitudes prefirmadas suponen la identificación mediante mecanismos distintos AWS de las credenciales. Se puede salvar esta diferencia y, al mismo tiempo, mantener la comunicación directa de los datos mediante solicitudes prefirmadas.

• Aprovechar la comprensión nativa de un navegador sobre las URL. Los navegadores entienden las URL, mientras que AWS STS las credenciales y las firmas de la versión 4 de Signature no. Esto resulta beneficioso cuando se integra con soluciones basadas en navegadores. Las soluciones alternativas requieren más código, utilizan más memoria para archivos de gran tamaño y pueden recibir un tratamiento diferente con extensiones como los escáneres de malware y virus.

Comparación con credenciales temporales AWS STS

Las credenciales temporales son similares a las solicitudes prefirmadas. Ambos caducan, permiten establecer el alcance del acceso y se suelen utilizar para vincular las credenciales que no son de IAM con el uso que requiere credenciales de AWS. 

Puede limitar estrictamente una AWS STS credencial temporal a un único objeto y acción de S3, pero esto puede provocar problemas de escalado, ya AWS STS que las API tienen límites. (Para obtener más información, consulte el artículo Cómo resolver la limitación de API o los errores de «tasa excedida» para IAM y en AWS STS el sitio web de AWS Re:post). Además, cada credencial generada requiere una llamada a la AWS STS API, lo que añade latencia y crea una nueva dependencia que podría afectar a la resiliencia. Una AWS STS credencial temporal también tiene un tiempo de caducidad mínimo de 15 minutos, mientras que una solicitud prefirmada puede admitir duraciones más cortas (60 segundos es práctico si se dan las condiciones adecuadas).

Comparación con soluciones que solo utilizan firmas

El único componente intrínsecamente secreto de una solicitud prefirmada es su firma de la versión 4 de firma. Si un cliente conoce los demás detalles de una solicitud y se le proporciona una firma válida que coincide con esos detalles, puede enviar una solicitud válida. Sin una firma válida, no puede hacerlo.

Las direcciones URL prefirmadas y las soluciones de solo firma son criptográficamente similares. Sin embargo, las soluciones que solo utilizan firmas tienen ventajas prácticas, como la posibilidad de utilizar un encabezado HTTP en lugar de un parámetro de cadena de consulta para transmitir la firma (consulte la sección sobre el registro de interacciones y mitigaciones). Los administradores también deben tener en cuenta que las cadenas de consulta se tratan más comúnmente como metadatos, mientras que los encabezados se tratan con menos frecuencia como tales.

Por otro lado, AWS los SDK ofrecen menos soporte para generar y usar firmas directamente. La creación de una solución que solo utilice firmas requiere más código personalizado. Desde una perspectiva práctica, el uso de bibliotecas en lugar de código personalizado por motivos de seguridad es una buena práctica general, por lo que el código para las soluciones que solo utilizan firmas requiere un análisis más exhaustivo.

Las soluciones que solo utilizan firmas no utilizan la cadena de X-Amz-Expires consulta ni proporcionan ningún período de validez explícito. IAM gestiona los períodos de validez implícita de las firmas que no tienen una fecha de caducidad explícita. Esos períodos implícitos no se publican. No suelen cambiar, pero se administran teniendo en cuenta la seguridad, por lo que no debes depender de los períodos de validez. Existe un equilibrio entre tener un control explícito sobre la fecha de caducidad y dejar que IAM gestione la caducidad.

Como administrador, es posible que prefiera una solución que solo utilice firmas. Sin embargo, en un sentido práctico, necesitará respaldar las soluciones tal como están diseñadas.