Розглядається система безпеки, прийнята в мові SQL. Викладаються загальні правила розмежування доступу. Описуються режими автентифікації та компоненти структури безпеки (користувачі, ролі баз даних), адміністрування системи безпеки (створення облікових записів та керування ними, керування користувачами та ролями). Надається визначення прав користувача на доступ до об'єктів бази даних. Розглядаються неявні права, питання заборони доступу та неявного відхилення доступу та конфлікти доступу.

Керування користувачами бази даних

Стабільна система управління користувачами – обов'язкова умова безпеки даних, що зберігаються в будь-якій реляційної СУБД. У мові SQL немає єдиної стандартної команди, призначеної для створення користувачівбази даних – кожна реалізація робить це по-своєму. В одних реалізаціях ці спеціальні команди мають певну схожість, тоді як в інших їхній синтаксис має суттєві відмінності. Однак незалежно від конкретної реалізації всі основні засади однакові.

Управління користувачами серед MS SQL Server

Розглянемо питання створення користувачіву середовищі MS SQL Server.

Після проектування логічної структури бази даних, зв'язків між таблицями, обмежень цілісності та інших структур необхідно визначити коло користувачів, які матимуть доступ до бази даних.

У системі SQL-сервер організовано дворівневе налаштування обмеження доступу до даних. На першому рівні необхідно створити так звану обліковий запис користувача(login), що дозволяє йому підключитися до сервера, але не дає автоматичного доступу до баз даних. На другому рівні для кожної бази даних SQL-сервера на основі облікового запису необхідно створити запис користувача. На основі прав , виданих користувачеві як користувачеві бази даних (user), його реєстраційне ім'я (login) отримує доступ до відповідної бази даних. У різних базах даних login одного і того ж користувача може мати однакові або різні імена userз різними правами доступу. Інакше кажучи, за допомогою облікового запису користувачаздійснюється підключення до SQL-сервера, після чого визначаються його рівні доступу кожної бази даних окремо.

У системі SQL-сервер є додаткові об'єкти – ролі , які визначають рівень доступу до об'єктів SQL-сервера. Вони поділені на дві групи: призначені для облікових записів користувачасервери та використовуються для обмеження доступу до об'єктів бази даних.

Отже, на рівні сервера система безпеки оперує такими поняттями:

• автентифікація;
• обліковий запис ;
• вбудовані ролі сервера.

На рівні бази даних застосовуються такі поняття;

• користувач бази даних;
• фіксована роль бази даних;
• користувальницькароль бази даних.

Режими аутентифікації

SQL Server пропонує два режими автентифікації користувачів:

• режим аутентифікації засобами Windows NT/2000;
• змішаний режим автентифікації (Windows NT Authentication and SQL Server Authentication).

Адміністрація системи безпеки

Для створення користувачав середовищі MS SQL Server слід зробити наступні кроки:

1. Створити у базі даних обліковий запис користувача, вказавши йому пароль і прийняте за умовчанням ім'я бази даних (процедура sp_addlogin ).
2. Додати цього користувача до всіх необхідних баз даних (процедура sp_adduser ).
3. Надати йому у кожній базі даних відповідні привілеї (команда GRANT).

Створення нового облікового записуможе бути проведено за допомогою системної процедури, що зберігається:

sp_addlogin [@login=] "обліковий_запис" [, [@password=] "пароль"] [, [@defdb=] "база_даних_за замовчуванням"]

Після завершення аутентифікації та отримання ідентифікатора облікового запису (login ID)вважається зареєстрованим, і йому надається доступ до сервера. Для кожної бази даних, до об'єктів якої він має намір отримати доступ, обліковий запис користувача(login) асоціюється з користувачем (user) конкретної бази даних, що здійснюється за допомогою процедури:

sp_adduser [@loginame=] "обліковий запис" [, [@name_in_db=] "ім'я_користувача"] [, [@grpname=] "ім'я_ролі"]

Відобразити обліковий запис Windows NT в ім'я користувача дозволяє процедура, що зберігається:

sp_grantdbaccess [@login=] 'обліковий_запис' [, [@name_in_db=]‘имя_користувача’]

Користувач , який створює об'єкт у базі даних (таблицю, процедуру, що зберігається, перегляд), стає його власником . Власник об'єкту(database object owner dbo) має всі права доступу до створеного ним об'єкта. Для того, щоб користувач міг створити об'єкт, власник бази даних (dbo) повинен надати йому відповідні права. Повне ім'ястворюваного об'єкта включає в себе ім'я користувача, що його створив.

Власник об'єктуне має спеціального пароляабо особливих прав доступу. Він неявно має повний доступ, але має явно надати доступ іншим користувачам.

SQL Server дозволяє передавати права володіння від одного користувача іншому за допомогою процедури:

sp_changeobjectowner [@objname=] 'ім'я_об'єкта' [@newowner=] 'ім'я_власника'

Роль дозволяє об'єднати одну групу користувачів , виконують однакові функції.

У SQL Server реалізовано два види стандартних ролей: лише на рівні сервера і лише на рівні баз даних. При установці SQL Server створюються фіксовані ролі сервера (наприклад, sysadmin з правом виконання будь-яких функцій SQL-сервера) та фіксовані ролі бази даних (наприклад, db_owner з правом повного доступудо бази даних або db_accessadmin з правом додавання та видалення користувачів). Серед фіксованих ролейбази даних існує роль public, яка має спеціальне призначення, оскільки її членами є всі користувачі, які мають доступ до бази даних.

Можна включити будь-який обліковий запис SQL Server (login) або обліковий запис Windows NT будь-яку роль сервера.

Ролі бази даних дозволяють об'єднувати користувачів в одну адміністративну одиницю та працювати з нею як з звичайним користувачем. Можна призначити права доступу до об'єктів бази даних для конкретної ролі, при цьому всі члени цієї ролі автоматично наділяються однаковими правами.

До ролі бази даних можна включити користувачів SQL Server, ролі SQL Server, користувачів Windows NT.

Різні дії щодо ролі здійснюються за допомогою спеціальних процедур:

• створення нової ролі:

  sp_addrole [@rolename=] "ім'я_ролі" [, [@ownername=] "ім'я_власника"]

• додавання користувача до ролі:

  sp_addrolemember [@rolename=] "ім'я_ролі", [@membername=] "ім'я_користувача"

• видалення користувача з ролі:

  sp_droprolemember [@rolename=] "ім'я_ролі", [@membername=] "ім'я_користувача"

• видалення ролі:

  sp_droprole [@rolename=] "ім'я_ролі"

Управління доступом до даних

Визначення привілеїв у стандарті мови

Кожна СУБД повинна підтримувати механізм, який гарантує, що доступ до бази даних зможуть отримати лише користувачі, які мають відповідний дозвіл. Мова SQL включає оператори GRANT і REVOKE , призначені організації захисту таблиць у базі даних. Механізм захисту побудований на використанні ідентифікаторів користувачів, що надаються їм прав володіння та привілеїв .

Ідентифікатор користувачаназивається звичайний ідентифікатор мови SQL, який використовується для позначення деякого користувача бази даних. Кожному користувачеві повинен бути призначений власний ідентифікатор, який надається адміністратором бази даних. З очевидних міркувань безпеки ідентифікатор користувачазазвичай зв'язується з деяким паролем. Кожен виконуваний СУБД SQL-оператор виконується від імені будь-якого користувача. Ідентифікатор користувачавизначає, на які об'єкти бази даних користувач може посилатися і які операції з цими об'єктами має право виконувати.

Кожен створений у середовищі SQL об'єкт має свого власника, який спочатку є єдиною персоною, яка знає про існування даного об'єктата має право виконувати з ним будь-які операції.

Привілеями або правами називаються дії, які користувач має право виконувати щодо даної таблиці бази даних або подання. У стандарті SQL визначається наступний набір привілеїв:

• SELECT - право вибирати дані з таблиці;
• INSERT – право вставляти у таблицю нові рядки;
• UPDATE – право змінювати дані у таблиці;
• DELETE – право видаляти рядки з таблиці;
• REFERENCES – право посилатися на стовпці вказаної таблиці в описах вимог підтримки цілісності даних;
• USAGE – право використовувати домени, перевірки та набори символів.

Привілеї INSERT і UPDATE можуть обмежуватися лише окремими стовпцями таблиці, у разі користувачеві дозволяється модифікувати значення лише зазначених стовпців. Аналогічним чином привілей REFERENCES може поширюватися виключно на окремі стовпці таблиці, що дозволить використовувати їх імена у формулюваннях вимог захисту цілісності даних – наприклад, у пропозиціях CHECK і FOREIGN KEY , що входять до визначення інших таблиць, тоді як застосування для подібних цілей інших стовпців буде заборонено.

Коли користувач за допомогою оператора CREATE TABLE створює нову таблицю, він автоматично стає її власником і отримує по відношенню до неї повний набірпривілеїв, яких інші користувачі не мають. Щоб забезпечити їм доступ, власник повинен явно надати необхідні права, для чого використовується оператор GRANT.

Створюючи подання за допомогою оператора CREATE VIEW, користувач автоматично стає власником цього подання та отримує повний набір прав. Для створення уявлення користувачеві достатньо мати привілей SELECT для всіх таблиць, що входять до нього, і привілей REFERENCES для всіх стовпців, згадуваних у визначенні цього уявлення. Привілеї INSERT , UPDATE і DELETE щодо створеного уявлення користувач отримає лише у тому випадку, якщо має відповідні привілеї щодо всіх таблиць, що використовуються в поданні.

Надання привілеїв користувачам

Оператор GRANT застосовується для надання привілеївщодо поіменованих об'єктів бази даних зазначеним користувачам. Зазвичай його використовує власник таблиці з метою надання доступудо неї іншим користувачам. Оператор GRANT має такий формат:

<предоставление_привилегий>::= GRANT (<привилегия>[...n] | ALL PRIVILEGES) ON ім'я_об'єкта TO (<идентификатор_пользователя>[,... n] | PUBLIC) [ WITH GRANT OPTION]

Параметр<привилегия>являє собою:

<привилегия>::= (SELECT | DELETE | INSERT [(ім'я_стовпця[,...n])] | UPDATE [(ім'я_стовпця[,...n])]) | REFERENCES [(ім'я_стовпця[,...n])] | USAGE )

З міркувань спрощення оператора GRANT можна вказати ключове слово ALL PRIVILEGES , що дозволить надати зазначеному користувачеві все існуючі привілеїбез необхідності їхнього перерахування. Крім того, в цьому операторі може вказуватись ключове слово PUBLIC , що означає надання доступузазначеного типу не тільки всім існуючим користувачам, але також і всім тим, хто буде визначений у базі даних.

Параметр ім'я_об'єкта може використовуватися як ім'я таблиці бази даних, уявлення, домену, набору символів, перевірки.

Завдяки параметру WITH GRANT OPTION, вказані в операторі GRANT користувачі мають право передавати всі наданіїм щодо зазначеного об'єкта привілею іншим користувачам, які, у свою чергу, будуть наділені таким самим правом передачі своїх повноважень. Якщо цей параметр не буде вказано, одержувач привілею не зможе передати свої права іншим користувачам. Таким чином, власник об'єкта може чітко контролювати, хто отримав право доступу до об'єкта та які повноваження йому надано.

Скасування наданих користувачам привілеїв

У мові SQL для скасування привілеїв, наданихкористувачам за допомогою оператора GRANT, використовується оператор REVOKE. За допомогою цього оператора можуть бути скасовані всі або деякі з привілеїв, отриманих вказаним користувачем раніше. Оператор REVOKE має такий формат:

<отмена_привилегий>::= REVOKE (<привилегия>[...n] | ALL PRIVILEGES) ON ім'я_об'єкта FROM (<идентификатор_пользователя>[,... n] | PUBLIC)

Ключове слово ALL PRIVILEGES означає, що для вказаного користувачаскасовуються всі привілеї, наданійому раніше тим користувачем, який запровадив даний оператор. Необов'язкова фраза GRANT OPTION FOR дозволяє всім привілеїв , переданих у вихідному операторі GRANT фразою WITH GRANT OPTION , скасовувати можливість передачі незалежно від самих привілеїв .

Якщо в операторі вказано ключове слово RESTRICT , успішне виконання команди REVOKE можливе лише в тому випадку, коли перераховані в операторі привілеї не можуть спричинити появу у будь-яких інших користувачів так званих "залишених" привілеїв . За допомогою параметра CASCADE видаляються всі привілеї, які могли б залишитися в інших користувачів.

"Залишеними" є привілеї, що збереглися у користувача, якому вони свого часу були надані за допомогою GRANT OPTION.

Оскільки наявність привілею необхідна створення певних об'єктів, разом із її видаленням можна втратити права , з допомогою використання якого було утворено той чи інший об'єкт (подібні об'єкти називаються " покинутими " ). Якщо в результаті виконання оператора REVOKE можуть з'явитися кинуті об'єкти (наприклад, уявлення), право буде скасовано за умови, що в ньому не вказується ключове слово CASCADE. Якщо ключове слово CASCADE в операторі є, то для будь-яких кинутих об'єктів, що виникають при виконанні вихідного оператора REVOKE, будуть автоматично видані оператори DROP.

Привілеї, які були надані зазначеному користувачеві іншими користувачами, не можуть бути порушені оператором REVOKE. Отже, якщо інший користувач також надав даному користувачеві привілей, що видаляється, то право доступу до відповідної таблиці у зазначеного користувача збережеться. Наприклад, нехай користувач A та користувач Е мали право INSERT на таблицю Товар . Користувач А надав користувачеві B привілей INSERT для таблиці Товар, причому із зазначенням WITH GRANT OPTION (етап 1). Користувач B передав цей привілей користувачеві C (етап 2). Потім користувач C отримав її від користувача E (етап 3). Далі користувач C надав згаданий привілей користувачу D (етап 4). Коли користувач A скасовує привілей INSERT для користувача B , вона може бути скасована і користувача C , оскільки він уже отримав її від користувача E . Якщо користувач E не надав даного привілею користувачу C , то видалення привілею користувача B мало б наслідком каскадне видаленняпривілеїв для користувачів C та D (див. таблицю 17.1).

Реалізація прав на доступ до об'єктів баз даних у середовищі MS SQL Server

Категорії прав у середовищі MS SQL Server

При підключенні до SQL Server все можливі діїкористувачів визначаються правами (привілеями, дозволами), виданими їх облікового запису, групі або ролі, в яких вони складаються.

Права можна розділити на три категорії:

• права на доступ до об'єктів;
• права на виконання команд;
• неявні права.

Таблиця 17.1.

Користувач A	Користувач B	Користувач C	Користувач D	Користувач E
GRANT INSERT ON Товар TO B WITH GRANT OPTION	Отримання права
		Здобуття права від B . Отримання права від E		GRANT INSERT ON Товар TO C WITH GRANT OPTION
		GRANT INSERT ON Товар TO D	Отримання права
REVOKE INSERT ON Товар TO B CASCADE	Скасування права	Збереження права	Збереження права	Збереження права

Робота з даними і виконання процедур, що зберігаються, вимагають наявності класу доступу, званого правами на доступ до об'єктівбаз даних. Під об'єктами маються на увазі таблиці, стовпці таблиць, уявлення, процедури, що зберігаються.

Для різних об'єктівзастосовуються різні набориправ доступу до них:

• SELECT , INSERT , UPDATE , DELETE , REFERENCES – для таблиці чи подання;
• SELECT , UPDATE – для конкретного стовпця таблиці чи подання;
• EXECUTE – для процедур і функцій, що зберігаються.

Право INSERT дозволяє вставляти нові рядки в таблицю або подання та видається лише на рівні таблиці або подання; воно може бути видано лише на рівні стовпця.

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

Право DELETE дозволяє видаляти рядки з таблиці або подання, видається лише на рівні таблиці або подання, але не може бути видано на рівні стовпця.

Право SELECT дозволяє вибірку даних і може видаватися як на рівні таблиці, так і на рівні окремого стовпця.

Право REFERENCES надає можливість посилатися на вказаний об'єкт. Стосовно таблиць дозволяє створювати зовнішні ключі, що посилаються на первинний ключ або унікальний стовпець цієї таблиці.

Надання прав

Для керування дозволом користувача на доступ до об'єктівбази даних використовується команда:

<предоставление_привилегий>::= GRANT ( ALL [ PRIVILEGES ] |<привилегия>[,...n]) ( [(ім'я_стовпця [,...n])] ON ( ім'я_таблиці | ім'я_перегляду) | ON (ім'я_таблиці | ім'я_перегляду ) ([ім'я_стовпця [,...n])] | | ім'я_зовнішньої_процедури)) TO ( ім'я_користувача | ім'я_групи | ім'я_ролі) [,... n]

Параметр<привилегия>

<привилегия>::= (SELECT | DELETE | INSERT | UPDATE | EXECUTE | REFERENCES )

Параметр WITH GRANT OPTION допоможе користувачеві, якому ви надаєте права, призначити права на доступ до об'єкта іншим користувачам. Його використання вимагає особливої ​​обережності, оскільки при цьому власник втрачає контроль над наданням правна доступ іншим користувачам. Найкраще обмежити коло користувачів, які мають можливість керувати призначенням прав.

Необов'язковий параметр AS (ім'я_групи | ім'я_ролі)дозволяє вказати участь користувача в ролі, що забезпечує надання правіншим користувачам.

Єдине право доступу , яке може бути надано для процедури, що зберігається, - право на її виконання (EXECUTE ). Природно, крім цього власник процедури, що зберігається, може переглядати і змінювати її код.

Для функції можна видати право на її виконання, а також видати право REFERENCES , що забезпечить можливість зв'язування функції з об'єктами, на які вона посилається. Таке зв'язування дозволить заборонити внесення змін до структури об'єктів, які можуть призвести до порушення роботи функції.

Права виконання команд SQL

Цей клас прав контролює можливість створення об'єктів у базі даних, самої бази даних та виконання процедури резервного копіювання. Можна використовувати наступну команду для надання права на виконання команд SQL:

<предоставление_права_выполнения>::= GRANT (ALL |<команда>

Параметр<команда>є наступною конструкцією:

<команда>::= (CREATE DATABASE | CREATE TABLE | CREATE VIEW | CREATE DEFAULT | CREATE RULE | CREATE PROCEDURE | BACKUP DATABASE | BACKUP LOG | ALL )

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

Неявні права

Виконання деяких дій не потребує явного дозволу і доступне за замовчуванням. Ці дії можуть виконуватися лише членами ролей сервера або власниками об'єктів у базі даних.

Неявні права не надаються користувачеві безпосередньо, він одержує їх лише за певних обставин. Наприклад, користувач може стати власником об'єкта бази даних, тільки якщо сам створить об'єкт або якщо хтось інший передасть право володіння своїм об'єктом. Таким чином власник об'єкта автоматично отримає права на виконання будь-яких дій з об'єктом, у тому числі на надання доступудо об'єкта іншим користувачам. Ці права ніде не вказуються, виконувати будь-які дії дозволяє лише факт володіння об'єктом.

Заборона доступу

Система безпеки SQL Server має ієрархічну структуру, і тому ролі бази даних включають облікові записита групи Windows NT, користувачів та ролі SQL Server. Користувач же, у свою чергу, може брати участь у кількох ролях і одночасно мати різні права доступу різних ролей. Коли одна з ролей , в яких складається користувач , має дозвіл на доступ до даних, він має автоматично аналогічні права . Тим не менш, якщо виникає необхідність, користувачеві можна заборонити доступ до даних або команд, тоді анулюються всі дозволи на доступ, отримані на будь-якому рівні ієрархії. При цьому гарантується, що доступ залишиться забороненим незалежно від дозволів на більш високому рівні.

Для заборони доступу

<запрещение_доступа>::= DENY (ALL | |<привилегия>[,...n]) ( [(ім'я_стовпця [,...n])] ON ( ім'я_таблиці | ім'я_перегляду) | ON (ім'я_таблиці | ім'я_перегляду ) [ім'я_стовпця [,...n])] | ON (ім'я_збереженої_процедури | ім'я_зовнішньої_процедури)) TO (ім'я_користувача | ім'я_групи | ім'я_ролі) [,...n]

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

Для заборони виконання команд SQL застосовується оператор:

<запрещение_выполнения>::= DENY (ALL |<команда>[,...n]) TO (ім'я_користувача | ім'я_групи | ім'я_ролі) [,...n]

Неявне відхилення доступу

Неявне відхиленняподібно заборони доступуз тією відмінністю, що вона діє лише на тому рівні, на якому визначено. Якщо користувачеві на певному рівні неявно відхилений доступ, він все ж таки може отримати його на іншому рівні ієрархії через членство в ролі , що має право перегляду. За промовчанням доступ користувача до даних неявно відхилений. Для неявного відхилення доступудо об'єктів бази даних використовується команда:

<неявное_отклонение_доступа>::= REVOKE (ALL [ PRIVILEGES] | |<привилегия>[,...n]) ( [(ім'я_стовпця [,...n])] ON ( ім'я_таблиці | ім'я_перегляду) | ON (ім'я_таблиці | ім'я_перегляду ) [ім'я_стовпця [,...n])] | ON (ім'я_збереженої_процедури | ім'я_зовнішньої_процедури)) TO | FROM (ім'я_користувача | ім'я_групи | ім'я_ролі)[,...n]

Для неявного відхиленнядозволи на виконання команд SQL використовується така команда:

<неявное_отклонение_разрешения>::= REVOKE (ALL |<команда>[,...n]) FROM (ім'я_користувача | ім'я_групи | ім'я_ролі)[,...n]

Сенс параметрів аналогічний параметрам команд GRANT і DENY. Параметр GRANT OPTION FOR використовується, коли потрібно відкликати право , наданепараметром WITH GRANT OPTION команди GRANT. Користувач зберігає дозвіл на доступ до об'єкта, але втрачає можливість надавати цей дозвіл іншим користувачам.

Конфлікти доступу

Дозволи, наданіролі або групі, що успадковуються їх членами. Хоча користувачу може бути надано доступчерез членство в одній ролі , роль іншого рівня може мати заборону на дію з об'єктом. У такому разі виникає конфлікт доступу.

При дозволі конфліктів доступу SQL Server керується наступним принципом: дозвіл на надання доступумає найнижчий пріоритет, а на заборона доступу- найвищий. Це означає, що доступ до даних може бути отриманий лише явним його наданнямпри відсутності заборони доступуна будь-якому іншому рівні ієрархії системи безпеки. Якщо доступ явно не надано, користувач не зможе працювати з даними.

Приклад 17.1.Створити нову базу даних нового користувача для цієї бази даних, надавши йому всі права.

Створення адміністратором нової -- бази даних CREATE DATABASE basa_user -- створення нового користувача з -- ім'ям UserA і паролем '123' -- базою даних за промовчанням для користувача UserA буде база -- з ім'ям basa_user. sp_addlogin "UserA","123","basa_user" -- перехід до бази даних basa_user USE basa_user -- додавання до поточної бази даних -- (basa_user) користувача з ім'ям -- userA sp_adduser "UserA" -- надання користувачеві userA -- у базі даних basa_user всіх прав GRANT ALL TO UserA Приклад 17.1. створення нової базиданих, нового користувача цієї бази даних, з наданням йому всіх прав.

Приклад 17.2.Використання ролей.

Створимо роль stud і включимо до цієї ролі двох користувачів user1 і user2 :

sp_addrole "stud" sp_addrolemember "stud","user1" sp_addrolemember "stud","user2"

Надамо права ролі stud і безпосередньо користувачеві user2 :

GRANT SELECT, INSERT ON Товар TO stud GRANT SELECT, INSERT ON Товар TO user2

Після виконання цих команд користувачі user1 та user2 можуть виконувати команди вибірки та додавання запису до таблиці Товар.

Припинимо право на виконання вставки в таблицю Товар для ролі stud:

REVOKE INSERT ON Товар TO stud

Після попередньої команди користувач user1 втрачає право вставки запису, а user2 зберігає це право , оскільки право вставки надано йому явно.

Виконаємо команду

DENY INSERT ON Товар TO stud.

Після виконання цієї команди обидва користувачі позбавляються права вставки в таблицю Товар.

Права доступу (дозволу) для роботи з базами геоданих налаштовуються шляхом призначення користувачам та групам попередньо налаштованих ролей. Обліковий запис або група в цьому випадку є обліковим записом Windows, який ідентифікує користувача, а ролі керують дозволами для дій, які може виконувати користувач.

Попередньо налаштовані ролі та можливі права доступу наведені нижче:

• Ні (None) – Не було надано жодного доступу до бази геоданих або до набору даних бази геоданих.
• Лише читання (Read Only) – Користувач може переглядати та вибирати дані.
• Читання/Запис (Read/Write) – Користувач може читати, записувати і створювати нові набори даних у базі геоданих або читати та записувати існуючі набори даних.
• Адміністратор (Admin) – Користувач може виконувати адміністративні завдання у певній базі геоданих.
• Адміністратор сервера (Server administrator) – Користувач, який керує сервером баз даних.

Дозволи є кумулятивними. Якщо ви є адміністратором на рівні сервера бази даних, ви також є адміністратором бази геоданих. Якщо ви є адміністратором бази геоданих, ви автоматично отримуєте дозволи на читання/запис (read/write) для всіх наборів даних у цій базі геоданих.

Нижче описано кожен рівень, на якому дозволи можуть бути призначені.

Права доступу на рівні сервера баз даних

Права доступу на рівні сервера бази даних можуть бути налаштовані лише адміністратора сервера; Користувач або є адміністратором сервера, чи ні.

У процесі постінсталяції, яка налаштовує екземпляр SQL Server Expressдля зберігання баз геоданих, на сервер баз даних додається обліковий запис Windows. У цей момент облікового запису призначається роль адміністратора сервера. Після цього права доступу до сервера баз даних можуть бути доступні з контекстного меню сервера баз даних ArcGIS for Desktop .

Адміністратор сервера може виконувати такі завдання:

• Додавати та видаляти користувачів сервера баз даних.
• Керувати базами геоданих та налаштуваннями безпеки.
• Створювати та видаляти бази геоданих.
• Прикріплювати та відкріплювати бази геоданих.
• Робити резервні копії та відновлювати бази геоданих.
• Оновлювати бази геоданих.
• Виконувати стиск баз геоданих (Compress).
• Оновлювати статистику та індекси в базі геоданих.
• Зменшувати базу геоданих (Shrink).
• Запускати, зупиняти та призупиняти сервер баз даних.

Зазвичай, у вас є один адміністратор сервера баз даних.

Нижче наведено приклад діалогового вікна Права доступу для серверів баз даних. Обліковий запис ROCKETJAY\har була призначена роль адміністратора сервера (Server administrator).

Права доступу на рівні бази геоданих

Права доступу на рівні баз геоданих призначаються за допомогою контекстного меню баз геоданих при доступі до них через папку Сервери баз даних (Database Servers) у дереві Каталогу.

Права доступу на цьому рівні будуть спочатку видані адміністратору сервера та керуватимуться на основі ролей. Можливі ролі, які можуть бути призначені користувачеві:

• Тільки Читання (Read Only) – Ця роздільна здатність дозволяє користувачеві вибирати дані з будь-якої таблиці в базі геоданих.
• Читання/Запис (Read/Write) – Користувачі з призначеною роздільною здатністю Читання/Запис можуть вибирати та редагувати всі наявні в базі геоданих дані та можуть створювати нові елементи бази геоданих, такі як класи об'єктів. Якщо користувач отримав дозвіл на читання/запис на рівні бази геоданих, ви не зможете змінити його права доступу на рівні наборів даних, вони будуть автоматично налаштовані як Читання/Запис.
• Адміністратор (Admin) – Користувачі з призначеною роллю Адміністратора (Admin) є адміністраторами лише цієї бази геоданих. Це означає, що користувач має дозволи на читання/запис на всі набори даних та базі геоданих, і ці права не можуть бути відкликані на рівні наборів даних. Наприклад, ви не зможете відкрити закладку Права доступу на рівні наборів даних та вибрати права Лише читання (Read Only) для набору класів для цього користувача.

  Крім доступу до наборів даних на читання/запис, адміністратори баз геоданих можуть виконувати адміністративні операції над цими базами геоданих, у тому числі створення резервних копій, стиснення баз геоданих, оновлення баз геоданих та адміністрування прав користувачів бази геоданих. (Користувачі повинні існувати на сервері баз даних; адміністратори бази геоданих не можуть додавати нових користувачів на сервер баз даних.)

• Ще однією опцією для ролі користувача є Ні (None). У такому разі користувач не матиме прав на доступ до даних на рівні бази геоданих; Однак користувачі можуть надавати права Лише читання або Читання/Запис на певні набори даних, як описано в розділі "Дозволи на рівні наборів даних". Ні (None) – це рівень прав доступу, що за замовчуванням встановлюється для користувачів, які додаються на сервер баз даних.

У наступному прикладі діалогового вікна Права доступу бази геоданих обліковий запис ROCKETAY\pllama доданий до ролі Читання/Запис (Read/Write) для бази геоданих historical.

Для отримання додаткової інформаціїпро адміністратори сервера та бази геоданих див. у розділі Адміністратори серверів баз даних.

Права доступу на рівні набору даних

Дозволи для набору даних доступні через команду Права доступу (Privileges)в контекстному менюнабору даних, що відкриває діалогове вікно Роздільна здатність . Можливими дозволами для набору даних, які доступні через діалогове вікно Роздільна здатність на рівні набору даних, є Тільки читання (Read Only), Читання/Запис (Read/Write) і Ні (None).

Користувач може не мати дозволів на рівні бази геоданих (його дозволу будуть встановлені як Ні (None)), але йому можуть бути видані права на читання/запис або лише читання для певних наборів даних у базі геоданих. Наприклад, ви можете призначити користувачам-аналітикам права лише на читання даних у базі геоданих, але надати їм права на запис/читання одного класу об'єктів у базі геоданих.

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

Якщо адміністратор сервера створює набори даних, то їх власником буде користувач dbo, і вони зберігатимуться в схемі dbo. Таким чином, адміністратор сервера може видати дозволи на будь-які набори класів у схемі dbo, але лише на об'єкти у схемі dbo. Іншими словами, адміністратор сервера не зможе видати дозволу на дані, якими володіють користувачі, які не є адміністраторами.

Нижче наведено приклад діалогового вікна Права доступу для набору даних:

Щоб дізнатися більше про призначення ролей користувачам та видачу та відкликання дозволів, див.

Всім привіт! Зараз ми з Вами розглянемо приклади створення та видалення користувачів в СУБД Microsoft SQL Serverяк з використанням інструкцій Transact-SQL, так і з використанням середовища Management Studio.

Процес створення користувачів у MS SQL Server включає два етапи:

1. Створення імені входу до SQL Server. Це ім'я необхідно, щоб надати користувачеві можливість підключитися до екземпляра SQL Server;
2. Створення користувача бази даних. У цьому випадку ми вже надаємо користувачеві дозволи на об'єкти бази даних.

Примітка! В якості SQL сервера у мене для прикладу буде виступати версія Microsoft SQL Server 2012 Express. На цьому SQL сервері створено тестову базу даних Test.

Створення імені входу на MS SQL Server

Перш ніж приступати до створення імені входу SQL сервер необхідно визначитися з методом аутентифікації. Існує два варіанти:

1. Перевірка автентичності Windows– це коли ім'я входу може ідентифікувати користувача як обліковий запис Windows або члена групи Windows ( у тому числі і доменні облікові записи, та групи);
2. Перевірка автентичності SQL Server. У цьому випадку ім'я входу існує лише у SQL Server.

Давайте розглянемо кілька прикладів створення імені входу на SQL сервер. Спочатку ми зробимо це за допомогою середовища SQL Server Management Studio , а потім з використанням мови Transact-SQL.

Створення імені входу за допомогою середовища SQL Server Management Studio

Запускаємо Management Studio, потім в браузері об'єктів знаходимо пункт « Безпека», Розкриваємо його плюсиком, клацаємо правою кнопкою миші по пункту « Імена входу» та вибираємо пункт « Створити ім'я входу».

Далі для прикладу давайте створимо тестове ім'я входу з автентичністю SQL Server. Ми вказуємо ім'я входу, вигадуємо пароль та підтверджуємо його. Також ми можемо відзначити кілька опцій, наприклад, використання політики паролів, база даних за промовчанням, мова за промовчанням та інші.

Потім натискаємо кнопку « ОК», після чого буде створено ім'я входу TestLogin. За замовчуванням це ім'явходу буде включено, і воно матиме права на роль сервера «public».

Створення імені входу за допомогою мови Transact-SQL

Для того, щоб створити ім'я входу Transact-SQL, необхідно в Management Studio відкрити редактор запитів і виконати наступну інструкцію (вона робить рівно те саме, що і наші дії вище в графічний інтерфейс Management Studio).

CREATE LOGIN WITH PASSWORD=N"Pa$$w0rd", DEFAULT_DATABASE=, DEFAULT_LANGUAGE=[Українська], CHECK_EXPIRATION=OFF, CHECK_POLICY=ON GO

Іншими словами, для створення імені входу в SQL сервер використовується інструкція CREATE LOGIN.

Створення імені входу на SQL Server з автентифікацією Windows

Щоб створити ім'я входу з автентифікацією Windows, виконайте наступне SQL інструкцію:

CREATE LOGIN FROM WINDOWS WITH DEFAULT_DATABASE=, DEFAULT_LANGUAGE=[Українська]; GO

• ComputerName\NameUser – це Ім'я комп'ютера\Ім'я користувача;
• FROM WINDOWS – вказує, що використовуватиметься автентифікація Windows;
• WITH DEFAULT_DATABASE= – база даних за умовчанням;
• DEFAULT_LANGUAGE=[Українська] – мова за замовчуванням.

Вимкнення та включення імен входу до MS SQL Server

У разі потреби Ви можете тимчасово вимкнути ім'я входу, щоб заблокувати доступ до сервера.

Вимкнення ALTER LOGIN TestLogin DISABLE; --Включення ALTER LOGIN TestLogin ENABLE;

Створення користувача бази даних у MS SQL Server

Коли ім'я входу створено, можна переходити до користувача бази даних, тобто. зіставлення користувача з ім'ям входу.

Давайте створимо користувача TestLogin також двома способами, тобто. з допомогою Management Studio та мови T-SQL .

Створення користувача бази даних за допомогою Management Studio

Відкриваємо Management Studio, в браузері об'єктів знаходимо потрібну базу даних і відкриваємо її плюсиком. Потім плюсиком відкриваємо пункт « Безпека» і клацаємо по папці « Користувачі» правою кнопкою миші та вибираємо пункт « Створити користувача».

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

Також давайте відразу відзначимо роль бази даних, яку матиме даний користувач. На сторінці " Членство» я поставив галочку навпроти ролі db_datareader, тобто. користувач буде мати права на читання даних з таблиць користувача. Тиснемо « ОК».

Створення користувача бази даних за допомогою Transact-SQL

Наступна інструкція T-SQL створює користувача бази даних ( схема за замовчуванням dbo) і призначає йому роль db_datareader, тобто. робить те саме, що і ми трохи раніше в графічному інтерфейсі Management Studio.

USE Test GO CREATE USER FOR LOGIN WITH DEFAULT_SCHEMA = GO ALTER ROLE ADD MEMBER ; GO

Таким чином, інструкція CREATE USERвикористовується для створення користувача бази даних.

Видалення користувача бази даних та імені входу до MS SQL Server

Для того, щоб видалити користувача бази даних, можна написати просту SQLінструкцію, наприклад

DROP USER Testlogin;

Або використовувати графічний інструмент Management Studio, тобто. в оглядачі об'єктів, потрібній базіданих вибираємо « Безпека -> Користувачі» і клацаємо правою кнопкою миші по користувачеві, якого необхідно видалити, та вибираємо « видалити».

Примітка! Користувачі, які володіють об'єктами, що захищаються, не можуть бути видалені з бази даних.

Для видалення імені входу можна також використовувати графічний інструмент Management Studio ( тобто. «Безпека -> Імена входу» правою кнопкою миші на ім'я, а потім натиснути на пункт «Видалити») та інструкцію Transact-SQL тобто.

DROP LOGIN TestLogin;

Примітка! Видалити поточне ім'я входу не можна, як і ім'я входу, що володіє будь-яким об'єктом рівня сервера, що захищається, або завданням агента SQL Server. Також ім'я входу не можна видалити, якщо в НаразіКористувач підключений до системи. Видалити ім'я входу без видалення зіставленого користувача бази даних можна, але це призведе до появи користувачів, які втратили зв'язок з обліковими записами.

На цьому у мене все сподіваюся, матеріал був Вам корисний, поки що!

Анотація: Ця лекція містить матеріали з управління доступом до баз даних SQL Server, зокрема розглядається управління користувачами бази даних, включення користувача guest, створення ролей бази даних, надання дозволів на базу даних та додавання користувача бази даних

Одного надання доступу до екземпляра SQL Server буде недостатньо для програми, яка потребує доступу до даних. Надавши доступ до екземпляра SQL Server, необхідно надати доступ до певних баз даних. Доступ до баз даних надається за допомогою додавання користувачів бази даних та зіставлення користувачам бази даних імен входу. Кожне ім'я входу порівнюється користувачеві бази даних для кожної бази даних, до якої цього імені входу потрібний доступ. Кожен користувач бази даних зіставляється лише одному імені входу, крім користувача бази даних dbo.

Примітка. У попередніх версіях SQL Server можна було використовувати для зіставлення декількох імен входу одному користувачеві бази даних системну процедуру sp_addalias . Так можна зробити і в SQL Server 2005. Однак цю функцію використовувати не рекомендується, оскільки вона вважається застарілою і, можливо, буде видалена з наступних версій програми.

Надання доступу до баз даних

Користувачі бази даних – це учасники рівня бази даних. Усі імена входу, за винятком серверної ролі sysadmin повинні бути зіставлені користувачам, які, в свою чергу, зіставлені базі даних, до якої їм потрібен доступ. Члени ролі sysadminзіставлені користувачеві dbo у всіх базах даних сервера.

Додаємо користувача бази даних

Додати користувача бази даних можна за допомогою інструкції CREATE USER. Наступний приклад коду Transact-SQL створює ім'я входу Peter та зіставленого з ним користувача в базі даних Adventure Works:

• Створюємо ім'я входу Peter

  CREATE LOGIN Peter WITH PASSWORD="Tyu87IOR0";

• USE AdventureWorks; GO

• Додаємо користувача бази даних Peter, який зіставлений імені входу Peter до БД AdventureWorks.

  CREATE USER Peter FOR LOGIN Peter;

Керуємо користувачами бази даних

Перевірити, чи має поточне ім'я входу доступ до бази даних, можна за допомогою наступної інструкції:

SELECT HAS_DBACCESS("AdventureWorks");

Щоб отримати інформацію про користувачів бази даних, можна скористатися представленням каталогу sys.database_principals.

Якщо потрібно тимчасово вимкнути доступ користувача до бази даних, можна відкликати дозвіл CONNECT для цього користувача. Наступний приклад відкликає дозвіл CONNECT для користувача Peter:

• Змінюємо контекст з'єднання на базу даних AdventureWorks.

  USE AdventureWorks; GO

• Відкликаємо дозвіл connect для Peter в AdventureWorks.

  REVOKE CONNECT TO Peter;

Видалити користувача до баз даних можна за допомогою інструкції DROP USER .

Попередження. SQL Server 2005 не дозволяє видалення користувача, який є власником схеми бази даних. Про схеми розповідається далі у цій лекції.

Керуємо користувачами, що втратили зв'язок із іменами входу

Користувачами, що втратили зв'язок з іменами входу, називаються користувачі бази даних, які не зіставлені вхідного імені в поточному екземплярі SQL Server. У SQL Server 2005 користувач може втратити зв'язок з ім'ям входу, якщо його ім'я входу буде видалено. Щоб отримати інформацію про таких користувачів, можна виконати такий код:

• Змінюємо контекст з'єднання на базу даних AdventureWorks.

  USE AdventureWorks; GO

• Складаємо звіт про всіх користувачів бази даних, що втратили зв'язок з ім'ям входу

  EXECUTE sp_change_users_login @Action="Report";

У SQL Server 2005 допускається створення користувача, не зіставленого імені входу за допомогою фрази WITHOUT LOGIN . Користувачі, створені за допомогою фрази WITHOUT LOGIN, не вважаються користувачами, що втратили зв'язок з ім'ям входу. Ця можливість може бути дуже корисною у ситуації, коли необхідно змінити контекст виконання будь-якого модуля. Про контекст виконання розповідається далі у цій лекції. Наступний приклад створює користувача, не зіставленого імені входу.

• Змінюємо контекст з'єднання на базу даних AdventureWorks.

  USE AdventureWorks; GO

• Створюємо користувача бази даних Paul у базі даних AdventureWorks
• не зіставляючи з ним імені входу до даному екземплярі SQL Server instance

  CREATE USER Paul WITHOUT LOGIN;

Включаємо користувача guest

Коли ім'я входу, яке не має зіставленого користувача, намагається з'єднатися з базою даних, SQL Server робить спробу підключення з використанням користувача Guest . Користувач Guest створюється за замовчуванням без дозволу. Можна ввімкнути користувача guest, надавши йому дозвіл CONNECT, як показано нижче.

• Змінюємо контекст з'єднання на базу даних AdventureWorks.

  USE AdventureWorks; GO

• Надаємо користувачеві Guest доступ до бази даних AdventureWorks.

  GRANT CONNECT TO Guest;

  Добре подумайте над тим, чи варто вмикати користувача guest, адже це надає середовище бази даних додаткового ризику.

Надання дозволів на базу даних

Створивши користувачів бази даних, необхідно керувати дозволами для цих користувачів. Це можна зробити, додаючи користувачів у ролі бази даних або надаючи самим користувачам гранулярні дозволи.

Створюємо ролі бази даних

Ролі бази даних – це учасники рівня бази даних. Ролібази даних можна використовувати для призначення дозволів бази даних групікористувачів. У SQL Server 2005 за промовчанням створюється набір ролей бази даних. Ці ролі за умовчанням перелічені у табл. 3.1.

Таблиця 3.1. Ролі бази даних за замовчуванням

Роль бази даних	"Опис
db_accessadmin	Може керувати доступом до бази даних
db_backupoperator	Може виконувати резервне копіюваннябази даних
db_datareader	Може читати дані з таблиць всіх користувачів
db_datawriter	Може додавати, видаляти та оновлювати дані в таблицях усіх користувачів
db_ddladmin	Може виконувати будь-які команди DDL у базі даних
db_denydatareader	Не може читати будь-які дані в таблицях користувачів
db_denydatawriter	Не може додавати, видаляти та оновлювати будь-які дані в таблицях користувачів
db_owner	Може виконувати всі дії з налаштування конфігурації та обслуговування
db_securityadmin	Може змінювати членство в ролях бази даних та керувати дозволами
public	Особлива роль бази даних. Усі користувачі належать до ролі public. Користувачів із групи public не можна видалити.

Можна додавати ролі бази даних, якщо потрібно згрупувати користувачів відповідно до вимог певних дозволів. Наступний приклад коду створює роль бази даних з ім'ям Auditors і додає користувача Peter до цієї нової ролі.

• Змінюємо контекст з'єднання на базу даних AdventureWorks.

  USE AdventureWorks; GO

• Створюємо роль Auditors у базі даних AdventureWorks.

  CREATE ROLE Auditors; GO

• Додаємо користувача Peter до ролі Auditors

  EXECUTE sp_addrolemember "Auditors", "Peter";

Керуємо ролями бази даних

Виконавши запит системної функції IS_MEMBER, можна перевірити, чи поточний користувач належить до будь-якої ролі бази даних. У наступному прикладі ми перевіримо, чи поточний користувач належить до ролі бази даних db_owner.

• Змінюємо контекст з'єднання на базу даних AdventureWorks.

  USE AdventureWorks; GO

• Перевіряємо, чи поточний користувач належить до ролі db_owner

  Схожих статей досить багато, але цю в першу чергу писав собі, зупиняючись на примітках, у яких описані можливі проблеми. Сподіваюся, стаття буде корисна й іншим.
  1. Встановлюємо 1С платформу
  2. Встановлюємо MS SQL Server 2008. Під час встановлення задаємо користувача баз даних. (Який SA).

  Після встановлення відкриваємо панель адміністрування серверів 1С підприємства і бачимо, що вона порожня.
  Потрібно створити сервер: Відкриваємо console root->Central 1C: Enterprise 8.2 servers. Клацаємо по ньому правою кнопкою миші та вибираємо пункт new. У меню вибираємо Центральний сервер 1С Підприємства 8.2. Перед нами відкриється віконце з 4-ма полями:
  Протокол- протокол, за яким будуть передаватися дані
  Ім'я- ім'я комп'ютера в мережі, на якому розташовується сервер
  IP порт-порт за яким доступний сервер
  Опис-Опис. не обов'язково.

  Примітка:
  Якщо платформа 1С була встановлена ​​на комп'ютер, і потім комп'ютер був перейменований, то достукатися до нього ви не зможете, тому що платформа 1С дуже розумна платфома і записує в певні файлики при встановленні ім'я комп'ютера, але потім, коли ім'я комп'ютера змінюються платформа їх вже не перепише. Ці файли потрібні для роботи сервісу RAGENT 1С (його можна знайти в запущених службах, через панель адміністрування сервера windows). Це все говорить про те, що для перейменування цих файлів необхідно зупинити службу RAGENT. Самі файли знаходяться у таких місцях:
  C:\Program Files (x86)\1cv82\srvinfo\srvribrg
  C:\Program Files (x86)\1cv82\srvinfo\reg_1541\1CV8Reg
  Відкриваємо ці файли блокнотом і правимо минуле ім'я машини на даний момент ручками. Зберігаємо та запускаємо RAGENT.

  Повертаємося до налаштування:
  Після того як заповнене вікно з полями натискаємо кнопку OK і якщо все зроблено правильно, то у нас з'являється сервер на ім'я машини, на якій він стоїть.

  І так. Сервер запущений і тепер нам потрібно створити базу на MySQL server і зв'язати її з північчю 1C. Є кілька способів-тут я опишу найпростіший:
  На сервері 1С підприємства відкриваємо наш новий створений сервер кліком по + поруч із назвою сервера та на пункті «ІНФОРМАЦІЙНІ БАЗИ» клікаємо правою кнопочкою миші, вибираємо New->Інформаційна база
  Перед нами відкриється вікно, в якому будуть наступні поля:

  Ім'я-ім'я нашої бази даних на сервері 1С (Як правило багато хто його пишуть таким же як і в полі база даних, щоб не плутатися)
  Опис-опис
  Захищене з'єднання-за замовчуванням вимкнено. можна включити, але тоді навантаження на сервер зросте
  Сервер баз даних-якщо сервер на цьому ж сервері то вказуємо (local) саме так у дужках, якщо не на цьому сервері то вказуємо ip сервера
  Тип СУБД-Вибираємо тип MS SQL
  База даних-ім'я бази даних на сервері MS SQL Якщо бази немає, то в одному з чекбоксів можна поставити галочку і вона створиться
  Користувач сервера БД-Вказуємо або того користувача якого створювали при встановленні, або створюємо окремого користувачау MS SQL, задаємо йому права та прописуємо його тут.
  Пароль користувача сервера БД-пароль
  Дозволити видачу ліцензій сервером 1С підприємство-Вибираємо так
  Країна-Вибираємо країну
  Зміщення дат-ставимо в 0
  Чекбокс «Створити базу у разі відсутності»- той самий чекбокс для створення бази, якщо її немає
  Чекбокс "Встановити блокування регламентних завдань"-Не ставимо галочку

  Натискаємо ОК і бачимо, що сервери налаштовані і у нас в закладці «Інформаційні бази» з'явилася інформаційна базапід ім'ям, яке ми їй дали.

  Щоб налаштувати Backup нам потрібно відкрити Microsoft SQL MANAGEMENT STUDIO.
  Вводимо логін та підключаємося до сервера.
  Перед нами є адміністративна консоль. У Object explorerвідкриваємо вкладку Managementі в ній бачимо Maintance plans.Тут створюватимемо потрібний нам BackUP. Як зазвичай правий клік по Maintance plans->new maintance plan. У головному вікні з'явиться вкладка subplan, а під Object Explorer з'явиться ще одне віконце ToolBoxв якому вкладено Maintance Plans Tasks. У ній ми виберемо Back Up DataBase Taskклікнувши ним 2 разу. Він перенесеться на головне вікно. На ньому клацаємо 2 рази і перед нами з'являється вікно знову ж таки з полями, де ми можемо вибрати який Back Up робити, яку базу BackUp-ить, і куди це зберігати. Після закінчення налаштувань потрібно натиснути OK.

  Примітка:
  Зберігаючи Back Up в якусь мережеву папку (шлях до речі доведеться прописати ручками, тому що вікно вибору директорії бачить тільки локальні ресурси) простежте за правами доступу, і заразом простежте яка у вас аутентифікація на сервері MySqlтому що якщо аутентифікація виставлена ​​не за обліковими записам Windows, а за внутрішнім користувачем СУБД і якщо при цьому у вас піднято сервер AD то BackUp буде видавати помилку при спробі виконання, оскільки це робитиме від імені внутрішнього користувача СУБД і AD його не пропустить нікуди крім локального комп'ютера.

  Після того, як ви налаштували шлях, базу та тип BackUp потрібно налаштувати розклад. Для цього в головному вікні над створеним вами Task є табличка SubPlan. Наприкінці таблички (праворуч) є іконка календаря. Натиснувши на неї ви потрапите в налаштування розкладу. Позначаючи чекбокси днів та виставляючи час, ви налаштуєте розклад. Клацнувши 2 рази на полі під назвою SubPlanВи можете змінити назву Task-a. Налаштувавши все пройдіть в File-> Save All. Після збереження в Maintance plans з'явиться Task з вашою назвою, яку ви дали BackUp-у.

  Після закінчення налаштування потрібно обов'язково перевірити роботу. Для цього Правою кнопкою миші натисніть на створеному Task і виконання Exicute.

  Примітка:
  Якщо Exicute виконується з помилкою читайте помилки які вам видасть Studio, і насамперед перевірте, чи запущено у вас SQL Server Agent. Це він займається виконанням завдань та функція Exicute звертається саме до нього за виконанням завдань. Якщо його не запущено спроба виконання зазнає невдачі. Для того, щоб подивитися роботу ді агент чи ні в Studio в Object Explorer пройдіть у вкладку SQL Server Agent. Якщо на іконці булет червоний кружок з хрестиком - значить, агент зупинений. Запустити його можна клацнувши на ньому правою кнопкою миші та вибравши до контекстного меню опцію START.