개인 VPN에 연결된 업무용 노트북: 실제로 무엇이 건너가는가

회사 노트북을 가정용 VPN에 연결하면 동시에 두 곳에 존재하게 되며, 흥미로운 질문은 불안을 부르는 질문보다 작고 유용합니다. 사무실과 집 사이에 누가 이더넷 케이블을 깐 것도 아니고, 어떤 경로도 가정 네트워크를 회사 서브넷의 확장으로 만들지 않습니다. 존재하는 것은 두 환경에 모두 접근할 수 있는 하나의 엔드포인트이며, 그 사이에서 실제로 무엇이 이동할 수 있는지는 세 가지 별개의 메커니즘이 결정합니다. 이 세 가지를 엔드포인트에서 바깥으로 따라가면 라벨에 대한 논쟁 대신 관리자가 행동할 수 있는 답이 나옵니다.

네트워크 다이어그램이 아니라 엔드포인트에서 시작하십시오

엔드포인트는 두 연결이 만나는 지점이므로 검토도 그곳에서 시작합니다. 어떤 프로세스가 돌아가고, 어디까지 닿을 수 있으며, 누가 그것을 통제하는가. 노트북에 연결된 두 개의 클라우드를 보여 주는 다이어그램은 정확하지만 도움이 되지 않습니다. 존재하지 않을 수도 있는 연결을 암시하기 때문입니다. 대신 각 환경과 대화할 수 있는 애플리케이션 목록으로 바꾸고, 각각이 어떤 계정으로 실행되는지 적어 두십시오. 이 틀은 검토의 균형도 유지합니다. 터널 두 개가 있는 노트북은 연결된 두 네트워크와 같은 대상이 아니기 때문입니다.

그 목록이 나머지 검토가 기대는 인벤토리입니다. 동기화 클라이언트, 두 환경에 로그인된 브라우저 프로필, 자격 증명을 가진 빌드 에이전트가 들어 있다면 검토에는 이미 대상이 있습니다.

세 가지 교차 지점, 따로 검토

애플리케이션 접근이 첫 번째 교차 지점이며 어떤 포워딩도 필요하지 않습니다. 엔드포인트의 브라우저 탭, 동기화 클라이언트, 빌드 에이전트는 한 환경의 리소스에서 읽고 다른 환경의 리소스로 데이터를 보낼 수 있습니다. 이 능력은 운영체제가 인터페이스 사이에서 패킷을 포워딩하는지와 무관하게 존재하며, 다리가 없으면 위험도 없다고 결론지을 때 사람들이 놓치는 메커니즘이 바로 이것입니다. 따라서 인터페이스 목록을 읽는 것보다 애플리케이션 목록을 읽는 편이 더 많은 정보를 줍니다.

정체성과 데이터가 두 번째 교차 지점을 이룹니다. 회사 자격 증명, 세션 쿠키, 내려받은 문서, 관리 권한은 엔드포인트에 있고, 다른 네트워크에 연결한다고 해서 그것들이 저절로 드러나지는 않습니다. 달라지는 것은 그 자격 증명을 보유한 동안 엔드포인트에 영향을 줄 수 있는 당사자의 집합이며, 이는 라우팅이 아니라 개인 네트워크의 신뢰성에 관한 질문입니다. 이는 엔드포인트 소유자가 혼자 내릴 수 없는 판단이고, 포워딩 규칙이 없다는 사실이 답이 되지도 않습니다.

네트워크 포워딩이 세 번째이며, 노트북을 중계 장치로 바꿀 수 있는 유일한 것입니다. IP 포워딩, 인터넷 연결 공유, 프록시, 브리징 기능이 각각 그렇게 할 수 있고, 각각은 켜져 있거나 꺼져 있는 설정입니다. VPN 클라이언트의 존재로 추정하지 말고 그 상태를 직접 확인하십시오. 관리되는 기기에서는 답이 보통 아니요이며, 확인하면 가정이 기록할 만한 사실이 됩니다.

두 개의 네트워크가 아니라 하나의 리소스를 요청하십시오

대부분의 실제 요구는 처음 보이는 것보다 좁습니다. 콘솔 하나, 파일 공유 하나, 내부 웹 애플리케이션 하나. 요구를 그렇게 진술하고, 그것이 이 엔드포인트에 속하는지 리소스 소유자가 결정하게 하십시오. 두 네트워크를 결합하는 형태의 요청은 승인하기 어렵고 거절하기 쉽습니다. 이름 붙인 서비스 하나에 대한 요청에는 답이 있습니다.

답이 예라면 지원되는 가장 좁은 경로를 선호하고 조직의 기존 통제 안에 두십시오. 관리되는 두 번째 프로필이나 범위가 제한된 애플리케이션 항목은 모니터링과 정책을 유지합니다. 경쟁하는 개인 설정은 그것들을 조용히 대체하며, 다음 업데이트 후에 어느 쪽이 이기는지 아무도 모릅니다.

DNS와 경로 영향을 포함하십시오

두 번째 프로필이 활성화되는 순간 이름 확인이 달라집니다. 개인 클라이언트가 자체 리졸버를 밀어 넣을 수 있고, 브라우저가 자체 암호화 DNS를 쓸 수 있으며, 정책 테이블이 내부 이름을 회사 구성이 기대하는 것과 다른 서버로 보낼 수 있습니다. 어느 것도 포워딩을 필요로 하지 않으며, 어느 것이든 내부 호스트 이름을 잘못된 곳으로 보낼 수 있습니다.

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

두 번째 프로필이 연결되기 전과 후에 그 세 가지 출력을 캡처하십시오. 그 차이가 실제로 사용자에게 도달하는 효과이며, 티켓이 설명하는 라우팅 변경보다 큰 경우가 많습니다. 두 캡처를 모두 보관해 나중 검토자가 의도가 아니라 무엇이 바뀌었는지 보게 하십시오.

검증하고 나가는 길을 남기십시오

승인된 애플리케이션은 같은 기기의 관리자 셸이 아니라 실제 프로세스와 사용자 컨텍스트에서 시험하십시오. 그다음 설계가 요구하는 곳에서 무관한 목적지가 여전히 도달 불가능한지 확인하십시오. 아무도 시험하지 않은 경계는 아무도 주장할 수 없는 경계입니다. 개인 터널을 끊으면 이전 상태가 복원되어야 하며, 그 복원은 누군가 아직 지켜보는 동안 확인할 가치가 있습니다.

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

제로 트러스트 아키텍처에 관한 NIST 지침은 여기서 유용합니다. 네트워크 위치를 자동적인 신뢰의 원천에서 제거하기 때문이며, 그것이 바로 문제가 되는 가정입니다. 질문은 가정 네트워크가 본래 신뢰할 만한가가 아니라, 누가 어떤 리소스에 어느 엔드포인트에서 어느 시행 지점을 통해 닿을 수 있는가입니다. 이 세 가지에 답하고, 판단과 함께 증거를 남기십시오.