Wie wirkt sich die Multi-Faktor-Authentifizierung von Salesforce auf Integrationen aus?
Die Multi-Faktor-Authentifizierung (MFA) von Salesforce wirkt sich auf Integrationen aus, weil sie für jede interaktive Anmeldung einen zusätzlichen Verifizierungsschritt verlangt.
Das bedeutet: Integrationen, die sich mit normalen Benutzeranmeldedaten wie Benutzername und Passwort anmelden, können fehlschlagen, sobald die MFA erzwungen wird. Um Unterbrechungen zu vermeiden, empfiehlt es sich, einen eigenen Integrationsbenutzer mit reinem API-Zugriff zu verwenden. Dieser ist von der MFA ausgenommen und sorgt für einen unterbrechungsfreien Zugriff von System zu System.
Salesforce schreibt die Multi-Faktor-Authentifizierung (MFA) inzwischen für alle direkten Anmeldungen über die Benutzeroberfläche verbindlich vor, um Sicherheitsverletzungen durch gestohlene Anmeldedaten oder schwache Passwörter zu verhindern.
Wie die MFA durchgesetzt wird, hängt jedoch davon ab, wie Benutzer auf Salesforce zugreifen – insbesondere bei automatisierten Integrationen.
In diesem Artikel erklären wir, was Multi-Faktor-Authentifizierung ist, wer von der Salesforce-MFA betroffen und wer davon ausgenommen ist, wie sie sich auf Integrationen auswirkt und was Sie tun müssen, um Unterbrechungen Ihrer Integration zu vermeiden.
Inhalt
-
Methoden der Multi-Faktor-Authentifizierung (MFA) von Salesforce
- Best Practices zur Vermeidung MFA-bedingter Integrationsfehler
Was ist die Multi-Faktor-Authentifizierung (MFA) von Salesforce?
Die Multi-Faktor-Authentifizierung (MFA) von Salesforce ergänzt die Anmeldung an Ihrem Konto um eine zusätzliche Sicherheitsebene.
Statt sich allein auf Benutzername und Passwort zu verlassen, verlangt die MFA einen zusätzlichen Verifizierungsschritt – etwa einen Code aus einer mobilen App, einen Hardware-Sicherheitsschlüssel oder einen Einmal-Passcode per SMS oder E-Mail. Durch die Kombination von etwas, das Sie wissen (Ihr Passwort), mit etwas, das Sie besitzen (der zusätzliche Faktor), macht Salesforce es Unbefugten deutlich schwerer, auf Ihr Konto zuzugreifen, selbst wenn Ihr Passwort kompromittiert wurde.
Methoden der Multi-Faktor-Authentifizierung (MFA) von Salesforce
Salesforce hat die Multi-Faktor-Authentifizierung (MFA) als zusätzliche Sicherheitsebene eingeführt, um Benutzerkonten vor unbefugtem Zugriff zu schützen. Statt sich allein auf Benutzername und Passwort zu verlassen, müssen Benutzer bei der MFA ihre Identität mit einem zweiten Authentifizierungsfaktor bestätigen. Zur Auswahl stehen:
- Salesforce Authenticator-App: Freigabe per Push-Benachrichtigung.
- Authenticator-Apps von Drittanbietern: Zum Beispiel Google Authenticator, Microsoft Authenticator oder Authy.
- Sicherheitsschlüssel: Hardwarebasierte Authentifizierung, etwa mit einem YubiKey.
- Einmal-Passcodes: Zustellung per SMS oder E-Mail (je nach Unternehmensrichtlinie).
Wer ist von der Salesforce-MFA betroffen?
Die MFA gilt für alle Benutzer, die sich über die Standard-Anmeldeseite bei Salesforce anmelden, und ebenso für jede Anwendung, die eine interaktive Anmeldung erfordert. Folgende Benutzertypen sind betroffen:
1. Standard-Benutzer von Salesforce (Administratoren und normale Benutzer)- Wenn sich ein Benutzer über die Salesforce-Benutzeroberfläche anmeldet (einschließlich Salesforce Classic, Lightning Experience oder mobiler Apps), muss er bei jeder Anmeldung die MFA durchlaufen.
- Das gilt für Systemadministratoren, Vertriebsmitarbeiter, Kundenservicemitarbeiter und alle anderen Mitarbeiter, die Salesforce interaktiv nutzen.
- Wenn ein Unternehmen Single Sign-On (SSO) nutzt, die MFA aber nicht auf Ebene des Identity Providers (IdP) erzwingt (z. B. Okta, Azure AD, Ping Identity), verlangt Salesforce bei der Anmeldung eine MFA.
- Wird die MFA bereits auf Ebene des IdP erzwungen, verlangt Salesforce keine zusätzliche MFA-Abfrage.
Wer ist von der Salesforce-MFA ausgenommen?
Für bestimmte Benutzer und Authentifizierungsmethoden ist die MFA nicht vorgeschrieben, darunter:
1. Reine API-Benutzer und Integrationsbenutzer- Benutzer, die sich mit API-Schlüsseln, OAuth-Flows oder Sicherheitstoken authentifizieren, benötigen keine MFA.
- Diese Ausnahme gibt es, weil API-basierte Authentifizierungsmethoden bereits auf einer sicheren tokenbasierten Authentifizierung beruhen, was das Risiko von Angriffen über Anmeldedaten verringert.
- Wird die MFA über den Identity Provider (IdP) des Unternehmens erzwungen (z. B. Okta, Microsoft Azure AD, PingFederate), betrachtet Salesforce dies als ausreichende Sicherheit.
- In diesem Fall muss der Benutzer in Salesforce keine zusätzliche MFA-Abfrage durchlaufen.
- Nicht authentifizierte Gastbenutzer (etwa Besucher einer öffentlichen Experience-Cloud-Site) unterliegen nicht der MFA-Pflicht.
Wie wirkt sich die MFA auf Salesforce-Integrationen aus?
Authentifiziert sich eine Integration mit den Anmeldedaten eines normalen Benutzers (z. B. mit Benutzername und Passwort), schlägt sie fehl, sobald die MFA-Pflicht aktiviert ist. Der Grund:
- Die Integration benötigt dann einen zweiten Authentifizierungsfaktor, der sich nicht automatisch bereitstellen lässt.
Wenn sich zum Beispiel eine iPaaS-Lösung mit den Anmeldedaten eines normalen Benutzers mit Salesforce verbindet, funktioniert sie nicht mehr, sobald die MFA erzwungen wird.
Welche Best Practices helfen, MFA-bedingte Integrationsfehler zu vermeiden?
Um Unterbrechungen zu vermeiden, sollten Integrationen Authentifizierungsmethoden verwenden, die ohne interaktive MFA auskommen:
Einen eigenen Integrationsbenutzer mit reinem API-Zugriff verwenden
- Statt für Integrationen ein normales Benutzerkonto zu verwenden, legen Sie einen eigenen API-Benutzer an, der von der MFA ausgenommen ist.
- Dieser Benutzer sollte nur die Berechtigungen erhalten, die für die Integration erforderlich sind.
So stellen Sie Ihre Integrationen von einem normalen Benutzer auf einen eigenen Integrationsbenutzer mit reinem API-Zugriff um:
- Folgen Sie den Schritten in diesem Artikel darüber, wie Sie Ihren Salesforce-Integrationsbenutzer einrichten.
- Nachdem Sie Ihren Integrationsbenutzer korrekt konfiguriert haben, müssen Sie Ihre bestehende Salesforce-Verbindung in MyRapidi neu autorisieren, und zwar über den neuen Integrationsbenutzer.
Das war’s schon!
Ein eigener Integrationsbenutzer mit reinem API-Zugriff ist für Sicherheit, Stabilität und Compliance unverzichtbar. Zudem ist ein solcher Benutzer speziell für die Kommunikation von System zu System konfiguriert und sorgt so jederzeit für einen unterbrechungsfreien Zugriff.
Wenn Sie Unterstützung benötigen, wenden Sie sich bitte an unser Support-Team.
Bereit für ein Upgrade Ihrer Systeme?
Wechseln Sie nahtlos von Dynamics NAV zu Dynamics 365 Business Central oder optimieren Sie Ihre Integrationen beim Umstieg von Salesforce auf Dynamics CRM oder HubSpot. RAPIDI macht es einfach, schnell und stressfrei. Kontaktieren Sie uns noch heute, um über Ihre Upgrade- und Integrationsanforderungen zu sprechen.
Wie wirkt sich die Salesforce-MFA auf Integrationen aus, die normale Benutzeranmeldedaten verwenden?
Integrationen, die sich mit dem Login eines normalen Salesforce-Benutzers anmelden, können fehlschlagen, sobald die MFA erzwungen wird, weil sich der zweite Authentifizierungsfaktor nicht automatisch bereitstellen lässt. Die empfohlene Lösung ist ein eigener Integrationsbenutzer mit reinem API-Zugriff, der von der MFA ausgenommen ist.
Wer ist bei der Integration mit externen Systemen von der Salesforce-MFA ausgenommen?
Benutzer, die sich über reine API-Konten, OAuth-Flows oder Sicherheitstoken authentifizieren, benötigen keine MFA. Ebenfalls ausgenommen sind Benutzer, die sich per SSO anmelden, wenn die MFA auf Ebene des Identity Providers erzwungen wird. So laufen Integrationen ohne Unterbrechung weiter.
Welche Best Practices helfen, MFA-bedingte Integrationsfehler zu vermeiden?
Verwenden Sie einen eigenen Integrationsbenutzer mit reinem API-Zugriff und nur den nötigen Berechtigungen, autorisieren Sie Ihre bestehenden Salesforce-Verbindungen über dieses Konto neu und halten Sie sich an die richtigen Einrichtungsschritte. Das gewährleistet Sicherheit und verhindert Unterbrechungen durch die MFA-Pflicht.
Aktualisiert im Januar 2026