Identitäts- und Zugriffsverwaltung – Muster
Weitere Informationen zu Well-Architected Trust → Identitäts- und Zugriffsverwaltung
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Architektur | ✅ Zugriffssteuerungen überprüfen die Identität explizit bei jeder Anforderung, unabhängig vom Netzwerkstandort oder Gerät |
| Plattform | Architektur | ✅ Identitätsbasierte Sicherheitssteuerungen ersetzen netzwerkbasierte Trust Annahmen |
| Plattform | Organisation | ✅ Bei Zugriffsentscheidungen wird berücksichtigt, wer Zugriff anfordert (Authentifizierung), wozu er autorisiert ist (Autorisierung) und welcher Kontext (Gerät, Standort) vorliegt |
| Plattform | Dokumentation | ✅ Sicherheitsarchitektur dokumentiert Identität als primäre Trust Grenze, nicht als Netzwerkperimeter |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Architektur | ⚠️ Benutzern im Unternehmensnetzwerk oder VPN wird ein vertrauenswürdiger Zugriff gewährt, der allein auf der Netzwerkposition basiert. |
| Plattform | Architektur | ⚠️ Zugriffskontrollen basieren auf dem Netzwerkumfang und nicht auf der Identitätsüberprüfung |
| Plattform | Organisation | ⚠️ Zugriffsentscheidungen berücksichtigen keine Kontextsignale (Gerät, Standort, Uhrzeit, Verhaltensmuster) |
| Plattform | Dokumentation | ⚠️ Sicherheitsarchitektur behandelt Netzwerkstandort als primäre Trust Grenze |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Organisation | ✅ Lösungen nutzen alle vier Salesforce-Zugriffsebenen: Organisation (Lizenzen, Funktionen), Objekt (CRUD), Feld (FLS), Datensatz (Freigabe) |
| Plattform | Organisation | ✅ Das Zugriffsmodell wurde von oben nach unten entworfen (Organisation → Objekt → Feld → Datensatz) und von unten nach oben validiert |
| Plattform | Organisation | ✅ Organisationsweite Standardeinstellungen sind für Objekte mit sensiblen Daten auf “Privat” festgelegt |
| Plattform | Organisation | ✅ OWDs, die auf “Öffentlicher Lesezugriff” festgelegt sind, sind auf Referenzobjekte (Produkte, Preisbücher) beschränkt, bei denen eine breite Sichtbarkeit Geschäftstätigkeiten unterstützt, ohne Risiken auszusetzen |
| Plattform | Organisation | ✅ Einschränkungen auf Organisationsebene (Lizenzen, IP-Bereiche, Anmeldezeiten, Funktionsberechtigungen) definieren grundlegende Funktionen für Benutzerpopulationen |
| Plattform | Organisation | ✅ Objektberechtigungen (über Profile und Berechtigungssätze) steuern den Erstellungs-, Lese-, Bearbeitungs- und Löschzugriff auf jedes Objekt für Benutzersegmente |
| Plattform | Organisation | ✅ Feldebenensicherheit schützt sensible Felder auch dann, wenn Objektzugriff erteilt wird |
| Plattform | Organisation | ✅ Die Freigabe auf Datensatzebene verwendet Rollenhierarchie und Freigaberegeln basierend auf dokumentierten Geschäftsanforderungen |
| Plattform | Organisation | ✅ Der Zugriff wird bewusst gegenüber der restriktiven Grundlage erweitert und nicht nach zulässigen Standardeinstellungen eingeschränkt |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Organisation | ⚠️ Das Zugriffsmodell nutzt nicht alle vier Ebenen (Organisation, Objekt, Feld, Datensatz) |
| Plattform | Organisation | ⚠️ OWDs sind während der Entwicklung ohne Einschränkungspläne auf “Öffentlicher Lese-/Schreibzugriff” festgelegt. |
| Plattform | Organisation | ⚠️ Frühzeitig festgelegte zu permissive Einmalkennwörter lassen sich mit zunehmendem Datenvolumen und kristallisierenden Geschäftsprozessen exponentiell schwerer einschränken |
| Plattform | Organisation | ⚠️ Die Feldebenensicherheit ist nicht konfiguriert und basiert ausschließlich auf Zugriffssteuerungen auf Objekt- oder Datensatzebene. |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Organisation | ✅ Die Multi-Faktor-Authentifizierung (MFA) wird für alle Benutzer erzwungen, die auf Produktionsumgebungen zugreifen (obligatorisch für Benutzeroberflächenzugriff) |
| Plattform | Organisation | ✅ Die MFA wird auf privilegierte Vorgänge wie Massendatenexporte, Berechtigungsänderungen und administrative Konfiguration erweitert |
| Plattform | Organisation | ✅ Single Sign-On (SSO) verwendet SAML 2.0- oder OpenID Connect-Protokolle |
| Plattform | Organisation | ✅ Sitzungs-Timeout ist entsprechend konfiguriert: 2 Stunden für Standardbenutzer, 15-30 Minuten für Administratoren und Benutzer, die auf eingeschränkte Daten zugreifen |
| Plattform | Organisation | ✅ IP-Einschränkungen werden für Verwaltungsprofile und Integrationsbenutzer erzwungen |
| Plattform | Organisation | ✅ Anmeldezeiten beschränken Serviceaccounts auf erwartete Betriebszeitfenster |
| Plattform | Organisation | ✅ Die native Geräteaktivierung überprüft Anmeldungen von nicht erkannten Geräten. MFA- und IP-Einschränkungen sorgen für zusätzlichen Schutz bei Accounts mit hohen Rechten |
| Plattform | Organisation | ✅ Wenn SSO aktiviert ist, haben genehmigte Administratorbenutzer direkten Anmeldezugriff (Brillenglasverfahren) |
| Plattform | Organisation | ✅ Die Beziehung zwischen Benutzern und Einheiten, die sich bei Salesforce anmelden, beträgt 1:1 (keine freigegebenen Benutzeraccounts) |
| Plattform | Organisation | ✅ API-Zugriffssteuerung verhindert, dass sich Benutzer über nicht autorisierte verbundene Anwendungen authentifizieren |
| Plattform | Anmeldeinformationen mit Namen | ✅ Anmeldeinformationen mit Namen und externe Anmeldeinformationen verwalten die Authentifizierung zentral mit Rotationsfunktionen |
| Plattform | Anmeldeinformationen mit Namen | ✅ Anmeldeinformationen mit Namen abstrahieren Authentifizierungsdetails aus Code und ermöglichen so Aktualisierungen von Anmeldeinformationen ohne Codeänderungen |
| Plattform | Anmeldeinformationen mit Namen | ✅ Anmeldeinformationen werden niemals in Code, Konfigurationsdateien oder Versionskontrolle eingebettet |
| Plattform | Apex | ✅ Methoden, die die Authentifizierung ausführen, verwenden Anmeldeinformationen mit Namen zum Verarbeiten von Benutzernamens-/Kennwort-Flows |
| Plattform | Apex | ✅ Es werden keine Benutzernamen oder Kennwörter im Code in lesbaren Formaten angezeigt (keine hartcodierten Werte oder Zeichenfolgen) |
| Plattform | Aura | ✅ Methoden, die die Authentifizierung ausführen, verwenden Anmeldeinformationen mit Namen zum Verarbeiten von Benutzernamens-/Kennwort-Flows |
| Plattform | Aura | ✅ Es werden keine Benutzernamen oder Kennwörter im Code in lesbaren Formaten angezeigt |
| Plattform | Lightning Web Components (LWC) | ✅ Methoden, die die Authentifizierung ausführen, verwenden Anmeldeinformationen mit Namen |
| Plattform | Lightning Web Components (LWC) | ✅ Im Code werden keine Benutzernamen oder Kennwörter angezeigt |
| Integration | API | ✅ OAuth 2.0-JWT-Bearer-Flow wird für Server-zu-Server-Integrationen in vertrauenswürdigen Umgebungen verwendet (für Produktionsintegrationen bevorzugt) |
| Integration | API | ✅ OAuth 2.0-Webserver-Flow wird für Server-zu-Server-Integrationen verwendet, die einen Benutzerkontext erfordern |
| Integration | API | ✅ OAuth 2.0-Geräte-Flow wird für Headless-Geräte verwendet; CLI- und CI/CD-Tools verwenden Webserver-Flow (sf org login web) oder JWT-Bearer-Flow (sf org login jwt) – Geräte-Flow wurde für die standardmäßige verbundene Salesforce CLI-Anwendung ab 28. August 2025 blockiert |
| Integration | API | ✅ Der OAuth-Flow für Benutzername und Kennwort wird nicht verwendet. Bestehende Integrationen, die darauf angewiesen sind, werden zum Flow für JWT-Bearer- oder Client-Anmeldeinformationen migriert |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Organisation | ⚠️ Die MFA wird für den Zugriff auf die Produktionsumgebung nicht erzwungen |
| Plattform | Organisation | ⚠️ Anmeldekonfigurationen stimmen nicht mit den Salesforce-MFA-Anforderungen überein |
| Plattform | Organisation | ⚠️ Die Multi-Faktor-Authentifizierung wird nicht auf privilegierte Vorgänge (Massenexporte, Berechtigungsänderungen, administrative Konfiguration) erweitert. |
| Plattform | Organisation | ⚠️ Sitzungszeitüberschreitung ist nicht konfiguriert oder übermäßig zulässig (> 24 Stunden) |
| Plattform | Organisation | ⚠️ Sitzungsrichtlinien unterscheiden nicht zwischen Standardbenutzern und Administratoren/Benutzern, die auf eingeschränkte Daten zugreifen |
| Plattform | Organisation | IP-Einschränkungen werden für Verwaltungsprofile und Integrationsbenutzer nicht erzwungen. |
| Plattform | Organisation | ⚠️ Für Serviceaccounts sind die Anmeldezeiten nicht auf die erwarteten Betriebszeitfenster beschränkt |
| Plattform | Organisation | ⚠️ Accounts mit hohen Berechtigungen basieren auf nichts anderem als der Geräteaktivierung – es wurden keine MFA- oder IP-Einschränkungen hinzugefügt |
| Plattform | Organisation | ⚠️ Wenn SSO aktiviert ist, haben keine genehmigten Administratorbenutzer direkten Anmeldezugriff (keine Glasbruchverfahren) |
| Plattform | Organisation | ⚠️ Die Beziehung zwischen Benutzern und Einheiten ist nicht 1:1 (gemeinsame Benutzeraccounts sind vorhanden) |
| Plattform | Organisation | ⚠️ API-Zugriffssteuerung ist nicht aktiviert |
| Plattform | Anmeldeinformationen mit Namen | ⚠️ Anmeldeinformationen werden direkt in Code, Konfigurationsdateien oder die Versionskontrolle eingebettet |
| Plattform | Apex | ⚠️ Benutzernamen und Kennwörter werden im Code in lesbaren Formaten angezeigt |
| Plattform | Apex | ⚠️ Die Authentifizierung wird ad hoc ohne konsistente Implementierung verarbeitet |
| Plattform | Aura | ⚠️ Die Authentifizierung wird ad hoc ohne Anmeldeinformationen mit Namen verarbeitet |
| Plattform | Aura | ⚠️ Benutzernamen und Kennwörter werden im Code angezeigt |
| Plattform | Lightning Web Components (LWC) | ⚠️ Die Authentifizierung wird ad hoc ohne Anmeldeinformationen mit Namen verarbeitet |
| Plattform | Lightning Web Components (LWC) | ⚠️ Benutzernamen und Kennwörter werden im Code angezeigt |
| Plattform | Unternehmen | ⚠️ Benutzerbereitstellung und -aufhebung von SLAs und Anforderungen sind nicht vorhanden |
| Integration | API | ⚠️ OAuth-Flow mit Benutzername und Kennwort wird verwendet, wenn sicherere OAuth-Flows verfügbar sind |
| Integration | API | ⚠️ OAuth-Geltungsbereiche sind übermäßig zulässig (vollständiger Zugriff, wenn der begrenzte Umfang ausreicht) |
| Integration | API | ⚠️ Client-Anmeldeinformationen (Client-ID, Client-Geheimnis) werden unsicher in Code- oder Konfigurationsdateien gespeichert |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Organisation | ✅ Die Tiefe der Rollenhierarchie beträgt maximal 5 bis 7 Ebenen (Vermeidung des Leistungsaufwands und der Komplexität der Fehlerbehebung) |
| Plattform | Organisation | ✅ Berechtigungssätze und Berechtigungssatzgruppen bieten flexiblen, additiven Zugriff ohne Profilverbreitung |
| Plattform | Organisation | ✅ Berechtigungssätze gewähren Zugriff auf bestimmte Auftragsfunktionen, Anwendungen oder temporäre erhöhte Berechtigungen |
| Plattform | Organisation | ✅ Berechtigungssatzgruppen kombinieren zugehörige Berechtigungssätze mit Stummschaltungsfunktionen für Ausnahmen |
| Plattform | Organisation | ✅ Der gesamte Funktionszugriff wird über Berechtigungssätze und Berechtigungssatzgruppen (nicht über Profile) gewährt, was Flexibilität bei der Entwicklung von Auftragsrollen bietet |
| Plattform | Organisation | ✅ Transaktionssicherheitsrichtlinien erweitern die Autorisierung mit kontextbezogener Echtzeitauswertung |
| Plattform | Organisation | ✅ Transaktionssicherheitsrichtlinien erkennen und blockieren anormales Verhalten (Herunterladen von Massendaten, die Muster überschreiten, Anmeldung aus unerwarteten geografischen Regionen, Berechtigungsänderungen außerhalb von Änderungsfenstern) |
| Plattform | Organisation | ✅ IP-Einschränkungen sind für hochsensible Vorgänge oder Datenzugriff konfiguriert |
| Plattform | Organisation | ✅ Für jede Integration wird ein eindeutiger reiner API-Integrationsbenutzer konfiguriert |
| Plattform | Apex | ✅ Der gesamte Code, der auf Daten zugreift, erzwingt CRUD und FLS mithilfe der Methoden WITH USER_MODE, WITH SYSTEM_MODE oder Security.stripInaccessible(). |
| Plattform | Apex | ✅ SOQL-Abfragen verwenden die Stichwörter WITH USER_MODE oder WITH SYSTEM_MODE explizit basierend auf Geschäftsanforderungen |
| Plattform | Apex | ✅ DML-Vorgänge verwenden Security.stripInaccessible() für die Zugriffserzwingung vor Vorgängen zum Einfügen/Aktualisieren/Einfügen. |
| Plattform | Apex | ✅ Datenbank-DML-Anweisungen deklarieren den Benutzer- oder Systemmodus explizit für Datenvorgänge |
| Plattform | Apex | ✅ Datenbankvorgänge verwenden stripInaccessible()-Methoden zum Filtern von Abfrage- und Unterabfrageergebnissen |
| Plattform | Apex | ✅ Freigabestichwörter (mit Freigabe, ohne Freigabe, übernommene Freigabe) werden entsprechend den Geschäftssicherheitsanforderungen verwendet |
| Plattform | Designstandards | ✅ Anwendungsfälle für die Gewährung erhöhter Berechtigungen (Alle Daten modifizieren, Alle Daten anzeigen) werden klar und deutlich mit geschäftlichen Gründen dokumentiert |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Organisation | ⚠️ Die Rollenhierarchie ist tiefer als 5–7 Ebenen, was zu einem Leistungs-Overhead bei Freigabeberechnungen und einer komplexen Fehlerbehebung führt |
| Plattform | Organisation | ⚠️ Die Rollenhierarchie gewährt umfassenden Zugriff ohne geschäftliche Begründung |
| Plattform | Organisation | ⚠️ Profile werden wiederholt für kleinere Berechtigungsvariationen dupliziert, wodurch Dutzende Profile mit unklaren Unterschieden erstellt werden |
| Plattform | Organisation | ⚠️ Profile enthalten Zugriffssteuerungen für Metadaten (sollten Berechtigungssätze verwenden) |
| Plattform | Organisation | ⚠️ Transaktionssicherheitsrichtlinien werden nicht implementiert, um anormales Verhalten zu erkennen |
| Plattform | Organisation | ⚠️ IP-Einschränkungen sind nicht für hochsensible Vorgänge oder Datenzugriff konfiguriert |
| Plattform | Organisation | ⚠️ Nur API-Benutzer sind nicht konfiguriert oder werden über mehrere Integrationen hinweg freigegeben |
| Plattform | Organisation | ⚠️ Die Berechtigungen “Alle Daten anzeigen” oder “Alle Daten modifizieren” werden ohne dokumentierte Begründung erteilt. |
| Plattform | Apex | ⚠️ SOQL/SOSL-Abfragen und DML-Vorgänge werden im standardmäßigen Systemmodus ohne explizite Zugriffsprüfungen ausgeführt |
| Plattform | Apex | ⚠️ Die Erzwingung von CRUD und FLS ist inkonsistent oder fehlt |
| Plattform | Apex | ⚠️ SOQL basiert auf WITH SECURITY_ENFORCED, das entfernt wurde und nun einen Kompilierungsfehler verursacht (durch WITH USER_MODE ersetzen). |
| Plattform | Apex | ⚠️ Freigabestichwörter werden inkonsistent oder gar nicht verwendet |
| Plattform | Designstandards | ⚠️ Anwendungsfälle für die Gewährung erhöhter Berechtigungen sind nicht eindeutig dokumentiert |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Data 360 | ✅ RBAC (Rollen, Profile, Berechtigungssätze) steuert den Plattformzugriff (wer Data 360 verwenden kann), ABAC steuert den Datenzugriff (welche Daten ihnen basierend auf Attributen angezeigt werden) |
| Plattform | Data 360 | ✅ AI-Agenten werden im Kontext des anfordernden Benutzers (im Namen von) ausgeführt, sodass von Agenten generierte Abfragen durch den Zugriff dieses Benutzers eingeschränkt werden und nicht mit Zugriff auf Systemebene ausgeführt werden |
| Plattform | Dokumentation | ✅ Die Datenklassifizierungstaxonomie wird mit Attributdefinitionen, Durchsetzungsregeln und Geschäftsberechtigung dokumentiert |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Data 360 | ⚠️ Der Zugriff, der der Datenklassifizierung folgen muss, wird durch Rollenhierarchie und Freigabe erzwungen, die ihn nicht ausdrücken können, statt die attributbasierte Zugriffssteuerung zu verwenden |
| Plattform | Data 360 | ⚠️ FLS-Bypass: Benutzer ohne Feldebenenzugriff rufen Daten über API- oder SOQL-Abfragen ab, die FLS nicht erzwingen |
| Plattform | Data 360 | ⚠️ AI-Agenten fragen Daten ab, ohne sie im Kontext des anfordernden Benutzers auszuführen. Von Agenten generierte Abfragen umgehen Zugriffssteuerungen auf Objekt-, Feld- und Datensatzebene |
| Plattform | Data 360 | ⚠️ Der Kontext für die Agentenausführung enthält keine Attribute vom Typ “Benutzer im Namen von”; Agenten arbeiten mit Zugriff auf Systemebene |
| Plattform | Dokumentation | ⚠️ Die Datenklassifizierungs-Taxonomie ist undokumentiert. Die Attributdefinitionen variieren je nach Team, was zu einer inkonsistenten Erzwingung führt. |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Organisation | ✅ Accounts mit kritischen Auswirkungen (Systemadministratoren, Integrationsbenutzer, Accounts für automatisierte Prozesse) werden im Vermögenswertinventar identifiziert und verfolgt |
| Plattform | Organisation | ✅ Accounts mit kritischen Auswirkungen stellen aufgrund erhöhter Berechtigungen, die einen umfassenden Plattformzugriff bieten, Ziele mit hohem Wert dar |
| Plattform | Organisation | ✅ Hardware-Sicherheitsschlüssel oder Authentifizierungsanwendungen sind für die Multi-Faktor-Authentifizierung erforderlich (keine SMS, die für SIM-Austausch anfällig ist) |
| Plattform | Organisation | ✅ IP-Bereiche für Anmeldungen sind auf bekannte Verwaltungsstandorte beschränkt |
| Plattform | Organisation | ✅ Anmeldebenachrichtigungen und Benachrichtigungen zu Berechtigungsänderungen sind aktiviert |
| Plattform | Organisation | ✅ Vierteljährliche Zugriffsüberprüfungen werden mit dokumentierter Bescheinigung durchgeführt |
| Plattform | Organisation | ✅ Für Notfallzugriff mit Überprüfung nach der Verwendung gibt es Brillenglasverfahren |
| Integration | Service-Accounts | ✅ OAuth-Flows werden für Integrations- und Service-Accounts verwendet (niemals Benutzername und Kennwort) |
| Integration | Service-Accounts | ✅ IP-Einschränkungen werden für Integrationsbenutzer erzwungen |
| Integration | Service-Accounts | ✅ Rotationspläne für Anmeldeinformationen werden implementiert (vierteljährlich oder pro Richtlinie) |
| Integration | Service-Accounts | ✅ Anomale API-Nutzungsmuster werden über die Ereignisüberwachung überwacht |
| Integration | Service-Accounts | ✅ Jede Integration verfügt über einen dedizierten Service-Account mit den erforderlichen Mindestberechtigungen (nicht freigegebener “Integrationsbenutzer” mit breitem Zugriff) |
| Integration | Service-Accounts | ✅ Service-Accounts wenden die geringsten Berechtigungen streng an, da sie unbeaufsichtigt arbeiten |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Organisation | ⚠️ Accounts mit wichtigen Auswirkungen (Administrator, Integration, Automatisierung) werden nicht identifiziert, verfolgt oder inventarisiert |
| Plattform | Organisation | ⚠️ Systemadministratoren verwenden SMS-basierte MFA anstelle von Hardware-Sicherheitsschlüsseln oder Authentifizierungsanwendungen |
| Plattform | Organisation | ⚠️ Accounts mit kritischen Auswirkungen weisen keine Anmeldezeit oder IP-Einschränkungen auf |
| Plattform | Organisation | ⚠️ Es werden keine Benachrichtigungen für Anmelde- oder Berechtigungsänderungen für berechtigte Accounts konfiguriert |
| Plattform | Organisation | ⚠️ Der Zugriff auf Accounts mit kritischen Auswirkungen wird niemals unregelmäßig (nicht vierteljährlich) überprüft |
| Plattform | Organisation | ⚠️ Für den Notzugriff sind keine Glasbruchverfahren vorhanden |
| Integration | Service-Accounts | ⚠️ Ein einzelner “API-Benutzer”-Account wird über mehrere Integrationen hinweg mit der Berechtigung “Alle Daten modifizieren” freigegeben |
| Integration | Service-Accounts | ⚠️ Service-Accounts verwenden die Authentifizierung mit Benutzername und Kennwort, wenn OAuth verfügbar ist |
| Integration | Service-Accounts | ⚠️ Service-Account-Anmeldeinformationen verwenden statische Kennwörter, die seit Jahren unverändert sind (keine Rotation) |
| Integration | Service-Accounts | ⚠️ Service-Accounts verfügen über übermäßige Berechtigungen, die über das für die Integration erforderliche Maß hinausgehen |
| Integration | Service-Accounts | ⚠️ Anomale API-Nutzungsmuster für Service-Accounts werden nicht überwacht |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Prozess | ✅ Der Identitätslebenszyklus umfasst: Bereitstellung (mit Basiszugriff erstellen), Zugriffsanpassung (Erteilen/Widerrufen bei Rollenänderung), regelmäßige Neuzertifizierung (vierteljährliche Validierung), Aufhebung der Bereitstellung (sofortiger Widerruf) |
| Plattform | Organisation | ✅ SCIM (System for Cross-Domain Identity Management) ist für die automatisierte Bereitstellung von Identitätsanbietern implementiert |
| Plattform | Prozess | ✅ Die Bereitstellung erstellt Accounts mit der Funktion “Basline Access Matching Job” (Übereinstimmung des Basiszugriffs für Aufträge), ausgelöst durch HR-Systemereignisse |
| Plattform | Prozess | ✅ Die Zugriffsanpassung gewährt zusätzliche Berechtigungen, wenn Rollen erweitert werden, und widerruft Berechtigungen, wenn Rollen geändert werden |
| Plattform | Prozess | ✅ Regelmäßige Neuzertifizierung erfolgt vierteljährlich, wobei Manager den Zugriff für ihre Teams überprüfen und validieren |
| Plattform | Prozess | ✅ Durch die Deprovisionierung wird der Zugriff sofort widerrufen, wenn die Beschäftigung endet oder die Rolle Salesforce nicht mehr erfordert |
| Plattform | Organisation | ✅ Die automatische Erkennung identifiziert Benutzer, die sich innerhalb von 90 Tagen nicht angemeldet haben, und löst Workflows für die Zugriffsüberprüfung aus |
| Plattform | Organisation | ✅ Just-in-Time (JIT)-Bereitstellung erstellt Benutzer automatisch über SSO, wenn dies angemessen ist |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Organisation | ⚠️ Die SCIM-Bereitstellung wird trotz Identitätsanbieterintegration nicht implementiert |
| Plattform | Prozess | ⚠️ Neue Benutzer werden manuell ohne Standardverfahren für die Einarbeitung erstellt |
| Plattform | Prozess | ⚠️ Der anfängliche Benutzerzugriff ist inkonsistent oder basiert auf dem Kopieren vorhandener Benutzer |
| Plattform | Prozess | ⚠️ Zugriffsänderungen für Rollenänderungen oder -übertragungen sind verzögert oder unvollständig |
| Plattform | Prozess | ⚠️ Die Einarbeitung verzögert sich; ehemalige Mitarbeiter behalten den Zugriff nach Beendigung bei (nicht Deaktivierung am selben Tag) |
| Plattform | Organisation | ⚠️ Für die Benutzerbereitstellung ist keine Automatisierung vorhanden (nur manuelle Benutzererstellung) |
| Plattform | Prozess | ⚠️ Es gibt keine Kampagnen zur Rezertifizierung des Zugriffs (keine vierteljährliche oder jährliche Überprüfung) |
| Plattform | Prozess | ⚠️ Nicht benötigter Zugriff, der bei der Neuzertifizierung identifiziert wurde, wird nicht entfernt |
| Plattform | Prozess | ⚠️ Die Neuzertifizierung des Zugriffs ist für berechtigte Accounts, organisationsübergreifenden Zugriff und externe Benutzer nicht streng |
| Plattform | Organisation | ⚠️ Ruhende Accounts (keine Anmeldung in über 90 Tagen) werden ohne Überprüfung oder Deaktivierung kumuliert |