Jagatud alamdomeenid, kaks sissepääsu: kes milliseid kirjeid näeb?

Kliinik A ja Kliinik B jagavad ühte koodibaasi, kahte alamdomeeni ning kontorist ja VPN-i kaudu tulijate segu. Võrgumeeskonnad kipuvad kahte sissepääsu eraldi seadistama, ja see on korras, kui rakendus seda ei tee. Allpool toodud kontrollid kuuluvad rakendusse ja peaksid käituma ühtemoodi olenemata sellest, millist ust päring kasutas.

Esiteks: hostinimi nimetab ainult rentnikku

Lahendage nõutud hostinimi administraatori hallatava vastenduse järgi ja lükake tagasi kõik tundmatu. Kasutage raamistiku valideeritud hostiväärtust toore päise asemel, et võltsitud Host ei saaks päringuvõtit sisestada. Edukas vaste ütleb koodile, millist rentniku konfiguratsiooni ja brändingut laadida. See ei ütle midagi selle kohta, kas kutsuja tohib selle rentniku andmeid näha. Hoidke see teine küsimus eraldi funktsioonis eraldi sisendiga.

Ühine abifunktsioon, mis tagastab ühest hostinime otsingust nii konteksti kui ka loa, on vea algus.

Teiseks: liikmelisus tuleb sessioonist

Otsige autenditud kasutaja aktiivsed liikmelisused ja võrrelge neid esimese kontrolli rentnikuga. Mõlemasse kliinikusse kuuluv kasutaja võib vahetada, kuid vahetus peaks olema päringu konteksti kirja pandud selgesõnaline toiming, mitte URL-ist tuletatud järeldus. Kasutaja, kes kuulub ühte kliinikusse ja küsib teist, lükatakse tagasi, sealhulgas allalaadimiste ja API-kutsete puhul.

Testige negatiivset juhtumit, muutes kirje identifikaatorit ja rentniku parameetrit. Kui kumbki muudatus tagastab andmeid, loetakse ulatus päringust, mitte kinnitatud liikmelisusest.

Küpsiste ulatus ja ühekordne sisselogimine otsustavad, kus kontot saab esitada. Need ei otsusta, mida see konto tohib lugeda.

Kolmandaks: võrk ei tõesta inimese kohta midagi

VPN-i lüüs autendib tunnelit ja avalik lubatud aadresside loend autendib aadressivahemikku. Kumbki ei tuvasta inimest. NAT surub paljud kasutajad ühte lähteaadressi ja kontorivahemik teeb sama kõigi hoone inimeste jaoks. Käsitlege mõlemat transpordifaktina ja hoidke autoriseerimine rakenduses või integratsioonis, mis väidab identiteeti selgesõnaliselt ja mida vastavalt üle vaadatakse.

DNS on kolmas transpordifakt. Privaatne vastus vajab privaatset marsruuti ja avalik esiots vajab toetatud päritoluteed. Ükski neist ei kanna luba.

Üks lause seinale: võrk otsustab, kuidas päring saabub, ja rakendus otsustab, mida see tohib lugeda.

Neljandaks: käivitage maatriks mõlemas sissepääsus

Kasutage kontrollitud kontosid, et proovida A-d A juures, B-d B juures, A-d B juures, tundmatut hostinime ja autenditud kontot ilma liikmelisusteta. Neljas ja viies peaksid läbi kukkuma suletult ega tohiks kunagi langeda vaikimisi rentnikule. Käivitage sama maatriks ka VPN-i sissepääsu kaudu, ühe sessioonipurgiga iga konto kohta:

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

Seejärel muutke lubatud aadresside loendi kirjet ja käivitage uuesti. Tulemus, mis liigub, tähendab, et võrgukontroll teeb autoriseerimisotsuse.

Korrake maatriksit pärast igasugust esiotsa muudatust, sest teine kooditee, mis kontrolli vahele jätab, on kõige tavalisem viis, kuidas see piir erodeerub. Oodatud tulemus on igav: iga sissepääs annab samad vastused.