Что такое безопасность? Часто считается, что для обеспечения безопасности достаточно задать пароль учетной записи или зашифровать данные. В некоторых случаях это так и есть. Но правильней будет уточнить, что данные меры усиливают защиту информации на некоторых «участках» функционирования системы. Обеспечение защиты данных понятие комплексное. Часть мер по организации контроля доступа к информации осуществляется техническими средствами, в том числе 1С:Предприятием, СУБД (например, Microsoft SQL Server) и операционной системой. Часть мер представляет собой набор административных действий и правил компании.
В данной статье будут рассмотрены вопросы безопасности информационных систем, работающих под управлением 1С:Предприятия 8.1 в клиент-серверном варианте с использованием СУБД MS SQL Server.
Базовый принцип защиты данных в клиент-серверном варианте заключается в том, что пользователи не имеют прямого доступа к файлам информационной базы. «Посредником» между клиентами 1С:Предприятия 8.1 и сервером СУБД является рабочий процесс rphost, который обращается с запросом к СУБД от имени своей учетной записи. Затем полученный результат возвращает клиенту.
Однако, использование клиент-серверного варианта не означает автоматически стопроцентную защиту информации. Важно правильно настроить систему в соответствии с конкретными требованиями безопасности.
Хотите пример?
В нашем примере, в некой компании Х в качестве сервера баз данных установлен MS SQL Server 2000 с настройками по умолчанию. В качестве учетной записи контекста исполнения службы «MSSQLServer» была выбрана учетная запись операционной системы. После развертывания клиент-серверного варианта 1С:Предприятие 8.1 для пользователей конфигурации были созданы учетные записи и назначены пароли. Дополнительных настроек связанных с безопасностью не производилось.
На первый взгляд все в порядке, пользователи не имеют доступа к файлам серверов приложений и СУБД. «Взлом» будет засчитан после получения злоумышленником доступа к учетной записи администратора сервера с MS SQL Server.
По нашему сценарию один из сотрудников компании Х становится злоумышленником. У него есть собственный ноутбук. И он работает с информационной базой от имени своей "законнной" учетной записи, как и большинство пользователей компании.
Администраторы, пренебрегли настройками прав доступа пользователей и оставили возможность выгрузки информационной базы при помощи конфигуратора.
Злоумышленник выгружает информационную базу себе на локальный диск в виде файла DT. Теперь он может развернуть ее локально у себя на компьютере или передать "врагам".
Другой возможной опасностью является отсутствие учетной записи администратора кластера на сервере 1С:Предприятия. Это позволит злоумышленнику создать на своем компьютере новую информационную базу на том же сервере 1С:Предприятия, который обслуживает рабочую базу.
В своей информационной базе злоумышленник создает превелигерованный модуль, исполняемый на стороне сервера. Этот модуль работает от имени учетной записи сервера 1С:Предприятия и, естественно, имеет полный доступ ко всем данным 1С:Предприятия. В том числе этот модуль может прочитать файл настроек C:\Program Files\1cv81\server\reg_1541\ 1CV8Reg.lst, где для баз среди параметров хранятся логин и пароль, под которым происходит подключение к SQL Server.
Примечание. С версии 8.1.6 пароли логинов СУБД в файле настроек шифруются. Тем неменее надо помнить про подключение через USR1CV81, когда логин и пароль в параметрах базы опускаются.
Причина, позволившая нам прочитать файл настроек – это доступ к файлу для учетной записи процесса rphost, совпадающей по умолчанию с учетной записью процесса ragent и rmngr.
Зная логин и пароль, злоумышленний подключается к MS SQL Server 2000 и выполняет для базы master такой скрипт:
EXEC xp_cmdshell 'net user Neo passW0rd /add' EXEC xp_cmdshell 'net localgroup Administrators Neo /add'
Эта команда содает пользователя с именем Neo и администраторскими правами на сервере, где установлен MS SQL Server.
Причиной, позволившей нам выполнить команды операционной системы, является учетная запись SQL Server, которая по умолчанию имела максимально возможные права.
Для того, чтобы избежать подбных ошибок, рассмотрим более детально, как работают механизмы защиты.
Комплексное понятие безопасности системы складывается на соновании ее защищенности на различных участках. Можно выделить три основных участка защиты данных:
При подключении к информационной базе пользователь указывает свой логин и пароль. Если в системе существует учетная запись с соответствующими параметрами, то доступ разрешается. Учетная запись создается для каждой информационной базы, используемой пользователем. При этом выполняется запрос к рабочему процессу кластера, расположенному на сервере 1С:Предприятия. Информация, передаваемая по сети на данном участке может быть зашифрована полностью или частично. Безопасность работы кластера обеспечивается исполнением приложения от имени учетной записи 1С:Предприятия в Windows. Контроль доступа к общим настройкам кластера осуществляется от имени учетной записи администраторов кластера 1С:Предприятие 8.1.
Защита данных, передаваемых между кластером серверов 1С:Предприятия и сервером СУБД, осуществляется средствами СУБД. MS SQL Server позволяет организовать шифрование передаваемых данных с помощью сертификатов.
В настоящей статье рассматриваются только технические меры обеспечения безопасности. Следует иметь в виду, что существует и такой фактов безопасности, как пользователь. Даже самая совершенная защита не может гарантировать безопасность системы, если к ней имеет доступ недобросовестный или неаккуратный пользователь. Системный администратор владеет информацией о паролях, главный бухгалтер - финансовой информацией о компании и т.д. Это значит, что всегда есть еще одно звено системы, которое может оказаться самым уязвивым в защите информации. Политика регулярной смены паролей, проводимая системным администратором, может быть сведена «на нет», если пользователи решат, что хранение «сложных» паролей надо доверить памяткам на мониторе своих рабочих мест.
Следующую таблицу можно использовать как памятку при проведении аудита безопасности системы.
| Вероятная угроза безопасности | Участок | Вероятность | Последствия | Вероятный злоумышленник | Трудоемкость |
|---|---|---|---|---|---|
|
1. Доступ пользователей к административным действиям конфигуратора |
Клиент | Высокое | Копирование всей информации | Программист, продвинутый пользователь | Средняя |
| 2. Отсутствие разграничений доступа в режиме 1С:Предприятие" | Клиент | Среднее | Копирование ключевой информации | Программист, продвинутый пользователь | Высокая |
| 3. Несанкционированный доступ к данным сервера СУБД | СУБД | Средняя | Порча информации, копирование информации | Администратор | Средняя |
| Клиент, Кластер, СУБД | Низкая | Последствия зависят от прав учетной записи | Уволенный сотрудник | Низкая | |
| 5. Несанкционированный доступ к файлам кластера серверов | Кластер | Низкая | Порча информации, возможность создания новых баз | Администратор, программист | Низкая |
| 6. Наличие уязвимостей операционной системы, СУБД | Клиент, Кластер, СУБД | Низкая | Повышение прав с помощью ломалок, опубликованных в интернете, возможно полное копирование информации | Администратор, Продвинутый пользователь | Низкая |
| 7. Вирусы, трояны, логгеры | Клиент, Кластер, СУБД | Низкая | Порча информации, получение данных, раскрытие паролей пользователей | Администратор, Продвинутый пользователь | Низкая |
| 8. Пароли на мониторах, слабые пароли | Клиент | Средняя | Несанкционированный доступ к учетным записям пользователей с последующим доступом к данным | Продвинутый пользователь, уволенный сотрудник | Низкая |
| 9. Перехват информации | Клиент-Кластер, Кластер-СУБД | Минимальная | Перехват паролей с последующим доступом к данным | Высоко квалифицированный системный программист, сетевой специалист | Высокая |
Следует понимать, что данная памятка является примером общего подхода к аудиту информационной безопасности вашей системы. Серьезность каждой угрозы может быть различной в каждом конкретном случае.
Для аудита безопасности вашей системы необходимо заполнить аналогичную таблицу, исходя из вашей реальной ситуации. При этом следует внимательно оценивать риски (например, к чему может привести кража "оборотно-сальдовой ведомости") и средства, выделяемые на снижение рисков (что можно сделать без выделенного специалиста безопасности, сколько будет стоит автоматизация доступа по картам сотрудников и т.п).
Начинайте аудит с наиболее серьезных угроз. После этого переходите к мероприятиям защиты с наименьшими трудозатрами. Помните, что система защиты информации не должна быть слишком сложна.
Каждая учетная запись пользователя принадлежит к одной или несколькими ролям. Роль – это набор прав. Некоторые права предоставляют возможность копирования информации или выполнения административных действий. Такие права должны быть только у пользователей, которым они необходимы по служебным обязанностям. Например, у администратора базы данных.
Составьте список всех ролей, имеющих права на выполнение административных функций. Затем составьте список пользователей, которые приписаны к этим ролям. Каждый из пользователей, перечисленных в списке сможет выполнять следующие действия:
Убедитесь в том, что для каждого пользователя из списка верно следующее:
Как показывает практика, вероятность возникновения такой угрозы очень высока.
В качестве последствий следует особенно отметить копирование информационной базы.
Назначайте административные права только тем пользователям 1С:Предприятия, которым это действительно необходимо.
Выделите права, которыми должен обладать только администратор базы и лишите этих прав всех остальных пользователей. Обычно, к таким правам относятся:
Для того, чтобы ограничить возможности злоумышленников по копированию базы данных на внешние носители (дисководы, USB-носители и т.п.) можно использовать групповые политики Active Directory.
Доступ к информации в режиме 1С:Предприятие определяется ролями (списком прав), также механизмами, реализованными кодом конфигурации. Для типовых конфигураций 1С это механизм ограничения доступа к данным на уровне записей и полей. Более подробно здесь. Неправильно назначенные права могут привести к несанкционированному доступу к данным.
На рисунке показан пример настройки прав менеджерам по продажам в типовом решении 1С.
Пример настройки прав в отраслевом решении.
Для проверки наличия угрозы необходимо проделать достаточно большую и кропотливую работу по сверке прав учетных записей пользователей и тех уровней доступа, которые должны иметь сотрудники.
Угрозой является наличие у пользователя прав доступа к той информации, которая не должна быть ему доступна. Серьезность этой угрозы определяется в каждом конкретном случае индивидуально.
Вероятность данной угрозы оценивается как средняя. Последствием может быть несанкционированный доступ пользователей к данным информационной базы.
Необходимо привести права доступа в соответствие с должностными обязанностями каждого сотрудника. Эта задача, в общем случае, является достаточно трудоемкой. Имеет смысл начинать проверку прав доступа и приведение их в соответствие с наиболее критичных областей данных.
Проверьте следующие признаки угрозы:
Полный доступ к информационным базам, хранящимся на MS SQL Server.
Ниже приведены меры защиты в порядке возрастания сложности реализации:
Например, это можно сделать с помощью команды:
ALTER LOGIN sa DISABLE
На рисунке показано успешное отключение логина SA.
3.3.1.2. Для выполнения административных функций создайте учетную запись с другим именем. Включите эту учетную запись в роль sysadmin.
Задать пароль через Transact-SQL можно так:
ALTER LOGIN my_sa WITH PASSWORD = 'Ple@se_Don''t_C0mprom1se_My_SQL_S3rv3r_Bec@us3_It_Is_V3ry_Ne@r_And_D3ar_To_My_H3@rt'
В этом примере для логина my_sa будет указан сложный пароль. (Смена пароля в версии MSDE описана на сайте Microsoft)
Процедура xp_cmdshell имеет доступ к ресурсам операционной системы сервера СУБД, в частности к диску, на котором физически находитсябаза данных.
Эта группа ролей имеет доступ к административным функциям базы данных. Если кто-то из пользователей Windows входит в эту группу, то он тоже получает этот доступ.
Создать пользователя и наделить правом создавать базы можно так:
Копировать в буфер обменаUSE [master]GOCREATE LOGIN [user1c] WITH PASSWORD=N'P@ssw0rd' GO EXEC master..sp_addsrvrolemember @loginame = N'user1c', @rolename = N'dbcreator' GO
В данном пример в результате успешного выполнения появиться пользователь user1c и будет обладать ролью 'dbcreator'.
Наделить учетную запись ролью ' SecurityAdmin ' можно так:
EXEC master..sp_addsrvrolemember @loginame = N'user1c', @rolename = N'securityadmin' GO
Примечание. Посмотреть набор прав для роли можно с помощью хранимой процедуры sp_srvrolepermission.
Наример, для роли dbcreator:
Копировать в буфер обменаexec sp_srvrolepermission 'dbcreator'
Это делается с помощью хранимой процедуры sp_changedbowner.
Такой подход позволит не предоставлять учетным записям пользователей роль dbcreator. То есть, пользователи не смогут самостоятельно создавать базы данных.
Использование sp_changedbowner для смены владельца базы данных:
Копировать в буфер обменаUSE db_buh GOEXEC sp_changedbowner user1c
GO
В этом примере db_buh - имя базы данных, user1c - имя пользователя, который должен стать владельцем базы.
Доступ к серверу должен быть предоставлен только администраторам сервера и учетной записи служб кластера серверов 1С:Предприятие 8.
Пример настройки доступа
Необходимо учитывать, что в некоторых случаях это может привести к некоторому замедлению работы из-за передачи данных по сети.
Для компьютера, на котором запущен MS SQL Server лучше оставить работающим приложением только MS SQL Server, исключив такие сервисы как "общий файловый доступ", "почтовый сервер", "интернет-прокси", "веб-сервера" и т.п.
Пример отключения файлового доступа по сети.
Все системные администраторы делятся на тех, кто делает бэкапы, и тех, кто их будет это делать после того, как первый раз потеряет важные данные в результате аппратного сбоя.
Уделите внимание безопасности хранилища, в котором содержатся резервные копии инфомационны баз. Помните, что если злоумышленнику будет проще унести резервную копию, чем взломать работающую систему, то он именно так и поступит.
Безопасность исполнения операций сервера MS SQL Server в операционной системе определяется его учетными записями. Это учетные записи служб SQL Server, Agent SQL Server и Browser SQL Server для SQL Server 2005.
Например, SQL Server имеет доступ к исполнению процедуры «xp_cmdshell», которая позволяет работать с командной строкой Windows. Процесс Windows, порожденный процедурой xp_cmdshell, имеет те же права защиты, что и учетная запись службы SQL Server.
Если учетная запись обладает правами системы или входит в группу Администраторы, то xp_cmdshell возволяет выполнять любые действия в операционной системе сервера СУБД. Если учетная запись входит только в группу Пользователи, возможности xp_cmdshell эквивалентны возможностями простого пользователя.
В SQL Server 2005 функциональность «xp_cmdshell» по умолчанию отключена в целях повышения безопасности.
На рисунке показана консоль SQL Server 2005 Surface Area Configuration, управляющая возможностью включения/выключения наиболее «вероятных» целей злоумышленников, в том числе xp_cmdshell.
Для работы 1С:Предприятие 8.1 все указанные в этой консоли функции могут быть выключены. Некоторые системные администраторы наделяют учетную запись службы административными правами «просто, чтобы работало». Чтобы организовать повышенную безопасность, практикуется «Принцип минимальности привилегий» - субъект должен обладать набором минимально необходимых прав для выполнения своих функций.Применительно к службам SQL Server это означает следующее:
Учетной записи, от имени которой работают службы сервера, присваиваются следующие пользовательские права и привилегии:
Запрет локальной регистрации в системе и соединения посредством сервера терминала ограничивают возможности злоумышленника в случае компрометации системы. Также необходимо удалить группу Domain Users у пользователей, имеющих право Logon Locally.
Для работы службы Agent SQL Server рекомендуется выбирать учетную запись пользователя Windows, не входящую в группу Администраторы. Однако существуют ограничения при администрировании нескольких серверов, когда учетная запись службы агента SQL Server не входит в локальную группу Администраторы. В частности, группы Администраторы требуется, чтобы использовать возможность автоматического перезапуска или создания типов CmdExec (вызов команд операционной системы) и ActiveX Script, не принадлежащие администратору SQL Server.
Browser SQL Server выполняется как служба Windows и запускается на UDP-порту 1434. При запуске обозреватель SQL Server считывает данные из реестра, определяет все экземпляры SQL Server на данном компьютере и назначает для них порты. Обозреватель SQL Server прослушивает входящие запросы на ресурсы Microsoft SQL Server и предоставляет сведения об экземплярах SQL Server, установленных на компьютере. При остановке или отключении службы «SQL Server, обозреватель» необходимо назначить каждому именованному экземпляру конкретные номера портов. Права, которые необходимо назначить обозревателю SQL Server для повышения безопасности:
Для работы экзмепляра по умолчанию (Default) обозреватель не требуется. В MS SQL Server 2000 роль обозреватель выполняла служба SQL Server.
Более подробно о настройке служб можно прочитать на сайте Microsoft.
Доступ к MS SQL Server выполняется после прохождения авторизации на сервере. Это можно сделать, используя учетную запись, созданную средствами MS SQL Server или с помощью учетной записи Windows.
Это использование логинов SQL Server-а, которые в консоли управления сервером находятся в разделе Security и использования учетных записей Windows. Доступ к базам данных происходит путем ассоциаций прошедших авторизацию на сервере пользователей с пользователями баз данных.
Для работы учетный записей SQL Server-а необходимо использовать смешанный (mixed) режим проверки подлинности пользователей. В большинстве случаев это можно сделать с помощью c графических утилит доступа. Однако для MSDE версии MS SQL Server 2000 оснастки нет. В этом случае можно переключить режим с помощью рееста.
Для работы 1С:Предприятие 8.1 с MS SQL Server используется режим авторизаци MS SQL Server и Windows. Если при установке был выбран режим авторизации только Windows (Windows only) - то подключиться к информационной базе 1С:Предприятия 8.1 не получится.
Для изменения типа авторизации откройте SQL Server Enterprise Manager.
В дереве "Concole Root - Microsoft SQL Servers" разверните группу SQL Server Group и выберите необходимый сервер (соответствует или имени компьютера или (local) - для локального сервера).
Если серверов нет - надо зарегистрировать новый сервер, выбрав из меню Action - New SQL Server Registration...
На значке сервера сделайте правый щелчок мышкой и в контекстном меню выберите Properties. В появишемся окне перейдите на закладку Security.
В разделе Security укажите Authentication на SQL Server and Windows.
Перезапустите сервис например с помощью командной строки:
net stop mssqlservernet start mssqlserver
или перегрузите компьютер с установленным MS SQL Server.
Для изменения типа авторизации откройте SQL Server Management Studio.
В меню File – Connect Object Explorer и выберите необходимый сервер.
Далее в окне Object Explorer на значке сервера сделайте правый щелчок мышкой и в контекстном меню выберите Properties. В появишемся окне перейдите на закладку Security.В разделе Server authentication укажите SQL Server and Windows Authentication mode.
Перезапустите сервис. Для этого значке сервера сделайте правый щелчок мышкой и в контекстном меню выберите Restart.
По умолчанию параметр реестра LoginMode имеет значение 1 (проверка подлинности Windows). Чтобы включить смешанный режим, значение этого параметра необходимо изменить на 2.
Место расположения параметра LoginMode зависит от имени, под которым установлен экземпляр MSDE. Если MSDE была установлена с именем по умолчанию, параметр LoginMode находится в следующем разделе реестра:
HKLM\Software\Microsoft\MSSqlserver\MSSqlServer\LoginMode
Если MSDE была установлена под другим именем, параметр LoginMode находится в следующем разделе реестра:
HKLM\Software\Microsoft\Microsoft SQL Server\имя_экземпляра\MSSQLServer\LoginMode
При использовании SQL Server 2005 Express Edition параметр LoginMode находится в следующем разделе реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.4\MSSQLServer
Чтобы присвоить параметру LoginMode значение 2, выполните следующие действия.
1. С помощью компонента «Службы» панели управления остановите MSSQLSERVER и другие связанные службы (например, SQLSERVERAgent).
2. Нажмите кнопку Пуск, выберите пункт Выполнить, введите команду regedt32 и нажмите кнопку ОК.
3. Найдите следующий раздел реестра (в соответствии с именем, под которым была установлена MSDE):
HKEY_LOCAL_MACHINE\Software\Microsoft\MSSqlserver\MSSqlServer\
HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\имя_экземпляра\MSSQLServer\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.4\MSSQLServer\
4. На правой панели окна редактора реестра дважды щелкните параметр LoginMode.
5. В диалоговом окне Изменение параметра DWORD установите для параметра значение 2, выберите вариант Шестнадцатеричное и нажмите кнопку ОК.
6. Чтобы изменения вступили в силу, запустите службы MSSQLSERVER и SQLSERVERAgent.
Обратите внимание. Что возможность управления переключением режимов аутентификации при определенных условиях может воспользоваться злоумышленник.
Как компромисный вариант, использовать серверную стойку и предоставлять ключи лицам по утвержденном списку.
В Интернете можно найти статьи, рекомендующие шифровать данные баз данных. Это можно делать и штатными средствами Windows, и используя ключи eToken, и программы сторонних производителей типа Jetico Bestcrypt или PGPDisk. Кроме этого можно встретить рекомендации создавать базы данных в нескольких файлах, один из которых шифровать.
Однако, в большинстве случаев рекомендуется сосредоточить внимание не на шифровании дисков, а на максимальном ограничении интерактивного, сетевого и физического доступа к ним.
Путем использования неформатированных разделов дисков можно обеспечить высокий уровень безопасности информации в базе данных. При этом, в некоторых случаях, может вырасти быстродействие дисковой подсистемы.
SQL Server позволяет использовать для создания файлов базы данных «неформатированные» (или «сырые» — raw) разделы. Неформатированный раздел — это раздел диска, который был создан с помощью утилиты fdisk или Disk Administrator, но не был отформатирован. На таком разделе не существует файловой системы (FAT или NTFS), поэтому там невозможно хранение файлов операционной системы. Тем не менее, если при создании базы данных в качестве физического имени файла указать неформатированный раздел, то SQL Server 2000 создаст в этом разделе блок данных (назовем его файлом), который займет все свободное пространство. Так как при создании файла будет занято все доступное пространство, то увеличение размера файла в данном случае невозможно. В качестве физического имени файла необходимо указать только букву раздела, например F. Задание неформатированного раздела другим способом (а такие имеются — например формат, используемый в файле boot.ini) не допускается. То есть, чтобы иметь возможность разместить файл базы данных на неформатированном разделе, нужно присвоить этому разделу конкретную букву, сконфигурировав его, таким образом, в качестве логического диска.
На неформатированном разделе можно разместить лишь один файл базы данных. Даже после того как SQL Server создаст в этом разделе файл, операционная система будет воспринимать раздел как неформатированный или как раздел с неизвестной файловой системой. Обычные операции работы с файлами, выполняемые операционной системой, будут недоступны. То есть нельзя будет выполнять копирование, удаление, изменение или перемещение созданного файла. Кроме того, операции резервного копирования с помощью утилиты Windows NT Backup также будут недоступны. Однако допускается создание резервных копий базы данных и журнала транзакций средствами SQL Server. При использовании неформатированных разделов недоступны инструменты проверки целостности диска. Более того, невозможна «горячая» замена поврежденных кластеров, которая выполняется для файловой системы NTFS на дисках SCSI. При размещении файлов базы данных на обычных дисках с файловой системой имеется возможность скопировать эти файлы и подключить к другому серверу SQL. При наличии неформатированных разделов скопировать данные будет практически невозможно, так как в операционных системах семейства Windows не реализованы механизмы работы с неформатированными разделами.
Рекомендуется создать базу данных из одного файла данных, расположенного на неформатированном разделе. В идеале файлы журнала транзакций также могут быть расположены на неформатированных разделах. Для каждого файла базы данных потребуется отдельный неформатированный раздел.
Пример cоздания базы db_buh в неформатированном разделе.
Копировать в буфер обменаUSE masterGOCREATE DATABASE db_buhON ( NAME = db_buh, FILENAME = 'f:') LOG ON( NAME = 'db_buh_log', FILENAME = 'g:' ) GO
На рисунке показан пример создания базы в сырых разделах дисков F и G.
Среди учетных записей, используемых системой могут оставаться те, которые принадлежали уволенным сотрудникам. Необходимо организовать регулярную процедуру проверки учетных записей.
Можно попробовать разработать автоматизированную процедуру проверки длительной неактивности учетных записей и их автоматического удаления
Уволенный сотрудник может воспользоваться своей старой учетной записью.
В данном случае обеспечение безопасности не является операцией, которая раз и на всегда решит проблему. Для поддержания необходимого уровня безопасности на данном участке необходимо организовать и проводить регулярную проверку всех учетных записей системы.
Следует понимать, что существует несколько видов учетных записей, которые используются при работе системы на различных уровнях ее функционирования.
1) Пользователи Windows (локальные учетные записи Windows и в службы каталогов Active Directory)
Факт применения учетной записи Windows можно опредлить по журналу событий безопасности Windows.
2) Пользователи информационных баз 1С:Предприятия
Факт использования учетной записи фиксируется в журнале регистрации 1С:Предприятия
3) Пользователи сервера MS SQL Server
Факт использования учетной записи фиксируется в логах MS SQL Server (в соответствии с настройками)
4) Пользователи баз данных MS SQL Server
5) Администраторы центрального сервера кластера серверов 1С:Предприятия 8.1
6) Администраторы кластера 1С:Предприятия
7) Учетные записи Windows для контекста исполнения служб 1С:Предприятие 8.1 и MS SQL Server (и других СУБД)
Кроме того, следует понимать, что:
Пользователи Windows (1) могут выступать как Пользователи 1С:Предприятие 8.1 (2), как Администраторы файла кластеров (5), и Администраторы кластера (6)
Пользователи Windows (1) могут быть Пользователями серверов СУБД (3). Однако 1С:Предприятие 8.1 использует учетные записи самой СУБД (3)
Пользователи СУБД (3) неявно получают доступ к базе данных «связывая» с учетной записью базы данных (4). Например, пользователь «dbo» – это владелец базы (dbowner). Пользователь СУБД с ролью «Создателя базы», в MS SQL Server это «dbcreator» считается пользователем базы «dbo»
Учетные записи Windows (1) также являются контекстом работы служб (7). Поэтому не предоставляйте эти записи для работы обычных пользователей (1),(2)
Разработчики конфигураций на платформе 1С:Предприятие также могут использовать программное разграничения доступа. Для этого, как правило, создается справочник «Пользователи». Управление настройками такого справочника выполняется в режиме «1С:Предприятие», а не Конфигураторе. Максимальные права доступа к справочнику «Пользователи» - чтение данных.
Признаки возможной угрозы:
Злоумышленник может получить пароли и общую информацию для подключения к серверу СУБД. Это может привести к тому, что ему станут полностью доступны данные информационных баз.
Создайте администратора центрального сервера
Если не задан администратор центрального сервера, то любой пользователь сможет создать новый кластер.
Создайте администратора кластера
Если не задан администратор кластера, то любой пользователь сможет редактировать параметры кластера.
Кластер серверов 1С:Предприятия использует для работы ряд служебных данных. Например, список кластеров сервера, реестры кластеров и др. Все служебные данные представляют собой совокупность файлов, которые находятся в двух каталогах:
Общая идеология работы со служебными данными заключается в том, что доступ к служебным данным кластера серверов должны иметь только менеджер кластера (rmngr.exe) и агент сервера (ragent.exe). Рабочие процессы (rphost.exe) используют служебные данные только через менеджер кластера, поскольку являются потенциально опасными (в них могут выполняться фрагменты кода конфигураций).
В каталоге данных приложения при установке кластера серверов 1С:Предприятия 8.1 создается специальный каталог, предназначенный только для файлов кластера серверов 1С:Предприятия.
Пользователю USR1CV81, от имени которого стартует по умолчанию агент сервера, назначаются полные права на этот каталог. Другим пользователям доступ в этот каталог запрещается. Запуск менеджера кластера выполняет агент сервера от имени того же самого пользователя, от которого запущен он сам.
Обратите внимание, если для рабочего процесса используется собственная учетная запись Windows, то она не имеет доступа к каталогу кластера.
Запуск рабочих процессов также осуществляет агент сервера. По умолчанию рабочий процесс запускается от имени того пользователя, от которого запущен и агент сервера. Однако предусмотрена возможность создания дополнительного пользователя операционной системы, от имени которого стартуют только рабочие процессы. Это позволяет предотвратить непосредственный доступ программного кода конфигураций к служебным данным.
Для того, чтобы rphost запускался от имени пользователя RPHOSTUSER, а
ragent запускается от USR1CV81, необходимо сделать следующее:
user=\\server\hostuser
password=пароль
Безопасность каталога временных файлов обеспечивается иначе. Поскольку системный каталог временных файлов является общедоступным, то в нем ограничиваются права доступа к каждому временному файлу отдельно.
Для этого при создании временного файла кластером серверов 1С:Предприятия пользователю USR1CV81 устанавливаются полные права на создаваемый файл. Другим пользователям доступ к этому файлу запрещается. Таким образом, данные, хранимые во временных файлах, защищаются от несанкционированного доступа.
Для сервера 1С:Предприятия исключите такие сервисы как "общий файловый доступ", "почтовый сервер", "интернет-прокси", "веб-сервера" и т.п.
Пример отключения файлового доступа по сети.
Как компромисный вариант, используйте серверную стойку и предоставляйте ключи лицам по утвержденном списку.
Вероятность угрозы оценивается, как незначительная. Последствия зависят от обнаруженной уязвимости. Риск взлома значительно уменьшается при отсутствии удаленного доступа к серверам из Интернета.
Выполняйте обновление операционной системы
Выполняйте обновление СУБД
Пользуйтесь услугами компаний, специализирующихся на безопасности
Присутствие вредоносных программ обнаруживается либо при помощи антивирусов, либо по факту вредоносной деятельности вируса.
Обычно вирусы не нацелены на взлом приложений 1С:Предприятия. Вероятность угрозы оценивается как невысокая. Однако, нарушение работы 1С:Предприятие может стать побочным эффектом деятельности вируса, поэтому пренебрегать этой опасностью не следует.
Брандмауэр – средство защиты , которое отслеживает и ограничивает обмен данными между компьютером и сетью или Интернетом, т.е. защищает компьютер от несанкционированного доступа извне.
Начиная с Windows XP, операционные системы компании Microsoft стали содержать втроенный брандмауэр (сетевой экран, firewall). Для Windows XP SP2 и Windows Vista брандмауэр по умолчанию включен.
Подробней на сайте Microsoft.
Для защиты данных в сети также могут применяться аппаратные и программные брандмауэры (межсетевые экраны) других производителей. Большинство программ не сможет принимать внешние запросы на соединение, если эти программы не внесены в список исключений брандмауэра.
Включенный брандмауэр (особенно программный) снижает быстродействие. В связи с этим рекомендуется избегать использования брандмаэров на сервере СУБД и сервере 1С:Предприятия.
Возможным последствием использования брандмауэра , который не настроен для работы с 1С:Предприятие 8.1, может быть сообщение об ошибке: «Не обнаружен ключ
Для обеспечения работоспособности 1С:Предприятие 8.1 , его необходимо добавить в список исключений брандмауэра.
Чтобы добавить программу 1С:Предприятие 8.1 в список исключений брандмауэра Windows XP SP2, необходимо выполнить следующие действия:
Если в сети используется компьютер с HASP License Manager и на нем включен брандмауэр, то необходимо добавить HASP License Manager в список исключений брандмауэра. В Windows XP SP2 для этого необходимо выполнить следующие действия:
Возможно случаи, когда брандмауэр включен на сервере, или в качестве сервера используется компьютер с настрольной операционной системой, например Windows XP SP2.
Совет. Вовсе не обязательно запоминать порты и исполняемые файлы, которые необходимо прописывать в брандмауэре.
Чтобы увидеть «реальную» картину работы клиент-серверного варианта и используемых портов (например, чтобы настроить брандмауэр) можно воспользоваться бесплатной утилитой TCPView.
Антивирусное программное обеспечение помогает защищать компьютер от известных вирусов, «червей», «троянцев» и других вредоносных программ, которые могут привести к сбою в работе компьютера. Однако антивирусное ПО требует аппартных ресурсов. При постоянно включенном мониторинге всех действий скорость выполнения всех остальных приложений, в том числе 1С:Предприятие 8 может заметно снизиться. Приведем рекомендации для каждого из компонент клиент-серверной архитектуры 1С:Предприятие 8.
Антивирусное программное обеспечение, работающее в реальном времени, отнимает значительные ресурсы у SQL Server. Использовать его не рекомендуется.
Вместо этого следует периодически сканировать SQL Server при помощи сканеров вирусов, предпочтительно в периоды минимальной нагрузки.
Так же рекомендуется избегать постоянно включенного мониторинга. Выполняйте сканирование на вирусы в периоды минимальной загрузки.
Компьютер с клиентской частью 1С:Предприятие 8 имеет наибольший риск заражения вирусами. Надо понимать, что используя антивирусную программу Вы должны выбрать разумный компромис между степенью защиты и быстродействием.
Как вариант настройки антивируса предлагается:
Основная сложность выбора настроек заключается в том, что 1С использует «опасные» каталоги, и при низком быстродействии или жалобах пользователей надо исследовать временные каталоги, как место потенциального попадания вирусов:
Если рассматриваемые в данном разделе риски высоки и отказаться от антивирусов и брандмауэра нельзя, расчитывайте на более мощное клиентское и сервное оборудование. Данное защитное ПО может расходовать значительные ресурсы компьютеров.
Полностью исключите возможность подключения к серверам через интернет.
Наличие действующих учетных записей уволенных сотрудников или не использующихся действующими сотрудниками больше месяца. Даже если сотрудник находится в отпуске, на время его отсутствия лучшим средством снизить риск является временно отключение пользователя или смена пароля.
Серьезность угрозы прямо зависит от прав записи данного сотрудника.
Пароли являются «первой линией защиты» от несанкционированного доступа к Вашей информации. Не смотря на все современные технологии, часто они становятся основной целью злоумышленника. Пользователи часто придумывают очень простые пароли. Они могут означать день рожденья пользователя, имя любимой кошки или номер сотового. Такие пароли легко подобрать, применяя общеизвестные закономерности. Другим способом является перебор всех возможных комбинаций символов.
Важно, чтобы пользователи составляли надежные пароли. Хороший пароль - это тот, который крайне трудно угадать или подобрать, но очень легко запомнить.
Для того чтобы обеспечить «сложные для взлома» пароли, в Windows используется политика "Пароль должен удовлетворять требованиям сложности":
содержит как минимум 7 символов;
сочетает в себе буквы, числа и специальные символы;
не содержится в словарях;
не является именем команды;
не является именем человека;
не является именем пользователя;
регулярно изменяется;
в значительной степени отличается от предыдущих паролей. 
Политика Windows представлена на рисунке.
Подробней о применении политики паролей Windows можно прочитать на сайте Microsoft. В MS SQL Server 2000 контроль сложных паролей отсутствует. В MS SQL Server 2005 cуществует возможность использовать политику сложных паролей Windows. Для каждого логина сервера политика назначается персонально. Т.е. один логин может отвечать требованиям сложного пароля, а другой – нет.
Паролями можно управлять через Transact-SQL:
Проверка сложности паролей пользователей также присутствует в 1С:Предприятии 8.1.
Для управления проверкой сложности выберите меню «Администрирование – Параметры информационной базы».
Если флажок «Проверка сложности паролей пользователей» установлен, минимальный размер пароля пользователя равен 7 символам.
Например, вы можете использовать смарт-карты.
Существует класс программ-шпионов, которые способны перехватывать информацию, передаваемую по сети. Например, к ним относятся безобидные на первый взгляд сетевые мониторы (сниферы).
Возможным последствием является полный перехват всего сетевого траффика, расшифровав который, можно (теоретически) получить какую-то информацию о работе вашей системы. Вероятность возникновения такой угрозы минимальна. Трудозатраты на организацию защиты очень высоки. Необходимо адекватно оценить риски. Как правило, организация защиты такого класса характерна для крупных компаний.
При создании новой базы вы указываете параметр «безопасное соединение» (защищенное соединение). Существует возможность выбрать одно из трех значений:
Настройка действует для всех подключений к кластеру серверов, в том числе с консоли «Сервера 1С Предприятий».
Уровень «Выключено» является самым низким, уровень «Постоянно» – самым высоким. При этом используется безопасное соединение по протоколу TCP/IP с шифрованием алгоритмами RSA и Triple DES.
Использование уровня безопасности «Постоянно» позволяет полностью защитить весь поток данных (как пароли, так и непосредственно данные) между клиентом и кластером серверов. При этом весь обмен происходит с использованием алгоритмов шифрования RSA и Triple DES. Следует учитывать, что при этом возможно снижение производительности системы.
Уровень безопасности задается при создании информационной базы. Эта информация сохраняется как на клиенте (в списке информационных баз), так и в кластере серверов (в реестре кластера). После создания информационной базы, ее параметры, сохраненные в реестре кластера, изменить уже нельзя. Однако можно изменить уровень безопасности, указанный для этой информационной базы на клиенте. Выполнить настройку уровня безопасности подключения через параметр запуска /SLev, который определяет уровень защищенности соединения клиента с сервером 1С:Предприятия
Возможные значения:
/SLev0 – незащищенное соединение.
/SLev1 – защищенное соединение только в процессе выполнения аутентификации.
/SLev2 – защищенное соединение в течение всего сеанса.
Отсутствие параметра эквивалентно /SLev0.
Необходимость в таких настройках может возникнуть, если например, пользователь из дома захотел подключиться к информационной базе по модему или по выделенной линии. Так как информация будет проходить по внешним каналам связи, то желательно установить более высокий уровень безопасности.
После установки соединения клиент генерирует приватный и публичный ключи для шифрования RSA, и передает в кластер серверов публичный ключ и уровень безопасности, который указан для данной информационной базы на клиенте. Это желаемый уровень безопасности.
Кластер серверов выбирает максимальный уровень безопасности из переданного клиентом и указанного для этой информационной базы в реестре кластера. Это фактический уровень безопасности. Кроме этого кластер серверов генерирует сеансовый ключ для шифрования Triple DES и вместе с фактическим уровнем безопасности передает его клиенту, предварительно зашифровав эти данные с помощью публичного ключа клиента.
Дальнейший обмен данными выполняется в соответствии с фактическим уровнем безопасности, при этом как клиент, так и сервер шифруют передаваемые данные с использованием сеансового ключа по алгоритму Triple DES, у которого сам процесс шифрования более скоростной, чем RSA.
Этот уровень безопасности является компромиссом между безопасностью и производительностью. Использование уровня безопасности "Установка соединения" позволяет частично защитить поток данных (только пароли) между клиентом и кластером серверов. Алгоритмы шифрования здесь используются до момента установки соединения клиентского приложения с рабочим процессом и выполнения аутентификации пользователя, затем идет открытый процесс обмена данными с кластером серверов.
При этом уровне безопасности данные информационной базы передаются в открытом виде. Поскольку эти данные составляют основную массу всего потока данных, производительность системы практически не снижается.
Частичную защищенность данных информационной базы обеспечивает то, что ключевая информация (пароли) передается только в зашифрованном виде. В результате, если открытый поток данных будет перехвачен, то из него можно будет получить лишь незначительную часть данных информационной базы. Т.к. пароли будут недоступны, то злоумышленник не сможет аутентифицироваться в информационной базе и получить доступ ко всем данным или выполнить произвольные действия с информационной базой.
Уровень безопасности Выключено является самым низким и самым производительным. Практически все данные передаются без использования шифрования.
После установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA. Дальнейший обмен выполняется нешифрованными данными.
Безопасность данных, передаваемых между консолью кластера серверов и кластером серверов обеспечивается, также, за счет возможности шифрования передаваемых данных. При этом используются те же самые три уровня безопасности: Выключено, Установка соединения и Постоянно.
Консоль кластера серверов взаимодействует с агентом сервера (процесс ragent.exe). Желаемый уровень безопасности задается при старте агента сервера. Фактический уровень безопасности будет выбран агентом сервера как максимальный из указанного при старте и уровней безопасности всех кластеров, расположенных на данном центральном сервере. Уровень безопасности кластера задается при его создании (программном или интерактивном).
Специалистам по безопасности также может потребоваться знание алгоритмов шифрования, применяемые в 1С:Предприятие 8.1
При уровне безопасности «Постоянно» выполняется шифрование по следующей схеме
В общем виде протокол взаимодействия клиента и кластера серверов представлен на следующем рисунке:
Протокол взаимодействия одинаков как для менеджера кластера (rmngr.exe), так и для рабочего процесса (rphost.exe): после установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA, дальнейший обмен данными выполняется с использованием шифрования по алгоритму Triple DES.
Для уровня «Установка соединения» в общем виде протокол взаимодействия клиента и кластера серверов представлен на следующем рисунке:
После установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA, затем обмен данными выполняется с использованием шифрования по алгоритму Triple DES до окончания процедуры аутентификации. Дальнейший обмен выполняется нешифрованными данными.
Для уровня безопасности «Выключено» в общем виде протокол взаимодействия клиента и кластера серверов представлен на следующем рисунке:
После установки соединения клиент отправляет Открытый ключ RSA и уровень безопасности в кластер серверов. Менеджер кластера отправляет ему сообщение о новом уровне безопасности, зашифрованное Открытым ключом RSA. Дальнейший обмен выполняется нешифрованными данными. Аналогичным образом осуществляется обмен данными клиентского приложения с рабочим процессом кластера.
Пароли администраторов кластера серверов и пароли доступа к информационным базам хранятся на кластере серверов в зашифрованном виде. Для этого используется шифрование алгоритмами SHA1 и AES128.
SHA1 - это алгоритм контрольного суммирования. С его помощью хранятся пароли, которые проверяет система 1С:Предприятие (например, пароль администратора кластера, администратора центрального сервера). При этом исходный текст хранимых паролей восстановить нельзя, а можно только проверить совпадение контрольной суммы введенного пароля с хранимой контрольной суммой.
AES128 – это алгоритм шифрования. С его помощью хранятся пароли, для которых должен восстанавливаться исходный текст (например, пароли доступа к СУБД).
Microsoft SQL Server позволяет шифровать передаваемый по сети трафик. Для этого используется Secure Sockets Layer (SSL) при передаче данных между серверома кластера и MS SQL Server. Если рабочий сервер кластера и MS SQL Server на одном компьютере, то используется протокол обмена Shared Memory (и шифрование не используется).
Для шифрования всех передаваемых данных для MS SQL Server 2000 необходимо воспользоваться утилитой "Server Network Utility". На закладке "General" установите флажок "Force protocol encryption".
Метод шифрования выбирается в зависимости от используемого клиентским приложением (т.е. сервером приложения 1С). Для использования SSL необходимо правильно настроить службу выдачи сертификатов в сети.
Более подробно о шифровании сертификатами можно прочитать на сайте Microsoft.
Для того чтобы установить необходимость шифрования всех передаваемых данных для определённого сервера приложений необходимо воспользоваться утилитой "Client Network Utility" (обычно расположенной в "C:\WINNT\system32\cliconfg.exe"). Как и в предыдущем случае, на закладке "General" установите флажок "Force protocol encryption".
Помните, что использование шифрования может достаточно сильно сказаться на производительности системы, особенно при использовании запросов, возвращающих большие объёмы информации.
Допольнительными мерами защиты передачи данных между сервером приложений и MS SQL Server при использовании протокола TCP/IP можно считать изменение настроек, заданных по умолчанию. Это использование нового порта взамен используемого стандартно порта 1433. При этом это изменение должно также быть выполнено для компьютера с сервером приложений, т.е. должен использоваться один и тот же порт.
В настройках протокола TCP/IP на сервере MS SQL «поднять» флажок "Hide server", запрещающий ответы на широковещательные запросы данному экземпляру службы MS SQL Server.
На рисунке показано «скрытие» SQL Server.
MS SQL Server 2005 поддерживает сетевые соединения как с клиентом SQL Server 2000, так и «собственных» клиентов Native Client.
Общая настройка сетевой конфигурации сервера здесь.
Еще один момент, который следует знать, но он не считается сам по себе уязвимостью.
Рекомендуемый режим подключения к SQL Server для процессов 1С:Предприятия 8.1 – смешанный режим «mixed» авторизации (SQL Server и Windows). Для подключения необходимо использовать учетные записи SQL Server. Тем не менее, существуюет возможность использовать режим авторизации Windows.
На рисунке показан режим авторизации Windows для SQL Server 2005.
В этом случаи необходимо определить, какая учетная запись Windows используется процессом rphost.exe.
На рисунке показаны в дистепечере процессы rphost.exe и учетная запись RPHOSTUSER, используемая для этих процессов.
И указать записи права для доступа к SQL Server и возможности создавать базы.
На рисунке создан пользователь SQLSRV\RPHOSTUSER (он же пользователю процессов rphost.exe) и указаны разрешения для работы с базами данных на SQL Server 2005.
Теперь при подключении информационных баз имя пользователя базы данных и пароль можно оставлять пустыми.
На рисунке показан пример создания новой информационной базы.
Пользователь базы данных и пароль пользователя не указаны. Будет использована учетная запись рабочего процесса кластера.
Отсюда следует вывод: для всех информационных баз 1С:Предприятия 8.1 пользователь будет один!
Такой подход снижает общую безопасность системы, т.к. получив этот единственный пароль, злоумышленник получит доступ ко всем базам сразу.