Podijeljeni poddomeni, dva ulaza: ko vidi koje zapise?

Klinika A i Klinika B dijele jednu kodnu bazu, dvije poddomene i mješavinu posjetilaca iz ureda i putem VPN-a. Mrežni timovi obično odvojeno konfigurišu dva ulaza, i to je u redu, dok god aplikacija to ne čini. Provjere ispod 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 pozivalac 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 uporedite ih sa zakupcem iz prve provjere. Korisnik koji pripada obama klinikama može prelaziti, ali prelazak 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 što ćete izmijeniti 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 odlučuju gdje se račun može predstaviti. Oni ne odlučuju šta taj račun smije čitati.

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

VPN prolaz autentificira tunel, a javni spisak dozvola 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 pregleda.

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 šta smije čitati.

Četvrto: pokrenite matricu na oba ulaza

Koristite kontrolisane 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 teglom 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 spisku dozvola i pokrenite ponovo. Rezultat koji se pomjeri 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.