Спільні піддомени, два входи: хто які записи бачить?

Клініка A і Клініка B ділять одну кодову базу, два піддомени та суміш відвідувачів з офісу й через VPN. Мережеві команди зазвичай налаштовують два входи окремо, і це нормально, доки застосунок так не робить. Перевірки нижче мають бути в застосунку і поводитися однаково незалежно від того, крізь які двері прийшов запит.

Перше: ім'я хоста лише називає орендаря

Зіставте запитане ім'я хоста з відображенням, яке веде адміністратор, і відхиляйте все невідоме. Використовуйте перевірене значення хоста з фреймворку замість сирого заголовка, щоб підроблений Host не міг вставити ключ пошуку. Успішний збіг повідомляє коду, яку конфігурацію орендаря та який брендинг завантажувати. Він нічого не каже про те, чи може викликач бачити дані цього орендаря. Тримайте це друге питання в окремій функції з окремим входом.

Спільна допоміжна функція, що повертає і контекст, і дозвіл з одного пошуку імені хоста, є початком помилки.

Друге: членство надходить із сесії

Знайдіть активні членства автентифікованого користувача і порівняйте їх з орендарем з першої перевірки. Користувач, який належить до обох клінік, може перемикатися, але перемикання має бути явною дією, зафіксованою в контексті запиту, а не висновком з URL. Користувачеві, який належить до однієї клініки й запитує іншу, відмовляють, зокрема й для завантажень та викликів API.

Перевірте негативний випадок, змінивши ідентифікатор запису та параметр орендаря. Якщо будь-яка зі змін повертає дані, область читається із запиту, а не з підтвердженого членства.

Область дії cookie та єдиний вхід визначають, де можна представити обліковий запис. Вони не визначають, що цей обліковий запис може читати.

Третє: мережа нічого не доводить про людину

VPN-шлюз автентифікує тунель, а публічний список дозволів автентифікує діапазон адрес. Жодне з них не ідентифікує людину. NAT зводить багатьох користувачів в одну адресу джерела, а офісний діапазон робить те саме для всіх у будівлі. Розглядайте обидва як факти транспорту і тримайте авторизацію в застосунку або в інтеграції, яка явно стверджує ідентичність і розглядається як така.

DNS — третій факт транспорту. Приватна відповідь потребує приватного маршруту, а публічний фронтенд потребує підтримуваного шляху до джерела. Жоден із них не несе дозволу.

Одне речення на стіну: мережа вирішує, як надходить запит, а застосунок вирішує, що він може читати.

Четверте: прогоніть матрицю на обох входах

Використовуйте контрольовані облікові записи, щоб перевірити A на A, B на B, A на B, невідоме ім'я хоста та автентифікований обліковий запис без членств. Четвертий і п'ятий мають відмовити закрито і ніколи не переходити до орендаря за замовчуванням. Прогоніть ту саму матрицю і через вхід VPN, з однією банкою сесії на кожен обліковий запис:

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

Потім змініть один запис у списку дозволів і запустіть знову. Результат, що зсувається, означає, що мережевий контроль ухвалює рішення про авторизацію.

Повторюйте матрицю після будь-якої зміни фронтенду, бо другий шлях коду, що пропускає перевірку, — найпоширеніший спосіб ерозії цієї межі. Очікуваний результат нудний: кожен вхід дає однакові відповіді.