Quy tắc AWS Client VPN thuộc về tài nguyên, không phải subnet

Nhân viên cần truy cập một ứng dụng trong VPC và không được truy cập trình lắng nghe cơ sở dữ liệu trên cùng instance, nên ai đó thêm một subnet công khai thứ hai cho endpoint VPN và tuyên bố yêu cầu đã được đáp ứng. Vị trí subnet thay đổi định tuyến và tính sẵn sàng. Nó không cấp hay thu hồi một cổng nào. Quyền thể hiện yêu cầu nằm ở đích, trong nhóm bảo mật của tài nguyên, và ranh giới VPN cung cấp tay nắm mà quy tắc đó tham chiếu.

Vị trí subnet là định tuyến, không phải cấp quyền

Vị trí liên kết mạng của endpoint quyết định bảng định tuyến nào mang lưu lượng của máy khách và vùng sẵn sàng nào sống sót qua sự cố. Nó không nói gì về việc lưu lượng đó có thể đến cổng nào trên instance nào. Hai máy khách liên kết với cùng một subnet vẫn đến với cùng một danh tính nguồn, và tài nguyên không thể phân biệt chúng bằng tên subnet.

Hãy bắt đầu từ yêu cầu: ai gọi, tài nguyên nào, cổng dịch vụ nào và hướng nào. Sau đó chọn mô hình quy tắc có thể diễn đạt bốn điều đó tại đích. Cách tiếp cận đó thường loại bỏ hoàn toàn subnet thừa khỏi thiết kế.

Nhóm liên kết của Client VPN chính là tay nắm

Đối với endpoint AWS Client VPN liên kết với subnet, cách bố trí được tài liệu hóa là cụ thể. Áp dụng nhóm bảo mật dự định cho các liên kết mạng đích của endpoint, sau đó cho phép lưu lượng cần thiết trong nhóm bảo mật của tài nguyên bằng cách dùng nhóm Client VPN đó làm nguồn.

Cụ thể, nhóm của instance ứng dụng chỉ cho phép cổng ứng dụng từ nhóm liên kết, và không gì khác. Quy trình truy cập tài nguyên của AWS mô tả mối quan hệ đó, và nên giữ cùng chính sách nhóm trên mọi subnet mà endpoint liên kết, vì một liên kết cũ với nhóm khác sẽ âm thầm mở rộng ranh giới.

Quy tắc đó không xác thực bất kỳ ai. Đăng nhập là một kiểm soát riêng, và đường đến tài nguyên là kiểm soát thứ ba. Cả ba phải đúng trước khi một yêu cầu đến. Cái nào thất bại sẽ quyết định cách khắc phục nào là đúng, và thay đổi quy tắc chỉ là câu trả lời đúng cho cái đầu tiên.

Điều mà một nhóm liên kết không thể phân biệt

Mọi máy khách sau cùng một nhóm liên kết đều đến tài nguyên như cùng một nguồn nhóm bảo mật. Hai người dùng có vai trò khác nhau không thể phân biệt ở lớp đó, dù nhóm được đặt tên hay gắn thẻ thế nào. Việc cấp quyền cho nhóm bên ngoài của Client VPN giới hạn truy cập theo tiền tố đích cho nhóm thư mục hoặc SAML, điều này thô hơn vai trò tài nguyên và nên được coi là ranh giới mạng, không phải hệ thống danh tính.

Những khác biệt tinh tế hơn thuộc về ứng dụng. Một trình lắng nghe cơ sở dữ liệu phải đóng với phần lớn nhân viên được bảo vệ tốt hơn bằng cách hoàn toàn không thể truy cập trên tiền tố được phép, thay vì hy vọng tư cách thành viên nhóm vẫn gọn gàng.

Đổi tên nhóm không tạo ra danh tính, và nhân bản nó theo từng đội chỉ nhân lên các liên kết cần kiểm toán.

Đừng sao chép quy tắc đó vào mọi thiết kế VPN

Cổng EC2 VPN tự quản lý, thiết bị kiểm tra được định tuyến và Client VPN được quản lý là ba đường đi gói tin khác nhau. Xác định địa chỉ nguồn nào thực sự đến tài nguyên, có chuyển đổi ở giữa hay không, và dịch vụ hỗ trợ cơ chế tham chiếu nào trên đường đó.

Chuyển lưu lượng qua thiết bị trung gian không giữ được tham chiếu nhóm bảo mật nguồn như lưu lượng trực tiếp giữa các instance. AWS ghi nhận rằng những thiết kế như vậy có thể cần địa chỉ nguồn riêng hoặc CIDR phù hợp thay cho tham chiếu nhóm. Quy trình Client VPN được quản lý không phải bằng chứng rằng nhóm gắn với mỗi cổng hoạt động như một token danh tính phổ quát cho các gói tin được chuyển tiếp.

Một bước nhảy NAT trên đường là đủ để phá vỡ giả định, và sự cố trông giống một quy tắc có tồn tại nhưng không bao giờ khớp.

Xem xét ranh giới hiệu lực

Đọc mọi nhóm bảo mật gắn với tài nguyên, vì các quy tắc cho phép cộng dồn và một quy tắc hẹp không hủy bỏ quy tắc rộng hơn ở nhóm khác. Sau đó kiểm tra ACL mạng, tường lửa của máy chủ và cấp quyền của chính ứng dụng, đây là những lớp riêng với sai sót riêng.

Kết thúc bằng một yêu cầu được phép và một yêu cầu cố ý bị loại trừ đối với cùng tài nguyên. Cặp đó chứng minh ranh giới, trong khi một kết nối thành công chỉ chứng minh rằng có gì đó đang mở. Xác nhận đường đi, nguồn hiệu lực và cổng dịch vụ dự định, không phải subnet chứa endpoint.

Thứ tự công việc: viết yêu cầu bốn phần, gắn nhóm vào các liên kết, giới hạn quy tắc tài nguyên theo cổng, xác minh một lần cho phép và một lần từ chối, và chỉ sau đó mới cân nhắc chia subnet vì lý do định tuyến.