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

Отключение клиента оставляет удалённый сеанс работающим, и его сетевые подключения и кэшированные учётные данные могут оставаться пригодными, пока этот сеанс не завершится. Выйдите из системы или явно завершите сеанс и подтвердите, что после этого счётчик ниже перестаёт расти. Проверка удаления, которая лишь закрывает крышку ноутбука, ничего не доказывает. Проведите ту же проверку один раз с отключённой учётной записью и один раз с отозванным разрешением на рабочий стол, затем запишите, что журналировал ресурс в каждом случае.