Mục đích của cơ sở dữ liệu 'chủ sở hữu' là gì?

Hôm nay trong khi xử lý sự cố một nhà môi giới dịch vụ, tôi phát hiện ra rằng chủ sở hữu cơ sở dữ liệu là thông tin đăng nhập Windows của một nhân viên đã rời công ty. Thông tin đăng nhập của anh ta đã bị xóa và do đó các thông báo truy vấn không thành công.

Được cho là cách thực hành tốt nhất để xử lý vấn đề này là biến 'sa' thành chủ sở hữu cơ sở dữ liệu. Chúng tôi đã thay đổi nó và xóa hàng đợi.

Câu hỏi (rất cơ bản) của tôi: chủ sở hữu cơ sở dữ liệu là gì và mục đích của nó là gì?

Có một số nhầm lẫn giữa các khái niệm cơ sở dữ liệu của 'dbo' (người dùng) và 'db_owner' (một vai trò cố định) ở một bên và khái niệm ví dụ về 'chủ sở hữu cơ sở dữ liệu' ở phía bên kia. 'Dbo' và 'db_owner' thường được gọi là 'chủ sở hữu cơ sở dữ liệu'. Trong những gì bạn đang hỏi, bạn đang nói về chủ sở hữu cơ sở dữ liệu với tư cách là hiệu trưởng máy chủ sở hữu cơ sở dữ liệu.

Lý thuyết diễn ra như sau: bất cứ điều gì có thể được cấp quyền là 'an toàn' . Tất cả các bảo mật có một chủ sở hữu. Chủ sở hữu của bảo mật có quyền kiểm soát tuyệt đối đối với bảo mật và không thể bị từ chối bất kỳ quyền riêng tư nào. Bảo mật cấp độ sơ thẩm được sở hữu bởi hiệu trưởng máy chủ (đăng nhập). Bảo mật cấp cơ sở dữ liệu được sở hữu bởi hiệu trưởng cơ sở dữ liệu (người dùng). Hiệu trưởng có hai hương vị: chính (bản sắc) và thứ cấp (thành viên). Bảo mật cấp máy chủ theo mặc định thuộc sở hữu của hiệu trưởng máy chủ chính hiện đang đăng nhập. Bảo mật mức cơ sở dữ liệu được sở hữu theo mặc định bởi hiệu trưởng cơ sở dữ liệu hiện tại, ngoại trừ các đối tượng ràng buộc lược đồ mà theo mặc định được sở hữu bởi chủ sở hữu lược đồ. Tất cả các bảo mật đều hỗ trợ mệnh đề AUTHORIZATION tại thời điểm tạo để thực thi một chủ sở hữu khác.ALTER AUTHORIZATION sau này có thể được sử dụng để thay đổi chủ sở hữu của bất kỳ bảo mật.

Vì cơ sở dữ liệu là cấp độ bảo mật của máy chủ, theo mặc định, nó sẽ được sở hữu bởi hiệu trưởng chính đã ban hành câu lệnh CREATE DATABASE. I E. đăng nhập NT của nhân viên đã rời đi.

Vì vậy, câu hỏi của bạn thực sự là " Tại sao bảo mật cần có chủ sở hữu? ". Bởi vì chủ sở hữu là gốc rễ của niềm tin. Đó là chủ sở hữu cấp, từ chối và thu hồi sự cho phép trên đối tượng. Một hệ thống an ninh có thể được thiết kế mà không có chủ sở hữu bảo mật? Có lẽ là có, nhưng sẽ phải có một số cơ chế để thay thế các chủ sở hữu vai trò trong mô hình hiện tại. Ví dụ, xem xét rằng bảo mật của cha không có chủ sở hữu (ví dụ: thay vì sở hữu bảo mật, người tạo ban đầu chỉ được cấp KIỂM SOÁT đối với nó), có thể tạo ra quyền truy cập an toàn và thu hồi quyền truy cập đối với mọi người , kể cả chính anh ta. Yêu cầu của chủ sở hữu giải quyết vấn đề này vì chủ sở hữu không thể tự khóa.

Tác dụng phụ ít được biết đến của CREATE DATABASE trong việc tạo một bảo mật (cơ sở dữ liệu) thuộc sở hữu của đăng nhập NT gốc đã bị đốt cháy nhiều trước đó. Các quy tắc là giống nhau cho mọi bảo mật, nhưng một số yếu tố làm trầm trọng thêm các vấn đề của chủ sở hữu DATABASE:

• các bảo mật cấp máy chủ khác (điểm cuối, vai trò máy chủ, đăng nhập) hiếm khi được sử dụng, di chuyển xung quanh, v.v.
• Bảo mật mức cơ sở dữ liệu thường kết thúc bằng việc được sở hữu bởi dbo(hiệu trưởng cơ sở dữ liệu) hoặc một số hiệu trưởng cơ sở dữ liệu khác, và do đó, chủ sở hữu được chứa trong cơ sở dữ liệu
• Có quyền sở hữu cơ sở dữ liệu mặc định cho hiệu trưởng chính NT tạo ra vấn đề ngăn chặn (chủ sở hữu là NT SID được quản lý bởi AD và không di chuyển với các tệp cơ sở dữ liệu, tài khoản NT có thể được xử lý, v.v.)
• điều quan trọng nhất: chủ sở hữu cơ sở dữ liệu có tác dụng phụ quan trọng, cụ thể là EXECUTE AS context. Vấn đề sau này là những gì đốt cháy hầu hết người dùng. Vì Nhà môi giới dịch vụ sử dụng rộng rãi EXECUTE AS (việc gửi tin nhắn có bối cảnh EXECUTE AS ngầm định, cũng như kích hoạt hàng đợi có một thứ rõ ràng) thường là người dùng Nhà môi giới dịch vụ phát hiện ra vấn đề này trước tiên.

BTW, Kudos để điều tra và khắc phục sự cố ban đầu của bạn :)

Cơ sở dữ liệu ownerlà một chút quay trở lại một thời gian trước khi lược đồ (thích hợp) được giới thiệu trong SQL Sever 2005.

Về cơ bản, chủ sở hữu cơ sở dữ liệu là mặc định dbo(chủ sở hữu cơ sở dữ liệu) của cơ sở dữ liệu, với cơ sở dữ liệu là đối tượng cơ sở dữ liệu .

Từ tài liệu SQL Server 2000 ...

Người dbodùng đã ngụ ý các quyền để thực hiện tất cả các hoạt động trong cơ sở dữ liệu.

Trong các phiên bản trước của SQL Server, khi một lược đồ không thể "sở hữu" một đối tượng ( hay đúng hơn nên nói rằng tất cả các đối tượng, bảng, khung nhìn, v.v. đều thuộc sở hữu dbovà không có lược đồ nào khác ) cần thiết cho một "user" để sở hữu nó ... nó nên đi mà không nói lý do tại sao một cái gì đó cần phải sở hữu cơ sở dữ liệu (hoặc quyền khác nói chung sẽ là khá khó khăn.)

Vì vậy, về mặt kỹ thuật trong các phiên bản cũ hơn của SQL Server (hoặc cơ sở dữ liệu được nâng cấp), đó không phải là bảng "Foo", đó là bảng "dbo.Foo" ... với dbochủ sở hữu.

Với sự ra đời của SQL Server 2005, bạn có thể có các đối tượng cơ sở dữ liệu thuộc sở hữu lược đồ như nói rằng bạn có một lược đồ có tên là "thanh" và bảng có tên "Foo" ... điều này trở thành bar.Foonhư trong ...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

Phần khó khăn đi kèm với thực tế là người dùng tạo cơ sở dữ liệu được tự động đặt làm chủ sở hữu dẫn đến các vấn đề với nhân viên chuyển qua, v.v.

Do đó, cách tốt nhất là thay đổi điều này thành satài khoản hoặc có lẽ (theo kinh nghiệm của tôi) thành tài khoản miền có thể được quản lý bởi nhóm ops / IT của tổ chức.

Bài viết này phân tích sự khác biệt giữa cách làm "chủ sở hữu" cũ hơn và hệ thống sở hữu dựa trên "lược đồ" mới hơn.

Để hiểu sự khác biệt giữa chủ sở hữu và lược đồ, hãy dành thời gian xem xét quyền sở hữu đối tượng. Khi một đối tượng được tạo trong SQL Server 2000 trở về trước, đối tượng phải có chủ sở hữu. Hầu hết thời gian, chủ sở hữu là người hâm mộ, hay còn gọi là chủ sở hữu cơ sở dữ liệu.