RDP ndryshon klientin: pse baza e të dhënave sheh një host tjetër

Rregulli juaj i VPN-së e refuzon bazën e të dhënave dhe bileta mbyllet si defekt i firewall-it, ndërsa i njëjti përdorues hap një desktop të publikuar dhe e pyet atë bazë pa asnjë problem. Të dyja deklaratat janë të vërteta. Desktopi është një klient tjetër, me adresën e vet në një segment ku rregullat tashmë i besojnë, dhe me identitetin e vet kur lidhet më tej. Ajo që duket si rregull kontradiktor është zakonisht një kërkesë e dytë që askush nuk e vendosi në rishikim.

Kërkesa e dytë ka adresën e vet të klientit

Kur një aplikacion brenda sesionit hap një lidhje me bazën, shtrëngimi i dorës TCP fillon në hostin e sesionit. Adresa e origjinës i përket rrjetit të atij hosti, kështu që çdo ruter dhe firewall i bazës përgjatë rrugës vlerëson segmentin e desktopit dhe jo pishinën e tuneleve nga e cila erdhi laptopi juaj. Adresa e VPN-së nuk shfaqet kurrë në atë rrjedhë. Prandaj një rregull refuzimi i bazuar në origjinë mund të jetë njëkohësisht i saktë dhe i parëndësishëm.

Lexoni origjinën nga brenda sesionit dhe jo nga laptopi, më pas provoni rrugën e mëtejshme nga i njëjti vend. Të dyja përgjigjet duhet të bien dakord se cili host po e bën kërkesën.

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

Krahasoni atë që raporton sesioni me adresën që baza regjistroi për të njëjtin moment. Kur regjistri i serverit tregon nënrrjetin e desktopit në vend të pishinës së tuneleve, pyetja pushon së qeni nëse rregulli u aktivizua dhe bëhet cili host e bëri kërkesën. Ajo është një hetim tjetër me një pronar tjetër.

Identiteti ndryshon bashkë me adresimin

Lidhja e mëtejshme zakonisht autentikohet si tokeni i sesionit, kredencial i ruajtur ose llogari shërbimi e aplikacionit, dhe burimi regjistron atë që iu dha. Prandaj një gjurmë auditimi që tregon një llogari shërbimi në bazë nuk provon se një njeri e ekzekutoi pyetjen. Ai as nuk e identifikon atë njeri. Vetëm regjistri i sesionit të desktopit i lidh ato dy të dhëna.

Autorizimi ndodh dy herë, dhe vendimi i dytë merret me hyrje të ndryshme. I pari i jep një përdoruesi të emëruar një hyrje në desktop, ndërsa i dyti jep atë që tokeni i atij përdoruesi ose llogaria e aplikacionit mund të bëjë me burimin. Një grup ndihme që mund të hapë një desktop nuk është automatikisht një grup që mund të lexojë një tabelë klientësh.

Shikoni tokenin dhe rrugën e delegimit përpara se të shkruani shënimin e aksesit. Të dyja janë të dukshme nga brenda sesionit, dhe është i vetmi vend ku përgjigja nuk është hamendje.

whoami /groups
klist
query session

Nëse aplikacioni përdor një llogari shërbimi, të drejtat e saj janë ato që kanë rëndësi më tej. Rrotullimi i atij kredenciali i përket rishikimit të aksesit, jo një mendimi operativ pasues.

Pse rruga e drejtpërdrejtë është ende e bllokuar, dhe me të drejtë

Rregulli i refuzimit nuk është i gabuar vetëm sepse destinacioni është i arritshëm në një mënyrë tjetër. Segmentimi vlerësohet sipas origjinës, dhe desktopi ndodhet në një segment që u lejua shumë kohë përpara se dikush ta mendojë si rrugë drejt bazës. Asgjë nuk e anashkaloi politikën. Politika thjesht përshkruan dy origjina të ndryshme me dy rezultate të ndryshme.

Ajo që rishikimi duhet të përgjigjet është çfarë mund të nisë çdo sesion i autorizuar në atë host. Shfletuesit me sesione të ruajtura, disqet e hartuara, agjentët që mbajnë kredenciale dhe shërbimet që dëgjojnë lokalisht të gjitha zgjerojnë shtrirjen e desktopit, dhe asnjë prej tyre nuk shfaqet në biletën që dha hyrjen. Ai inventar është sipërfaqja e vërtetë e lejeve.

Numërojeni nga brenda një sesioni testimi, jo nga një fletëllogaritëse. Disa komanda mbulojnë pjesën më të madhe të sipërfaqes.

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

Zgjidhni kufirin me qëllim

Tre forma i përshtaten detyrave të ndryshme, dhe zgjedhja duhet të ndjekë detyrën dhe jo mjetin që ekziston rastësisht. Një aplikacion i publikuar ekspozon një program me lejet e veta, një desktop i plotë ekspozon gjithçka që mund të bëjë profili i përdoruesit, dhe një llogari e ngushtë baze me kufizim origjine ekspozon një burim pa asnjë desktop. Forma më e ngushtë që ende e përfundon punën është ajo që duhet dokumentuar. Çdo gjë më e gjerë kërkon një arsye të shkruar pranë saj.

Për një raport të vetëm, një aplikacion i publikuar ose një llogari e kufizuar është një dhënie më e vogël se një desktop i përgjithshëm. Për mirëmbajtje që vërtet kërkon disa mjete, desktopi mund të jetë i saktë, por atëherë miratimi përshkruan të gjithë hostin dhe jo një aplikacion. Pyetni pronarin e burimit se me cilën nga këto është dakord.

Lëvizja e të dhënave është një çelës i veçantë. Clipboard-i, ridrejtimi i disqeve dhe shkarkimet mund t'i çojnë të dhënat e kompanisë te klienti, dhe ekzekutimi i një aplikacioni në distancë nuk i mban të dhënat në distancë vetvetiu.

Kontrolloni të dyja miratimet dhe rrugën e heqjes

Dy miratime i përkasin regjistrit: e drejta për të arritur dhe hapur desktopin, dhe e drejta për të përdorur burime nga brenda tij. Caktoni një pronar për secilën dhe mbajeni të dytën të dukshme për këdo që rishikon burimin. Është pikërisht hyrja e dytë ajo për të cilën do të pyesë një auditues, sepse përshkruan shtrirjen dhe jo hyrjen. Shkruajini të dyja përpara se ndryshimi të miratohet, jo pas incidentit të parë.

Më pas provoni heqjen, sepse një sesion i shkëputur mund t'i mbijetojë arsyes që e justifikonte. Tabela e sesioneve është vendi më i shpejtë për të parë çfarë po funksionon ende.

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

Shkëputja e klientit e lë sesionin në distancë duke punuar, dhe lidhjet e tij të rrjetit dhe kredencialet e ruajtura në cache mund të mbeten të përdorshme derisa ai sesion të përfundojë. Dilni, ose përfundoni sesionin në mënyrë eksplicite, dhe konfirmoni që numëruesi poshtë ndalon së ecuri përpara pas kësaj. Një provë heqjeje që vetëm mbyll kapakun e laptopit nuk provon asgjë. Kryeni të njëjtën provë një herë me llogarinë e çaktivizuar dhe një herë me lejen e desktopit të hequr, pastaj shënoni çfarë regjistroi burimi në secilin rast.