Approcci di gestione dinamica delle autorizzazioni - AWS Transfer Family
Comprendere l'architettura delle autorizzazioni Transfer FamilyDue approcci alla gestione delle autorizzazioniImplementazione delle politiche diImplementazione per tipo di utenteEsempio: semplificazione della gestione dei ruoli con policy di sessione

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Approcci di gestione dinamica delle autorizzazioni

Comprendere l'architettura delle autorizzazioni Transfer Family

AWS Transfer Family supporta la gestione dinamica delle autorizzazioni tramite policy di sessione, che consentono di limitare le autorizzazioni effettive dei ruoli IAM in fase di esecuzione. Questo approccio funziona sia per gli utenti gestiti dal servizio che per gli utenti di provider di identità personalizzati, ma è supportato solo per il trasferimento di file da o verso Amazon S3 (non Amazon EFS).

Ogni AWS Transfer Family utente opera con un modello di autorizzazione composto da:

  1. Ruolo IAM di base: definisce le autorizzazioni fondamentali per l'utente

  2. Politica di sessione opzionale: limita (riduce l'ambito) le autorizzazioni di base in fase di esecuzione

Le autorizzazioni effettive sono l'intersezione tra le autorizzazioni dei ruoli di base e le autorizzazioni dei criteri di sessione. I criteri di sessione possono solo limitare le autorizzazioni; non possono concedere autorizzazioni aggiuntive oltre a quelle consentite dal ruolo di base.

Questa architettura si applica a entrambi i tipi di utenti:

  • Utenti gestiti dal servizio: le politiche di sessione possono essere configurate direttamente nelle impostazioni dell'utente

  • Utenti con provider di identità personalizzati: i criteri di sessione possono essere restituiti come parte della risposta di autenticazione o archiviati in AWS Secrets Manager

Due approcci alla gestione delle autorizzazioni

Quando si progettano le autorizzazioni per gli utenti di Transfer Family che necessitano di modelli di accesso unici, è possibile scegliere tra due approcci principali:

Un ruolo per utente

Crea un ruolo IAM separato per ogni utente Transfer Family con autorizzazioni specifiche adattate alle esigenze di quell'utente. Utilizza questo approccio quando:

  • Ogni utente richiede autorizzazioni molto diverse

  • L'amministrazione delle autorizzazioni è gestita da diverse persone all'interno dell'organizzazione

  • È necessario un controllo granulare sull'accesso dei singoli utenti

Ruolo condiviso con le politiche di sessione

Utilizza un singolo ruolo IAM con ampie autorizzazioni (come l'accesso a un intero bucket Amazon S3 contenente più home directory di utenti) e applica policy di sessione per limitare ogni utente alla sua area specifica. Questo approccio riduce in modo significativo il sovraccarico amministrativo rispetto alla gestione di ruoli separati per ogni utente. Utilizza questo approccio quando:

  • Gli utenti necessitano di tipi di accesso simili ma a risorse diverse (ad esempio, tutti gli utenti devono read/write accedere, ma ognuno solo alla propria cartella)

  • Desideri semplificare la gestione dei ruoli ed evitare di creare dozzine o centinaia di ruoli singoli

  • Gli utenti devono accedere alle home directory designate solo all'interno di un bucket condiviso

  • L'amministrazione delle autorizzazioni è centralizzata all'interno dell'organizzazione

Ad esempio, invece di creare ruoli separati per gli utenti «alice», «bob» e «charlie», puoi creare un ruolo con accesso all'intero s3://company-transfers/ bucket, quindi utilizzare le policy di sessione per limitare alice as3://company-transfers/alice/, bob a e così s3://company-transfers/bob/ via.

Implementazione delle politiche di

Le policy di sessione funzionano limitando le autorizzazioni effettive del ruolo IAM di base assegnato a un utente. Le autorizzazioni finali sono l'intersezione tra le autorizzazioni del ruolo e le autorizzazioni della politica di sessione.

È possibile implementare politiche di sessione dinamiche in due modi:

Sostituzione variabile

Utilizza le variabili della politica di Transfer Family come ${transfer:Username}${transfer:HomeDirectory}, e ${transfer:HomeBucket} nelle politiche di sessione. Queste variabili vengono sostituite automaticamente con i valori effettivi in fase di esecuzione. Per ulteriori informazioni su queste variabili, vedereCreazione di una politica di sessione per un bucket Amazon S3.

Generazione dinamica

Per i provider di identità personalizzati, genera policy di sessione on-the-fly come parte della risposta di autenticazione dalla funzione Lambda o dal metodo API Gateway. Questo approccio consente di creare policy altamente personalizzate basate sugli attributi degli utenti, sull'appartenenza ai gruppi o su fonti di dati esterne al momento dell'autenticazione.

È inoltre possibile memorizzare le politiche di sessione pregenerate AWS Secrets Manager includendo una chiave denominata Policy con la politica di sessione JSON come valore. Ciò consente di utilizzare lo stesso ampio ruolo IAM tra più utenti mantenendo controlli di accesso specifici dell'utente.

Nota

Le policy di sessione sono supportate solo per i trasferimenti di file da e verso Amazon S3. Non si applicano ai file system Amazon EFS. Per Amazon EFS, le autorizzazioni sono regolate UID/GID e i bit di autorizzazione applicati all'interno del file system stesso.

Implementazione per tipo di utente

Utenti gestiti dal servizio

Per gli utenti gestiti dal servizio, è possibile specificare le politiche di sessione direttamente nella configurazione utente tramite la AWS Transfer Family console, l'API o la CLI. Per ulteriori informazioni, consulta Lavorare con utenti gestiti dal servizio.

Utenti di provider di identità personalizzati

Per gli utenti di provider di identità personalizzati, puoi fornire politiche di sessione in due modi:

  • AWS Secrets Manager Tramite l'inclusione di una chiave denominata Policy con la politica di sessione come valore

  • Direttamente nella risposta della funzione Lambda o nella risposta API Gateway come parte del risultato dell'autenticazione

Per ulteriori informazioni, consulta Soluzione personalizzata per provider di identità.

Esempio: semplificazione della gestione dei ruoli con policy di sessione

Questo esempio dimostra come la gestione dinamica delle autorizzazioni possa ridurre in modo significativo il sovraccarico amministrativo mantenendo al contempo la sicurezza.

Scenario

L'organizzazione ha 50 utenti che necessitano dell'accesso SFTP per trasferire i file. Ogni utente deve accedere alla propria cartella solo all'interno di un bucket Amazon S3 condiviso chiamato. company-transfers Senza policy di sessione, avresti bisogno di creare 50 ruoli IAM separati.

Approccio tradizionale (senza politiche di sessione)

  • Crea 50 ruoli IAM: TransferRole-Alice TransferRole-BobTransferRole-Charlie,, ecc.

  • Ogni ruolo dispone di autorizzazioni specifiche solo per la cartella di quell'utente

  • La gestione delle autorizzazioni richiede l'aggiornamento dei singoli ruoli

  • L'aggiunta di nuovi utenti richiede la creazione di nuovi ruoli

Approccio dinamico (con politiche di sessione)

  • Crea 1 ruolo IAM: TransferRole-Shared con ampie autorizzazioni per l'intero bucket

  • Utilizza le policy di sessione per limitare ogni utente alla sua cartella specifica in fase di esecuzione

  • La gestione delle autorizzazioni richiede l'aggiornamento di un ruolo o di un modello di politica di sessione

  • L'aggiunta di nuovi utenti non richiede nuovi ruoli, ma solo la configurazione dell'utente

Implementazione

Ecco come implementeresti l'approccio dinamico (usando il company-transfers bucket come esempio da sostituire con il tuo bucket Amazon S3 effettivo):

Per implementare la gestione dinamica delle autorizzazioni

  1. Crea un ruolo IAM condiviso con ampie autorizzazioni 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. Crea un modello di policy di sessione che limiti l'accesso alla cartella dell'utente:

    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. Configura ogni utente con:

    • Il ruolo IAM condiviso

    • La politica della sessione si applicava come segue:

      • Utenti gestiti dal servizio: utilizza l'API o la CLI per applicare il JSON tramite il parametro Policy durante la creazione o la modifica degli utenti (la console offre solo opzioni di policy predefinite)

      • Utenti di provider di identità personalizzati: lo restituiscono come parte della risposta della funzione Lambda durante l'autenticazione o lo archiviano AWS Secrets Manager come chiave denominata «Policy» insieme alle credenziali dell'utente

    • Cartella principale: /company-transfers/${transfer:Username}/