RDP ŝanĝas la klienton: kial la datumbazo vidas alian gastiganton

Via VPN-regulo malpermesas la datumbazon kaj la bileto fermiĝas kiel fajroŝirma misfunkcio, dum la sama uzanto malfermas publikigitan labortablon kaj senprobleme pridemandas tiun datumbazon. Ambaŭ asertoj estas veraj. La labortablo estas alia kliento, kun propra adreso en segmento, kiun la reguloj jam fidas, kaj propra identeco, kiam ĝi konektiĝas plu. Tio, kio aspektas kiel kontraŭdira regulo, kutime estas dua peto, kiun neniu metis en la revizion.

La dua peto havas propran klientan adreson

Kiam aplikaĵo ene de la seanco malfermas konekton al la datumbazo, la TCP-manpremo komenciĝas ĉe la seanco-gastiganto. Ĝia fonta adreso apartenas al la reto de tiu gastiganto, do ĉiu enkursigilo kaj datumbaza fajroŝirmilo sur la vojo taksas la segmenton de la labortablo anstataŭ la tunelaron, de kiu venis via tekokomputilo. La VPN-adreso neniam aperas en tiu fluo. Tial font-bazita malpermesa regulo povas esti samtempe ĝusta kaj nerelevanta.

Legu la originon el la seanco anstataŭ el la tekokomputilo, poste testu la pluan vojon el la sama loko. La du respondoj devus konsenti pri tio, kiu gastiganto faras la peton.

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

Komparu tion, kion raportas la seanco, kun la adreso, kiun la datumbazo registris por la sama tempo. Kiam la servila protokolo montras la subreton de la labortablo anstataŭ la tunelaron, la demando ĉesas esti ĉu la regulo ekfunkciis kaj fariĝas kiu gastiganto faris la peton. Tio estas alia esploro kun alia posedanto.

La identeco ŝanĝiĝas same kiel la adresado

La plua konekto kutime aŭtentikiĝas kiel la ĵetono de la seanco, konservita akreditaĵo aŭ servokonto de la aplikaĵo, kaj la rimedo registras, kion ĝi ricevis. Tial revizia spuro montranta servokonton sur la datumbazo ne pruvas, ke homo plenumis la pridemandadon. Ĝi ankaŭ ne identigas la homon. Nur la propra seancprotokolo de la labortablo ligas tiujn du rikordojn.

Rajtigo okazas dufoje, kaj la dua decido estas farata kun malsamaj enigaĵoj. La unua donas labortablan salutong al nomita uzanto, dum la dua donas tion, kion la ĵetono de tiu uzanto aŭ la konto de la aplikaĵo povas fari al la rimedo. Subtena grupo rajtanta malfermi labortablon ne aŭtomate estas grupo rajtanta legi klientan tabelon.

Rigardu la ĵetonon kaj la delegadan vojon antaŭ ol skribi la aliran noton. Ambaŭ videblas el la seanco, kaj tio estas la sola loko, kie la respondo ne estas konjekto.

whoami /groups
klist
query session

Se la aplikaĵo uzas servokonton, ĝiaj rajtoj estas la decidaj plu. Rotacio de tiu akreditaĵo apartenas al la alira revizio, ne al posta operacia pripenso.

Kial la rekta vojo ankoraŭ estas blokita, kaj prave

La malpermesa regulo ne estas malĝusta nur ĉar la celo atingeblas alimaniere. Segmentado estas taksata laŭ fonto, kaj la labortablo sidas en segmento, kiu estis permesita longe antaŭ ol iu konsideris ĝin vojo al la datumbazo. Nenio preteriris la politikon. La politiko simple priskribas du malsamajn fontojn kun du malsamaj rezultoj.

Kion la revizio devas respondi estas, kion ĉiu rajtigita seanco sur tiu gastiganto povas lanĉi. Retumiloj kun konservitaj seancoj, mapitaj diskoj, agentoj tenantaj akreditaĵojn kaj loke aŭskultantaj servoj ĉiuj etendas la atingon de la labortablo, kaj neniu el ili aperas en la bileto, kiu donis la salutong. Tiu inventaro estas la reala permesa surfaco.

Kalkulu ĝin ene de testa seanco, ne el kalkultabelo. Plenmano da komandoj kovras la plejparton de la surfaco.

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

Elektu la limon konscie

Tri formoj taŭgas por malsamaj taskoj, kaj la elekto devus sekvi la taskon anstataŭ la ilon, kiu hazarde ekzistas. Publikigita aplikaĵo elmontras unu programon kun propraj permesoj, plena labortablo elmontras ĉion, kion la profilo de la uzanto povas fari, kaj mallarĝa datumbaza konto kun fonta limigo elmontras unu rimedon tute sen labortablo. La plej mallarĝa formo, kiu ankoraŭ plenumas la laboron, estas la dokumentinda. Ĉio pli larĝa bezonas kialon skribitan apude.

Por unu raporto, publikigita aplikaĵo aŭ limigita konto estas pli malgranda permeso ol ĝenerala labortablo. Por prizorgado, kiu vere bezonas plurajn ilojn, la labortablo povas esti ĝusta, sed tiam la aprobo priskribas la tutan gastiganton anstataŭ unu aplikaĵon. Demandu la rimedposedanton, al kiu el tiuj ili konsentas.

Datummovado estas aparta ŝaltilo. Tondujo, diskoredirektado kaj elŝutoj povas porti kompaniajn datumojn al la kliento, kaj ekzekuti aplikaĵon distance ne tenas datumojn distance per si mem.

Kontrolu ambaŭ aprobojn kaj la forigvojon

Du aproboj apartenas al la rikordo: la rajto atingi kaj malfermi la labortablon, kaj la rajto uzi rimedojn el ĝia interno. Nomu posedanton por ĉiu kaj tenu la duan videbla al kiu ajn revizias la rimedon. Ĝuste pri tiu dua ero demandos revizoro, ĉar ĝi priskribas atingon anstataŭ eniron. Skribu ambaŭ antaŭ ol la ŝanĝo estos aprobita, ne post la unua okazaĵo.

Poste testu la forigon, ĉar malkonektita seanco povas postvivi sian kialon. La seantabelo estas la plej rapida loko por vidi, kio ankoraŭ funkcias.

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

Malkonekti la klienton lasas la malproksiman seancon funkcii, kaj ĝiaj retaj konektoj kaj kaŝmemoraj akreditaĵoj povas resti uzeblaj ĝis tiu seanco finiĝos. Elsalutu, aŭ finu la seancon eksplicite, kaj konfirmu, ke la sekva nombrilo poste ĉesas antaŭeniri. Forigtesto, kiu nur fermas la kovrilon de la tekokomputilo, pruvas nenion. Faru la saman teston unufoje kun malŝaltita konto kaj unufoje kun forigita labortabla permeso, poste registru, kion la rimedo protokolis en ĉiu kazo.