Агульныя паддамены, два ўваходы: хто якія запісы бачыць?

Клініка 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

Затым змяніце запіс у спісе дазволаў і запусціце зноў. Вынік, які змяніўся, азначае, што сеткавы кантроль прымае рашэнне аб аўтарызацыі.

Паўтарыце матрыцу пасля любой змены франтэнду, бо другі шлях кода, які прапускае праверку, — самы часты спосаб разбурэння гэтай мяжы. Чаканы вынік нудны: кожны ўваход дае аднолькавыя адказы.