Deljene poddomene, dva vhoda: kdo vidi katere zapise?

Klinika A in Klinika B si delita eno kodno zbirko, dve poddomeni in mešanico obiskovalcev iz pisarne in prek VPN. Omrežne ekipe običajno ločeno konfigurirajo oba vhoda, in to je v redu, dokler aplikacija tega ne počne. Spodnje kontrole spadajo v aplikacijo in bi se morale obnašati enako ne glede na to, skozi katera vrata je zahteva prišla.

Prvič: ime gostitelja poimenuje samo najemnika

Razrešite zahtevano ime gostitelja glede na preslikavo, ki jo vzdržuje skrbnik, in zavrnite vse neznano. Uporabite preverjeno vrednost gostitelja iz ogrodja namesto surove glave, da ponarejen Host ne more vstaviti iskalnega ključa. Uspešno ujemanje pove kodi, katero konfiguracijo najemnika in katero blagovno znamko naložiti. Ne pove ničesar o tem, ali sme klicatelj videti podatke tega najemnika. Drugo vprašanje hranite v ločeni funkciji z ločenim vhodom.

Skupna pomožna funkcija, ki iz enega iskanja imena gostitelja vrne kontekst in dovoljenje, je začetek napake.

Drugič: članstvo prihaja iz seje

Poiščite aktivna članstva preverjenega uporabnika in jih primerjajte z najemnikom iz prve kontrole. Uporabnik, ki pripada obema klinikama, lahko preklaplja, vendar mora biti preklop izrecno dejanje, zabeleženo v kontekstu zahteve, ne sklep iz URL-a. Uporabniku, ki pripada eni kliniki in zahteva drugo, je dostop zavrnjen, tudi za prenose in klice API.

Preizkusite negativni primer tako, da uredite identifikator zapisa in parameter najemnika. Če katera koli sprememba vrne podatke, se obseg bere iz zahteve in ne iz preverjenega članstva.

Obseg piškotkov in enotna prijava odločata, kje je mogoče predstaviti račun. Ne odločata, kaj lahko ta račun bere.

Tretjič: omrežje ne dokazuje ničesar o osebi

Prehod VPN overi tunel, javni seznam dovoljenih naslovov pa overi obseg naslovov. Nobeno ne identificira osebe. NAT stisne veliko uporabnikov v en naslov vira, pisarniški obseg pa naredi isto za vse v stavbi. Oboje obravnavajte kot dejstva prevoza in avtorizacijo hranite v aplikaciji ali v integraciji, ki izrecno zatrjuje identiteto in se kot taka pregleda.

DNS je tretje dejstvo prevoza. Zasebni odgovor potrebuje zasebno pot, javni sprednji del pa podprto pot do izvora. Nobeno od njih ne nosi dovoljenja.

En stavek za na steno: omrežje odloča, kako zahteva prispe, aplikacija pa odloča, kaj lahko bere.

Četrtič: zaženite matriko na obeh vhodih

Uporabite nadzorovane račune, da preizkusite A pri A, B pri B, A pri B, neznano ime gostitelja in overjen račun brez članstev. Četrti in peti morata odpovedati zaprto in nikoli ne smeta pasti na privzetega najemnika. Zaženite isto matriko tudi skozi vhod VPN, z enim kozarcem seje na račun:

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

Nato spremenite vnos na seznamu dovoljenih naslovov in zaženite znova. Rezultat, ki se premakne, pomeni, da omrežna kontrola sprejema odločitev o avtorizaciji.

Matriko ponovite po vsaki spremembi sprednjega dela, ker je druga kodna pot, ki kontrolo preskoči, najpogostejši način, kako ta meja erodira. Pričakovani rezultat je dolgočasen: vsak vhod daje enake odgovore.