Zero Copy ohne Kontrollverlust bei Berechtigungen und Datenzugriff

Zero Copy reduziert Datenkopien und kann Integrationsarchitekturen deutlich schlanker machen. Informationen müssen nicht für jeden neuen Analytics-, Salesforce- oder AI-Use-Case erneut kopiert, synchronisiert und an einem weiteren Ort gespeichert werden. Die schwierigere Frage bleibt trotzdem bestehen: Wer darf auf diese Daten zugreifen, unter welcher Identität erfolgt der Zugriff und welche Regeln gelten, wenn mehrere Plattformen beteiligt sind?

Ein Vertriebsteam arbeitet beispielsweise in Salesforce, während Produktnutzung und Transaktionsdaten in Databricks liegen. Der Service benötigt zusätzliche Informationen aus einem Data Warehouse, und ein Agentforce-Agent soll ausgewählte Daten nutzen, um einen Account einzuordnen oder eine Anfrage vorzubereiten. Klassisch würden dafür häufig neue Pipelines aufgebaut und Daten in mehrere Systeme repliziert. Jede zusätzliche Kopie bringt wiederum eigene Anforderungen an Aktualität, Berechtigungen, Löschung und Governance mit sich.

Zero Copy verändert dieses Modell. Daten können an ihrem Ursprungsort bleiben und trotzdem in anderen Systemen nutzbar werden. Die Integrationsarbeit verschwindet dadurch allerdings nicht, sondern verlagert sich teilweise. Statt vor allem Datenbewegung zu organisieren, müssen Unternehmen genauer definieren, wie Identitäten, Berechtigungen und Zugriffsregeln über Plattformgrenzen hinweg funktionieren.

Was Zero Copy tatsächlich verändert

Der Begriff Zero Copy kann leicht den Eindruck erwecken, dass Daten ihre ursprüngliche Plattform überhaupt nicht mehr verlassen. Technisch geht es vor allem darum, keinen zweiten dauerhaft replizierten Datenbestand aufzubauen. Bei einer Live Query wird eine Anfrage an das Quellsystem geschickt, dort verarbeitet und das benötigte Ergebnis zurückgegeben, während der führende Datenbestand weiterhin an der Quelle liegt.

Bei klassischen ETL- oder ELT-Prozessen entsteht dagegen bewusst ein zusätzlicher Datenbestand. Diese Kopie muss aktualisiert, geschützt, klassifiziert und gegebenenfalls wieder gelöscht werden. Änderungen an Berechtigungen oder Datenstrukturen müssen zwischen mehreren Plattformen sauber nachgezogen werden, und bei zeitversetzten Ladeprozessen kann es vorkommen, dass unterschiedliche Systeme vorübergehend mit unterschiedlichen Datenständen arbeiten.

Zero Copy reduziert diese Replikationsschicht. Das kann besonders bei großen Datenbeständen interessant sein, von denen im konsumierenden System nur ein kleiner Teil tatsächlich benötigt wird. Wenn beispielsweise Milliarden Nutzungsereignisse in einer Datenplattform liegen, Salesforce aber nur aggregierte Informationen für einzelne Accounts benötigt, muss nicht zwangsläufig der gesamte Datenbestand repliziert werden.

Dafür entstehen andere Abhängigkeiten. Das Quellsystem muss die Anfrage zuverlässig beantworten können, Berechtigungen müssen bei jedem Zugriff korrekt greifen und es muss klar sein, welche Daten nach einer Abfrage im konsumierenden System verarbeitet werden dürfen. Der technische Aufwand verschwindet also nicht vollständig, sondern verschiebt sich von der Pflege zusätzlicher Kopien stärker in Richtung Zugriffskontrolle und Laufzeitverhalten.

Der technische Vorteil liegt damit vor allem darin, Daten dort zu nutzen, wo sie bereits gepflegt werden. Ob daraus auch eine bessere Governance entsteht, hängt jedoch davon ab, wie sauber die beteiligten Berechtigungsmodelle miteinander verbunden sind.

Berechtigungen reisen nicht automatisch mit

Wenn eine Tabelle in Databricks oder Snowflake sauber abgesichert ist, bedeutet das noch nicht automatisch, dass Salesforce dieselben Nutzer, Rollen und fachlichen Grenzen versteht. Zwei Plattformen können dieselbe Person kennen und trotzdem unterschiedliche Identifikatoren, Rollenmodelle und Berechtigungskonzepte verwenden. Genau an dieser Stelle wird aus einer technischen Datenverbindung eine Architekturfrage.

Angenommen, ein Mitarbeiter darf in der Datenplattform nur Kunden seiner Region sehen. In Salesforce existiert derselbe Nutzer, sein Zugriff wird dort aber über ein anderes Rollen- und Sharing-Modell gesteuert. Zusätzlich kann ein Agent im Auftrag dieses Mitarbeiters auf Daten zugreifen, ohne selbst dieselbe Rolle wie der Mensch zu besitzen. Die Architektur muss dann nachvollziehbar abbilden, welcher Nutzungskontext tatsächlich hinter einer Anfrage steht.

Ein gemeinsamer technischer Service Account ist relativ einfach einzurichten. Er kann jedoch dazu führen, dass das Quellsystem nur diesen einen technischen Nutzer sieht und nicht mehr ohne Weiteres erkennen kann, welcher Salesforce-Nutzer den Zugriff ursprünglich ausgelöst hat. Ist der Account außerdem breit berechtigt, müssen Einschränkungen an anderer Stelle zuverlässig greifen.

Ein nutzerbezogenes oder föderiertes Identitätsmodell erlaubt feinere Kontrollen, verlangt dafür aber ein sauberes Mapping zwischen den Plattformen. Rollen, Nutzerattribute, Offboarding, Token und Zuständigkeiten werden dadurch Teil der Datenintegration. Das wirkt zunächst komplexer, ermöglicht aber eine deutlich präzisere Umsetzung von Least Privilege und Auditierbarkeit.

Zero Copy nimmt die dauerhafte Kopie aus der Architektur. Die Berechtigungsfrage bleibt.

Diese Entwicklung zeigt sich inzwischen auch in der Zusammenarbeit von Salesforce und Databricks. Themen wie Federated Authentication, Identity Mapping und die Abstimmung von Governance-Metadaten rücken dort stärker in den Vordergrund. Das unterstreicht, dass Zero Copy langfristig nicht nur über technische Datenverfügbarkeit funktioniert, sondern über eine belastbare Verbindung von Datenzugriff und Identität.

Drei Ebenen der Zugriffskontrolle

Bei Zero Copy greifen meist mehrere Governance-Ebenen gleichzeitig. Entscheidend ist deshalb nicht nur, ob eine Verbindung technisch funktioniert, sondern auch, welche Schicht welche Verantwortung übernimmt und wo Zugriffe tatsächlich begrenzt werden.

• Die Datenquelle kontrolliert den eigentlichen Datenbestand. Rollen, Row-Level Security, Masking und Datenklassifizierung können bereits in Databricks, Snowflake oder einer anderen Plattform greifen.
• Die föderierte Datenebene entscheidet, welche externen Informationen im Salesforce-Kontext verfügbar werden und für welche Anwendungsfälle sie genutzt werden können.
• Der Consumer bringt den konkreten Nutzungskontext ein. Ein Sales-Mitarbeiter, ein Dashboard, ein Service-Team und ein AI-Agent benötigen selten dieselben Daten und Berechtigungen.

Diese Ebenen sollten sich ergänzen und nicht gegenseitig ersetzen. Wenn beispielsweise die Datenquelle bereits sensible Felder maskiert, sollte eine neue Zugriffsschicht diese Einschränkung nicht umgehen. Umgekehrt kann Salesforce zusätzliche Grenzen setzen, auch wenn das Quellsystem einen breiteren Zugriff erlauben würde.

Probleme entstehen vor allem dann, wenn mehrere Schichten dieselbe Verantwortung übernehmen sollen und nicht klar ist, welche Regel im Konfliktfall maßgeblich ist. Eine Zero-Copy-Architektur sollte deshalb früh festlegen, welche Berechtigungen an der Quelle bleiben, welche Regeln in Salesforce ergänzt werden und wie der tatsächliche Nutzer- oder Prozesskontext durchgängig erhalten bleibt.

Warum weniger Kopien Governance vereinfachen können

Der Governance-Vorteil von Zero Copy liegt vor allem in der geringeren Zahl dauerhaft gepflegter Datenbestände. Wenn sensible Kundendaten an mehreren Stellen repliziert werden, entstehen ebenso viele Orte, an denen Berechtigungsänderungen, Löschregeln, Klassifizierungen und Datenqualität berücksichtigt werden müssen. Jede zusätzliche Plattform erweitert damit auch den Bereich, in dem Governance aktiv betrieben werden muss.

Das zeigt sich beispielsweise beim Rollenwechsel eines Mitarbeiters. Wird der Zugriff im führenden System geändert, muss sichergestellt sein, dass bestehende Kopien oder nachgelagerte Systeme diese Änderung ebenfalls zeitnah berücksichtigen. Bei mehreren Pipelines und Plattformen kann genau diese Synchronisation schwierig werden, besonders wenn unterschiedliche Teams für Quelle, Integration und Zielsystem verantwortlich sind.

In einem föderierten Modell bleibt der zentrale Datenbestand näher an seiner autoritativen Quelle. Kontrollen wie Row-Level Security oder Masking können direkt dort greifen, und Änderungen an diesen Regeln wirken beim nächsten Zugriff auf dieselbe Quelle. Das reduziert die Gefahr, dass alte Kopien noch mit veralteten Berechtigungen weitergenutzt werden.

Der Vorteil entsteht allerdings nur dann, wenn klar ist, welche Regeln an welcher Stelle gelten. Wenn Databricks eine Policy setzt, Salesforce zusätzlich filtert und ein weiterer Consumer eigene Berechtigungslogik verwendet, muss das Zusammenspiel dieser Ebenen nachvollziehbar bleiben. Weniger Datenkopien bedeuten also weniger Governance-Flächen, aber nicht automatisch weniger Verantwortung.

Bei AI-Agenten wird der Zugriffskontext noch wichtiger

Für Analytics ist Zero Copy bereits attraktiv, weil aktuelle Daten genutzt werden können, ohne ständig zusätzliche Pipelines und Kopien zu pflegen. Bei Agentforce und anderen agentischen Systemen kommt hinzu, dass Agenten Informationen aus mehreren Quellen kombinieren und anschließend für weitere Entscheidungen oder Aktionen verwenden können. Damit wächst der Wert aktueller Daten, gleichzeitig aber auch die Bedeutung eines sauber begrenzten Zugriffs.

Ein Agentforce-Agent könnte beispielsweise einen Account Manager vor einer Vertragsverlängerung unterstützen. Salesforce enthält Opportunity, Ansprechpartner und bisherige Aktivitäten, während Produktnutzung und Verbrauchsdaten in Databricks liegen. Der Agent soll daraus erkennen, ob die Nutzung zurückgeht, ob bestimmte Funktionen kaum verwendet werden oder ob sich ein Risiko für die Verlängerung abzeichnet.

Für diese Aufgabe benötigt der Agent aber nur einen kleinen Ausschnitt des gesamten Datenbestands. Zugriff auf sämtliche Kunden, historische Rohdaten oder sensible technische Felder wäre unnötig. Eine gute Architektur begrenzt deshalb bereits die Abfrage und stellt nur jene Datensätze und Attribute bereit, die für den konkreten Prozess gebraucht werden.

Wichtig ist außerdem, was nach der Abfrage passiert. Zero Copy verhindert eine dauerhafte vollständige Replikation, aber das Ergebnis einer Abfrage wird weiterhin verarbeitet und kann im Agentenkontext landen. Datenminimierung, Logging und klare Regeln für zulässige Agentenaktionen bleiben daher relevant.

Damit verschiebt sich die Frage von "Kann der Agent auf diese Daten zugreifen?" zu "Welche Daten braucht der Agent für genau diesen Auftrag?". Diese Unterscheidung ist wesentlich, weil produktive Agenten langfristig auf immer mehr Systeme und Datenquellen zugreifen können. Ein technisch möglicher Zugriff sollte deshalb nicht automatisch zu einem fachlich erlaubten Zugriff werden.

Zero Copy, Ingestion oder Caching?

Zero Copy sollte nicht für jeden Datenbestand automatisch die bevorzugte Lösung sein. In einer realen Enterprise-Architektur können unterschiedliche Modelle parallel sinnvoll sein, weil Anforderungen an Aktualität, Performance, Kosten und Governance stark variieren.

Zero Copy beziehungsweise Federation eignet sich besonders für große, aktuelle und bereits gut kontrollierte Datenbestände, bei denen eine zusätzliche vollständige Kopie wenig Mehrwert bringen würde. Das gilt beispielsweise für umfangreiche Nutzungs-, Transaktions- oder Eventdaten, von denen Salesforce nur gezielt einzelne Ausschnitte benötigt.

Ingestion kann sinnvoll sein, wenn Daten intensiv innerhalb von Data 360 verarbeitet, für Identity Resolution benötigt oder eng in operative Salesforce-Prozesse eingebunden werden. In solchen Fällen kann ein bewusst aufgebauter Datenbestand innerhalb der Plattform einfacher zu verarbeiten und zu steuern sein.

Caching kann bei häufigen Live Queries helfen, Latenz und Belastung des Quellsystems zu reduzieren. Dafür entstehen temporär wieder Daten außerhalb der ursprünglichen Plattform, was bei Governance- und Compliance-Anforderungen berücksichtigt werden muss.

In der Praxis entsteht deshalb häufig ein hybrides Modell. Ein stabiler Kern wird ingestiert, große oder besonders aktuelle externe Bestände bleiben föderiert und häufig benötigte Informationen werden gezielt beschleunigt. Die bessere Architektur ist nicht die mit dem höchsten Zero-Copy-Anteil, sondern diejenige, die den jeweiligen Use Case mit möglichst wenig unnötiger Datenbewegung unterstützt.

Ein Beispiel aus dem Vertrieb

Ein Softwareunternehmen verwaltet Accounts, Opportunities und Ansprechpartner in Salesforce. Produktnutzungsdaten liegen in Databricks und werden dort vom Data-Team aufbereitet, klassifiziert und über bestehende Governance-Regeln kontrolliert. Der Vertrieb möchte aktuelle Nutzungsinformationen direkt im Account-Kontext sehen, während ein Agentforce-Agent vor Vertragsverlängerungen mögliche Nutzungseinbrüche erkennen und dem Account Manager relevante Hinweise geben soll.

Eine vollständige Replikation aller historischen Nutzungsdaten nach Salesforce wäre dafür unnötig. Ein großer Teil dieser Events würde im Vertriebsprozess nie benötigt, müsste aber trotzdem gespeichert, synchronisiert und abgesichert werden. Über Zero Copy können stattdessen die relevanten Informationen im Salesforce-Kontext verfügbar werden, während der führende Datenbestand in Databricks verbleibt.

Der Account Manager sollte dabei nur die Accounts sehen, für die er verantwortlich ist. Der Agent benötigt ebenfalls nur die Daten, die für seinen konkreten Anwendungsfall relevant sind. Sensible Felder können bereits an der Quelle ausgeschlossen oder maskiert bleiben, während zusätzliche Regeln im Salesforce-Kontext den Zugriff weiter einschränken.

Für die Governance ist außerdem wichtig, dass der Weg der Anfrage nachvollziehbar bleibt. Im Idealfall lässt sich später erkennen, welcher Nutzer oder Agent die Daten abgefragt hat, unter welcher Identität der Zugriff ausgeführt wurde und in welchem Prozesskontext die Information verwendet wurde.

Der Nutzen entsteht dadurch aus zwei Komponenten: aktuelle Daten ohne zusätzliche vollständige Replikation und ein Zugriffsmodell, das bestehende Governance-Regeln respektiert. Genau hier liegt der Unterschied zwischen einer technisch funktionierenden Zero-Copy-Anbindung und einer belastbaren Enterprise-Architektur.

Was Unternehmen vor der Umsetzung klären sollten

Vor einer Zero-Copy-Anbindung sollten vier Entscheidungen bereits auf Architektur-Ebene getroffen werden. Werden sie erst nach der technischen Verbindung geklärt, muss das Zugriffsmodell später oft mit zusätzlichem Aufwand nachgebaut werden.

1. Wo liegt die führende Berechtigungslogik? Bestehende Row-Level Security, Masking und fachliche Zugriffsregeln sollten durch die neue Zugriffsschicht nicht ausgehebelt werden. Es muss klar sein, welche Regeln an der Quelle bleiben und wo zusätzliche Einschränkungen notwendig sind.

2. Unter welcher Identität erfolgt die Abfrage? Technische Accounts und nutzerbezogene Identitäten haben unterschiedliche Auswirkungen auf Least Privilege und Auditierbarkeit. Gerade bei Agenten sollte nachvollziehbar bleiben, in wessen Auftrag ein Zugriff stattgefunden hat.

3. Welche Daten braucht der konkrete Consumer? Ein Dashboard, ein Sales-Mitarbeiter und ein AI-Agent benötigen selten denselben Datenumfang. Datensätze und Felder sollten deshalb am tatsächlichen Use Case ausgerichtet werden.

4. Wie bleibt der Zugriff nachvollziehbar? Für sensible Prozesse sollte erkennbar sein, welcher Nutzer oder Agent welche Informationen abgefragt hat, welche Berechtigungen dabei gegriffen haben und in welchem Prozesskontext das passiert ist.

Diese Entscheidungen wirken organisatorisch, sind aber unmittelbar technische Architekturfragen. Werden sie früh geklärt, kann Zero Copy deutlich sauberer in eine bestehende Daten- und Berechtigungslandschaft integriert werden.

Was jetzt zählt

Zero Copy kann Datenarchitekturen vereinfachen, weil für neue Salesforce-, Analytics- oder AI-Use-Cases nicht jedes Mal vollständige Datenbestände kopiert und synchronisiert werden müssen. Der Vorteil bleibt aber nur dann erhalten, wenn Identity, Berechtigungen und Governance genauso bewusst geplant werden wie die technische Verbindung.

Für uns bei Ai11 gehört Zero Copy deshalb in die Daten- und Integrationsarchitektur. Entscheidend ist nicht nur, wo Daten liegen, sondern wer sie in welchem Kontext nutzen darf und wie dieser Zugriff nachvollziehbar bleibt.

Sie möchten prüfen, welche Daten in Ihrer Architektur sinnvoll föderiert werden können und wie Berechtigungen dabei kontrollierbar bleiben? Kontaktieren Sie uns.