Яке призначення бази даних "власник"?

Сьогодні, вирішуючи проблему сервісного брокера, я виявив, що власником бази даних є логін Windows працівника, який вийшов з компанії. Його логін було видалено, і таким чином повідомлення про запити не вдалося.

Імовірно, найкраща практика для вирішення цього питання - зробити "власника" власником бази даних. Ми це змінили, і це очистило чергу.

Моє (дуже елементарне) запитання: що таке власник бази даних і яка її мета?

Існує деяка плутанина між поняттями бази даних 'dbo' (користувач) і 'db_owner' (фіксована роль) з одного боку та екземплярною концепцією «власника бази даних» з іншого боку. 'Dbo' та 'db_owner' часто називають "власником бази даних". У тому, що ви запитуєте, ви говорите про власника бази даних як про головного сервера, який є власником бази даних.

Теорія виглядає так: усе, на що можна отримати дозволи, є "безпечним" . Усі захисні товари мають власника. Власник сейфу має абсолютний контроль над сейфом і йому не можна відмовити в будь-якій привілейованості. Охоронні знаки на рівні екземплярів належать принципалам серверів (логінам). Охоронні засоби на базі даних належать керівникам (користувачам) баз даних. Основні бувають двох кольорів: первинний (ідентичність) та вторинний (членство). За замовчуванням серверні засоби, що знаходяться на сервері, за замовчуванням належать головному головному серверу. Поточні основні бази даних за замовчуванням є власними засобами захисту даних бази даних, за винятком об'єктів, пов'язаних із схемою, які за замовчуванням належать власнику схеми. Усі захищені товари підтримують пункт АВТОРИЗАЦІЇ під час створення закону про застосування іншого власника.ALTER AUTHORIZATION пізніше можна використовувати для зміни власника будь-якого захищеного.

Оскільки база даних є серверним рівнем, це випливає, що за замовчуванням вона буде належати первинному принципалу, який видав операцію CREATE DATABASE. Тобто NT логін відрядженого працівника.

Тож ваше запитання справді " Для чого потрібні власники товарів? ". Тому що власник - корінь довіри. Саме власник надає, відмовляє та відкликає дозвіл на об’єкт. Чи може бути спроектована система безпеки без власників засобів безпеки? Можливо, так, але мав би бути якийсь механізм для заміни ролі власників у поточній моделі. Наприклад, врахуйте, що татові securables не мають власника (наприклад, замість того, щоб мати захищений файл, оригінальному творцю просто надається КОНТРОЛЬ над ним), можна було б створити захищений і скасувати доступ до нього всім , включаючи себе. Вимога власника обходить цю проблему, оскільки власник не може закрити себе.

Маловідомий побічний ефект СТВОРЕННЯ ДАТАБАЗИ створення безпечної (бази даних), що належить оригінальному входу в NT, спалив багато раніше. Правила однакові для кожного захищеного, але деякі фактори погіршують проблеми власника DATABASE:

• інші захисні засоби серверного рівня (кінцева точка, роль сервера, логін) дуже часто використовуються, переміщуються тощо.
• Охоронні засоби на рівні бази даних зазвичай закінчуються тим, що належить dbo(директору бази даних) або іншому директору бази даних, і таким чином власник міститься в базі даних
• Якщо за замовчуванням власник бази даних є основним основним принципом NT, він створює проблему з обмеженням (власник - NT SID, керований AD, і не подорожує з файлами баз даних, обліковий запис NT можна підключити тощо тощо)
• найголовніше: власник бази даних має важливі побічні ефекти, зокрема EXECUTE AS context. Ця пізніша проблема - це те, що спалює більшість користувачів. Оскільки Service Broker широко використовує EXECUTE AS (доставка повідомлень має неявний контекст EXECUTE AS, а також активацію черги, яка має явний), зазвичай користувачі Service Broker, які спочатку виявляють цю проблему.

BTW, Kudos для дослідження та виправлення первісної проблеми :)

База даних ownerтрохи відвертається до часу, перш ніж були введені (належні) схеми в SQL Sever 2005.

В основному власник бази даних є типовим dbo(власником) бази даних, при цьому сама база даних є об'єктом бази даних .

З документів SQL Server 2000 ...

Це dboкористувач, який мав на увазі дозволи на виконання всіх дій у базі даних.

У більш ранніх версіях SQL Server, коли схема не могла "володіти" об'єктом ( вірніше, слід зазначити, що всіма об'єктами, таблицями, представленнями тощо належать dboі інші схеми не було), це було необхідно для "користувач", щоб володіти ним ... це не повинно говорити, чому щось потрібно володіти базою даних (інакше дозволи взагалі були б досить важкими.)

Так, технічно для старих версій SQL Server (або оновлених баз даних) це була не таблиця "Foo", а таблиця "dbo.Foo" ... з тим, dboщо є власником.

З появою SQL Server 2005 у вас могли виникнути об'єкти бази даних, що належать схемі, наприклад, у вас є схема з назвою "бар" та таблиця з назвою "Foo" ... це стає bar.Fooяк у ...

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

Складна частина полягає в тому, що користувач, який створює базу даних, автоматично встановлюється як власник, що призводить до проблем із перекиданням співробітників тощо.

Тому найкращою практикою є або змінити це в saобліковому записі, або, можливо, (на мій досвід), на доменний рахунок, яким може керувати операційна / ІТ-команда організації.

Ця стаття надає розрив різниці між старішим "власницьким" способом роботи та новою системою власності на основі "схеми".

Щоб зрозуміти різницю між власниками та схемою, приділімо деякий час перегляду власності на об’єкт. Коли об’єкт створюється в SQL Server 2000 або новіших версіях, об'єкт повинен мати власника. Більшість часу власником є ​​"dbo", також відомий як власник бази даних.