Geteilte Subdomains, zwei Eingänge: Wer sieht welche Datensätze?

Klinik A und Klinik B teilen eine Codebasis, zwei Subdomains und eine Mischung aus Besuchern aus dem Büro und über VPN. Netzwerkteams neigen dazu, die beiden Eingänge getrennt zu konfigurieren, und das ist in Ordnung, solange die Anwendung es nicht tut. Die folgenden Prüfungen gehören in die Anwendung und sollten sich identisch verhalten, egal durch welche Tür die Anfrage kam.

Erstens: der Hostname benennt nur einen Mandanten

Lösen Sie den angefragten Hostnamen gegen eine Zuordnung auf, die der Administrator pflegt, und lehnen Sie alles Unbekannte ab. Verwenden Sie den validierten Hostwert des Frameworks statt des rohen Headers, damit ein manipulierter Host keinen Suchschlüssel einschleusen kann. Eine erfolgreiche Übereinstimmung sagt dem Code, welche Mandantenkonfiguration und welches Branding zu laden sind. Sie sagt nichts darüber aus, ob der Aufrufer die Daten dieses Mandanten sehen darf. Halten Sie diese zweite Frage in einer eigenen Funktion mit einer eigenen Eingabe.

Eine gemeinsame Hilfsfunktion, die aus einem einzigen Hostnamen-Lookup sowohl Kontext als auch Berechtigung zurückgibt, ist der Anfang des Fehlers.

Zweitens: die Mitgliedschaft kommt aus der Sitzung

Schlagen Sie die aktiven Mitgliedschaften des authentifizierten Benutzers nach und vergleichen Sie sie mit dem Mandanten aus der ersten Prüfung. Ein Benutzer, der beiden Kliniken angehört, darf wechseln, aber der Wechsel sollte eine ausdrückliche, im Anfragekontext festgehaltene Handlung sein und keine Folgerung aus der URL. Ein Benutzer, der einer Klinik angehört und die andere anfragt, wird abgewiesen, auch bei Downloads und API-Aufrufen.

Testen Sie den Negativfall, indem Sie eine Datensatz-ID und einen Mandantenparameter ändern. Wenn eine der beiden Änderungen Daten zurückgibt, wird der Geltungsbereich aus der Anfrage gelesen und nicht aus der verifizierten Mitgliedschaft.

Cookie-Geltungsbereich und Single Sign-on entscheiden, wo ein Konto präsentiert werden kann. Sie entscheiden nicht, was dieses Konto lesen darf.

Drittens: das Netzwerk beweist nichts über die Person

Ein VPN-Gateway authentifiziert einen Tunnel, und eine öffentliche Allowlist authentifiziert einen Adressbereich. Keines von beiden identifiziert eine Person. NAT fasst viele Benutzer zu einer Quelladresse zusammen, und ein Bürobereich tut dasselbe für alle im Gebäude. Behandeln Sie beides als Transporttatsachen, und halten Sie die Autorisierung in der Anwendung oder in einer Integration, die Identität ausdrücklich behauptet und als solche geprüft wird.

DNS ist eine dritte Transporttatsache. Eine private Antwort braucht eine private Route, und ein öffentliches Frontend braucht einen unterstützten Origin-Pfad. Keine von ihnen trägt eine Berechtigung.

Ein Satz für die Wand: das Netzwerk entscheidet, wie eine Anfrage ankommt, und die Anwendung entscheidet, was sie lesen darf.

Viertens: die Matrix an beiden Eingängen durchlaufen

Verwenden Sie kontrollierte Konten, um A bei A, B bei B, A bei B, einen unbekannten Hostnamen und ein authentifiziertes Konto ohne Mitgliedschaften zu prüfen. Das vierte und das fünfte sollten geschlossen fehlschlagen und niemals auf einen Mandanten zurückfallen. Führen Sie dieselbe Matrix auch über den VPN-Eingang aus, mit einem eigenen Cookie-Speicher pro Konto:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Ändern Sie dann einen Allowlist-Eintrag und führen Sie die Prüfung erneut aus. Ein Ergebnis, das sich verschiebt, bedeutet, dass eine Netzwerkkontrolle eine Autorisierungsentscheidung trifft.

Wiederholen Sie die Matrix nach jeder Frontend-Änderung, denn ein zweiter Codepfad, der die Prüfung überspringt, ist der häufigste Weg, auf dem diese Grenze erodiert. Das erwartete Ergebnis ist langweilig: jeder Eingang liefert die gleichen Antworten.