Đăng ký người dùng VPN: trước hết hãy tìm chủ sở hữu danh tính

Ai đó yêu cầu quyền truy cập VPN, và phản xạ đầu tiên là chạy adduser trên máy chủ. Phản xạ đó chỉ đúng trong một nhóm triển khai hẹp. Trước khi tạo bất cứ thứ gì, hãy mở cấu hình của máy chủ và tìm ra sản phẩm nào chạy ở đó và nó xác thực thông tin đăng nhập ở đâu, vì tài khoản có thể nằm trong cơ sở dữ liệu của sản phẩm, tại nhà cung cấp danh tính hoặc trong ngăn xếp xác thực riêng của máy chủ. Tạo sai loại tài khoản khiến người đó có đăng nhập hoạt động nhưng không có đường hầm.

Một hồ sơ máy khách có ghi OpenVPN mô tả giao thức, không mô tả hệ thống danh tính phía sau.

Bắt đầu từ máy chủ, không phải adduser

Trước hết hãy xác định sản phẩm. Community OpenVPN là daemon cộng với bất kỳ xác thực nào bạn đã gắn vào nó, trong khi Access Server là sản phẩm có lớp người dùng riêng. Yêu cầu cấu hình, tên unit và danh sách gói, và kiểm tra xem có giao diện web để quản lý người dùng hay không. Sau đó xem hồ sơ đã triển khai mong đợi máy khách chứng minh danh tính bằng gì: chứng chỉ, tên người dùng và mật khẩu, hoặc cả hai. Câu trả lời đó nêu tên hệ thống sở hữu tài khoản.

Chỉ sau đó cụm từ tạo người dùng mới có nghĩa. Trong triển khai chỉ dùng chứng chỉ, điều đó nghĩa là cấp danh tính thiết bị qua quy trình đã được phê duyệt, và đăng nhập Unix không thay đổi gì. Trong triển khai dùng mật khẩu, điều đó nghĩa là backend thực sự xác thực mật khẩu.

Bốn backend, bốn nơi để tạo tài khoản

Xác thực cục bộ của Access Server giữ tài khoản trong cơ sở dữ liệu riêng, nên giao diện để tạo chúng thuộc về sản phẩm chứ không phải máy chủ. PAM ủy thác việc xác thực cho ngăn xếp của hệ điều hành, vì thế tài khoản Unix cục bộ có thể là một phần của đăng ký khi dịch vụ đã chọn đúng ngăn xếp đó. LDAP, RADIUS và SAML chuyển việc xác thực sang dịch vụ bên ngoài, nơi cư trú của việc cấp phát, chính sách mật khẩu và MFA. Access Server vẫn có thể giữ chứng chỉ và quyền theo từng người dùng trong cả bốn trường hợp, và đó chính là điều khiến việc phân tách trở nên khó hiểu.

Hãy kiểm tra phương thức hiệu lực cho người dùng cụ thể này thay vì mặc định toàn cục. Access Server 2.10 và mới hơn có thể áp dụng các phương thức xác thực khác nhau theo nhóm hoặc theo người dùng, nên mặc định là cục bộ không chứng minh tài khoản trước mặt bạn được xác thực cục bộ.

Quyền là một quyết định riêng

Xác thực trả lời người đó là ai; quyền trả lời họ có thể chạm tới đâu. Hãy giữ chúng như hai bước, vì đăng nhập thành công không phải là cấp quyền. Chủ động chỉ định các tuyến đường dự kiến, quyền trên tài nguyên và quyền quản trị, và xác nhận rằng quyền truy cập không liên quan vẫn bị từ chối. Ở nơi triển khai hỗ trợ danh tính cá nhân, hãy cấp một danh tính cho mỗi người thay vì chuyển tiếp hồ sơ của người khác, vì hồ sơ dùng chung không thể bị thu hồi cho một người.

Tài liệu máy khách cũng quan trọng. Hồ sơ đăng nhập tự động và đăng nhập người dùng tương tác đại diện cho các mối quan hệ xác thực khác nhau, và việc hoán đổi cái này bằng cái kia thay đổi điều máy chủ thực sự kiểm tra.

Thu hồi quyền truy cập là một phần của đăng ký

Ghi lại ba chủ sở hữu trong khi người dùng được tạo: ai xác thực tài khoản, ai cho phép quyền truy cập VPN, và thiết bị hoặc hồ sơ nào đại diện cho kết nối. Đó có thể là ba hệ thống khác nhau, và một kế hoạch thu hồi chỉ nêu một trong số đó sẽ để lại một con đường mở. Khi người đó rời đi, hãy gỡ quyền khỏi chủ sở hữu của nó và thu hồi mọi thông tin xác thực đã cấp tại chủ sở hữu của nó. Xóa một tệp đã tải xuống không phải là thu hồi, và xóa một mục cục bộ cũng không phải nếu danh tính bên ngoài vẫn xác thực.

Sau đó kiểm tra đăng ký như một kẻ tấn công sẽ làm: kết nối một lần với danh tính mới, xác nhận quyền truy cập tài nguyên dự kiến và xác nhận rằng một tài nguyên không liên quan vẫn từ chối. Kết nối đầu tiên hoạt động cộng với một bài kiểm tra phủ định là một đăng ký hoàn chỉnh.

Giữ bản ghi cùng với hồ sơ mà nó thuộc về. Người kiểm toán tiếp theo sẽ hỏi ai có thể kết nối trong một tháng nhất định, và câu trả lời nằm ở ba chủ sở hữu đó.