Sicherheitsänderungen bei Salesforce Connected Apps: ein Leitfaden

Salesforce stellt den Zugriff von Connected Apps von "standardmäßig offen" auf "standardmäßig genehmigt" um. Nicht installierte Connected Apps werden jetzt für die meisten Benutzer blockiert, OAuth 2.0 Device Flow wird eingestellt, und Salesforce lenkt alle in Richtung External Client Apps als langfristigen Ersatz. Wenn Ihre Org nicht geprüft hat, was tatsächlich auf sie zugreifen darf, wird eine Integration ausfallen, bevor Sie den Grund kennen.

Was ändert sich bei Connected Apps wirklich?

Salesforce blockiert nicht installierte Connected Apps jetzt standardmäßig. Das heißt: Jede App, die ein Benutzer selbst autorisiert hat, ohne dass ein Admin sie formell in der Org installiert hat, verliert den Zugriff, sofern niemand eine bestimmte Bypass-Berechtigung vergibt. Apps, die noch auf OAuth 2.0 Device Flow setzen, verlieren den Zugriff vollständig, auch wenn sie zuvor autorisiert waren. Langfristig gibt Salesforce die klassische Connected App als primäres Integrationsobjekt zugunsten von External Client Apps auf, die die App-Definition von ihren Richtlinien trennen und Admins eine feinere Kontrolle über Scopes, IP-Bereiche und Sitzungsverhalten geben.

Warum verschärft Salesforce das gerade jetzt?

Kurz gesagt: Die OAuth-Autorisierung wurde zu einem beliebten Angriffsziel. Angreifer gaben sich als IT-Support aus, brachten Mitarbeitende dazu, legitim wirkende Connected Apps zu genehmigen, und nutzten diesen Zugriff dann, um über Wochen unbemerkt Daten abzuziehen. Das ist ein Social-Engineering-Problem und keine Schwachstelle der Plattform, doch Salesforce antwortet architektonisch: Die Standardhaltung lautet nun "nichts verbindet sich, bis ein Admin zustimmt".

Dieser Schritt ist vernünftig. Er bedeutet aber auch, dass Org-Hygiene, die früher optional war, also genau zu wissen, welche Apps API-Zugriff haben und warum, jetzt den Unterschied zwischen einem ruhigen Dienstag und einem ungeplanten Incident-Call ausmacht.

Wo fallen Integrationen tatsächlich aus?

Unsere Erfahrung bei der Begleitung von Salesforce-Orgs durch Plattformänderungen zeigt: Die Ausfälle treten selten dort auf, wo Teams sie erwarten. Achten Sie auf:

• Middleware- und iPaaS-Konnektoren, die vor Jahren von jemandem eingerichtet wurden, der das Team inzwischen verlassen hat, ohne dokumentierten Verantwortlichen.
• Data Loader-Jobs und geplante ETL-Skripte, die für unbeaufsichtigte Läufe noch OAuth Device Flow verwenden.
• Reporting- oder BI-Tools, die ein einzelner Benutzer autorisiert hat, statt sie org-weit zu installieren.
• Partner- oder ISV-Apps, die nie formell installiert, sondern nur einmal während eines Pilotprojekts autorisiert wurden.

All das kann monatelang unbemerkt bleiben, bis die Einschränkung greift und der Sync-Job einfach stoppt, oft ohne eindeutige Fehlermeldung, die auf die Ursache verweist.

Wie prüfen Sie Ihre Org, bevor die Einschränkungen greifen?

Dafür brauchen Sie keine neuen Tools, nur einen gezielten Durchgang durch Setup:

• Öffnen Sie Setup > Connected Apps OAuth Usage und listen Sie jede aktuell autorisierte App auf, nicht nur die von Ihnen installierten.
• Markieren Sie alles mit einer "Install"-Aktion: Das ist Ihre Liste nicht installierter, gefährdeter Apps.
• Prüfen Sie das Datum der letzten Nutzung. Apps ohne aktuelle Aktivität sollten Sie widerrufen, statt sie "für alle Fälle" zu behalten.
• Klären Sie die API Access Control-Richtlinie Ihrer Org und wer die Berechtigung "Approve Uninstalled Connected Apps" besitzt.
• Halten Sie für alles, was Sie behalten, fest, wem es gehört und warum. Diese Dokumentation spart Ihnen beim nächsten Plattformwechsel Zeit, nicht nur bei diesem.

Was sollte sich künftig an der Governance Ihrer Integrationen ändern?

Nehmen Sie das als Anlass, die Integrations-Governance zu formalisieren, nicht als einmalige Aufräumaktion. Neue Integrationen sollten vom ersten Tag an bewusst installiert und eingegrenzt werden, statt ad hoc von der Person autorisiert zu werden, die sie eingerichtet hat. Wenn Sie neue externe Verbindungen planen, vermeidet der Aufbau als External Client Apps von Anfang an eine zweite Migration.

Genau diese Arbeit leisten wir gemeinsam mit internen Salesforce-Teams: bestehende Integrationen erfassen, entscheiden, was bleibt, wegfällt oder neu gebaut wird, und das Ergebnis in einen Entwicklungsprozess überführen, der Zugriffskontrolle als Teil des Releases behandelt und nicht als Nachgedanken.

Wenn Sie den Connected-App-Bestand Ihrer Org lieber gemeinsam mit jemandem durchgehen möchten, bevor das nächste Plattform-Update kommt, nehmen Sie Kontakt auf, und wir helfen Ihnen, aus der Checkliste etwas Wiederholbares zu machen.

FAQ

Fallen dadurch meine bestehenden Salesforce-Integrationen aus?

Nur wenn sie nicht installiert sind oder noch OAuth 2.0 Device Flow verwenden. Installierte Apps und moderne Authentifizierungsflows funktionieren unverändert weiter.

Was ist der Unterschied zwischen einer Connected App und einer External Client App?

External Client Apps trennen die Identität der App von ihren Zugriffsrichtlinien und geben Admins eine genauere Kontrolle über Scopes und Sitzungen. Salesforce positioniert sie als langfristigen Ersatz für klassische Connected Apps.

Wer sollte die Berechtigung "Approve Uninstalled Connected Apps" erhalten?

Halten Sie den Kreis klein, Admins, die neue Apps testen, und Entwickler, die Integrationen pflegen, denn es ist ein Alles-oder-nichts-Bypass und keine Freigabe pro App.

Wie oft sollten wir den Zugriff von Connected Apps prüfen?

Mindestens vierteljährlich und sofort nach jedem Sicherheits-Release von Salesforce, denn ausufernde Berechtigungen entstehen schleichend und werden leicht übersehen.