Questo post è stato scritto in collaborazione con Amy Tseng, Jack Lin e Regis Chow di BMO.

BMO è l'ottava banca più grande del Nord America per patrimonio. Fornisce servizi bancari personali e commerciali, mercati globali e servizi bancari di investimento a 8 milioni di clienti. Mentre continuano ad implementare la loro strategia Digital First per velocità, scalabilità ed eliminazione della complessità, sono sempre alla ricerca di modi per innovare, modernizzare e anche semplificare il controllo dell'accesso ai dati nel cloud. BMO ha accumulato dati finanziari sensibili e aveva bisogno di creare un ambiente analitico sicuro e performante. Una delle principali sfide della banca legate ai severi requisiti di sicurezza informatica è implementare la crittografia a livello di campo per le informazioni di identificazione personale (PII), il settore delle carte di pagamento (PCI) e i dati classificati come ad alto rischio per la privacy (HPR). I dati con questa classificazione protetta vengono archiviati in forma crittografata sia nel data warehouse che nel data lake. Solo gli utenti con le autorizzazioni richieste possono accedere ai dati in testo non crittografato.

Amazon RedShift è un servizio di data warehouse completamente gestito utilizzato da decine di migliaia di clienti per gestire l'analisi su larga scala. Amazon Redshift supporta la sicurezza leader del settore con gestione delle identità integrata e federazione per Single Sign-On (SSO) insieme all'autenticazione a più fattori. IL Spettro Amazon Redshift la funzionalità consente l'interrogazione diretta del tuo Amazon Simple Storage Service (Amazon S3) data Lake e molti clienti lo utilizzano per modernizzare la propria piattaforma dati.

Formazione AWS Lake è un servizio completamente gestito che semplifica la creazione, la protezione e la gestione dei data lake. Fornisce un controllo degli accessi granulare, tagging (controllo degli accessi basato su tag (TBAC)) e l'integrazione tra i servizi analitici. Consente di semplificare la governance degli oggetti del catalogo dati e di accedere ai dati protetti da servizi come Amazon Redshift Spectrum.

In questo post condividiamo la soluzione utilizzando Controllo degli accessi basato sui ruoli (RBAC) di Amazon Redshift ed AWS Lake Formation basato su tag controllo degli accessi per gli utenti federati per eseguire query sul tuo data Lake utilizzando Amazon Redshift Spectrum.

Caso d'uso

BMO aveva più di Petabyte (PB) di dati finanziari sensibili classificati come segue:

1. Informazioni di identificazione personale (PII)
2. Industria delle carte di pagamento (PCI)
3. Elevato rischio per la privacy (HPR)

La banca mira a archiviare i dati nel data warehouse Amazon Redshift e nel data Lake Amazon S3. Hanno una base di utenti finali ampia e diversificata che comprende vendite, marketing, rischio di credito e altre linee di business e personaggi:

1. Analisti aziendali
2. Ingegneri dei dati
3. Data scientist

È necessario applicare un controllo degli accessi granulare ai dati sia su Amazon Redshift che sui data Lake a cui si accede utilizzando Amazon Redshift Spectrum. La banca sfrutta servizi AWS come Colla AWS ed Amazon Sage Maker su questa piattaforma di analisi. Utilizzano inoltre un provider di identità (IdP) esterno per gestire la propria base utenti preferita e integrarla con questi strumenti di analisi. Gli utenti finali accedono a questi dati utilizzando client SQL e strumenti di business intelligence di terze parti.

Panoramica della soluzione

In questo post utilizzeremo dati sintetici molto simili ai dati BMO con dati classificati come PII, PCI o HPR. Utenti e gruppi esistono nell'IdP esterno. Questi utenti si federano per il Single Sign-On su Amazon Redshift utilizzando federazione IdP nativa. Definiremo le autorizzazioni utilizzando il controllo degli accessi basato sui ruoli Redshift (RBAC) per i ruoli utente. Per gli utenti che accedono ai dati nel data Lake utilizzando Amazon Redshift Spectrum, utilizzeremo le policy Lake Formation per il controllo degli accessi.

Soluzione tecnica

Per soddisfare le esigenze dei clienti per la protezione di diverse categorie di dati, è necessaria la definizione di più ruoli AWS IAM, che richiedono la conoscenza delle policy IAM e il loro mantenimento quando cambiano i limiti delle autorizzazioni.

In questo post mostriamo come abbiamo semplificato la gestione delle policy di classificazione dei dati con un numero minimo di ruoli Amazon Redshift AWS IAM allineati in base alla classificazione dei dati, invece di permutazioni e combinazioni di ruoli per linee di business e classificazioni dei dati. Altre organizzazioni (ad esempio, il Financial Service Institute [FSI]) possono trarre vantaggio dall'implementazione della sicurezza e della conformità dei dati da parte del BMO.

Nell'ambito di questo blog, i dati verranno caricati in Amazon S3. L'accesso ai dati è controllato utilizzando policy definite utilizzando Redshift RBAC per i corrispondenti gruppi di utenti del provider di identità e il controllo degli accessi basato su TAG verrà implementato utilizzando AWS Lake Formation per i dati su S3.

Architettura della soluzione

Il diagramma seguente illustra l'architettura della soluzione insieme ai passaggi dettagliati.

1. Utenti IdP con gruppi simili lob_risk_public, Lob_risk_pci, hr_publice hr_hpr vengono assegnati in IdP esterno (Identity Provider).
2. Ogni utente viene mappato sui ruoli locali Amazon Redshift inviati dall'IdP e inclusi aad:lob_risk_pci, aad:lob_risk_public, aad:hr_publice aad:hr_hpr in Amazon Redshift. Ad esempio, Utente1 che fa parte di Lob_risk_public ed hr_hpr concederà l'utilizzo del ruolo di conseguenza.
3. allegare iam_redshift_hpr, iam_redshift_pcipiie iam_redshift_public Ruoli AWS IAM nel cluster Amazon Redshift.
4. Database AWS Glue supportati su s3 (ad esempio, lobrisk,lobmarket,hr e le rispettive tabelle) sono citati in Amazon Redshift. Utilizzando Amazon Redshift Spectrum, puoi eseguire query su tabelle e database esterni (ad esempio, external_lobrisk_pci, external_lobrisk_public, external_hr_publice external_hr_hpr), creati utilizzando i ruoli AWS IAM iam_redshift_pcipii, iam_redshift_hpr, iam_redshift_public come mostrato nei passaggi della soluzione.
5. AWS Lake Formation viene utilizzato per controllare l'accesso agli schemi e alle tabelle esterni.
6. Utilizzando i tag AWS Lake Formation, applichiamo il controllo di accesso granulare a queste tabelle esterne per i ruoli AWS IAM (ad esempio, iam_redshift_hpr, iam_redshift_pcipiie iam_redshift_public).
7. Infine, concedi l'utilizzo di questi schemi esterni ai rispettivi ruoli Amazon Redshift.

Soluzione

Le sezioni seguenti illustrano l'implementazione della soluzione utilizzando dati sintetici.

Scarica i file di dati e inserisci i file nei bucket

Amazon S3 funge da data Lake scalabile e durevole su AWS. Utilizzando Data Lake puoi importare qualsiasi dato in formato aperto come CSV, JSON, PARQUET o ORC in Amazon S3 ed eseguire analisi sui tuoi dati.

Le soluzioni utilizzano file di dati CSV contenenti informazioni classificate come PCI, PII, HPR o pubbliche. È possibile scaricare i file di input utilizzando i collegamenti forniti di seguito. Utilizzando i file scaricati, caricali su Amazon S3 creando cartelle e file come mostrato nello screenshot seguente seguendo le istruzioni qui. Il dettaglio di ciascun file è fornito nel seguente elenco:

Registra i file nel Catalogo dati di AWS Glue utilizzando i crawler

Le seguenti istruzioni illustrano come registrare i file scaricati nel Catalogo dati di AWS Glue utilizzando i crawler. Organizziamo i file in database e tabelle utilizzando AWS Glue Data Catalog, come da passaggi seguenti. Si consiglia di consultare la documentazione per apprendere come impostare correttamente un Database di AWS Glue. I crawler possono automatizzare il processo di registrazione dei file scaricati nel catalogo anziché farlo manualmente. Creerai i seguenti database nel Catalogo dati di AWS Glue:

• lobrisk
• lobmarket
• hr

Passaggi di esempio per creare un database AWS Glue lobrisk i dati sono i seguenti:

• Vai Console AWS Glue.
• Quindi, selezionare Database per Catalogo dati.
• Scegli Aggiungi database e inserisci il nome dei database come lobrisk.
• Seleziona Crea database, come mostrato nella seguente schermata.

Ripeti i passaggi per creare altri database simili lobmarket ed hr.

Un crawler di AWS Glue esegue la scansione dei file di cui sopra e cataloga i relativi metadati nel Catalogo dati di AWS Glue. Il catalogo dati di Glue organizza questi dati di Amazon S3 in tabelle e database, assegnando colonne e tipi di dati in modo che i dati possano essere interrogati utilizzando SQL che Amazon Redshift Spectrum può comprendere. Si prega di rivedere il Documentazione di AWS Glue sulla creazione del Glue Crawler. Una volta terminata l'esecuzione del crawler AWS Glue, verranno visualizzati il ​​database e le tabelle seguenti:

• lobrisk
  • lob_risk_high_confidential_public
  • lob_risk_high_confidential
• lobmarket
  • credit_card_transaction_pci
  • credit_card_transaction_pci_public
• hr
  • customers_pii_hpr_public
  • customers_pii_hpr

Passaggi di esempio per creare un crawler AWS Glue lobrisk i dati sono i seguenti:

• Seleziona Crawlers per Catalogo dati nella console AWS Glue.
• Quindi, scegliere Crea cingolato. Fornisci il nome del crawler come lobrisk_crawler e scegli Avanti.

Assicurati di selezionare l'origine dati come Amazon S3 e sfoglia il percorso Amazon S3 per raggiungere il file lob_risk_high_confidential_public cartella e scegli un'origine dati Amazon S3.

• I crawler possono eseguire la scansione di più cartelle in Amazon S3. Scegliere Aggiungi un'origine dati e includere il percorso S3://<<Your Bucket >>/ lob_risk_high_confidential.

• Dopo aver aggiunto un'altra cartella Amazon S3, scegli Avanti.

• Quindi, creane uno nuovo Ruolo IAM nel Sicurezza della configurazione e socievole.
• Scegli Avanti.

• Seleziona il database di destinazione come lobrisk. Scegliere Avanti.

• Successivamente, sotto Reviewscegli Crea cingolato.
• Seleziona Esegui crawler. Questo crea due tabelle: lob_risk_high_confidential_public ed lob_risk_high_confidential sotto banca dati lobrisk.

Allo stesso modo, crea un crawler AWS Glue per lobmarket ed hr dati utilizzando i passaggi precedenti.

Crea ruoli AWS IAM

Utilizzando AWS IAM, crea i seguenti ruoli IAM con le autorizzazioni Amazon Redshift, Amazon S3, AWS Glue e AWS Lake Formation.

Puoi creare ruoli AWS IAM in questo servizio utilizzando questo collegamento. Successivamente, puoi collegare una policy gestita a questi ruoli IAM:

• iam_redshift_pcipii (Ruolo AWS IAM collegato al cluster Amazon Redshift)
  • AmazonRedshiftFullAccess
  • AmazonS3FullAccess
  • Aggiungi la policy in linea (Lakeformation-inline) per l'autorizzazione Lake Formation come segue:

    {
       "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "RedshiftPolicyForLF",
                "Effect": "Allow",
                "Action": [
                    "lakeformation:GetDataAccess"
                ],
                "Resource": "*"
            }
        ]

  • iam_redshift_hpr (Ruolo AWS IAM collegato al cluster Amazon Redshift): aggiungi quanto segue gestito:
    • AmazonRedshiftFullAccess
    • AmazonS3FullAccess
    • Aggiungi la policy in linea (Lakeformation-inline), creata in precedenza.
  • iam_redshift_public (Ruolo AWS IAM collegato al cluster Amazon Redshift): aggiungi la seguente policy gestita:
    • AmazonRedshiftFullAccess
    • AmazonS3FullAccess
    • Aggiungi la policy in linea (Lakeformation-inline), creata in precedenza.
  • LF_admin (Amministratore Lake Formation): aggiungere la seguente policy gestita:
    • AWSLakeFormationDataAdmin
    • AWSLakeFormationCrossAccountManager
    • AWSGlueConsoleFullAccess

Utilizza il controllo degli accessi basato su tag Lake Formation (LF-TBAC) per controllare l'accesso alle tabelle del catalogo dati di AWS Glue.

LF-TBAC è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. Utilizzando LF_admin L'amministratore di Lake Formation può creare tag LF, come indicato nei seguenti dettagli:

Segui le istruzioni seguenti per creare i tag Lake Formation:

• Accedi alla console Lake Formation (https://console.aws.amazon.com/lakeformation/) utilizzando il ruolo AWS IAM LF-Admin.
• Vai su Tag LF e autorizzazioni in Sezioni autorizzazioni.
• Seleziona Aggiungi tag LF.

• Crea i restanti tag LF come indicato nella tabella precedente. Una volta creati, troverai i tag LF come mostrato di seguito.

Assegna LF-TAG alle tabelle del catalogo AWS Glue

L'assegnazione dei tag Lake Formation alle tabelle implica in genere un approccio strutturato. L'amministratore di Lake Formation può assegnare tag in base a vari criteri, ad esempio origine dati, tipo di dati, dominio aziendale, proprietario dei dati o qualità dei dati. Hai la possibilità di allocare tag LF alle risorse del Catalogo dati, inclusi database, tabelle e colonne, consentendoti di gestire l'accesso alle risorse in modo efficace. L'accesso a queste risorse è limitato ai principali a cui sono stati assegnati i tag LF corrispondenti (o coloro a cui è stato concesso l'accesso tramite l'approccio delle risorse denominate).

Seguire le istruzioni nel collegamento fornito per assegnare LF-TAGS a Glue Tabelle del catalogo dati:

Segui le istruzioni seguenti per assegnare un tag LF alle tabelle di collegamento dalla console AWS come segue:

• Per accedere ai database in Lake Formation Console, vai al file Catalogo dati sezione e scegliere Database.
• Seleziona il lobrisk database e scegli Visualizza tabelle.
• Seleziona lob_risk_high_confidential tabella e modificare il file Tag LF.
• Assegna il Classificazione: HPR as Chiavi assegnate e valori come Sì. Selezionare Risparmi.

• Allo stesso modo, assegnare la Classificazione Le ed Valore in quanto non sensibile per il lob_risk_high_confidential_public tabella.

Seguire le istruzioni sopra per assegnare le tabelle alle tabelle rimanenti lobmarket ed hr banche dati.

Concedi le autorizzazioni alle risorse utilizzando un'espressione LF-Tag ai ruoli IAM Redshift

Grant select, descrivere Autorizzazione Lake Formation per i tag LF e il ruolo IAM Redshift utilizzando Lake Formation Administrator nella console Lake Formation. Per concedere seguire la documentazione.

Utilizza la tabella seguente per concedere il ruolo IAM corrispondente ai tag LF:

Segui le istruzioni seguenti per concedere le autorizzazioni ai tag LF e ai ruoli IAM:

• Scegli Autorizzazioni del data lake in Permessi sezione nella console AWS Lake Formation.
• Scegli Sovvenzioni. Selezionare Utenti IAM e ruoli in Principals.
• Nei tag LF o nelle risorse del catalogo seleziona Le as Classifications ed valori as non-sensitive.

• Quindi, selezionare Autorizzazioni della tabella as Seleziona e descrivi. Scegliere borse di studio.

Segui le istruzioni sopra riportate per i restanti tag LF e i relativi ruoli IAM, come mostrato nella tabella precedente.

Mappare i gruppi utenti IdP ai ruoli Redshift

In Redshift, utilizza la federazione IdP nativa per mappare i gruppi utenti IdP ai ruoli Redshift. Utilizzo Editor di query V2.

create role aad:rs_lobrisk_pci_role;
create role aad:rs_lobrisk_public_role;
create role aad:rs_hr_hpr_role;
create role aad:rs_hr_public_role;
create role aad:rs_lobmarket_pci_role;
create role aad:rs_lobmarket_public_role;

Creare schemi esterni

In Redshift, crea schemi esterni utilizzando i ruoli AWS IAM e i database del catalogo AWS Glue. Gli schemi esterni vengono creati secondo la classificazione dei dati utilizzando iam_role.

create external schema external_lobrisk_pci
from data catalog
database 'lobrisk'
iam_role 'arn:aws:iam::571750435036:role/iam_redshift_pcipii';

create external schema external_hr_hpr
from data catalog
database 'hr'
iam_role 'arn:aws:iam::571750435036:role/iam_redshift_hpr';

create external schema external_lobmarket_pci
from data catalog
database 'lobmarket'
iam_role 'arn:aws:iam::571750435036:role/iam_redshift_pcipii';

create external schema external_lobrisk_public
from data catalog
database 'lobrisk'
iam_role 'arn:aws:iam::571750435036:role/iam_redshift_public';

create external schema external_hr_public
from data catalog
database 'hr'
iam_role 'arn:aws:iam::571750435036:role/iam_redshift_public';

create external schema external_lobmarket_public
from data catalog
database 'lobmarket'
iam_role 'arn:aws:iam::571750435036:role/iam_redshift_public';

Verificare l'elenco delle tabelle

Verificare l'elenco delle tabelle in ogni schema esterno. Ogni schema elenca solo le tabelle a cui Lake Formation ha concesso IAM_ROLES utilizzato per creare uno schema esterno. Di seguito è riportato l'elenco delle tabelle nell'output v2 della modifica della query Redshift in alto a sinistra.

Concedi l'utilizzo su schemi esterni a diversi ruoli locali Redshift

In Redshift, concedi l'utilizzo su schemi esterni a diversi ruoli locali Redshift come segue:

grant usage on schema external_lobrisk_pci to role aad:rs_lobrisk_pci_role;
grant usage on schema external_lobrisk_public to role aad:rs_lobrisk_public_role;

grant usage on schema external_lobmarket_pci to role aad:rs_lobmarket_pci_role;
grant usage on schema external_lobmarket_public to role aad:rs_lobmarket_public_role;

grant usage on schema external_hr_hpr_pci to role aad:rs_hr_hpr_role;
grant usage on schema external_hr_public to role aad:rs_hr_public_role;

Verificare l'accesso allo schema esterno

Verifica l'accesso allo schema esterno utilizzando l'utente del team Lob Risk. Utente lobrisk_pci_user federato nel ruolo locale di Amazon Redshift rs_lobrisk_pci_role. Ruolo rs_lobrisk_pci_role ha accesso solo allo schema esterno external_lobrisk_pci.

set session_authorization to creditrisk_pci_user;
select * from external_lobrisk_pci.lob_risk_high_confidential limit 10;

Durante l'interrogazione della tabella da external_lobmarket_pci schema, vedrai che la tua autorizzazione è stata negata.

set session_authorization to lobrisk_pci_user;
select * from external_lobmarket_hpr.lob_card_transaction_pci;

Fornitura automatizzata dell'accesso di BMO

Collaborando con la banca, abbiamo sviluppato un quadro di fornitura degli accessi che consente alla banca di creare un archivio centrale degli utenti e dei dati a cui hanno accesso. Il file delle policy è archiviato in Amazon S3. Quando il file viene aggiornato, viene elaborato e vengono inseriti i messaggi Amazon SQS. AWS Lambda utilizzando API dati viene utilizzato per applicare il controllo degli accessi ai ruoli Amazon Redshift. Contemporaneamente, AWS Lambda viene utilizzato per automatizzare il controllo degli accessi basato su tag in AWS Lake Formation.

I vantaggi derivanti dall’adozione di questo modello sono stati:

1. Creato un processo di automazione scalabile per consentire l'applicazione dinamica delle policy in evoluzione.
2. Semplificazione degli accessi utente e dell'elaborazione con la gestione degli accessi aziendali esistente.
3. Ha consentito a ciascuna linea di business di limitare l'accesso ai dati sensibili di sua proprietà e di proteggere i dati e la privacy dei clienti a livello aziendale.
4. Semplificazione della gestione e della manutenzione dei ruoli AWS IAM riducendo notevolmente il numero di ruoli richiesti.

Con il recente rilascio di Amazon Redshift, l'integrazione con AWS Identity Center che consente la propagazione dell'identità attraverso il servizio AWS può essere sfruttata per semplificare e scalare questo processo implementazione.

Conclusione

In questo post, ti abbiamo mostrato come implementare solidi controlli di accesso per i dati sensibili dei clienti in Amazon Redshift, che erano impegnativi quando si cercava di definire molti ruoli AWS IAM distinti. La soluzione presentata in questo post dimostra come le organizzazioni possono soddisfare le esigenze di sicurezza e conformità dei dati con un approccio consolidato, utilizzando un set minimo di ruoli AWS IAM organizzati per classificazione dei dati anziché per linee di business.

Utilizzando l'integrazione nativa di Amazon Redshift con IdP esterno e definendo le policy RBAC sia in Redshift che in AWS Lake Formation, è possibile applicare controlli di accesso granulari senza creare un numero eccessivo di ruoli distinti. Ciò consente di sfruttare i vantaggi dell'accesso basato sui ruoli riducendo al minimo il sovraccarico amministrativo.

Altri istituti di servizi finanziari che desiderano proteggere i dati dei clienti e soddisfare le normative di conformità possono seguire un approccio RBAC consolidato simile. Un'attenta definizione delle policy, allineata alla sensibilità dei dati piuttosto che alle funzioni aziendali, può aiutare a ridurre la proliferazione dei ruoli AWS IAM. Questo modello bilancia sicurezza, conformità e gestibilità per la governance dei dati sensibili in Amazon Redshift e nelle piattaforme dati cloud più ampie.

In breve, un modello RBAC centralizzato basato sulla classificazione dei dati semplifica la gestione degli accessi garantendo al tempo stesso una solida sicurezza e conformità dei dati. Questo approccio può avvantaggiare qualsiasi organizzazione che gestisce informazioni sensibili sui clienti nel cloud.

Informazioni sugli autori

Amy Tseng è amministratore delegato dell'integrazione di dati e analisi (DnA) presso BMO. È una degli AWS Data Hero. Ha oltre 7 anni di esperienza nelle migrazioni cloud di dati e analisi in AWS. Fuori dal lavoro, Amy ama viaggiare e fare escursioni.

Jack Lin è Direttore dell'ingegneria sulla piattaforma dati presso BMO. Ha oltre 20 anni di esperienza nel campo dell'ingegneria delle piattaforme e dell'ingegneria del software. Fuori dal lavoro, Jack ama giocare a calcio, guardare le partite di calcio e viaggiare.

Regis Chow è un direttore dell'integrazione del DNA presso BMO. Ha oltre 5 anni di esperienza di lavoro nel cloud e gli piace risolvere i problemi attraverso l'innovazione in AWS. Al di fuori del lavoro, Regis ama tutte le cose all'aria aperta, è particolarmente appassionato di golf e cura del prato.

Nishchai JM è un esperto di analisi delle soluzioni Architect presso Amazon Web Services. È specializzato nella creazione di applicazioni Big-data e aiuta i clienti a modernizzare le proprie applicazioni su Cloud. Pensa che i dati siano petrolio nuovo e trascorre la maggior parte del suo tempo a ricavare intuizioni dai dati.

Harshida Patel è Principal Solutions Architect, Analytics con AWS.

Raghu Kuppala è un Analytics Specialist Solutions Architect con esperienza nel settore dei database, del data warehousing e dell'analisi. Al di fuori del lavoro, gli piace provare cucine diverse e trascorrere del tempo con la famiglia e gli amici.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://aws.amazon.com/blogs/big-data/how-bmo-improved-data-security-with-amazon-redshift-and-aws-lake-formation/