Nextcloud chỉ qua VPN: trước tiên hãy kiểm kê mọi lối vào

Kế hoạch Nextcloud chỉ qua VPN thất bại khi nó bảo vệ trình duyệt mà quên ứng dụng đồng bộ. Trang web, công cụ đồng bộ trên máy tính, tải lên từ di động, công cụ WebDAV và người nhận liên kết chia sẻ đều cần một đường đến cùng dịch vụ, và mỗi thứ có thể để lộ một lối vào khác. Hãy kiểm kê chúng trước khi đóng bất cứ thứ gì. Danh sách đó chính là vành đai thực sự.

Làm theo danh sách kiểm tra đúng thứ tự. Mục đầu tiên xác định riêng tư nghĩa là gì đối với triển khai này; các mục sau kiểm tra xem triển khai có thực sự khớp với định nghĩa đó không.

Xác định riêng tư trước khi thay đổi vành đai

Viết yêu cầu trong một câu: mọi người dùng phải tham gia VPN trước khi đến ứng dụng, hoặc ứng dụng có thể vẫn công khai trong khi nguồn gốc vẫn riêng tư. Đó là các thiết kế khác nhau, và một proxy ngược công khai chuyển tiếp vào đường hầm riêng tư chỉ thỏa mãn thiết kế thứ hai.

Địa chỉ backend riêng tư không làm ứng dụng trở nên riêng tư. Nếu ánh xạ công khai, tên máy chủ thứ hai hoặc trình lắng nghe IPv6 vẫn đến cùng một phiên bản Nextcloud, lối vào vẫn tồn tại bất kể backend ở đâu. Kiểm tra từng tên từ bên ngoài trước khi tuyên bố dịch vụ là riêng tư. Bản ghi DNS bị thiếu không giống với cổng bị đóng.

Cũng thống nhất về đối tượng mục tiêu: nhân viên, một hộ gia đình, một tổ chức đối tác hoặc một tập hợp con tài khoản. Câu trả lời quyết định liên kết chia sẻ công khai là tính năng hay mâu thuẫn. Ghi đối tượng đó vào kế hoạch truy cập. Đó là bài kiểm tra cho mọi ngoại lệ tiếp theo.

Kiểm kê từng lối vào và từng tên

Liệt kê ánh xạ địa chỉ công khai, proxy ngược, tên máy chủ thay thế, trình lắng nghe IPv6 và mọi địa chỉ đường hầm hoặc mesh đến được dịch vụ. Bao gồm các tên phân giải đến những địa chỉ đó, vì một bản ghi DNS bị quên là lối vào với nhãn thân thiện.

Kiểm tra cấu hình proxy về tiêu đề được chuyển tiếp và khối máy chủ thay thế. Một proxy được thêm cho ứng dụng khác có thể để lộ cùng upstream qua một đường dẫn hoặc một máy chủ ảo còn sót lại. Đọc cấu hình thực tế thay vì sơ đồ dự định. Hai thứ này thường khác nhau nhất sau khi ứng dụng được di chuyển.

Sau đó chặn những lối vào bạn không chọn. Backend riêng tư với phần giao diện công khai không phải thiết kế chỉ qua VPN, và một quy tắc tường lửa chỉ phủ IPv4 sẽ để trình lắng nghe IPv6 mở. Đóng cả hai họ và cả hai tên trong cùng một thay đổi.

Cho mỗi ứng dụng khách một tên dịch vụ

Trỏ DNS riêng tư đến dịch vụ, định tuyến tên đó qua VPN và cấp chứng chỉ cho nó. Tên phải phân giải qua đường riêng tư và xác thực mà không có cảnh báo. Ứng dụng khách truy cập trực tiếp IP vẫn cần tên hoạt động.

Các ứng dụng khách kết nối qua địa chỉ IP không liên quan không nên phải bỏ qua lỗi chứng chỉ để thiết kế hoạt động. Một tên ổn định cũng ngăn ứng dụng đồng bộ tạo mục máy chủ trùng lặp khi địa chỉ thay đổi. Đó là khác biệt giữa dịch vụ riêng tư và IP riêng tư.

Giữ bật xác thực chứng chỉ. Mạng riêng tư giảm phơi nhiễm nhưng không làm cho kết nối TLS chưa xác thực trở nên chấp nhận được, và một ứng dụng khách đã quen bỏ qua cảnh báo sẽ bỏ qua chúng cả trên mạng khác.

Giới hạn truy cập mạng, không phải toàn bộ LAN

Cho phép người dùng đã đăng ký đến dịch vụ Nextcloud và các phụ thuộc cần thiết, và giữ việc quản trị máy chủ trên một đường riêng. Một VPN cho phép một ứng dụng khách vào toàn bộ mạng gia đình hoặc văn phòng trao cho ứng dụng khách đó nhiều hơn mức ứng dụng yêu cầu.

Việc vào VPN không thay thế tài khoản, quyền hay xác thực bổ sung của Nextcloud. Ứng dụng vẫn quyết định người dùng nào được đọc tệp nào, và lớp mạng không nên là kiểm soát duy nhất.

Ghi lại dải nguồn đã phê duyệt và cổng dịch vụ. Chủ sở hữu đích cần nguồn quan sát được, và NAT hoặc proxy có thể ghi lại nó trước khi yêu cầu đến ứng dụng.

Xem xét mọi quy trình làm việc ngoài trình duyệt

Đồng bộ máy tính và tải lên từ di động mở kết nối riêng vào thời điểm riêng. Chúng cần đường riêng tư đã phê duyệt khi kết nối, và có thể hành xử khác khi không có VPN: thử lại, tạm dừng hoặc hiển thị lỗi. Kiểm tra từng cái, không chỉ trình duyệt.

Công cụ WebDAV và ứng dụng lịch hoặc liên hệ là các tích hợp riêng với cấu hình riêng. Một ứng dụng khách lưu URL công khai vào bộ nhớ đệm vẫn tiếp tục thử URL đó sau khi vành đai thay đổi, và lỗi trông giống như vấn đề của ứng dụng.

Liên kết chia sẻ xứng đáng có một quyết định rõ ràng. Liên kết không cấp quyền truy cập VPN cho người nhận, vì vậy trong thiết kế thực sự chỉ qua VPN, người nhận bên ngoài không thể dùng nó dù liên kết hợp lệ. Nếu cần chia sẻ ra ngoài, đó là ngoại lệ có chủ đích với đường truy cập riêng, không phải sơ suất phát hiện sau này.

Liên bang và tích hợp máy chủ với máy chủ cần cùng cách xử lý. Đó là quan hệ khả năng tiếp cận giữa các cài đặt, và triển khai chỉ riêng tư phải nói rõ chúng có được hỗ trợ hay không.

Chấp nhận cả trường hợp được phép và bị từ chối

Từ một ứng dụng khách đã phê duyệt, kiểm tra giao diện web và một lần tải lên hoặc tải xuống tệp thông thường. Sau đó kiểm tra một ứng dụng đồng bộ và một quy trình ngoài trình duyệt. Thành công chỉ trong trình duyệt không phải là chấp nhận.

Từ một đường chưa được phê duyệt, xác nhận ứng dụng không thể truy cập qua mọi lối vào trong danh sách. Kiểm tra tên máy chủ thay thế và địa chỉ IPv6, không chỉ URL chính.

Cuối cùng, xem lại các cài đặt ứng dụng dễ nhầm với chính sách mạng. trusted_domains liệt kê các tên mà phiên bản chấp nhận; đây không phải danh sách IP ứng dụng khách được phép. Nếu proxy ngược cung cấp thông tin địa chỉ, trusted_proxies phải nêu tên proxy thực tế, và tiêu đề được chuyển tiếp chỉ nên được chấp nhận từ nó.

Tiếp tục công việc tăng cường thông thường song song với thay đổi mạng: giữ dữ liệu và bản sao lưu ngoài các đường web không mong muốn, vá ứng dụng, bảo vệ quyền truy cập quản trị và giữ khả năng khôi phục dùng được. VPN loại bỏ một bề mặt lối vào; nó không làm cho ứng dụng khách đã đăng ký trở nên đáng tin cậy.