Enfoques de gestión dinámica de permisos - AWS Transfer Family
Descripción de la arquitectura de permisos de Transfer FamilyDos enfoques para la administración de permisosImplementación de políticas de sesiónImplementación por tipo de usuarioEjemplo: simplificar la administración de funciones con políticas de sesión

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.

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

  2. 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:

Reemplazo 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, consulteCreación de una política de sesión para un bucket de Amazon S3.

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.

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.

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 llamadocompany-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:

    JSON
    {
  "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"
    }
  ]
}

  2. Cree una plantilla de política de sesión que restrinja el acceso a la carpeta del usuario:

    JSON
    {
  "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}*"
        }
      }
    }
  ]
}

  3. 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élvala como parte de la respuesta de la función Lambda durante la autenticación o guárdela AWS Secrets Manager como una clave denominada «Política» junto con las credenciales del usuario

    • Directorio principal: /company-transfers/${transfer:Username}/