Datenverwaltungs- und Analyseplattform für Unternehmen bereitstellen

Last reviewed 2025-04-04 UTC

Eine Plattform für die Datenverwaltung und -analyse in Unternehmen bietet eine Enklave, in der Sie sensible Daten speichern, analysieren und bearbeiten können, während Sicherheitskontrollen aufrechterhalten werden. Sie können die Enterprise Data Mesh-Architektur verwenden, um eine Plattform auf Google Cloud für die Datenverwaltung und ‑analyse bereitzustellen. Die Architektur ist für eine hybride Umgebung konzipiert, in der Google Cloud Komponenten mit Ihren vorhandenen On-Premise-Komponenten und Betriebsabläufen interagieren.

Die Architektur für Enterprise Data Mesh umfasst Folgendes:

• Ein GitHub-Repository, das eine Reihe von Terraform-Konfigurationen, ‑Scripts und ‑Code zum Erstellen der folgenden Elemente enthält:
  • Ein Governance-Projekt, mit dem Sie die Implementierung des CDMS Key Controls Framework (Cloud Data Management Capabilities) von Google verwenden können.
  • Beispiel für eine Datenplattform, die interaktive und Produktionsworkflows unterstützt.
  • Eine Produzentenumgebung innerhalb der Datenplattform, die mehrere Datendomänen unterstützt. Datendomänen sind logische Gruppierungen von Datenelementen.
  • Eine Nutzerumgebung innerhalb der Datenplattform, die mehrere Nutzerprojekte unterstützt.
  • Ein Datenübertragungsdienst, der die Workload Identity Federation und die Verschlüsselungsbibliothek Tink verwendet, um Daten sicher in Google Cloud zu übertragen.
  • Beispiel für eine Datendomain mit Aufnahme-, nicht vertraulichen und vertraulichen Projekten.
  • Ein Beispiel für ein Datenzugriffssystem, mit dem Datenabnehmer Zugriff auf Datensätze anfordern und Dateneigentümer Zugriff auf diese Datensätze gewähren können. Das Beispiel enthält auch einen Workflow-Manager, der die IAM-Berechtigungen dieser Datensätze entsprechend ändert.
• Einer Anleitung zu den Architektur-, Design-, Sicherheitskontrollen und Betriebsprozessen, die Sie mit dieser Architektur implementieren (dieses Dokument).

Die Data-Mesh-Architektur für Unternehmen ist mit dem Blueprint für Unternehmensgrundlagen kompatibel. Der Blueprint zu den Unternehmensgrundlagen bietet eine Reihe von Diensten auf Basisebene, auf die diese Architektur basiert, z. B. VPC-Netzwerke und Logging. Sie können diese Architektur bereitstellen, ohne den Blueprint zu Unternehmensgrundlagen bereitzustellen, wenn IhreGoogle Cloud Umgebung die erforderlichen Funktionen bietet.

Dieses Dokument richtet sich an Cloud-Architekten, Data Scientists, Data Engineers und Sicherheitsarchitekten, die mit der Architektur umfassende Datendienste in Google Clouderstellen und bereitstellen können. In diesem Dokument wird davon ausgegangen,dass Sie mit den Konzepten von Datennetzwerken, Google CloudDatendiensten und der Google Cloud Implementierung des CDMC-Frameworks vertraut sind.

Architektur

Die Data Mesh-Architektur für Unternehmen verfolgt einen mehrschichtigen Ansatz, um die Funktionen zur Datenaufnahme, Datenverarbeitung und Governance bereitzustellen. Die Architektur soll über einen CI/CD-Workflow bereitgestellt und gesteuert werden. Das folgende Diagramm zeigt, wie die Datenebene, die mit dieser Architektur bereitgestellt wird, zu anderen Ebenen in Ihrer Umgebung in Beziehung steht.

Dieses Diagramm enthält Folgendes:

• Die Google Cloud -Infrastruktur bietet Sicherheitsfunktionen wie die Verschlüsselung ruhender Daten und die Verschlüsselung während der Übertragung sowie grundlegende Bausteine wie Computing und Speicher.
• Die Unternehmensgrundlage bietet eine Reihe von Ressourcen wie Identitäts-, Netzwerk-, Logging-, Monitoring- und Bereitstellungssysteme, die Sie für Ihre Datenarbeitslasten übernehmen können. Google Cloud
• Die Datenschicht bietet verschiedene Funktionen wie Datenaufnahme, Datenspeicherung, Datenzugriffssteuerung, Datenverwaltung, Datenüberwachung und Datenfreigabe.
• Die Anwendungsschicht stellt verschiedene Anwendungen dar, die die Assets der Datenebene verwenden.
• CI/CD bietet die Tools zur Automatisierung der Bereitstellung, Konfiguration, Verwaltung und Bereitstellung von Infrastruktur, Workflows und Softwarekomponenten. Mit diesen Komponenten sorgen Sie für konsistente, zuverlässige und überprüfbare Bereitstellungen und können manuelle Fehler minimieren und den gesamten Entwicklungszyklus beschleunigen.

Um zu zeigen, wie die Datenumgebung verwendet wird, enthält die Architektur einen Beispieldatenworkflow. Im Beispieldaten-Workflow werden die folgenden Prozesse erläutert: Datenverwaltung, Datenaufnahme, Datenverarbeitung, Datenfreigabe und Datennutzung.

Wichtige Architekturentscheidungen

In der folgenden Tabelle sind die wichtigsten Entscheidungen für die Architektur zusammengefasst.

Entscheidungsbereich	Entscheidungs-
Google Cloud architecture
Ressourcenhierarchie	Die Architektur verwendet die Ressourcenhierarchie aus dem Blueprint für Unternehmensgrundlagen.
Netzwerk	Die Architektur enthält einen Beispieldienst für die Datenübertragung, der die Workload Identity-Föderation und eine Tink-Bibliothek verwendet.
Rollen und IAM-Berechtigungen	Die Architektur umfasst segmentierte Rollen für Datenersteller, Datennutzer, Data-Governance und Datenplattform.
Gängige Datendienste
Metadaten	In der Architektur werden Datenmetadaten mit Data Catalog verwaltet.
Zentrale Richtlinienverwaltung	Für die Verwaltung von Richtlinien wird die Implementierung des CDMC-Frameworks von Google Cloudverwendet.
Verwaltung des Datenzugriffs	Zur Kontrolle des Zugriffs auf Daten umfasst die Architektur einen unabhängigen Prozess, bei dem Datennutzer den Zugriff auf Daten-Assets vom Dateninhaber anfordern müssen.
Datenqualität	In der Architektur wird die Cloud Data Quality Engine verwendet, um Datenqualitätsregeln für bestimmte Tabellenspalten zu definieren und auszuführen. Die Datenqualität wird anhand von Messwerten wie Richtigkeit und Vollständigkeit gemessen.
Datensicherheit	Die Architektur verwendet Tagging, Verschlüsselung, Maskierung, Tokenisierung und IAM-Kontrollen, um die Datensicherheit zu gewährleisten.
Datendomain
Datenumgebungen	Die Architektur umfasst drei Umgebungen. Zwei Umgebungen (Nicht-Produktion und Produktion) sind Betriebsumgebungen, die von Pipelines gesteuert werden. Eine Umgebung (Entwicklung) ist eine interaktive Umgebung.
Dateninhaber	Dateneigentümer nehmen Daten-Assets auf, verarbeiten, stellen sie bereit und gewähren Zugriff darauf.
Datenkonsumenten	Datennutzer fordern Zugriff auf Daten-Assets an.
Onboarding und Betrieb
Pipelines	In der Architektur werden die folgenden Pipelines zum Bereitstellen von Ressourcen verwendet: Fundament-Pipeline Infrastrukturpipeline Artefaktpipelines Service Catalog-Pipeline
Repositories	Für jede Pipeline wird ein separates Repository verwendet, um eine Abgrenzung der Verantwortlichkeiten zu ermöglichen.
Prozessablauf	Für Änderungen an der Produktionsumgebung sind ein Einreicher und ein Genehmiger erforderlich.
Cloud-Betrieb
Kurzübersichten zu Datenprodukten	Die Berichts-Engine generiert Übersichten zu Datenprodukten.
Cloud Logging	Die Architektur verwendet die Logging-Infrastruktur aus dem Blueprint für Unternehmensgrundlagen.
Cloud Monitoring	Die Architektur verwendet die Monitoring-Infrastruktur aus dem Blueprint für Unternehmensgrundlagen.

Identität: Rollen Gruppen zuordnen

Das Data Mesh nutzt die vorhandene Architektur für die Identitätsverwaltung, Autorisierung und Authentifizierung des Blueprints für Unternehmensgrundlagen. Nutzern werden Rollen nicht direkt zugewiesen. Stattdessen sind Gruppen die primäre Methode zum Zuweisen von Rollen und Berechtigungen in IAM. IAM-Rollen und -Berechtigungen werden während der Projekterstellung über die Foundation-Pipeline zugewiesen.

Im Data Mesh werden Gruppen einem der vier Hauptbereiche zugeordnet: Infrastruktur, Datenverwaltung, domainbasierte Datenerzeuger und domainbasierte Datenverbraucher.

Die Berechtigungsbereiche für diese Gruppen sind:

• Der Berechtigungsbereich der Infrastrukturgruppe ist das Data Mesh insgesamt.
• Der Berechtigungsbereich der Data-Governance-Gruppen ist das Data-Governance-Projekt.
• Die Berechtigungen für domainbasierte Ersteller und Nutzer gelten für ihre Datendomain.

In den folgenden Tabellen sind die verschiedenen Rollen aufgeführt, die in dieser Data-Mesh-Implementierung verwendet werden, sowie die zugehörigen Berechtigungen.

Infrastruktur

Gruppe	Beschreibung	Rollen
[e-mail]	Gesamtadministratoren des Data Mesh	roles/owner (Datenplattform)

Data Governance

Gruppe	Beschreibung	Rollen
[e-mail]	Administratoren des Data-Governance-Projekts	roles/owner für das Data-Governance-Projekt
[e-mail]	Entwickler, die die Komponenten der Datenverwaltung erstellen und verwalten	Mehrere Rollen im Projekt zur Datenverwaltung, einschließlich roles/viewer, BigQuery-Rollen und Data Catalog-Rollen
[e-mail]	Leser von Informationen zur Datenverwaltung	roles/viewer
[e-mail]	Sicherheitsadministratoren des Governance-Projekts	roles/orgpolicy.policyAdmin und roles/iam.securityReviewer
[e-mail]	Gruppe mit Berechtigung zur Verwendung von Tag-Vorlagen	roles/datacatalog.tagTemplateUser
[e-mail]	Gruppe mit Berechtigung zur Verwendung von Tag-Vorlagen und zum Hinzufügen von Tags	roles/datacatalog.tagTemplateUser und roles/datacatalog.tagEditor
[e-mail]	Dienstkontogruppe für Security Command Center-Benachrichtigungen	Keine. Dies ist eine Gruppe für die Mitgliedschaft und es wird ein Dienstkonto mit diesem Namen erstellt, das die erforderlichen Berechtigungen hat.

Domainbasierte Datenersteller

Gruppe	Beschreibung	Rollen
gcp-dm-{data_domain_name}[e-mail]	Administratoren einer bestimmten Datendomain	roles/owner für das Datendomainprojekt
gcp-dm-{data_domain_name}[e-mail]	Entwickler, die Datenprodukte innerhalb einer Datendomain erstellen und verwalten	Mehrere Rollen im Datendomainprojekt, einschließlich roles/viewer-, BigQuery- und Cloud Storage-Rollen
gcp-dm-{data_domain_name}[e-mail]	Leser der Informationen zur Datendomain	roles/viewer
gcp-dm-{data_domain_name}-metadata-editors@{var.domain}	Bearbeiter von Data Catalog-Einträgen	Rollen zum Bearbeiten von Data Catalog-Einträgen
gcp-dm-{data_domain_name}[e-mail]	Datenverwalter für die Datendomain	Rollen zum Verwalten von Metadaten und Aspekten der Datenverwaltung

Domainbasierte Datenkonsumenten

Gruppe	Beschreibung	Rollen
gcp-dm-consumer-{project_name}[e-mail]	Administratoren eines bestimmten Nutzerprojekts	roles/owner für das Nutzerprojekt
gcp-dm-consumer-{project_name}[e-mail]	Entwickler, die an einem Nutzerprojekt arbeiten	Mehrere Rollen im Kundenprojekt, einschließlich roles/viewer- und BigQuery-Rollen
gcp-dm-consumer-{project_name}[e-mail]	Leser der Informationen zum Nutzerprojekt	roles/viewer

Organisationsstruktur

Um zwischen Produktionsabläufen und Produktionsdaten zu unterscheiden, werden in der Architektur verschiedene Umgebungen für die Entwicklung und Veröffentlichung von Workflows verwendet. Produktionsabläufe umfassen die Governance, Nachverfolgbarkeit und Wiederholbarkeit eines Workflows sowie die Prüfbarkeit der Ergebnisse des Workflows. Produktionsdaten sind möglicherweise sensible Daten, die Sie für die Verwaltung Ihrer Organisation benötigen. Alle Umgebungen sind mit Sicherheitseinstellungen ausgestattet, mit denen Sie Ihre Daten aufnehmen und verarbeiten können.

Für Data Scientists und Entwickler enthält die Architektur eine interaktive Umgebung, in der Entwickler direkt mit der Umgebung arbeiten und Dienste über einen ausgewählten Katalog von Lösungen hinzufügen können. Betriebsumgebungen werden über Pipelines gesteuert, die eine codierte Architektur und Konfiguration haben.

Bei dieser Architektur wird die Organisationsstruktur des Enterprise Foundations-Blueprints als Grundlage für die Bereitstellung von Datenarbeitslasten verwendet. Das folgende Diagramm zeigt die Ordner und Projekte der obersten Ebene, die in der Enterprise Data Mesh-Architektur verwendet werden.

In der folgenden Tabelle werden die Ordner und Projekte der obersten Ebene beschrieben, die Teil der Architektur sind.

Ordner	Komponente	Beschreibung
common	prj-c-artifact-pipeline	Enthält die Bereitstellungspipeline, mit der die Codeartefakte der Architektur erstellt werden.
	prj-c-service-catalog	Enthält die Infrastruktur, die vom Service Catalog zum Bereitstellen von Ressourcen in der interaktiven Umgebung verwendet wird.
	prj-c-datagovernance	Enthält alle Ressourcen, die von der Implementierung des CDMC-Frameworks von Google Cloudverwendet werden.
development	fldr-d-dataplatform	Enthält die Projekte und Ressourcen der Datenplattform zum Entwickeln von Anwendungsfällen im interaktiven Modus.
non-production	fldr-n-dataplatform	Enthält die Projekte und Ressourcen der Datenplattform zum Testen von Anwendungsfällen, die Sie in einer Produktionsumgebung bereitstellen möchten.
production	fldr-p-dataplatform	Enthält die Projekte und Ressourcen der Datenplattform für die Bereitstellung in der Produktion.

Ordner für Datenplattform

Der Ordner „Datenplattform“ enthält alle Komponenten der Datenebene und einige der CDMC-Ressourcen. Außerdem enthalten der Ordner „Datenplattform“ und das Data-Governance-Projekt die CDMC-Ressourcen. Das folgende Diagramm zeigt die Ordner und Projekte, die im Ordner „Data Platform“ bereitgestellt werden.

Jeder Ordner der Datenplattform enthält einen Ordner für die Umgebung (Produktion, Nicht-Produktion und Entwicklung). In der folgenden Tabelle werden die Ordner in den einzelnen Datenplattformordnern beschrieben.

Ordner	Beschreibung
Produzenten	Enthält die Datendomänen.
Nutzer	Enthält die Nutzerprojekte.
Datendomain	Enthält die Projekte, die mit einer bestimmten Domain verknüpft sind.

Ordner „Produzenten“

Jeder Ordner für Produzenten enthält eine oder mehrere Datendomänen. Eine Datendomain bezieht sich auf eine logische Gruppierung von Datenelementen, die dieselbe Bedeutung, denselben Zweck oder denselben Geschäftskontext haben. Mit Datendomains können Sie Daten-Assets innerhalb einer Organisation kategorisieren und organisieren. Das folgende Diagramm zeigt die Struktur einer Datendomain. Bei dieser Architektur werden für jede Umgebung Projekte im Ordner „Datenplattform“ bereitgestellt.

In der folgenden Tabelle werden die Projekte beschrieben, die für jede Umgebung im Ordner „data platform“ bereitgestellt werden.

Projekt	Beschreibung
Aufnahme	Im Datenaufnahmeprojekt werden Daten in die Datendomain aufgenommen. Die Architektur enthält Beispiele dafür, wie Sie Daten in BigQuery, Cloud Storage und Pub/Sub streamen können. Das Datenaufnahmeprojekt enthält auch Beispiele für Dataflow und Cloud Composer, mit denen Sie die Transformation und Übertragung aufgenommener Daten orchestrieren können.
Nicht vertraulich	Das nicht vertrauliche Projekt enthält de-identifizierte Daten. Sie können Daten maskieren, containerisieren, verschlüsseln, tokenisieren oder verschleiern. Mit Richtlinien-Tags können Sie festlegen, wie die Daten präsentiert werden.
Vertraulich	Das vertrauliche Projekt enthält Klartextdaten. Sie können den Zugriff über IAM-Berechtigungen steuern.

Ordner „Verbraucher“

Der Ordner „Consumer“ enthält Nutzerprojekte. Verbraucherprojekte bieten einen Mechanismus, mit dem Datennutzer basierend auf der erforderlichen Vertrauensgrenze segmentiert werden können. Jedem Projekt wird eine separate Nutzergruppe zugewiesen, der dann projektweise Zugriff auf die erforderlichen Daten-Assets gewährt wird. Mit dem Verbraucherprojekt können Sie die Daten für die Gruppe erheben, analysieren und ergänzen.

Allgemeiner Ordner

Der Ordner „common“ enthält die Dienste, die von verschiedenen Umgebungen und Projekten verwendet werden. In diesem Abschnitt werden die Funktionen beschrieben, die dem gemeinsamen Ordner hinzugefügt werden, um das Enterprise Data Mesh zu aktivieren.

CDMC-Architektur

Die Architektur verwendet die CDMC-Architektur für die Datenverwaltung. Die Funktionen zur Datenverwaltung befinden sich im Data Governance-Projekt im Common-Ordner. Das folgende Diagramm zeigt die Komponenten der CDMC-Architektur. Die Zahlen im Diagramm stellen die Schlüsselkontrollen dar, die mit Google Cloud-Diensten behandelt werden.

In der folgenden Tabelle werden die Komponenten der CDMC-Architektur beschrieben, die in der Enterprise Data Mesh-Architektur verwendet werden.

CDMC-Komponente	Google Cloud -Dienst	Beschreibung
Zugriffs- und Lebenszykluskomponenten
Schlüsselverwaltung	Cloud KMS	Ein Dienst, mit dem Verschlüsselungsschlüssel zum Schutz sensibler Daten sicher verwaltet werden.
Datensatzmanager	Cloud Run	Eine Anwendung, die umfassende Protokolle und Datensätze zu Aktivitäten der Datenverarbeitung führt, damit Organisationen die Datennutzung nachverfolgen und prüfen können.
Archivierungsrichtlinie	BigQuery	Eine BigQuery-Tabelle, die die Speicherrichtlinie für Daten enthält.
Berechtigungen	BigQuery	Eine BigQuery-Tabelle, in der Informationen dazu gespeichert werden, wer auf vertrauliche Daten zugreifen kann. Mit dieser Tabelle wird sichergestellt, dass nur autorisierte Nutzer auf bestimmte Daten zugreifen können, die zu ihren Rollen und Berechtigungen passen.
Komponenten scannen
Datenverlust	Schutz sensibler Daten	Dienst, mit dem Assets auf sensible Daten geprüft werden.
DLP-Ergebnisse	BigQuery	Eine BigQuery-Tabelle, in der Datenklassifikationen auf der Datenplattform katalogisiert werden.
Richtlinien	BigQuery	Eine BigQuery-Tabelle, die einheitliche Datenverwaltungspraktiken enthält (z. B. Datenzugriffstypen).
Abrechnungsexport	BigQuery	Eine Tabelle mit Kosteninformationen, die aus Cloud Billing exportiert werden, um die Analyse von Kostenmesswerten zu ermöglichen, die mit Datenassets verknüpft sind.
Cloud Data Quality Engine	Cloud Run	Eine Anwendung, die Datenqualitätsprüfungen für Tabellen und Spalten durchführt.
Ergebnisse zur Datenqualität	BigQuery	Eine BigQuery-Tabelle, in der Abweichungen zwischen den definierten Datenqualitätsregeln und der tatsächlichen Qualität der Daten-Assets erfasst werden.
Berichtskomponenten
Planer	Cloud Scheduler	Ein Dienst, der steuert, wann die Cloud Data Quality Engine ausgeführt wird und wann die Prüfung des Schutzes sensibler Daten erfolgt.
Report Engine	Cloud Run	Eine Anwendung, mit der Berichte erstellt werden, die dabei helfen, die Einhaltung der Kontrollen des CDMC-Frameworks zu verfolgen und zu messen.
Ergebnisse und Assets	BigQuery und Pub/Sub	Ein BigQuery-Bericht zu Abweichungen oder Inkonsistenzen bei den Datenverwaltungssteuerungen, z. B. fehlende Tags, falsche Klassifizierungen oder nicht konforme Speicherorte.
Tag-Exporte	BigQuery	Eine BigQuery-Tabelle mit extrahierten Tag-Informationen aus dem Data Catalog.
Weitere Komponenten
Richtlinienverwaltung	Organisationsrichtliniendienst	Ein Dienst, der Einschränkungen für den geografischen Speicherort von Daten festlegt und erzwingt.
Attributbasierte Zugriffsrichtlinien	Access Context Manager	Ein Dienst, der detaillierte, attributbasierte Zugriffsrichtlinien definiert und erzwingt, damit nur autorisierte Nutzer von zulässigen Standorten und Geräten auf vertrauliche Informationen zugreifen können.
Metadaten	Data Catalog	Ein Dienst, der Metadaten zu den Tabellen speichert, die im Data Mesh verwendet werden.
Tag-Engine	Cloud Run	Eine Anwendung, die Daten in BigQuery-Tabellen Tags hinzufügt.
CDMC-Berichte	Looker Studio	Dashboards, mit denen Ihre Analysten Berichte aufrufen können, die von den CDMC-Architektur-Engines generiert wurden.

CDMC-Implementierung

In der folgenden Tabelle wird beschrieben, wie die Architektur die Schlüsselkontrollen im CDMC-Framework implementiert.

CDMC-Kontrollanforderung	Implementierung
Compliance bei Datenkontrollen	Die Report Engine erkennt nicht konforme Daten-Assets und veröffentlicht die Ergebnisse in einem Pub/Sub-Thema. Diese Ergebnisse werden auch in BigQuery für Berichte mit Looker Studio geladen.
Dateninhaberschaft wird sowohl für migrierte als auch für in der Cloud generierte Daten eingerichtet	Data Catalog erfasst automatisch technische Metadaten aus BigQuery. Die Tag Engine wendet Geschäftsmetadaten-Tags wie den Namen des Inhabers und das Datenschutzniveau aus einer Referenztabelle an. So wird sichergestellt, dass alle sensiblen Daten aus Compliance-Gründen mit Informationen zum Inhaber getaggt sind. Dieser automatisierte Tagging-Prozess trägt zur Datenverwaltung und Compliance bei, indem vertrauliche Daten mit den entsprechenden Eigentümerinformationen gekennzeichnet werden.
Datenbeschaffung und -nutzung werden durch Automatisierung gesteuert und unterstützt	Data Catalog klassifiziert Datenassets, indem sie mit dem Flag is_authoritative getaggt werden, wenn sie eine maßgebliche Quelle sind. Data Catalog speichert die Informationen zusammen mit den technischen Metadaten automatisch in einem Datenregister. Die Report Engine und die Tag Engine können das Datenregister von vertrauenswürdigen Quellen mithilfe von Pub/Sub prüfen und melden.
Datenhoheit und grenzüberschreitende Datenübertragungen werden verwaltet	Der Organization Policy Service definiert zulässige Speicherorte für Daten-Assets und Access Context Manager schränkt den Zugriff basierend auf dem Standort des Nutzers ein. Data Catalog speichert die genehmigten Speicherorte als Metadaten-Tags. Die Report Engine vergleicht diese Tags mit dem tatsächlichen Speicherort der Daten-Assets in BigQuery und veröffentlicht Abweichungen als Ergebnisse über Pub/Sub. Security Command Center bietet eine zusätzliche Überwachungsebene, indem Sicherheitslückenergebnisse generiert werden, wenn Daten außerhalb der definierten Richtlinien gespeichert oder darauf zugegriffen wird.
Datenkataloge werden implementiert und verwendet und sind interoperabel	Data Catalog speichert und aktualisiert die technischen Metadaten für alle BigQuery-Daten-Assets und erstellt so einen kontinuierlich synchronisierten Data Catalog. Mit Data Catalog werden alle neuen oder geänderten Tabellen und Ansichten sofort dem Katalog hinzugefügt, sodass ein aktuelles Inventar der Daten-Assets vorhanden ist.
Datenklassifizierungen werden definiert und verwendet	Der Schutz sensibler Daten prüft BigQuery-Daten und identifiziert sensible Datentypen. Diese Ergebnisse werden dann anhand einer Klassifizierungsreferenztabelle bewertet und die höchste Vertraulichkeitsstufe wird in Data Catalog auf Spalten- und Tabellenebene als Tag zugewiesen. Tag Engine verwaltet diesen Prozess, indem der Data Catalog jedes Mal mit Sensibilitäts-Tags aktualisiert wird, wenn neue Daten-Assets hinzugefügt oder vorhandene geändert werden. So wird eine fortlaufend aktualisierte Klassifizierung von Daten basierend auf ihrer Vertraulichkeit sichergestellt, die Sie mit Pub/Sub und integrierten Berichtstools überwachen und in Berichte aufnehmen können.
Datenberechtigungen werden verwaltet, erzwungen und nachverfolgt	Mit Richtlinien-Tags in BigQuery wird der Zugriff auf vertrauliche Daten auf Spaltenebene gesteuert. So wird sichergestellt, dass nur autorisierte Nutzer auf bestimmte Daten zugreifen können, die ihnen über das zugewiesene Richtlinien-Tag zugewiesen sind. IAM verwaltet den allgemeinen Zugriff auf das Data Warehouse, während Data Catalog die Klassifizierungen der Datensensibilität speichert. Es werden regelmäßig Prüfungen durchgeführt, um sicherzustellen, dass alle vertraulichen Daten entsprechende Richtlinien-Tags haben. Abweichungen werden über Pub/Sub gemeldet, damit sie behoben werden können.
Zugriff, Verwendung und Ergebnisse von Daten nach ethischen Maßstäben werden verwaltet	Vereinbarungen zur Datenfreigabe für Anbieter und Nutzer werden in einem speziellen BigQuery-Data Warehouse gespeichert, um die Verwendungszwecke zu steuern. In Data Catalog werden Datenressourcen mit den Informationen zur Anbietervereinbarung gekennzeichnet, während Nutzervereinbarungen für die Zugriffssteuerung mit IAM-Bindungen verknüpft sind. Mit Abfragelabels werden Nutzungszwecke erzwungen. Nutzer müssen bei der Abfrage vertraulicher Daten einen gültigen Zweck angeben, der anhand ihrer Berechtigungen in BigQuery überprüft wird. Ein Audit-Trail in BigQuery erfasst alle Datenzugriffe und sorgt für die Einhaltung der Datenfreigabevereinbarungen.
Daten werden gesichert und Kontrollen werden nachgewiesen	Die standardmäßige Verschlüsselung inaktiver Daten von Google trägt zum Schutz von Daten bei, die auf dem Laufwerk gespeichert sind. Cloud KMS unterstützt vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) für eine erweiterte Schlüsselverwaltung. BigQuery implementiert eine dynamische Datenmaskierung auf Spaltenebene zur De-Identifikation und unterstützt die De-Identifikation auf Anwendungsebene während der Datenaufnahme. Data Catalog speichert Metadaten-Tags für Verschlüsselungs- und De-Identifikationstechniken, die auf Daten-Assets angewendet werden. Automatische Prüfungen sorgen dafür, dass die Verschlüsselungs- und De-Identifikationsmethoden den vordefinierten Sicherheitsrichtlinien entsprechen. Abweichungen werden als Ergebnisse über Pub/Sub gemeldet.
Ein Datenschutz-Framework ist definiert und betriebsbereit.	In Data Catalog werden sensible Daten-Assets mit relevanten Informationen für die Folgenabschätzung getaggt, z. B. der Standort des Subjekts und Links zu Bewertungsberichten. Die Tag Engine wendet diese Tags basierend auf der Datenvertraulichkeit und einer Richtlinientabelle in BigQuery an, in der die Bewertungsanforderungen basierend auf Daten und dem Datenstandort des Subjekts definiert werden. Durch diesen automatisierten Tagging-Prozess können die Anforderungen an die Folgenabschätzung kontinuierlich überwacht und entsprechende Berichte erstellt werden. So wird sichergestellt, dass bei Bedarf Datenschutz-Folgenabschätzungen (DSFAs) oder Folgenabschätzungen im Hinblick auf den Schutz personenbezogener Daten (PIAs) durchgeführt werden.
Der Datenlebenszyklus wird geplant und verwaltet	In Data Catalog werden Daten-Assets mit Aufbewahrungsrichtlinien versehen, in denen Aufbewahrungsdauern und Ablaufaktionen (z. B. Archivieren oder Löschen) angegeben werden. Record Manager automatisiert die Durchsetzung dieser Richtlinien, indem BigQuery-Tabellen anhand der definierten Tags dauerhaft gelöscht oder archiviert werden. Durch diese Erzwingung werden die Datenlebenszyklus-Richtlinien eingehalten und die Anforderungen an die Datenaufbewahrung erfüllt. Abweichungen werden erkannt und über Pub/Sub gemeldet.
Datenqualität wird verwaltet	Die Cloud Data Quality Engine definiert und führt Datenqualitätsregeln für bestimmte Tabellenspalten aus. Dabei wird die Datenqualität anhand von Messwerten wie Richtigkeit und Vollständigkeit gemessen. Die Ergebnisse dieser Prüfungen, einschließlich Erfolgsprozentsätze und Grenzwerte, werden als Tags in Data Catalog gespeichert. Durch das Speichern dieser Ergebnisse können die Datenqualität kontinuierlich überwacht und Berichte erstellt werden. Alle Probleme oder Abweichungen von zulässigen Grenzwerten werden als Ergebnisse mit Pub/Sub veröffentlicht.
Die Grundsätze der Kostenverwaltung werden festgelegt und angewendet.	Im Data Catalog werden kostenbezogene Messwerte für Daten-Assets gespeichert, z. B. Abfragekosten, Speicherkosten und Datenausgangskosten. Diese werden anhand von Abrechnungsinformationen berechnet, die aus Cloud Billing nach BigQuery exportiert wurden. Durch das Speichern kostenbezogener Messwerte können Sie die Kosten umfassend im Blick behalten und analysieren. So wird die Einhaltung von Kostenrichtlinien und eine effiziente Ressourcennutzung sichergestellt. Anomalien werden über Pub/Sub gemeldet.
Herkunft und Herkunftsnachweis von Daten werden verstanden	Die integrierten Funktionen zur Datenherkunft in Data Catalog erfassen die Herkunft und die Abfolge von Daten-Assets und stellen den Datenfluss visuell dar. Darüber hinaus identifizieren und taggen Datenaufnahmescripts die ursprüngliche Quelle der Daten in Data Catalog, wodurch die Rückverfolgbarkeit der Daten bis zu ihrer Quelle verbessert wird.

Verwaltung des Datenzugriffs

Der Zugriff auf Daten wird über einen unabhängigen Prozess gesteuert, der die Betriebssteuerung (z. B. das Ausführen von Dataflow-Jobs) von der Datenzugriffssteuerung trennt. Der Zugriff eines Nutzers auf einen Google Cloud Dienst wird durch eine Umgebungs- oder Betriebsanforderung definiert und von einer Cloud-Engineering-Gruppe bereitgestellt und genehmigt. Der Zugriff eines Nutzers auf Google Cloud Daten-Assets (z. B. eine BigQuery-Tabelle) ist ein Datenschutz-, Regulierungs- oder Governance-Anliegen und unterliegt einer Zugriffsvereinbarung zwischen den produzierenden und konsumierenden Parteien und wird über die folgenden Prozesse gesteuert. Das folgende Diagramm zeigt, wie der Datenzugriff durch die Interaktion verschiedener Softwarekomponenten bereitgestellt wird.

Wie im vorherigen Diagramm dargestellt, werden die Datenzugriffe über die folgenden Prozesse eingerichtet:

• Cloud-Daten-Assets werden von Data Catalog erfasst und inventarisiert.
• Der Workflowmanager ruft die Daten-Assets aus Data Catalog ab.
• Dateninhaber werden im Workflow-Manager eingerichtet.

Die Datenzugriffsverwaltung funktioniert so:

1. Ein Datenverbraucher stellt eine Anfrage für ein bestimmtes Asset.
2. Der Dateninhaber des Assets wird über die Anfrage informiert.
3. Der Dateninhaber genehmigt oder lehnt die Anfrage ab.
4. Wenn die Anfrage genehmigt wird, übergibt der Workflow-Manager die Gruppe, das Asset und das zugehörige Tag an den IAM-Mapper.
5. Der IAM-Mapper übersetzt die Tags des Workflow-Managers in IAM-Berechtigungen und gewährt der angegebenen Gruppe IAM-Berechtigungen für das Daten-Asset.
6. Wenn ein Nutzer auf das Daten-Asset zugreifen möchte, prüft IAM den Zugriff auf das Google Cloud Asset anhand der Berechtigungen der Gruppe.
7. Sofern zulässig, greift der Nutzer auf das Daten-Asset zu.

Netzwerk

Der Datensicherheitsprozess wird in der Quellanwendung gestartet, die sich lokal oder in einer anderen Umgebung außerhalb des ZielGoogle Cloud projekts befinden kann. Bevor eine Netzwerkübertragung stattfindet, authentifiziert sich diese Anwendung mithilfe der Identitätsförderung von Arbeitslasten sicher bei Google Cloud APIs. Anhand dieser Anmeldedaten interagiert er mit Cloud KMS, um die erforderlichen Schlüssel abzurufen oder zu verschlüsseln. Anschließend verwendet er die Tink-Bibliothek, um die sensiblen Daten gemäß vordefinierten Vorlagen zu verschlüsseln und zu anonymisieren.

Nachdem die Datennutzlast geschützt ist, muss sie sicher in das Google Cloud Aufnahmeprojekt übertragen werden. Für lokale Anwendungen können Sie Cloud Interconnect oder möglicherweise Cloud VPN verwenden. Verwenden Sie innerhalb desGoogle Cloud -Netzwerks Private Service Connect, um die Daten an den Datenaufnahmeendpunkt im VPC-Netzwerk des Zielprojekts weiterzuleiten. Mit Private Service Connect kann die Quellanwendung über private IP-Adressen eine Verbindung zu Google APIs herstellen, sodass der Traffic nicht dem Internet ausgesetzt wird.

Der gesamte Netzwerkpfad und die Zielaufnahmedienste (Cloud Storage, BigQuery und Pub/Sub) im Aufnahmeprojekt werden durch einen VPC Service Controls-Perimeter geschützt. Dieser Perimeter erzwingt eine Sicherheitsgrenze, die dafür sorgt, dass die geschützten Daten aus der Quelle nur in die autorisiertenGoogle Cloud -Dienste innerhalb dieses bestimmten Projekts aufgenommen werden können.

Logging

In dieser Architektur werden die Cloud Logging-Funktionen verwendet, die vom Blueprint für Unternehmensgrundlagen bereitgestellt werden.

Pipelines

Die Data-Mesh-Architektur für Unternehmen verwendet eine Reihe von Pipelines, um die Infrastruktur, die Orchestrierung, Datensätze, Datenpipelines und Anwendungskomponenten bereitzustellen. In den Ressourcenbereitstellungspipelines der Architektur wird Terraform als IaC-Tool (Infrastruktur als Code) und Cloud Build als CI/CD-Dienst verwendet, um die Terraform-Konfigurationen in der Architekturumgebung bereitzustellen. Das folgende Diagramm zeigt die Beziehung zwischen den Pipelines.

Die Grundlagenpipeline und die Infrastrukturpipeline sind Teil des Blueprints für Unternehmensgrundlagen. In der folgenden Tabelle werden der Zweck der Pipelines und die bereitgestellten Ressourcen beschrieben.

Pipeline	Bereitgestellt von	Ressourcen
Fundament-Pipeline	Bootstrap	Ordner und Unterordner der Datenplattform Gemeinsame Projekte Dienstkonto für die Infrastrukturpipeline Cloud Build-Trigger für die Infrastrukturpipeline Freigegebene VPC VPC Service Control-Perimeter
Infrastrukturpipeline	Fundament-Pipeline	Nutzerprojekte Service Catalog-Dienstkonto Der Cloud Build-Trigger für die Service Catalog-Pipeline Dienstkonto für die Artefaktpipeline Der Cloud Build-Trigger für die Artefaktepipeline
Service Catalog-Pipeline	Infrastrukturpipeline	Im Service Catalog-Bucket bereitgestellte Ressourcen
Artefaktpipelines	Infrastrukturpipeline	In Artefaktpipelines werden die verschiedenen Container und anderen Komponenten der Codebasis erstellt, die vom Data Mesh verwendet werden.

Jede Pipeline hat eigene Repositories, aus denen Code und Konfigurationsdateien abgerufen werden. Für jedes Repository gilt eine Aufgabentrennung, bei der die Einreichung und Genehmigung von Bereitstellungen von Betriebscodes in der Verantwortung verschiedener Gruppen liegt.

Interaktive Bereitstellung über Service Catalog

Interaktive Umgebungen sind die Entwicklungsumgebung innerhalb der Architektur und befinden sich im Ordner „Entwicklung“. Die Hauptoberfläche für die interaktive Umgebung ist der Service Catalog, mit dem Entwickler vorkonfigurierte Vorlagen verwenden können, um Google-Dienste zu instanziieren. Diese vorkonfigurierten Vorlagen werden als Dienstvorlagen bezeichnet. Mit Dienstvorlagen können Sie Ihre Sicherheitsmaßnahmen verstärken, z. B. die CMEK-Verschlüsselung obligatorisch machen. Außerdem wird verhindert, dass Ihre Nutzer direkten Zugriff auf Google APIs haben.

Das folgende Diagramm zeigt die Komponenten der interaktiven Umgebung und wie Data Scientists Ressourcen bereitstellen.

So stellen Sie Ressourcen mit Service Catalog bereit:

1. Der MLOps-Entwickler fügt eine Terraform-Ressourcenvorlage für Google Cloudin ein Git-Repository ein.
2. Der Git-Commit-Befehl löst eine Cloud Build-Pipeline aus.
3. Cloud Build kopiert die Vorlage und alle zugehörigen Konfigurationsdateien in Cloud Storage.
4. Der MLOps-Ingenieur richtet die Service Catalog-Lösungen und den Service Catalog manuell ein. Der Entwickler gibt den Service Catalog dann für ein Dienstprojekt in der interaktiven Umgebung frei.
5. Der Data Scientist wählt eine Ressource aus dem Service Catalog aus.
6. Service Catalog stellt die Vorlage in der interaktiven Umgebung bereit.
7. Die Ressource ruft alle erforderlichen Konfigurationsscripts ab.
8. Der Data Scientist interagiert mit den Ressourcen.

Artefaktpipelines

Bei der Datenaufnahme werden Cloud Composer und Dataflow verwendet, um die Übertragung und Transformation von Daten innerhalb des Datenbereichs zu orchestrieren. Die Artefaktpipeline erstellt alle erforderlichen Ressourcen für die Datenaufnahme und verschiebt sie an den richtigen Speicherort, damit die Dienste darauf zugreifen können. Die Artefaktpipeline erstellt die Containerartefakte, die vom Orchestrator verwendet werden.

Sicherheitskontrollen

Die Enterprise Data Mesh-Architektur verwendet ein mehrschichtiges Sicherheitsmodell mit mehreren Verteidigungsebenen, das standardmäßige Google Cloud Funktionen, Google CloudDienste und Sicherheitsfunktionen umfasst, die über den Blueprint „Unternehmensgrundlagen“ konfiguriert werden. Das folgende Diagramm zeigt die Schichtung der verschiedenen Sicherheitsmaßnahmen für die Architektur.

In der folgenden Tabelle werden die Sicherheitsmaßnahmen beschrieben, die mit den Ressourcen in den einzelnen Schichten verknüpft sind.

Ebene	Ressource	Sicherheitskontrollen
CDMC-Framework	Google Cloud CDMC-Implementierung	Bietet ein Governance-Framework, mit dem Sie Ihre Daten-Assets schützen, verwalten und steuern können. Weitere Informationen finden Sie im CDMC Key Controls Framework.
Bereitstellung	Infrastrukturpipeline	Bietet eine Reihe von Pipelines, mit denen Infrastruktur bereitgestellt, Container erstellt und Datenpipelines erstellt werden. Pipelines ermöglichen Prüfbarkeit, Rückverfolgbarkeit und Wiederholbarkeit.
	Artefaktpipeline	Hier werden verschiedene Komponenten bereitgestellt, die nicht über die Infrastrukturpipeline bereitgestellt werden.
	Terraform-Vorlagen	Erweitert die Systeminfrastruktur.
	Open Policy Agent	Hilft dabei, dafür zu sorgen, dass die Plattform den ausgewählten Richtlinien entspricht.
Netzwerk	Private Service Connect	Bietet Schutz vor Datenexfiltration für die Architekturressourcen auf API- und IP-Ebene. Ermöglicht die Kommunikation mit Google Cloud APIs über private IP-Adressen, sodass Sie keinen Traffic gegenüber dem Internet exponieren.
	VPC-Netzwerk mit privaten IP-Adressen	Hilft, die Gefahr von Internetbedrohungen zu verringern.
	VPC Service Controls	Hilft, sensible Ressourcen vor Datenexfiltration zu schützen.
	Firewall	Hilft, das VPC-Netzwerk vor unbefugtem Zugriff zu schützen.
Zugriffsverwaltung	Access Context Manager	Steuert, wer auf welche Ressourcen zugreifen kann, und verhindert den nicht autorisierten Zugriff auf Ihre Ressourcen.
	Workload Identity-Föderation	Es sind keine externen Anmeldedaten mehr erforderlich, um Daten aus lokalen Umgebungen auf die Plattform zu übertragen.
	Data Catalog	Bietet einen Index der für Nutzer verfügbaren Assets.
	IAM	Ermöglicht einen detaillierten Zugriff.
Verschlüsselung	Cloud KMS	Sie können damit Ihre Verschlüsselungsschlüssel und Geheimnisse verwalten und Ihre Daten durch Verschlüsselung inaktiver Daten und Verschlüsselung während der Übertragung schützen.
	Secret Manager	Bietet einen Secret-Store für Pipelines, die von IAM gesteuert werden.
	Verschlüsselung inaktiver Daten	Standardmäßig verschlüsselt Google Cloud inaktive Daten.
	Verschlüsselung während der Übertragung	Standardmäßig verschlüsselt Google Cloud übertragene Daten.
Erkennung	Security Command Center	Hilft Ihnen, Fehlkonfigurationen und schädliche Aktivitäten in Ihrer Google Cloud Organisation zu erkennen.
	Kontinuierliche Architektur	Prüft Ihre Google Cloud Organisation kontinuierlich anhand einer Reihe von OPA-Richtlinien (Open Policy Agent), die Sie definiert haben.
	IAM Recommender	Hier werden die Berechtigungen von Nutzern analysiert und Vorschläge zur Reduzierung der Berechtigungen gemacht, um das Prinzip der geringsten Berechtigung durchzusetzen.
	Firewall Insights	Analysiert Firewallregeln, identifiziert zu freizügige Firewallregeln und schlägt restriktivere Firewalls vor, um die allgemeine Sicherheitslage zu verbessern.
	Cloud Logging	Bietet Transparenz in Bezug auf Systemaktivitäten und trägt zur Erkennung von Anomalien und schädlichen Aktivitäten bei.
	Cloud Monitoring	Es werden wichtige Signale und Ereignisse erfasst, die dabei helfen können, verdächtige Aktivitäten zu erkennen.
Prävention	Unternehmensrichtlinien	Hier können Sie Aktionen innerhalb Ihrer Google Cloud Organisation steuern und einschränken.

Workflows

In den folgenden Abschnitten werden der Workflow für Datenersteller und der Workflow für Datennutzer beschrieben. Dabei werden geeignete Zugriffssteuerungen basierend auf der Datensensibilität und den Nutzerrollen sichergestellt.

Workflow für Datenproduzenten

Das folgende Diagramm zeigt, wie Daten bei der Übertragung zu BigQuery geschützt werden.

So funktioniert die Datenübertragung:

1. Eine Anwendung, die in die Identitätsföderation von Arbeitslasten eingebunden ist, verwendet Cloud KMS, um einen verpackten Verschlüsselungsschlüssel zu entschlüsseln.
2. Die Anwendung verwendet die Tink-Bibliothek, um die Daten mithilfe einer Vorlage zu anonymisieren oder zu verschlüsseln.
3. Die Anwendung überträgt Daten in Google Cloudan das Datenaufnahmeprojekt.
4. Die Daten werden in Cloud Storage, BigQuery oder Pub/Sub empfangen.
5. Im Datenaufnahmeprojekt werden die Daten mithilfe einer Vorlage entschlüsselt oder reidentifiziert.
6. Die entschlüsselten Daten werden anhand einer anderen De-Identifikationsvorlage verschlüsselt oder maskiert und dann in das nicht vertrauliche Projekt verschoben. Die Tagging-Engine wendet die Tags nach Bedarf an.
7. Daten aus dem nicht vertraulichen Projekt werden in das vertrauliche Projekt übertragen und neu identifiziert.

Folgender Datenzugriff ist zulässig:

• Nutzer, die Zugriff auf das vertrauliche Projekt haben, können auf alle Rohdaten im Klartext zugreifen.
• Nutzer mit Zugriff auf das nicht vertrauliche Projekt können je nach den mit den Daten verknüpften Tags und ihren Berechtigungen auf maskierte, tokenisierte oder verschlüsselte Daten zugreifen.

Workflow für Datennutzer

In den folgenden Schritten wird beschrieben, wie ein Verbraucher auf Daten zugreifen kann, die in BigQuery gespeichert sind.

1. Der Datennutzer sucht mit Data Catalog nach Daten-Assets.
2. Nachdem der Datennutzer die gewünschten Assets gefunden hat, fordert er Zugriff auf die Datenassets an.
3. Der Dateninhaber entscheidet, ob er Zugriff auf die Assets gewährt.
4. Wenn der Kunde Zugriff erhält, kann er mit einem Notebook und dem Solution Catalog eine Umgebung erstellen, in der er die Datenressourcen analysieren und transformieren kann.

Zusammenfassung

Im GitHub-Repository finden Sie eine detaillierte Anleitung zum Bereitstellen des Data Mesh aufGoogle Cloud , nachdem Sie die Enterprise Foundation bereitgestellt haben. Die Bereitstellung der Architektur umfasst die Änderung Ihrer vorhandenen Infrastruktur-Repositories und die Bereitstellung neuer Data-Mesh-spezifischer Komponenten.

Führen Sie Folgendes aus:

1. Alle Voraussetzungen müssen erfüllt sein, einschließlich der folgenden:
   1. Installieren Sie die Google Cloud CLI, Terraform, Tink, Java und Go.
   2. Stellen Sie den Blueprint für Unternehmensgrundlagen (Version 4.1) bereit.
   3. Die folgenden lokalen Repositories verwalten:
      • gcp-data-mesh-foundations
      • gcp-bootstrap
      • gcp-environments
      • gcp-networks
      • gcp-org
      • gcp-projects
2. Ändern Sie den vorhandenen Grundriss und implementieren Sie dann die Data-Mesh-Anwendungen. Führen Sie für jeden Artikel die folgenden Schritte aus:
   1. Prüfen Sie im Zielrepository den Zweig Plan.
   2. Wenn Sie Data Mesh-Komponenten hinzufügen möchten, kopieren Sie die entsprechenden Dateien und Verzeichnisse aus gcp-data-mesh-foundations in das entsprechende Foundation-Verzeichnis. Überschreiben Sie Dateien bei Bedarf.
   3. Aktualisieren Sie die Data Mesh-Variablen, -Rollen und -Einstellungen in den Terraform-Dateien (z. B. *.tfvars und *.tf). Legen Sie die GitHub-Tokens als Umgebungsvariablen fest.
   4. Führen Sie die Terraform-Vorgänge „initialize“, „plan“ und „apply“ für jedes Repository aus.
   5. Führen Sie einen Commit für Ihre Änderungen aus, übertragen Sie den Code in Ihr Remote-Repository, erstellen Sie Pull-Requests und führen Sie eine Zusammenführung in Ihren Entwicklungs-, Nicht-Produktions- und Produktionsumgebungen durch.

Nächste Schritte

• Weitere Informationen zur Architektur und zu den Funktionen in einem Data Mesh
• Daten aus Google Cloud in ein gesichertes BigQuery-Data Warehouse importieren
• CDMC Key Controls Framework in einem BigQuery-Data-Warehouse implementieren
• Weitere Informationen zum Blueprint für Unternehmensgrundlagen