Quản trị NAS qua VPN: giữ tên, bỏ cổng công khai
Truy cập trang quản trị qua đường hầm, không qua một cổng công khai mới. Phân giải tên thật, khớp chứng chỉ với tên đó và chỉ cho phép một dịch vụ từ một nguồn.
Trang quản trị NAS hoạt động tại nhà và ngừng hoạt động ngay khi người quản trị đi công tác, nên ai đó mở một cổng và vấn đề biến mất cùng với sự riêng tư. Có một hình thức tốt hơn cho việc này. Giữ trang ở nguyên chỗ cũ, để đường hầm đảm bảo khả năng tiếp cận, và biến điều bạn ghi chép thành một URL đầy đủ với đường dẫn quyền có tên, thay vì một địa chỉ thiết bị tình cờ trả lời. Mọi quyết định dưới đây, từ tên đến chứng chỉ và cổng duy nhất được phép, đều xuất phát từ việc viết như vậy.
Đơn vị thiết kế là URL, không phải địa chỉ
Viết điểm vào dưới dạng URL đầy đủ với cổng và giao thức của nó, rồi gắn các điều kiện: ai được dùng, từ mạng nào và qua đường nào. Một ví dụ có thể là https://nas.corp.example:8443 chỉ được công bố cho các máy khách riêng tư đã được phê duyệt, trong đó tên và cổng đại diện cho điều thiết bị thực sự lắng nghe.
Khung đó buộc phải quyết định sớm. URL ngụ ý một tên, tên ngụ ý một chứng chỉ, và chứng chỉ ngụ ý một thỏa thuận tin cậy. Địa chỉ không ngụ ý bất kỳ điều nào trong số đó, và chính vì thế phiên bản chỉ có địa chỉ tồn tại đến cảnh báo trình duyệt đầu tiên rồi trở thành thói quen bấm qua nó.
| 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 |
Giữ tên mà chứng chỉ được cấp cho
Máy khách cần một tuyến được phép đến địa chỉ riêng của NAS, và một cấu hình DNS riêng có thể phân giải tên máy chủ dự định về địa chỉ đó trong khi vẫn giữ tên mà dịch vụ HTTPS mong đợi. Cả hai nửa đều quan trọng: tuyến đưa gói tin đến đó, tên cho máy khách biết phải xác minh danh tính nào.
Gõ địa chỉ số thay vào đó sẽ thay đổi yêu cầu về danh tính. RFC 9525 tách tên mà máy khách định liên hệ khỏi danh tính mà dịch vụ trình bày, nên một chứng chỉ cấp cho nas.corp.example có thể thất bại một cách hợp lệ khi trình duyệt được trỏ đến 10.20.0.15. Cảnh báo là đúng, và cách sửa là tên, không phải ngoại lệ.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleChạy cả hai trước khi đổ lỗi cho đường hầm. Cái đầu cho biết tên riêng có phân giải đúng chỗ bạn nghĩ không, cái thứ hai cho biết dịch vụ thực sự trình bày chứng chỉ nào và những tên chủ thể thay thế nào. Một CA riêng có thể là lựa chọn được quản lý hoàn toàn tốt; điều không nên thành thông lệ là dạy người ta bỏ qua cảnh báo danh tính.
Giới hạn đường quản trị
Chỉ cho phép đúng dịch vụ quản trị từ nguồn dự định, cả ở cổng vào lẫn ở NAS. Câu đó ẩn một chi tiết gây đau: một nhóm máy khách được định tuyến và một cổng vào có dịch địa chỉ nguồn đến NAS với địa chỉ nguồn khác nhau, nên quy tắc cho phép viết cho cái này sẽ âm thầm thất bại với cái kia.
NAS cũng cần đường quay về, và trình duyệt phải dùng cổng và giao thức đã cấu hình thay vì giá trị mặc định của nhà sản xuất lấy từ một bài đăng diễn đàn. Tiếp cận thiết bị không phải là quyền tiếp cận mọi cổng trên đó. Khoảng cách giữa một thiết bị trả lời ping và một trang quản trị tải được là khoảng cách giữa hai quy tắc riêng biệt. Hãy viết chúng thành hai quy tắc với hai chú thích, để người tiếp theo thấy vì sao cả hai tồn tại.
Tách việc được vào VPN khỏi quyền trên NAS
Được cho qua đường hầm không giống với được phép quản trị thiết bị. Một người dùng có nhu cầu lưu trữ tệp chính đáng không nên thừa hưởng quyền quản trị thiết bị chỉ vì cả hai nằm sau một cổng vào, và mô hình tài khoản của NAS là nơi phải thực thi sự tách biệt đó.
Một địa chỉ ra dùng chung hoặc đã dịch cũng không thể nhận diện một quản trị viên cá nhân. Nếu nhật ký kiểm toán cần nêu tên một người, danh tính phải đến từ một tài khoản đã xác thực chứ không phải từ địa chỉ nguồn của một đường hầm mà nhiều người dùng.
Điều gì không nên công bố vô tình
Một proxy ngược công khai và một relay của nhà sản xuất đều là kiến trúc thật, và mỗi cái mang theo quyết định tin cậy và phơi bày riêng. Không cái nào trở nên cần thiết vì người quản trị đi vắng nhà, và không cái nào nên xuất hiện như tác dụng phụ của việc phơi bày một máy chủ media hay một chia sẻ tệp.
Ghi chép bốn điều và dừng lại: tên riêng, trình lắng nghe mà nó ánh xạ tới, nhóm được phép dùng nó, và đường phục hồi nếu đường hầm không khả dụng. Bốn điều đó cũng trả lời những câu hỏi mà một buổi đánh giá sự cố sẽ hỏi, điều không đúng với ảnh chụp màn hình của một trang chuyển tiếp cổng. Cuối cùng bạn có một điểm vào quản trị ổn định thay vì một thiết bị mà mọi tính năng đều hướng ra internet.