TLS, lối vào mạng và quyền SQL trả lời những câu hỏi khác nhau
Mã hoá một kết nối, cho phép một nguồn và cấp một bảng là ba quyết định. Hãy đi qua chúng theo thứ tự trước khi hỏi liệu TLS có thể thay thế VPN hay không.
Ai đó đề xuất trao cho khách hàng một đăng nhập PostgreSQL để yêu cầu hoàn chi phí đi lại được mã hoá từ đầu đến cuối. Quản trị viên cơ sở dữ liệu cần một phiên SQL thực sự, và người khác lại đề xuất một biểu mẫu web thay vào đó. Cả hai đề xuất đều giải quyết sai vấn đề, vì không đề xuất nào bắt đầu từ thao tác mà khách hàng thực sự thực hiện. Hãy đi qua ba quyết định theo thứ tự và câu hỏi liệu TLS có thể thay thế VPN sẽ tự trả lời.
Bắt đầu từ thao tác mà khách hàng cần
Hãy ghi ra điều khách hàng phải đạt được. Gửi một yêu cầu, đọc một dòng báo cáo và chạy một truy vấn tức thời là ba thao tác khác nhau với ba cấu hình rủi ro khác nhau.
Sau đó ghi ra ai là người đưa ra yêu cầu. Khách hàng, nhân viên hỗ trợ và quản trị viên không thể thay thế cho nhau ngay cả khi họ chạm cùng một bảng. Sự khác biệt quyết định khách hàng nên thấy bao nhiêu phần của ngôn ngữ truy vấn.
Cặp câu trả lời quyết định giao diện. Mọi thứ sau đó là triển khai, và phần lớn các cuộc tranh luận về mã hoá thực chất là tranh luận về việc giao diện nào đã được chọn.
Ba kiểm soát, ba quyết định
TLS có xác thực bảo vệ kết nối và quyết định danh tính TLS nào được chấp nhận. Lối vào mạng quyết định nguồn nào có thể tiếp cận trình lắng nghe. Phân quyền cơ sở dữ liệu quyết định một vai trò có thể dùng đối tượng và hành động nào.
Không cái nào trong ba cái thay thế cái khác, điều mà bảng nêu rõ.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Hãy đọc dòng mà bạn dựa vào trước khi bỏ một dòng khác. Phần lớn những thiết kế này thất bại vì một kiểm soát được giả định thay vì được cấu hình.
SQL trực tiếp để chính sách cơ sở dữ liệu chịu trách nhiệm
Với một kết nối trực tiếp đã được phê duyệt, hãy giữ cả việc xác minh danh tính dịch vụ và chính sách truy cập dự kiến. Bật TLS giúp các kết nối được mã hoá trở nên khả dụng; nó không từ chối những kết nối không mã hoá trừ khi cấu hình truy cập yêu cầu điều đó thông qua các mục hostssl.
Sự khác biệt đó đáng được kiểm tra trong cấu hình đang chạy chứ không phải trong một mẫu. Một máy chủ cung cấp TLS và chấp nhận văn bản thuần không phải là thiết kế mà phần lớn mọi người nghĩ rằng họ đã triển khai. Hãy đọc các quy tắc truy cập và xem những mục nào thực sự yêu cầu điều đó. Chính lần kiểm tra đó tách một máy chủ có khả năng mã hoá khỏi một máy chủ chỉ được mã hoá.
Chỉ dùng các vai trò có đúng những quyền mà công việc cần, và xem lại quyền sở hữu, tư cách thành viên kế thừa và các quyền được cấp rộng rãi. Mô hình quyền của PostgreSQL là ranh giới thẩm quyền cho các đối tượng cơ sở dữ liệu.
VPN có thể hạn chế thiết bị nào tiếp cận dịch vụ trước khi việc xác thực cơ sở dữ liệu diễn ra, và một cổng truy cập cũng có thể làm điều tương tự. Cả hai đều không loại bỏ nhu cầu bảo trì thành phần bị lộ, quản lý thông tin xác thực và giới hạn việc dùng tài nguyên.
Chứng chỉ khách hàng là một thông tin xác thực, không phải ACL
Một chứng chỉ khách hàng có thể thêm một yêu cầu tại thời điểm kết nối. Cấu hình clientcert có thể yêu cầu một chứng chỉ đáng tin cậy và, ở chế độ chặt chẽ hơn, một mối quan hệ giữa tên chứng chỉ và người dùng cơ sở dữ liệu.
Đó là một thông tin xác thực mạnh hơn. Nó không phải là danh sách uỷ quyền, và nó không làm máy chủ trở nên vô hình, vì thành phần nhận kết nối vẫn xử lý lưu lượng mạng và một lần bắt tay. Coi một chứng chỉ như danh sách truy cập để nguyên các quyền thực tế. Nó cũng có xu hướng mở rộng việc phân phối chứng chỉ, điều tạo ra vấn đề tiếp theo.
Một chứng chỉ mạnh gắn với một vai trò có quá nhiều quyền tạo ra một quản trị viên được xác thực tốt. Hãy kiểm tra vai trò trước khi ăn mừng chứng chỉ.
Chọn giao diện hẹp hơn khi nó phù hợp
Đối với một yêu cầu hoàn chi phí, một điểm cuối ứng dụng nhận yêu cầu, thực thi các quy tắc nghiệp vụ và trả về kết quả được phép của người dùng đó thể hiện thao tác tốt hơn một tài khoản SQL chung.
Sau đó ứng dụng dùng danh tính cơ sở dữ liệu bị hạn chế của chính nó, và khách hàng không bao giờ nhận được ngôn ngữ truy vấn như một tính năng. Đó là một bề mặt nhỏ hơn với ít cách sai hơn.
Đây là một lựa chọn thiết kế chứ không phải khẳng định rằng mã ứng dụng tự động an toàn hơn. Mã đó phải xác thực người gọi, uỷ quyền từng hành động và kiểm tra đầu vào của nó, và các quyền cơ sở dữ liệu của chính nó vẫn quan trọng.
SQL trực tiếp vẫn đúng cho những người và công cụ mà công việc đã được phê duyệt của họ đòi hỏi điều đó. Hãy giới hạn thiết kế đó bằng vai trò, phạm vi mạng và giới hạn vận hành, và để các khách hàng khác giữ giao diện hẹp hơn. Trộn hai nhóm người vào một vai trò là nơi các cuộc tranh luận bắt đầu.