Dijeljene poddomene, dva ulaza: tko vidi koje zapise?

Klinika A i Klinika B dijele jednu bazu koda, dvije poddomene i mješavinu posjetitelja iz ureda i putem VPN-a. Mrežni timovi obično odvojeno konfiguriraju dva ulaza, i to je u redu, dokle god aplikacija to ne čini. Provjere u nastavku pripadaju aplikaciji i moraju se ponašati jednako bez obzira na to kroz koja su vrata zahtjev ušao.

Prvo: naziv hosta imenuje samo zakupca

Razriješite traženi naziv hosta prema mapiranju koje održava administrator i odbijte sve nepoznato. Koristite provjerenu vrijednost hosta iz okvira umjesto sirovog zaglavlja, da kovan Host ne bi mogao ubaciti ključ za pretragu. Uspješno podudaranje kaže kodu koju konfiguraciju zakupca i koje brendiranje učitati. Ono ne govori ništa o tome može li pozivatelj vidjeti podatke tog zakupca. Drugo pitanje držite u zasebnoj funkciji sa zasebnim ulazom.

Zajednička pomoćna funkcija koja iz jednog traženja naziva hosta vraća i kontekst i dopuštenje početak je greške.

Drugo: članstvo dolazi iz sesije

Potražite aktivna članstva autentificiranog korisnika i usporedite ih sa zakupcem iz prve provjere. Korisnik koji pripada objema klinikama može se prebacivati, ali prebacivanje mora biti izričita radnja zabilježena u kontekstu zahtjeva, a ne zaključak iz URL-a. Korisniku koji pripada jednoj klinici i traži drugu pristup se odbija, uključujući preuzimanja i API pozive.

Testirajte negativan slučaj tako da uredite identifikator zapisa i parametar zakupca. Ako bilo koja izmjena vrati podatke, opseg se čita iz zahtjeva, a ne iz potvrđenog članstva.

Opseg kolačića i jedinstvena prijava određuju gdje se račun može predstaviti. Oni ne određuju što taj račun smije čitati.

Treće: mreža ne dokazuje ništa o osobi

VPN prolaz autentificira tunel, a javni popis dopuštenja autentificira raspon adresa. Niti jedno ne identificira osobu. NAT sabija mnogo korisnika u jednu izvornu adresu, a uredski raspon čini isto za sve u zgradi. Tretirajte oboje kao transportne činjenice i držite autorizaciju u aplikaciji ili u integraciji koja izričito tvrdi identitet i kao takva se pregledava.

DNS je treća transportna činjenica. Privatan odgovor traži privatnu rutu, a javni frontend traži podržanu putanju do izvora. Nijedno od njih ne nosi dopuštenje.

Jedna rečenica za zid: mreža odlučuje kako zahtjev stiže, a aplikacija odlučuje što smije čitati.

Četvrto: pokrenite matricu na oba ulaza

Koristite kontrolirane račune da provjerite A na A, B na B, A na B, nepoznat naziv hosta i autentificiran račun bez članstava. Četvrti i peti moraju pasti zatvoreno i nikada se ne smiju vratiti na zakupca kao zadano. Pokrenite istu matricu i kroz VPN ulaz, s jednom staklenkom sesije po računu:

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

Zatim promijenite unos na popisu dopuštenja i pokrenite ponovno. Rezultat koji se pomakne znači da mrežna kontrola donosi odluku o autorizaciji.

Ponovite matricu nakon svake promjene frontenda, jer drugi put kroz kod koji preskače provjeru najčešći je način na koji se ova granica erodira. Očekivani rezultat je dosadan: svaki ulaz daje iste odgovore.