|
Видимо, некоторым требуется прочесть несколько раз для усвоения материала.
== FAQ ==
К сожалению, в некоторых биллинговых системах, использующих технологию «клиент – сервер», широко используется метод разграничения прав пользователей базы данных на уровне приложения, а не средствами SQL сервера. Основное преимущество данного решения – простота реализации. Фактичестки, в БД, существует всего 1 пользователь с супер-правами (как правило, это стандартный «sa» с паролем типа «123», а в «клинических» случаях – вообще без пароля). При авторизации пользователя, информация о пользователе берется из некоторой таблицы БД, где хранится имя пользователя, пароль (обычно – в открытом виде), а также уровень доступа пользователя. В особо «продвинутых» системах, этот механизм реализован в виде связки таблиц (юзер-группа-права), однако суть при этом не изменяется т.к. все пароли пользователей очень легко считать т.к. таблице с паролями должны быть открыты права на чтение всем пользователям.
== Отсюда читаем несколько раз до понимания сути ==
В АСР «Дельта» вышеназванный алгоритм не используется вообще. Ни в каких таблицах БД не хранятся пароли и уровень доступа пользователей. Функции обеспечения безопасности полностью реализованы только с помощью встроенных функций самого SQL сервера. Благодаря «тонкой» настройки прав на таблицы и хранимые процедуры обеспечивается защита данных от несанкционированного доступа – как чтения, так и изменения. В БД существует несколько ролей, согласно которым, пользователь, имеющий определенную роль, может выполнять те, или другие манипуляции с данными.
На рабочей станции, пароль, также нигде не хранится. При первом входе в «Дельту», пользователь вводит пароль, который при работе хранится только в переменной (фактически – в оперативной памяти), а при выходе из программы – не сохраняется. Поэтому, в случае несанкционированного доступа к локальной БД (например при копировании ее с компьютера пользователя на компьютер злоумышленника), никаким образом, невозможно вытащить пароль, под которым пользователь работал с базой в последний раз.
К сожалению, MS Access, по умолчанию, для связанных объектов (таблицы, запросы) хранит в себе ODBC строку подключения, включая пароль. Однако существуют способы «отучения» Access от этой «нехорошей привычки». Для связанных таблиц, при каждом входе в систему, выполняется процедура динамического подключения с опцией запрета сохранения паролей (этот процесс видно при старте программы). Данный алгоритм, обеспечивает также, возможность поочередной работы с БД разных пользователей с разными уровнями доступа – для каждого пользователя, при входе, создается своя модель безопасности, которая разрушается при закрытии программы, а том числе, при аварийном выходе из программы.
Что касается временных запросов (создание запроса к SQL серверу с пустым именем), то такие запросы, в любом случае, не сохраняются. Поэтому после закрытия такого запроса, сам запрос и строка подключения разрушается. Запросы, имеющие при создании имя (например, использующиеся в качестве источника строк для подчиненной формы) имеют строку подключения, в которой имя пользователя и пароль к серверу, также, не сохраняется. Данные меры обеспечения безопасности более чем достаточны для создания защищенной СУБД, усиление их излишне.
== до сюда ==
Дополниение: если спи#дить бэкап базы из него тоже не получится поднять пароли юзеров.
Еще вопросы?
|
