Một thiết bị hiện trường mở kết nối tới dịch vụ, và câu hỏi thiết kế hiện ra như một lựa chọn giữa VPN và TLS. Cách đặt vấn đề đó sai, vì hai thứ làm những việc khác nhau. TLS xác thực điểm cuối ứng dụng và bảo vệ cuộc trao đổi; còn VPN kiểm soát khả năng tiếp cận và bảo vệ các gói tin giữa các điểm ngang hàng. Hãy lần theo kết nối từ thiết bị ra ngoài và mỗi lớp đều có câu trả lời riêng.

Nếu bạn không nói được TLS kết thúc ở đâu, bạn cũng không nói được ứng dụng thực sự tin vào điều gì.

Xác định nơi TLS thực sự kết thúc

Bắt đầu từ ứng dụng trên thiết bị và lần theo kết nối tới tiến trình hoàn tất bắt tay. Nếu một proxy kết thúc TLS trước máy chủ lớn, đường đi được bảo vệ dừng lại ở proxy đó. Chặng còn lại cần có biện pháp bảo vệ riêng đã được ghi thành văn bản.

Gọi đó là đầu-cuối chỉ dựa vào giả định chính là cách một buổi đánh giá thiết kế phê duyệt một lỗ hổng. Hãy vẽ điểm kết thúc và neo tin cậy trên cùng một sơ đồ.

TLS mang theo yêu cầu và phản hồi theo cả hai chiều, nên một ứng dụng hai chiều không đương nhiên cần VPN thay cho TLS. Điều ngược lại cũng đúng: một triển khai vẫn có thể cần VPN cho các giao thức khác trên cùng thiết bị.

Quyết định thiết bị phải xác thực điều gì

Cấu hình việc kiểm tra danh tính máy chủ và các gốc tin cậy dự định. Nếu mỗi thiết bị phải chứng minh danh tính của chính nó, hãy chọn một mô hình xác thực máy khách được hỗ trợ và đăng ký một thông tin xác thực riêng cho từng thiết bị. Thông tin xác thực dùng chung biến một thiết bị bị đánh cắp thành vấn đề của cả đội thiết bị.

Hãy lập kế hoạch bảo vệ khóa, gia hạn, thu hồi và khôi phục trước khi xuất xưởng. Một thiết bị ngoài hiện trường không thể đăng ký lại sau khi gia hạn thất bại sẽ trở thành một chuyến đi đến tận nơi, và chi phí đó định hình thiết kế nhiều hơn cả bước bắt tay.

Hãy dùng một thư viện được hỗ trợ và hướng dẫn hiện hành. Hướng dẫn triển khai TLS hiện đại cấm thương lượng TLS 1.0 và 1.1, còn việc một ghi chú thiết kế cũ nhắc tới TLSv1 không phải là một yêu cầu.

Đóng lại khi bắt tay thất bại

Một bước bắt tay hoặc kiểm tra danh tính thất bại không được âm thầm quay về giao thức văn bản rõ ban đầu. Sự quay lại đó chính là lỗ hổng mà công việc TLS được đặt ra để bịt kín. Hãy làm cho lỗi hiện rõ với người vận hành thiết bị và với dịch vụ, đồng thời buộc dùng kênh được bảo vệ cho các thao tác nhạy cảm. Sau đó để việc phân quyền của ứng dụng quyết định thiết bị đã xác thực được phép làm gì.

Hãy định nghĩa thời gian sống của kết nối, cách chia khung, thời gian chờ và hành vi thử lại như một phần của hợp đồng. Mã hóa không làm một lệnh lặp lại trở nên an toàn, và việc thử lại sau một thao tác chưa rõ kết quả cần một câu trả lời ở tầng ứng dụng.

Hãy viết quy tắc quay lại ra giấy. "Nó kết nối lại mà không có TLS nếu bắt tay thất bại" là một quyết định thiết kế, và đó nên là một quyết định được nêu rõ.

Chỉ giao cho VPN công việc mà nó có thể làm

VPN có thể hạn chế khả năng tiếp cận và bảo vệ các gói tin tới điểm ngang hàng của chính nó. TLS bảo vệ mối quan hệ của ứng dụng với điểm cuối đã chọn. Điểm kết thúc của chúng có thể khác nhau, và không bên nào bảo vệ dữ liệu lưu trữ hay quyền truy cập quản trị của điểm cuối.

Hãy đo chi phí bắt tay, việc trao đổi tin nhắn ở trạng thái ổn định và việc kết nối lại trên chính thiết bị thay vì giả định một cơ chế nhanh hơn. Sau đó kiểm thử bốn trường hợp quan trọng: trao đổi như dự định, sai danh tính máy chủ, thiết bị không được phép, và kết nối lại sau một thao tác chưa rõ kết quả. Ghi lại kết quả cho từng trường hợp, kể cả lỗi mà thiết bị hiển thị.

Bài viết liên quan