Dieser Beitrag wurde gemeinsam mit Amy Tseng, Jack Lin und Regis Chow von BMO verfasst.

BMO ist nach Vermögenswerten die achtgrößte Bank in Nordamerika. Es bietet 8 Millionen Kunden Privat- und Geschäftsbankdienstleistungen, globale Märkte und Investmentbanking-Dienstleistungen an. Während sie ihre Digital First-Strategie für Geschwindigkeit, Skalierbarkeit und Beseitigung von Komplexität weiter umsetzen, suchen sie stets nach Möglichkeiten, die Datenzugriffskontrolle in der Cloud zu innovieren, zu modernisieren und zu optimieren. BMO hat sensible Finanzdaten gesammelt und musste eine sichere und leistungsstarke Analyseumgebung aufbauen. Eine der größten Herausforderungen der Bank im Zusammenhang mit strengen Cybersicherheitsanforderungen ist die Implementierung einer Verschlüsselung auf Feldebene für persönlich identifizierbare Informationen (PII), Payment Card Industry (PCI) und Daten, die als hohes Datenschutzrisiko (HPR) eingestuft sind. Daten mit dieser gesicherten Datenklassifizierung werden sowohl im Data Warehouse als auch in ihrem Data Lake verschlüsselt gespeichert. Nur Benutzer mit den erforderlichen Berechtigungen dürfen auf Daten im Klartext zugreifen.

Amazon RedShift ist ein vollständig verwalteter Data-Warehouse-Service, den Zehntausende Kunden zur Verwaltung von Analysen im großen Maßstab nutzen. Amazon Redshift unterstützt branchenführende Sicherheit mit integriertem Identitätsmanagement und Verbund für Single Sign-On (SSO) sowie Multi-Faktor-Authentifizierung. Der Amazon Redshift-Spektrum Funktion ermöglicht die direkte Abfrage Ihres Amazon Simple Storage Service (Amazon S3) Data Lake, und viele Kunden nutzen dies, um ihre Datenplattform zu modernisieren.

AWS Lake-Formation ist ein vollständig verwalteter Dienst, der den Aufbau, die Sicherung und die Verwaltung von Data Lakes vereinfacht. Es bietet eine differenzierte Zugriffskontrolle, Tagging (Tag-basierte Zugriffskontrolle (TBAC)) und Integration über Analysedienste hinweg. Es ermöglicht die Vereinfachung der Verwaltung von Datenkatalogobjekten und den Zugriff auf gesicherte Daten von Diensten wie Amazon Redshift Spectrum.

In diesem Beitrag teilen wir die Lösung mit Rollenbasierte Zugriffskontrolle (RBAC) von Amazon Redshift und AWS Lake Formation-Tag-basiert Zugriffskontrolle für Verbundbenutzer zur Abfrage Ihres Data Lake mit Amazon Redshift Spectrum.

Anwendungsfall

BMO verfügte über mehr als Petabyte (PB) an finanzsensiblen Daten, die wie folgt klassifiziert waren:

1. Personenbezogene Daten (PII)
2. Zahlungskartenbranche (PCI)
3. Hohes Datenschutzrisiko (HPR)

Die Bank möchte Daten in ihrem Amazon Redshift Data Warehouse und Amazon S3 Data Lake speichern. Sie verfügen über eine große, vielfältige Endbenutzerbasis in den Bereichen Vertrieb, Marketing, Kreditrisiko und anderen Geschäftsbereichen und Persönlichkeiten:

1. Geschäftsanalysten
2. Dateningenieure
3. Datenwissenschaftler

Auf die Daten sowohl auf Amazon Redshift als auch auf Data Lake-Daten, auf die mit Amazon Redshift Spectrum zugegriffen wird, muss eine differenzierte Zugriffskontrolle angewendet werden. Die Bank nutzt AWS-Dienste wie AWS-Kleber und Amazon Sage Maker auf dieser Analyseplattform. Sie nutzen außerdem einen externen Identitätsanbieter (IdP), um ihre bevorzugte Benutzerbasis zu verwalten und sie in diese Analysetools zu integrieren. Endbenutzer greifen über SQL-Clients und Business-Intelligence-Tools von Drittanbietern auf diese Daten zu.

Lösungsüberblick

In diesem Beitrag verwenden wir synthetische Daten, die den BMO-Daten sehr ähnlich sind, wobei die Daten als PII, PCI oder HPR klassifiziert sind. Benutzer und Gruppen sind im externen IdP vorhanden. Diese Benutzer schließen sich für die einmalige Anmeldung bei Amazon Redshift zusammen nativer IdP-Verbund. Wir definieren die Berechtigungen mithilfe der rollenbasierten Zugriffskontrolle (RBAC) von Redshift für die Benutzerrollen. Für Benutzer, die mit Amazon Redshift Spectrum auf die Daten im Data Lake zugreifen, verwenden wir Lake Formation-Richtlinien zur Zugriffskontrolle.

Technische Lösung

Um die Anforderungen der Kunden an die Sicherung verschiedener Datenkategorien umzusetzen, ist die Definition mehrerer AWS IAM-Rollen erforderlich, was Kenntnisse über IAM-Richtlinien und deren Pflege bei Änderungen der Berechtigungsgrenzen erfordert.

In diesem Beitrag zeigen wir, wie wir die Verwaltung der Datenklassifizierungsrichtlinien mit einer minimalen Anzahl von Amazon Redshift AWS IAM-Rollen, die nach Datenklassifizierung ausgerichtet sind, vereinfacht haben, anstatt Permutationen und Kombinationen von Rollen nach Geschäftsbereichen und Datenklassifizierungen. Andere Organisationen (z. B. das Financial Service Institute [FSI]) können von der Implementierung von Datensicherheit und Compliance durch das BMO profitieren.

Im Rahmen dieses Blogs werden die Daten in Amazon S3 hochgeladen. Der Zugriff auf die Daten wird mithilfe von Richtlinien gesteuert, die mithilfe von Redshift RBAC für entsprechende Benutzergruppen von Identitätsanbietern definiert wurden, und eine TAG-basierte Zugriffskontrolle wird mithilfe von AWS Lake Formation für Daten auf S3 implementiert.

Lösungsarchitektur

Das folgende Diagramm veranschaulicht die Lösungsarchitektur zusammen mit den detaillierten Schritten.

1. IdP-Benutzer mit Gruppen wie lob_risk_public, Lob_risk_pci, hr_public und hr_hpr werden im External IdP (Identity Provider) zugewiesen.
2. Jeder Benutzer wird den lokalen Rollen von Amazon Redshift zugeordnet, die vom IdP gesendet werden, einschließlich aad:lob_risk_pci, aad:lob_risk_public, aad:hr_public und aad:hr_hpr in Amazon Redshift. Zum Beispiel Benutzer1, der Teil von ist Lob_risk_public und hr_hpr gewährt die Rollennutzung entsprechend.
3. Anfügen iam_redshift_hpr, iam_redshift_pcipii und iam_redshift_public AWS IAM-Rollen für den Amazon Redshift-Cluster.
4. AWS Glue-Datenbanken, die auf s3 basieren (z. B. lobrisk,lobmarket,hr und ihre jeweiligen Tabellen) werden in Amazon Redshift referenziert. Mit Amazon Redshift Spectrum können Sie diese externen Tabellen und Datenbanken abfragen (z. B. external_lobrisk_pci, external_lobrisk_public, external_hr_public und external_hr_hpr), die mithilfe von AWS IAM-Rollen erstellt werden iam_redshift_pcipii, iam_redshift_hpr, iam_redshift_public wie in den Lösungsschritten gezeigt.
5. AWS Lake Formation wird verwendet, um den Zugriff auf die externen Schemata und Tabellen zu steuern.
6. Mithilfe von AWS Lake Formation-Tags wenden wir die differenzierte Zugriffskontrolle auf diese externen Tabellen für AWS IAM-Rollen an (z. B. iam_redshift_hpr, iam_redshift_pcipii und iam_redshift_public).
7. Gewähren Sie abschließend die Nutzung dieser externen Schemata für deren Amazon-Redshift-Rollen.

Lösungsweg

Die folgenden Abschnitte führen Sie durch die Implementierung der Lösung mithilfe synthetischer Daten.

Laden Sie die Datendateien herunter und platzieren Sie Ihre Dateien in Buckets

Amazon S3 dient als skalierbarer und langlebiger Datensee auf AWS. Mithilfe von Data Lake können Sie beliebige Daten in offenen Formaten wie CSV, JSON, PARQUET oder ORC in Amazon S3 übertragen und Analysen Ihrer Daten durchführen.

Die Lösungen nutzen CSV-Datendateien, die Informationen enthalten, die als PCI, PII, HPR oder öffentlich klassifiziert sind. Sie können Eingabedateien über die unten bereitgestellten Links herunterladen. Verwenden Sie die heruntergeladenen Dateien, um sie in Amazon S3 hochzuladen, indem Sie Ordner und Dateien erstellen, wie im folgenden Screenshot gezeigt, indem Sie den Anweisungen folgen hier. Die Einzelheiten zu jeder Datei finden Sie in der folgenden Liste:

Registrieren Sie die Dateien mithilfe von Crawlern im AWS Glue Data Catalog

Die folgenden Anweisungen zeigen, wie Sie mithilfe von Crawlern in den AWS Glue Data Catalog heruntergeladene Dateien registrieren. Wir organisieren Dateien mithilfe von AWS Glue Data Catalog gemäß den folgenden Schritten in Datenbanken und Tabellen. Es wird empfohlen, die Dokumentation zu lesen, um zu erfahren, wie Sie eine ordnungsgemäß einrichten AWS Glue-Datenbank. Crawler können den Prozess der Registrierung unserer heruntergeladenen Dateien im Katalog automatisieren, anstatt ihn manuell durchzuführen. Sie erstellen die folgenden Datenbanken im AWS Glue Data Catalog:

• lobrisk
• lobmarket
• hr

Beispielschritte zum Erstellen einer AWS Glue-Datenbank für lobrisk Die Daten lauten wie folgt:

• Gehen Sie zum AWS Glue-Konsole.
• Als nächstes wählen Sie Datenbanken für Datenkatalog.
• Auswählen Datenbank hinzufügen und geben Sie den Namen der Datenbanken als ein Lobrisk.
• Auswählen Datenbank erstellen, wie im folgenden Screenshot gezeigt.

Wiederholen Sie die Schritte zum Erstellen einer anderen Datenbank wie z lobmarket und hr.

Ein AWS Glue Crawler scannt die oben genannten Dateien und katalogisiert Metadaten darüber im AWS Glue Data Catalog. Der Glue-Datenkatalog organisiert diese Amazon S3-Daten in Tabellen und Datenbanken und weist Spalten und Datentypen zu, sodass die Daten mit SQL abgefragt werden können, das Amazon Redshift Spectrum verstehen kann. Bitte überprüfen Sie die AWS Glue-Dokumentation über die Erstellung des Glue Crawlers. Sobald die Ausführung des AWS Glue-Crawlers abgeschlossen ist, werden Ihnen die folgenden entsprechenden Datenbanken und Tabellen angezeigt:

• 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

Beispielschritte zum Erstellen eines AWS Glue Crawlers für lobrisk Die Daten lauten wie folgt:

• Auswählen Crawlers für Datenkatalog in der AWS Glue-Konsole.
• Als nächstes wählen Sie Crawler erstellen. Geben Sie den Crawler-Namen an als lobrisk_crawler und wählen Sie Weiter.

Stellen Sie sicher, dass Sie die Datenquelle als auswählen Amazon S3 und durchsuchen Sie den Amazon S3-Pfad zum lob_risk_high_confidential_public Ordner und wählen Sie eine Amazon S3-Datenquelle.

• Crawler können mehrere Ordner in Amazon S3 crawlen. Wählen Fügen Sie eine Datenquelle hinzu und Pfad einschließen S3://<<Your Bucket >>/ lob_risk_high_confidential.

• Nachdem Sie einen weiteren Amazon S3-Ordner hinzugefügt haben, wählen Sie Weiter.

• Als nächstes erstellen Sie ein neues IAM-Rolle der Konfigurationssicherheit zu üben.
• Auswählen Weiter.

• Wählen Sie die Zieldatenbank als aus lobrisk. Wählen Sie Weiter.

• Als nächstes unter Bewertung, wählen Crawler erstellen.
• Auswählen Führen Sie Crawler aus. Dadurch werden zwei Tabellen erstellt: lob_risk_high_confidential_public und lob_risk_high_confidential unter Datenbank lobrisk.

Erstellen Sie auf ähnliche Weise einen AWS Glue-Crawler für lobmarket und hr Daten mithilfe der oben genannten Schritte.

Erstellen Sie AWS IAM-Rollen

Erstellen Sie mit AWS IAM die folgenden IAM-Rollen mit den Berechtigungen Amazon Redshift, Amazon S3, AWS Glue und AWS Lake Formation.

Über diesen Link können Sie AWS IAM-Rollen in diesem Service erstellen. Später können Sie diesen IAM-Rollen eine verwaltete Richtlinie zuordnen:

• iam_redshift_pcipii (AWS IAM-Rolle, die dem Amazon-Redshift-Cluster zugeordnet ist)
  • AmazonRedshiftFullAccess
  • AmazonS3FullAccess
  • Fügen Sie die Inline-Richtlinie (Lakeformation-inline) für die Lake Formation-Berechtigung wie folgt hinzu:

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

  • iam_redshift_hpr (AWS IAM-Rolle, die dem Amazon-Redshift-Cluster zugeordnet ist): Fügen Sie Folgendes verwaltet hinzu:
    • AmazonRedshiftFullAccess
    • AmazonS3FullAccess
    • Fügen Sie die zuvor erstellte Inline-Richtlinie (Lakeformation-inline) hinzu.
  • iam_redshift_public (AWS IAM-Rolle, die dem Amazon-Redshift-Cluster zugeordnet ist): Fügen Sie die folgende verwaltete Richtlinie hinzu:
    • AmazonRedshiftFullAccess
    • AmazonS3FullAccess
    • Fügen Sie die zuvor erstellte Inline-Richtlinie (Lakeformation-inline) hinzu.
  • LF_admin (Lake Formation Administrator): Fügen Sie die folgende verwaltete Richtlinie hinzu:
    • AWSLakeFormationDataAdmin
    • AWSLakeFormationCrossAccountManager
    • AWSGlueConsoleFullAccess

Verwenden Sie die tagbasierte Zugriffskontrolle (LF-TBAC) von Lake Formation, um den Zugriff auf die AWS Glue-Datenkatalogtabellen zu kontrollieren.

LF-TBAC ist eine Autorisierungsstrategie, die Berechtigungen basierend auf Attributen definiert. Benutzen LF_admin Als Lake Formation-Administrator können Sie LF-Tags erstellen, wie in den folgenden Details erwähnt:

Befolgen Sie die folgenden Anweisungen, um Lake Formation-Tags zu erstellen:

• Melden Sie sich bei der Lake Formation Console an (https://console.aws.amazon.com/lakeformation/) mit der AWS IAM-Rolle LF-Admin.
• Gehen Sie zu LF-Tags und Berechtigungen in Abschnitte „Berechtigungen“..
• Auswählen LF-Tag hinzufügen.

• Erstellen Sie die restlichen LF-Tags wie in der Tabelle oben beschrieben. Nach der Erstellung finden Sie die LF-Tags wie unten gezeigt.

Weisen Sie den AWS Glue-Katalogtabellen LF-TAG zu

Das Zuweisen von Lake Formation-Tags zu Tabellen erfordert normalerweise einen strukturierten Ansatz. Der Lake Formation-Administrator kann Tags basierend auf verschiedenen Kriterien zuweisen, z. B. Datenquelle, Datentyp, Geschäftsdomäne, Dateneigentümer oder Datenqualität. Sie haben die Möglichkeit, Data Catalog-Assets, einschließlich Datenbanken, Tabellen und Spalten, LF-Tags zuzuweisen, wodurch Sie den Ressourcenzugriff effektiv verwalten können. Der Zugriff auf diese Ressourcen ist auf Prinzipale beschränkt, denen entsprechende LF-Tags zugewiesen wurden (oder denen der Zugriff über den benannten Ressourcenansatz gewährt wurde).

Befolgen Sie die Anweisungen im angegebenen Link, um Glue LF-TAGS zuzuweisen Datenkatalogtabellen:

Befolgen Sie die nachstehenden Anweisungen, um Glue-Tabellen über die AWS-Konsole wie folgt ein LF-Tag zuzuweisen:

• Um auf die Datenbanken in der Lake Formation Console zuzugreifen, gehen Sie zu Datenkatalog Abschnitt und wählen Sie Datenbanken.
• Wähle aus Lobrisk Datenbank und wählen Sie Tabellen anzeigen.
• Auswählen lob_risk_high_confidential Tabelle und bearbeiten Sie die LF-Tags.
• Weisen Sie die Klassifizierung:HPR as Zugewiesene Schlüssel und Werte als Ja. Wählen Speichern.

• Weisen Sie auf ähnliche Weise die Klassifizierung zu Wesentliche und Wert als unempfindlich für die lob_risk_high_confidential_public Tabelle.

Befolgen Sie die obigen Anweisungen, um Tabellen den verbleibenden Tabellen zuzuordnen lobmarket und hr Datenbanken.

Erteilen Sie Berechtigungen für Ressourcen mithilfe einer LF-Tag-Ausdruckserteilung für Redshift IAM-Rollen

Gewähren wählen, beschreiben Lake Formation-Berechtigung für LF-Tags und Redshift IAM-Rolle mithilfe des Lake Formation-Administrators in der Lake Formation-Konsole. Zur Gewährung befolgen Sie bitte die Dokumentation.

Verwenden Sie die folgende Tabelle, um LF-Tags die entsprechende IAM-Rolle zuzuweisen:

Befolgen Sie die folgenden Anweisungen, um Berechtigungen für LF-Tags und IAM-Rollen zu erteilen:

• Auswählen Data Lake-Berechtigungen in Berechtigungen Abschnitt in der AWS Lake Formation-Konsole.
• Auswählen Grants. Wählen IAM-Benutzer und Rollen darin Prinzipien.
• In LF-Tags oder Katalogressourcen auswählen Wesentliche as Classifications und Werte as non-sensitive.

• Als nächstes wählen Sie Tabellenberechtigungen as Auswählen und beschreiben. Wählen Sie für Balkonkraftwerke Reduzierung.

Befolgen Sie die obigen Anweisungen für die verbleibenden LF-Tags und ihre IAM-Rollen, wie in der vorherigen Tabelle gezeigt.

Ordnen Sie die IdP-Benutzergruppen den Redshift-Rollen zu

Verwenden Sie in Redshift die native IdP-Föderation, um die IdP-Benutzergruppen den Redshift-Rollen zuzuordnen. Verwenden Abfrage-Editor 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;

Erstellen Sie externe Schemata

Erstellen Sie in Redshift externe Schemata mithilfe von AWS IAM-Rollen und mithilfe von AWS Glue Catalog-Datenbanken. Externe Schemata werden gemäß der Datenklassifizierung erstellt 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';

Überprüfen Sie die Tabellenliste

Überprüfen Sie die Liste der Tabellen in jedem externen Schema. Jedes Schema listet nur die Tabellen auf, denen Lake Formation Zugriff gewährt hat IAM_ROLES Wird zum Erstellen eines externen Schemas verwendet. Unten finden Sie oben links die Liste der Tabellen in der Ausgabe von Redshift Query Edit v2.

Gewähren Sie die Nutzung externer Schemata für verschiedene lokale Redshift-Rollen

Gewähren Sie in Redshift die Nutzung externer Schemata verschiedenen lokalen Redshift-Rollen wie folgt:

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;

Überprüfen Sie den Zugriff auf das externe Schema

Überprüfen Sie den Zugriff auf das externe Schema mithilfe eines Benutzers aus dem Lob Risk-Team. Benutzer lobrisk_pci_user in die lokale Rolle von Amazon Redshift eingebunden rs_lobrisk_pci_role. Rolle rs_lobrisk_pci_role hat nur Zugriff auf externe Schemata external_lobrisk_pci.

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

Beim Abfragen der Tabelle von external_lobmarket_pci Schema sehen Sie, dass Ihre Berechtigung verweigert wird.

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

BMOs automatisierte Zugriffsbereitstellung

In Zusammenarbeit mit der Bank haben wir ein Zugriffsbereitstellungs-Framework entwickelt, das es der Bank ermöglicht, ein zentrales Repository für Benutzer und die Daten zu erstellen, auf die sie Zugriff haben. Die Richtliniendatei wird in Amazon S3 gespeichert. Wenn die Datei aktualisiert wird, wird sie verarbeitet und Nachrichten werden eingefügt Amazon SQS. Verwendung von AWS Lambda Daten-API wird verwendet, um die Zugriffskontrolle auf Amazon Redshift-Rollen anzuwenden. Gleichzeitig, AWS Lambda wird verwendet, um die Tag-basierte Zugriffskontrolle in AWS Lake Formation zu automatisieren.

Die Einführung dieses Modells hatte folgende Vorteile:

1. Es wurde ein skalierbarer Automatisierungsprozess erstellt, der die dynamische Anwendung sich ändernder Richtlinien ermöglicht.
2. Optimierte Benutzerzugriffs-Onboarding und -Verarbeitung mit vorhandener Unternehmenszugriffsverwaltung.
3. Ermöglicht jedem Geschäftsbereich, den Zugriff auf vertrauliche Daten, die er besitzt, einzuschränken und die Daten und Privatsphäre der Kunden auf Unternehmensebene zu schützen.
4. Vereinfachte die AWS IAM-Rollenverwaltung und -wartung durch eine deutlich reduzierte Anzahl erforderlicher Rollen.

Mit der jüngsten Veröffentlichung von Amazon Redshift kann die Integration mit AWS Identity Center, die die Weitergabe von Identitäten im gesamten AWS-Service ermöglicht, genutzt werden, um dies zu vereinfachen und zu skalieren Implementierung.

Zusammenfassung

In diesem Beitrag haben wir Ihnen gezeigt, wie Sie robuste Zugriffskontrollen für sensible Kundendaten in Amazon Redshift implementieren, was bei dem Versuch, viele verschiedene AWS IAM-Rollen zu definieren, eine Herausforderung darstellte. Die in diesem Beitrag vorgestellte Lösung zeigt, wie Unternehmen Datensicherheits- und Compliance-Anforderungen mit einem konsolidierten Ansatz erfüllen können – unter Verwendung eines minimalen Satzes von AWS IAM-Rollen, die nach Datenklassifizierung und nicht nach Geschäftsbereichen organisiert sind.

Durch die Nutzung der nativen Integration von Amazon Redshift mit External IdP und die Definition von RBAC-Richtlinien sowohl in Redshift als auch in AWS Lake Formation können granulare Zugriffskontrollen angewendet werden, ohne dass eine übermäßige Anzahl unterschiedlicher Rollen erstellt wird. Dies ermöglicht die Vorteile des rollenbasierten Zugriffs und minimiert gleichzeitig den Verwaltungsaufwand.

Andere Finanzdienstleistungsinstitute, die Kundendaten schützen und Compliance-Vorschriften einhalten möchten, können einen ähnlichen konsolidierten RBAC-Ansatz verfolgen. Eine sorgfältige Richtliniendefinition, die auf die Datensensibilität und nicht auf Geschäftsfunktionen ausgerichtet ist, kann dazu beitragen, die Verbreitung von AWS IAM-Rollen zu reduzieren. Dieses Modell gleicht Sicherheit, Compliance und Verwaltbarkeit für die Verwaltung sensibler Daten in Amazon Redshift und breiteren Cloud-Datenplattformen aus.

Kurz gesagt: Ein zentralisiertes RBAC-Modell, das auf Datenklassifizierung basiert, rationalisiert die Zugriffsverwaltung und sorgt gleichzeitig für robuste Datensicherheit und Compliance. Dieser Ansatz kann jedem Unternehmen zugute kommen, das vertrauliche Kundeninformationen in der Cloud verwaltet.

Über die Autoren

Amy Tseng ist Managing Director für Data and Analytics (DnA) Integration bei BMO. Sie ist eine der AWS Data Heros. Sie verfügt über mehr als 7 Jahre Erfahrung mit Daten- und Analytics-Cloud-Migrationen in AWS. Außerhalb der Arbeit liebt Amy das Reisen und Wandern.

Jack Lin ist Director of Engineering für die Datenplattform bei BMO. Er verfügt über mehr als 20 Jahre Erfahrung in der Plattform- und Softwareentwicklung. Außerhalb der Arbeit spielt Jack gerne Fußball, schaut sich Fußballspiele an und reist.

Regis Chow ist Direktor für DnA-Integration bei BMO. Er verfügt über mehr als 5 Jahre Erfahrung in der Cloud und hat Spaß daran, Probleme durch Innovationen in AWS zu lösen. Außerhalb der Arbeit liebt Regis alle Dinge im Freien, besonders Golf und Rasenpflege sind seine Leidenschaft.

Nishchai JM ist Analytics Specialist Solutions Architect bei Amazon Web Services. Er ist spezialisiert auf die Erstellung von Big-Data-Anwendungen und hilft Kunden bei der Modernisierung ihrer Anwendungen in der Cloud. Er hält Daten für neues Öl und verbringt die meiste Zeit damit, Erkenntnisse aus den Daten zu gewinnen.

Harshida Patel ist Principal Solutions Architect, Analytics bei AWS.

Raghu Kuppala ist ein auf Analytics spezialisierter Lösungsarchitekt mit Erfahrung in den Bereichen Datenbanken, Data Warehousing und Analyse. Außerhalb der Arbeit probiert er gerne verschiedene Küchen aus und verbringt Zeit mit seiner Familie und Freunden.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/big-data/how-bmo-improved-data-security-with-amazon-redshift-and-aws-lake-formation/