Hai thư mục trông giống nhau trong một bài hướng dẫn lại làm những việc hoàn toàn khác. Một thư mục chứa cơ quan chứng thực: khóa riêng của nó, bộ đếm số sê-ri và bản ghi mọi thứ nó đã ký. Thư mục kia chứa những gì daemon cần để khởi động và phục vụ máy khách. Đặt cả hai trên cùng một máy chủ dưới cùng một tài khoản thì tiện cho một buổi chiều và tốn kém cho phần đời còn lại của việc triển khai, vì daemon khi đó chạy bên cạnh đúng một khóa có thể tạo ra bất kỳ danh tính nào nó muốn.

Không gian làm việc của CA chứa gì

Thư mục PKI là trạng thái của tổ chức phát hành, không phải cấu hình. Nó chứa khóa riêng và chứng chỉ của CA, một tệp số sê-ri, một chỉ mục các chứng chỉ đã phát hành và tài liệu cho từng danh tính được tạo ra từ chúng.

Ký một yêu cầu sẽ thay đổi trạng thái đó, vì vậy không gian làm việc thuộc về một tài khoản do quản trị viên kiểm soát trên một máy chủ không chạy dịch vụ VPN. Bất kỳ ai đọc được khóa riêng của CA đều có thể phát hành một chứng chỉ mà máy chủ sẽ tin cậy, nên việc bảo vệ khóa chính là toàn bộ mô hình tin cậy trong một tệp. Sao chép nó sang vị trí thứ hai để tiết kiệm một bước lại tạo ra thứ thứ hai phải bảo vệ và thứ thứ hai phải quên. Mỗi chữ ký cũng tăng số sê-ri và thêm một mục vào chỉ mục, vì vậy không gian làm việc là một bản sao trạng thái chứ không phải một thư mục chứa tệp.

Chứng chỉ công khai của CA thì khác. Nó được dùng để phân phối, và đó là thứ máy khách cùng máy chủ dùng để xác minh lẫn nhau.

Daemon đọc gì khi khởi động

Máy chủ đang chạy tiêu thụ một tập nhỏ: chứng chỉ của chính nó, khóa riêng của chính nó, chứng chỉ CA để xác minh các peer và bất kỳ tài liệu khóa nào mà chế độ đã chọn yêu cầu. Nó đọc những đường dẫn đó khi khởi động và đọc lại khi tải lại.

Quyền sở hữu phải được đánh giá theo đơn vị thực sự khởi chạy, không phải theo một shell root tương tác. Việc cô lập đã khai báo có thể khiến một phần hệ thống tệp chỉ đọc hoặc vô hình ngay cả khi thử nghiệm thủ công với quyền root thành công.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

Dòng thứ ba là dòng mà mọi người bỏ qua. Nó hỏi chính tài khoản của daemon xem có đọc được khóa không, và đó là phiên bản duy nhất của câu hỏi có ý nghĩa sau khi quyền đã bị hạ. Mã thoát bằng không với quyền root không cho biết gì về điều xảy ra sau khi hạ quyền.

Nên tách hai con đường lỗi trước khi thay đổi bất kỳ quyền nào. Lỗi ký trỏ đến thư mục PKI, quyền tìm kiếm trên các thư mục cha của nó và tài khoản chạy tổ chức phát hành. Lỗi khởi động trỏ đến đơn vị, thư mục làm việc của nó và các đường dẫn được nêu trong cấu hình máy chủ. Việc làm cho toàn bộ cây đọc được với mọi người không khắc phục được cái nào và xóa bỏ ranh giới mà cả hai phụ thuộc vào.

Vì sao việc sao chép khóa CA sang máy chủ lại thất bại về sau

Bản sao thường bắt đầu như một thao tác gỡ lỗi: ai đó muốn gia hạn một máy khách trên máy chủ VPN, nên khóa CA rơi vào /etc/openvpn và việc gia hạn thành công. Nhiệm vụ trước mắt hoàn thành, và ranh giới biến mất.

Sau đó máy chủ được sao lưu, và cơ quan ký gia nhập các bản sao lưu. Một ảnh chụp nhanh, một gói hỗ trợ hoặc một bản sao thư mục cấu hình giờ đây mang theo khả năng phát hành danh tính đáng tin cậy chừng nào CA còn hiệu lực. Bất kỳ ai giữ bản sao đó đều có thể tạo chứng chỉ cho bất kỳ tên nào máy chủ chấp nhận, kể cả những tên chưa từng được phát hành. Bản ghi duy nhất về việc phát hành đó là bản ghi họ chọn giữ lại.

Khôi phục từ trạng thái đó không phải là chuyện xóa một tệp. Bạn phải quyết định xem khóa có bị lộ không, luân chuyển CA nếu có, và phân phối lại niềm tin cho mọi peer. Một không gian làm việc riêng tránh được toàn bộ cuộc trò chuyện.

Tài khoản, thư mục, bản sao lưu

Cấp cho tổ chức phát hành tài khoản và thư mục chính riêng, giữ ngoài máy chủ VPN khi thực tế cho phép. Cấp cho daemon một tài khoản khác, có quyền đọc tài liệu đã triển khai và không có quyền ghi vào bất cứ thứ gì phát hành chứng chỉ. Triển khai bằng cách sao chép chứng chỉ công khai ra ngoài và không bao giờ kéo trạng thái riêng của tổ chức phát hành vào trong. Sao lưu hai vai trò riêng biệt, vì độ nhạy cảm và câu chuyện khôi phục của chúng khác nhau.

Sau khi thu hồi, hãy cập nhật tệp CRL mà cấu hình máy chủ nêu tên, rồi tải lại dịch vụ để các kết nối mới đọc được nó. Tài liệu Easy-RSA trình bày cách bố trí không gian làm việc và quy trình ký; các quy tắc sở hữu xung quanh nó vẫn là quyết định về máy chủ của bạn. Hãy xác nhận những gì dịch vụ đã tải bằng openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate thay vì cho rằng việc tải lại đã nhận được nó.

Một bài kiểm tra chứng minh sự tách biệt

Hãy kiểm tra trường hợp phủ định, không chỉ trường hợp hoạt động. Ký một chứng chỉ từ tài khoản của tổ chức phát hành như thiết kế, rồi xác nhận rằng chính tài khoản đó không thể khởi động dịch vụ hoặc đọc khóa riêng của máy chủ. Sau đó xác nhận rằng tài khoản của daemon không thể đọc khóa riêng của CA.

Ba kiểm tra đó mất vài phút và tồn tại qua các thay đổi nhân sự, vì chúng là những tuyên bố về quyền chứ không phải về thói quen. Hãy ghi lại kết quả cùng các đường dẫn và tài khoản mà nó bao phủ, kèm ngày bạn chạy chúng. Người tiếp theo kế thừa việc triển khai này nếu không sẽ lại suy ra ranh giới từ một bài hướng dẫn chưa từng có ranh giới nào. Một bản ghi có ngày tháng cũng là thứ khiến lần rà soát tiếp theo mất vài phút thay vì một buổi chiều.

Bài viết liên quan