Excel đến SQL Server của đối tác không có tin cậy miền

Một sổ làm việc Excel mở bảng trên SQL Server của tổ chức khác cần ba thứ thường được bàn như một: danh tính mà máy chủ chấp nhận, đường truyền mà máy khách xác thực, và đường mạng mà cả hai bên cho phép. Tin cậy miền là một cách đáp ứng điều đầu tiên, và là cách rộng nhất. TLS đáp ứng điều thứ hai và không nói gì về điều đầu. Đường đi đáp ứng điều thứ ba và tự nó không bảo vệ gì.

Tách ba điều này biến bảng tính thành một yêu cầu nhỏ, có thể xem xét thay vì một quan hệ hành chính.

Ba quyết định mà câu hỏi che giấu

Danh tính là việc cơ sở dữ liệu nghĩ bạn là ai: tài khoản Windows từ miền tin cậy, đăng nhập SQL với mật khẩu riêng, hoặc danh tính dựa trên chứng chỉ. Đường truyền là việc phiên có được mã hóa hay không và máy khách có kiểm tra chuỗi chứng chỉ của máy chủ hay không. Đường đi là cách các gói tin đến được trình lắng nghe, có thể là VPN, liên kết riêng hoặc điểm cuối công khai với quy tắc tường lửa. Mỗi thứ sống ở một nơi khác nhau và mỗi thứ có thể thất bại riêng.

Tin cậy rừng trả lời điều đầu một cách rộng rãi và là quan hệ giữa các tổ chức, không phải thiết lập cho một sổ làm việc. Nó cũng không mã hóa gì, điều khiến những người cho rằng tin cậy chính là kiểm soát bảo mật phải ngạc nhiên.

Danh tính không có tin cậy rừng

Một tài khoản được cấp có chủ đích trong môi trường đích có thể đáp ứng yêu cầu hẹp hơn mà không cần tin cậy nào, miễn là quy trình của máy khách dùng được nó. Xác thực SQL là câu trả lời phổ biến khác khi chính sách cho phép: đăng nhập mang vòng đời thông tin xác thực riêng và không tham gia miền cũng không tạo xác thực tích hợp Windows. Danh tính dựa trên chứng chỉ hoặc mã thông báo là lựa chọn thứ ba trên nền tảng mới hơn. Dù chọn gì, chỉ cấp những quyền cơ sở dữ liệu mà sổ làm việc thực sự cần.

Ưu tiên tài khoản chuyên dụng hơn đăng nhập cá nhân của ai đó. Thông tin xác thực dùng chung trong bảng tính là một vấn đề hỗ trợ đang chờ xảy ra, và tài khoản có tên giúp việc thu hồi trở nên khả thi khi dự án kết thúc.

Mã hóa thì có, nhưng có tin chứng chỉ không?

Với ODBC Driver 18, Encrypt=Yes;TrustServerCertificate=No yêu cầu một phiên được mã hóa mà chứng chỉ thực sự được kiểm tra. Chuỗi kết nối sau đó phải nêu tên máy chủ mà chứng chỉ bao phủ, và máy khách phải tin chuỗi của nó. Driver 18 cũng mã hóa theo mặc định, khác với các phiên bản trước, nên một chuỗi kết nối cũ giờ có thể thương lượng TLS mà không nói ra. Các thiết lập rõ ràng làm cho chính sách dự định hiển thị trên mọi máy, điều quan trọng khi nhiều người cùng duy trì một sổ làm việc.

TrustServerCertificate=Yes mã hóa và bỏ qua xác thực, đây không phải là cách sửa tương đương cho việc tên không khớp hoặc chuỗi không đáng tin. Nó loại bỏ tín hiệu lẽ ra cho bạn biết máy khách đã đến sai điểm cuối, vì vậy hãy sửa chứng chỉ hoặc tên.

Việc thực thi phía máy chủ là một kiểm soát riêng. Nếu mã hóa phải áp dụng cho mọi máy khách, hãy cấu hình và xác minh thiết lập buộc mã hóa của máy chủ, vì một chuỗi kết nối hợp tác không thực thi được gì.

Đường mạng không phải là sự bảo vệ

Một trình lắng nghe riêng tiếp cận qua VPN làm giảm phơi nhiễm, và VPN phải mang đúng tuyến đích và tuyến quay về để điều đó hoạt động. Một đường hầm hoạt động không loại bỏ nhu cầu xác thực hay xác thực chứng chỉ, và TLS không hạn chế hệ thống từ xa nào được thử kết nối. Đó là ba quan sát riêng biệt: bắt tay TLS, đăng nhập VPN và truy vấn được cấp quyền. Chỉ quan sát thứ ba chứng minh sổ làm việc đã đọc dữ liệu mà nó được phép đọc.

Vì vậy hãy chống lại lối tắt trả lời câu hỏi tin cậy bằng cách phơi cơ sở dữ liệu ra internet. Câu trả lời hẹp thường là tài khoản chuyên dụng, mã hóa đã xác thực và một đường đi được phê duyệt, theo đúng thứ tự đó.

Xác minh bằng quy trình Excel thông thường: danh tính được chấp nhận, quyền hiệu lực và mã hóa đã thương lượng, mỗi thứ qua chế độ xem phiên của chính máy chủ.