Cet article est co-écrit avec Amy Tseng, Jack Lin et Regis Chow de BMO.

BMO est la 8e banque en importance en Amérique du Nord en termes d'actifs. Elle fournit des services bancaires personnels et commerciaux, des marchés mondiaux et des services bancaires d'investissement à 13 millions de clients. Alors qu'ils continuent de mettre en œuvre leur stratégie Digital First visant la rapidité, l'évolutivité et l'élimination de la complexité, ils recherchent toujours des moyens d'innover, de moderniser et également de rationaliser le contrôle d'accès aux données dans le Cloud. BMO a accumulé des données financières sensibles et avait besoin de créer un environnement analytique sécurisé et performant. L'un des principaux défis de la banque liés aux exigences strictes en matière de cybersécurité est de mettre en œuvre un cryptage au niveau du champ pour les informations personnelles identifiables (PII), le secteur des cartes de paiement (PCI) et les données classées comme présentant un risque élevé pour la confidentialité (HPR). Les données avec cette classification de données sécurisée sont stockées sous forme cryptée à la fois dans l'entrepôt de données et dans leur lac de données. Seuls les utilisateurs disposant des autorisations requises sont autorisés à accéder aux données en texte clair.

Redshift d'Amazon est un service d'entrepôt de données entièrement géré que des dizaines de milliers de clients utilisent pour gérer les analyses à grande échelle. Amazon Redshift prend en charge une sécurité de pointe avec une gestion des identités intégrée et une fédération pour l'authentification unique (SSO) ainsi qu'une authentification multifacteur. Le Spectre Amazon Redshift La fonctionnalité permet d'interroger directement votre Amazon Simple Storage Service (Amazon S3) lac de données, et de nombreux clients l'utilisent pour moderniser leur plateforme de données.

Formation AWS Lake est un service entièrement géré qui simplifie la création, la sécurisation et la gestion des lacs de données. Il fournit un contrôle d'accès précis, un marquage (contrôle d'accès basé sur des balises (TBAC)) et l'intégration entre les services analytiques. Il permet de simplifier la gouvernance des objets du catalogue de données et d'accéder aux données sécurisées à partir de services comme Amazon Redshift Spectrum.

Dans cet article, nous partageons la solution en utilisant Contrôle d'accès basé sur les rôles Amazon Redshift (RBAC) ainsi que AWS Lake Formation basé sur des balises contrôle d'accès pour les utilisateurs fédérés afin d'interroger votre lac de données à l'aide d'Amazon Redshift Spectrum.

Cas d'utilisation

BMO détenait plus de pétaoctets (po) de données financières sensibles classées comme suit :

1. Informations personnellement identifiables (PII)
2. Industrie des cartes de paiement (PCI)
3. Risque élevé pour la confidentialité (HPR)

La banque vise à stocker les données dans son entrepôt de données Amazon Redshift et son lac de données Amazon S3. Ils disposent d'une base d'utilisateurs finaux large et diversifiée dans les domaines des ventes, du marketing, du risque de crédit et d'autres secteurs d'activité et personnalités :

1. Analystes d'affaires
2. Ingénieurs de données
3. Data scientists

Un contrôle d'accès précis doit être appliqué aux données sur Amazon Redshift et aux données du lac de données accessibles à l'aide d'Amazon Redshift Spectrum. La banque exploite les services AWS comme Colle AWS ainsi que Amazon Sage Maker sur cette plateforme d'analyse. Ils utilisent également un fournisseur d'identité externe (IdP) pour gérer leur base d'utilisateurs préférés et l'intégrer à ces outils d'analyse. Les utilisateurs finaux accèdent à ces données à l'aide de clients SQL tiers et d'outils de business intelligence.

Vue d'ensemble de la solution

Dans cet article, nous utiliserons des données synthétiques très similaires aux données de BMO avec des données classées PII, PCI ou HPR. Les utilisateurs et les groupes existent dans le fournisseur d'identité externe. Ces utilisateurs se fédèrent pour une authentification unique à Amazon Redshift à l'aide fédération d'IdP native. Nous définirons les autorisations à l'aide du contrôle d'accès basé sur les rôles (RBAC) Redshift pour les rôles d'utilisateur. Pour les utilisateurs accédant aux données du lac de données à l'aide d'Amazon Redshift Spectrum, nous utiliserons les stratégies Lake Formation pour le contrôle d'accès.

Solution technique

Pour mettre en œuvre les besoins des clients en matière de sécurisation de différentes catégories de données, cela nécessite la définition de plusieurs rôles AWS IAM, ce qui nécessite une connaissance des politiques IAM et leur maintien lorsque les limites d'autorisation changent.

Dans cet article, nous montrons comment nous avons simplifié la gestion des politiques de classification des données avec un nombre minimum de rôles Amazon Redshift AWS IAM alignés par classification des données, au lieu de permutations et de combinaisons de rôles par secteurs d'activité et classifications de données. D'autres organisations (par exemple, le Financial Service Institute [FSI]) peuvent bénéficier de la mise en œuvre par BMO de la sécurité et de la conformité des données.

Dans le cadre de ce blog, les données seront téléchargées dans Amazon S3. L'accès aux données est contrôlé à l'aide de politiques définies à l'aide de Redshift RBAC pour les groupes d'utilisateurs du fournisseur d'identité correspondants et le contrôle d'accès basé sur TAG sera mis en œuvre à l'aide d'AWS Lake Formation pour les données sur S3.

Architecture de la solution

Le diagramme suivant illustre l'architecture de la solution ainsi que les étapes détaillées.

1. Utilisateurs IdP avec des groupes comme lob_risk_public, Lob_risk_pci, hr_publicet hr_hpr sont attribués dans l’IdP externe (Identity Provider).
2. Chaque utilisateur est mappé aux rôles locaux Amazon Redshift envoyés par l'IdP, y compris aad:lob_risk_pci, aad:lob_risk_public, aad:hr_publicet aad:hr_hpr dans Amazon Redshift. Par exemple, User1 qui fait partie de Lob_risk_public ainsi que hr_hpr accordera l’utilisation du rôle en conséquence.
3. Attacher iam_redshift_hpr, iam_redshift_pcipiiet iam_redshift_public Rôles AWS IAM sur le cluster Amazon Redshift.
4. Bases de données AWS Glue sauvegardées sur s3 (par exemple, lobrisk,lobmarket,hr et leurs tableaux respectifs) sont référencés dans Amazon Redshift. À l'aide d'Amazon Redshift Spectrum, vous pouvez interroger ces tables et bases de données externes (par exemple, external_lobrisk_pci, external_lobrisk_public, external_hr_publicet external_hr_hpr), qui sont créés à l'aide des rôles AWS IAM iam_redshift_pcipii, iam_redshift_hpr, iam_redshift_public comme indiqué dans les étapes de solutions.
5. AWS Lake Formation est utilisé pour contrôler l'accès aux schémas et tables externes.
6. À l'aide des balises AWS Lake Formation, nous appliquons le contrôle d'accès précis à ces tables externes pour les rôles AWS IAM (par exemple, iam_redshift_hpr, iam_redshift_pcipiiet iam_redshift_public).
7. Enfin, accordez l'utilisation de ces schémas externes à leurs rôles Amazon Redshift.

Procédure pas à pas

Les sections suivantes vous guident dans la mise en œuvre de la solution à l'aide de données synthétiques.

Téléchargez les fichiers de données et placez vos fichiers dans des compartiments

Amazon S3 sert de lac de données évolutif et durable sur AWS. Grâce à Data Lake, vous pouvez importer n'importe quelle donnée au format ouvert comme CSV, JSON, PARQUET ou ORC dans Amazon S3 et effectuer des analyses sur vos données.

Les solutions utilisent des fichiers de données CSV contenant des informations classées PCI, PII, HPR ou Public. Vous pouvez télécharger les fichiers d'entrée en utilisant les liens fournis ci-dessous. En utilisant les fichiers téléchargés, téléchargez-les sur Amazon S3 en créant un dossier et des fichiers comme indiqué dans la capture d'écran ci-dessous en suivant les instructions ici. Le détail de chaque fichier est fourni dans la liste suivante :

Enregistrez les fichiers dans AWS Glue Data Catalog à l'aide de robots d'exploration

Les instructions suivantes montrent comment enregistrer les fichiers téléchargés dans le catalogue de données AWS Glue à l'aide de robots d'exploration. Nous organisons les fichiers en bases de données et en tables à l'aide d'AWS Glue Data Catalog, selon les étapes suivantes. Il est recommandé de consulter la documentation pour savoir comment configurer correctement un Base de données AWS Glue. Les robots d'exploration peuvent automatiser le processus d'enregistrement de nos fichiers téléchargés dans le catalogue plutôt que de le faire manuellement. Vous allez créer les bases de données suivantes dans le catalogue de données AWS Glue :

• lobrisk
• lobmarket
• hr

Exemples d'étapes pour créer une base de données AWS Glue pour lobrisk les données sont les suivantes :

• Allez à Console de colle AWS.
• Ensuite, sélectionnez Bases de données sous Catalogue de données.
• Selectionnez Ajouter une base de données et entrez le nom des bases de données comme lobrisk.
• Sélectionnez Créer une base de données, comme illustré dans la capture d'écran suivante.

Répétez les étapes pour créer une autre base de données comme lobmarket ainsi que hr.

Un AWS Glue Crawler analyse les fichiers ci-dessus et catalogue les métadonnées les concernant dans le catalogue de données AWS Glue. Le catalogue de données Glue organise ces données Amazon S3 en tables et bases de données, en attribuant des colonnes et des types de données afin que les données puissent être interrogées à l'aide de SQL qu'Amazon Redshift Spectrum peut comprendre. Veuillez consulter le Documentation AWS Glue sur la création du Glue Crawler. Une fois l'exécution du robot d'exploration AWS Glue terminée, vous verrez la base de données et les tables respectives suivantes :

• 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

Exemples d'étapes pour créer un AWS Glue Crawler pour lobrisk les données sont les suivantes :

• Sélectionnez Rampeurs sous Catalogue de données dans la console AWS Glue.
• Ensuite, choisissez Créer un robot. Fournissez le nom du robot d'exploration comme lobrisk_crawler et choisissez Suivant.

Assurez-vous de sélectionner la source de données comme Amazon S3 et parcourez le chemin Amazon S3 vers le lob_risk_high_confidential_public dossier et choisissez une source de données Amazon S3.

• Les robots d'exploration peuvent analyser plusieurs dossiers dans Amazon S3. Choisir Ajouter une source de données et inclure le chemin S3://<<Your Bucket >>/ lob_risk_high_confidential.

• Après avoir ajouté un autre dossier Amazon S3, choisissez Suivant.

• Ensuite, créez un nouveau Rôle IAM dans l' Sécurité des configurations paramètres.
• Selectionnez Suivant.

• Sélectionnez la base de données cible comme lobrisk. Choisir Suivant.

• Ensuite, sous Avis, choisissez Créer un robot.
• Sélectionnez Exécuter le robot d'exploration. Cela crée deux tables : lob_risk_high_confidential_public ainsi que lob_risk_high_confidential sous la base de données lobrisk.

De même, créez un robot d'exploration AWS Glue pour lobmarket ainsi que hr données en suivant les étapes ci-dessus.

Créer des rôles AWS IAM

À l'aide d'AWS IAM, créez les rôles IAM suivants avec les autorisations Amazon Redshift, Amazon S3, AWS Glue et AWS Lake Formation.

Vous pouvez créer des rôles AWS IAM dans ce service à l'aide de ce lien. Plus tard, vous pourrez attacher une stratégie gérée à ces rôles IAM :

• iam_redshift_pcipii (Rôle AWS IAM attaché au cluster Amazon Redshift)
  • AmazonRedshiftFullAccess
  • AmazonS3FullAccess
  • Ajoutez une stratégie en ligne (Lakeformation-inline) pour l’autorisation Lake Formation comme suit :

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

  • iam_redshift_hpr (Rôle AWS IAM attaché au cluster Amazon Redshift) : ajoutez les éléments gérés suivants :
    • AmazonRedshiftFullAccess
    • AmazonS3FullAccess
    • Ajoutez une stratégie en ligne (Lakeformation-inline), créée précédemment.
  • iam_redshift_public (Rôle AWS IAM attaché au cluster Amazon Redshift) : ajoutez la stratégie gérée suivante :
    • AmazonRedshiftFullAccess
    • AmazonS3FullAccess
    • Ajoutez une stratégie en ligne (Lakeformation-inline), créée précédemment.
  • LF_admin (Administrateur de Lake Formation) : ajoutez la stratégie gérée suivante :
    • AWSLakeFormationDataAdmin
    • AWSLakeFormationCrossAccountManager
    • AWSGlueConsoleFullAccess

Utilisez le contrôle d'accès basé sur des balises de Lake Formation (LF-TBAC) pour contrôler l'accès aux tables du catalogue de données AWS Glue.

LF-TBAC est une stratégie d'autorisation qui définit les autorisations en fonction des attributs. En utilisant LF_admin Administrateur de Lake Formation, vous pouvez créer des balises LF, comme mentionné dans les détails suivants :

Suivez les instructions ci-dessous pour créer des balises Lake Formation :

• Connectez-vous à la console Lake Formation (https://console.aws.amazon.com/lakeformation/) à l'aide du rôle AWS IAM LF-Admin.
• Cliquez sur Balises LF et autorisations in Sections d'autorisations.
• Sélectionnez Ajouter une balise LF.

• Créez les balises LF restantes comme indiqué dans le tableau ci-dessus. Une fois créé, vous trouvez les balises LF comme indiqué ci-dessous.

Attribuez LF-TAG aux tables du catalogue AWS Glue

L'attribution de balises Lake Formation aux tables implique généralement une approche structurée. L'administrateur de Lake Formation peut attribuer des balises en fonction de divers critères, tels que la source de données, le type de données, le domaine d'activité, le propriétaire des données ou la qualité des données. Vous avez la possibilité d'attribuer des balises LF aux actifs Data Catalog, notamment aux bases de données, aux tables et aux colonnes, ce qui vous permet de gérer efficacement l'accès aux ressources. L'accès à ces ressources est limité aux principaux qui ont reçu les balises LF correspondantes (ou à ceux qui ont obtenu l'accès via l'approche des ressources nommées).

Suivez les instructions dans le lien donné pour attribuer LF-TAGS à Glue Tableaux du catalogue de données:

Suivez les instructions ci-dessous pour attribuer une balise LF aux tables Glue à partir de la console AWS comme suit :

• Pour accéder aux bases de données dans Lake Formation Console, accédez au Catalogue de données section et choisissez Bases de données.
• Sélectionnez le lobrisk base de données et choisissez Afficher les tableaux.
• Sélectionnez lob_risk_high_confidential tableau et modifiez le Étiquettes LF.
• Attribuez le Classification : HPR as Clés attribuées et les valeurs comme Oui. Sélectionner Épargnez.

• De même, attribuez la classification clés / KEY : ainsi que Valeur comme non sensible pour le lob_risk_high_confidential_public tableau.

Suivez les instructions ci-dessus pour attribuer des tables aux tables restantes pour lobmarket ainsi que hr bases de données.

Accorder des autorisations aux ressources à l'aide d'une expression LF-Tag accordée aux rôles Redshift IAM

Subvention Sélectionner, décrire Autorisation de Lake Formation pour les rôles LF-Tags et Redshift IAM à l'aide de Lake Formation Administrator dans la console Lake Formation. Pour accorder, veuillez suivre les Documentation.

Utilisez le tableau suivant pour accorder le rôle IAM correspondant aux balises LF :

Suivez les instructions ci-dessous pour accorder des autorisations aux balises LF et aux rôles IAM :

• Selectionnez Autorisations du lac de données in Permissions dans la console AWS Lake Formation.
• Selectionnez Subventions. Sélectionner Utilisateurs IAM et des rôles dans Directeurs d'école.
• Dans les balises LF ou les ressources du catalogue, sélectionnez clés / KEY : as Classifications ainsi que valeurs as non-sensitive.

• Ensuite, sélectionnez Droits de table as Sélectionner et décrire. Choisir subventions.

Suivez les instructions ci-dessus pour les balises LF restantes et leurs rôles IAM, comme indiqué dans le tableau précédent.

Mappez les groupes d'utilisateurs IdP aux rôles Redshift

Dans Redshift, utilisez la fédération Native IdP pour mapper les groupes d'utilisateurs IdP aux rôles Redshift. Utiliser Éditeur de requête 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;

Créer des schémas externes

Dans Redshift, créez des schémas externes à l'aide des rôles AWS IAM et des bases de données AWS Glue Catalog. Les schémas externes sont créés selon la classification des données à l'aide de 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';

Vérifier la liste des tables

Vérifiez la liste des tables dans chaque schéma externe. Chaque schéma répertorie uniquement les tables que Lake Formation a accordées à IAM_ROLES utilisé pour créer un schéma externe. Vous trouverez ci-dessous la liste des tables de la sortie d'édition de requête Redshift v2 en haut à gauche.

Accorder l'utilisation sur des schémas externes à différents rôles locaux Redshift

Dans Redshift, accordez l'utilisation sur des schémas externes à différents rôles locaux Redshift comme suit :

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;

Vérifier l'accès au schéma externe

Vérifiez l'accès au schéma externe à l'aide de l'utilisateur de l'équipe Lob Risk. Utilisateur lobrisk_pci_user fédéré dans le rôle local Amazon Redshift rs_lobrisk_pci_role. Rôle rs_lobrisk_pci_role n'a accès qu'au schéma externe external_lobrisk_pci.

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

Lors de l'interrogation de la table à partir de external_lobmarket_pci schéma, vous verrez que votre autorisation est refusée.

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

Fourniture d'accès automatisée de BMO

En collaboration avec la banque, nous avons développé un cadre de fourniture d'accès qui permet à la banque de créer un référentiel central d'utilisateurs et des données auxquelles ils ont accès. Le fichier de stratégie est stocké dans Amazon S3. Lorsque le fichier est mis à jour, il est traité, les messages sont placés dans SQS d'Amazon. AWS Lambda utilisant API de données est utilisé pour appliquer le contrôle d'accès aux rôles Amazon Redshift. Simultanément, AWS Lambda est utilisé pour automatiser le contrôle d'accès basé sur les balises dans AWS Lake Formation.

Les avantages de l'adoption de ce modèle étaient les suivants :

1. Création d'un processus d'automatisation évolutif pour permettre l'application dynamique de politiques changeantes.
2. Rationalisation de l'intégration et du traitement des accès des utilisateurs grâce à la gestion des accès d'entreprise existante.
3. Nous avons donné à chaque secteur d'activité les moyens de restreindre l'accès aux données sensibles qu'ils possèdent et de protéger les données et la confidentialité des clients au niveau de l'entreprise.
4. Simplification de la gestion et de la maintenance des rôles AWS IAM en réduisant considérablement le nombre de rôles requis.

Avec la récente version de l'intégration d'Amazon Redshift avec AWS Identity Center, qui permet la propagation des identités sur le service AWS, elle peut être exploitée pour simplifier et faire évoluer cela. la mise en oeuvre.

Conclusion

Dans cet article, nous vous avons montré comment mettre en œuvre des contrôles d'accès robustes pour les données clients sensibles dans Amazon Redshift, ce qui était difficile lors de la tentative de définition de nombreux rôles AWS IAM distincts. La solution présentée dans cet article montre comment les organisations peuvent répondre aux besoins de sécurité et de conformité des données avec une approche consolidée, en utilisant un ensemble minimal de rôles AWS IAM organisés par classification des données plutôt que par secteurs d'activité.

En utilisant l'intégration native d'Amazon Redshift avec un fournisseur d'identité externe et en définissant des politiques RBAC dans Redshift et AWS Lake Formation, des contrôles d'accès granulaires peuvent être appliqués sans créer un nombre excessif de rôles distincts. Cela permet de bénéficier des avantages d’un accès basé sur les rôles tout en minimisant les frais administratifs.

D’autres institutions de services financiers cherchant à sécuriser les données de leurs clients et à respecter les réglementations de conformité peuvent suivre une approche RBAC consolidée similaire. Une définition minutieuse des politiques, alignée sur la sensibilité des données plutôt que sur les fonctions commerciales, peut contribuer à réduire la prolifération des rôles AWS IAM. Ce modèle équilibre la sécurité, la conformité et la gérabilité pour la gouvernance des données sensibles dans Amazon Redshift et sur les plateformes de données cloud plus larges.

En bref, un modèle RBAC centralisé basé sur la classification des données rationalise la gestion des accès tout en garantissant une sécurité et une conformité solides des données. Cette approche peut profiter à toute organisation gérant des informations client sensibles dans le cloud.

À propos des auteurs

Amy Tseng est directeur général de l'intégration des données et analyses(ADN) chez BMO. Elle est l'une des AWS Data Hero. Elle a plus de 7 ans d'expérience dans les migrations de données et d'analyses Cloud dans AWS. En dehors du travail, Amy adore voyager et faire de la randonnée.

Jack Lin est directeur de l’ingénierie de la plateforme de données chez BMO. Il possède plus de 20 ans d’expérience dans l’ingénierie de plates-formes et l’ingénierie logicielle. En dehors du travail, Jack adore jouer au football, regarder des matchs de football et voyager.

Régis Chow est directeur de l’intégration ADN chez BMO. Il a plus de 5 ans d'expérience dans le cloud et aime résoudre les problèmes grâce à l'innovation dans AWS. En dehors du travail, Régis aime tout ce qui se passe en plein air, il est particulièrement passionné par le golf et l'entretien des pelouses.

Nishchai JM est architecte de solutions spécialisées en analyse chez Amazon Web Services. Il se spécialise dans la création d'applications Big Data et aide les clients à moderniser leurs applications sur le Cloud. Il pense que les données sont du nouveau pétrole et passe le plus clair de son temps à tirer des enseignements des données.

Harshida Patel est architecte de solutions principal, Analytics avec AWS.

Raghu Kuppala est un architecte de solutions spécialisé en analyse expérimenté dans le domaine des bases de données, de l'entreposage de données et de l'analyse. En dehors du travail, il aime essayer différentes cuisines et passer du temps avec sa famille et ses amis.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/big-data/how-bmo-improved-data-security-with-amazon-redshift-and-aws-lake-formation/