RDP змяняе кліента: чаму база даных бачыць іншы хост

Ваша правіла VPN забараняе доступ да базы, і заяўка закрываецца як збой файрвола, а той жа карыстальнік адкрывае апублікаваны працоўны стол і без праблем робіць запыт да гэтай базы. Абодва сцверджанні праўдзівыя. Працоўны стол — іншы кліент: у яго свой адрас у сегменце, якому правілы ўжо давяраюць, і свая ідэнтычнасць, калі ён злучаецца далей. Тое, што выглядае як супярэчлівае правіла, звычайна ёсць другім запытам, якога ніхто не ўнёс у разгляд.

Другі запыт мае ўласны адрас кліента

Калі праграма ўнутры сеанса адкрывае злучэнне да базы, TCP-рукапоцісак пачынаецца на хосце сеанса. Яго адрас крыніцы належыць сетцы гэтага хоста, таму кожны маршрутызатар і файрвол базы на шляху ацэньвае сегмент працоўнага стала, а не пул тунеля, з якога прыйшоў ваш ноўтбук. Адрас VPN у гэтым патоку не з’яўляецца ніколі. Таму правіла забароны па крыніцы можа быць адначасова слушным і неістотным.

Чытайце крыніцу знутры сеанса, а не з ноўтбука, затым праверце далейшы шлях з таго ж месца. Абодва адказы павінны сыходзіцца ў тым, які хост робіць запыт.

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

Параўнайце тое, што паведамляе сеанс, з адрасам, які база запісала для таго ж часу. Калі журнал сервера паказвае падсетку працоўнага стала замест пула тунеля, пытанне перастае быць пытаннем, ці спрацавала правіла, і робіцца пытаннем, які хост зрабіў запыт. Гэта іншае расследаванне з іншым уладальнікам.

Ідэнтычнасць змяняецца разам з адрасацыяй

Далейшае злучэнне звычайна аўтэнтыфікуецца як токен сеанса, захаваныя ўліковыя даныя або службовы рахунак праграмы, і рэсурс запісвае тое, што яму далі. Таму журнал аўдыту са службовым рахункам у базе не даказвае, што запыт выканаў чалавек. Ён і не вызначае чалавека. Толькі ўласны журнал сеанса працоўнага стала звязвае гэтыя два запісы.

Аўтарызацыя адбываецца двойчы, і другое рашэнне прымаецца з іншымі ўваходамі. Першае дае ўваход на працоўны стол пэўнаму карыстальніку, другое дае тое, што можа зрабіць з рэсурсам токен гэтага карыстальніка або рахунак праграмы. Група службы падтрымкі, якой можна адкрываць працоўны стол, не абавязкова ёсць групай, якой можна чытаць табліцу кліентаў.

Паглядзіце на токен і шлях дэлегавання перад тым, як пісаць нататку пра доступ. Абодва бачныя знутры сеанса, і гэта адзінае месца, дзе адказ не здагадка.

whoami /groups
klist
query session

Калі праграма выкарыстоўвае службовы рахунак, менавіта яго правы маюць значэнне далей. Змена гэтых уліковых даных належыць да разгляду доступу, а не да аператыўнай думкі пасля.

Чаму прамы шлях усё яшчэ заблакаваны і пры гэтым слушна

Правіла забароны не памылковае толькі таму, што мэта дасягальная іншым шляхам. Сегментацыя ацэньваецца па кожнай крыніцы, а працоўны стол знаходзіцца ў сегменце, які дазволілі задоўга да таго, як хтосьці ўявіў яго шляхам да базы. Нішто не абышло палітыку. Палітыка проста апісвае дзве розныя крыніцы з двума рознымі вынікамі.

Разгляд павінен адказаць, што можа пачаць кожны дазволены сеанс на гэтым хосце. Браўзеры з захаванымі сеансамі, падключаныя дыскі, агенты з уліковымі данымі і лакальныя службы, што слухаюць порты, пашыраюць дасяжнасць працоўнага стала, і ніводнае з іх не з’яўляецца ў заяўцы, якая дала ўваход. Менавіта гэты пералік і ёсць сапраўдная паверхня дазволаў.

Пералічыце яго знутры тэставага сеанса, а не з табліцы. Некалькі каманд пакрываюць большую частку паверхні.

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

Выбірайце мяжу свядома

Тры формы адпавядаюць розным задачам, і выбар павінен ісці за задачай, а не за інструментам, які выпадкова існуе. Апублікаваная праграма адкрывае адну праграму з яе ўласнымі правамі, поўны працоўны стол адкрывае ўсё, што можа рабіць профіль карыстальніка, а вузкі рахунак базы з абмежаваннем крыніцы адкрывае адзін рэсурс зусім без працоўнага стала. Самая вузкая форма, якая ўсё яшчэ выконвае працу, і ёсць тым, што трэба задокументаваць. Усё шырэйшае патрабуе прычыны, запісанай побач.

Для адной справаздачы апублікаваная праграма або абмежаваны рахунак ёсць меншым дазволам, чым агульны працоўны стол. Для абслугоўвання, якому сапраўды патрэбныя некалькі інструментаў, працоўны стол можа быць правільным, але тады ўхваленне апісвае ўвесь хост, а не адну праграму. Спытайце ўладальніка рэсурсу, на што з гэтага яны згаджаюцца.

Перамяшчэнне даных — асобны перамыкач. Буфер абмену, перанакіраванне дыскаў і спампоўкі могуць перанесці даныя кампаніі на кліент, а запуск праграмы аддалена не ўтрымлівае даныя аддалена сам па сабе.

Праверце абодва ўхваленні і шлях выдалення

У запіс належаць два ўхваленні: права дасягнуць і адкрыць працоўны стол і права карыстацца рэсурсамі знутры яго. Назавіце ўладальніка для кожнага і трымайце другое бачным для таго, хто разглядае рэсурс. Менавіта другі запіс спытае аўдытар, бо ён апісвае дасяжнасць, а не ўваход. Напішыце абодва да ўхвалення змены, а не пасля першага інцыдэнту.

Затым праверце выдаленне, бо адключаны сеанс можа перажыць прычыну свайго існавання. Табліца сеансаў — найхутчэйшае месца, каб убачыць, што яшчэ працуе.

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

Адключэнне кліента пакідае аддалены сеанс працуючым, і яго сеткавыя злучэнні і кэшаваныя ўліковыя даныя могуць заставацца прыдатнымі, пакуль гэты сеанс не скончыцца. Выйдзіце з сістэмы або яўна завершыце сеанс і пацвердзіце, што пасля гэтага лічыльнік далей не расце. Тэст выдалення, які толькі зачыняе вечка ноўтбука, нічога не даказвае. Прайдзіце той жа тэст адзін раз з адключаным рахункам і адзін раз з выдаленым дазволам на працоўны стол, затым запішыце, што рэсурс зафіксаваў у кожным выпадку.