IP 허용 목록과 승인된 노트북: 서로 다른 두 가지 통제

승인된 노트북만 연결할 수 있다는 규칙 요청은 흔히 사무실의 공용 주소에 대한 방화벽 항목으로 끝납니다. 그 규칙은 이제 그 주소 뒤에 있는 모든 기기를 허용합니다. 요구 사항과 구현은 같은 것이 아닙니다. 정책이 원하는 것과 주소가 증명할 수 있는 것을 분리하십시오.

하나의 정책 요청에 담긴 세 가지 질문

요청을 세 부분으로 나누십시오. 연결이 어디서 오는지, 어떤 서비스에 도달할 수 있는지, 어떤 컴퓨터가 자격 증명을 제시하는지입니다. 출처 주소 규칙은 첫 번째에 답하고, 목적지 서비스 규칙은 두 번째에 답합니다. 둘 다 물리적 기기를 식별하지 못합니다. 둘 다 많은 기기가 공유하는 네트워크 필드에서 동작하기 때문입니다. 세 번째는 해당 기기에 발급되어 조용히 재사용할 수 없는 자격 증명이 필요합니다.

세 가지 답을 따로 적으십시오. 방화벽 한 줄로는 세 가지를 지목하는 요구 사항을 충족할 수 없습니다.

출처 주소가 알려 줄 수 있는 것

주소 변환이 네트워크 출처 규칙이 지나치게 허용하는 흔한 이유입니다. 사무실 출구 하나 뒤의 모든 것이 같은 공용 주소로 보입니다. 그래서 규칙은 그룹 전체를 허용합니다. VPN 내부의 고정 주소도 다른 곳에서 같은 약점을 가집니다. 그것은 세션에 붙은 할당이며 하드웨어의 속성이 아닙니다. 수락된 자격 증명을 가진 기기라면 무엇이든 그 세션을 열 수 있습니다. 주소를 네트워크 제한으로 다루고 그렇게 설명하십시오.

그것은 노출을 제한하는 데 여전히 유용하며, 기기 인증은 아닙니다.

접근을 등록된 자격 증명에 묶기

요구 사항이 기기 제한이라면 VPN이 지원하는 기기별 등록을 사용하고 각 컴퓨터에 별도의 정체성을 부여하십시오.

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

저장소 목록은 인증서와 개인 키의 존재 여부를 보여 주고, 검증은 체인이 의도한 앵커로 이어지는지를 보여 줍니다. 인증서는 구성된 정책에 따라 수락된 개인 키의 보유를 증명합니다. 그러나 그 키를 내보내고 복사할 수 있을 때 어느 물리적 기기가 그것을 가졌는지는 증명하지 않습니다. 프로필을 노트북 이름으로 부르는 것은 비밀을 이전과 똑같이 옮길 수 있게 남깁니다. 플랫폼이 지원하는 곳에서는 하드웨어로 보호된 키와 증명 정책이 더 강한 결속을 제공하지만, 누가 자격 증명을 받을 수 있는지는 등록이 여전히 결정해야 합니다.

경계를 시험한 뒤 제거를 계획하기

두 경우를 평가하십시오. 승인된 노트북과 사용자는 연결되어야 하고, 사용자의 계정만 가진 다른 기기는 연결되지 않아야 합니다. 설계가 사용자와 기기 검사를 모두 요구한다면, 선택한 방법이 같은 세션에서 둘 다 적용하는지 확인하십시오. 두 개의 독립 설정이 결합된다고 가정하는 대신입니다.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

폐기는 수락된 기기 정체성을 제거해야 하며, 활성 세션 처리는 별도의 시험을 받을 만합니다. TPM이나 관리 기기 표시는 기기의 모든 프로세스에 대한 깨끗한 건강 증명서가 아닙니다.

네트워크 제한, 기기 자격 증명, 등록 결정을 세 명의 소유자와 함께 세 가지 통제로 기록하십시오. 그것이 경계를 검토 가능하게 만들며, 주소만으로는 결코 제공할 수 없는 것입니다.