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.
# Administrar los controles de acceso
Puede controlar el acceso de un usuario a AWS Transfer Family los recursos mediante una política AWS Identity and Access Management (de IAM). Una política de IAM es una declaración, normalmente en formato JSON, que permite un determinado nivel de acceso a un recurso. Puede utilizar una política de IAM para definir las operaciones con archivos que desea permitir o prohibir a sus usuarios. También puede utilizar una política de IAM para definir el bucket o buckets de Amazon S3 a los que los usuarios puedan tener acceso. Para especificar estas políticas para los usuarios, debe crear un rol de IAM AWS Transfer Family que tenga asociadas la política de IAM y la relación de confianza.
A cada usuario se le asigna un rol de IAM. *El tipo de función de IAM que se AWS Transfer Family utiliza se denomina función de servicio.* Cuando un usuario inicia sesión en su servidor, AWS Transfer Family asume la función de IAM asignada al usuario. Para obtener información sobre cómo crear un rol de IAM que proporcione a un usuario acceso a un bucket de Amazon S3, consulte [Crear un rol para delegar permisos a un AWS servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la Guía del *usuario de IAM*.
Puede conceder acceso de solo escritura a los objetos de Amazon S3 mediante determinados permisos de una política de IAM. Para obtener más información, consulte [Otorgue la capacidad de escribir y enumerar únicamente archivos](configure-storage.md#headobject-access-denied).
El blog sobre AWS almacenamiento contiene una publicación en la que se detalla cómo configurar el acceso con privilegios mínimos. Para obtener más información, consulte [Implementación del acceso con privilegios mínimos en un AWS Transfer Family flujo de trabajo](https://aws.amazon.com/blogs//storage/implementing-least-privilege-access-in-an-aws-transfer-family-workflow/).
**nota**
Si su bucket de Amazon S3 está cifrado con AWS Key Management Service (AWS KMS), debe especificar permisos adicionales en su política. Para obtener más información, consulte [Protección y cifrado de datos](encryption-at-rest.md). Además, puede consultar más información sobre [las políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session.html) en la *Guía del usuario de IAM*.
**Topics**
+ [Autorización del acceso de lectura y escritura a un bucket de Amazon S3](users-policies-all-access.md)
+ [Creación de una política de sesión para un bucket de Amazon S3](users-policies-session.md)
+ [Enfoques de gestión dinámica de permisos](dynamic-permission-management.md)
# Autorización del acceso de lectura y escritura a un bucket de Amazon S3
En esta sección se describe cómo crear una política de IAM que permita el acceso de escritura y lectura a un bucket de Amazon S3 específico. Al asignar un rol de IAM que tenga esta política de IAM a su usuario, este tendrá read/write acceso al bucket de Amazon S3 especificado.
La política siguiente proporciona acceso de lectura y escritura por programación a un bucket de Amazon S3. Los estados de cuenta `GetObjectACL` y `PutObjectACL` solo son obligatorios si necesitas habilitar el acceso entre cuentas. Es decir, el servidor de Transfer Family necesita acceder a un bucket de otra cuenta.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid":"ReadWriteS3",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:GetObjectTagging",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObjectVersion",
"s3:GetObjectVersionTagging",
"s3:GetObjectACL",
"s3:PutObjectACL"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/*"]
}
]
}
```
La acción `ListBucket` requiere permiso sobre el bucket en sí. Las acciones `PUT`, `GET` y `DELETE` requieren permisos de objeto. Como se trata de recursos diferentes, se especifican mediante distintos nombres de recursos de Amazon (ARNs).
Para reducir aún más el ámbito de acceso de sus usuarios y restringirlo al directorio `home` del bucket de Amazon S3 especificado, consulte [Creación de una política de sesión para un bucket de Amazon S3](users-policies-session.md).
# Creación de una política de sesión para un bucket de Amazon S3
Una *política de sesión* es una política AWS Identity and Access Management (IAM) que restringe a los usuarios a determinadas partes de un bucket de Amazon S3. Esto se consigue evaluando el acceso en tiempo real.
**nota**
Las políticas de sesión solo se utilizan con Amazon S3. En el caso de Amazon EFS, se utilizan los permisos de archivos POSIX para limitar el acceso.
Puede usar una política de sesión cuando sea necesario proporcionar a un grupo de usuarios el mismo acceso a una parte determinada del bucket de Amazon S3. Por ejemplo, puede que un grupo de usuarios solo requiera acceso al directorio `home`. Ese grupo de usuarios comparte el mismo rol de IAM.
**nota**
La longitud máxima de una ruta es 2048 caracteres. Para obtener más información, consulte el [Parámetro de solicitud de política](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#API_CreateUser_RequestSyntax) correspondiente a la acción de `CreateUser` en la *Referencia de la API*.
Para crear una política de sesión, utilice las variables siguientes en su política de IAM:
+ `${transfer:HomeBucket}`
+ `${transfer:HomeDirectory}`
+ `${transfer:HomeFolder}`
+ `${transfer:UserName}`
**importante**
No puede usar las variables anteriores en Políticas administradas. Tampoco puede utilizarlas como variables de política en una definición de roles de IAM. Puede crear estas variables en una política de IAM y especificarlas directamente al configurar el usuario. Tampoco puede utilizar la variable `${aws:Username}` en esta política de sesión. Esta variable hace referencia a un nombre de usuario de IAM, no al nombre de usuario que AWS Transfer Family necesita.
## Ejemplo de política de sesión
El código siguiente muestra un ejemplo de política de sesión.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowListingOfUserFolder",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::${transfer:HomeBucket}"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"${transfer:HomeFolder}/*",
"${transfer:HomeFolder}"
]
}
}
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion",
"s3:GetObjectACL",
"s3:PutObjectACL"
],
"Resource": "arn:aws:s3:::${transfer:HomeDirectory}/*"
}
]
}
```
**nota**
En el ejemplo de política anterior se supone que los directorios principales de los usuarios están configurados para incluir una barra al final, lo que significa que se trata de un directorio. Si, por el contrario, establece el `HomeDirectory` de un usuario sin la barra final, debe incluirlo como parte de su política.
En el ejemplo anterior de política, anote el uso de los parámetros de la política `transfer:HomeFolder`, `transfer:HomeBucket` y `transfer:HomeDirectory`. Estos parámetros se establecen para el `HomeDirectory` que está configurado para el usuario, tal y como se describe en [HomeDirectory](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectory)y[Implementación de su método de API Gateway](authentication-api-gateway.md#authentication-api-method). Estos parámetros tienen las siguientes definiciones:
+ El parámetro `transfer:HomeBucket` se sustituye por el primer componente de `HomeDirectory`.
+ El parámetro `transfer:HomeFolder` se sustituye por las partes restantes del parámetro `HomeDirectory`.
+ Se ha eliminado la barra inclinada inicial (`/`) del parámetro `transfer:HomeDirectory` para que pueda usarse como parte de un nombre de recurso de Amazon (ARN) de S3 en una declaración de `Resource`.
**nota**
Si utiliza directorios lógicos, es decir, el `homeDirectoryType` del usuario es `LOGICAL`, estos parámetros de política (`HomeBucket`, `HomeDirectory` y `HomeFolder`) no son compatibles.
Por ejemplo, supongamos que el parámetro `HomeDirectory` que está configurado para el usuario de Transfer Family es `/home/bob/amazon/stuff/`.
+ `transfer:HomeBucket` toma el valor de `/home`.
+ `transfer:HomeFolder` toma el valor de `/bob/amazon/stuff/`.
+ `transfer:HomeDirectory` se convierte en `home/bob/amazon/stuff/`.
El primer `"Sid"` permite al usuario enumerar todos los directorios a partir de `/home/bob/amazon/stuff/`.
El segundo `"Sid"` limita los accesos del usuario `put` y `get` a la misma ruta, `/home/bob/amazon/stuff/`.
Al aplicar la política anterior, cuando un usuario inicia sesión solo tiene acceso a los objetos de su directorio de inicio. En el momento de la conexión, AWS Transfer Family reemplaza estas variables por los valores adecuados para el usuario. Esto facilita la aplicación de los mismos documentos de política a múltiples usuarios. Este método reduce el trabajo de administración de roles y políticas de IAM para el acceso de los usuarios al bucket de Amazon S3.
También puede utilizar una política de sesión para personalizar el acceso de cada usuario en función de los requisitos de su negocio. Para obtener más información, consulte [los permisos para AssumeRole AssumeRoleWith SAML y AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_assumerole.html) la Guía del *usuario de IAM*.
**nota**
AWS Transfer Family almacena el JSON de la política, en lugar del nombre de recurso de Amazon (ARN) de la política. Por lo tanto, cuando cambias la política en la consola de IAM, tienes que volver a la AWS Transfer Family consola y actualizar a tus usuarios con el contenido más reciente de la política. Puede actualizar el usuario en la pestaña **Información de la política** en la sección **Configuración de usuario**.
Si utiliza la AWS CLI, puede utilizar el siguiente comando para actualizar la política.
```
aws transfer update-user --server-id server --user-name user --policy \
"$(aws iam get-policy-version --policy-arn policy --version-id version --output json)"
```
## Sustituciones anidadas de las políticas de sesión
Las sustituciones anidadas no se realizan en las políticas de sesión de Transfer Family. Las políticas de sesión pueden usar variables anidadas, como. `${transfer:HomeDirectory}` Cuando se procesa la política, es posible que la variable externa (por ejemplo,`${transfer:HomeDirectory}`) se sustituya por un valor que contenga otra variable (por ejemplo, \$1`amzn-s3-demo-bucket:/$(transfer:UserName}`). Sin embargo, la variable anidada ya no se sustituye por el nombre de usuario real (por ejemplo, **johndoe**).
Esto significa que, al crear políticas de sesión para Transfer Family, debe tener en cuenta este comportamiento y asegurarse de que la estructura de políticas y el uso de variables estén diseñados en consecuencia. Es posible que las variables anidadas no se resuelvan como se esperaba y que la política no conceda los permisos previstos. Es importante probar y validar minuciosamente las políticas de sesión para garantizar que funcionan según lo esperado. Este comportamiento es una consideración clave a la hora de implementar el control de acceso y los permisos para su entorno de Transfer Family.
Una solución a este problema es utilizar el nombre real del bucket de Amazon S3 en la política de sesión. Así, por ejemplo, en lugar de especificarlo `${transfer:HomeDirectory}` en su política de sesión, utilice lo siguiente, donde amzn-s3-demo-bucket es su bucket real:. `${amzn-s3-demo-bucket/transfer:UserName}`
# Enfoques de gestión dinámica de permisos
## Descripción de la arquitectura de permisos de Transfer Family
AWS Transfer Family admite la gestión dinámica de permisos mediante políticas de sesión, que permiten restringir los permisos efectivos de las funciones de IAM en tiempo de ejecución. Este enfoque funciona tanto para los usuarios gestionados por el servicio como para los usuarios de proveedores de identidad personalizados, pero solo se admite cuando se transfieren archivos hacia o desde Amazon S3 (no Amazon EFS).
Cada AWS Transfer Family usuario opera con un modelo de permisos que consiste en:
1. *Función básica de IAM*: define los permisos fundamentales del usuario
1. *Política de sesión opcional*: restringe (reduce el alcance) los permisos básicos en tiempo de ejecución
Los permisos efectivos son la intersección de los permisos del rol base y los permisos de la política de sesión. Las políticas de sesión solo pueden restringir los permisos; no pueden conceder permisos adicionales más allá de lo que permite el rol base.
Esta arquitectura se aplica a ambos tipos de usuarios:
+ *Usuarios gestionados por el servicio*: las políticas de sesión se pueden configurar directamente en la configuración del usuario
+ *Usuarios proveedores de identidad personalizados*: las políticas de sesión pueden devolverse como parte de la respuesta de autenticación o almacenarse en AWS Secrets Manager
## Dos enfoques para la administración de permisos
Al diseñar los permisos para los usuarios de Transfer Family que necesitan patrones de acceso únicos, puede elegir entre dos enfoques principales:
Un rol por usuario
Cree un rol de IAM independiente para cada usuario de Transfer Family con permisos específicos adaptados a las necesidades de ese usuario. Utilice este enfoque cuando:
+ Cada usuario requiere permisos muy diferentes
+ La administración de permisos está a cargo de diferentes personas de su organización
+ Necesita un control detallado sobre el acceso de los usuarios individuales
Función compartida con políticas de sesión
Utilice un único rol de IAM con amplios permisos (como el acceso a un bucket completo de Amazon S3 que contenga varios directorios principales de usuarios) y aplique políticas de sesión para restringir a cada usuario a su área específica. Este enfoque reduce considerablemente la sobrecarga administrativa en comparación con la administración de funciones independientes para cada usuario. Utilice este enfoque cuando:
+ Los usuarios necesitan tipos de acceso similares pero a recursos diferentes (por ejemplo, todos los usuarios necesitan read/write acceso, pero cada uno solo a su propia carpeta)
+ Desea simplificar la administración de funciones y evitar la creación de docenas o cientos de funciones individuales
+ Los usuarios solo deben acceder a sus directorios principales designados dentro de un depósito compartido
+ La administración de permisos está centralizada en su organización
Por ejemplo, en lugar de crear roles separados para los usuarios «alice», «bob» y «charlie», puede crear un rol con acceso a todo el `s3://company-transfers/` grupo y, a continuación, usar las políticas de sesión para restringir a alice `s3://company-transfers/alice/``s3://company-transfers/bob/`, bob to, etc.
## Implementación de políticas de sesión
Las políticas de sesión funcionan restringiendo los permisos efectivos de la función de IAM básica asignada a un usuario. Los permisos finales son la intersección de los permisos del rol y los permisos de la política de sesión.
Puede implementar políticas de sesión dinámicas de dos maneras:
Substitución de variables
Utilice variables de política de Transfer Family como `${transfer:Username}``${transfer:HomeDirectory}`, y `${transfer:HomeBucket}` en las políticas de sesión. Estas variables se sustituyen automáticamente por los valores reales en tiempo de ejecución. Para obtener más información sobre estas variables, consulte[Creación de una política de sesión para un bucket de Amazon S3](users-policies-session.md).
Generación dinámica
En el caso de los proveedores de identidades personalizados, genere políticas de sesión on-the-fly como parte de la respuesta de autenticación desde la función Lambda o el método API Gateway. Este enfoque le permite crear políticas altamente personalizadas basadas en los atributos de los usuarios, las pertenencias a grupos o las fuentes de datos externas en el momento de la autenticación.
También puede almacenar las políticas de sesión generadas previamente incluyendo una clave denominada `Policy` JSON como valor de la política de sesión. AWS Secrets Manager Esto le permite utilizar la misma función general de IAM en varios usuarios y, al mismo tiempo, mantener los controles de acceso específicos de cada usuario.
**nota**
Las políticas de sesión solo se admiten para las transferencias de archivos desde y hacia Amazon S3. No se aplican a los sistemas de archivos Amazon EFS. En el caso de Amazon EFS, los permisos se rigen UID/GID y los bits de permiso se aplican dentro del propio sistema de archivos.
## Implementación por tipo de usuario
Usuarios administrados por servicios
Para los usuarios gestionados por el servicio, puede especificar las políticas de sesión directamente en la configuración del usuario a través de la AWS Transfer Family consola, la API o la CLI. Para obtener más información, consulte [Trabajar con usuarios de servicios administrados](service-managed-users.md).
Proveedores de identidad personalizados
Para los usuarios de proveedores de identidades personalizados, puede proporcionar políticas de sesión de dos maneras:
+ AWS Secrets Manager Mediante la inclusión de una clave nombrada `Policy` junto con la política de sesión como valor
+ Directamente en la respuesta de la función Lambda o en la respuesta de API Gateway como parte del resultado de la autenticación
Para obtener más información, consulte [Solución de proveedor de identidad personalizada](custom-idp-toolkit.md).
## Ejemplo: simplificar la administración de funciones con políticas de sesión
Este ejemplo demuestra cómo la administración dinámica de permisos puede reducir significativamente la sobrecarga administrativa y, al mismo tiempo, mantener la seguridad.
### Escenario
Su organización tiene 50 usuarios que necesitan acceso SFTP para transferir archivos. Cada usuario solo debe acceder a su propia carpeta dentro de un bucket compartido de Amazon S3 llamado`company-transfers`. Sin políticas de sesión, tendría que crear 50 funciones de IAM independientes.
Enfoque tradicional (sin políticas de sesión)
+ Cree 50 funciones de IAM:`TransferRole-Alice`,`TransferRole-Bob`,`TransferRole-Charlie`, etc.
+ Cada función tiene permisos específicos solo para la carpeta de ese usuario
+ La administración de los permisos requiere actualizar los roles individuales
+ Para añadir nuevos usuarios es necesario crear nuevos roles
Enfoque dinámico (con políticas de sesión)
+ Cree 1 función de IAM: `TransferRole-Shared` con amplios permisos para todo el segmento
+ Utilice las políticas de sesión para restringir a cada usuario a su carpeta específica durante el tiempo de ejecución
+ La administración de los permisos requiere actualizar un rol o una plantilla de política de sesión
+ La adición de nuevos usuarios no requiere nuevos roles, solo la configuración del usuario
### Implementación
Así es como implementaría el enfoque dinámico (utilizando el `company-transfers` bucket como ejemplo para reemplazarlo por su bucket de Amazon S3 real):
**Para implementar la administración dinámica de permisos**
1. Cree un rol de IAM compartido con amplios permisos de Amazon S3:
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::company-transfers/*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::company-transfers"
}
]
}
```
1. Cree una plantilla de política de sesión que restrinja el acceso a la carpeta del usuario:
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::company-transfers/${transfer:Username}/*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::company-transfers",
"Condition": {
"StringLike": {
"s3:prefix": "${transfer:Username}*"
}
}
}
]
}
```
1. Configure cada usuario con:
+ La función de IAM compartida
+ La política de sesión se aplicó de la siguiente manera:
+ *Usuarios gestionados por el servicio*: utilice la API o la CLI para aplicar el JSON mediante el parámetro Policy al crear o modificar usuarios (la consola solo ofrece opciones de políticas predefinidas)
+ *Usuarios de proveedores de identidad personalizados*: devuélvalos como parte de la respuesta de la función Lambda durante la autenticación o guárdelos AWS Secrets Manager como una clave denominada «Política» junto con las credenciales del usuario
+ Directorio principal: `/company-transfers/${transfer:Username}/`