Введение
Все пользователи 1С работают с сервером MSSQL посредством одной учетной записи MSSQL. Права пользователя на работу с базой данных должны быть не менее db_owner. Нужно отметить, что в 90% случаев администраторы забывают выполнять эту процедуру до конца и делают как проще – назначают учетную запись от имени sa.
Потенциально получив пароль на sa, злоумышленник получает полный контроль над сервером и соответственно данными, размещенными на нем. Последствия этого можно представить – это возможность украсть, модифицировать или уничтожить всю необходимую информацию пользователю с минимальным набором прав.
В данной статье рассмотрим способы защиты данных, которые позволят обойти вышеописанные проблемы безопасности и в тоже время не приведут к усложнению администрирования системы.
Рассмотрим два варианта организации системы защиты для 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_writer + execute всех процедур базы
- Продвинутые пользователи 1С
db_owner
- Программисты 1С
db_owner
Возникает вопрос, а зачем вообще нужен механизм application role если можно было бы соответствующие права дать прямо на Windows NT группу?
Ответ очевиден, только для того что бы пользователь не мог зайти из другой программы в базу, например из Query Analyzer. Из этого требования возникает дополнительное требование - у всех трех групп на уровне Windows аутентификации есть права доступа только public, т.е. только на соединение с базой.
Также для каждой из групп необходимо разработать отдельную программу стартер. Правами на запуск своего стартера будут обладать только члены соответствующей группы.
Стартер нужен для того, что бы определять текущего Windows пользователя и его домен. После определения пользователя стартер запускает процесс 1cv7s.exe и передает туда в качестве параметров командной строки имя пользователя и имя базы.
После авторизации пользователя, пока что у него нет никаких прав к базе, стартер инициирует применение 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С под ним.
Компания "СофтПоинт" разработала все вышеописанные компоненты и механизмы, и готова их Вам предложить с подробным описанием технологии. Использование данного программного комплекса позволит существенно увеличить безопасность Ваших данных.
Комментарии
1