VPN을 통한 NAS 관리: 이름은 유지하고 공용 포트는 버리기
관리 페이지에는 터널로 접근하고 새 공용 포트를 열지 마십시오. 실제 이름을 확인하고 인증서를 거기에 맞추며 하나의 출처에서 하나의 서비스만 허용하십시오.
NAS 관리 페이지는 집에서는 작동하지만 관리자가 여행을 떠나는 순간 작동을 멈추므로, 누군가 포트를 열고 문제는 프라이버시와 함께 사라집니다. 여기에는 더 나은 형태가 있습니다. 페이지는 있던 자리에 두고 도달성은 터널이 제공하게 하며, 문서화하는 대상을 우연히 응답하는 장치 주소가 아니라 이름이 붙은 권한 경로를 가진 완전한 URL로 만드십시오. 아래의 모든 결정은 이름에서 인증서, 그리고 유일하게 허용된 포트에 이르기까지 그렇게 쓰는 데서 나옵니다.
설계 단위는 주소가 아니라 URL입니다
진입점을 포트와 스킴을 포함한 완전한 URL로 쓰고, 이어서 누가 사용할 수 있는지, 어느 네트워크에서, 어느 경로로인지 조건을 붙이십시오. 예를 들어 승인된 사설 클라이언트에만 게시되는 https://nas.corp.example:8443 가 있을 수 있으며, 이름과 포트는 장치가 실제로 수신하는 대상을 대표합니다.
그 틀은 결정을 이르게 강제합니다. URL은 이름을 함의하고, 이름은 인증서를 함의하며, 인증서는 신뢰 배치를 함의합니다. 주소는 그중 어느 것도 함의하지 않으며, 바로 그렇기 때문에 주소만 쓰는 방식은 첫 브라우저 경고까지 버티다가 그것을 클릭해 넘어가는 습관이 됩니다.
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
인증서가 발급된 이름을 유지하십시오
클라이언트에는 NAS의 사설 주소로 가는 허용된 경로가 필요하고, 사설 DNS 구성은 HTTPS 서비스가 기대하는 이름을 유지하면서 의도한 호스트 이름을 그 주소로 확인할 수 있습니다. 두 절반 모두 중요하며, 경로는 패킷을 그곳으로 보내고, 이름은 클라이언트에 어느 신원을 검증할지 알려 줍니다.
대신 숫자 주소를 입력하면 신원 요구가 달라집니다. RFC 9525는 클라이언트가 접속하려는 이름과 서비스가 제시하는 신원을 분리하므로, nas.corp.example 에 대해 발급된 인증서는 브라우저가 10.20.0.15 을 가리켰을 때 정당하게 실패할 수 있습니다. 경고는 옳고, 해결책은 예외가 아니라 이름입니다.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.example터널을 탓하기 전에 둘 다 실행하십시오. 첫 번째는 사설 이름이 생각하는 곳에서 확인되는지 보여 주고, 두 번째는 서비스가 실제로 어떤 인증서와 어떤 주체 대체 이름을 제시하는지 보여 줍니다. 사설 CA는 충분히 잘 관리된 선택일 수 있지만, 일상이 되어서는 안 되는 것은 사람들에게 신원 경고를 무시하도록 가르치는 일입니다.
관리 경로를 제한하십시오
게이트웨이와 NAS 양쪽에서 의도한 출처로부터 정확히 관리 서비스만 허용하십시오. 그 문장에는 물어뜯는 세부가 숨어 있으며, 라우팅된 클라이언트 풀과 출처 변환을 하는 게이트웨이는 서로 다른 출처 주소로 NAS에 도착하므로, 한쪽을 위해 쓴 허용 규칙은 다른 쪽에서 조용히 실패합니다.
NAS에는 반환 경로도 필요하고, 브라우저는 포럼 게시물에서 가져온 벤더 기본값이 아니라 설정된 포트와 스킴을 사용해야 합니다. 장치에 도달하는 것은 그 장치의 모든 포트에 도달할 권한이 아닙니다. 핑에 응답하는 장치와 로드되는 관리 페이지 사이의 간격은 두 개의 별개 규칙 사이의 간격입니다. 두 개의 주석이 달린 두 규칙으로 쓰면 다음 사람이 둘 다 왜 존재하는지 볼 수 있습니다.
VPN 입장과 NAS 권한을 분리하십시오
터널을 통과하도록 허용되는 것과 장치를 관리하도록 허용되는 것은 같지 않습니다. 파일 저장이 정당하게 필요한 사용자가 둘 다 하나의 게이트웨이 뒤에 있다는 이유로 장치 관리를 물려받아서는 안 되며, NAS의 계정 모델이 그 분리를 강제해야 하는 곳입니다.
공유되거나 변환된 출구 주소도 개별 관리자를 식별할 수 없습니다. 감사 기록이 사람을 지목해야 한다면, 신원은 많은 사람이 쓰는 터널의 출처 주소가 아니라 인증된 계정에서 와야 합니다.
실수로 게시해서는 안 되는 것
공용 리버스 프록시와 벤더 릴레이는 둘 다 실제 아키텍처이며, 각각 고유한 신뢰와 노출 결정을 지닙니다. 관리자가 집을 비웠기 때문에 어느 쪽도 필요해지지 않으며, 미디어 서버나 파일 공유를 노출한 부작용으로 나타나서도 안 됩니다.
네 가지를 문서화하고 멈추십시오. 사설 이름, 그것이 매핑되는 리스너, 그것을 사용하도록 허용된 그룹, 터널을 쓸 수 없을 때의 복구 경로입니다. 이 네 가지는 사고 검토가 물을 질문에도 답하지만, 포트 포워딩 페이지의 스크린샷에는 해당하지 않으며, 결국 남는 것은 모든 기능이 인터넷을 향한 장치가 아니라 안정적인 관리 진입점 하나입니다.