VPN에서 VLAN으로의 접근: 규칙보다 먼저 매트릭스를 만드세요
한쪽에 역할, 다른 쪽에 서비스. 다섯 가지 점검이 모호한 VPN-VLAN 접근 설계를 방화벽 담당자가 구현할 수 있는 표로 바꿉니다.
방화벽 문법이 아니라 매트릭스에서 시작하세요. 한쪽에 역할, 다른 쪽에 서비스가 있는 표는 애플리케이션 담당자가 검토하고 보안 담당자가 논의하며 게이트웨이를 가진 누구든 구현할 수 있습니다. 그 검토가 아무도 합의하지 않은 규칙을 디버깅하는 것보다 쌉니다.
한 시간의 작성이 나중에 일주일치 규칙 고고학을 아낍니다. 설계는 누가 어느 서비스에 도달하는지를 말하며, 번호 재부여 후에도 살아남는 부분이 바로 그것입니다.
1단계: 네트워크보다 역할을 먼저 이름 붙이기
스위치가 아니라 사람에서 시작하세요. 원격으로 접속하는 각 그룹과 그 그룹이 무엇을 하는지 설명하는 한 문장을 적으세요. 예를 들어 재고 수준을 읽는 창고 직원이나 하나의 통합을 유지하는 계약자이며, 두 그룹이 같은 접근을 받게 된다면 이 목적에서는 하나의 역할입니다.
역할이 조직도 때문에만 존재한다면 여기서 멈추세요. 고유한 서비스 필요가 없는 역할은 동일한 셀의 행이 되고, 동일한 행은 나중에 편의를 위해 전체 서브넷을 내주도록 누군가를 부추깁니다. 사람들이 하는 일로 나누고, 누가 그들의 지출에 서명하는지로 나누지 마세요. 작은 사무실에는 여섯 개의 역할이 보통 너무 많고 세 개가 흔히 맞습니다.
2단계: 각 셀을 서비스 진술로 바꾸기
«애플리케이션»이라고 적힌 셀은 검증할 수 없지만 «직원 풀에서 443 포트의 ERP 호스트로 HTTPS»라고 적힌 셀은 검증할 수 있습니다. 모든 네트워크 이름을 목적지, 프로토콜, 포트로 바꾸고, 서비스가 없으면 작동하지 않는 의존성을 추가하세요. 내부 리졸버나 ID 공급자 같은 것입니다.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
방향 열이 가장 비싼 실수를 잡습니다. 직원이 애플리케이션을 여는 권한이 애플리케이션 서버가 직원 노트북으로 되돌아가는 연결을 여는 권한을 뜻하지는 않으며, 첫 번째 방향을 허용하는 상태 저장 규칙은 흔히 두 번째도 허용하는 것으로 읽힙니다.
3단계: 아이덴티티가 정책이 되는 지점 정하기
누군가는 인증된 세션을 게이트웨이가 적용할 수 있는 역할로 바꿔야 합니다. 지원되는 옵션에는 인증 백엔드가 제공하는 그룹 정책, 신뢰할 수 있는 세션 속성, 역할별로 분리된 주소 풀이 있습니다. 세 가지 모두 작동하지만 클라이언트가 보내는 레이블은 작동하지 않습니다. 포럼 게시물이 설명하는 방식이 아니라 게이트웨이가 문서화하는 방식을 고르세요.
VLAN에 속한 것처럼만 보이는 주소를 할당하는 것은 다른 옷을 입은 같은 무응답입니다. OpenVPN 방화벽 규칙에 관한 Netgate 안내서는 그 분리를 분명히 하며, 터널이 올라오게 하는 것과 그 안으로 트래픽이 지나가게 하는 것은 다른 결정입니다.
어떤 방식을 골랐고 어디에 설정되어 있는지 적어 두세요. 역할이 바뀔 때 그 메모가 한 번의 편집과 세 인터페이스를 뒤지는 수고의 차이입니다. 또한 감사자에게 먼저 어디를 봐야 하는지 알려 줍니다.
4단계: 목적지가 보는 출발지 주소 관찰하기
포워딩 정책은 경계에서 실제 출발지와 일치해야 합니다. 게이트웨이가 VPN 클라이언트를 자기 주소로 변환하면, 하위의 모든 방화벽은 하나의 출발지만 보게 되고 역할별 결정 능력을 잃습니다. 클라이언트 주소를 보존하면 그 풀에 대한 반환 경로가 있어야 합니다.
최종 규칙을 작성하기 전에 양방향을 시험하고, 관찰된 출발지를 각 셀 옆에 기록하세요. 같은 점검을 두 개의 다른 역할에서 실행해 결과를 비교하세요. 둘 다 게이트웨이 주소를 보여 준다면 역할 구분은 이미 사라진 것입니다. 게이트웨이가 출발지 변환을 하는데 주소가 보존된다고 가정한 매트릭스는 첫 하위 ACL에서 실패합니다.
5단계: 배포 전에 각 셀 시험하기
허용된 각 셀을 하나의 대표 작업으로, 거부된 각 셀을 부정 사례로 바꾸세요. 둘 다 시험하는 경로를 우회하는 게이트웨이 콘솔이 아니라 실제 역할의 클라이언트에서 실행하세요.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'연결되는 부정 사례는 우연이 아니라 발견이며, 규칙이 고쳐질 때까지 매트릭스에서 실패한 셀로 남아야 합니다. 시험 명령을 표 옆에 두어 다음 검토자가 추론을 다시 세우지 않고 다시 실행하게 하세요.
완성된 표는 그것이 쓰인 게이트웨이보다 오래갑니다. 규칙은 펌웨어와 공급업체에 따라 바뀌지만, 계약자가 하나의 프로젝트 서비스에 도달한다는 행은 그 작업이 바뀔 때까지 참으로 남습니다.