Добавление информационной базы из окна запуска «1С:Предприятие». Предоставление разрешений на базу данных

Управление пользователями базы данных

Стабильная система управления пользователями – обязательное условие безопасности данных , хранящихся в любой реляционной СУБД. В языке 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 все возможные действия пользователей определяются правами (привилегиями , разрешениями), выданными их учетной записи , группе или роли , в которых они состоят.

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

• права на доступ к объектам ;
• права на выполнение команд ;
• неявные права .

Работа с данными и выполнение хранимых процедур требуют наличия класса доступа , называемого правами на доступ к объектам баз данных. Под объектами подразумеваются таблицы, столбцы таблиц, представления, хранимые процедуры.

Для различных объектов применяются разные наборы прав доступа к ним:

• SELECT , INSERT , UPDATE , DELETE , REFERENCES – для таблицы или представления;
• SELECT , UPDATE – для конкретного столбца таблицы или представления;
• EXECUTE – для хранимых процедур и функций.

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

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

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

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

Право REFERENCES предоставляет возможность ссылаться на указанный объект. Применительно к таблицам разрешает создавать внешние ключи, ссылающиеся на первичный ключ или уникальный столбец этой таблицы.

Предоставление прав

Для управления разрешением пользователя на доступ к объектам базы данных используется команда:

<предоставление_привилегий>::= GRANT { ALL [ PRIVILEGES] | <привилегия> [,...n]} { [(имя_столбца [,...n])] ON { имя_таблицы | имя_просмотра} | ON {имя_таблицы | имя_просмотра } ([имя_столбца [,...n])] | ON {имя_хранимой_процедуры | имя_внешней_процедуры}} 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.

После выполнения этой команды оба пользователя лишаются права вставки в таблицу Товар .

Термин «сервер БД» используется для обозначения всей СУБД, основанной на архитектуре клиент-сервер, включая серверную и клиентскую часть. Такие системы предназначены для хранения и обеспечения доступа к БД. Обычно одна БД целиком хранится в одном узле сети и поддерживается сервером в сервере БД, представляющим собой простое и дешевое приближение к распределенным БД, так как общая БД доступна для всех пользователей локальной сети. Доступ к базам данных из прикладной программы или пользователя осуществляется с использованием клиентской части системы. В качестве основного интерфейса между клиентскими и серверными частями выступает язык SQL.

Язык SQL представляет собой текущий стандарт интерфейса СУБД в открытых системах. Соблюдая предосторожности при программировании, можно создать прикладные информационные системы мобильные в классе SQL-серверов.

Серверы БД, интерфейс которых основан на языке SQL, обладают своими преимуществами и недостатками.

Преимущества: стандартный открытый интерфейс, т. е. клиентская часть любой ориентированной СУБД может работать с любым SQL-сервером независимо от того, когда компания его разработала.

Недостатки. При высоком уровне интерфейса между клиентской и серверной частями системы со стороны клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная работающая станция. Но если клиентский компонент обладает достаточной мощностью, то часто возникает необходимость возложить на него большие функции управления БД. Разгрузить сервер, который в этом случае является узким местом этой системы. Одним из корректных направлений СУБД является гибкая конфигурированная система, при которой распределяются функции между клиентской и пользовательской системами.

Преимущества протоколов удаленного вызова процедур

Использование механизма удаленного вызова процедур позволяет перераспределить функции между клиентскими и серверными частями систем, т. к. в тексте программы RPC ничем не отличается от ее обычного вызова. Следовательно, любой компонент системы может располагаться и на стороне сервера, и на стороне клиента.

Механизм RPC, скрывает различия между взаимодействующими компьютерами, физически неоднородная локальная вычислительная сеть приводится к логически однородной сети, взаимодействующих компонентов. В результате использования нет необходимости серьезно заботиться о разовой закупке совместимых серверов и рабочих станций.

Типичные распределения функций между клиентами и серверами

Типичным на сегодняшний день на стороне СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к БД, а обращается для этого к серверу с использование языка SQL.

В некоторых случаях необходимо включить в состав клиентской части системы некоторых функций для работы с локальной КЭШ БД, т.е. с той ее частью, которая интенсивно используется клиентской прикладной программой. Используя современные технологии, это можно сделать только путем формального создания на стороне клиента локальной копии серверов БД и рассмотрения всей системы как набор взаимодействующих серверов. С другой стороны иногда хотелось бы перенести большую часть прикладной системы на стороны сервера, если разница в мощностях клиентских рабочих станций и сервера велика, то это можно сделать, используя удаленный вызов процедур при условии, что программное обеспечение сервера это позволяет.

Требования к аппаратуре и программному обеспечению клиентских и сервисных компьютеров различают в зависимости от вида использованной системы.

Если разделение между клиентской и сервисной частью достаточно жесткое, как в большинстве современных СУБД, то пользователям, работающим на станциях, все равно какая аппаратура и операционная система работает на сервере при условии, что он сравнивается с возникающим потоком запросов.

Если могут возникнуть потребности перераспределения функций между клиентом и сервером, то не все равно какие операции системы используются.

Распределенные базы данных

Основной задачей системы управления распределенной БД состоит в обеспечении средств интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети для того, чтобы пользователи, работающие на любом узле сети, имели доступ ко всем базам данных как к единой БД. При этом должны обеспечиваться:

1) простота использования системы;

2) возможности автономного функционирования, при нарушении связанности сети;

Разновидности распределенных систем

Существуют однородные и неоднородные БД. В однородной БД каждая локальная БД управляется одной и той же СУБД. В неоднородной системе локальные БД могут относиться даже к разным моделям данных.

Наиболее успешно в настоящее время решается задача интеграции неоднородных SQL ориентированных систем. Этому способствует стандартизация языка SQL и общее следование.

Основная цель проекта создания распределенной системы управления базами данных может быть сформулирована следующим образом: необходимо обеспечить средства интеграции локальных баз данных, располагающихся в узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных, так, как если бы они были централизованными, при этом должны обеспечиваться:

1) легкость использования системы;

2) возможность автономного функционирования при нарушении связности сети;

3) высокая степень эффективности.

Для решения этих проблем был принят ряд необходимых проектных решений, касающихся декомпозиции исходного запроса, оптимального выбора способа выполнения запроса, согласованного выполнения транзакций, обеспечение синхронизации, обнаружение и разрешение распределенных тупиков, восстановление состояния баз данных после разного рода сбоев в узлах сети. Легкость использования системы достигается за счет того, что пользователи остаются в среде языка SQL. Возможность использования SQL обеспечивает прозрачность местоположения данных. Система автоматически обнаруживает текущее местоположение упоминаемых в пользовательском запросе объектов данных. Одна и та же прикладная программа, включающая приложение SQL, может быть выполнена в разных узлах сети. При этом в каждом узле сети на этапе компиляции запроса выбирается наиболее оптимальный план выполнения запросов в соответствии с расположением данных в распределенной системе. Обеспечение автономности узлов сети может быть обеспечено следующим образом: каждая локальная БД администрируется независимо от других, возможно автономное подключение новых пользователей, смена версии автономной части системы и т.д. Система спроектирована таким образом, что в ней не требуются централизованных службы именования объектов или обнаружения тупиков.

В индивидуальных узлах не требуется наличия глобального знания об операциях, выполняющихся в других узлах сети. Работа с доступными базами данных может продолжаться при выходе из строя отдельных узлов сети и линий связи. Для достижения высокой степени эффективности системы используется два основных приема. Во-первых, выполнению запроса предшествует его компиляция. В ходе этого процесса производится поиск употребляемых в запросе имен объектов баз данных в распределенном каталоге и замена имен на внутренние идентификаторы; проверка прав доступа пользователя, от которого производится компиляция, на выполнение соответствующей операции над базами данных и выбор наиболее оптимального глобального плана выполнения запроса, который затем подвергается декомпозиции и про частям рассылается в соответствующие узлы сети, где производится выбор оптимальных локальных планов выполнения компонентов запроса и производится генерация модулей доступа в машинных кодах. В результате на стадии компиляции производится множество действий до реального выполнения запросов. Обработанная таким образом прикладная программа, включающая предложения SQL, может в дальнейшем выполняться много раз без дополнительных накладных расходов.

Во-вторых, средством повышения эффективности системы является возможность перемещения удаленных отношений в локальные базы данных.

Распределенная компиляция запросов

Запросы на языке SQL до своего реального выполнения могут подвергаться компиляции. Компиляция запросов может производиться на стадии предкомпиляции прикладной программы, написанной на обычном традиционном языке программирования с включением предложений SQL, или в процессе выполнения транзакций с использованием инструкции языка SQL. С точки зрения пользователя процесс компиляции приводит к следующим результатам: для каждого предложения на SQL образуется программа в машинных кодах, вызовы которой помещаются в текст исходной прикладной программы, однако в действительности процесс компиляции запроса намного более сложен из-за наличия сложных сетевых взаимодействий, которые требуются при реальном выполнении транзакции. Будем называть главным узлом сети тот узел, в котором инициирован процесс компиляции предложений SQL, и дополнительными узлами (те узлы, которые вовлекаются в этот процесс в ходе его выполнения). На самом грубом уровне процесс компиляции можно разбить на следующие стадии:

В главном узле сети производится грамматический разбор предложения SQL с построением внутреннего представления запроса в виде дерева. На основе информации из локального каталога главного узла и удаленных каталогов дополнительных узлов производится замена имен объектов, фигурирующих в запросе, на их системные идентификаторы.

В главном узле генерируется глобальный план выполнения запроса, в котором учитывается только порядок взаимодействия узлов при реальном выполнении запроса. Глобальный план отображается в преобразованном соответствующим образом дереве запросов.

Если в глобальном плане выполнения запроса участвуют дополнительные узлы, производится его декомпозиция на части, каждую из которых можно выполнить в одном узле. Например, локальная фильтрация отношения в соответствии с заданным условием, при которой соответствующие части запроса рассылаются в соответствующие дополнительные узлы.

В каждом узле, участвующем в глобальном плане выполнения запроса, в главном или дополнительном, выполняется завершающая стадия компиляции. Эта стадия включает по существу две последние фазы процесса компиляции запроса: оптимизацию и генерацию машинных кодов, производится проверка прав пользователя, от имени которого выполняется компиляция, на выполнение соответствующих действий. Происходит обработка представлений БД, осуществляется локальная оптимизация обрабатываемой части запроса в соответствии с имеющимися индексами и производится генерация кода.

Добавление пользователей базы данных

Пользователь может войти в систему баз данных, используя учетную запись пользователя Windows или регистрационное имя входа в SQL Server. Для последующего доступа и работы с определенной базой данных пользователь также должен иметь учетную запись пользователя базы данных. Для работы с каждой отдельной базой данных требуется иметь учетную запись пользователя именно для этой базы данных. Учетную запись пользователя базы данных можно сопоставить с существующей учетной записью пользователя Windows, группой Windows (в которой пользователь имеет членство), регистрационным именем или ролью.

Управлять пользователями баз данных можно с помощью среды Management Studio или инструкций языка Transact-SQL. Оба эти способа рассматриваются в следующих подразделах.

Управление пользователями базы данных с помощью среды Management Studio

Чтобы добавить пользователя базы данных с помощью среды Management Studio, разверните узел сервера в окне Object Explorer и в нем папку "Databases", в этой папке разверните узел требуемой базы данных, а в ней папку "Security". Щелкните правой кнопкой мыши папку "Users" и в контекстном меню выберите пункт New User. Откроется диалоговое окно Database User - New, в котором следует ввести имя пользователя User name и выбрать соответствующее регистрационное имя Login name:

Здесь можно также выбрать схему по умолчанию для данного пользователя.

Управление безопасностью базы данных посредством инструкций языка Transact-SQL

Для добавления пользователя в текущую базу данных используется инструкция CREATE USER . Синтаксис этой инструкции выглядит таким образом:

CREATE USER user_name Соглашения по синтаксису

Параметр user_name определяет имя, по которому пользователь идентифицируется в базе данных, а в параметре login указывается регистрационное имя, для которого создается данный пользователь. В параметрах cert_name и key_name указываются соответствующий сертификат и асимметричный ключ соответственно. Наконец, в параметре WITH DEFAULT_SCHEMA указывается первая схема, с которой сервер базы данных будет начинать поиск для разрешения имен объектов для данного пользователя базы данных.

Применение инструкции CREATE USER показано в примере ниже:

USE SampleDb; CREATE USER Vasya FOR LOGIN Vasya; CREATE USER Alex FOR LOGIN WITH DEFAULT_SCHEMA = poco;

Для успешного выполнения на вашем компьютере второй инструкции примера требуется сначала создать учетную запись Windows для пользователя Alexandr и вместо домена (сервера) ProfessorWeb указать имя вашего сервера.

В этом примере первая инструкция CREATE USER создает пользователя базы данных Vasya для пользователя Vasya учетной записи Windows. Схемой по умолчанию для пользователя Vasya будет dbo, поскольку для параметра DEFAULT_SCHEMA значение не указано. Вторая инструкция CREATE USER создает нового пользователя базы данных Alex. Схемой по умолчанию для этого пользователя будет схема poco. (Параметру DEFAULT_SCHEMA можно присвоить в качестве значения схему, которая в данное время не существует в базе данных.)

Каждая база данных имеет своих конкретных пользователей. Поэтому инструкцию CREATE USER необходимо выполнить для каждой базы данных, для которой должна существовать учетная запись пользователя. Кроме этого, для определенной базы данных регистрационное имя входа в SQL Server может иметь только одного пользователя базы данных.

С помощью инструкции ALTER USER можно изменить имя пользователя базы данных, изменить схему пользователя по умолчанию или переопределить пользователя с другим регистрационным именем. Подобно инструкции CREATE USER, пользователю можно присвоить схему по умолчанию прежде, чем она создана.

Для удаления пользователя из текущей базы данных применяется инструкция DROP USER . Пользователя, который является владельцем защищаемых объектов (объектов базы данных), удалить нельзя.

Схемы базы данных по умолчанию

Каждая база данных в системе имеет следующие схемы по умолчанию.

Базы данных (в т.ч. система MySQL) представляет собой сущность для хранения информации в виде таблиц. Дабы чужие БД не были доступны абсолютному каждому пользователю на сервере, существует система пользователей для этих баз данных. Сам доступ к какой-либо БД может быть назначен администратором (либо уполномоченным пользователем) другому пользователю, причем он может быть полным или в некоторой степени ограниченным. Более конкретно эта степень доступа выражается в привилегиях («правах» или «разрешениях»).

Права для пользователей MySQL

Существует некоторое количество привилегий в системе БД MySQL которые указаны ниже с описанием. Последние привилегии являются привилегиями администраторского уровня, что явно указано лишь для справки. Полная информация о правах/ привилегиях доступна в документации разработчика MySQL :

CREATE - позволяет создавать новые базы данных и таблицы

DROP - позволяет удалять базы данных или таблицы

INSERT - позволяет добавлять строки к таблице.

UPDATE - позволяет изменять содержание строк таблиц. Не путать с ALTER, которая позволяет изменять саму структуру таблиц (количество строк/столбцов, типы столбцов).

DELETE - противоположна INSERT - позволяет удалять строки из таблицы.

ALTER - позволяет изменять структуру таблиц. Требует CREATE и INSERT привилегии.

GRANT OPTION - позволяет назначить конкретные права определенному пользователю (также и отобрать). Возможно дать/отобрать только те права, которыми назначающий сам располагает.

LOCK TABLES - блокирует таблицу на время искусственного внесения в нее изменений (администрирование), чтобы данные внутри нее не могли измениться своим естественным путем (во время рабочего процесса).

REFERENCES - позволяет создавать связь между таблицами по внешнему ключу.

EVENT - дает право на создание/изменение/удаление заданий для планировщика

TRIGGER - позволяет создавать/изменять/удалять триггеры (привязываемые к определенным таблицам), которые при выполнении операций DELETE, UPDATE или INSERT совершают дополнительные действия.

INDEX - привилегия даёт право добавлять/удалять индексы к (из) таблицам. Сами индексы назначаются вручную, и дают возможность сэкономить время на поиске строк.

CREATE TEMPORARY TABLES - позволяет создавать временные таблицы на время сессии.

CREATE VIEW - позволяет создать некоторое представление в виде таблицы, которая фактически не существует как единая и содержит лишь данные других таблиц. К примеру, в этом представлении можно собрать определенные сгруппированные данные из трёх таблиц (оператором SELECT) и по факту собранные данные будут лишь ссылаться на данные этих 3-х таблиц и также будут объединением, не нуждающимся в собственной таблице.

SHOW VIEW - позволяет проверить каким запросом (из каких данных состоит) создано определенное представление, заданное с помощью CREATE VIEW

CREATE ROUTINE - позволяет создать процедуру, которая является набором заготовленным набором SQL-команд.

ALTER ROUTINE - позволяет изменить процедуру, созданную посредством CREATE ROUTINE .

EXECUTE - позволяет вызывать готовые процедуры.

FILE - предоставляет доступ на чтение любого файла на сервере, к которому есть доступ у самой системы MySQL и доступ на создание файла в директориях, на которые у MySQL есть права записи.

CREATE TABLESPACE (admin) - позволяет создавать/изменять/удалять пространства таблиц. Само это пространство является логическим и не связано со структурой БД или схемой. Оно декларирует расположение объектов БД на физических носителях и используется для оптимизации системы БД.

CREATE USER (admin) - позволяет создавать/изменять/переименовывать/удалять пользователей баз данных.

PROCESS (admin) - разрешает доступ к информации о потоках (процессах) исполняющихся на сервере.

PROXY (admin) - позволяет войти пользователем под видом другого пользователя. Используется администратором для проверки/отладки прав доступа у необходимого пользователя.

RELOAD (admin) - разрешает использование оператора FLUSH, который чистит кеш MySQL

REPLICATION CLIENT (admin) - позволяет выполнять операции SHOW MASTER STATUS, SHOW SLAVE STATUS и SHOW BINARY LOG.

REPLICATION SLAVE (admin) - данная привилегия необходима пользователям ведомого сервера БД, чтобы этот сервер мог подключаться к ведущему серверу в роли ведомого. Без этой привилегии ведомые сервера не смогут запрашивать обновления баз данных и таблиц у ведущего сервера.

SHOW DATABASES (admin) - позволяет выполнять оператор SHOW DATABASES. Пользователи, не имеющие подобной привилегии, при выполнении данного оператора смогут лишь увидеть базы данных к которым у них есть какие-либо права.

SHUTDOWN (admin) - привилегия позволяет выполнить оператор SHUTDOWN, выключающий MySQL сервер.

SUPER (admin) - привилегия, дающая право на множество операций:

• позволяет завершить процессы, принадлежащие другим пользователям
• изменить глобальные системные переменные
• включать/отключать логирование
• производить обновления даже при установленных правах на чтение для системных переменных
• запускать/останавливать репликации на ведомых серверах
• и пр.

ALL (admin) - пользователю, получившему данную привилегию, автоматически назначаются все права в рамках уровня привилегий (возможных привилегий в принципе, согласно контексту выдачи привилегий). Не назначается только привилегия GRANT OPTION в данном случае.

Назначение прав для пользователей MySQL в панелях управления хостингом

• DirectAdmin
• cPanel
• ISPmanager
• Webuzo

DirectAdmin

На главной странице DirectAdmin из под уровня пользователя в меню Your Account переходим в раздел MySQL Management :

Тут мы можем как создать нового пользователя для данной базы путем перехода по Create New Database User , так и привязать к ней существующего,. Следует отметить, что нет специально отведенного интерфейса для управления пользователями. Он доступен только посредством перехода через какую-либо базу данных. Чтобы дать пользователю права - переходим по ссылке modify privileges :

На странице привилегий выбираем те привилегии, которые хотим выдать пользователю на конкретную базу данных и сохраняем. Строка состояния напомнит на что и кому выделяются права:

После этого произойдет переход на страницу подтверждения сохранения. Всё, права выданы.

cPanel

На главной странице cPanel нам необходимо найти раздел Базы данных в нем перейти по Базы данных MySQL :

Все манипуляции с базами данных MySQL, пользователями БД и их правами производятся именно в этом меню.

Если у нас нет ни базы, ни пользователя, то создаем их в соответствующих разделах страницы:

Раздел Текущие базы данных обновится:

Создаем пользователя:

Раздел Текущие пользователи обновится:

Для назначения прав определенному пользователю к определенной базе данных нам необходимо найти на странице раздел Добавить пользователя в базу данных и добавить необходимого пользователя к необходимой базе данных:

После добавления пользователя к базе данных откроется диалоговое окно для назначения привилегий:

Кнопка «Все права» эквивалентна привилегии ALL, описанной в начале руководства, и назначит все возможные права пользователю в контексте принадлежности пользователя определенной группе пользователей на уровне всего MySQL сервера.

После подтверждения внесенных изменений будет переадресация на страницу, подтверждающую что указанные права были выданы и на странице управления базами и пользователями MySQL повторно обновится раздел Текущие базы данных :

Готово. Пользователь назначен базе данных.

ISPmanager Lite 5

При входе в ISPmanager в роли какого-либо пользователя необходимо перейти в Инструменты -> Базы данных из левого меню.

Далее на открывшемся интерфейсе управления базами данных необходимо выбрать необходимую базу и перейти в меню Users для перехода к интерфейсу управления пользователями БД. Если же баз данных нет, то создать новую можно перейдя по кнопке Add .

Следует заметить, что при создании новой БД представится возможность сразу создать нового пользователя, который будет назначен к этой базе данных. Либо же можно будет выбрать существующего пользователя, который также будет автоматически назначен этой базе данных.

В интерфейсе управления базой данных нам представится список всех пользователей этой базы данных в текущем аккаунте ISPmanager. Для редактирования прав необходимо выделить конкретного пользователя, которому назначаем права, и перейти в меню Изменить

После этого мы увидим все права, которые можно назначить этому пользователю:

По-умолчанию при создании пользователя и БД назначаются все права. Изменяем те, которые нам необходимо и сохраняем результаты. После этого Вас вернет на страницу управления пользователями баз данных.

Webuzo

Webuzo состоит из 2-х панелей: администраторская и пользовательская. Переходим в пользовательскую панель и на главной странице выбираем Manage Databases

На открывшейся странице мы можем:

• увидеть список существующих баз данных [Database(s) ];
• создать новую базу данных [Create Database ];
• увидеть список существующих пользователей баз данных [Database User(s) ];
• создать пользователя баз данных и назначить его определенной базе данных [Add User To Database ]

Если целевой базы данных пока что не существует, то переходим в Create Database и создаем новую базу данных:

Если все же целевая база данных уже существует, то в управлении базами данных нам необходимо перейти в Add User To Database и создать нового пользователя БД или указать какого-либо существующего для его привязки к базе данных:

При добавлении пользователя к базе данных откроется новое окно с запросом назначения прав этому пользователю. Выбираем необходимые нам права и подтверждаем изменения кнопкой Submit Changes .

При успешном изменении прав в текущем окне появится надпись Database Privileges Updated . Задача выполнена.