Cách gửi nhật ký thiết bị đến bộ thu gom từ xa một cách an toàn

Thiết bị có thể phát ra nhật ký, bộ thu gom nằm ở phía bên kia internet, và câu hỏi đầu tiên mà mọi người đặt ra là xây đường hầm nào. Cách đặt vấn đề đó bắt đầu từ sai chỗ. Phương thức truyền do định dạng thiết bị có thể tạo ra, xác thực mà bộ thu gom sẽ chấp nhận, và ý nghĩa của “đã giao” khi liên kết bị đứt quyết định. Viết ba câu trả lời đó ra, và phương thức truyền thường tự chọn lấy nó.

Bắt đầu từ những gì thiết bị có thể phát ra

Trên thực tế chỉ có ba dạng. Sự kiện syslog riêng lẻ qua UDP hoặc TCP, tải lên HTTPS có xác thực được tích hợp trong sản phẩm, hoặc các tệp hoàn chỉnh được ghi ra đĩa và phải di chuyển. Một tường lửa chỉ gửi được syslog qua UDP sẽ không trở thành bộ gửi TLS vì bạn đã thêm đường hầm; nó vẫn gửi các datagram không được xác nhận, giờ nằm trong một phong bì mã hóa.

Vì vậy trước tiên hãy kiểm kê bên gửi: giao thức, hỗ trợ TLS và thư viện TLS nào, nó có xác thực được chứng chỉ của bộ thu gom không, có trình được chứng chỉ khách không, và bộ đệm gửi có sống sót qua lần khởi động lại không. Mọi thứ thiết bị không làm được phải do thứ khác trên đường làm, và thứ khác đó trở thành một phần thiết kế của bạn.

Syslog TLS: đường ngắn nhất khi cả hai đầu đều nói được

Nếu thiết bị hỗ trợ syslog qua TLS và bộ thu gom kết thúc nó, hãy dùng cách đó và dừng lại. Giao thức ứng dụng tự bảo vệ mình, bộ thu gom xác thực bên gửi, và không có bước nhảy thừa nào mà bạn phải chịu trách nhiệm về tính sẵn sàng. Cái bẫy là “syslog TLS” bao trùm nhiều cách triển khai, và hướng dẫn hiện hành về syslog an toàn đã vượt qua các danh sách mật mã trong các hướng dẫn cũ, và đó là lý do một bộ chuyển tiếp đang chạy tốt lại hỏng sau khi nâng cấp thư viện.

Trong rsyslog, chỉ tên mô-đun truyền tải đã cho biết bạn đang ở thời đại nào: lmnsd_gtls bọc GnuTLS, còn lmnsd_ossl bọc OpenSSL và đó là thứ các gói 8.x hiện tại cung cấp. Một hành động chuyển tiếp có xác thực chứng chỉ trông đại khái như thế này, và nên đối chiếu tên tham số chính xác với phiên bản đã cài:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

Xác minh điểm cuối trước khi gỡ lỗi bên gửi. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error hoặc hoàn tất bắt tay với chuỗi hợp lệ, hoặc cho bạn biết chính xác kiểm tra nào đã thất bại. Hãy thử từ thiết bị, không phải từ máy tính xách tay, vì kho tin cậy của thiết bị mới là thứ quan trọng.

SFTP: tốt cho tệp, sai cho luồng

Giao nhận dựa trên tệp phù hợp với thiết bị chỉ ghi nhật ký luân chuyển và không làm gì khác. Truyền qua SSH cho bạn khóa máy chủ, khóa theo từng tài khoản và hệ thống tệp có thể kiểm toán, đó là một câu chuyện tin cậy hợp lý cho thiết bị hoàn toàn không làm được TLS. Đây là lựa chọn tồi cho luồng sự kiện, nơi “tệp được ghi mỗi giờ” nghĩa là một sự cố khiến bạn mất phần đuôi của giờ hiện tại.

Giữ bật xác minh máy chủ. Một lệnh gọi hàng loạt tắt nó đi để tránh lời nhắc sẽ phá hủy xác thực duy nhất mà phương thức truyền có:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

Ghim khóa máy chủ vào known_hosts của tài khoản trong lúc chuẩn bị, giới hạn tài khoản trong thư mục đích, và ưu tiên hệ thống con internal-sftp với chroot. Cũng hãy lên kế hoạch cho câu chuyện gửi lại: nếu một tệp được gửi lại sau thất bại một phần, bộ thu gom phải phân biệt bản trùng với tệp mới, thường bằng tên cộng với tổng kiểm tra chứ không phải thời điểm đến.

Khi cổng nội bộ hoặc đường hầm là câu trả lời trung thực

Một số thiết bị chỉ nói được định dạng mà không ai muốn phơi bày. Trong trường hợp đó, một bộ thu gom được ủy quyền trên chính mạng của thiết bị nhận định dạng gốc và chuyển tiếp nó qua TLS. Đó là thiết kế hợp pháp, nhưng hãy chính xác về những gì nó mua: mã hóa bắt đầu tại cổng không bảo vệ hồi tố đoạn giữa thiết bị và cổng, nên bước nhảy đó vẫn cần ranh giới tin cậy và kiểm soát truy cập riêng.

Đường hầm trang hoặc thiết bị có định tuyến là lựa chọn nặng nhất và đúng khi bộ thu gom phải giữ một địa chỉ riêng nhiều dịch vụ, không chỉ nhật ký. Nó mang theo quy hoạch địa chỉ, quy tắc truy cập, đường quay về và vòng đời của điểm cuối đường hầm. Nó cũng không cải thiện giao thức bên trong: syslog qua UDP trong đường hầm IPsec vẫn là dịch vụ datagram không có xác nhận giao nhận.

Dù chọn gì, hãy giữ quyền của bộ thu gom hẹp hơn phương thức truyền. Danh tính đường hầm thuộc về một điểm cuối, và nó không nói gì về việc thiết bị hạ nguồn nào đã tạo ra một trường tên máy cụ thể trong thông điệp.

Viết hợp đồng giao nhận trước khi gửi

Mã hóa, xác thực và lưu giữ trả lời những câu hỏi khác nhau, và hàng đợi không phải là chính sách lưu giữ. Trước khi nhật ký đầu tiên rời thiết bị, hãy quyết định xác nhận thực sự có nghĩa gì trên bộ thu gom này: nhận trên đường truyền, được chấp nhận để xử lý, hay được ghi bền vững vào kho lưu trữ. Đó là ba bảo đảm khác nhau và chỉ cái cuối cùng sống sót qua lần khởi động lại bộ thu gom.

Sau đó trả lời bằng văn bản các câu hỏi vận hành. Sự kiện chưa gửi chờ ở đâu, và bộ đệm đó có chịu được mất điện không? Điều gì xảy ra khi nó đầy, và ai được thông báo? Các lần thử lại được giới hạn thế nào, và bản trùng được nhận diện ra sao? Trường nào chứng minh danh tính bên gửi, khi một bước chuyển tiếp có thể viết lại tên máy?

Giữ thiết kế đủ nhỏ để giải thích trong một đoạn: phương thức truyền được hỗ trợ nhỏ nhất mang các sự kiện cần thiết, kèm theo tuyên bố rõ ràng về những bảo đảm mà nó không cung cấp. Nếu câu trả lời cần hai bước nhảy, hãy nói điều đó trong runbook và giao cho mỗi bước một người phụ trách.