Xác thực AWS Client VPN: quyền IAM không phải là phương thức đăng nhập

Cấp cho người dùng quyền tạo hoặc mô tả một điểm cuối AWS Client VPN không cho phép người đó kết nối tới nó. Đây là hai loại danh tính khác nhau: IAM quản lý các lệnh gọi AWS API, còn điểm cuối chỉ chấp nhận những phương thức xác thực máy khách được cấu hình trên nó. Vì vậy một người dùng có thể có quyền rộng trên console mà vẫn không có gì để máy khách VPN trình ra. Hãy quyết định điểm cuối tin phương thức nào, rồi quyết định liệu một đường hầm đầy đủ có phải là hình thức đúng cho quyền truy cập bạn đang cấp.

Danh tính API không phải danh tính đường hầm

Khi ai đó nói «vai trò IAM đã được gắn, vậy tại sao VPN vẫn lỗi», câu trả lời thường là không bước nào trong luồng kết nối đọc vai trò đó. Máy khách trình một chứng chỉ, tên người dùng và mật khẩu AD, hoặc một khẳng định SAML. Điểm cuối xác thực một trong số đó rồi cấp một địa chỉ.

IAM vẫn quan trọng, chỉ là muộn hơn và ở chỗ khác: tạo điểm cuối, liên kết subnet, công bố tuyến và viết quy tắc ủy quyền là các hành động API. Hãy giữ những quyền đó trong phạm vi những người vận hành cần đến, thay vì trao cho mọi người dùng khả năng viết lại quy tắc truy cập của điểm cuối.

Chọn trong các phương thức mà điểm cuối hỗ trợ

AWS Client VPN chấp nhận xác thực tương hỗ dựa trên chứng chỉ, xác thực Active Directory và xác thực liên hợp dựa trên SAML. Chứng chỉ máy chủ là bắt buộc bất kể bạn chọn phương thức máy khách nào, và một cấu hình kết hợp nhiều phương thức yêu cầu cả hai cùng thành công, không phải một.

Chứng chỉ là rẻ nhất để dựng lên và dễ sai nhất ở quy mô lớn, vì mỗi người dùng cần một thông tin xác thực và mỗi lần rời đi cần một lần thu hồi. Xác thực thư mục chuyển vòng đời đó sang một hệ thống sẵn có. Liên hợp chuyển nó sang nhà cung cấp danh tính và thêm một bước trình duyệt cho máy khách.

Hãy đọc cấu hình của chính điểm cuối trước khi gỡ lỗi máy khách. Nếu xác thực tương hỗ được bật song song với một phương thức dựa trên người dùng, máy khách có chứng chỉ hợp lệ nhưng không có tài khoản thư mục vẫn sẽ thất bại, và lỗi thường trông giống một sự cố bắt tay chung.

Liên hợp không phải là chuyển khóa truy cập

Một cấu hình SAML không đưa khóa truy cập IAM hay token của vai trò được đảm nhận vào đường hầm. Nhà cung cấp danh tính xác thực người đó, trả về một khẳng định, và điểm cuối chấp nhận nó trong phạm vi tin cậy bạn đã cấu hình. Phiên tạo ra là phiên VPN, không phải phiên AWS API.

Sự khác biệt đó quyết định ai có thể chẩn đoán cái gì. Sự cố IdP hiện ra như lỗi trình duyệt hoặc máy khách trước khi có bất kỳ đường hầm nào, còn sự cố đường hầm hiện ra sau một khẳng định thành công. Hãy hỏi bạn đang nhìn cái nào trong hai trước khi mở bất kỳ console nào.

Sau khi đăng nhập, tuyến và ủy quyền vẫn quyết định

Xác thực cho một phiên một địa chỉ; nó không cho phiên một đích đến. Các tuyến của điểm cuối cho máy khách biết gửi tới subnet nào, các quy tắc ủy quyền quyết định người dùng nào có thể tới subnet nào trong số đó, và nhóm bảo mật cùng quyền của chính đích quyết định phần còn lại.

Đó là lý do một người dùng xác thực thành công vẫn có thể không tới được cơ sở dữ liệu. Hãy kiểm tra liên kết bảng tuyến cho subnet, quy tắc ủy quyền cho nhóm của người dùng và nhóm bảo mật trên đích theo thứ tự đó, vì mỗi thứ tạo ra một kiểu hết thời gian khác nhau.

Với một cơ sở dữ liệu riêng, hãy so sánh với chuyển tiếp cổng

Nếu nhiệm vụ thật là một kết nối được phê duyệt tới một cơ sở dữ liệu riêng, một đường hầm mạng đầy đủ là lựa chọn chứ không phải yêu cầu. AWS Systems Manager Session Manager có thể mở một phiên chuyển tiếp cổng tới một nút được quản lý qua IAM, và nút đó tới được cơ sở dữ liệu trên mạng riêng. Người dùng không bao giờ nhận địa chỉ VPC. Nút được quản lý trở thành máy chủ duy nhất tới được cổng cơ sở dữ liệu, và đó thường là điều mà bản đánh giá bảo mật yêu cầu. Người dùng sau đó cần một máy khách cục bộ và một lệnh phiên thay vì hồ sơ VPN.

Sự đánh đổi là phạm vi so với điều kiện tiên quyết. Chuyển tiếp cổng cần tác nhân SSM trên nút được quản lý, khả năng tiếp cận mạng từ nút đó tới cơ sở dữ liệu, plugin Session Manager trên máy của người dùng và quyền khởi động đúng phiên đó. Nó không phải là đường vào mọi subnet, và nó không mang theo giao thức tùy ý như đường hầm.

Dù thế nào, hãy giữ danh tính của chính cơ sở dữ liệu tại chỗ. Kiểm tra TLS và xác thực cơ sở dữ liệu không biến mất chỉ vì đường đi đã được IAM ủy quyền, và một phiên được phê duyệt không nói gì về việc người dùng được đọc bảng nào.

Hãy chọn theo phạm vi và vòng đời: một đường hầm khi nhiều người dùng cần nhiều đích đến và bạn có thể vận hành vòng đời chứng chỉ hoặc thư mục; một phiên chuyển tiếp khi một nhóm nhỏ cần một dịch vụ và bạn muốn tránh phát địa chỉ mạng. Dù thế nào, hãy ghi lại phương thức xác thực, quy tắc ủy quyền và đăng nhập cơ sở dữ liệu như ba sự kiện riêng biệt, vì chúng thất bại riêng rẽ.