RDS riêng tư từ EC2: cùng VPC, peering hay cách khác?

Máy tính xách tay của nhà phát triển đến phiên bản RDS riêng tư qua VPN của nhân viên, nhưng ứng dụng trên EC2 hoàn toàn không kết nối được. Đây không phải là một lần triển khai hỏng. Máy tính xách tay có một đường hầm mà phiên bản EC2 không bao giờ kế thừa, và «riêng tư» trong RDS nghĩa là cơ sở dữ liệu không có điểm cuối công khai, chứ không phải người dùng VPN là những người gọi duy nhất được phép. Ứng dụng cần tuyến đường được ủy quyền riêng, mối quan hệ riêng với nhóm bảo mật và danh tính riêng trong cơ sở dữ liệu, và thứ tự chọn ba thứ này tiết kiệm phần lớn thời gian gỡ lỗi. Quyết định tuyến trước, sau đó đến quyền, rồi xác minh từ môi trường đã triển khai thay vì từ bàn làm việc của bạn.

VPN của máy tính xách tay không phải là tuyến của ứng dụng

Bất kể VPN của nhân viên làm gì cho con người, nó không làm gì cho một phiên bản trừ khi phiên bản đó là phần rõ ràng của cùng một tuyến mạng. Một phiên bản EC2 trong mạng con riêng tư đến RDS thông qua định tuyến VPC, nhóm bảo mật và ACL mạng. Nó không kế thừa đường hầm của con người, phiên của con người hay thông tin đăng nhập của con người, và không nên: kết nối ứng dụng không giám sát và truy cập từ xa của nhân viên phải vận hành độc lập.

Sự độc lập đó là một đặc điểm. Khi VPN ngừng hoạt động, ứng dụng vẫn tiếp tục chạy. Khi ứng dụng hoạt động sai, không ai mất quyền truy cập từ xa. Những thiết kế gộp cả hai vào một tuyến thường được phát hiện trong một sự cố, vào thời điểm tồi tệ nhất có thể.

Quyết định 1: cùng VPC, tuyến trực tiếp

Khi ứng dụng và cơ sở dữ liệu ở cùng một VPC với định tuyến trực tiếp và không có hộp kiểm tra nào ở giữa, tuyến rất đơn giản và tham chiếu nhóm bảo mật là công cụ mạnh nhất hiện có. Cấp cho ứng dụng nhóm riêng của nó, sau đó cho phép cổng cơ sở dữ liệu từ nhóm đó thay vì từ một dải địa chỉ:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

Cổng chỉ là ví dụ và phải khớp với công cụ. Tham chiếu nhóm ủy quyền lưu lượng từ các phiên bản của ứng dụng; nó không sao chép quy tắc của chúng và không tạo đăng nhập cơ sở dữ liệu. Hai vấn đề riêng biệt, hai cách khắc phục riêng biệt.

Sau đó kiểm tra phần còn lại của tuyến thay vì dừng ở quy tắc bạn vừa thêm. Chính sách ra của ứng dụng, toàn bộ nhóm gắn với cơ sở dữ liệu, bảng định tuyến của mạng con và bất kỳ ACL mạng nào đều phải khớp nhau. Quy tắc nhóm bảo mật có trạng thái, trong khi ACL mạng tùy chỉnh phải cho phép yêu cầu và lưu lượng trả về trong các quy tắc riêng, bao gồm các cổng tạm thời. Một quy tắc cơ sở dữ liệu mới và hẹp cũng không hủy bỏ một quyền cho phép rộng cũ đã được gắn.

Quyết định 2: VPC khác hoặc tài khoản khác

Nếu ứng dụng ở VPC khác, chủ sở hữu mạng chọn một kết nối riêng được hỗ trợ: peering, thiết kế trung chuyển hoặc thỏa thuận VPC chia sẻ. Sau đó phải tồn tại cả hai hướng định tuyến, phân giải tên phải hoạt động cho điểm cuối RDS, và nguồn mà chính sách cơ sở dữ liệu đánh giá phải khớp với những gì thực sự đến. Tên tài khoản trùng nhau hay quan hệ thanh toán chung không cung cấp bất kỳ điều nào trong số đó.

Tham chiếu nhóm bảo mật là phần thay đổi. Nó hoạt động trong một số thiết kế kết nối riêng, nhưng ngừng hoạt động ngay khi một hộp trung gian ghi lại nguồn hoặc kết thúc kết nối, vì cơ sở dữ liệu khi đó thấy hộp trung gian chứ không phải nhóm ứng dụng của bạn. Các kịch bản VPC của RDS tách truy cập trong cùng VPC khỏi các bố trí khác, và đáng để kiểm tra cấu trúc liên kết cụ thể của bạn với chúng trước khi cho rằng một phong cách quy tắc được chuyển giao.

Đừng giải quyết tuyến bị thiếu bằng cách làm cho cơ sở dữ liệu có thể truy cập công khai. Đó là một quyết định phơi bày khác với chủ sở hữu khác, và thường được đề xuất bởi người ở xa hậu quả nhất.

Quyết định 3: cơ sở dữ liệu chấp nhận danh tính nào

Truy cập mạng và xác thực cơ sở dữ liệu là các lớp riêng biệt, và việc trộn lẫn chúng tạo ra những lỗi gây hiểu nhầm nhất. Vai trò của phiên bản là danh tính AWS để gọi API AWS. Nó không phải người dùng cơ sở dữ liệu. Xác thực cơ sở dữ liệu bằng IAM là một tính năng được hỗ trợ nơi công cụ và cấu hình cho phép, và nó vẫn là ánh xạ tới một người dùng cơ sở dữ liệu, không phải thay thế.

Sử dụng tên điểm cuối RDS trong cấu hình của ứng dụng thay vì địa chỉ thu được từ một lần tra cứu. Chuyển đổi khi lỗi Multi-AZ thay đổi địa chỉ phía sau tên đó, và một ứng dụng bị ghim vào IP sẽ thất bại đúng vào lúc cần thiết. Hãy để xác minh TLS của công cụ bật thay vì tắt nó để lỗi biến mất, vì lỗi xác minh cho bạn biết điều gì đó về điểm cuối bạn đã đến.

Sau đó cấp cho tài khoản cơ sở dữ liệu mức tối thiểu mà ứng dụng cần, trong lược đồ mà nó thực sự sử dụng. Công việc đó nhàm chán, có thể kiểm toán, và là phần mà một cuộc đánh giá sự cố sẽ hỏi đến.

Xác minh từ môi trường đã triển khai

Kiểm tra từ phiên bản hoặc từ một tác vụ chạy với cùng nhóm, mạng con và vai trò. Bốn lỗi trông giống nhau từ máy tính xách tay và dễ phân biệt từ đó: một tên không phân giải được, một kết nối hết thời gian chờ, một lỗi xác thực TLS và một lần đăng nhập cơ sở dữ liệu bị từ chối. Mỗi lỗi chỉ vào một ranh giới khác nhau, và thay đổi mức phơi bày của cơ sở dữ liệu trước khi biết mình có lỗi nào là đoán mò.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

Nếu kết nối thành công từ phiên bản và thất bại từ bàn làm việc của bạn, tuyến của ứng dụng vẫn ổn và quyền truy cập của bạn là thứ cần sửa. Nếu nó thất bại từ cả hai, hãy bắt đầu bằng các kiểm tra nhóm và tuyến ở trên thay vì thông tin đăng nhập. Chỉ một so sánh đó ngăn phần lớn sự lộn xộn mà những phiếu này tạo ra.