Wie Sie eine Salesforce-Org sicher halten, waehrend Ihr Team waechst

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 loest man durch Designentscheidungen statt durch Security-Produkte.

Was verschlechtert Salesforce-Sicherheit wirklich, wenn ein Team waechst?

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 behaelt es drei Jahre. Multiplizieren Sie das mit jeder Einstellung, jedem Projekt und jedem Austritt, dessen Zugriff nie eingezogen wurde.
• Ueberprivilegierte 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 naturgemaess 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.
• Temporaerer Zugriff hat kein Ablaufdatum. Salesforce nimmt ihn nicht fuer Sie zurueck, und kein Ticket erinnert jemanden daran.
• Fuer Entzug ist niemand zustaendig. Vergaben haben einen Antragsteller. Entzuege haben niemanden, und deshalb werden Zugriffsreviews geplant und dann still uebersprungen.
• Sensible Rechte verstecken sich in der Summe. Zwei harmlose Permission Sets koennen sich zu einer Faehigkeit verbinden, die keines von beiden gewaehren wollte.

Welches Berechtigungsmodell ueberlebt 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 gehoert.
2. Permission Sets fuer Faehigkeiten, nicht fuer Personen. Ein Permission Set beschreibt eine Aufgabe, sein Name sollte also die Person ueberdauern, die es zuerst brauchte.
3. Permission Set Groups fuer Rollen, mit Muting, wo eine Gruppe etwas zu viel gewaehrt. 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 Gedaechtnis erhalten.
5. Fuehren Sie die gefaehrlichen Rechte auf einer benannten Liste. Modify All Data, View All Data, API Enabled, Export und Manage Users verdienen einen Eigentuemer und eine schriftliche Begruendung je Inhaber. Ist diese Liste laenger als Ihre Geschaeftsfuehrung, haben Sie Ihr erstes Projekt gefunden.

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

Warum sind Integrationsbenutzer der groesste blinde Fleck?

Weil sie in jedem Sicherheitsgespraech unsichtbar sind. Sie durchlaufen kein Onboarding, verlassen nie das Unternehmen, und niemand prueft 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 unmoeglich zu sagen, wer einen Datensatz geschrieben hat, und unmoeglich, ein System zu entziehen, ohne ein anderes zu brechen.
• Nutzen Sie die API-only-Integrationslizenz, wo es geht. Salesforce stellt fuenf 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 fuer diese Integration.
• Beschraenken Sie per IP und beobachten Sie das Volumen. Das Verhalten eines Integrationsbenutzers ist vorhersagbar, deshalb sind Abweichungen darin ungewoehnlich aussagekraeftig gegenueber menschlicher Aktivitaet.

Welche Kontrollen ueberleben Skalierung wirklich?

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

1. Deployen Sie Berechtigungen ueber die Pipeline, nicht von Hand in der Produktion. Liegen Zugriffsaenderungen in der Versionsverwaltung, hat jede Vergabe Autor, Review und Datum. Diese eine Kontrolle macht die naechsten vier moeglich.
2. Halten Sie ein wiederkehrendes Zugriffsreview mit benanntem Eigentuemer und fester Agenda: die Liste gefaehrlicher Rechte, Integrationsbenutzer und jede Person mit Rollenwechsel im letzten Quartal.
3. Vereinbaren Sie eine Ablaufkonvention fuer 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 Pruefung wie Apex, denn er kann schneller mehr Schaden anrichten.

Woran erkennen Sie, dass es wirkt?

Waehlen Sie Kennzahlen, die sinken sollen. Zaehlen Sie die Inhaber jedes gefaehrlichen Rechts. Zaehlen Sie Rechte, die ausserhalb einer Permission Set Group vergeben wurden. Zaehlen Sie Integrationsbenutzer mit UI-Zugriff. Zaehlen Sie Profile. Sinken diese vier Zahlen nicht Quartal fuer 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 ueber Permission Sets und Permission Set Groups ausdruecken.

Wie oft sollte Zugriff geprueft werden?

Quartalsweise fuer gefaehrliche Rechte und Integrationsbenutzer, und sofort bei jedem Rollenwechsel oder Austritt. Ein jaehrliches Review ist eine Audituebung, keine Kontrolle.

Brauchen Integrationsbenutzer MFA?

API-only-Integrationsbenutzer authentifizieren sich System zu System. Die sinnvollen Kontrollen sind IP-Beschraenkungen, 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 gehoert die Loesung 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.