필드 장치의 TLS와 VPN: 어느 경계가 무엇을 지키는가

필드 장치가 서비스로 연결을 열면 설계 질문은 VPN과 TLS 중 무엇을 고르냈냐로 다가옵니다. 그러나 이 틀은 틀렸습니다. 둘은 서로 다른 일을 합니다. TLS는 애플리케이션 종단점을 인증하고 대화를 보호하며, VPN은 도달 가능성을 제어하고 피어 사이의 패킷을 보호합니다. 장치에서 바깥으로 연결을 따라가면 각 계층마다 나름의 답이 있습니다.

TLS가 어디서 종료되는지 말할 수 없다면 애플리케이션이 실제로 무엇을 신뢰하는지도 말할 수 없습니다.

TLS가 실제로 어디서 종료되는지 찾아내기

장치의 애플리케이션에서 시작해 핸드셰이크를 완료하는 프로세스까지 연결을 따라갑니다. 프록시가 메인프레임 앞에서 TLS를 종료한다면 보호 경로는 프록시에서 끝납니다. 남은 구간에는 자체적인 문서화된 보호가 필요합니다.

이를 가정으로 종단 간이라고 부르는 것이 바로 설계 검토가 빈틈을 승인하는 방식입니다. 종료 지점과 신뢰 기준점을 같은 도면에 그리십시오.

TLS는 요청과 응답을 양방향으로 나르므로 양방향 애플리케이션이 본질적으로 TLS 대신 VPN을 필요로 하지는 않습니다. 반대도 참입니다. 같은 장치의 다른 프로토콜 때문에 배포에 여전히 VPN이 필요할 수 있습니다.

장치가 무엇을 인증해야 하는지 정하기

서버 신원 검증과 의도한 신뢰 루트를 구성합니다. 각 장치가 자체 신원을 증명해야 한다면 지원되는 클라이언트 인증 모델을 선택하고 장치마다 별도의 자격 증명을 등록하십시오. 공유 자격 증명은 장치 한 대의 도난을 전체 함대의 문제로 만듭니다.

출하 전에 키 보호, 갱신, 폐기, 복구를 계획하십시오. 갱신 실패 후 재등록할 수 없는 현장 장치는 현장 방문이 되고, 그 비용이 핸드셰이크보다 설계를 더 많이 형성합니다.

지원되는 라이브러리와 최신 지침을 사용하십시오. 현대적 TLS 배포 지침은 TLS 1.0과 1.1의 협상을 금지하며, 오래된 설계 메모의 TLSv1 언급은 요구 사항이 아닙니다.

핸드셰이크가 실패하면 닫기

실패한 핸드셰이크나 신원 확인이 조용히 원래의 평문 프로토콜로 되돌아가서는 안 됩니다. 그 폴백이야말로 TLS 작업이 막아야 했던 취약점입니다. 실패를 장치 운영자와 서비스에 보이게 하고, 민감한 작업에는 보호된 채널을 요구하십시오. 그다음 인증된 장치가 무엇을 할 수 있는지는 애플리케이션 인가가 결정하게 하십시오.

연결 수명, 프레임, 타임아웃, 재시도 동작을 계약의 일부로 정의하십시오. 암호화는 반복 명령을 안전하게 만들지 않으며, 불확실한 이전 작업 후의 재시도에는 애플리케이션 수준의 답이 필요합니다.

폴백 규칙을 적어 두십시오. “핸드셰이크가 실패하면 TLS 없이 다시 연결한다”는 설계 결정이며 분명해야 합니다.

VPN에는 할 수 있는 일만 맡기기

VPN은 도달 가능성을 제한하고 자신의 피어까지 패킷을 보호할 수 있습니다. TLS는 선택한 종단점과 애플리케이션의 관계를 보호합니다. 둘의 종료 지점은 다를 수 있고, 어느 쪽도 종단점의 저장 데이터나 관리 접근을 보호하지 않습니다.

한 메커니즘이 더 빠르다고 가정하지 말고 실제 장치에서 핸드셰이크 비용, 정상 상태 메시징, 재연결을 측정하십시오. 그다음 중요한 네 가지 경우를 시험하십시오. 의도한 교환, 잘못된 서버 신원, 권한 없는 장치, 불확실한 작업 후의 재연결입니다. 각 경우의 결과를 장치가 표시하는 오류까지 포함해 기록하십시오.