멀티테넌트 VPN: 공유 게이트웨이, 테넌트별인가 호스트별인가

누가 고객을 수용하고 무엇이 그 고객이 다른 테넌트의 리소스에 도달하지 못하게 하는지 결정합니다. 이는 두 가지 결정이며, IPsec, WireGuard, 메시 제품 중 무엇을 고르든 둘 다에 답하지 않습니다. 완벽하게 올라오는 터널도 모든 테넌트가 서로에게 도달할 수 있는 상태를 남길 수 있고, 둘을 같은 것으로 취급하는 검토는 잘못된 설계를 승인합니다. 먼저 고객-리소스 지도를 작성합니다: 관리자, 지원 접근, 공유 서비스, 그리고 계속 거부되어야 하는 경로입니다.

제품이 아니라 지도에서 시작합니다

그 지도가 첫 산출물이며, 아래의 모든 선택은 그것을 강제하는 경계가 어디에 있는지에 대한 결정일 뿐입니다. 검토 가능하게 유지합니다: 고객마다 한 행, 공유 서비스마다 한 행, 거부 경로는 명시합니다.

아무도 읽을 수 없는 지도는 아무도 강제하지 않을 지도입니다.

하나의 수용 지점과 그 매핑 문제

각 배치는 하나의 운영상 질문으로 결정되며, 표가 비교의 전부입니다.

공유 게이트웨이는 수용을 중앙화하고 위험을 한곳에 모읍니다: 즉 테넌트 ID와 그 정책 사이의 연결입니다. 그룹이나 터널 주소는 올바른 리소스 권한으로 해석되어야 합니다, 그리고 고객마다 다른 레이블을 붙이는 것만으로는 아무것도 막지 못합니다. 분리된 라우팅 컨텍스트는 플랫폼이 지원하고 설계가 완전할 때 겹치는 프리픽스를 담을 수 있습니다. 단순한 공유 라우팅 테이블은 뒤에 있는 사람들이 다른 계정을 가졌다는 이유만으로 동일한 목적지 프리픽스 두 개를 구분할 수 없습니다.

대부분의 설계에서 이것이 시험입니다. 내부적으로 10.0.0.0/8로 번호를 매기는 두 테넌트에는 명명 규칙이 아니라 분리된 라우팅 상태가 필요합니다.

테넌트별 게이트웨이는 경계와 시스템을 삽니다

고객마다 게이트웨이 하나를 두면 그 고객의 수용과 정책이 함께 있으므로 일부 관리 경계를 설명하기 쉬워집니다. 반면 자격 증명, 패치, 모니터링, 소유자가 필요한 시스템을 배로 늘립니다. 그리고 특정한 공인 주소 배치를 강요하지 않습니다: 엔드포인트 공유, 변환, 프로토콜 역다중화는 구현이 실제로 지원하는 것에 달려 있습니다.

보안 이득을 세기 전에 시스템과 사람을 셉니다. 팀이 패치할 수 있는 것보다 게이트웨이가 네 개 더 많은 설계는 실제로 더 격리되지 않습니다.

테넌트 수가 매달 움직인다면 그 모델에는 템플릿이 아니라 자동화 이야기가 필요합니다.

호스트별 연결은 작업을 옮깁니다

호스팅되는 각 머신의 연결은 운영 작업을 없애지 않고 머신의 수명 주기로 옮깁니다. 등록, 머신별 정책, 키 회전, 교체가 모두 프로비저닝의 일부가 되고, 머신 자체와 같은 창에서 실패합니다. 서로 다른 네트워크의 몇 안 되는 장수 호스트에는 흔히 맞고, 어떤 이미지가 어디서 도는지 이미 놓친 함대에는 드뭅니다.

각 선택지에서 ID 발급, 업데이트, 접근 제거, 모니터링, 복구의 역할을 지정합니다. 그다음 한 고객이 떠나는 날 무슨 일이 일어나는지 묻습니다.

폐기는 비교에 포함됩니다

대부분의 비교는 폐기를 건너뜁니다. 테넌트를 제거하면 그 자격 증명을 무효화하고, 정책을 버리고, 주소와 라우팅 상태를 해제하며, 나머지 모두는 건드리지 않아야 합니다. NIST의 제로 트러스트 아키텍처 지침이 여기서 올바른 참조인 것은, 네트워크 위치를 신뢰하는 대신 인증과 권한 부여를 리소스에 두기 때문이며, 이는 고객 자신의 세그먼트 안에서도 적용됩니다.

프로토콜 벤치마크를 재기 전에 허용·거부 흐름, 겹치는 주소 처리, 폐기 절차를 재어 봅니다. 그다음 선택한 경계에 맞는 전송과 인증 방식을 고릅니다. 오래된 제품 이름이나 모든 기업이 하나의 프로토콜로 표준화해야 한다는 주장은 그중 어느 것도 결정하지 못합니다. 먼저 쓴 지도가 결정합니다.