Megosztott aldomainek, két bejárat: ki melyik rekordokat látja?

Az A klinika és a B klinika egy kódbázist, két aldomaint és irodai, valamint VPN-en keresztül érkező látogatók keverékét osztja meg. A hálózati csapatok hajlamosak a két bejáratot külön konfigurálni, és ez rendben van, amíg az alkalmazás nem teszi ezt. Az alábbi ellenőrzések az alkalmazásba tartoznak, és ugyanúgy kell viselkedniük, függetlenül attól, melyik ajtón jött a kérés.

Először: a hosztnév csak egy bérlőt nevez meg

Oldja fel a kért hosztnevet az adminisztrátor által karbantartott leképezés alapján, és utasítson el mindent, ami ismeretlen. A nyers fejléc helyett a keretrendszer érvényesített hosztértékét használja, hogy egy hamisított Host ne tudjon keresési kulcsot befecskendezni. A sikeres egyezés megmondja a kódnak, melyik bérlőkonfigurációt és márkázást töltse be. Semmit nem mond arról, hogy a hívó láthatja-e az adott bérlő adatait. Tartsa ezt a második kérdést külön függvényben, külön bemenettel.

Egy megosztott segédfüggvény, amely egyetlen hosztnév-keresésből egyszerre adja vissza a kontextust és az engedélyt, a hiba kezdete.

Másodszor: a tagság a munkamenetből származik

Keresse meg a hitelesített felhasználó aktív tagságait, és hasonlítsa össze őket az első ellenőrzés bérlőjével. Az a felhasználó, aki mindkét klinikához tartozik, válthat, de a váltásnak a kérés kontextusában rögzített, kifejezett műveletnek kell lennie, nem az URL-ből levont következtetésnek. Azt a felhasználót, aki egy klinikához tartozik, és a másikat kéri, elutasítják, a letöltéseket és az API-hívásokat is beleértve.

Tesztelje a negatív esetet egy rekordazonosító és egy bérlőparaméter szerkesztésével. Ha bármelyik módosítás adatot ad vissza, a hatókör a kérésből olvasódik, nem az ellenőrzött tagságból.

A cookie-hatókör és az egyszeri bejelentkezés eldönti, hol jeleníthető meg egy fiók. Azt nem döntik el, mit olvashat az a fiók.

Harmadszor: a hálózat semmit nem bizonyít a személyről

A VPN-átjáró egy alagutat hitelesít, a nyilvános engedélyezési lista pedig egy címteret. Egyik sem azonosít személyt. A NAT sok felhasználót von össze egyetlen forrás címbe, és az irodai címtartomány ugyanezt teszi az épület mindenkivel. Kezelje mindkettőt szállítási tényként, és tartsa az engedélyezést az alkalmazásban, vagy olyan integrációban, amely kifejezetten állítja az identitást, és ennek megfelelően vizsgálják.

A DNS egy harmadik szállítási tény. A privát válaszhoz privát útvonal kell, a nyilvános frontendhez pedig támogatott forrásútvonal. Egyik sem hordoz engedélyt.

Egy mondat a falra: a hálózat eldönti, hogyan érkezik a kérés, az alkalmazás pedig eldönti, mit olvashat.

Negyedszer: futtassa a mátrixot mindkét bejáraton

Használjon ellenőrzött fiókokat, hogy kipróbálja A-t A-ban, B-t B-ben, A-t B-ben, egy ismeretlen hosztnevet és egy tagság nélküli hitelesített fiókot. A negyediknek és az ötödiknek zártan kell meghiúsulnia, és soha nem eshet vissza egy alapértelmezett bérlőre. Futtassa ugyanezt a mátrixot a VPN-bejáraton is, fiókonként egy munkamenet-üveggel:

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

Ezután módosítson egy bejegyzést az engedélyezési listán, és futtassa újra. Az elmozduló eredmény azt jelenti, hogy egy hálózati vezérlő engedélyezési döntést hoz.

Ismételje meg a mátrixot minden frontend-változás után, mert az ellenőrzést kihagyó második kódútvonal a leggyakoribb módja annak, ahogy ez a határ erodálódik. A várt eredmény unalmas: minden bejárat ugyanazokat a válaszokat adja.