Sử dụng Microsoft SQL Server một cách an toàn với Power Apps
Có nhiều cách khác nhau để kết nối và xác thực với SQL Server bằng Power Apps. Bài viết này trình bày các khái niệm có thể hữu ích trong việc đưa ra lựa chọn về cách kết nối với SQL Server bằng phương pháp bảo mật phù hợp với các yêu cầu cho ứng dụng của bạn.
Quan trọng
Tính năng kết nối ngầm an toàn đã được phát hành vào tháng 1 năm 2024. Microsoft khuyến khích tất cả ứng dụng hiện đang sử dụng kết nối ngầm chuyển sang kết nối ngầm an toàn và thu hồi các kết nối được chia sẻ với người dùng cuối.
Sự khác biệt giữa các kết nối ngầm rõ ràng, ngầm ẩn và ngầm an toàn
Kết nối với SQL Server được tạo bất cứ khi nào bạn tạo ứng dụng bằng Power Apps kết nối với SQL Server. Khi các ứng dụng đó được xuất bản và chia sẻ với những người khác, cả ứng dụng và kết nối đều được triển khai cho những người dùng đó. Nói cách khác, ứng dụng và kết nối—cả hai đều hiển thị với người dùng mà ứng dụng được chia sẻ.
Phương thức xác thực được sử dụng cho các kết nối như vậy có thể rõ ràng hoặc ẩn. Chúng tôi cũng có thể nói rằng kết nối như vậy được chia sẻ một cách rõ ràng hoặc ẩn.
- Kết nối được chia sẻ rõ ràng có nghĩa là người dùng cuối của ứng dụng phải xác thực SQL Server bằng thông tin xác thực rõ ràng của riêng họ. Thông thường, quá trình xác thực này diễn ra ở chế độ ẩn như một phần của Microsoft Entra hoặc quá trình bắt tay xác thực Windows. Người dùng thậm chí không nhận thấy khi xác thực diễn ra.
- Kết nối được chia sẻ ẩn nghĩa là người dùng hoàn toàn sử dụng thông tin đăng nhập của tài khoản mà nhà sản xuất ứng dụng đã sử dụng để kết nối và xác thực với nguồn dữ liệu trong khi tạo ứng dụng. Thông tin đăng nhập của người dùng cuối không dùng để xác thực. Mỗi khi người dùng cuối chạy ứng dụng, họ đang sử dụng thông tin đăng nhập mà tác giả đã tạo ứng dụng.
- Kết nối được chia sẻ ngầm bảo mật đề cập đến tình huống mà người dùng cuối của ứng dụng ngầm sử dụng thông tin đăng nhập của tài khoản mà nhà sản xuất ứng dụng đã dùng để kết nối và xác thực với nguồn dữ liệu khi tạo ứng dụng. Điều này có nghĩa là thông tin đăng nhập của người dùng cuối không được sử dụng để xác thực. Thay vào đó, khi người dùng chạy ứng dụng, họ sẽ sử dụng thông tin đăng nhập mà tác giả ứng dụng đã tạo ra. Điều quan trọng cần lưu ý là người dùng cuối không được cấp quyền truy cập trực tiếp vào kết nối và ứng dụng chỉ cho phép truy cập vào một số hành động và bảng giới hạn.
Bốn kiểu xác thực kết nối sau đây có thể được sử dụng với SQL Server cho Power Apps:
| Loại xác thực | Phương thức kết nối Power Apps |
|---|---|
| Microsoft Entra Tích hợp | Rõ ràng |
| Xác thực SQL Server | Ngầm định / Bảo mật Ngầm định |
| Xác thực Windows | Ngầm định / Bảo mật Ngầm định |
| Xác thực Windows (không chia sẻ) | Rõ ràng |
Rủi ro chia sẻ kết nối ẩn
Tất cả các ứng dụng mới đều tự động sử dụng kết nối ngầm an toàn mới. Tuy nhiên, với các ứng dụng sử dụng 'kết nối ngầm' cũ, cả ứng dụng và kết nối của nó đều được triển khai tới người dùng cuối, điều này có nghĩa là người dùng cuối có thể tạo các ứng dụng mới dựa trên các kết nối đó.
Khi tác giả sử dụng kết nối ngầm an toàn, điều đó có nghĩa là không có kết nối nào được chia sẻ và không có người dùng cuối nào nhận được đối tượng kết nối. Điều này loại bỏ nguy cơ tác giả là người dùng cuối sử dụng lại kết nối để tạo ứng dụng mới. Thay vào đó, ứng dụng hoạt động với kết nối proxy nhận biết ứng dụng và chỉ giao tiếp với ứng dụng cụ thể đó. Kết nối proxy cho phép thực hiện các hành động hạn chế (tạo, đọc, cập nhật, xóa) và truy cập vào các bảng cụ thể trong ứng dụng được xác định khi ứng dụng được phát hành. Do đó, chỉ những hành động và quyền truy cập được ủy quyền mới được cấp cho người dùng cuối.
Kết nối ngầm đơn giản theo kiểu cũ thực chất phân phối một đối tượng kết nối tới người dùng cuối. Ví dụ, nếu bạn tạo một ứng dụng có chức năng lọc dữ liệu mà bạn không muốn người dùng nhìn thấy. Tuy nhiên, dữ liệu đã lọc vẫn có trong cơ sở dữ liệu. Nhưng bạn đang dựa vào bộ lọc mà bạn đã định cấu hình để đảm bảo người dùng cuối sẽ không nhìn thấy một số dữ liệu nhất định.
Một lần nữa, với các kết nối ngầm đơn giản theo kiểu cũ, sau khi bạn triển khai ứng dụng, người dùng cuối có thể sử dụng kết nối được triển khai với ứng dụng của bạn trong bất kỳ ứng dụng mới nào họ tạo. Trong các ứng dụng mới, người dùng có thể xem dữ liệu bạn đã lọc ra trong ứng dụng của mình. Điều quan trọng là phải sử dụng các kết nối ngầm an toàn mới.
Quan trọng
Khi kết nối chia sẻ ngầm cũ được triển khai cho người dùng cuối, các hạn chế bạn có thể đã đặt trong ứng dụng đã chia sẻ (chẳng hạn như bộ lọc hoặc quyền truy cập chỉ đọc) sẽ không còn hiệu lực đối với các ứng dụng mới do người dùng cuối tạo ra. Người dùng cuối sẽ có bất kỳ quyền nào mà xác thực cho phép như một phần của kết nối được chia sẻ ẩn. Do đó, khi bạn chuyển đổi ứng dụng để sử dụng kết nối ngầm an toàn, bạn cũng phải thu hồi các kết nối đã chia sẻ với ứng dụng của mình. Quản trị viên có thể nhận báo cáo về các ứng dụng có kết nối được chia sẻ ngầm bằng bộ công cụ COE.
Bảo mật máy khách và máy chủ
Bạn không thể dựa vào tính bảo mật của dữ liệu thông qua lọc hoặc các hoạt động phía máy khách khác để được bảo mật. Các ứng dụng yêu cầu lọc dữ liệu an toàn phải đảm bảo rằng cả nhận dạng và lọc người dùng đều diễn ra trên máy chủ.
Sử dụng các dịch vụ như Microsoft Entra ID thay vì dựa vào các bộ lọc được thiết kế trong ứng dụng khi nói đến danh tính và bảo mật người dùng. Cấu hình này đảm bảo các bộ lọc phía máy chủ hoạt động như mong đợi.
Các hình minh họa sau đây giải thích sự khác biệt giữa các mô hình bảo mật trong ứng dụng giữa các mô hình bảo mật phía máy khách và phía máy chủ.
Trong một mẫu ứng dụng bảo mật máy khách, [1] người dùng chỉ xác thực với ứng dụng ở phía máy khách. Sau đó, [2] ứng dụng yêu cầu thông tin của dịch vụ và [3] dịch vụ trả về thông tin chỉ dựa trên yêu cầu dữ liệu.
Trong mẫu bảo mật phía máy chủ, [1] đầu tiên người dùng xác thực với dịch vụ để người dùng biết đến dịch vụ. Sau đó, [2] khi một cuộc gọi được thực hiện từ ứng dụng, dịch vụ [3] sử dụng danh tính đã biết của người dùng hiện tại để lọc dữ liệu một cách thích hợp và [4] trả về dữ liệu.
Các kịch bản chia sẻ bộ phận ngầm định được mô tả ở trên là sự kết hợp của hai mẫu này. Người dùng phải đăng nhập vào dịch vụ bằng thông tin đăng nhập. Power Apps Microsoft Entra Hành vi này là mẫu ứng dụng bảo mật máy chủ. Người dùng được biết đến bằng cách sử dụng Microsoft Entra danh tính trên dịch vụ. Do đó, ứng dụng bị hạn chế đối với nhóm người dùng Power Apps đã chính thức chia sẻ ứng dụng.
Tuy nhiên, kết nối được chia sẻ ngầm tới SQL Server là mẫu ứng dụng bảo mật máy khách. SQL Server chỉ biết rằng một tên người dùng và mật khẩu cụ thể được sử dụng. Chẳng hạn, bất kỳ quá trình lọc phía máy khách nào cũng có thể bị bỏ qua bằng một ứng dụng mới sử dụng cùng một tên người dùng và mật khẩu.
Để lọc dữ liệu ở phía máy chủ một cách an toàn, hãy sử dụng các tính năng bảo mật tích hợp sẵn trong SQL Server, chẳng hạn như bảo mật cấp độ hàng cho các hàng và phủ nhận quyền đối với các đối tượng cụ thể (chẳng hạn như cột) cho người dùng cụ thể. Phương pháp này sử dụng danh tính người dùng để lọc dữ liệu trên máy chủ. Microsoft Entra
Một số dịch vụ công ty hiện có đã sử dụng phương pháp tiếp cận trong đó danh tính người dùng được thu thập trong một lớp dữ liệu kinh doanh giống như cách Microsoft Dataverse làm. Trong trường hợp này, lớp nghiệp vụ có thể hoặc không sử dụng bảo mật cấp hàng của SQL Server và từ chối các tính năng trực tiếp. Nếu không, thường là trường hợp bảo mật được kích hoạt bằng cách sử dụng các dạng xem hoặc thủ tục lưu trữ.
Doanh nghiệp tầng (ở phía máy chủ) sử dụng danh tính người dùng Microsoft Entra đã biết để gọi một quy trình được lưu trữ dưới dạng đối tượng chính của SQL Server và lọc dữ liệu. Tuy nhiên, Power Apps hiện không kết nối với các thủ tục lưu trữ. Một doanh nghiệp tầng cũng có thể gọi một chế độ xem sử dụng Microsoft Entra danh tính làm đối tượng chính của SQL Server. Trong trường hợp này, hãy sử dụng Power Apps để kết nối với các dạng xem để dữ liệu được lọc ở phía máy chủ. Chỉ hiển thị các dạng xem cho người dùng có thể cần quy trình Power Automate để cập nhật.