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

클라이언트 연결을 끊어도 원격 세션은 계속 실행되며, 그 네트워크 연결과 캐시된 자격 증명은 세션이 끝날 때까지 사용 가능한 상태로 남을 수 있습니다. 로그아웃하거나 세션을 명시적으로 종료하고, 그 뒤 하위 카운터가 더 이상 진행하지 않는지 확인하십시오. 노트북 덮개만 닫는 제거 시험은 아무것도 증명하지 않습니다. 같은 시험을 계정을 비활성화한 상태에서 한 번, 데스크톱 권한을 제거한 상태에서 한 번 실행하고, 각 경우에 리소스가 무엇을 기록했는지 적으십시오.