Споделени поддомейни, два входа: кой кои записи вижда?

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

Първо: името на хоста назовава само наемател

Съпоставете заявеното име на хост с карта, която администраторът поддържа, и отхвърляйте всичко непознато. Използвайте проверената от рамката стойност на хоста вместо суровия заглавен ред, за да не може подправен Host да вмъкне ключ за търсене. Успешното съвпадение казва на кода коя конфигурация на наемателя и кое брандиране да зареди. То не казва нищо за това дали извикващият може да види данните на този наемател. Дръжте втория въпрос в отделна функция с отделен вход.

Обща помощна функция, която връща едновременно контекст и разрешение от едно търсене на име на хост, е началото на дефекта.

Второ: членството идва от сесията

Намерете активните членства на удостоверения потребител и ги сравнете с наемателя от първата проверка. Потребител, който принадлежи и към двете клиники, може да превключва, но превключването трябва да е явно действие, записано в контекста на заявката, а не извод от URL. Потребител, който принадлежи към една клиника и заяви другата, получава отказ, включително за изтегляния и API заявки.

Тествайте отрицателния случай, като редактирате идентификатор на запис и параметър на наемател. Ако някоя от двете промени върне данни, обхватът се чете от заявката, а не от потвърденото членство.

Обхватът на бисквитките и еднократното влизане решават къде може да се представи профил. Те не решават какво може да чете този профил.

Трето: мрежата не доказва нищо за човека

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

След това променете запис в списъка за разрешаване и пуснете отново. Резултат, който се променя, означава, че мрежов контрол взема решение за оторизация.

Повторете матрицата след всяка промяна на фронтенда, защото втори кодов път, който пропуска проверката, е най-честият начин тази граница да ерозира. Очакваният резултат е скучен: всеки вход дава същите отговори.