RDP bytter klient: hvorfor databasen ser en annen vert

VPN-regelen din avviser databasen, og saken lukkes som en brannmurfeil, mens den samme brukeren åpner et publisert skrivebord og spør mot den databasen uten problemer. Begge utsagnene er sanne. Skrivebordet er en annen klient, med sin egen adresse på et segment som reglene allerede stoler på, og med sin egen identitet når den kobler videre. Det som ser ut som en motstridende regel, er som regel en andre forespørsel som ingen la inn i gjennomgangen.

Den andre forespørselen har sin egen klientadresse

Når et program inne i økten åpner en tilkobling til databasen, starter TCP-håndtrykket på øktverten. Kildeadressen tilhører nettverket til den verten, så hver ruter og databasens brannmur langs veien vurderer segmentet til skrivebordet og ikke tunnelbassenget den bærbare datamaskinen din kom fra. VPN-adressen dukker aldri opp i den strømmen. Derfor kan en avvisningsregel basert på kilde være både riktig og irrelevant samtidig.

Les opphavet fra inne i økten og ikke fra den bærbare datamaskinen, og test deretter veien videre fra samme sted. De to svarene bør være enige om hvilken vert som sender forespørselen.

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

Sammenlign det økten rapporterer med adressen databasen registrerte for samme tidspunkt. Når serverloggen viser subnettet til skrivebordet i stedet for tunnelbassenget, slutter spørsmålet å være om regelen slo til, og blir hvilken vert som sendte forespørselen. Det er en annen undersøkelse med en annen eier.

Identiteten endres sammen med adresseringen

Viderekoblingen autentiserer seg vanligvis som øktens token, en lagret legitimasjon eller en tjenestekonto for programmet, og ressursen registrerer det den fikk. Et revisjonsspor som viser en tjenestekonto på databasen beviser derfor ikke at et menneske kjørte spørringen. Det identifiserer heller ikke mennesket. Bare skrivebordets egen øktlogg knytter de to postene sammen.

Autorisasjon skjer to ganger, og den andre avgjørelsen tas med andre inngangsverdier. Den første gir en navngitt bruker pålogging til et skrivebord, mens den andre gir det tokenet til brukeren eller kontoen til programmet kan gjøre mot ressursen. En helpdeskgruppe som kan åpne et skrivebord, er ikke automatisk en gruppe som kan lese en kundetabell.

Se på tokenet og delegeringsveien før du skriver tilgangsnotatet. Begge er synlige fra inne i økten, og det er det eneste stedet der svaret ikke er en gjetning.

whoami /groups
klist
query session

Hvis programmet bruker en tjenestekonto, er det rettighetene til den som betyr noe videre. Rotasjon av den legitimasjonen hører i tilgangsgjennomgangen, ikke i en operativ ettertanke.

Hvorfor den direkte veien fortsatt er blokkert, og med rette

Avvisningsregelen er ikke feil bare fordi målet kan nås på en annen måte. Segmentering vurderes per kilde, og skrivebordet ligger på et segment som ble tillatt lenge før noen tenkte på det som en rute til databasen. Ingenting omgikk policyen. Policyen beskriver ganske enkelt to forskjellige kilder med to forskjellige utfall.

Det gjennomgangen må svare på, er hva hver autorisert økt på den verten kan starte. Nettlesere med lagrede økter, tilknyttede stasjoner, agenter som holder legitimasjon og lokalt lyttende tjenester utvider alle rekkevidden til skrivebordet, og ingen av dem vises i saken som ga påloggingen. Den oversikten er den egentlige tillatelsesflaten.

List dem opp fra inne i en testøkt, ikke fra et regneark. Noen få kommandoer dekker det meste av flaten.

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

Velg grensen med vilje

Tre former passer til ulike oppgaver, og valget bør følge oppgaven og ikke verktøyet som tilfeldigvis finnes. Et publisert program viser ett program med egne tillatelser, et fullt skrivebord viser alt brukerprofilen kan gjøre, og en avgrenset databasekonto med kildebegrensning viser én ressurs helt uten skrivebord. Den smaleste formen som fortsatt fullfører arbeidet, er den som skal dokumenteres. Alt bredere trenger en grunn skrevet ved siden av.

For én rapport er et publisert program eller en begrenset konto en mindre tildeling enn et generelt skrivebord. For vedlikehold som virkelig trenger flere verktøy, kan skrivebordet være riktig, men da beskriver godkjenningen hele verten og ikke ett program. Spør ressurseieren hvilket av dem de sier ja til.

Dataflytting er en egen bryter. Utklippstavle, stasjonsomdirigering og nedlastinger kan føre bedriftsdata til klienten, og det å kjøre et program eksternt holder ikke data eksternt av seg selv.

Kontroller begge godkjenningene og fjerningsveien

To godkjenninger hører i posten: retten til å nå og åpne skrivebordet, og retten til å bruke ressurser fra innsiden. Navngi en eier for hver av dem og hold den andre synlig for den som gjennomgår ressursen. Det er den andre posten en revisor vil spørre om, fordi den beskriver rekkevidde og ikke inngang. Skriv begge før endringen godkjennes, ikke etter den første hendelsen.

Test deretter fjerningen, fordi en frakoblet økt kan overleve grunnen til at den finnes. Økttabellen er det raskeste stedet å se hva som fortsatt kjører.

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

Frakobling av klienten lar fjernøkten fortsette å kjøre, og nettverkstilkoblingene og de hurtiglagrede legitimasjonene kan forbli brukbare til den økten avsluttes. Logg ut, eller avslutt økten eksplisitt, og bekreft at telleren lenger ned slutter å bevege seg etterpå. En fjerneringstest som bare lukker lokket på den bærbare datamaskinen, beviser ingenting. Kjør den samme testen én gang med deaktivert konto og én gang med fjernet skrivebordstillatelse, og noter deretter hva ressursen loggførte i hvert tilfelle.