Unerwartetes Verhalten in Snowflake’s Cortex AI

1. Einführung

KI überall, aber zu welchem Preis?

KI dringt in alle Bereiche der Technologie vor, von Chatbots in Business-Analytics-Tools bis hin zu generativen Modellen, die die Datenentdeckung vorantreiben. Diese Innovationen bieten enorme Effizienzgewinne und fördern das Unternehmenswachstum, bringen jedoch auch unbekannte Sicherheitsrisiken mit sich. Ein besonders besorgniserregendes Risiko ist die unerwartete Datenoffenlegung. Ob es sich um M365 Co-Pilot, Snowflake Cortex AI oder einen anderen KI-Dienst handelt – Ihre Sicherheit ist nur so gut wie die von Ihnen konfigurierten Zugriffsrichtlinien.

In diesem Beitrag untersuchen wir, wie der CORTEX Search Service von Snowflake, ein hochmodernes, KI-gestütztes Such- und Abruf-Tool, dazu führen könnte, dass sensible Daten innerhalb Ihrer Snowflake-Nutzerbasis offengelegt werden – selbst in einer sicheren Umgebung mit streng konfigurierten Zugriffs- und Maskierungsrichtlinien.

Am Ende des Beitrags erklären wir, wie Cyera dabei helfen kann, dieses Problem zu verhindern. Wenn Sie weitere Unterstützung benötigen, wenden Sie sich bitte an support@cyera.com.

Wir möchten dem gesamten Snowflake-Team für ihre Transparenz, Reaktionsfähigkeit und Zusammenarbeit während des gesamten Prozesses danken. Wir schätzen ihre Unterstützung wirklich sehr.

2. Anwendungsfall: Missbrauch der CORTEX-Suche zur Anzeige sensibler Daten

2.1 Dynamische Maskierung in Snowflake

Dynamische Datenmaskierung ist Snowflakes Methode, um einzuschränken, wie Daten angezeigt werden – abhängig davon, wer die Abfrage stellt. In der Regel wird eine Maskierungsrichtlinie für sensible Spalten festgelegt, zum Beispiel so:

• ADMIN-Rolle sieht echte Daten (val).
• Alle anderen sehen maskierte Daten (*****).

Dies ist entscheidend, um Compliance-Anforderungen einzuhalten – z. B. den Schutz von PII oder Finanzdaten zur Abfragezeit, ohne Daten zu duplizieren.

2.2 Der CORTEX-Suchdienst

Snowflakes CORTEX Search ist dafür konzipiert, unscharfe Suchen und LLM-gesteuerte RAG- (Retrieval Augmented Generation) Anwendungsfälle zu unterstützen.

In der Praxis:

• CORTEX läuft unter einer Rolle mit dem Privileg CREATE CORTEX SEARCH SERVICE.
• Benutzer benötigen keine direkten SELECT-Berechtigungen für die zugrunde liegenden Tabellen.
• Ein Benutzer kann Daten über CORTEX SEARCH abfragen, solange er die BERECHTIGUNG "USAGE" für den Dienst hat.

2.3 RECHTE DER ANRUFER vs RECHTE DER EIGENTÜMER

Eines der wichtigsten Konzepte in der Datenbanksicherheit ist der Unterschied zwischen Rechten des Aufrufers und Rechten des Eigentümers.

Rechte der Aufrufenden: Der Prozess oder die Funktion wird mit denselben Rechten wie der Benutzer ausgeführt, der sie aufruft. Wenn Sie eingeschränkte Rechte haben, sind die Fähigkeiten der Funktion entsprechend eingeschränkt.

Praxisbeispiel: Stellen Sie sich einen normalen Benutzer in einem Kollaborationstool vor, der keinen Zugriff auf einen privaten Ordner hat. Auch jedes Skript, das er von seinem Konto ausführt, hat weiterhin keinen Zugriff auf diesen privaten Ordner – es ist an **seine** Rechte gebunden.

Eigentümerrechte: Der Prozess oder die Funktion wird mit den Rechten des Eigentümers des Objekts ausgeführt, unabhängig davon, wer sie aufruft. Wenn der Eigentümer erhöhte oder Administratorrechte hat, kann die Funktion Dinge tun, die der Aufrufer selbst normalerweise nicht tun könnte.

Praxisbeispiel: In einigen Systemen, wie bestimmten SaaS-Plattformen oder fortgeschrittenen gespeicherten Prozeduren, wird eine Funktion mit den Berechtigungen einer privilegierten Rolle (wie einer Administratorrolle) ausgeführt. Selbst wenn ein normaler Benutzer die Aktion auslöst, läuft der Code mit den erweiterten Rechten der Servicerolle und kann Daten lesen oder schreiben, auf die der Benutzer normalerweise keinen Zugriff hätte.

In vielen Datenbanksystemen werden Funktionen unter den Rechten des Aufrufers ausgeführt, um das Prinzip der minimalen Rechte zu wahren. Im CORTEX Search-Szenario von Snowflake hingegen – wie auch bei anderen Funktionen innerhalb von Snowflake – läuft der Code unter den Rechten des Eigentümers des Dienstes, oft eine mächtige Rolle wie CORTEX_ROLE oder sogar ACCOUNTADMIN. Das bedeutet, dass jeder, der den Dienst aufrufen kann, während dieser Ausführung die potenziell höheren Rechte des Eigentümers erbt. Bei angemessener Nutzung können die Rechte des Eigentümers dazu beitragen, das Prinzip der minimalen Rechte einzuhalten, wie zum Beispiel bei gespeicherten Prozeduren. Hier kann der Eigentümer bestimmte administrative Aufgaben, wie das Bereinigen alter Daten, an eine andere Rolle (den Aufrufer) delegieren, ohne dieser Rolle allgemeinere Rechte zu gewähren, wie etwa das Recht, alle Daten aus einer bestimmten Tabelle zu löschen. Für Cortex Search könnte dies helfen, den Zugriff auf ausgewählte Spalten einer Tabelle zu ermöglichen, ohne Zugriff auf die gesamte Tabelle zu gewähren.

Warum das wichtig ist:

• Wenn CORTEX Search (oder ein anderer zustandsbehafteter Dienst) weitreichenden Datenzugriff (Eigentümerrechte) erhält, dann erhält jeder Benutzer, der ihn aufrufen kann, einen ähnlichen Lesezugriff wie der Eigentümer, der den Index erstellt hat. Selbst wenn sie keine direkte SELECT-Berechtigung für eine Tabelle haben, können sie nicht maskierte Daten abrufen, da die Abfrage im Namen des Eigentümers ausgeführt wird.
• Im Gegensatz dazu würde ein Dienst, der die Rechte des Anrufers verwendet, nur Daten zurückgeben, die der tatsächliche Benutzer sehen darf, wodurch dynamische Maskierung und Zugriffskontrollen erhalten bleiben.

Da CORTEX Search die Rechte des Eigentümers verwendet, „leiht“ es sich effektiv alle Privilegien der Rolle, unter der es ausgeführt wird. Dadurch kann es einem Benutzer mit geringeren Rechten möglicherweise Lesezugriff auf indizierte Daten gewähren. Die Nutzung dieser Funktion durch einen Administrator, der mit diesen Details nicht vertraut ist, kann zu unbeabsichtigter Offenlegung von Informationen im Snowflake-Konto des Unternehmens führen.

3. Technische Aufschlüsselung

Schritt 1: Erstellen des CORTEX-Suchdienstes mit AccountAdmin

Sie als accountadmin richten den CORTEX Search Service ein, damit analyst_user die salary_info-Tabelle abfragen kann. Der Dienst wird mit der Rolle accountadmin initialisiert, die vollen Zugriff auf alle Daten in der Umgebung hat.

Visual 1: Video zur Erstellung des CORTEX-Dienstes mit AccountAdmin

Schritt 2: Berechtigungen für analyst_user vergeben

Als Nächstes erteilen Sie analyst_user die erforderlichen Berechtigungen, um den CORTEX Search Service zu nutzen.

Visual 2: Foto der an analyst_user gewährten Zuschüsse

An diesem Punkt scheint alles in Ordnung zu sein. Allerdings könnte der accountadmin fälschlicherweise davon ausgehen, dass analyst_user den CORTEX Search Service nutzen kann, um mit der Tabelle unter Verwendung seiner eigenen (analyst_user) Berechtigungen zu interagieren.

Schritt 3: Ausnutzen der Konfiguration

Nun versucht analyst_user, die salary_info-Tabelle direkt abzufragen,

Wenig überraschend werden diese Daten maskiert zurückgegeben.

Aber dann versucht analyst_user etwas anderes – sie verwenden den CORTEX Search Service, um dieselbe Tabelle abzufragen:

‍VOLLSTÄNDIGE DEMO

Vollständige Demo, die den gesamten Ablauf vom Erstellen des Cortex-Suchdienstes bis zur Nutzung und dem Umgehen der Maskierungsrichtlinie zeigt.

4. Lösung: Verhindern Sie, dass KI über das Ziel hinausschießt

Snowflake-Kontoadministratoren können dieses Verhalten jedoch vermeiden.

Für Snowflake-Nutzer (Sie):

✅ Setzen Sie CORTEX Search nicht mit hoch privilegierten Rollen wie ACCOUNTADMIN ein, es sei denn, Sie möchten Ihre Rechte an die Nutzer von CORTEX Search weitergeben. Verwenden Sie eine Service-Rolle mit minimalen Rechten, die nur den minimal erforderlichen SELECT-Zugriff besitzt.

✅ Isolieren Sie sensible Tabellen von allgemeinen Suchdiensten. Wenn eine Tabelle Maskierungsrichtlinien oder compliance-relevante Daten enthält, indexieren Sie die Spalten mit diesen sensiblen Daten nicht in einem Cortex Search-Dienst.

✅ Seien Sie vorsichtig mit USAGE-Berechtigungen beim Cortex Search Service – wenn Sie der Eigentümer sind, kann jede Rolle, der Sie USAGE für den Service gewähren, auf alle materialisierten Inhalte zugreifen.

✅ Auditieren Sie die Rollennutzung: Überprüfen Sie regelmäßig, welche Rolle zur Erstellung jedes CORTEX Search Service verwendet wurde. Hatte der Ersteller vollen Zugriff auf sensible Tabellen, ziehen Sie in Erwägung, den Service zu entziehen oder neu aufzubauen.

Fazit: KI-Dienste wie CORTEX Search können bei falscher Konfiguration zu unbeabsichtigter Offenlegung von Informationen führen. Ohne sorgfältige Eingrenzung könnten sie es Nutzern mit niedrigen Berechtigungen ermöglichen, unbemerkt Maskierungen zu umgehen und sensible Daten abzurufen – ganz ohne erforderliche SELECT-Berechtigung.

Das Prinzip der geringsten Privilegien muss auch für KI gelten, denn KI sieht Ihre Daten nicht nur, sie spricht auch darüber.

5. Fazit: KI-Dienste stehen nicht über Zugriffskontrollen

CORTEX Search ist ein leistungsstarkes, KI-gestütztes Tool, das die natürliche Sprachsuche für unstrukturierte Unternehmensdaten ermöglicht. Doch diese Macht muss verantwortungsvoll eingesetzt werden. Wie gezeigt, läuft CORTEX Search mit den Rechten der Eigentümer und nicht mit denen der Aufrufer. Das bedeutet, dass Abfragen mit den Berechtigungen der privilegierten Rolle ausgeführt werden, die den Dienst erstellt hat, und nicht mit denen des Nutzers, der ihn aufruft.

In diesem Fall könnten die erwarteten Ergebnisse und Fähigkeiten des dynamischen Maskierungsmechanismus von Snowflake nicht erreicht werden. Eine maskierte Spalte wird nur dann maskiert, wenn die Zugriffskontrolle durchgesetzt wird. Bei einer Fehlkonfiguration kann CORTEX einem Benutzer ermöglichen, SELECT zu umgehen und dennoch Klartextwerte zu sehen.

Tatsächlich kann KI unbeabsichtigt zu einem Kanal werden, über den Daten innerhalb einer Organisation offengelegt werden. Genau deshalb ist Cyera so wichtig: Es hilft Ihnen, sensible Daten in Ihrer Umgebung automatisch zu entdecken, zu klassifizieren und zu schützen. Anstatt zu raten oder stundenlang manuell zu suchen, wissen Sie genau, was vorhanden ist, wie sensibel es ist und ob es gefährdet ist.

Verantwortungsvolle Offenlegung und Reaktion der Anbieter

Dieses Problem wurde verantwortungsbewusst an das Snowflake-Team gemeldet, das schnell und professionell reagierte. In Zusammenarbeit mit den Sicherheits- und Produktteams wurden bereits erste Maßnahmen in Form von Aktualisierungen der CORTEX Search Service-Dokumentation umgesetzt, um die Auswirkungen von durch den Eigentümer ausgeführten Rechten zu verdeutlichen. Weitere Verbesserungen sind in Planung, darunter die Bereitstellung eines Ausführungskontexts mit den Rechten des Aufrufers für bestimmte Snowflake-Anwendungsfälle sowie verbesserte UI-Warnungen für Administratoren, um unbeabsichtigte Fehlkonfigurationen zu verhindern. Wir schätzen das Engagement von Snowflake und das Bestreben, die Sicherheitslage der Plattform weiter zu stärken.

Cyera ist bereit, Ihnen dabei zu helfen, Ihre Daten mit DSPM und DLP zu schützen. Starten Sie noch heute mit einer Demo.