Controllo degli accessi basato su tag Lake Formation - AWS Lake Formation
Come funziona il controllo degli accessi basato su tag Lake Formation

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à.

Controllo degli accessi basato su tag Lake Formation

Il controllo degli accessi basato su tag di Lake Formation (LF-TBAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. In Lake Formation, questi attributi sono chiamati LF-tag. È possibile allegare tag LF alle risorse del Data Catalog e concedere autorizzazioni ai responsabili di Lake Formation su tali risorse utilizzando questi tag LF. Lake Formation consente operazioni su tali risorse quando il principale ha concesso l'accesso a un valore di tag che corrisponde al valore del tag della risorsa.

LF-TBAC è utile in ambienti in rapida crescita e aiuta in situazioni in cui la gestione delle politiche diventa complicata.

LF-TBAC è il metodo consigliato da utilizzare per concedere le autorizzazioni di Lake Formation quando è presente un numero elevato di oggetti Data Catalog, inclusi cataloghi federati, database, tabelle e viste. Lake Formation supporta il controllo degli accessi basato su tag per cataloghi federati di tabelle Amazon S3, Amazon Redshift data warehouse e fonti di dati federate come Amazon DynamoDB SQL Server e Snowflake.

Nota

I tag IAM non sono uguali ai tag LF. Questi tag non sono intercambiabili. I tag LF vengono utilizzati per concedere i permessi di Lake Formation e i tag IAM vengono utilizzati per definire le politiche IAM.

Come funziona il controllo degli accessi basato su tag Lake Formation

Ogni tag LF è una coppia chiave-valore, ad esempio o. department=sales classification=restricted Una chiave può avere più valori definiti, ad esempio. department=sales,marketing,engineering,finance

Per utilizzare il metodo LF-TBAC, gli amministratori del data lake e i data engineer eseguono le seguenti attività.

Attività Dettagli dell'attività

1. Definire le proprietà e le relazioni dei tag LF.

 -

2. Crea i creatori di tag LF in Lake Formation.

 Aggiungere creatori di tag LF

3. Crea il tag LF in Lake Formation.

 Creazione di tag LF

4. Assegna i tag LF alle risorse del Data Catalog.

 Assegnazione di tag LF alle risorse del Data Catalog

5. Concedi le autorizzazioni ad altri principali per assegnare i tag LF alle risorse, opzionalmente con l'opzione grant.

 Gestione dei permessi per i valori del tag LF

6. Concedi le espressioni dei tag LF ai principali, opzionalmente con l'opzione grant.

 Concessione delle autorizzazioni per il data lake utilizzando il metodo LF-TBAC

7. (Consigliato) Dopo aver verificato che i principali abbiano accesso alle risorse corrette tramite il metodo LF-TBAC, revocate le autorizzazioni concesse utilizzando il metodo della risorsa denominata.

 -

Si consideri il caso in cui è necessario concedere le autorizzazioni a tre principali su tre database e sette tabelle.

Tre figure di utenti sono a sinistra, disposte verticalmente. A destra ci sono tre database denominati A, B e C, disposti verticalmente. Il database A ha due tabelle denominate A.1 e A.2, il database B ha le etichette delle tabelle B.1 e B.2 e il database C ha tre tabelle etichettate C.1, C.2 e C.3. Diciassette frecce collegano gli utenti ai database e alle tabelle, indicando agli utenti le concessioni sui database e le tabelle.

Per ottenere le autorizzazioni indicate nel diagramma precedente utilizzando il metodo named resource, è necessario concedere 17 concessioni, come segue (in pseudo-codice).

GRANT CREATE_TABLE ON Database A TO PRINCIPAL 1
GRANT SELECT, INSERT ON Table A.1 TO PRINCIPAL 1
GRANT SELECT, INSERT ON Table A.2 TO PRINCIPAL 1
GRANT SELECT, INSERT ON Table B.2 TO PRINCIPAL 1
...
GRANT SELECT, INSERT ON Table A.2 TO PRINCIPAL 2
GRANT CREATE_TABLE ON Database B TO PRINCIPAL 2
...
GRANT SELECT, INSERT ON Table C.3 TO PRINCIPAL 3

Considerate ora come concedereste le autorizzazioni utilizzando LF-TBAC. Il diagramma seguente indica che sono stati assegnati tag LF a database e tabelle e che sono state concesse le autorizzazioni sui tag LF ai principali.

In questo esempio, i tag LF rappresentano aree del data lake che contengono analisi per diversi moduli di una suite di applicazioni ERP (Enterprise Resource Planning). È possibile controllare l'accesso ai dati di analisi per i vari moduli. Tutti i tag LF hanno la chiave module e i valori possibili SalesOrders, e. Customers Un esempio di tag LF ha il seguente aspetto:

module=Sales

Il diagramma mostra solo i valori del tag LF.

Come nel diagramma precedente, tre figure di utenti sono a sinistra, disposte verticalmente, mentre a destra ci sono tre database etichettati A, B e C, disposti verticalmente. Il database A ha due tabelle etichettate A.1 e A.2, il database B ha le tabelle con etichette B.1 e B.2 e il database C ha tre tabelle etichettate C.1, C.2 e C.3. Non ci sono frecce tra gli utenti e i database e le tabelle. Invece, le «bandiere» etichettate accanto agli utenti indicano che all'utente 1 sono state concesse le vendite LF-Tag Sales and Customers, all'utente 2 sono state concesse le LF-Tag Orders e all'utente 3 sono state concesse le LF-Tag Customers. I flag accanto ai database e alle tabelle indicano le seguenti assegnazioni di tag LF a database e tabelle: Database A: Vendite. Tabella A1: un contrassegno oscurato indica che Sales è stato ereditato dal database A. Tabella A2: Ordini, mentre un contrassegno oscurato indica che Sales è stato ereditato dal database A. Database B: Ordini. La Tabella B.1 e B.2 ereditano gli ordini, mentre la Tabella B.2 contiene i Clienti. Il database C ha clienti e le tabelle C.1, C.2 e C.3 ereditano clienti. Le tabelle C non hanno altre assegnazioni.
Assegnazione di tag alle risorse e all'ereditarietà di Data Catalog

Le tabelle ereditano i tag LF dai database e le colonne ereditano i tag LF dalle tabelle. I valori ereditati possono essere sovrascritti. Nel diagramma precedente, i tag LF oscurati vengono ereditati.

A causa dell'ereditarietà, l'amministratore del data lake deve effettuare solo le seguenti cinque assegnazioni di tag LF alle risorse (in pseudo-codice).

ASSIGN TAGS module=Sales TO database A
ASSIGN TAGS module=Orders TO table A.2
ASSIGN TAGS module=Orders TO database B
ASSIGN TAGS module=Customers TO table B.2
ASSIGN TAGS module=Customers TO database C
Contributi di tag ai committenti

Dopo aver assegnato i tag LF ai database e alle tabelle, l'amministratore del data lake deve concedere solo quattro tag LF ai principali, come segue (in pseudo-codice).

GRANT TAGS module=Sales TO Principal 1
GRANT TAGS module=Customers TO Principal 1
GRANT TAGS module=Orders TO Principal 2
GRANT TAGS module=Customers TO Principal 3

Ora, un principale con il tag module=Sales LF può accedere alle risorse del Data Catalog con il tag LF (ad esempio, il database A), un principale con il module=Sales tag LF può accedere alle risorse con il tag LF e così via. module=Customers module=Customers

I comandi di concessione precedenti sono incompleti. Questo perché, sebbene indichino tramite LF-Tags le risorse del Data Catalog su cui i responsabili hanno i permessi, non indicano esattamente quali SELECT permessi di Lake Formation (ad esempioALTER) i principali hanno su tali risorse. Pertanto, i seguenti comandi in pseudo-codice sono una rappresentazione più accurata del modo in cui le autorizzazioni di Lake Formation vengono concesse alle risorse del Data Catalog tramite i tag LF.

GRANT (CREATE_TABLE ON DATABASES) ON TAGS module=Sales TO Principal 1
GRANT (SELECT, INSERT ON TABLES)  ON TAGS module=Sales TO Principal 1
GRANT (CREATE_TABLE ON DATABASES) ON TAGS module=Customers TO Principal 1
GRANT (SELECT, INSERT ON TABLES)  ON TAGS module=Customers TO Principal 1
GRANT (CREATE_TABLE ON DATABASES) ON TAGS module=Orders TO Principal 2
GRANT (SELECT, INSERT ON TABLES)  ON TAGS module=Orders TO Principal 2
GRANT (CREATE_TABLE ON DATABASES) ON TAGS module=Customers TO Principal 3
GRANT (SELECT, INSERT ON TABLES)  ON TAGS module=Customers TO Principal 3
Mettere insieme: autorizzazioni risultanti sulle risorse

Dati i tag LF assegnati ai database e alle tabelle nel diagramma precedente e i tag LF concessi ai principali del diagramma, la tabella seguente elenca i permessi di Lake Formation che i principali hanno sui database e sulle tabelle.

Principale Autorizzazioni concesse tramite LF-Tags
Principale 1

  • CREATE_TABLEsul database A

  • SELECT, INSERT nella tabella A.1

  • SELECT, INSERT nella tabella B.2

  • CREATE_TABLEnel database C

  • SELECT, INSERT nella tabella C.1

  • SELECT, INSERT nella tabella C.2

  • SELECT, INSERT nella tabella C.3
Principal 2

  • SELECT, INSERT nella tabella A.2

  • CREATE_TABLEnel database B

  • SELECT, INSERT nella tabella B.1
Principal 3

  • SELECT, INSERT nella tabella B.2

  • CREATE_TABLEnel database C

  • SELECT, INSERT nella tabella C.1

  • SELECT, INSERT nella tabella C.2

  • SELECT, INSERT nella tabella C.3
Conclusione

In questo semplice esempio, utilizzando cinque operazioni di assegnazione e otto operazioni di concessione, l'amministratore del data lake è stato in grado di specificare 17 autorizzazioni. Quando ci sono decine di database e centinaia di tabelle, il vantaggio del metodo LF-TBAC rispetto al metodo delle risorse denominate diventa evidente. Nel caso ipotetico della necessità di concedere a ogni risorsa l'accesso principale, e n(P) dov'è il numero di principali e il numero di risorse: n(R)

  • Con il metodo Named Resource, il numero di sovvenzioni richieste è ✕. n(P) n(R)

  • Con il metodo LF-TBAC, utilizzando un singolo tag LF, il totale del numero di sovvenzioni ai committenti e di assegnazioni alle risorse è +. n(P) n(R)

Consulta anche
Argomenti