VPN 장치 상태 검사가 차단하지 않나요? 먼저 보고서를 따라가세요

몇 주 전부터 백신 서명 업데이트가 멈춘 노트북이 여전히 내부 앱을 열 수 있다면, 잘못된 것은 대개 정책 문서가 아니다. 접근이 거부되기 전에 세 개의 별개 시스템이 합의해야 한다. 무언가가 엔드포인트를 측정하고, 무언가가 그 측정을 허용 또는 거부 판정으로 바꾸고, 무언가가 실제로 트래픽을 떨어뜨린다. 비준수 장치가 그래도 들어온다면 그 연결고리 중 정확히 하나가 없거나 믿지 말아야 할 증거를 믿고 있다. 아래 점검은 그 순서대로 진행되며 각각 멈출 지점이 있다.

차단은 첫 단계가 아니라 마지막 단계다

인증과 장치 상태는 서로 다른 질문에 답한다. 로그인 성공은 자격 증명이 제시되었다는 것만 증명하며, 그것을 제시한 기계에서 무엇이 도는지는 말해 주지 않는다. 이 틈 때문에 복사한 클라이언트 프로필이 건강해 보이는 세션을 건강하지 않은 호스트로 옮길 수 있다.

엔드포인트 준수 작업에는 이미 이 사슬을 위한 어휘가 있다. RFC 5209의 NEA 참조 모델은 작업을 수집기, 평가 단계, 적용 지점으로 나누고, 자기 상태에 대해 거짓말하는 클라이언트는 모델 밖에 있다고 분명히 말한다. 이 단서가 도식보다 중요하다. 신뢰된 플랫폼 모듈은 스스로 보고한 측정을 사실로 만들지 않는다.

수집기가 범위에 대해 정직하도록 하라. 정책이 이름 붙인 속성을 접근을 요청하는 장치에서 보고해야 하며, 그 밖의 것은 거의 보고하지 않아야 한다. 설치된 모든 패키지를 나열하는 자산 에이전트는 상태 수집기와 다른 도구이고, 그 차이는 보존과 정확성의 문제이기도 하다. 보고서를 하나의 장치 정체성에 묶을 수 없다면, 평가자는 방금 어느 기계를 통과시켰는지 추측하고 있는 것이다.

빨간 상태를 보여 주는 대시보드는 통제가 아니다. 거부된 사용자가 여전히 무엇에 닿을 수 있는지 물어라. 위키, 파일 공유, 데이터베이스 포트는 어떤가. 교정에는 좁은 표면 하나가 필요하고, 나머지는 모두 차단 뒤에 두어야 한다.

규칙을 읽기 전에 보고서를 읽어라

클라이언트의 초록 체크가 아니라 원천에서 시작하라. Windows에서 로컬 측정은 Defender나 Security Center에 스스로 등록한 제품에서 오며, 둘 다 공급업체 콘솔 없이 읽을 수 있다:

Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState

두 번째 명령은 productState이라는 정수를 돌려준다. 그 비트는 느슨하게 문서화되어 있고 공급업체마다 활성화와 최신성 플래그를 다르게 묶으므로, 해석하기보다 확인하라. 서드파티 제품군은 제거 후에도 Security Center 항목을 남기며, 그것은 디스크에 더 이상 없는 소프트웨어를 보고한다.

사람들이 건너뛰는 항목은 나이다. 서명 타임스탬프는 평가를 수행하는 기계의 시계에 비추어야만 의미가 있으므로, 눈대중으로 어림하지 말고 간격으로 환산하라:

$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours

이제 정책에는 읽을 숫자가 하나 있다. 규칙이 72시간이라고 말한다면 그것이 쓰는 숫자이고, 일주일 잠든 노트북은 누구도 라벨을 해석하지 않아도 실패한다. 임계값은 명령 옆에 적어 두어라. 엔드포인트 도구가 교체되면 둘은 서로 어긋난다.

각 장치 상태를 서면 판정으로 바꿔라

상태를 둘러싼 분쟁의 대부분은 사실 알 수 없는 행에 대한 분쟁이다. 첫 사고 전에, 증거와 판정과 소유자를 지목하는 표 안에서 결정하라. 그러면 아무도 게이트웨이 콘솔에서 즉흥적으로 처리하지 않는다.

제품이 갈리는 곳은 맨 아래 행이다. 어떤 게이트웨이는 연결을 거부하고 이유를 설명하며, 다른 것은 터널을 올린 채 제한 정책을 적용하고, 몇몇은 마지막으로 알려진 정상 보고서로 되돌아간다. 방어할 수 있는 것은 처음 둘뿐이며, 자기 것이 어느 쪽인지 시험해 볼 가치가 있다.

정체성과 권한도 각자의 차선에 두어라. 모든 상태 시험을 통과한 노트북도 앱에 대한 올바른 사람 승인이 필요하고, 장치 인증서는 키의 보유를 증명할 뿐 파일 시스템의 상태를 증명하지 않는다. 셋을 하나의 불리언으로 뭉개면 헬프데스크 계정이 운영 환경에 상시 접근 권한을 얻는다.

적용 경로는 대시보드가 아니라 요청으로 확인하라

적용은 요청의 속성이므로 요청 하나로 측정하라. 비준수 기계를 터널에 올리고 실제 사용자가 할 호출을 하라:

curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health

차단되어야 할 장치에서 200이 온다면 판정이 데이터 경로에 도달하지 않은 것이다. 흔한 원인은 둘이다. 정책이 시험 계정이 가입한 적 없는 그룹에 붙어 있거나, 앱이 VPN이 소유하지 않은 경로로 닿는다.

먼저 라우팅 가정을 확인하라. 내부 이름이 클라이언트가 이미 로컬 LAN으로 닿는 주소로 해석된다면 터널은 무관하고 어떤 정책도 적용되지 않는다. 그 주소를 게이트웨이가 밀어 넣는 경로와 비교하라. OpenVPN에서는 클라이언트별 정책이 공통 이름으로 키가 지정된 파일에 살므로 확인이 쉽다:

ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17

disable이 들어 있는 파일은 그 클라이언트를 완전히 끊고, push "route ..." 행은 닿을 수 있는 범위를 좁힌다. 둘 다 적용이며, 둘 다 보고서를 디버그하는 사람에게 보인다.

네 가지 경우를 시험 계정 하나에서 시험하라

마지막 확인은 작은 행렬이지 순조로운 길이 아니다. 시험 계정 하나를 네 상태로 통과시켜라. 최신, 만료된 서명, 보호 해제, 에이전트 미설치. 각각에 대해 판정을 평가 로그에, 앱이 돌려주는 HTTP 상태를, 교정 페이지가 로드되었는지를 기록하라.

foreach ($case in 'current', 'stale', 'disabled', 'absent') {
  Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
  curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}

놓치기 쉬운 세부가 둘 있다. 먼저 재생은, 기계가 건강할 때 잡은 보고서를 같은 장치의 이후 세션에 받아들여서는 안 되므로 현재 연결에 묶인 타임스탬프를 찾는 일이다. 다음 제거는, 에이전트를 지우면 오래된 보고서와 같은 거부가 나와야 하고 그냥 통과하면 안 된다. 바로 이 경우가 가장 자주 시험되지 않는다.

행렬이 표와 맞으면 다음에 게이트웨이를 운영할 사람에게 명령과 임계값과 기대되는 네 가지 결과를 넘겨라. 이 인계가 진짜 산출물이다. 정책 문서 안에서만 사는 상태 설계는 엔드포인트 도구가 보고 필드를 바꾸는 첫 순간에 어긋난다.