TLS gốc, chuyển tiếp SSH hoặc VPN cho một dịch vụ đám mây

Câu hỏi hiếm khi là có nên mã hóa thứ gì đó giữa hai máy đám mây hay không; câu hỏi là giao diện nào bạn đang mã hóa và ai kiểm tra danh tính của ai. Tôi bắt đầu những cuộc trò chuyện này từ dịch vụ chứ không phải từ sơ đồ mạng, vì dịch vụ đã biết mình cần gì. Ba ranh giới bao phủ hầu hết các trường hợp: TLS của chính ứng dụng, một cổng TCP được chuyển tiếp qua SSH và một lớp phủ định tuyến cấp địa chỉ cho mọi thành viên. Chúng không được xếp theo độ mạnh mà theo mức độ bao phủ vấn đề.

Bắt đầu từ dịch vụ, không phải từ mạng

Đi từ tiến trình ra ngoài. Nó nói giao thức nào, máy khách sẽ xác minh tên nào và ai được phép mở kết nối? Ba câu trả lời đó loại bỏ lựa chọn nhanh hơn bất kỳ bảng so sánh nào, và cấu hình của chính dịch vụ thường trả lời chúng trong vài phút.

Lấy một API nội bộ nhỏ đã phục vụ HTTPS trên cổng 8443 với chứng chỉ cho api.internal.example. ss -ltnp trên máy chủ cho thấy nó liên kết với gì, và openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example cho thấy chứng chỉ có hợp lệ cho tên mà máy khách thực sự dùng hay không. Nếu cả hai đều khỏe, dịch vụ có thể tự bảo vệ luồng của mình và chỉ còn khả năng tiếp cận. Đó là vấn đề nhỏ hơn nhiều so với việc xây dựng một mạng.

Bước 1: dịch vụ có tự bảo vệ không?

Đây là lựa chọn nên dùng khi phù hợp, và nó phù hợp thường xuyên hơn các nhóm giả định. Mã hóa của dịch vụ bao phủ toàn bộ đường đi giữa máy khách và máy chủ, kể cả mọi chặng ở giữa, điều mà không đường hầm nào quanh phần giữa cải thiện được. Đặt tên mong đợi và sự tin cậy một cách rõ ràng thay vì dựa vào những gì kho lưu trữ mặc định của máy khách tình cờ có.

Mã hóa và khả năng tiếp cận vẫn là các kiểm soát riêng biệt, và việc gộp chúng là nơi lựa chọn này sai. Một dịch vụ TLS trên trình lắng nghe công khai không giới hạn vẫn chấp nhận nỗ lực kết nối từ bất kỳ ai, vì vậy trình lắng nghe và quy tắc mạng phải được xác định độc lập với việc tải trọng được bảo vệ. Sau đó kiểm tra các phụ thuộc, vì API trên TLS không nói gì về điểm khám phá, cổng quản trị hay kênh truyền hàng loạt bên cạnh. Mỗi thứ cần câu trả lời riêng, và một người anh em không được bảo vệ là đủ để biến toàn bộ ranh giới thành hư cấu.

Bước 2: một cổng TCP có phải là toàn bộ yêu cầu?

Khi yêu cầu thực sự là một cổng TCP, chuyển tiếp là thứ nhỏ nhất hoạt động được. Chuyển tiếp cục bộ SSH mang cổng đó qua một kết nối đã xác thực sẵn có.

Hình thức là ssh -N -L 8443:127.0.0.1:8443 [email protected], và chi tiết quan trọng là địa chỉ đích: 127.0.0.1 được phân giải ở phía xa, nên kết nối tới dịch vụ được mở từ bastion chứ không phải từ máy tính xách tay của bạn. Liên kết trình lắng nghe cục bộ hẹp như -L 127.0.0.1:8443:... để bạn không vô tình công bố dịch vụ lên mạng cục bộ của mình. Về phía máy chủ, giới hạn những gì tài khoản được phép chuyển tiếp thay vì tin vào hành vi tốt của máy khách. PermitOpen, AllowTcpForwarding local và GatewayPorts no mặc định là ba cài đặt biến một rơ-le tổng quát thành một kênh cụ thể.

Hợp đồng hẹp theo cả hai hướng. SSH bảo vệ kênh của chính nó, và một chặng nữa từ bastion tới ứng dụng khác cần sự bảo vệ riêng. Một dịch vụ chỉ lắng nghe trên loopback của bastion có mức phơi bày hoàn toàn khác với dịch vụ tiếp cận qua mạng khác, và chuyển tiếp không thay đổi điều đó. Giữ xác thực và kiểm tra TLS của ứng dụng thay vì coi đường hầm là thứ thay thế chúng.

Điều này hoạt động tốt cho một kết nối với một chủ sở hữu. Ở quy mô lớn, nó trở thành một hệ thống: xung đột cổng cục bộ, giám sát, luân chuyển khóa và câu hỏi ai khởi động lại chuyển tiếp sau khi khởi động lại.

Bước 3: định tuyến có phải là yêu cầu thực sự?

Danh sách đó là chi phí trung thực của lựa chọn nhỏ nhất, và đó là lý do các nhóm cuối cùng thay một vài lệnh nền bị lãng quên bằng thứ gì đó được quản lý. Sự thay thế không tự động là VPN. Nếu yêu cầu vẫn là một cổng TCP, một chuyển tiếp được giám sát với chủ sở hữu được ghi lại rẻ hơn để vận hành so với lớp phủ và nó thất bại theo những cách bạn có thể thấy. Đo quyền sở hữu vận hành trước khi đo vẻ thanh lịch.

Định tuyến trở thành câu trả lời đúng khi định tuyến là yêu cầu. Nhiều ứng dụng cần kết nối IP thông thường, các giao thức mà chuyển tiếp TCP không thể mang, hoặc dịch vụ di chuyển giữa các máy chủ đều chỉ về cùng một hướng.

Lớp phủ cấp địa chỉ và tuyến cho các thành viên, rồi công việc thực sự bắt đầu: dải không chồng lấn, quyền sở hữu tuyến, DNS, đăng ký, thu hồi và điều gì xảy ra khi một đối tác biến mất. Không có gì trong số đó đến cùng địa chỉ. Một đối tác được kết nạp vào lớp phủ cũng không tự động được phép cho mọi thao tác ở đích, nên xác thực cấp dịch vụ vẫn còn.

Những gì bạn sở hữu sau đó

Hai điều thuộc về bản ghi bạn để lại. Thứ nhất là danh tính mà máy khách được mong đợi xác minh, vì mỗi ranh giới này suy giảm âm thầm ngay khi kiểm tra tên bị nới lỏng để làm cho thứ gì đó hoạt động. Thứ hai là bước gỡ bỏ: khóa nào, quy tắc nào hoặc tuyến nào biến mất khi quyền truy cập kết thúc, và ai thực hiện.

Hành trình kết thúc ở nơi nó bắt đầu, tại dịch vụ. Chọn ranh giới bao phủ lưu lượng thực và xác minh các đối tác bạn định xác minh, sau đó ghi lại cách quyền truy cập được cập nhật, giám sát và gỡ bỏ. Tài liệu tham khảo OpenSSH là nơi xác nhận các tùy chọn chuyển tiếp trước khi hứa một hợp đồng hẹp. Nếu bạn không thể mô tả bước gỡ bỏ trong một câu, ranh giới lớn hơn vấn đề.