RDP zmienia klienta: dlaczego baza danych widzi inny host

Twoja reguła VPN odmawia dostępu do bazy i zgłoszenie jest zamykane jako awaria zapory, podczas gdy ten sam użytkownik otwiera opublikowany pulpit i bez problemu odpytywuje tę bazę. Oba stwierdzenia są prawdziwe. Pulpit jest innym klientem, z własnym adresem w segmencie, któremu reguły już ufają, i własną tożsamością, gdy łączy się dalej. To, co wygląda na sprzeczną regułę, jest zwykle drugim żądaniem, którego nikt nie umieścił w przeglądzie.

Drugie żądanie ma własny adres klienta

Gdy aplikacja wewnątrz sesji otwiera połączenie z bazą, uścisk dłoni TCP zaczyna się na hoście sesji. Jego adres źródłowy należy do sieci tego hosta, więc każdy router i zapora bazy na ścieżce ocenia segment pulpitu, a nie pulę tuneli, z której przyszedł Twój laptop. Adres VPN nigdy nie pojawia się w tym przepływie. Dlatego reguła odmowy oparta na źródle może być jednocześnie poprawna i nieistotna.

Czytaj pochodzenie wewnątrz sesji, a nie z laptopa, następnie sprawdź dalszą ścieżkę z tego samego miejsca. Obie odpowiedzi powinny być zgodne co do tego, który host wysyła żądanie.

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

Porównaj to, co zgłasza sesja, z adresem, który baza zapisała dla tego samego momentu. Gdy dziennik serwera pokazuje podsieć pulpitu zamiast puli tuneli, pytanie przestaje dotyczyć tego, czy reguła zadziałała, a zaczyna dotyczyć tego, który host wykonał żądanie. To inne śledztwo z innym właścicielem.

Tożsamość zmienia się wraz z adresowaniem

Dalsze połączenie zwykle uwierzytelnia się jako token sesji, zapisane poświadczenie lub konto usługi aplikacji, a zasób zapisuje to, co zostało mu podane. Dlatego ślad audytu pokazujący konto usługi w bazie nie dowodzi, że zapytanie wykonał człowiek. Nie identyfikuje też tego człowieka. Tylko własny dziennik sesji pulpitu łączy te dwa zapisy.

Autoryzacja odbywa się dwa razy, a druga decyzja jest podejmowana z innymi danymi wejściowymi. Pierwsza daje wskazanemu użytkownikowi logowanie do pulpitu, druga daje to, co token tego użytkownika lub konto aplikacji mogą zrobić z zasobem. Grupa pomocy technicznej, która może otworzyć pulpit, nie jest automatycznie grupą, która może czytać tabelę klientów.

Spójrz na token i ścieżkę delegowania, zanim napiszesz notatkę o dostępie. Oba są widoczne wewnątrz sesji i to jedyne miejsce, w którym odpowiedź nie jest domysłem.

whoami /groups
klist
query session

Jeśli aplikacja używa konta usługi, to jego uprawnienia liczą się dalej. Rotacja tych poświadczeń należy do przeglądu dostępu, a nie do późniejszej myśli operacyjnej.

Dlaczego ścieżka bezpośrednia jest nadal i słusznie zablokowana

Reguła odmowy nie jest błędna tylko dlatego, że do celu można dotrzeć inną drogą. Segmentacja jest oceniana według źródła, a pulpit znajduje się w segmencie, który został dozwolony długo przed tym, nim ktokolwiek pomyślał o nim jako o drodze do bazy. Nic nie ominęło polityki. Polityka po prostu opisuje dwa różne źródła z dwoma różnymi wynikami.

Przegląd musi odpowiedzieć, co może uruchomić każda autoryzowana sesja na tym hoście. Przeglądarki z zapisanymi sesjami, zmapowane dyski, agenci trzymający poświadczenia i usługi nasłuchujące lokalnie rozszerzają zasięg pulpitu, a żaden z nich nie pojawia się w zgłoszeniu, które dało logowanie. Ten wykaz to rzeczywista powierzchnia uprawnień.

Wymień je wewnątrz sesji testowej, a nie z arkusza kalkulacyjnego. Kilka poleceń pokrywa większość powierzchni.

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

Wybierz granicę świadomie

Trzy kształty pasują do różnych zadań, a wybór powinien podążać za zadaniem, a nie za narzędziem, które przypadkiem istnieje. Opublikowana aplikacja udostępnia jeden program z własnymi uprawnieniami, pełny pulpit udostępnia wszystko, co może zrobić profil użytkownika, a wąskie konto bazy z ograniczeniem źródła udostępnia jeden zasób całkowicie bez pulpitu. Najwęższy kształt, który nadal kończy pracę, jest tym, który należy udokumentować. Wszystko szersze wymaga uzasadnienia zapisanego obok.

Dla jednego raportu opublikowana aplikacja lub ograniczone konto to mniejsze upoważnienie niż ogólny pulpit. Dla utrzymania, które naprawdę wymaga kilku narzędzi, pulpit może być właściwy, ale wtedy zatwierdzenie opisuje cały host, a nie jedną aplikację. Zapytaj właściciela zasobu, na co z tego się zgadza.

Przepływ danych to osobny przełącznik. Schowek, przekierowanie dysków i pobierania mogą przenieść dane firmy do klienta, a uruchamianie aplikacji zdalnie samo w sobie nie utrzymuje danych zdalnie.

Sprawdź oba zatwierdzenia i ścieżkę usunięcia

Dwa zatwierdzenia należą do rekordu: prawo dotarcia do pulpitu i otwarcia go oraz prawo korzystania z zasobów od wewnątrz. Wskaż właściciela dla każdego z nich i utrzymuj drugie widoczne dla każdego, kto przegląda zasób. To o drugi wpis zapyta audytor, ponieważ opisuje zasięg, a nie wejście. Napisz oba przed zatwierdzeniem zmiany, a nie po pierwszym incydencie.

Następnie przetestuj usunięcie, ponieważ odłączona sesja może przeżyć swój powód. Tabela sesji to najszybsze miejsce, by zobaczyć, co jeszcze działa.

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

Odłączenie klienta pozostawia sesję zdalną uruchomioną, a jej połączenia sieciowe i buforowane poświadczenia mogą pozostać użyteczne, dopóki ta sesja się nie zakończy. Wyloguj się albo zakończ sesję jawnie, i potwierdź, że licznik poniżej przestaje się potem przesuwać. Test usunięcia, który tylko zamyka pokrywę laptopa, niczego nie dowodzi. Wykonaj ten sam test raz z wyłączonym kontem, a raz z odebranym uprawnieniem do pulpitu, po czym zapisz, co zasób zarejestrował w każdym przypadku.