Binabago ng RDP ang kliyente: bakit nakikita ng database ang ibang host

Tinatanggihan ng iyong patakaran sa VPN ang database at ang tiket ay isinasara bilang sira ng firewall, habang ang parehong gumagamit ay nagbubukas ng nai-publish na desktop at nagtatanong sa database na iyon nang walang problema. Ang dalawang pahayag ay totoo. Ang desktop ay ibang kliyente, may sariling address sa segment na pinagkakatiwalaan na ng mga patakaran, at may sariling pagkakakilanlan kapag kumokonekta paitaas. Ang parang magkasalungat na patakaran ay karaniwang pangalawang kahilingan na walang isinama sa pagsusuri.

Ang pangalawang kahilingan ay may sariling address ng kliyente

Kapag ang isang aplikasyon sa loob ng session ay nagbukas ng koneksyon sa database, ang TCP handshake ay nagsisimula sa host ng session. Ang source address nito ay kabilang sa network ng host na iyon, kaya sinusuri ng bawat router at firewall ng database sa daan ang segment ng desktop at hindi ang pool ng tunnel na pinanggalingan ng iyong laptop. Ang address ng VPN ay hindi kailanman lumilitaw sa daloy na iyon. Kaya naman ang patakarang pagtanggi batay sa pinagmulan ay maaaring tama at walang kaugnayan nang sabay.

Basahin ang pinagmulan mula sa loob ng session at hindi mula sa laptop, pagkatapos subukan ang karagdagang daan mula sa parehong lugar. Dapat magkasundo ang dalawang sagot kung aling host ang gumagawa ng kahilingan.

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

Ihambing ang iniuulat ng session sa address na itinala ng database para sa parehong sandali. Kapag ang log ng server ay nagpapakita ng subnet ng desktop sa halip na ang pool ng tunnel, ang tanong ay hindi na kung umandar ang patakaran at nagiging aling host ang gumawa ng kahilingan. Iba iyon na imbestigasyon na may ibang may-ari.

Nagbabago rin ang pagkakakilanlan kasama ng pag-address

Ang karagdagang koneksyon ay karaniwang nagpapatunay bilang token ng session, nakatagong kredensyal o service account ng aplikasyon, at itinatala ng resource ang ibinigay dito. Kaya ang audit trail na nagpapakita ng service account sa database ay hindi nagpapatunay na tao ang nagpatakbo ng query. Hindi rin nito kinikilala ang taong iyon. Ang log ng session ng desktop mismo lamang ang nag-uugnay sa dalawang talaan.

Dalawang beses nangyayari ang awtorisasyon, at ang pangalawang desisyon ay ginagawa gamit ang ibang input. Ang una ay nagbibigay ng pag-sign in sa desktop sa isang pinangalanang gumagamit, habang ang pangalawa ay nagbibigay ng kung ano ang maaaring gawin ng token ng gumagamit na iyon o ng account ng aplikasyon sa resource. Ang grupong helpdesk na maaaring magbukas ng desktop ay hindi awtomatikong grupong maaaring magbasa ng talahanayan ng customer.

Tingnan ang token at ang daan ng delegasyon bago isulat ang tala ng access. Parehong nakikita mula sa loob ng session, at iyon ang tanging lugar kung saan hindi haka-haka ang sagot.

whoami /groups
klist
query session

Kung gumagamit ang aplikasyon ng service account, ang mga karapatan nito ang mahalaga sa hinaharap. Ang pag-ikot ng kredensyal na iyon ay kabilang sa pagsusuri ng access, hindi sa operasyonal na pag-iisip mamaya.

Bakit blokeado pa rin ang direktang daan, at tama nga

Hindi mali ang patakarang pagtanggi dahil lang naaabot ang destinasyon sa ibang paraan. Ang segmentation ay sinusuri ayon sa pinagmulan, at ang desktop ay nasa segment na pinayagan matagal bago pa man ito isipin ng kahit sino bilang daan patungo sa database. Walang lumabag sa patakaran. Ang patakaran ay naglalarawan lamang ng dalawang magkaibang pinagmulan na may dalawang magkaibang resulta.

Ang dapat sagutin ng pagsusuri ay kung ano ang maaaring simulan ng bawat awtorisadong session sa host na iyon. Ang mga browser na may nakatagong session, naka-map na drive, ahenteng humahawak ng kredensyal at lokal na nakikinig na serbisyo ay pinalalawak ang abot ng desktop, at wala sa mga ito ang lumilitaw sa tiket na nagbigay ng pag-sign in. Ang imbentaryong iyon ang tunay na ibabaw ng pahintulot.

Isa-isahin ito mula sa loob ng pagsubok na session, hindi mula sa spreadsheet. Ilang utos lang ang sumasaklaw sa karamihan ng ibabaw.

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

Piliin ang hangganan nang sadya

Tatlong hugis ang angkop sa magkaibang gawain, at ang pagpili ay dapat sumunod sa gawain at hindi sa kasangkapan na nagkataong naroon. Ang nai-publish na aplikasyon ay naglalantad ng isang programa na may sariling pahintulot, ang buong desktop ay naglalantad ng lahat ng kaya ng profile ng gumagamit, at ang makitid na account ng database na may pinagmulang paghihigpit ay naglalantad ng isang resource na walang desktop. Ang pinakamakitid na hugis na nakakumpleto pa rin ng gawain ang dapat idokumento. Anumang mas malawak ay nangangailangan ng dahilan na nakasulat sa tabi nito.

Para sa isang ulat, ang nai-publish na aplikasyon o limitadong account ay mas maliit na bigay kaysa sa pangkalahatang desktop. Para sa maintenance na talagang nangangailangan ng maraming kasangkapan, maaaring tama ang desktop, pero ang pag-apruba ay naglalarawan ng buong host at hindi ng isang aplikasyon. Itanong sa may-ari ng resource kung alin sa mga ito ang sinasang-ayunan nila.

Ang paggalaw ng data ay hiwalay na switch. Ang clipboard, pag-redirect ng drive at mga pag-download ay makakapagdala ng data ng kompanya sa kliyente, at ang pagpapatakbo ng aplikasyon nang malayuan ay hindi nagpapanatili ng data sa malayo nang mag-isa.

Suriin ang dalawang pag-apruba at ang daan ng pag-alis

Dalawang pag-apruba ang kabilang sa talaan: ang karapatang maabot at mabuksan ang desktop, at ang karapatang gumamit ng resource mula sa loob nito. Magbigay ng may-ari sa bawat isa at panatilihing nakikita ang pangalawa ng sinumang sumusuri sa resource. Ang pangalawang entry na iyon ang tatanungin ng auditor, dahil inilalarawan nito ang abot at hindi ang pagpasok. Isulat ang dalawa bago aprubahan ang pagbabago, hindi pagkatapos ng unang insidente.

Pagkatapos ay subukan ang pag-alis, dahil ang nadiskonektang session ay maaaring mabuhay nang mas matagal kaysa sa dahilan nito. Ang talahanayan ng session ang pinakamabilis na lugar upang makita kung ano pa ang tumatakbo.

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

Ang pagdiskonekta sa kliyente ay nag-iiwan ng remote session na tumatakbo, at ang mga koneksyon sa network at naka-cache na kredensyal nito ay maaaring manatiling magagamit hanggang matapos ang session na iyon. Mag-sign out, o tapusin ang session nang tahasan, at tiyakin na ang counter sa ibaba ay humihinto sa pag-usad pagkatapos. Ang pagsubok ng pag-alis na nagbababa lang ng takip ng laptop ay walang pinapatunayan. Gawin ang parehong pagsubok isang beses na naka-disable ang account at isang beses na tinanggal ang pahintulot sa desktop, pagkatapos itala kung ano ang na-log ng resource sa bawat kaso.