Ein Kunde öffnet im Portal den Bearbeitungsstand seines Auftrags. Ändert er die Vorgangsnummer in der Adresse, darf dadurch kein fremder Auftrag erscheinen. Die Zuordnung zwischen Konto und Vorgang muss der Server bei jedem Zugriff prüfen.

Die Anmeldung klärt, wer zugreift. Die Berechtigungsprüfung klärt, welche Daten diese Person lesen oder ändern darf. Sie muss auch direkte Aufrufe abfangen, bei denen jemand die Navigation des Portals umgeht.

Beginne mit dem Vorgang, den Kunden heute erfragen

Wenn dein Team regelmäßig Auskunft über denselben Bearbeitungsstand gibt, ist das ein konkreter Einstieg. Welche Information wird am Telefon genannt? Woher stammt sie? Wann ist sie aktuell genug, um sie ohne zusätzliche Erklärung zu zeigen?

Fiktives Beispiel: Eine Werkstatt stellt den Status eines Reparaturvorgangs bereit: eingegangen, wird geprüft, zur Abholung bereit. Interne Notizen zur Fehlersuche bleiben intern. Der Kunde sieht seine freigegebene Zusammenfassung und einen zugehörigen Dokumentlink. Die Seite ersetzt weder Warenwirtschaft noch Buchhaltung.

Kläre vor der Entwicklung, wer den Status pflegt. Ein Portal mit veralteten Angaben verlagert die Rückfragen nur: Statt „Ist mein Auftrag fertig?“ lautet die Frage dann „Warum steht dort immer noch Prüfung?“. Ein Zeitstempel zur letzten Änderung hilft nur, wenn die Datenquelle verlässlich angebunden ist.

Schreibe Rechte als konkrete Handlungen auf

Eine Rollenbezeichnung wie „Kunde“ oder „Team“ reicht nicht aus. Notiere pro Handlung, welche Daten gemeint sind.

Handlung Kunde im fiktiven Beispiel Interne Bearbeitung
Status lesen Nur eigene Vorgänge Zugewiesene Vorgänge
Status ändern Nein Nach vereinbarten Regeln
Dokument öffnen Nur ausdrücklich freigegebene eigene Dokumente Im zugewiesenen Arbeitsbereich
Interne Notiz lesen Nein Im zugewiesenen Arbeitsbereich

Diese Tabelle ist eine fachliche Vorlage, keine fertige Sicherheitsarchitektur. Die OWASP-Empfehlungen zur Autorisierung verlangen unter anderem Berechtigungsprüfungen bei jeder Anfrage und eine grundsätzlich verweigernde Entscheidung, wenn keine Erlaubnis vorliegt. Das betrifft auch direkte Aufrufe eines Dokuments oder einer Schnittstelle.

Klärt außerdem den Lebenszyklus des Zugangs. Wie wird eine Person erstmals einem Kunden zugeordnet? Was passiert nach einem Ansprechpartnerwechsel? Eine frei eingegebene Kundennummer darf nicht allein darüber entscheiden, welche Vorgänge jemand erhält.

Den Zugriff mit zwei getrennten Konten prüfen

Lege zwei getrennte Testkonten mit unterschiedlichen Vorgängen an. Prüfe mit beiden den normalen Weg. Versuche anschließend, mit Konto A die Vorgangskennung von B direkt aufzurufen. Der Zugriff muss auch dann abgelehnt werden, wenn die Kennung bekannt ist. Prüfe ebenso Dokumentlinks und Exportfunktionen.

Prüfe auch ein Konto ohne Vorgänge, einen Auftrag ohne freigegebenes Dokument und eine abgelaufene Sitzung. Die Seite sollte jeweils den Grund nennen und, wo nötig, zur erneuten Anmeldung führen.

Für einen bestehenden Anwendungsbereich lässt sich Kundenkonten & Berechtigungen integrieren abgrenzen. Kundenportal entwickeln umfasst einen begrenzten vollständigen Ablauf. Wenn ausschließlich das eigene Team Vorgänge bearbeitet, passt eventuell ein internes Werkzeug.

Auch bei einer ersten Produktversion ist die Rechtefrage nicht auf später zu verschieben. Begrenze beim MVP lieber die Zahl der Funktionen und Datenarten. Welche Person welchen Datensatz sehen darf, muss bereits für diesen kleinen Umfang eindeutig sein.