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.
Barandillas adicionales
Cuando los creadores de soluciones y los usuarios utilizan adecuadamente las solicitudes prefirmadas, proporcionan un mecanismo seguro para que los usuarios accedan a los datos. Además, la capacidad de generar solicitudes prefirmadas no proporciona a los directores un acceso que aún no tenían.
En ese contexto, ¿son necesarios controles adicionales? La justificación de los controles adicionales no se basa en la necesidad de denegar el acceso, sino en ofrecer la posibilidad de supervisar, aprobar el uso y establecer límites, además de reducir el riesgo de que los usuarios cometan errores. De esta forma, puede ayudar a garantizar que el uso sea adecuado y necesario.
Las siguientes barandillas le ayudan a lograr este objetivo. Antes de activar estos controles, es posible que desee determinar el uso actual identificando las solicitudes prefirmadas. Esta identificación le ayuda a prepararse para el impacto de la barandilla en el uso actual o a planificar excepciones cuando sea necesario.
Barandilla para S3: Signature Age
Una característica que define a las solicitudes prefirmadas es que describen un tiempo de caducidad. La firma de la solicitud contiene una fecha. Esta fecha se transmite como parámetro de cadena de X-Amz-Date consulta para las URL prefirmadas y como encabezado Date o x-amz-date para las POST prefirmadas.
Amazon S3 proporciona una clave de condición, s3:SignatureAge, que puede utilizar para limitar el tiempo máximo entre la fecha de firma y el vencimiento efectivo de la solicitud. Esta condición nunca puede aumentar el período de validez, pero sí puede reducirlo.
En la siguiente política, la clave de s3:signatureAge condición limita las solicitudes prefirmadas a 15 minutos de validez. Todos los ejemplos siguientes utilizan 15 minutos para limitar la validez a un período de tiempo similar al que admite la firma estándar.
La segunda declaración de la política deniega cualquier acceso a la versión 2 de Signature. Esta versión del protocolo de firma está en desuso, pero algunas Regiones de AWS aún la admiten. Le recomendamos que la bloquee de forma explícita antes de que quede totalmente obsoleta.
Puede aplicar la siguiente política como política de control de AWS Organizations servicios (SCP). Los usuarios pueden seguir utilizando solicitudes prefirmadas e implementar soluciones que dependan de esas solicitudes, siempre que el tiempo entre la generación de la firma y el uso sea inferior a 15 minutos. Según la implementación, es posible que esta limitación no tenga ningún impacto, que una solución quede inutilizable o que se produzcan errores ocasionales que se puedan volver a intentar.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" } } }, { "Sid": "DenySignatureVersion2", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringEquals": { "s3:signatureversion": "AWS" } } } ] }
Excepciones
Si una solución requiere más tiempo antes de caducar y, por lo tanto, se ve afectada por la política anterior, le recomendamos que proporcione un método para aprobar las excepciones. Para evitar enumerar las excepciones en un SCP, utilice aws: PrincipalTag, como en la siguiente política, para gestionar las excepciones de forma escalable. Otros AWS ejemplos, como los ejemplos de políticas perimetrales de datos de AWS
Si implementa una política de excepciones mediante el usoaws:PrincipalTag, debe controlar el acceso a las etiquetas de configuración en las entidades principales. Las etiquetas de este tipo pueden provenir directamente de los directores y pueden ser controladas por un SCP, como en este ejemplo de control de los valores de las etiquetas que se pueden estableceraws:PrincipalTag es un tema complejo. Sin embargo, una organización que tenga experiencia en el uso del control de acceso basado en atributos (ABAC) tendrá la experiencia y los controles necesarios para permitir el uso adecuado en este caso de aws:PrincipalTag uso.
En el siguiente ejemplo, la aws:PrincipalTag condición crea una excepción que permite asignar y establecer a cualquier principal con la etiqueta denominada (long-presigned-allowed). true Con esta excepción, no se aplica la restricción de antigüedad de la firma.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } } ] }
Políticas de buckets
Puede aplicar políticas de bucket a todos los buckets o a algunos de ellos mediante una política como la que se muestra en el siguiente ejemplo. A diferencia de una SCP, una política de bucket también se centra en el uso principal del servicio. El apéndice A no documenta ningún uso principal esperado de las solicitudes prefirmadas, pero si quisieras implementar un control para demostrar ese límite, la siguiente política proporcionaría ese control. Además, a diferencia de un SCP, se puede aplicar una política de grupos a los principales de tu cuenta de administración.
ABAC-based las excepciones funcionan en las políticas de bucket de la misma manera que en un SCP. El objetivo de una política agrupada podría ser aplicarla a los directores ajenos a la organización, por lo que las excepciones de la ABAC deberían limitarse a los directores a los que se aplican los controles de la ABAC.
En el siguiente ejemplo, la aws:PrincipalTag condición de la primera sentencia crea una excepción para un director con la etiqueta denominada (long-presigned-allowed) asignada y establecida en. true Con esta excepción, no se aplica la restricción de antigüedad de la firma. La segunda declaración aplica esta restricción a todos los directores ajenos a la AWS
organización propietaria del depósito. El alcance de esta segunda declaración debe coincidir con los controles de ABAC para establecer la etiqueta nombrada para los directores.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] }
Políticas de control de recursos
Puede aplicar una política a los depósitos a escala mediante políticas de control de recursos (RCP). Al igual que los SCP y a diferencia de las políticas de compartimentos, los RCP no se centran en el uso principal del servicio. Los RCP afectan a los directores que no son de servicio de cualquier cuenta, pero no afectan a los recursos de la cuenta de administración. Para obtener más información, consulte la Documentación de AWS Organizations.
Al igual que ocurre con las políticas de grupos, si suele aws:PrincipalTags crear excepciones para los principales, tenga en cuenta el alcance de los controles de ABAC sobre el etiquetado de los principales.
El siguiente RCP restringe el uso de URL prefirmadas en todos los segmentos de S3 de una organización al limitar la antigüedad de las firmas a 15 minutos.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true", } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] }
Guardrail para S3: AuthType
Las URL prefirmadas utilizan la autenticación mediante cadenas de consulta y las POST prefirmadas siempre utilizan la autenticación POST. Amazon S3 admite la denegación de solicitudes en función del tipo de autenticación mediante la clave de condición s3:AuthType. REST-QUERY-STRINGes el s3:authType valor de las cadenas de consulta y POST es el s3:authType valor de POST.
Puede aplicar la siguiente política como SCP. La política se utiliza s3:authType para permitir únicamente la autenticación basada en encabezados. También configura un método para proporcionar excepciones a usuarios o roles individuales.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
La denegación de solicitudes en función del tipo de autenticación afecta a cualquier solución o función que utilice el tipo de autenticación denegada. Por ejemplo, la denegación REST-QUERY-STRING impide que los usuarios realicen cargas o descargas desde la consola Amazon S3. Si desea que los usuarios utilicen la consola Amazon S3, no utilice esta barandilla o haga una excepción para los usuarios. Por otro lado, si no quiere que los usuarios usen la consola Amazon S3, puede denegársela a REST-QUERY-STRING los usuarios.
Quizás ya deniegue a los usuarios el acceso directo a los recursos de Amazon S3. En este caso, una barrera para el tipo de autenticación es redundante. Sin embargo, una sentencia de s3:authType denegación proporciona una utilidad de defensa exhaustiva, ya que las implementaciones para denegar el acceso directo suelen incluir muchas sentencias de control, algunas con excepciones.
Los roles que se utilizan para las cargas de trabajo no suelen necesitar acceso a la cadena de consulta ni a la autenticación. POST Las excepciones son las funciones que respaldan los servicios diseñados para usar solicitudes prefirmadas. Puede crear excepciones específicas para esas funciones.
También puedes aplicar una política de grupos a todos los grupos o a algunos de ellos mediante una política como la siguiente:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Esta política de segmentos tiene el efecto de denegar el uso de las UploadPartCopyAPI CopyObjecty para realizar copias entre regiones. La replicación de Amazon S3 no se ve afectada porque no depende de estas API.
Si desea utilizar una política de bucket como la política anterior y seguir siendo compatible con la UploadPartCopyAPI CopyObjecto entre regiones, añada una condición aws:ViaAWSService similar a la siguiente:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" }, "Bool": { "aws:ViaAWSService": "false" }, } } ] }
Combinación de barandas prefirmadas y excepciones a otras barandillas
Si no tiene previsto aplicar una barrera de protección en general a sus usuarios y funciones, puede que le interese aplicarla a las excepciones de otras barreras de protección comunes, de forma que esas excepciones no admitan las solicitudes prefirmadas.
Si tienes restricciones de red, pero permites excepciones para socios externos o para casos de uso especiales, debes bloquear la cadena de consulta o la POST autenticación cuando se apliquen esas excepciones, a menos que se identifique específicamente que son obligatorias.
Limitaciones de S3: SignatureAge
A los administradores les resultará útil comprender mejor sus implicaciones. s3:signatureAge Cada solicitud firmada incluyeX-Amz-Date, en la que se debe indicar, la hora actual. Este valor lo rellenan el cliente y el firmante de la solicitud. AWS rechaza las solicitudes que considera que tienen tiempos no válidos. Sin embargo, un firmante podría generar firmas por adelantado en future time. Amazon S3 rechaza las solicitudes que especifiquen una hora futura si se envían con demasiada antelación. Sin embargo, si la solicitud no se envía hasta el momento en que se inicia sesión en la firma, la firma podría generarse antes y enviarse más tarde.
s3:signatureAgelimita la antigüedad máxima de X-Amz-Date una firma solo para las solicitudes prefirmadas. Se rechazan las solicitudes con una antigüedad superior a la especificada, incluso si han caducado X-Amz-Expires o si una POST política las hubiera declarado válidas. s3:signatureAgeno cambia el período de validez de las solicitudes que no incluyen un vencimiento explícito. Tampoco controla el valor X-Amz-Date que un cliente utiliza como firma.
Si el reloj del sistema es incorrecto o si un cliente solicita intencionalmente fechas futuras, es posible que la hora firmada no sea la hora en que se generó la firma. Esto limita en qué medida s3:signatureAge pueden controlar las soluciones. Una solución que utiliza la hora actual para generar firmas está limitada de la forma esperada: las firmas siguen siendo válidas durante el número de milisegundos especificado ens3:signatureAge. Una solución que no utilice la hora actual tendrá límites diferentes. Una restricción es que las credenciales que se usaron para firmar la firma deben seguir siendo válidas. Como administrador, puede controlar la validez máxima de las credenciales temporales emitidas. Puede permitir que las credenciales sean válidas durante un máximo de 36 horas o restringir la validez a un mínimo de 15 minutos. La caducidad de las credenciales temporales no depende del valor deX-Amz-Date.
Las credenciales permanentes no tienen esta restricción. Se recomienda usar solo credenciales temporales, y puedes revocar de forma explícita cualquier credencial permanente, lo que también invalidaría cualquier firma basada en esa credencial.
Aunque s3:signatureAge se mide en milisegundos, no es práctico configurarlo en menos de 60 segundos, incluso si el reloj está bien sincronizado y el uso de la latencia es bajo. Los ajustes inferiores a 60 segundos conllevan el riesgo de rechazar solicitudes válidas. Si prevé demoras entre la generación de la firma y el envío de la solicitud, o si hay problemas con la sincronización del reloj, debe tener en cuenta estos problemas en la gestión de los s3:signatureAge mismos.
Dirigirse a los grupos a gran escala
Los SCP y los RCP se pueden utilizar aws:PrincipalTag para hacer excepciones para los usuarios. No puedes usar etiquetas en un depósito para controlar el accesoaws:ResourceTag; solo se usan etiquetas de objetos para el control de acceso. Por lo general, no es escalable añadir una etiqueta a cada objeto al que quieras aplicar este control.
Una solución que se adapta a muchos casos de uso es aplicar la política y la excepción a nivel de cuenta, ya sea cambiando las cuentas a las que se aplica el SCP o el RCP o utilizando aws: ResourceAccount, aws: ResourceOrgPaths o aws: ResourceOrg ID. Por ejemplo, se puede aplicar un SCP o un RCP a un conjunto de cuentas de producción.
Otra solución consiste en utilizar una AWS Config regla personalizada para implementar un control detectivesco o un control responsivo. El objetivo sería que cada grupo contuviera una política de grupo con la barrera de protección adecuada. Además de probar el contenido de una política de bucket, la AWS Config regla personalizada puede recuperar las etiquetas del bucket y excluirlo de la regla si el bucket está etiquetado con un valor específico. Si esa regla no supera la comprobación de conformidad, podría marcar el depósito como no conforme o solicitar una solución para añadir el elemento de protección a la política del depósito.
nota
No puedes restringir el contenido de las etiquetas de las solicitudes a. PutBucketTagging Para mantener el control sobre cómo se etiqueta un depósito, debes limitar el acceso a PutBucketTagging y DeleteBucketTagging.
