Настройка прав доступа к базам данных [BS Docs 4]

Что понадобится

1. Компьютер отвечающий минимальным системным требованиям для работы веб-сервера под управлением одной из операционных систем:
2. Права локального администратора на данном компьютере.
3. Дистрибутив для установки компонент «1С:Предприятие». Для настройки 64-разрядного модуля расширения веб-сервера, дистрибутив для установки 64-разрядного сервера «1С:Предприятие». В данном примере используется версия 8.3.4.389. Для более старых версий «1С:Предприятие» (8.1 и 8.2) алгоритм публикации баз данных в целом аналогичен.

Вступление

Эта статья в основном ориентирована на разработчиков ADP проектов. Возможно, Вы знакомы с 2-мя вещами относительно безопасности SQL сервера. Во-первых, безопасность – это не опция, как это было в Jet. Во-вторых, модель безопасности SQL сервера отличается от модели безопасности Access.

Эта статья также может быть полезна администраторам SQL серверов. Решения, предлагаемые здесь, могут помочь им в управлении безопасностью сервера средствами Access. Из содержания этой статьи администраторы могут узнать об управлении безопасностью сервера без использования графических средств Enterprise Manager или запуска Transact SQL (T-SQL)

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

Вторая часть статьи демонстрирует программные решения, основанные на управлении объектами SQL-DMO (SQL Distributed Management Objects) средствами Microsoft Visual Basic® for Applications (VBA). Поскольку SQL-DMO имеет иерархическую модель построения объектов, очень похожую на модель построения объектов Microsoft Office, то все, что необходимо, это больше узнать об объектах, свойствах, методах, и событиях SQL-DMO относительно безопасности.

.1. Файл default.vrd

В файле default.vrd описываются опубликованные Web-сервисы (элемент <ws>), а также указывается имя виртуального приложения (атрибут base) и строка подключения к информационной базе «1С:Предприятие» (атрибут ib). В данном примере для файловой информационной базы, строка подключения будет следующей:

ib="File="C:1C_BASEDemoAccounting";"

.2. Файл web.config

Файл web.config — это файл, определяющий параметры для ASP.NET web-приложения. В каждом web-приложении должен быть файл web.config, находящийся в его корневом каталоге. Наш виртуальный каталог не является исключением.

В текущем файле содержатся данные об обработчике «1С Web-service Extension», обрабатывающем запросы к данному приложению. Обработчик настроен таким образом, что все запросы передаются библиотеке wsisapi.dll, расположенной в каталоге bin, каталога с файлами «1С:Предприятие».

Данный обработчик можно найти (или добавить, если его нет) в Диспетчере служб IIS. Для этого необходимо выделить вкладку с текущим приложением и в окне свойств выбрать пункт «Сопоставления обработчиков» (Handler Mappings).

В таблице сопоставлений обработчиков увидим наш обработчик «1С Web-service Extension». Если такого обработчика в списке нет, его следует добавить выбрав в окне «Действия» (Actions) пункт «Добавление сопоставления сценария с подстановочными знаками» (Add Wildcard Script Map…).

При добавлении вводим имя обработчика и указываем путь к файлу wsisapi.dll. Данные параметры можно изменить и для действующего обработчика выбрав пункт «Изменить…» (Edit…) в окне списка действий.

Необходимо также убедиться, что для обработчика стоит флаг «Выполнение» (Execute) в окне изменений разрешений функции. Вызвать данное окно можно выбрав пункт «Изменение разрешений функции…» (Edit Feature Permissions…) в окне «Действия» (Actions).

Установка веб-сервера IIS

Устанавливаем веб-сервер Internet Information Server, который по умолчанию входит в поставку Microsoft Windows Server. При установке обязательно выбираем компоненты:

Подробно про процесс развертывания веб-сервера IIS я писал:

Установка компонент «1С:Предприятие»

На этот же сервер, где развернут веб-сервер IIS, устанавливаем «1С:Предприятие» (32-разрядные компоненты) обязательно выбрав при установке компоненты:

• 1С:Предприятие
• Модули расширения веб-сервера

Если планируется настроить 64-разрядный модуль расширения веб-сервера, то необходимо дополнительно запустить программу установки 64-разрядного сервера из соответствующей поставки «1С:Предприятие» и установить компоненту:

• Модуль расширения веб-сервера

Публикация базы данных на веб-сервере

Переходим к непосредственной публикации базы данных на веб-сервере. Для этого запускаем «1С:Предприятие» в режиме Конфигуратор для той базы, которую требуется опубликовать.  Затем в меню выбираем «Администрирование» — «Публикация на веб-сервере…»

Откроется окно настройки свойств публикации на веб-сервере. Основные поля необходимые для публикации уже заполнены по умолчанию:

• Имя виртуального каталога — имя по которому будет происходить обращение к база данных на веб-сервере. Может состоять только из символов латинского алфавита.
• Веб сервер — выбирается из списка найденных на текущем компьютере веб-серверов. В нашем случае это Internet Information Services.
• Каталог — физическое расположение каталога, в котором будут располагаться файлы виртуального приложения.
• Соответствующими флагами можно указать типы клиентов для публикации, а также указать возможность публикации Web-сервисов. В расположенной ниже таблице можно отредактировать список Web-сервисов которые будут опубликованы, а также в столбце «Адрес» изменить синоним, по которому будет происходить обращение к данному Web-сервису.
• Также для веб-сервера IIS есть возможность указать необходимость выполнения аутентификации на веб-сервере средствами ОС, установив соответствующий флаг.

Выбрав необходимые настройки публикации нажимаем «Опубликовать».

Если публикация прошла без ошибок, увидим соответствующее сообщение.

Публикация на веб-сервере IIS всегда выполняется для веб-сайта по умолчанию и для пула приложения по умолчанию. Стоит иметь ввиду, что при выполнении публикации из конфигуратора будет зарегистрирован 32-разрядный модуль расширения веб-сервера, а используемый по умолчанию пул приложений — DefaultAppPool — без настройки работает только с 64-разрядными приложениями.

Соответственно, дальнейшие действия зависят от разрядности модуля расширения веб-сервера, который планируется использовать. Для 32-разрядного модуля расширения веб-сервера, необходимо разрешить пулу приложений использовать 32-разрядные приложения, либо же зарегистрировать 64-разрядный модуль расширения веб-сервера. Об этом пойдет речь ниже

Настройка IIS для использования 32-разрядного модуля расширения веб-сервера

Запустим Диспетчер служб IIS (Internet Information Services (IIS) Manager). Сделать это можно из Диспетчера серверов (Server Manager) выбрав в меню пункт «Средства» (Tools) — «Диспетчер служб IIS» (Internet Information Services (IIS) Manager).

Здесь, развернув дерево в окне подключений, увидим, что для веб-сайта по умолчанию — Default Web Site — появился преобразованный в приложение виртуальный каталог с именем, которое мы задавали при публикации базы данных. Для завершения публикации осталось только разрешить 32-разрядные приложения для пула приложений по умолчанию. Для этого перейдем в дереве подключений на вкладку «Пулы приложений» (Application Pools).

В списке пулов приложений найдем пул с именем DefaultAppPool. Кликнем по нему правой кнопкой мыши и в контекстном меню выберем пункт «Дополнительные параметры» (Advanced Settings).

В открывшемся окне параметров пула приложения, в группе «Общие» (General) найдем пункт «Разрешены 32-разрядные приложения» (Enable 32-Bit Applications) и установим значение параметра равным True. Затем сохраним изменения нажав «ОК».

Настройка IIS для использования 64-разрядного модуля расширения веб-сервера

Зарегистрировать 64-разрядный модуль расширения веб-сервера можно с помощью утилиты webinst.exe соответствующей версии, расположенной в каталоге bin, каталога с установленной программой «1С:Предприятие», либо воспользоваться приведенным ниже способом.

Запустим Диспетчер служб IIS (Internet Information Services (IIS) Manager). Сделать это можно из Диспетчера серверов (Server Manager) выбрав в меню пункт «Средства» (Tools) — «Диспетчер служб IIS» (Internet Information Services (IIS) Manager).

Здесь, развернув дерево в окне подключений, увидим, что для веб-сайта по умолчанию — Default Web Site — появился преобразованный в приложение виртуальный каталог с именем, которым мы задавали при публикации базы данных. Для завершения публикации осталось только указать данному приложению использовать 64-разрядный обработчик запросов.

В таблице сопоставлений обработчиков найдем обработчик «1С Web-service Extension». Откроем данный обработчик, кликнув 2 раза по соответствующей строке в таблице.

Отредактируем обработчик, заменив путь к исполняемой dll 32-разрядного модуля расширения веб-сервера, который выбран в данный момент, на путь к 64-разрядной версии библиотеки. В данном примере меняем путь c «C:Program Files (x86)1cv88.3.4.389binwsisapi.dll» на «C:

Вьюшки

Допустим, что у нас есть две таблицы. В одной из них хранится список работников фирмы, а в другой находится информация о количестве отработанных часов в месяц и полученной заработной плате (белой и черной). Допустим, что к вам приходит налоговая инспекция и говорит, а покажите нам зарплату работников! А все ли вы налоги заплатили? Какие нужно выполнить действия?

Первое предложение поступило из третьего ряда – создать нового пользователя, которому разрешен доступ на чтение (изменение и другие права налоговой не нужны) таблиц со списком работников и зарплаты. При этом нужно не забыть закрыть колонку с черным налом, иначе босс даст по мягкому месту в районе копчика. В принципе, решение верное, но абсолютно не эффективное.

Лучшим вариантом может быть создание вьюшки (View). Вьюшка – это просто запрос на языке SQL, который выбирает данные, а в базе данных она выглядит как таблица и работа с ней происходит также. Из вьюшки можно выбирать данные SQL запросами и также назначать права. Получается, что будет выполняться запрос к запросу.

Окно создания вьюшки

Для создания вьюшки можно выполнить примерно следующий запрос:

CREATE VIEW Зарплата AS
SELECT разрешенные для налоговой поля
FROM Работники, Доходы
WHERE навести связи

Теперь в ветке Databases/Northwind/Views. Появился новый объект «Зарплата». Если щелкнуть по нему правой кнопкой и в появившемся меню выбрать All tasks/Manage permissions, то перед нами откроется окно настройки прав, как для таблиц. Настраиваем доступ для доступа налоговой и сохраняем. Чтобы просмотреть содержимое вьюшки нужно выполнить запрос:

SELECT *
FROM Зарплата

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

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

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

Изменение режима аутентификации

Одним из основных преимуществ, которое дает SQL-DMO программистам, работающим с MSDE и MSDE 2000, является реализация этой возможности, которая иначе была бы им недоступна. Вызвано это тем, что Enterprise Manager не включен в установочный пакет MSDE или MSDE 2000.

К примеру, клиентский компонент SQL Server Enterprise Manager дает возможность администраторам графическими средствами изменить режим аутентификации сервера:Windows аутентификация или смешанный режим. Проект ADP не предоставляет такой возможности. Однако следующая пара процедур позволит Вам изменить режим аутентификации сервера, даже не имея возможности использовать Enterprise Manager.

Индивидуализм

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

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

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

Клиент

Cookie:
• уникальный идентификатор юзера
• хэш

Концепция безопасности sql сервера

Этот раздел состоит из 4-х основных частей. Ознакомление начинается с описания аутентификации – процесса проверки пользователя на право доступа к базе данных сервера. Используя Enterprise Manager, SQL сервер предоставляет два вида аутентификации. Первая часть раздела показывает различия и сходства между ними.

Настройка прав доступа к базам данных [bs docs 4]

Открытие проекта adp

Иногда бывает необходимо из Вашего приложения SQL-DMO программно открыть проект ADP. Технология открытия проекта ADP не требует использования SQL-DMO, однако, Ваше приложение SQL-DMO может использовать преимущество такой возможности. В последнем примере кода этой статьи (прямо перед заключительным разделом) демонстрируется процедура создания нового пользователя.

Политика прав

Некоторые администраторы любят назначать права, взяв за основу какую-то существующую роль, например, public. Это не верно, потому что в этой роли может быть такие права, которые абсолютно не нужны пользователям. Старайтесь назначать права с самого нуля.

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

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

Права доступа

Теперь посмотрим, как можно назначать права доступа. Дважды щелкни по созданной ранее роли buh и снова откроется окно, которое было при создании, но в этот раз оно открылось для редактирования. Обрати внимание, что кнопка Permission стала доступной, чего не было раньше.

Настройка прав доступа в ролях

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

• Object имена объектов;
• Owner владелец объекта;
• SELECT разрешение на просмотр данных или выполнение команды SELECT. Доступно только для таблиц и вьюшек;
• INSERT разрешение на добавление данных или выполнение команды INSERT. Доступно только для таблиц и вьюшек;
• UPDATE разрешение на изменение данных или выполнение команды UPDATE. Доступно только для таблиц и вьюшек;
• DELETE разрешение на удаление данных или выполнение команды DELETE. Доступно только для таблиц и вьюшек;
• EXEC разрешение на выполнение хранимых процедур и функций. Доступно только для хранимых процедур и функций;
• DRI (declarative referential integrity) обеспечение целостности. Доступно только для таблиц, вьюшек и функций.

В новой роли никаких прав нет. Чтобы добавить возможность просмотра таблицы, например, Categories, нужно щелкнуть в квадрате на пересечении строки и Categories и колонки SELECT. Щелчок устанавливает в этом квадрате зеленую галочку, что соответствует разрешению.

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

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

Настройка прав доступа на колонки таблицы

Это действительно супер возможность, потому что некоторые колонки, отвечающие за целостность базы не должны изменяться пользователями, и тем более хакерами. На такие колонки лучше запретить операцию изменения (UPDATE) и если есть возможность то даже просмотр (SELECT).

Права на таблицы

Давай посмотрим, как можно давать права на определенные объекты. Для начала посмотрим таблицы. Выбери в дереве объектов ветку Databases/Northwind/Tables и в правой части будет показан список всех таблиц. Щелкни по любой таблице правой кнопкой и в появившемся меню выбери All tasks/Manage permissions.

Перед нами открывается окно настройки прав. Ничего не напоминает это окошко? Я тоже думаю, что дежавю какое-то :). Окно похоже на распределение прав ролей, только вместо списка объектов стоит список пользователей. Объект и так ясен – это та таблица, по которой мы щелкали, и ее имя виднеться в выпадающем списке вверху окна. Теперь нам остается только указать права для этого объекта различным пользователям.

Настройка прав на таблицу

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

Процедуры и функции

Современные сервера баз данных поддерживают очень удобную вещицу – хранимые процедуры и функции. Это код на языке PL/SQL или Transact-SQL (зависит от базы), который выполняется прямо на сервере баз данных. Через такие процедуры можно выполнять какие-либо действия на сервере или просто выбирать данные, как во вьюшке. Каждой процедуре можно назначать свои права.

При рассмотрении ролей мы уже видели процедуры в списке объектов, на которые можно назначать права и в этих строчках доступна только колонка EXEC (выполнение), потому что процедуры можно только выполнять.

Системные вьюшки

В каждой базе данных могут быть системные вьюшки, которые создаются сервером автоматически. Не советую разрешать к ним доступ, потому что они могут показать что-нибудь лишнее, что поможет хакеру поднять свои права или просто испортить данные. Системные вьюшки начинаются с префикса sys и в колонке Type списка светиться надпись System.

Заключение

Безопасность SQL Server построена на принципах, отличных от тех, что использовали программисты в базах данных Jet. Тем не менее, SQL Server Books Online тщательно документирует правила по безопасности SQL Server. Эта статья переводит основные правила BOL в специфические правила, цель которых использовать проект Access с SQL Server. Примеры кода, приведенные в этой статье, демонстрируют, как управлять безопасностью SQL Server с помощью Access.