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

Від’єднання клієнта залишає віддалений сеанс працюючим, і його мережеві з’єднання та кешовані облікові дані можуть залишатися придатними, доки цей сеанс не завершиться. Вийдіть із системи або явно завершіть сеанс і підтвердьте, що після цього лічильник нижче перестає рухатися вперед. Перевірка видалення, яка лише закриває кришку ноутбука, нічого не доводить. Проведіть ту саму перевірку один раз з вимкненим обліковим записом і один раз із відкликаним дозволом на робочий стіл, потім запишіть, що журналював ресурс у кожному випадку.