|
Проблемы безопасности данных в системе 1С Предприятие 7.7. и MSSQL 2000
Введение
Все пользователи 1С работают с сервером MSSQL
посредством одной учетной записи MSSQL.
Права пользователя на работу с базой данных должны быть
не менее db_owner. Нужно отметить, что в 90% случаев
администраторы забывают выполнять эту процедуру до конца
и делают как проще – назначают учетную запись от имени
sa.
Потенциально получив пароль на
sa, злоумышленник получает полный
контроль над сервером и соответственно данными,
размещенными на нем. Получить же пароль и учетную
запись, на базу данных, прописываемую в конфигураторе не
просто – а очень просто. Не будем рассказывать, как это
делается в этой статье. Достаточно в поиске по
Internet набрать несколько фраз и в
вашем распоряжении будет ряд программ (или описания
алгоритмов) с помощью которых можно элементарно получить
пароль и учетную запись даже неопытному
пользователю.
Последствия этого можно представить –
это возможность украсть, модифицировать или уничтожить
всю необходимую информацию пользователю с минимальным
набором прав.
В данной статье рассмотрим способы защиты данных,
которые позволят обойти вышеописанные проблемы
безопасности и в тоже время не приведут к усложнению
администрирования системы.
Рассмотрим два варианта организации системы защиты
для 1С Предприятие 7.7. MSSQL на базе Windows
авторизации. Естественно
материал данной статьи подразумевает некоторый уровень
подготовки читателя ,понимание терминологии а также
основных принципов организации доменной структуры
безопасности.
Описание технологии
безопасности на базе Windows авторизации и применения
application role в MSSQL 2000.
Основные требования к
системе:
- Безопасность хранения пароля
- Невозможность входа в базу SQL посредством других
приложений без соответствующего набора прав.
- Аутентификация пользователей в системе SQL
посредством Windows авторизации.
- Однозначное соответствие между пользователями 1С и
пользователями Windows NT.
Реализация Необходимо
всех пользователей базы разбить на три Windows NT
группы:
- Обычные пользователи 1С
Обычные
пользователи, не обладающие правами для монопольного
входа в систему.
- Продвинутые пользователи
1С
Пользователи, обладающие правами
монопольного входа в систему. Они могут выполнять
регламентные процедуры: открытие периода, добавление
новых счетов и т.п.
- Программисты 1С
Пользователи, обладающие
правами на вход в конфигурацию системы и изменение
структуры БД
Каждая группа Windows NT будет соответствовать
определенной application role c ограниченными правами
доступа к SQL.
- Обычные пользователи 1С
db_reader,
db_reader + execute всех процедур базы
- Продвинутые пользователи 1С
db_owner
- Программисты 1С
db_owner
Возникает вопрос, а зачем вообще нужен механизм
application role если можно было бы соответствующие
права дать прямо на Windows NT группу?
Ответ
очевиден, только для того что бы пользователь не мог
зайти из другой программы в базу, например из Query
Analyzer. Из этого требования возникает дополнительное
требование - у всех трех групп на уровне Windows
аутентификации есть права доступа только public, т.е.
только на соединение с базой.
Также для каждой из групп необходимо разработать
отдельную программу стартер. Права на запуск своего
стартера будут обладать только члены соответствующей
группы.
Стартер нужен для того, что бы определять текущего
Windows пользователя и его домен. После определения
пользователя стартер запускает процесс 1cv7s.exe
передавать туда в качестве параметров командной строки
имя пользователя и имя базы.
Во время запуска
процесса 1cv7s.exe, стартер подменяет вызов сессии 1С со
стандартного на коннект с Windows авторизацией. После
авторизации пользователя, пока что у него нет никаких
прав к базе, стартер инициирует применение application
role которая наделяет соответствующего пользователя
необходимыми правами.
Алгоритм хранения пароля или
даже автогенерации пароля реализован внутри стартера и
хорошо защищен.
Заметим, что в данном механизме нет
патчинга bkend.dll и т.п.
С точки зрения
администратора данная схема настройки безопасности
выглядит следующим образом: Необходимо
выполнить следующие пункты:
- Завести три доменные группы
- Для каждой группы завести соответствующую
application role и назначить им пароли либо определив
для стартера алгоритм генерации.
- Выдать права на запуск соответствующего стартера
по группам. Разместить их естественно нужно на каких
либо сетевых ресурсах.
- Внутри 1С всех пользователей необходимо завести
соответственно к имени login name Windows NT
по четко определенному алгоритму.
Например
пользователь с доменным именем domenivanov в
1С должен называться ivanov_domain.
- Прописать в конфигурации
ПриНачалеРаботыСистемы вызов метода
компоненты, которая будет первый раз после изменения
структуры выдавать права execute на все процедуры базы
для роли Обычные пользователи 1С. Также в
процедуре ПриНачалеРаботыСистемы необходимо
прописать проверку на соответствие имени Windows NT к
имени пользователя в 1С.
Если соответствие будет
нарушаться - то можно либо закрывать 1С, либо
действовать по любому другому алгоритму.
Как выглядит для пользователя использование 1С при
подобной схеме реализации защиты?
Они это даже могут
и не почувствовать вовсе. Пользователь будет запускать
стартер, который можно даже назвать 1cv7s.exe и дать ему
ярлык соответствующий стандартному 1С.
После запуска
стартера он попадать в 1С где после выбора базы
автоматом войдет в нее под конкретным пользователем 1С
(который соответствует доменному).
Рассмотрим варианты, которые может попытаться
применить злоумышленник, что бы несанкционированно войти
в базу:
- Если он попытается запустить 1С без стартера в
надежде обойти систему, то это у него не выйдет – прав
то к базе у его группы нет (если он не администратор).
Права ему выдаст только потом стартер при загрузке
application role.
- Попытка зайти из внешнего приложения к базе ему
тоже ничего не даст. Windows права у него только на
public да и то если он заведен как пользователь 1С.
- Попытка без соответствующего набора прав запустить
стартер завершится неудачей. Запустить процесс без
прав на него со стороны Windows NT очень сложная
задача.
- Получить пароль application role тоже довольно
сложная задача, кроме всего прочего ставятся еще
несколько уникальных уровней защиты, которые в рамках
этой статьи не описываются.
Описание технологии
безопасности на базе Windows авторизации с применением в
MSSQL 2000.
Отличие данного механизма реализации от
вышеописанного в том, что защита доступа к данным SQL
строится не на базе application role а на базе Windows
аутентификации.
Вопрос закрытия доступа из других
приложений решается путем заведения параллельных учетных
записей пароль, на которые пользователь не знает.
Стартер при запуске определяет текущего пользователя и
запускает под соответствующей ему учетной записью
процесс 1С.
Пароль учетной записи пользователь не
знает и, следовательно, зайти например из QA не сможет.
В стартере реализован алгоритм, который определяет этот
пароль и запускает процесс 1С.
Естественно можно в
соответствие каждому из пользователей поставить одну
учетную запись, но это усложнит дальнейшие задачи
администрирования. Все пользователи с точки зрения SQL
сольются как бы в одного пользователя. Их будет сложно
идентифицировать в процессе работы. Поэтому имеет смысл
каждому пользователю завести такого же пользователя с
префиксом «1С» например. Пример:
Группа Windows NT:
User domain - 1C User domain
Пользователи группы User domain:
ivanov - 1C_ivanov
Sidorov – 1C_sidorov
....
....
Стартер при запуске будет идентифицировать текущего
пользователя «User» и будет запускать процесс 1С под
пользователем «1С_User». Таким образом, пользователи
будут четко идентифицированы с точки зрения SQL.
Естественно вручную делать это неудобно, поэтому
лучше реализовать все это через обработку, которая будет
автоматически делать «зеркальную» группу,
соответствующие «зеркальные» учетные записи и назначать
им пароль по алгоритму, который укажет
администратор.
Вполне логично возникает вопрос: "а как запустить 1С
под другим пользователем если это действительно нужно,
делать log off"? Естественно этот вариант возможен, но
крайне неудобен. Для подобной операции в Windows
реализован стандартный интерфейс. Достаточно выделить
ярлык программы которую мы хотим запустить, нажать
shift и одновременно нажать правую кнопку мыши.
После чего выбрать в меню Run as. Выбрав этот
пункт мы в появившемся диалоге указываем windows
пользователя и запускаем процесс 1С под ним.
|
