Wie Sie eine Salesforce-Org sicher halten, während Ihr Team wächst

Kurze Antwort: Salesforce-Orgs werden fast nie unsicher, weil jemand sie angegriffen hat. Sie werden unsicher, weil Berechtigungen schneller wachsen, als jemand sie entfernt, und weil Integrationsbenutzer weit mehr Zugriff bekommen, als die Integration braucht. Beide Probleme sind leise, beide wachsen mit der Belegschaft, und beide löst man durch Designentscheidungen statt durch Security-Produkte.

Was verschlechtert Salesforce-Sicherheit wirklich, wenn ein Team wächst?

Zwei Mechanismen, und keiner sieht am Tag des Geschehens wie ein Einbruch aus.

• Berechtigungswildwuchs. Zugriff wird als Kette von Ausnahmen vergeben. Jemand braucht am Freitag einen Bericht, bekommt ein Permission Set und behält es drei Jahre. Multiplizieren Sie das mit jeder Einstellung, jedem Projekt und jedem Austritt, dessen Zugriff nie eingezogen wurde.
• Überprivilegierte Integrationsbenutzer. Die Middleware muss auf zwei Objekte schreiben und bekommt ein System-Administrator-Profil, weil das der schnellste Weg ist, die Synchronisation zum Laufen zu bringen.

Beides ist naturgemäß additiv. Nichts in der Plattform entzieht Zugriff von selbst. Diese Asymmetrie, leicht zu vergeben und niemandes Aufgabe zu widerrufen, ist die ganze Geschichte, wie aus einer gut entworfenen Org in zwei Jahren ein Auditproblem wird.

Warum entsteht Wildwuchs sogar in disziplinierten Teams?

Weil der schnelle und der richtige Weg in verschiedene Richtungen zeigen:

• Klonen ist einfacher als Modellieren. Ein Profil zu klonen dauert eine Minute, eine ordentliche Permission Set Group zu bauen einen Nachmittag. So enden Orgs mit Dutzenden fast identischer Profile, die niemand zusammenzulegen wagt.
• Temporärer Zugriff hat kein Ablaufdatum. Salesforce nimmt ihn nicht für Sie zurück, und kein Ticket erinnert jemanden daran.
• Für Entzug ist niemand zuständig. Vergaben haben einen Antragsteller. Entzüge haben niemanden, und deshalb werden Zugriffsreviews geplant und dann still übersprungen.
• Sensible Rechte verstecken sich in der Summe. Zwei harmlose Permission Sets können sich zu einer Fähigkeit verbinden, die keines von beiden gewähren wollte.

Welches Berechtigungsmodell überlebt Wachstum?

Das skalierende Modell ist langweilig und gut dokumentiert. Entscheidend ist, sich darauf festzulegen, bevor Sie 200 Nutzer haben, nicht danach.

1. Minimales Basisprofil. Geben Sie dem Profil nur, was jeder Nutzer dieses Lizenztyps braucht. Kein Objektzugriff, der zu einer Funktion gehört.
2. Permission Sets für Fähigkeiten, nicht für Personen. Ein Permission Set beschreibt eine Aufgabe, sein Name sollte also die Person überdauern, die es zuerst brauchte.
3. Permission Set Groups für Rollen, mit Muting, wo eine Gruppe etwas zu viel gewährt. Das ist der Mechanismus, mit dem Sie eine Rolle zusammensetzen, ohne wieder ein Profil zu klonen.
4. Automatisieren Sie die Zuweisung mit User Access Policies, damit Eintritte und Wechsel Zugriff nach Kriterien statt aus dem Gedächtnis erhalten.
5. Führen Sie die gefährlichen Rechte auf einer benannten Liste. Modify All Data, View All Data, API Enabled, Export und Manage Users verdienen einen Eigentümer und eine schriftliche Begründung je Inhaber. Ist diese Liste länger als Ihre Geschäftsführung, haben Sie Ihr erstes Projekt gefunden.

Der Least-Privilege-Leitfaden von Salesforce Ben ist eine gute Ergänzung, wenn Sie die Klickdetails wollen. Die Designentscheidung oben muss von Ihnen kommen.

Warum sind Integrationsbenutzer der größte blinde Fleck?

Weil sie in jedem Sicherheitsgespräch unsichtbar sind. Sie durchlaufen kein Onboarding, verlassen nie das Unternehmen, und niemand prüft sie am Projektende. Zugleich halten sie meist breiteren Datenzugriff als jeder Mensch in der Org und authentifizieren sich ohne MFA-Abfrage.

Vier Regeln, die mit steigender Zahl von Integrationen halten:

• Ein Integrationsbenutzer pro Integration. Geteilte Integrationsbenutzer machen es unmöglich zu sagen, wer einen Datensatz geschrieben hat, und unmöglich, ein System zu entziehen, ohne ein anderes zu brechen.
• Nutzen Sie die API-only-Integrationslizenz, wo es geht. Salesforce stellt fünf kostenlose Salesforce-Integration-Lizenzen in Enterprise-, Unlimited- und Performance-Editionen bereit, ganz ohne UI-Zugriff, was eine ganze Klasse von Missbrauch entfernt.
• Grenzen Sie auf Objekte und Felder ein, nicht auf Profile. Schreiben Sie auf, was die Integration anfassen darf, und erzwingen Sie es mit einem Permission Set nur für diese Integration.
• Beschränken Sie per IP und beobachten Sie das Volumen. Das Verhalten eines Integrationsbenutzers ist vorhersagbar, deshalb sind Abweichungen darin ungewöhnlich aussagekräftig gegenüber menschlicher Aktivität.

Welche Kontrollen überleben Skalierung wirklich?

Diese funktionieren weiter, wenn sich das Team verdoppelt, geordnet nach Ertrag pro Aufwand:

1. Deployen Sie Berechtigungen über die Pipeline, nicht von Hand in der Produktion. Liegen Zugriffsänderungen in der Versionsverwaltung, hat jede Vergabe Autor, Review und Datum. Diese eine Kontrolle macht die nächsten vier möglich.
2. Halten Sie ein wiederkehrendes Zugriffsreview mit benanntem Eigentümer und fester Agenda: die Liste gefährlicher Rechte, Integrationsbenutzer und jede Person mit Rollenwechsel im letzten Quartal.
3. Vereinbaren Sie eine Ablaufkonvention für Ausnahmezugriffe, notfalls per Kalendererinnerung. Zugriff ohne Enddatum ist dauerhafter Zugriff.
4. Verfolgen Sie Health Check und Setup Audit Trail als Trend, nicht als Screenshot vor einem Audit.
5. Nehmen Sie Berechtigungen ins Code-Review. Ein Profil- oder Permission-Set-Diff verdient dieselbe Prüfung wie Apex, denn er kann schneller mehr Schaden anrichten.

Woran erkennen Sie, dass es wirkt?

Wählen Sie Kennzahlen, die sinken sollen. Zählen Sie die Inhaber jedes gefährlichen Rechts. Zählen Sie Rechte, die außerhalb einer Permission Set Group vergeben wurden. Zählen Sie Integrationsbenutzer mit UI-Zugriff. Zählen Sie Profile. Sinken diese vier Zahlen nicht Quartal für Quartal, driftet Ihre Sicherheitslage, auch wenn noch nichts schiefgegangen ist.

FAQ

Sind Profile in Salesforce abgeschafft?

Nein, und Sie brauchen weiterhin eines pro Nutzer. Die praktische Linie lautet: Profile minimal halten und alles Rollenspezifische über Permission Sets und Permission Set Groups ausdrücken.

Wie oft sollte Zugriff geprüft werden?

Quartalsweise für gefährliche Rechte und Integrationsbenutzer, und sofort bei jedem Rollenwechsel oder Austritt. Ein jährliches Review ist eine Auditübung, keine Kontrolle.

Brauchen Integrationsbenutzer MFA?

API-only-Integrationsbenutzer authentifizieren sich System zu System. Die sinnvollen Kontrollen sind IP-Beschränkungen, eng gefasste Rechte und Monitoring, nicht eine MFA-Abfrage, die kein Mensch je sieht.

Ist das ein Problem von Security-Tooling?

Werkzeuge helfen Ihnen, den Wildwuchs zu sehen. Sie entscheiden nicht, wer Zugriff haben soll. Die Entscheidungen sind architektonisch, und deshalb gehört die Lösung in Ihren Lieferprozess und nicht in einen Einkauf.

Wir bauen auf Salesforce als zertifizierter SI, ISV und PDO und haben Pakete durch die AppExchange Security Review in Gesundheitswesen, Logistik und Fertigung gebracht. Das Berechtigungsmodell entwerfen wir also, statt es zu erben. Ist Ihre Org schneller gewachsen als ihr Zugriffsmodell? Sprechen Sie uns an.