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

Прекъсването на клиента оставя отдалечената сесия работеща и нейните мрежови връзки и кеширани идентификационни данни могат да останат използваеми, докато тази сесия приключи. Излезте или прекратете сесията изрично и потвърдете, че броячът надолу по веригата спира да напредва след това. Тест за премахване, който само затваря капака на лаптопа, не доказва нищо. Направете същия тест веднъж с изключен акаунт и веднъж с премахнато разрешение за работния плот, после запишете какво е регистрирал ресурсът във всеки случай.