Connected Apps und KI-Tools: Lehren aus Salesloft Drift

Der Salesloft-Drift-Vorfall hat gezeigt, dass eine Connected App ein unüberwachter Weg in Ihre Org sein kann, und KI-Integrationen fügen jedes Quartal neue hinzu. Im August 2025 haben Angreifer mit gestohlenen OAuth-Tokens einer KI-Chat-App Daten aus Kunden-Orgs exportiert, ohne in Salesforce selbst einzubrechen. Jedes Tool, das ein Refresh Token für Ihre Org hält, gehört zu Ihrer Sicherheitsgrenze. Ein Hersteller braucht pro App einen Verantwortlichen, enge Scopes, einen eigenen Integrationsuser mit wenig Rechten und eine Token-Richtlinie, dazu Logs, die weit genug zurückreichen.

Was ist beim Salesloft-Drift-Vorfall passiert?

Drift ist ein KI-Chat-Agent von Salesloft, den Unternehmen über eine Connected App mit Salesforce verbunden hatten. Laut Google Threat Intelligence1 nutzte eine als UNC6395 geführte Gruppe im August 2025 gestohlene OAuth-Access- und Refresh-Tokens der Drift-App. Der Angreifer fragte in Kunden-Orgs Cases, Accounts, User und Opportunities ab, exportierte die Ergebnisse und löschte danach die Query-Jobs; die Logs blieben erhalten.

GTIG geht davon aus, dass es vor allem um Zugangsdaten ging: AWS-Schlüssel, Passwörter und Snowflake-Tokens in den exportierten Datensätzen. The Hacker News2 berichtet, dass GTIG mehr als 700 potenziell betroffene Organisationen kannte, Salesforce sprach von einer „small number of customers“.

1. 08.08.2025Angreifer beginnen, gestohlene Drift-Tokens zu nutzen
2. 18.08.2025Zugriffe laufen laut GTIG mindestens bis zu diesem Tag
3. 20.08.2025Salesloft und Salesforce widerrufen alle aktiven Drift-Tokens
4. 28.08.2025Salesforce schaltet alle Salesloft-Integrationen ab
5. 07.09.2025Integrationen wieder freigegeben, außer Drift

Salesforce nahm die App außerdem aus dem AppExchange, laut seiner Sicherheitsmeldung3. Das GTIG-Update vom 28. August ergänzte, dass auch Drift-Email-Tokens gegen Google Workspace eingesetzt wurden und Kunden jedes in Drift gespeicherte Token als kompromittiert behandeln sollten.

GTIG und Salesforce stellen beide fest, dass der Vorfall nicht auf eine Schwachstelle der Salesforce-Plattform zurückgeht. Das stimmt und hilft Ihnen trotzdem nicht: Salesforce sah eine autorisierte App, die mit gültigen Tokens die API aufrief, und das sieht auf den ersten Blick aus wie eine normale Synchronisation.

Warum betrifft das gerade KI-Integrationen?

Drift war ein KI-Tool. Die meisten Unternehmen schließen gerade weitere an: Meeting-Recorder, die Gesprächsnotizen in Opportunities schreiben, E-Mail-Assistenten, Chatbots, die Leads und Fälle anlegen. Jedes läuft auf den Servern des Anbieters und hält ein Refresh Token für Ihre Org, standardmäßig bis jemand es widerruft. Vier Fragen entscheiden über den Schaden, wenn ein solches Token gestohlen wird:

• Als welcher Benutzer handelt das Token? Hat der Anbieter beim Einrichten einen Admin verlangt, liest das Token, was ein Admin liest.
• Welche Scopes wurden erteilt? GTIG warnt ausdrücklich vor zu weiten Scopes wie full.
• Wie lange gilt das Token? „Gültig bis zum Widerruf“ ist laut Dokumentation der OAuth-Richtlinien4 der Standard bei Connected Apps.
• Von wo darf es genutzt werden? Der Angreifer kam von Cloud-Hosts und Tor-Ausgangsknoten, die Login-IP-Bereiche, beschränkt auf die Adressen des Anbieters, abgewiesen hätten.

Drift war nicht der letzte Fall. Im November 2025 hat Salesforce die OAuth-Tokens widerrufen5, die von Gainsight veröffentlichte Anwendungen nutzten, nach auffälligen Zugriffen über VPN- und Tor-Adressen, wieder ohne Schwachstelle in der Plattform. Angreifer brauchen kein Loch in Salesforce, wenn eine OAuth-App ihnen den Schlüssel gibt.

Für einen Hersteller haben die exportierten Objekte besonderes Gewicht. Opportunities und Accounts enthalten Händlerkonditionen und Projektpreise. Die User-Abfrage im GTIG-Bericht zog Namen, Titel, E-Mails und Mobilnummern aktiver Benutzer, eine fertige Phishing-Liste. Und in den Servicefällen eines Maschinenbauers würde ich genau das erwarten, wonach GTIG suchen lässt: Login-URLs, VPN-Daten und Passwörter, eingetragen von Technikern, die Fernzugriff auf eine Maschine im Werk eines Kunden brauchten. Das trifft zuerst den Kunden.

Salesforce hat den OAuth-Zugang seit 2025 verschärft

Die Schritte im Einzelnen:

• Anfang September 2025: nicht installierte Connected Apps gesperrt. Apps, die Benutzer autorisiert haben, ohne dass ein Admin sie installiert hat, sind für die meisten Benutzer nicht mehr erreichbar, laut Salesforce-Admins-Blog6. Wer „Approve Uninstalled Connected Apps“ oder „Use Any API Client“ hat, umgeht die Sperre; diese Berechtigungen sollten also selten sein.
• Spring ’26: keine neuen Connected Apps. Das Anlegen ist standardmäßig gesperrt, außer über Paketinstallation, und die Freischaltung braucht eine Anfrage beim Support, laut Spring-’26-Überblick für Architekten7.
• External Client Apps als Ersatz. Eine ECA ist standardmäßig geschlossen und funktioniert in einer Org erst, wenn ein Admin sie installiert. Admin-Richtlinien lassen sich nicht paketieren, ein Anbieter kann Ihnen also keine laxe Token-Richtlinie mitliefern, und ECAs sind laut Entwickler-Blog8 vollständig als Metadaten abbildbar. Ihre Richtlinien können im Repository liegen und durchs Review gehen.
• Refresh-Token-Rotation bei neuen ECAs, standardmäßig aktiv und gesperrt. Laut Salesforce verkleinert sie den Schaden eines gestohlenen Refresh Tokens deutlich (Help-Artikel9).
• Pflichtkontrollen für Partner-Apps. Apps, die in mehr als zwei Produktions-Orgs von Kunden laufen, mussten bis 11. Mai 2026 PKCE, Refresh-Token-Rotation, einen Ablauf nach 30 Tagen Inaktivität und eine IP-Allowlist für Refresh Tokens aktivieren, soweit die jeweilige Kontrolle auf den OAuth-Flow der App anwendbar ist, laut Partner-FAQ10.

ECAs unterstützen außerdem den Username-Password Flow nicht. Was das für ältere ERP- und Middleware-Anbindungen heißt, steht in Passwort-Integrationen enden 2027.

Welche Kontrollen braucht ein Hersteller jetzt?

Das würde ich für jede Connected App und ECA in Produktion verlangen, beginnend mit den KI-Tools:

1. Eine Bestandsliste mit Verantwortlichen. Connected Apps OAuth Usage im Setup listet jede App, ihre Benutzer und ob sie installiert ist. Jeder Eintrag bekommt einen fachlichen Verantwortlichen und einen Zweck. Apps, die niemand beansprucht, werden gesperrt, was ihre Sitzungen sofort beendet; kündigen Sie das vorher an.
2. Installieren und vorab autorisieren. „Admin approved users are pre-authorized“ setzen und den Zugang über ein Permission Set pro App vergeben.
3. Ein eigener Integrationsuser pro serverseitiger App. Die Lizenz Salesforce Integration mit dem Profil „Minimum Access - API Only Integrations“ erlaubt laut Salesforce-Hilfe11 nur API-Zugriff. Das Profil selbst ist konfigurierbar; ich würde die Rechte der App über Permission Sets ergänzen. Ein Chatbot auf der Website muss Leads und Fälle anlegen, keine Opportunities lesen.
4. API Enabled nur über Permission Sets, wie GTIG empfiehlt, damit ein normaler Benutzer nicht versehentlich einen API-Client autorisiert.
5. Kein Scope full. Besteht ein Anbieter darauf, fragen Sie schriftlich nach dem Grund.
6. Eine Token-Richtlinie. „Gültig bis zum Widerruf“ durch Ablauf bei Nichtnutzung ersetzen. Bei IP-Grenzen hilft die Connected-App-Einstellung „Enforce IP restrictions“ allein wenig: Sie ist laut Dokumentation der OAuth-Richtlinien4 ohnehin der Standard und wendet nur die in der Org konfigurierten IP-Bereiche an, etwa die im Profil des Benutzers. Die eigentliche Kontrolle sind die veröffentlichten Adressbereiche des Anbieters als Login-IP-Bereiche im Profil des Integrationsusers oder die IP-Allowlist für Refresh Tokens einer External Client App.
7. Logs, die zurückreichen. Ohne Add-on bekommen Enterprise- und Unlimited-Orgs ausgewählte Ereignistypen mit einem Tag Aufbewahrung, laut Event-Monitoring-FAQ12. Bezahlte Logs halten standardmäßig 30 Tage, bis zu einem Jahr, und beginnen erst mit dem Vertragsbeginn. Drift lief mindestens zehn Tage, bevor es bekannt wurde.
8. Keine Zugangsdaten in Datensätzen. Fälle, Kommentare und E-Mails nach Passwörtern, VPN-Begriffen und AWS-Schlüsseln durchsuchen, wie GTIG sie auflistet, und dem Service einen Tresor für Fernwartungszugänge geben.
9. Ein Fragebogen für Anbieter und eine Widerrufsübung. Fragen Sie jeden Anbieter, wo Ihre Tokens liegen und ob Rotation und IP-Allowlist aktiv sind. Intern legen Sie fest, wer nachts die Tokens einer App widerruft und welcher Prozess dann stillsteht.

Das meiste davon ist Konfiguration. Event Monitoring kostet Geld und verdient eine bewusste Entscheidung.

Rechenbeispiel: neun Apps bei einem Maschinenbauer

Nehmen wir einen Maschinenbauer mit Sales Cloud, Service Cloud, SAP und 80 Händlern. Alle Zahlen sind Annahmen. Connected Apps OAuth Usage zeigt neun Apps, darunter die SAP-Middleware, ein Backup-Tool, einen KI-Meeting-Recorder für 25 Vertriebsmitarbeitende, einen KI-Chatbot für Ersatzteilanfragen auf der Website und eine App, die niemand kennt.

Der Chatbot ist das Drift-Muster. Sein Integrationsuser wurde im Proof of Concept von einem Systemadministrator kopiert, der Scope ist full, das Refresh Token gilt bis zum Widerruf, IP-Beschränkungen sind gelockert. Er muss Leads und Fälle anlegen. Er könnte jede Preisvereinbarung mit Händlern lesen.

Der Meeting-Recorder läuft pro Benutzer, jeder mit seinen eigenen Rechten, ähnlich dem Named-User-Modell in Hosted MCP Server und Datenzugriff. Der Unterschied: Der Anbieter speichert 25 Refresh Tokens auf seinen eigenen Servern.

Die Korrekturen dauern angenommen zwei Wochen. Der Chatbot bekommt einen eigenen Integrationsuser, der nur Leads und Fälle anlegen darf, full entfällt, die IP-Bereiche des Anbieters kommen als Login-IP-Bereiche in sein Profil. Der Meeting-Recorder wird installiert, auf ein Permission Set beschränkt, seine Tokens laufen nach 30 Tagen ohne Nutzung ab. Die unbekannte App wird gesperrt. Eine Suche in den Servicefällen findet, angenommen, 340 Datensätze mit Passwörtern oder Fernwartungsdaten; sie werden bereinigt und die Zugänge mit den betroffenen Kunden geändert.

Nichts davon verhindert, dass ein Anbieter Ihre Tokens verliert. Es entscheidet, was ein gestohlenes Token kann: von einer fremden Adresse nichts, von einer erlaubten Leads anlegen, aber keine Händlerpreise lesen.

Jede App markieren, die Salesforce-Daten an ein Modell schickt

Fangen Sie mit den KI-Tools an, weil sie die neuesten und am wenigsten geprüften sind: Markieren Sie jede App, die Salesforce-Daten an ein Modell schickt, und prüfen Sie für diese zuerst Benutzer, Scopes und Token-Richtlinie. Ihr zweites Risiko ist Prompt Injection im Händlerportal. Eine Liste aller Schnittstellen mit benannten Verantwortlichen gehört zu meiner Arbeit an Salesforce-Schnittstellen.

Quellen12

1. 1Google Threat Intelligence (öffnet in einem neuen Tab)cloud.google.com
2. 2The Hacker News (öffnet in einem neuen Tab)thehackernews.com
3. 3Sicherheitsmeldung (öffnet in einem neuen Tab)help.salesforce.com
4. 4Dokumentation der OAuth-Richtlinien (öffnet in einem neuen Tab)help.salesforce.com
5. 5OAuth-Tokens widerrufen (öffnet in einem neuen Tab)help.salesforce.com
6. 6Salesforce-Admins-Blog (öffnet in einem neuen Tab)admin.salesforce.com
7. 7Spring-’26-Überblick für Architekten (öffnet in einem neuen Tab)salesforce.com
8. 8Entwickler-Blog (öffnet in einem neuen Tab)developer.salesforce.com
9. 9Help-Artikel (öffnet in einem neuen Tab)help.salesforce.com
10. 10Partner-FAQ (öffnet in einem neuen Tab)help.salesforce.com
11. 11Salesforce-Hilfe (öffnet in einem neuen Tab)help.salesforce.com
12. 12Event-Monitoring-FAQ (öffnet in einem neuen Tab)help.salesforce.com