Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Prácticas recomendadas fundamentales
Las mejores prácticas generales que son controles efectivos para otras solicitudes de AWS API también se aplican a las solicitudes prefirmadas. En esta sección, se analizan dos de las prácticas más relevantes: los privilegios mínimos y los perímetros de datos. Estas prácticas crean una profundidad de controles que otras prácticas amplían.
Aplicación del principio de privilegios mínimos
El primer paso para limitar el uso de solicitudes prefirmadas es limitar el acceso a Amazon S3 en general. Una URL prefirmada no puede proporcionar acceso a recursos que no se hayan otorgado a la entidad principal que generó la firma de la URL prefirmada. Tampoco puede proporcionar acceso a un recurso de una manera que no se haya otorgado a ese director. Por lo tanto, aplicar las mejores prácticas para conceder a esos directores el menor privilegio es una barrera eficaz.
El proceso de creación de una URL prefirmada es una operación algorítmica que se basa en un estándar publicado (Signature versión 4) para la generación de firmas. Por lo tanto, no es posible poner límites a la generación de URL prefirmadas. Sin embargo, para que sea relevante, una URL prefirmada debe ser válida y proporcionar acceso a los recursos, por lo que la validez de una URL prefirmada también es una barrera eficaz.
Para obtener más información sobre los privilegios mínimos, consulte Otorgar acceso con privilegios mínimos en el pilar de seguridad del AWS Well-Architected Framework.
Implemente un perímetro de datos
Una extensión de privilegios mínimos es mantener un perímetro de datos que sea coherente con las necesidades de su organización. Las URL prefirmadas son compatibles con los perímetros de datos. Al igual que con otras solicitudes, la validez de una solicitud de URL prefirmada se evalúa en el momento de la solicitud. Si las propiedades de la red, el recurso, la sesión de rol y el principal cambian, se evalúan en el momento y mediante el método con el que se recibe la solicitud.
Por ejemplo, supongamos que un servicio que se ejecuta en un contenedor de Amazon Elastic Kubernetes Service (Amazon EKS) firma una solicitud. La solicitud se envía posteriormente desde el sistema informático personal del usuario que está conectado a Internet. En este caso, la SourceIp condición aws: evalúa la dirección IP pública visible de la solicitud del sistema personal del usuario, no la dirección IP del servicio en el contenedor EKS de Amazon.
Del mismo modo, si las etiquetas del principal o recurso cambian antes de que se envíe la solicitud, los valores actualizados, no los originales, se aplicarán a la solicitud mediante las ResourceTag/tag-key condiciones aws: PrincipalTag/tag-key y aws:.
