직렬로 놓인 두 VPN 게이트: 각각이 실제로 무엇을 결정하는가
VPN을 두 단계 직렬로 두는 것은 두 개의 별도 권한 결정을 뜻해야 합니다. 각 게이트가 무엇을 확인하는지 이름 붙이고, 안쪽 게이트가 무엇을 거부하는지 시험하십시오.
두 VPN을 연결하는 일은 대개 추가 암호화로 팔리지만, 그것은 이 구성이 하는 가장 흥미롭지 않은 일입니다. 진짜 산출물은 다른 소유자가 다른 자원 집합에 대해 내리는 두 번째 인가 결정입니다. 두 단계가 같은 자격 증명을 받아들이고 같은 목적지에 도달한다면, 안쪽 게이트는 지연만 더하는 장식입니다. 그 두 번째 결정이 운영 비용을 감당할 만한지 판단하는 일은 각 게이트가 실제로 무엇을 검증하는지 이름 붙이는 데서 시작합니다.
하나의 터널, 그다음 두 번째 결정
바깥 게이트는 넓은 질문에 답합니다. 이것이 승인된 직원 기기이며 일반 내부 네트워크에 도달해도 되는가. 안쪽 게이트는 더 좁은 질문에 답합니다. 이 주체가 유지보수 권한을 가지며 이 특정 관리 엔드포인트에 도달해도 되는가. 이는 소유자가 다른 서로 다른 질문이며 어느 것도 다른 것을 함의하지 않습니다. 두 단계를 지나는 경로가 존재한다는 것은 두 번째 뒤에 있는 것을 쓸 권한이 아닙니다. 먼 입구에 도달한다는 것은 경로가 동작한다는 증거일 뿐 그 이상이 아닙니다.
원칙은 오래되었고 여전히 무시됩니다. 네트워크상의 위치는 그 자체로 아무것도 주장하지 않습니다. NIST 제로 트러스트 아키텍처 요약 은 이를 분명히 말하며, 연결이 어디서 왔는지 또는 누가 네트워크를 소유하는지에서 비롯하는 암묵적 신뢰를 거부합니다. 여기에 적용하면, 안쪽 입구에 도달하는 것은 그 자원의 전제 조건이며 결코 그것을 사용할 권한이 아닙니다.
각 게이트가 무엇을 검증하는지 적으십시오
각 단계마다 확인하는 주체, 허용하는 목적지, 건너뛸 수 있는 조건을 기록하십시오. 바깥 게이트는 일반 내부 서비스와 안쪽 게이트의 리스너만을 정당하게 허용할 수 있습니다. 안쪽 게이트는 역할 주장을 요구하고 변경 기록에 명시된 관리 주소만 허용할 수 있습니다. 먼 쪽의 응용 프로그램은 그 역할이 어떤 작업을 수행할 수 있는지에 대한 최종 발언권을 가지므로, 사슬은 응용 프로그램 인가를 대체하지 않고 게이트를 하나 더할 뿐입니다.
| Gate | Identity it checks | Destinations it permits | How it could be skipped | When it is removed |
|---|---|---|---|---|
| Outer gateway | Employee account plus a managed device posture | General internal services and the inner gateway's listener | Any alternate path to the same destinations, including a public listener | Ordinary work stops and the inner stage becomes unreachable |
| Inner gateway | A maintenance entitlement or role claim on that identity | The named management addresses in the change record | Direct routes from the outer domain to those addresses | Maintenance access ends while general access stays as it was |
두 가지 누락이 설계를 조용히 망칩니다. 바깥 도메인이 이미 모든 민감한 목적지에 직접 도달한다면, 안쪽 게이트는 필수가 아니라 선택입니다. 공개 리스너나 두 번째 전용 경로가 같은 접근을 제공한다면, 의도한 경로는 여러 선택지 중 하나일 뿐입니다. 각 규칙 집합에 소유자를 지정하고, 그 계약이 목적지 서비스, 허용된 출처 주체, 전용 DNS, 주소 변환, 그리고 인계가 실패할 때 누가 응답하는지를 명시하게 하십시오. 바깥 네트워크에서 신뢰되는 주소가 안쪽 도메인의 인가를 대신해서는 결코 안 됩니다.
거부 사례를 시험하고, 잘 풀리는 경로를 시험하지 마십시오
두 게이트를 통과하는 성공적인 연결은 거의 아무것도 증명하지 못합니다. 그것은 배포 때 모두가 시험한 사례이기 때문입니다. 흥미로운 사례는 한 단계는 통과하고 다른 단계는 거부하는 경우입니다. 그중 세 가지가 위험의 대부분을 덮으며, 각각은 논쟁이 아니라 확인할 수 있는 기대 결과를 가집니다.
일반 접근이 승인되고 민감한 역할이 없을 때, 민감한 목적지가 거부되는 동안 일반 업무는 계속되어야 합니다. 두 단계를 모두 승인하면 도달 가능한 집합은 변경 기록에 명시된 유지보수 엔드포인트여야 하며 그보다 넓어서는 안 됩니다. 세션 도중 권한이 철회되면 합의된 세션 정책이 무관한 일반 접근을 끊지 않고 발효되어야 합니다. 그 철회가 기존 세션을 즉시 끝내는지 다음 재인증 때 끝내는지는 계약에 이미 있어야 할 정책 결정입니다. 승인 사례를 쓴 사람은 사고 중에 그것을 해석할 사람이 아닙니다.
curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"
추가한 의존성을 세십시오
추가 단계마다 고장 날 수 있는 구성 요소와 바깥 터널 안에 올바로 중첩되어야 하는 경로가 하나씩 늘어납니다. 부분 고장 동안 바깥 경로는 살아 있지만 안쪽은 도달할 수 없으므로, 사용자는 결코 응답하지 않는 서비스 옆에서 정상 VPN 아이콘을 봅니다.
정상 상황만이 아니라 고장 상황에서 경로와 차단 규칙을 확인하십시오. 바깥 터널이 밀어 넣은 기본 경로가 안쪽 게이트 자체의 주소를 잡을 수 있고, 그러면 두 번째 단계는 연결이 맺어진 뒤 끊어지는 것이 됩니다. 안쪽 터널이 없을 때 무엇이 차단된 채로 남아야 하는지 기록하십시오. 그 주위의 우발적 폴백은 깔끔한 중단보다 나쁩니다. 두 홉에 같은 점검 형태를 써서 각각을 가정이 아니라 측정하십시오. 연결됨 표시 두 개는 중첩도 격리도 증명하지 않습니다.
두 번째 게이트가 사 줄 수 없는 것
두 게이트가 자격 증명, 인증 기관, 관리 평면을 공유하는지 물으십시오. 공유한다면 가장 중요한 고장 모드도 공유하며, 두 번째 단계는 겉보기에 더하는 독립성보다 비용이 큽니다. 별도의 암호 세션은 별도의 관리 통제를 만들지 않습니다.
안쪽 게이트는 바깥 도메인이 결코 확인하지 않는 역할처럼, 말하고 시험할 수 있는 요구를 강제하는 동안 유지하십시오. 같은 주체를 같은 목적지에 다시 인증하는 일만 남으면 없애십시오. 어느 쪽이든 요구, 소유자, 고장 시 동작을 함께 기록하여 다음 검토가 그림이 아니라 요구를 논하게 하십시오.