A VPN-szabálya megtagadja az adatbázist, és a jegyet tűzfalszabály-hibaként zárják le, miközben ugyanaz a felhasználó megnyit egy közzétett asztalt, és gond nélkül kérdez le abból az adatbázisból. Mindkét állítás igaz. Az asztal másik kliens, saját címmel egy olyan szegmensen, amelyben a szabályok már megbíznak, és saját identitással, amikor tovább kapcsolódik. Ami ellentmondó szabálynak látszik, az általában egy második kérés, amelyet senki nem tett be az átvizsgálásba.

A második kérésnek saját ügyfélcíme van

Amikor a munkameneten belüli alkalmazás kapcsolatot nyit az adatbázishoz, a TCP kézfogás a munkamenet gazdagépén indul. Forráscíme annak a gazdagépnek a hálózatához tartozik, ezért az útvonalon minden útválasztó és adatbázis-tűzfal az asztal szegmensét értékeli, nem azt az alagútgyűjtőt, ahonnan a notebookja érkezett. A VPN-cím soha nem jelenik meg abban a folyamban. Ezért lehet egy forrásalapú tiltószabály egyszerre helyes és lényegtelen.

A származást a munkamenet belsejéből olvassa ki, ne a notebookból, majd ugyanarról a helyről tesztelje a további útvonalat. A két válasznak meg kell egyeznie abban, melyik gazdagép küldi a kérést.

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

Hasonlítsa össze, amit a munkamenet jelent, azzal a címmel, amelyet az adatbázis ugyanarra az időpontra rögzített. Amikor a kiszolgálónapló az alagútgyűjtő helyett az asztal alhálózatát mutatja, a kérdés megszűnik arról szólni, hogy lecsapott-e a szabály, és arról szól, melyik gazdagép tette a kérést. Az másik vizsgálat, másik felelőssel.

Az identitás a címzés mellett szintén megváltozik

A továbbkapcsolódás általában a munkamenet tokenjeként, tárolt hitelesítő adatként vagy az alkalmazás szolgáltatásfiókjaként hitelesít, és az erőforrás azt rögzíti, amit kapott. Ezért az adatbázison szolgáltatásfiókot mutató auditnyom nem bizonyítja, hogy ember futtatta a lekérdezést. Azt az embert sem azonosítja. Csak az asztal saját munkamenetnaplója kapcsolja össze a két rekordot.

Az engedélyezés kétszer történik, és a második döntés más bemenetekkel születik. Az első névre szóló felhasználónak ad asztali bejelentkezést, a második azt adja, amit a felhasználó tokenje vagy az alkalmazás fiókja az erőforrással tehet. Egy ügyfélszolgálati csoport, amely megnyithat egy asztalt, nem automatikusan csoport, amely ügyféltáblát olvashat.

Nézze meg a tokent és a delegálási útvonalat, mielőtt megírja a hozzáférési feljegyzést. Mindkettő látható a munkamenet belsejéből, és ez az egyetlen hely, ahol a válasz nem találgatás.

whoami /groups
klist
query session

Ha az alkalmazás szolgáltatásfiókot használ, annak jogai számítanak tovább. A hitelesítő adat cseréje a hozzáférési átvizsgálás része, nem utólagos üzemeltetési gondolat.

Miért van a közvetlen útvonal továbbra is – helyesen – elzárva

A tiltószabály nem attól hibás, hogy a cél más úton elérhető. A szegmentálást forrásonként értékelik, és az asztal olyan szegmensen ül, amelyet jóval azelőtt engedélyeztek, hogy bárki az adatbázis felé vezető útvonalként gondolt volna rá. Semmi nem kerülte meg a szabályzatot. A szabályzat egyszerűen két különböző forrást ír le két különböző eredménnyel.

Az átvizsgálásnak azt kell megválaszolnia, mit indíthat minden engedélyezett munkamenet azon a gazdagépen. A mentett munkamenetű böngészők, a csatolt meghajtók, a hitelesítő adatokat tartó ügynökök és a helyben figyelő szolgáltatások mind kiterjesztik az asztal elérését, és egyik sem jelenik meg abban a jegyben, amely a bejelentkezést adta. Ez a leltár a valódi engedélyfelület.

Tesztmunkamenet belsejéből sorolja fel, ne táblázatból. Néhány parancs lefedi a felület nagy részét.

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

Válassza meg a határt szándékosan

Három forma illik különböző feladatokhoz, és a választásnak a feladatot kell követnie, nem a véletlenül létező eszközt. A közzétett alkalmazás egy programot tár fel saját jogosultságaival, a teljes asztal mindent feltár, amit a felhasználói profil tehet, a forráskorlátozással szűkített adatbázisfiók pedig egy erőforrást tár fel asztal nélkül. A legszűkebb forma, amely még elvégzi a munkát, az, amelyet dokumentálni kell. Minden szélesebb indoklást igényel mellé írva.

Egyetlen jelentéshez a közzétett alkalmazás vagy a korlátozott fiók kisebb engedély, mint egy általános asztal. A valóban több eszközt igénylő karbantartáshoz az asztal lehet helyes, de akkor a jóváhagyás az egész gazdagépet írja le, nem egy alkalmazást. Kérdezze meg az erőforrás tulajdonosát, melyikkel ért egyet.

Az adatmozgatás külön kapcsoló. A vágólap, a meghajtó-átirányítás és a letöltések a vállalat adatait a klienshez vihetik, és az alkalmazás távoli futtatása önmagában nem tartja távol az adatokat.

Ellenőrizze mindkét jóváhagyást és az eltávolítás útvonalát

Két jóváhagyás tartozik a nyilvántartáshoz: a jog, hogy elérje és megnyissa az asztalt, és a jog, hogy erőforrásokat használjon belülről. Nevezzen meg tulajdonost mindkettőhöz, és tartsa a másodikat láthatóan annak, aki az erőforrást átvizsgálja. A második bejegyzésről fog kérdezni egy auditor, mert az elérést írja le, nem a belépést. Mindkettőt a változás jóváhagyása előtt írja meg, nem az első esemény után.

Aztán tesztelje az eltávolítást, mert egy bontott munkamenet túlélheti a létének okát. A munkamenettábla a leggyorsabb hely, hogy lássa, mi fut még.

query session
query user
qwinsta /server:rdsh01.corp.internal

Az ügyfél bontása futva hagyja a távoli munkamenetet, és annak hálózati kapcsolatai és gyorsítótárazott hitelesítő adatai addig maradhatnak használhatók, amíg az a munkamenet véget nem ér. Jelentkezzen ki, vagy fejezze be a munkamenetet kifejezetten, és erősítse meg, hogy az alsóbb számláló utána megáll. Az eltávolítási teszt, amely csak a notebook fedelét csukja be, semmit nem bizonyít. Futtassa ugyanazt a tesztet egyszer letiltott fiókkal, egyszer pedig elvont asztali engedéllyel, majd rögzítse, mit naplózott az erőforrás az egyes esetekben.

Kapcsolódó cikkek