Współdzielone subdomeny, dwa wejścia: kto widzi które rekordy?

Klinika A i Klinika B dzielą jedną bazę kodu, dwie subdomeny oraz mieszankę odwiedzających z biura i przez VPN. Zespoły sieciowe zwykle konfigurują oba wejścia osobno i to jest w porządku, dopóki aplikacja tego nie robi. Poniższe kontrole należą do aplikacji i powinny zachowywać się identycznie niezależnie od tego, którymi drzwiami przyszło żądanie.

Po pierwsze: nazwa hosta tylko nazywa najemcę

Rozwiąż żądaną nazwę hosta względem mapowania utrzymywanego przez administratora i odrzuć wszystko nieznane. Użyj zweryfikowanej wartości hosta z frameworka zamiast surowego nagłówka, aby spreparowany Host nie mógł wstrzyknąć klucza wyszukiwania. Pomyślne dopasowanie mówi kodowi, którą konfigurację najemcy i który branding załadować. Nie mówi nic o tym, czy wywołujący może zobaczyć dane tego najemcy. Trzymaj to drugie pytanie w osobnej funkcji z osobnym wejściem.

Wspólna funkcja pomocnicza, która zwraca jednocześnie kontekst i uprawnienie z jednego wyszukania nazwy hosta, jest początkiem błędu.

Po drugie: członkostwo pochodzi z sesji

Wyszukaj aktywne członkostwa uwierzytelnionego użytkownika i porównaj je z najemcą z pierwszej kontroli. Użytkownik należący do obu klinik może się przełączać, ale przełączenie powinno być jawną akcją zapisaną w kontekście żądania, a nie wnioskiem z adresu URL. Użytkownikowi należącemu do jednej kliniki i żądającemu drugiej odmawia się dostępu, także do pobierania i wywołań API.

Przetestuj przypadek negatywny, edytując identyfikator rekordu i parametr najemcy. Jeśli którakolwiek zmiana zwróci dane, zakres jest czytany z żądania, a nie ze zweryfikowanego członkostwa.

Zakres plików cookie i logowanie jednokrotne decydują, gdzie można zaprezentować konto. Nie decydują, co to konto może czytać.

Po trzecie: sieć niczego nie dowodzi o osobie

Brama VPN uwierzytelnia tunel, a publiczna lista dozwolonych uwierzytelnia zakres adresów. Żadna z nich nie identyfikuje osoby. NAT zbiera wielu użytkowników w jeden adres źródłowy, a zakres biurowy robi to samo dla wszystkich w budynku. Traktuj oba jako fakty transportowe i trzymaj autoryzację w aplikacji albo w integracji, która jawnie stwierdza tożsamość i jest jako taka przeglądana.

DNS jest trzecim faktem transportowym. Prywatna odpowiedź wymaga prywatnej trasy, a publiczny frontend wymaga obsługiwanej ścieżki źródłowej. Żaden z nich nie niesie uprawnienia.

Jedno zdanie na ścianę: sieć decyduje, jak żądanie dociera, a aplikacja decyduje, co może ono czytać.

Po czwarte: uruchom macierz na obu wejściach

Użyj kontrolowanych kont, aby sprawdzić A przy A, B przy B, A przy B, nieznaną nazwę hosta i uwierzytelnione konto bez członkostw. Czwarte i piąte powinny zawieść zamknięte i nigdy nie spaść do domyślnego najemcy. Uruchom tę samą macierz także przez wejście VPN, z jednym słoikiem sesji na 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

Następnie zmień wpis na liście dozwolonych i uruchom ponownie. Wynik, który się przesuwa, oznacza, że kontrola sieciowa podejmuje decyzję autoryzacyjną.

Powtarzaj macierz po każdej zmianie frontendu, ponieważ druga ścieżka kodu, która pomija kontrolę, jest najczęstszym sposobem erozji tej granicy. Oczekiwany wynik jest nudny: każde wejście daje te same odpowiedzi.