Kiểm soát khả năng hiển thị tên cơ sở dữ liệu trong các phiên bản Amazon RDS for SQL Server

Tác giả: Alex Pawvathil và Swarndeep Singh
Ngày phát hành: 20 JAN 2026
Chuyên mục: Advanced (300), Amazon RDS, RDS for SQL Server, Technical How-to

Môi trường SQL Server đa đối tượng thuê (multi-tenant) đối mặt với thách thức kiến trúc khi tên cơ sở dữ liệu bị lộ có thể tiết lộ thông tin nhạy cảm của đối tượng thuê. SQL Server chạy tại chỗ (on-premises) hoặc tự quản lý trên Amazon Elastic Compute Cloud (Amazon EC2) có thể giải quyết thách thức này bằng cách từ chối thủ công các quyền cấp máy chủ (server-level permissions) cho các login cụ thể. Trong Amazon Relational Database Service (Amazon RDS) for SQL Server, khả năng hiển thị cơ sở dữ liệu được cấu hình bằng một stored procedure chuyên dụng.

Theo mặc định, vai trò PUBLIC của SQL Server cho phép người dùng đã xác thực xem tất cả tên cơ sở dữ liệu, một tính năng nhằm mục đích minh bạch nhưng có thể trở thành mối lo ngại đáng kể trong kiến trúc đa đối tượng thuê. Đối với các nhà cung cấp phần mềm độc lập (ISV) và nhà cung cấp phần mềm dưới dạng dịch vụ (SaaS) đang lưu trữ nhiều cơ sở dữ liệu khách hàng trên cùng một phiên bản, hành vi mặc định này đòi hỏi sự cân nhắc kỹ lưỡng và các chiến lược giảm thiểu để bảo vệ danh tính của đối tượng thuê.

Trong bài viết này, chúng tôi trình bày cách ly đối tượng thuê ở cấp độ hiển thị, ngăn đối tượng thuê nhìn thấy tên cơ sở dữ liệu thuộc về các khách hàng khác trong khi vẫn duy trì quyền truy cập của họ vào tài nguyên của chính họ.

Tổng quan giải pháp

Giải pháp này giải quyết một cân nhắc kiến trúc quan trọng trong môi trường SQL Server đa đối tượng thuê, nơi tên cơ sở dữ liệu có thể tiết lộ thông tin đối tượng thuê. Bằng cách sử dụng stored procedure tùy chỉnh của Amazon RDS for SQL Server msdb.dbo.rds_manage_view_db_permission, người dùng có thể kiểm soát hiệu quả khả năng hiển thị cơ sở dữ liệu trên cơ sở từng login trong khi vẫn duy trì đầy đủ chức năng ứng dụng.

Điều quan trọng là, giải pháp này chỉ quản lý khả năng hiển thị cơ sở dữ liệu; các login có quyền cơ sở dữ liệu thích hợp vẫn có thể truy cập và sử dụng đầy đủ các cơ sở dữ liệu theo quyền được cấp của họ, ngay cả khi họ không thể nhìn thấy tên cơ sở dữ liệu trong SQL Server Management Studio (SSMS) hoặc các client SQL Server khác. Điều này đặc biệt có giá trị đối với các nhà cung cấp SaaS và ISV lưu trữ cơ sở dữ liệu đa đối tượng thuê trên các phiên bản dùng chung.

Việc triển khai tuân theo các bước cấp cao sau:

Chuẩn bị phiên bản RDS for SQL Server với các cơ sở dữ liệu và login đa đối tượng thuê.
Áp dụng stored procedure tùy chỉnh để từ chối khả năng hiển thị cơ sở dữ liệu cho các login cụ thể.
Xác thực cấu hình bằng cách xác nhận khả năng hiển thị bị hạn chế.
Duy trì khả năng hoàn tác các thay đổi khi cần.

Giải pháp này tăng cường tư thế bảo mật bằng cách giảm thiểu rủi ro tiết lộ thông tin và cung cấp trải nghiệm đối tượng thuê rõ ràng mà không làm lộ tên cơ sở dữ liệu cho đối tượng thuê. Các sơ đồ sau minh họa tư thế bảo mật trước và sau khi triển khai.

Diagram comparing Amazon RDS for SQL Server database visibility before and after hiding tenant database names for improved security

Điều kiện tiên quyết

Bạn phải có các điều kiện tiên quyết sau:

Truy cập vào tài khoản AWS
Hiểu biết cơ bản về SQL Server và các khái niệm bảo mật
Một phiên bản DB RDS for SQL Server và thông tin login để kết nối với nó

Việc triển khai Amazon RDS for SQL Server sẽ phát sinh chi phí. Hãy xem lại Giá AWS trước khi tiếp tục.

Chuẩn bị phiên bản RDS for SQL Server

Tạo hai cơ sở dữ liệu và hai login mới, sau đó cấp các quyền thích hợp:

Tạo một phiên bản RDS for SQL Server bằng cách sử dụng AWS CLI hoặc AWS Management Console.
Kết nối với phiên bản RDS for SQL Server bằng login Primary.
Tạo hai cơ sở dữ liệu, Tenant1DB và Tenant2DB:
sql CREATE DATABASE Tenant1DB GO CREATE DATABASE Tenant2DB GO
Tạo hai login, Tenant1 và Tenant2:
sql USE [master] GO CREATE LOGIN [Tenant1] WITH PASSWORD=N'xxxxxx' GO USE [master] GO CREATE LOGIN [Tenant2] WITH PASSWORD=N'xxxxxx' GO
Cấp quyền cho Tenant1 đối với Tenant1DB:
sql USE [Tenant1DB] GO CREATE USER [Tenant1] FOR LOGIN [Tenant1] GO USE [Tenant1DB] GO ALTER ROLE [db_owner] ADD MEMBER [Tenant1] GO
Cấp quyền cho Tenant2 đối với Tenant2DB:
sql USE [Tenant2DB] GO CREATE USER [Tenant2] FOR LOGIN [Tenant2] GO USE [Tenant2DB] GO ALTER ROLE [db_owner] ADD MEMBER [Tenant2] GO

Xem xét quyền cơ sở dữ liệu

Đăng nhập bằng login của từng đối tượng thuê và xác thực hành vi mặc định là tất cả tên cơ sở dữ liệu đều hiển thị:

Mở SSMS.
Đăng nhập bằng Tenant1.
Mở rộng thư mục Databases.
Xác nhận rằng Tenant1 có thể nhìn thấy tất cả tên cơ sở dữ liệu.
Tương tự, đăng nhập vào phiên bản bằng Tenant2.
Xác nhận Tenant2 có thể nhìn thấy tất cả tên cơ sở dữ liệu.

Sửa đổi quyền xem tên cơ sở dữ liệu

Trong phần này, bạn áp dụng stored procedure tùy chỉnh của Amazon RDS for SQL Server để thay đổi khả năng hiển thị cơ sở dữ liệu cho các login:

Kết nối với phiên bản bằng login Primary.
Thực thi script sau:
sql EXEC msdb.dbo.rds_manage_view_db_permission @permission='DENY', @server_principal='Tenant1'

Như đã nêu trước đó, stored procedure không kiểm soát quyền cơ sở dữ liệu; thay vào đó, nó chỉ ẩn tên cơ sở dữ liệu.

Xác thực quyền xem tên cơ sở dữ liệu

Bây giờ bạn có thể xác thực rằng Tenant1 không còn nhìn thấy tên cơ sở dữ liệu nữa:

Tên cơ sở dữ liệu đã bị ẩn. Tuy nhiên, nếu bạn kết nối với phiên bản bằng login Tenant2, bạn sẽ thấy tên cơ sở dữ liệu. Lý do là stored procedure tùy chỉnh chưa được áp dụng cho login Tenant2.

SQL Server Management Studio Object Explorer for Tenant2 showing visible database names including rdsadmin, Tenant1DB, and Tenant2DB with annotation highlighting database visibility

Tên cơ sở dữ liệu hiển thị.

Hoàn tác thay đổi

Để hoàn tác các thay đổi, hãy hoàn thành các bước sau:

Hoàn tác các thay đổi bằng cách chạy lệnh sau:

			
EXEC msdb.dbo.rds_manage_view_db_permission 
    @permission='GRANT', 
    @server_principal='Tenant1'

Đăng xuất và mở một phiên truy vấn (query session) mới tới RDS instance bằng tài khoản đăng nhập Tenant1.
Xác nhận rằng bạn có thể nhìn thấy lại tên các cơ sở dữ liệu.

Tên cơ sở dữ liệu đang được hiển thị.

Hạn chế

Giải pháp này có các hạn chế và cân nhắc vận hành chính sau:

Khi một login bị xóa và tạo lại, stored procedure phải được thực thi lại để áp dụng lại quyền.
Stored procedure này không quản lý quyền truy cập cơ sở dữ liệu; quyền truy cập cơ sở dữ liệu vẫn phải được quản lý riêng thông qua các biện pháp bảo mật thích hợp.
Tên cơ sở dữ liệu có thể vẫn hiển thị trong các dấu vết SQL Server (SQL Server traces), nhật ký lỗi (error logs) và các dynamic management views (DMVs) cụ thể, ngay cả khi quyền này được áp dụng.
Khi quyền bị thu hồi, tên cơ sở dữ liệu sẽ hiển thị cho login đó.
Quyền được đặt ở cấp độ máy chủ (server level). Khi một cơ sở dữ liệu được khôi phục sang một phiên bản mới bằng phương pháp khôi phục, các quyền phải được áp dụng lại.
Kiểm soát khả năng hiển thị tên cơ sở dữ liệu không thể áp dụng cho login Primary; tất cả tên cơ sở dữ liệu sẽ luôn hiển thị cho login Primary.

Dọn dẹp

Nếu bạn đã tạo một cơ sở dữ liệu thử nghiệm để thực hiện theo hướng dẫn này, hãy đảm bảo dọn dẹp tài nguyên để tránh các khoản phí không cần thiết. Xóa người dùng, login và cơ sở dữ liệu thử nghiệm khỏi phiên bản RDS for SQL Server của bạn. Nếu bạn đã tạo một phiên bản RDS hoặc máy chủ EC2 cụ thể cho bản demo này, hãy xóa các tài nguyên này thông qua bảng điều khiển Amazon RDS và Amazon EC2 tương ứng, nếu chúng không còn được sử dụng. Điều này sẽ giúp tránh phát sinh các khoản phí không mong muốn.

Kết luận

Trong bài viết này, chúng tôi đã trình bày cách quản lý khả năng hiển thị tên cơ sở dữ liệu trong môi trường đa đối tượng thuê bằng Amazon RDS for SQL Server. Chúng tôi đã hướng dẫn quy trình ẩn tên cơ sở dữ liệu bằng cách sử dụng stored procedure tùy chỉnh của Amazon RDS for SQL Server, giúp ngăn các đối tượng thuê khác trên cùng một máy chủ nhìn thấy thông tin khách hàng có khả năng nhạy cảm có thể bị tiết lộ thông qua tên cơ sở dữ liệu. Bạn có thể áp dụng giải pháp này để kiểm soát khả năng hiển thị tên cơ sở dữ liệu trong môi trường Amazon RDS for SQL Server của mình trong khi vẫn duy trì các quyền truy cập cần thiết cho ứng dụng của bạn.

Để tìm hiểu thêm về các tác vụ DBA phổ biến dành riêng cho Amazon RDS, hãy tham khảo Các tác vụ DBA phổ biến cho Amazon RDS for Microsoft SQL Server.

Về tác giả

Swarndeep Singh

Swarndeep là Kiến trúc sư Giải pháp Chuyên biệt Cơ sở dữ liệu cấp cao tại AWS. Với hơn 20 năm kinh nghiệm trong kỹ thuật và kiến trúc cơ sở dữ liệu, Swarndeep Singh chuyên cung cấp các giải pháp đổi mới trên các công cụ cơ sở dữ liệu thương mại và mã nguồn mở.

Alex Pawvathil

Alex là Quản lý Tài khoản Kỹ thuật cấp cao tại AWS, chuyên về các giải pháp và triển khai cơ sở dữ liệu. Với hơn 14 năm kinh nghiệm trong kỹ thuật cơ sở dữ liệu và công nghệ SQL Server, ông là chuyên gia về triển khai Amazon RDS for SQL Server và các triển khai quy mô doanh nghiệp.