Internes CRM absichern: Zugriffe für Mitarbeitende und Partner

Das Beispiel: ein CRM mit externen Partnern

Eine Agentur baut ein internes CRM für einen mittelständischen Betrieb. Mitarbeitende bearbeiten Kontakte und Angebote. Zwei Partnerfirmen erhalten zeitlich begrenzten Einblick in zugewiesene Vorgänge. Eine CRM-Verantwortliche beim Kunden genehmigt Einladungen und Rollenwechsel. Das ist ein fiktives Architekturbeispiel, keine Kundenreferenz und kein geprüfter Sicherheitsnachweis.

Die Oberfläche läuft auf crm.firma.example, eine eigene CRM-API verarbeitet fachliche Aktionen. Im Beispiel liegen Daten bei Supabase. Für ausgewählte Lesezugriffe nutzt das Frontend dessen Data API direkt. Genau dieser zweite Weg macht die Entscheidung interessant: Ein Login vor der CRM-Domain liegt nicht automatisch vor dem Supabase-Endpunkt.

Die grundsätzliche Abnahme von Anmeldung, Secrets, Backups und Betrieb behandelt unser Leitfaden für den sicheren Betrieb von Vibe-Coding-Anwendungen. Hier geht es um die konkrete Frage: Welche Person darf über welchen Weg welche Daten erreichen, und wie endet dieser Zugriff?

App-Login, TLS-Proxy, Tunnel und Access unterscheiden

Ein CRM braucht eine verlässliche Identität und fachliche Rechte. Ein TLS-Proxy übernimmt die HTTPS-Verbindung und leitet Anfragen weiter. Ein Tunnel verbindet einen erreichbaren Einstieg mit einem Ziel im Kundennetz. Eine zusätzliche Access-Schicht kann vor der Anwendung entscheiden, welche Identitäten den geschützten Einstieg benutzen dürfen. Diese Aufgaben gehören zusammen, beantworten aber unterschiedliche Fragen.

OWASP empfiehlt, Berechtigungen bei jeder Anfrage zu prüfen und nicht ausdrücklich erlaubte Zugriffe zu verweigern. Eine erlaubte Anmeldung ist damit kein Freibrief für jeden Datensatz. Ebenso schützt HTTPS den Transport, ersetzt aber keine Berechtigungsentscheidung; die OWASP-Empfehlungen für REST-Dienste behandeln beide Kontrollen getrennt.

Access muss nicht zu zwei sichtbaren Anmeldungen führen. Anwendung und vorgeschalteter Dienst können denselben Identitätsanbieter verwenden. Ob dabei tatsächlich eine gemeinsame Anmeldung entsteht, hängt von der Integration ab. Eine Anwendung darf eine weitergereichte Identität nur aus einem abgesicherten, überprüften Vertrauensverhältnis übernehmen. Ein vom Browser gesetzter Header wie X-User ist dafür kein Nachweis.

Drei Anfragewege zum selben CRM

Das Diagramm zeigt eine mögliche Architektur mit zusätzlichem Access. Es beschreibt keine heute verfügbare obhut-Konfiguration. Pfeile zeigen die Richtung der Anfragen; Antworten laufen zurück. Die drei Wege werden getrennt dargestellt, damit auch die Nebenwege sichtbar bleiben.

Auf schmalen Bildschirmen lässt sich das Diagramm seitlich verschieben. Alle drei Wege sind direkt darunter als Text beschrieben.

1. Weg A: geschützter CRM-Einstieg. Browser → Access-Prüfung mit zentraler Identität → TLS-Proxy beziehungsweise Tunnel → CRM-API. Access entscheidet über den Zutritt zum Einstieg. Die CRM-API prüft ihre Sitzung oder den vorgesehenen Identitätsnachweis sowie Aktion und Objekt. Im dargestellten Nutzerkontext begrenzen zusätzlich Tabellenrechte und RLS den Datenzugriff.
2. Weg B: direkter Supabase-Aufruf. Browser → Supabase Data API → Tabellenrechte und RLS. Die Access-Regel der CRM-Domain wird dabei nicht durchlaufen. Der Supabase-Endpunkt prüft die dort vorgesehenen Zugangsnachweise; die Datenregeln müssen den erlaubten Umfang selbst erzwingen.
3. Weg C: direkter Ursprung. Browser → öffentlich erreichbare Ursprungsadresse → CRM-API. Dieser Nebenweg umgeht Access und den vorgesehenen Proxy. Wenn Access für jeden CRM-Zugriff vorgeschrieben ist, muss der Betreiber diesen Weg schließen oder gleichwertig absichern. Die API-Prüfungen bleiben trotzdem erforderlich.

Ergänzen Sie in der tatsächlichen Zeichnung Datei-Downloads, Storage, Realtime, Webhooks, Verwaltungsadressen und Automatisierungen. Ein Tunnel schließt keine zweite, bereits öffentliche Adresse. Auch eine geänderte DNS-Adresse entfernt keinen weiterhin erreichbaren Ursprung.

Welche Architektur passt zum Projekt?

Beginnen Sie mit einer Anforderung, die sich testen lässt. „Nur Mitarbeitende und ausdrücklich eingeladene Partner dürfen das CRM nutzen“ ist der Anfang. Präziser wird es mit den erlaubten Datenbereichen und der Zeit, innerhalb derer eine Sperre wirken muss. Daraus folgen drei Entscheidungen:

1. Reicht die Anwendungsanmeldung als Einstiegskontrolle? Wenn alle Datenwege verlässliche Anmeldung, aktuelle Mitgliedschaften und fachliche Rechte prüfen, kann diese Architektur die Anforderung erfüllen. Ein zusätzliches Access-Produkt ist keine Voraussetzung für korrekte Anwendungsrechte.
2. Soll eine zentrale Regel vor dem CRM gelten? Das ist etwa sinnvoll, wenn der Kunde dieselben Unternehmensidentitäten für mehrere interne Anwendungen verwaltet. Dann gehören CRM-Frontend und eigene API in den vorgesehenen Schutzumfang. Partnerkonten erhalten eine ausdrücklich zugewiesene Berechtigung; eine passende E-Mail-Domain allein ersetzt diese Entscheidung nicht.
3. Dürfen Browser einen Datenservice direkt ansprechen? Wenn ja, ist dieser Dienst eine eigene Sicherheitsgrenze. Wenn nein, führt die Anwendung solche Aufrufe über ihr Backend und der bisherige direkte Datenzugang wird technisch eingeschränkt. Nur die URL aus dem Frontend zu entfernen schließt ihn nicht.

Für unser Beispiel nehmen wir an: Das CRM soll zentralen Access verwenden, ausgewählte direkte Supabase-Lesezugriffe bleiben aber erlaubt. Dann muss der Kunde wissen, dass ein Access-Entzug allein diese Datenzugriffe nicht beendet. Die dafür maßgebliche CRM-Mitgliedschaft muss auch auf dem direkten Datenpfad wirksam geprüft werden. Kann das Team diese zweite Grenze nicht zuverlässig betreiben, ist ein einziger kontrollierter Backend-Pfad eine zu prüfende Alternative.

Der direkte Supabase-Endpunkt bleibt eine eigene Grenze

Eine Supabase Data API kann von Anwendungen direkt angesprochen werden. Ein öffentlich vorgesehener Publishable-Key oder älterer anon-Key identifiziert dabei keine berechtigte CRM-Person. Für private Daten müssen Nutzeridentität, Tabellenrechte und RLS zusammenpassen. Supabase beschreibt diese Trennung in API keys und Securing your API.

Im Beispiel darf ein Partner nur Vorgänge lesen, für die eine aktuelle Freigabe besteht. Die Regel braucht deshalb mehr als „Nutzer ist angemeldet“: Sie muss Mitgliedschaft und Zuordnung zum konkreten Vorgang berücksichtigen. Prüfen Sie auch Listen, Suche und verknüpfte Daten. Wie daraus eine belastbare Gegenprobe wird, zeigt Supabase RLS testen.

Secret- und Service-Role-Schlüssel gehören nicht in den Browser. Sie können RLS umgehen. Nutzt ein Backend einen solchen privilegierten Zugang, muss es die fachlichen Rechte selbst zuverlässig durchsetzen. Das Diagramm zeigt bewusst den Zugriff im Nutzerkontext; es behauptet keine RLS-Wirkung für einen administrativen Datenpfad.

Wird die Data API im Projekt nicht gebraucht, kann sie laut Supabase deaktiviert werden. Wird sie gebraucht, sind die erreichbaren Tabellen und Operationen gezielt freizugeben. Supabase weist außerdem darauf hin, dass zusätzliche Prüfungen über db_pre_request nur für die Data API über PostgREST gelten. Storage und Realtime brauchen die jeweils passenden Kontrollen.

Mitarbeitende und Partner vom Eintritt bis zum Austritt

Der Kunde benennt für jeden Zugang eine fachlich verantwortliche Person. Die Agentur setzt den Ablauf technisch um; der spätere Betreiber führt ihn aus. Persönliche Konten machen nachvollziehbar, wer eingeladen wurde und wessen Rechte enden. Ein gemeinsam verwendetes Partnerkonto erschwert beides.

• Eintritt: Zweck, freigegebene Vorgänge und Rolle festhalten. Einladung an die richtige Person prüfen. MFA entsprechend dem Schutzbedarf einrichten; administrative Konten besonders absichern.
• Partnerzugang: Einen internen Ansprechpartner und ein Enddatum festlegen. Die technische Sperre bei Ablauf gehört zur Umsetzung. Ein Datum in einer Projektliste sperrt kein Konto.
• Rollenwechsel: Bisherige Rechte entfernen, neue Rechte gezielt vergeben und eine bestehende Sitzung gegen die neue Rolle prüfen. Historische Gruppen oder Projektzuordnungen dürfen keinen unbeabsichtigten Restzugang eröffnen.
• Austritt: Neue Anmeldungen verhindern, CRM-Mitgliedschaften und Partnerfreigaben entziehen, bestehende Sitzungen berücksichtigen und persönlich zugeordnete technische Tokens widerrufen. Ein gemeinsam genutztes Integrationskonto braucht einen eigenen Verantwortlichen und einen eigenen Entzugsprozess.

Für die Übergabe wird daraus eine kurze Zuständigkeitsliste: Wer genehmigt, wer setzt um, wer prüft das Ergebnis und wer übernimmt bei Abwesenheit? Der Beitrag Software an Kunden übergeben ordnet diese Aufgaben in die gesamte Betriebsübergabe ein.

Wann ist ein entzogener Zugang wirklich unwirksam?

Identitätskonto, Access-Sitzung und CRM-Sitzung können unterschiedliche Laufzeiten haben. Eine Sperre beim Identitätsanbieter beendet nicht automatisch bereits ausgestellte Anwendungstokens. Auch ein Rollenwert in einem noch gültigen Token kann gegenüber der aktuellen Mitgliedschaft veraltet sein.

Supabase dokumentiert, dass nach dem Abmelden bereits ausgestellte Access-Tokens bis zu ihrem Ablauf gültig bleiben. Für strengere Anforderungen beschreibt die Sitzungsdokumentation eine Prüfung, ob die zum Token gehörende Sitzung noch existiert. Das muss auf dem relevanten Anfrageweg tatsächlich umgesetzt werden; es entsteht nicht durch das Entfernen eines Buttons.

Vereinbaren Sie deshalb ein Entziehungsfenster für jeden Weg. Eine kurze Tokenlaufzeit begrenzt verbleibende Gültigkeit, liefert allein aber keinen sofortigen Entzug. Muss die nächste Datenanfrage bereits gesperrt sein, braucht der jeweilige Kontrollpunkt aktuelle Sperr- oder Mitgliedschaftsinformationen. Für einen direkten Supabase-Aufruf genügt eine solche Prüfung ausschließlich in der eigenen CRM-API nicht.

Die folgenden Fälle sind eine Abnahmevorlage mit geeigneten Testkonten auf eigenen oder ausdrücklich freigegebenen Systemen. Sie sind keine hier erzielten Ergebnisse.

Notieren Sie je Fall Version, Umgebung, Testrolle, Zugangsweg, Zeitpunkt des Entzugs, letzte erfolgreiche und erste verweigerte Anfrage. Speichern Sie keine aktiven Tokens im Abnahmeprotokoll. Eine einzelne verweigerte Anfrage ist noch kein Nachweis für alle Schnittstellen.

Was obhut heute dazu beitragen kann

obhut entwickelt eine Plattform für Agenturen, die Websites, Kundenportale, SaaS und interne Anwendungen bauen. Der aktuelle Stand ist ein interner Pilot; externer Zugang und Hosting-Beta sind noch nicht freigegeben. Statische Deployments mit Rollback sowie DNS, Zertifikate und Proxy- und Tunnelgrundlagen sind implementiert.

Identitätsbasierter Access für Kundenanwendungen, WAF und Rate-Limit-Regeln für Kundentraffic sowie Runtime-Hosting sind geplant. Das oben gezeichnete Access-Modell ist daher eine Architekturhilfe, keine verfügbare obhut-Funktion. Die Anmeldung an der obhut-Verwaltung schützt nicht automatisch ein Kunden-CRM.

Statisches Hosting liefert fertige Dateien aus. Es betreibt weder die hier gezeichnete CRM-API noch eine Kundendatenbank. Für eine extern betriebene Anwendung kann ein HTTP-/HTTPS- oder Tunnelpfad grundsätzlich in Betracht kommen; Eignung und Freigabe müssen am konkreten Projekt geklärt werden. Anwendungsrechte und der direkte Supabase-Zugang bleiben eigene Aufgaben.

Für ein Gespräch über Ihr Agenturprojekt helfen eine einfache Skizze der tatsächlichen Datenwege und fünf Angaben: Wo läuft das CRM, wer meldet sich an, welche Partner brauchen welche Daten, welche direkten APIs bestehen und wer übernimmt den Betrieb? Zugangsdaten oder Kundendatensätze sind dafür nicht erforderlich.