v8: Безопасность 1С:Предприятия 8.0 (клиент-сервер)

Книга знаний

1С:Предприятие / v8 / Администрирование / Безопасность

v8: Безопасность 1С:Предприятия 8.0 (клиент-сервер)

Автор статьи: Волшебник | Редакторы:
Последняя редакция №2 от 19.04.06 | История
URL: http://kb.mista.ru/article.php?id=166

Введение

1С:Предприятие является самой распространённой учетной системой в России системой, но, несмотря на это, до версии 8.0 её разработчики уделяли крайне мало внимания вопросам безопасности. В основном, конечно, это диктовалось ценовой нишей продукта и ориентацией на малые предприятия, где отсутствуют квалифицированные ИТ-специалисты, и возможная стоимость развёртывания и поддержки защищённой системы была бы непозволительно дорога для предприятия. С выпуском версии 8.0 акценты должны были поменяться: стоимость решений значительно возросла, система стала значительно более масштабируемой и гибкой – требования значительно изменились. Стала ли система достаточно надёжной и защищённой – это вопрос очень индивидуальный. Основная информационная система современного предприятия должна удовлетворять как минимум, следующим требованиям безопасности:

Достаточно низкая вероятность сбоя системы по внутренним причинам.
Надёжная авторизация пользователей и защита данных от некорректных действий.
Эффективная система назначения прав пользователей.
Оперативная система резервного копирования и восстановления в случае сбоя.

Удовлетворяют ли решения на базе 1С:Предприятия 8.0 таким требованиям? Однозначного ответа не существует. Несмотря на значительные изменения в системе управления доступом осталось достаточно много нерешённых вопросов. В зависимости от того, как разработана и настроена система, все эти требования могут не выполняться или выполняться в достаточной для данного внедрение мере, однако стоит обратить внимание (и это существенное следствие "юности" платформы), что для полного выполнения перечисленных условий приходится прикладывать поистине титанические усилия.

Данная статья предназначена для разработчиков и внедренцев решений на платформе 1С:Предприятие, а также системных администраторов организаций, где используется 1С:Предприятие, и описывает некоторые моменты разработки и настройки клиент-серверного варианта системы с точки зрения организации информационной безопасности. Данная статья не может использоваться, как замена документации, а лишь указывает на некоторые моменты не нашедшие пока в ней отражения. И, конечно, ни эта статья, ни вся документация не смогут отразить всю сложность проблемы построения защищенной информационной системы, которая одновременно должна удовлетворять противоречивым требованиям безопасности, производительности, удобства и функциональности.

Классификация и терминология

Ключевым предметом рассмотрения в статье являются информационные угрозы.

Информационная угроза – возможность ситуации, когда данные несанкционированно будут прочитаны, скопированы, изменены или заблокированы.

И, исходя из данного определения, в статье информационные угрозы классифицируются следующим образом:

Несанкционированное уничтожение данных
Несанкционированное изменение данных
Несанкционированное копирование данных
Несанкционированное чтение данных
Недоступность данных

Все угрозы делятся на умышленные и неумышленные. Реализованную информационную угрозу будем называть инцидентом. Особенностями системы являются:

Уязвимости – особенности, приводящие к инцидентам

Меры защиты – особенности, блокирующие возможность инцидента

В основном рассматриваются только те случаи, вероятность которых обусловлена применением именно технологической платформы 1С:Предприятие 8.0 в клиент-серверном варианте (далее, в тех случаях, когда это не противоречит смыслу просто 1С или 1С 8.0). Определим следующие основные роли по отношению к использованию системы:

Операторы – пользователи, имеющие ограниченные прикладной ролью права на просмотр и изменение данных, но не обладающие административными функциями
Администраторы системы – пользователи, обладающие административными правами в системе, в том числе административными правами в операционных системах сервера приложений и сервера MS SQL, административными правами на MS SQL и т.п.
Администраторы ИБ – пользователи, которым делегированы отдельные административные функции в информационной базе 1С (такие как добавление пользователей, тестирование и исправление, резервное копирование, настройка прикладного решения и т.п.)
Разработчики системы – пользователи, разрабатывающие прикладное решение. В общем случае доступа к рабочей системе могут не иметь.
Лица, не имеющие непосредственного доступа к системе – пользователи, которым не делегированы права на доступ к 1С, но которые в той или иной мере могут влиять на работу системы (обычно это все пользователи того же домена Active Directory, в котором установлена система). Данная категория рассматривается в первую очередь для выявления потенциально опасных субъектов в системе.
Автоматизированные административные сценарии – программы, которым делегированы некоторые функции, предназначенные для автоматического выполнения некоторых действий (например, импорта-экспорта данных)

Здесь необходимо отметить два момента: во-первых, данная классификация очень грубая и не учитывает деления внутри каждой группы – такое деление будет создано для некоторых конкретных случаев, а во-вторых, предполагается, что остальные лица не могут оказывать влияние на работу системы, что должно быть обеспечено средствами внешними по отношению к 1С.

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

ценности защищаемой информации;
затратам на создание инцидента (в случае умышленной угрозы);
финансовым рискам в случае инцидента

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

Основные особенности механизма информационной безопасности системы

<IMG SRC="166/fig1.png">

1С:Предприятие 8.0 поставляется в двух вариантах: файловый и клиент-серверный. Файловый вариант нельзя считать обеспечивающим информационную безопасность системы по следующим причинам:

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

В клиент-серверном варианте для хранения информации используется MS SQL Server, что обеспечивает:

Более надёжное хранение данных.
Изоляцию файлов от прямого доступа.
Более совершенные механизмы транзакций и блокировок.

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

Авторизация пользователя по паролю заданному в 1С.
Авторизация пользователя по текущему пользователю Windows.
Назначение ролей пользователям системы.
Ограничение выполнения административных функций по ролям.
Назначение доступных интерфейсов по ролям.
Ограничение доступа к объектам метаданных по ролям.
Ограничение доступа к реквизитам объектов по ролям.
Ограничение доступа к объектам данных по ролям и параметрам сеанса.
Ограничение интерактивного доступа к данным и исполняемым модулям.
Некоторые ограничения выполнения кода.

В целом, используемая схема доступа к данным достаточно типична для информационных систем такого уровня. Однако применительно к данной реализации трёхзвенной клиент-серверной архитектуры есть несколько принципиальных аспектов, которые приводят к относительно большому количеству уязвимостей:

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

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

К сожалению, далеко не все внутренние механизмы системы идеально отлажены, особенно это касается неинтерактивных механизмов, отладка которых всегда с одной стороны более трудоёмка, но с другой более ответственна. Эта "болезнь" не является проблемой исключительно фирмы 1С, она встречается во многих серверных продуктах большинства вендоров. Лишь в последние годы внимание к этим проблемам значительно возросло.
Недостаточно высокая средняя квалификация разработчиков и администраторов систем, доставшаяся в наследство от предыдущей версии.

Продукты линейки 1С:Предприятие изначально были ориентированы на простоту разработки и поддержки и на работу в небольших организациях, поэтому неудивительно, что исторически сложилось так, что значительная часть "разработчиков" прикладных решений и "администраторов" систем не обладают достаточными познаниями и навыками для работы со значительно более сложным продуктом, которым является версия 8.0. Проблему усугубляет и принятая в компаниях-франчайзи практика обучать "в бою" за счет клиентов, не подходя системно к данному вопросу. Необходимо отдать должное фирме 1С в том, что за последние несколько лет эта ситуация постепенно исправляется: серьёзные компании-франчайзи стали более ответственно подходить к проблеме подбора и обучения персонала, уровень информационно-технологической поддержки со стороны фирмы 1С значительно возрос, появились программы сертификаций ориентированные на высокий уровень сервиса; но моментально ситуацию исправить нельзя, поэтому данный фактор следует учитывать при анализе безопасности системы.
Сравнительно небольшой возраст платформы.

Среди продуктов сходной направленности и целей использования это одно из самых молодых решений. Функциональность платформы более-менее устоялась менее года назад. При этом каждый релиз платформы, начиная в 8.0.10 (именно в этом релизе были реализованы почти все нынешние возможности системы) становился значительно стабильнее предыдущих. Функциональность типовых прикладных решений до сих пор растёт не по дням, а по часам, хотя из возможностей платформы используется от силы половина. Конечно, в таких условиях говорить о стабильности, можно достаточно условно, но в целом необходимо признать, что уже во многих отношениях решения на платформе 1С 8.0 значительно обгоняют по функциональности и производительности (а нередко и по стабильности) аналогичные решения на платформе 1С 7.7.

Некоторые особенности работы клиент-серверного варианта

В данном разделе описаны некоторые особенности работы клиент-серверного варианта и их влияние на безопасность. Для большего удобства при прочтении приняты следующие обозначения:

Внимание! описание уязвимости
Рекомендация: различные рекомендации по настройке, не указанные или недостаточно раскрытые в документации.

Хранение информации, управляющей доступом к системе

Хранение списка пользователей ИБ

Вся информация о списке пользователей данной ИБ и доступных им ролях в ней хранится в таблице Params в базе данных MS SQL (см. [ИТС2]). Взглянув на структуру и содержимое этой таблицы, становится очевидным, что вся информация о пользователях хранится в записи, со значением поля FileName – "users.usr".

Внимание! данная запись не защищена от изменения поля FileName, что при наличии доступа к БД MS SQL приводит к следующему эффекту:

выполняем команду: <1C>UPDATE PARAMS SET FileName = '- users.usr' WHERE FileName = 'users.usr'</1C>
т. к. система не находит список пользователей, то можно запустить конфигуратор без авторизации;

выполняем команду:

UPDATE PARAMS SET FileName = 'users.usr' WHERE FileName = '- users.usr'

открываем исходный список пользователей, который можно редактировать;

Так как мы предполагаем, что пользователи не имеют доступа к БД MS SQL, то сам по себе данный факт не может быть использован злоумышленником, однако в случае возможности выполнения кода на MS SQL это "открывает двери" на получение любого(!) доступа из 1С. Этот же механизм (с незначительными изменениями) может быть использован и файловой версии системы, что, учитывая особенности файловой версии, полностью исключает применимость её в построении безопасных систем.

Рекомендация: на текущий момент нет способа полностью защитить приложение от такого изменения, кроме использования триггеров на уровне MS SQL Server, что, с другой стороны, может стать причиной проблем при обновлении версии платформы или изменении списка пользователей. Для отслеживания таких изменений можно использовать журнал регистраций 1С (обращая внимание на "подозрительные" входы в систему в режиме конфигуратора без указания пользователя) или держать постоянно запущенным SQL Profiler (что крайне негативно скажется на производительности системы) или настраивать механизм Alerts (скорее всего, совместно с использованием триггеров)

Хранение информации о списке ИБ на сервере

Для каждого сервера приложений 1С хранится информация о списке подключенных к нему БД MS SQL. Каждая информационная база для работы использует свою строку соединения сервера приложений и сервера MS SQL. Информация о зарегистрированных на сервере приложений информационных базах вместе со строками подключения хранится в файле srvrib.lst, который расположен на сервере в каталоге <Общие данные приложений>/1C/1Cv8 (например, C:/Documents and Settings/All Users/Application Data/1C/1Cv8/srvrib.lst). Для каждой ИБ хранится полная строка подключения, включающая пароль пользователя MS SQL при использовании смешанной модели авторизации MS SQL. Именно наличие этого файла позволяет опасаться несанкционированного доступа к БД MS SQL, причем если вопреки рекомендациям для доступа хотя бы к одной БД используется привилегированный пользователь (например "sa"), то кроме угрозы одной ИБ возникает угроза всей системе, использующей MS SQL.

Интересно отметить, что использование смешанной авторизации и авторизации Windows на сервере MS SQL приводит при получении доступа к данному файлу к разным типам проблем. Так ключевыми негативными свойствами авторизации Windows будут:

Работа всех ИБ на сервере приложений и на сервере MS SQL под одним набором прав (скорее всего избыточным)
Из процесса сервера приложений 1С (или в общем случае от пользователя USER1CV8SERVER или его аналога) без указания пароля можно легко подключаться к любой ИБ без указания пароля

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

Рекомендация: Файл srvrib.lst должен быть доступен только процессу сервера. Обязательно настроить аудит на изменение данного файла.

К сожалению, по умолчанию данный файл почти никак не защищён от прочтения, что необходимо учитывать при развёртывании системы. Идеальным вариантом было бы, если бы сервер приложений во время работы предотвращал чтение и запись данного файла (в том числе чтение и запись исполняемыми на этом сервере подключениями пользователей).

Отсутствие авторизации при создании ИБ на сервере

Внимание! Ошибка отсутствия авторизации была исправлена в релизе 8.0.14 платформы 1С:Предприятие. В этом релизе появилось понятие "Администратор сервера 1С:Предприятие", но пока на сервере указан список администраторов, система действует так, как описано ниже, поэтому не забывайте об этой возможной особенности.

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

Должна быть установлена система в следующем варианте

MS SQL Server 2000 (например, сетевое имя SRV1)
Сервер 1С:Предприятие 8.0 (сетевое имя SRV2)
Клиентская часть 1С:Предприятие 8.0 (сетевое имя WS)

Предполагается, что пользователь (далее USER), работающий на WS имеет хотя бы минимальный доступ к одной из ИБ, зарегистрированных на SRV2, но не имеет привилегированного доступа к SRV1 и SRV2. В целом совмещение функций перечисленными компьютерами не влияет на ситуацию. Настройка системы выполнена с учетом рекомендаций в документации и на дисках ИТС. Ситуация отражена на рис. 2.

<IMG SRC="166/fig2.png">

USER (злоумышленно) обеспечивает существование фиктивного временного сервера MS SQL на одной из рабочих станций в сети. Здесь есть 2 основные возможности:
- USER является локальным администратором WS и устанавливает MS SQL Server
- USER обеспечивает доступ к серверу на дополнительном ПК, например на ноутбуке или вне локальной сети.
Фиктивный сервер MS SQL назовём EXTERN.
USER обладает достаточными полномочиями для создания БД SQL на EXTERN.
Внимание! Пользователь создаёт пустую ИБ 1С, использующую в качестве хранилища данных EXTERN, и регистрирует её на сервере приложений 1С SRV2.
<IMG SRC="166/fig3.png">
Пользователь создаёт в полученной ИБ конфигурацию особого вида, содержащую серверные модули. Данные модули будут исполняться на SRV2 в контексте пользователя USER1CV8SERVER или аналогичного.
При выполнении на сервере доступны некоторые потенциально небезопасные способы доступа к файловой системе сервера приложений и некоторым COM-объектам. Например, объекты ЧтениеТекста, COMОбъект, метод Выполнить глобального контекста и т.п. выполняются на сервере SRV2 с правами пользователя USER1CV8SERVER или аналогичного (эта возможность подробнее рассматривается ниже)
Т.к. выполнение на сервере происходит от имени пользователя USER1CV8SERVER или аналогичного, то возможно чтение файла srvrib.lst, в котором в явном виде указываются пароли и имена пользователей SQL Server, которыми пользуется SRV2 при доступе к SRV1. Запретить процессу сервера читать данный файл невозможно по принципу действия системы.
С учетом того, что большую часть действий можно произвести заранее, реализовав их в виде программы на встроенном языке 1С, специалистом может быть составлена очень простая инструкция для по использованию вредоносной программы. Размер файла конфигурации может в случае специализированной конфигурации быть очень небольшим.

Рекомендация: Необходимо:

настроить безопасность COM+ на сервере приложений таким образом, чтобы только пользователи 1С имели право на подключение к процессу сервера приложений (подробнее [ИТС12]);
файл srvrib.lst должен быть доступен только на чтение пользователю USER1CV8SERVER (для добавления новой ИБ на сервер временно разрешать запись);
для подключения к MS SQL использовать только протокол TCP/IP, в этом случае можно:
ограничивать подключения при помощи брандмауэра;
настроить использование нестандартного порта TCP, что усложнит подключение "посторонних" ИБ 1С;
использовать шифрование передаваемых данных между сервером приложений и сервером SQL;
настроить брандмауэр сервера так, чтобы использование посторонних серверов MS SQL было невозможным;
использовать внутрисетевые средства безопасности для исключения возможности появления неавторизованного компьютера в локальной сети (IPSec, групповые политики безопасности, брандмауэры и т.п.);
ни в коем случае не предоставлять пользователю USER1CV8SERVER административные права на сервере приложений.

Использование кода, выполняемого на сервере

При использовании клиент-серверного варианта 1С разработчик может распределять выполнение кода между клиентском и сервером приложений. Для того чтобы код (процедура или функция) выполнялся только на сервере необходимо расположить её в общем модуле, для которого установлено свойство "Сервер" и, в случае, когда исполнение модуля разрешено не только на сервере, расположить код в секцию ограниченную "#Если Сервер":

#Если Сервер Тогда

Функция НаСервере(Парам1, Парам2 = 0) Экспорт // Эта функция, несмотря на её простоту, выполняется на сервере
    Парам1 = Парам1 + 12;
    Возврат Парам1;
КонецФункции
#КонецЕсли

При использовании кода, выполняемого на сервере необходимо учитывать, что:

код выполняется с правами USER1CV8SERVER на сервере приложений (доступны COM-объекты и файлы сервера);
все пользовательские сессии выполняются одним экземпляром службы, поэтому, например, переполнение стека на сервере вызовет отключение всех активных пользователей;
отладка серверных модулей затруднена (например, в отладчике нельзя поставить точку останова), но должна быть осуществлена;
передача управления от клиента серверу приложений и обратно может потребовать значительных ресурсов при больших объёмах передаваемых параметров;
использование интерактивных средств (форм, табличных документов, диалоговых окон), внешних отчетов и обработок в коде на сервере приложений невозможна;
использование глобальных переменных (переменные модуля приложения, объявленные с указанием "Экспорт") недопустимо;

Подробнее см. [ИТС15] и другие статьи ИТС.

К серверу приложений должны предъявляться особые требования по надёжности. В правильно выстроенной клиент-серверной системе должны быть выполнены следующие условия:

никакие действия клиентского приложения не должны прерывать работу сервера (кроме административных случаев);
на сервере не может выполняться программный код, полученный от клиента;
ресурсы должны "справедливо" распределяться по подключениям клиентов, обеспечивая доступность сервера вне зависимости от текущей загруженности;
при отсутствии блокировок данных, подключения клиентов не должны влиять на работу друг друга;
на сервере нет пользовательского интерфейса, но должны быть развиты средства мониторинга и протоколирования;

В целом система 1С выстроена так, чтобы приблизиться к данным требованиям (например, заставить внешние обработки выполняться на сервере невозможно), но несколько неприятных особенностей всё же существует, поэтому:

Рекомендация: При разработке серверной части выполнения рекомендуется придерживаться принципа минимальности интерфейса. Т.е. количество входов в серверные модули с клиентского приложения должно быть очень ограничено, а параметры жёстко регламентированы.
Рекомендация: При получении параметров процедур и функций на сервере необходимо осуществлять валидацию параметров (проверку соответствия параметров ожидаемому типу и диапазону значений). Этого не делается в типовых решениях, но в собственных разработках внедрить обязательность валидации очень желательно.
Рекомендация: При генерации текста запросов (а тем более параметра команды Выполнить) на серверной стороне не используйте строки, полученные от клиентского приложения.

Общей рекомендацией будет ознакомиться с принципами построения безопасных веб-приложений для баз данных и работать по схожим принципам. Сходство, действительно немалое: во-первых, как и веб-приложение, сервер приложений это промежуточный слой между БД и интерфейсом пользователя (основное отличие в том, что веб-сервер формирует интерфейс пользователя); во-вторых, с точки зрения безопасности нельзя доверять полученным от клиента данным, т.к. возможен запуск внешних отчетов и обработок.

Передача параметров

Передача параметров функции (процедуре), выполняемой на сервере достаточно тонкий вопрос. Это в первую очередь связано с необходимостью передачи их между процессом сервера приложений и клиента. При переходе управления с клиентской части на серверную все передаваемые параметры сериализуются, передаются на сервер, где "распаковываются" и используются. При переходе с серверной части на клиентскую – обратный процесс. Здесь необходимо отметить, что данная схема корректно обрабатывает передачу параметров по ссылке и по значению. При передаче параметров действуют следующие отграничения:

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

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

УровеньВложенности = 1250;
М = Новый Массив;
ПередаваемыйПараметр = М;
Для Сч = 1 По УровеньВложенности Цикл
    МВнутр = Новый Массив;
    М.Добавить(МВнутр);
    М = МВнутр;
КонецЦикла;
СервернаяФункция(ПередаваемыйПараметр);

Приводит к аварийной остановке сервера с отключением всех пользователей, причём это происходит до передачи управления в код на встроенном языке.

Использование небезопасных функций на стороне сервера.

Не все средства встроенного языка можно использовать в коде, выполняемом на сервере приложений, но даже среди доступного инструментария есть множество "проблемных" конструкций, которые можно условно классифицировать следующим образом:

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

Основные известные мне проблемные конструкции (с примерами) перечислены ниже:

Процедура Выполнить(<Строка>)

Выполнение кода. Позволяет выполнить фрагмент кода, который передается ему в качестве строкового значения. При использовании на сервере необходимо проследить, чтобы в качестве параметра не использовались данные, полученные с клиента. Например, недопустимо следующее использование:
#Если Сервер Тогда

Процедура НаСервере(Парам1) Экспорт
    Выполнить(Парам1);
КонецПроцедуры
#КонецЕсли

Тип "COMОбъект" (конструктор Новый COMОбъект(<Имя>, <Имя сервера>))

Нарушение прав и выполнение кода. Создает COM-объект внешнего приложения под правами USER1CV8SERVER на сервере приложений (или другом указанном компьютере). При использовании на сервере, проследить, что параметры не передаются с клиентского приложения. Однако на стороне сервера эффективно использовать эту возможность при импорте/экспорте, отправке данных по сети Интернет, реализации нестандартных функций и т.п.

Функция ПолучитьCOMОбъект(<Имя файла>, <Имя класса COM>)

Нарушение прав и выполнение кода. Аналогично предыдущему, только получение COM-объекта, соответствующего файлу.

Процедуры и функции ИмяКомпьютера(), КаталогВременныхФайлов(), КаталогПрограммы(), ПользователиWindows()

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

Процедуры и функции работы с файлами (КопироватьФайл, НайтиФайлы, ОбъединитьФайлы и многие другие), а также типы "Файл".

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

Обязательно проверяйте права пользователя 1С перед использованием данных функций. Для проверки прав пользователя можно использовать следующую конструкцию в модуле сервера:
#Если Сервер Тогда

Процедура ВыполнитьРаботуСфайлом() Экспорт
    РольАдминистратор = Метаданные.Роли.Администратор;
    Пользователь = ПараметрыСеанса.ТекущийПользователь;
    Если Пользователь.Роли.Содержит(РольАдминистратор) Тогда
        //Здесь выполняется код работы с файлами
    КонецЕсли;
#КонецЕсли
Обязательно проверяйте параметры, если применяете эти процедуры и функции, в противном случае остаётся риск нанести случайно или осознанно непоправимый вред серверу приложений 1С, например, при выполнении на сервере кода:
Путь = "C:\Documents and Settings\All Users\Application Data\1C\1Cv8\";
ПереместитьФайл(Путь + "srvrib.lst", Путь + "ВотКудаДелсяФайл");
После выполнения такого кода на сервере, если у пользователя USER1CV8SERVER есть права на его изменение, о чём было написано выше, и после перезапуска процесса сервера (по умолчанию через 3 минуты после выхода всех пользователей), возникнет БОЛЬШОЙ вопрос по запуску сервера. А ведь возможно и полное удаление файлов...

Типы "XBase", "ДвоичныеДанные", "ЧтениеXML", "ЗаписьXML", "ПреобразованиеXSL", "ЗаписьZipФайла", "ЧтениеZipФайла", "ЧтениеТекста", "ЗаписьТекста"

Нарушение прав. Позволяют, выполнив их на сервере, получить доступ к локальным (и расположенным в сети) файлам определённых типов и выполнять их чтение/запись под правами пользователя USER1CV8SERVER. Если используются осознанно, то возможна эффективная реализация таких задач, как импорт/экспорт данных на сервере, протоколирование работы некоторых функций, решение административных задач. В целом рекомендации совпадают с предыдущим пунктом, но следует учитывать возможности передачи данных этих файлов (но не объектов всех этих типов) между клиентской и серверной частью.

Тип "СистемнаяИнформация"

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

Типы "ИнтернетСоединение", "ИнтернетПочта", "ИнтернетПрокси", "HTTPСоединение", "FTPСоединение"

Нарушение прав. При использовании на сервере осуществляет соединение с удалённым ПК с сервера приложений под правами USER1CV8SERVER. Рекомендации:

Контроль параметров при вызове методов.
Контроль прав пользователя 1С.
Жёсткие ограничения прав пользователя USER1CV8SERVER на доступ к сети.
Правильная настройка брандмауэра на сервере приложений 1С.

При правильном использовании удобно организовывать, например, рассылку электронной почты с сервера приложений.

Типы "МенеджерПользователейИнформационнойБазы", "ПользовательИнформационнойБазы"

Нарушение прав. При некорректном использовании (в привилегированном модуле) возможно добавление пользователей или смена параметров авторизации существующих пользователей.

Функция Формат

Сбой сервера. Да! Эта, вроде бы безобидная функция, если не контролировать её параметры и выполнить на сервере, способна вызвать аварийное завершение приложения сервера. Ошибка проявляется при форматировании чисел и использовании режима вывода ведущих нулей и большого количества знаков, например
Формат(1, "ЧЦ=999; ЧВН=");
Надеюсь, эта ошибка будет исправлена в ближайших релизах платформы, а пока во всех вызовах этой функции, которые могут исполняться на сервере, проконтролируйте параметры вызова.

Процедуры и функции сохранения значений (ЗначениеВСтрокуВнутр, ЗначениеВФайл)

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

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

Одной из проблем, с которыми можно столкнуться при использовании сервера – большая "ответственность" серверных функций (возможность аварийного завершения всего серверного приложения из-за ошибки в одном соединении и использование одного "пространства ресурсов" для всех соединений). Отсюда необходимость контролировать основные параметры времени выполнения:

Для функций встроенного языка проверяйте параметры их запуска (яркий пример – функция "Формат")

При использовании циклов убедитесь, что условие выхода из цикла срабатывает. Если цикл потенциально бесконечный ограничьте искусственно количество итераций:

МаксимальноеЗначениеСчетчикаИтераций = 1000000;
СчетчикИтераций = 1;
Пока 
    ФункцияКотораяМожетНеВернутьЛожногоЗначения() 
    И (СчетчикИтераций<МаксимальноеЗначениеСчетчикаИтераций) Цикл
    
    //.... Тело цикла
    СчетчикИтераций = СчетчикИтераций + 1;
КонецЦикла;
Если СчетчикИтераций>МаксимальноеЗначениеСчетчикаИтераций Тогда
    //.... обработать событие чрезмерно долгого выполнения цикла
КонецЕсли;

При использовании рекурсии ограничивайте максимальный уровень вложенности.
При формировании и выполнении запросов старайтесь предотвратить очень долгие выборки и выборки большого количества информации (например, при использовании условия "В ИЕРАРХИИ" не используйте пустое значение)
При проектировании информационной базы обеспечьте достаточно большой запас разрядности для чисел (иначе сложение и умножение становится некоммутативным и неассоциативным, что затрудняет отладку)
В исполняемых запросах проверьте логику работы на наличие значений NULL и корректную работу условий и выражений запроса с использованием NULL.
При использовании коллекций контролируйте возможность их передачи между сервером приложений и клиентской частью.

Использование терминального доступа к клиентской части для ограничения доступа

Нередко можно встретить рекомендации использовать терминальный доступ для ограничения доступа к данным и поднятия производительности за счет выполнения кода клиентской части на сервере терминалов. Да, при правильной настройке использование терминального доступа действительно способно повысить общий уровень безопасности системы, но, к сожалению, нередко можно встретиться с тем, что при практическом использовании безопасность системы только снижается. Давайте попытаемся разобраться, с чем это связано. Сейчас есть два распространённых средства организации терминального доступа, это Microsoft Terminal Services (протокол RDP) и Citrix Metaframe Server (протокол ICA). В целом средства Citrix предоставляют гораздо более гибкие возможности администрирования доступа, но и цена этих решений значительно выше. Мы рассмотрим только основные, общие для обоих протоколов особенности, которые могут понизить общий уровень безопасности. Основных опасностей при использовании терминального доступа всего три:

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

В любом случае терминальные службы позволяют:

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

Можно сформулировать следующие рекомендации по использованию сервера терминалов.

Необходимо ограничивать количество возможных соединений с сервером терминалов одного пользователя

В силу "прожорливости" клиентского приложения 1С относительно ресурсов обязательно необходимо ограничивать максимальное количества одновременных подключений одного пользователя (оператора) к серверу терминалов. Активно используемое подключение может использовать до 300 МБ памяти только с одним экземпляром приложения. Кроме памяти активно используется процессорное время, что также не способствует стабильности работы пользователей этого сервера. Одновременно с предотвращением чрезмерного использования ресурсов сервера, такое ограничение может предотвратить использование чужой учетной записи. Реализуется стандартными настройками терминального сервера.

Нельзя допускать запуска более одного-двух клиентских приложений 1С одновременно в одном подключении

Диктуется теми же причинами, что и в предыдущем абзаце, но технически сложнее реализуется. Проблема в том, что предотвратить повторный запуск 1С средствами сервера терминалов практически невозможно (ниже будет объяснено почему), поэтому приходится реализовывать эту возможность на уровне прикладного решения (что тоже не является хорошим решением, т.к. могут оставаться некоторое время "висящие" сессии при некорректном завершении приложения и возникает необходимость доработки прикладного решения в модуле приложения и некоторых справочников, что осложнит использование обновлений от 1С). Очень желательно оставить пользователю возможность запускать 2 приложения для возможности запускать некоторые действия (например, формирование отчетов) в фоновом режиме – клиентское приложение, к сожалению, фактически однопоточное.

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

Конечно, доступ на терминальный сервер лучше оставить только пользователям, не использующим такие задачи как анализ данных (data mining), географические схемы, импорт/экспорт, и прочие задачи, серьёзно нагружающие клиентскую часть приложения. Если всё же есть необходимость разрешить такие задачи, то необходимо: уведомлять пользователя о том, что данные задачи могут повлиять на быстродействие других пользователей, зафиксировать в журнале регистрации событие начала и окончания такого процесса, разрешать выполнение только в регламентированное время и т.п.

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

Во-первых, если не ограничить возможность записи в общие каталоги (такие как каталог, куда установлена 1С) то сохраняется возможность злоумышленнику изменить поведение программы для всех пользователей. Во-вторых, данные одного пользователя (временные файлы, файлы сохранения настроек отчетов и т.п.) ни в коем случае не должны быть доступны другому пользователю терминального сервера – в целом при обычной настройке это правило выполняется. В-третьих, у злоумышленника остаётся возможность "замусорить" раздел так, что на жёстком диске не останется места. Я знаю, мне возразят, что в ОС Windows, начиная с Windows 2000, есть механизм квот, но это достаточно затратный механизм, да и реального его использования я практически не встречал.

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

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

Необходимо запретить подключение (mapping) дисковых устройств, принтеров и буфера обмена клиентского рабочего места.

В RDP и ICA есть возможность организовать автоматическое подключение дисков, принтеров, буфера обмена com-портов терминального компьютера к серверу. Если эта возможность есть, то практически невозможно запретить запуск постороннего кода на сервере терминалов и сохранение данных из 1С на клиенте терминального доступа. Разрешайте эти возможности только для лиц имеющих административные права.

Сетевой файловый доступ с сервера терминалов должен быть ограничен.

Если этого не делать, то пользователь сможет опять же запустить нежелательный код или сохранить данные. Так как штатный журнал регистрации не отслеживает файловые события (кстати, хорошая идея для реализации разработчиками платформы), а системный аудит во всей сети настроить практически невозможно (не хватит ресурсов на его обслуживание), то лучше, чтобы пользователь мог отправлять данные либо на печать, либо по электронной почте. Особенное внимание обратите на то, чтобы терминальный сервер не работал напрямую со съёмными носителями пользователей.

<H4 class="">Ни в коем случае при создании защищённой системы нельзя оставлять сервер приложений на терминальном сервере.
Если сервер приложений запускается на одном компьютере с клиентскими приложениями, то существует достаточно много возможностей по нарушению его нормальной работы. Если по каким-то причинам разделить функции терминального сервера и сервера приложений невозможно, то обратите особое внимание на доступ пользователей к файлам, использующимся сервером приложений.

Необходимо исключить возможность запуска всех приложений кроме 1С:Предприятия на терминальном сервере.

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

При входе в терминальный режим не запускается стандартное меню "Пуск" Windows или оно в значительной мере ограничено политикой безопасности и настройками меню "Программы". Как предельный вариант ограничений – использовать запуск 1С вместо запуска Explorer (возможно, сразу с ключами командной строки, определяющими ИБ). При использовании ICA лучше использовать seamles mode.
Пользователь не может запустить окно "Запуск программы" (рис 5.). Это можно сделать из меню "Пуск" или нажав Win+R или из диспетчера задач. Также необходимо проверить невозможность запустить приложение "CMD" путём запуска ярлыка.

<IMG SRC="166/fig4.png">
Диспетчер задач недоступен (ни по Ctrl+Alt+Del, ни по Ctrl+Shift+Escape никаким другим образом). При использовании RDP не в полноэкранном режиме или при использовании ICA вместо стандартных комбинаций используются другие.
Нельзя запустить сценарии VBScript и файлы ".bat" и ".cmd".
При появлении окна выпора файла в контекстном меню файлов нельзя выбрать ничего кроме его открытия в 1С (пункт "Выбрать").
Нельзя открыть файлы MS Office и других программ с возможностью доступа к программированию (в MS Office переход к редактированию программы – Alt+F11).
Пользователь не может самостоятельно зарегистрировать COM-объект.
Элементы управления ActiveХ в IE запрещены.

Сложность реализации данного требования приводит зачастую к возможности запустить на сервере терминалов "лишний" сеанс 1С (даже если остальные приложения ограничены, то принципиально запретить запуск 1С средствами Windows нельзя).

Учитывайте ограничения штатного журнала регистрации (все пользователи используют программу с одного компьютера)

Очевидно, что раз пользователи открывают 1С в терминальном режиме, то и в журнале регистрации записываться будет именно сервер терминалов. С какого компьютера подключился пользователь, журнал регистрации не сообщает.

Сервер терминалов – защита или уязвимость?

Итак, после рассмотрения основных особенностей севера терминалов, можно сказать, что потенциально север терминалов может помочь в автоматизации для распределения вычислительной нагрузки, но построить безопасную систему достаточно сложно. Одним из случаев, когда применение сервера терминалов наиболее эффективно, является запуск 1С без Windows Explorer в полноэкранном режиме для пользователей c ограниченным функционалом и специализированным интерфейсом.

Работа клиентской части

Использование Internet Explorer (IE)

Одним из условий нормальной работы клиентской части 1С является использование компонент Internet Explorer. С этими компонентами надо быть очень осторожными.

Внимание! Во-первых, если к IE "прицепился" модуль spyware или adware, то он загрузится и в случае просмотра любых HTML файлов в 1С. Пока я не встречал сознательного использования данной возможности, но встречал в одной из организаций загруженный "шпионский" модуль одной из порнографических сетей при запущенной 1С (антивирусная программа не обновлялась, симптомы по которым обнаружено: при настройке брандмауэра было видно, что 1С пытается по порту 80 подключиться к порносайту). Собственно, это еще один аргумент в пользу того, что защита должна быть комплексной
Внимание! Во-вторых, система 1С допускает использование в отображаемых HTML-документах flash-роликов, ActiveX объектов, VBScript, отправку данных в Интернет, даже открытие PDF-файлов(!), правда в последнем случае спрашивает "открыть или сохранить"... В общем, всё, что душе угодно. Пример не вполне разумного использования встроенной возможности просмотра и редактирования HTML:

Создайте новый HTML-документ (Файл -> Новый -> HTML документ).
Перейдите на закладку "Текст" пустого документа.
Удалите текст (полностью).
Перейдите на закладку "Просмотр" этого документа
При помощи drag-n-drop переместите из открытого проводника в окно документа файл с расширением SWF (это файлы flash-роликов), например из кеша браузера, хотя можно и с FLASH-игрушкой для забавы.
Какая прелесть! На 1С можно запустить игрушку!

С точки зрения безопасности системы это совершенно неправильно. Пока специальных атак на 1С через эту уязвимость я не встречал, но, скорее всего это окажется вопросом времени и ценности Вашей информации.

Есть еще некоторые незначительные моменты, которые проявляются при работе с полем HTML-документа, но основными являются два перечисленных. Хотя, если подходить к этим особенностям творчески, можно организовать поистине потрясающие интерфейсные возможности работы с 1С.

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

Использование внешних отчетов и обработок.

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

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

Использование стандартных механизмов типовых решений и платформы (обмен данными)

Некоторые из стандартных механизмов потенциально опасны, причем достаточно неожиданным образом.

Печать списков

Любой список (например, справочник или регистр сведений) в системе, можно распечатать или сохранить в файл. Для этого достаточно использовать штатную возможность, доступную из контекстного меню и меню "Действия":

<IMG SRC="166/fig5.png">

Учитывайте, что фактически всё, что пользователь видит в списках, может быть выведено во внешние файлы. Единственное, что можно посоветовать – ведите протокол печати документов на серверах печати. Для особо критичных форм необходимо настроить панель действий, связанную с защищаемым табличным полем так чтобы возможность вывода списка не была доступна из этой панели, и отключить контекстное меню (см. рис 6).

<IMG SRC="166/fig6.png">

Обмен данными в распределённой базе

Формат обмена данными достаточно прост и описан в документации. Если у пользователя есть возможность подменить несколько файлов, он может внести неавторизованные изменения в систему (хотя это занятие достаточно трудоёмкое). Возможность создания периферийной базы при использовании планов обмена распределённой базы данных не должна быть доступна обычным операторам.

Рекомендация: ограничить доступ к файлам обмена (оставить только администраторам ИБ), использовать шифрование.

Стандартный обмен данными XML

В стандартном обмене данными, который используется для обмена между типовыми конфигурациями (например, "Управление торговлей" и "Бухгалтерия предприятия") есть возможность указать в правилах обмена обработчики событий загрузки и выгрузки объектов. Реализуется это получением обработчика из файла и процедурой "Выполнить()" стандартной обработки загрузки и выгрузки файла (процедура "Выполнить()" запускается на клиентской части). Очевидно, что несложно создать такой фальшивый файл обмена, который будет выполнять вредоносные действия. Для большинства ролей пользователей типовых решений обмен по умолчанию разрешён.

Рекомендация: ограничить доступ к XML-обмену для большинства пользователей (оставить только администраторам ИБ). Вести протоколы запусков этой обработки, сохраняя файл обмена, например, посылая его электронной почтой администратору ИБ до загрузки.

Использование универсальных отчетов, особенно консоли отчетов

Еще одной проблемой является доступ пользователей по умолчанию к универсальным отчетам, особенно это касается отчета "Консоль отчетов". Этот отчет характерен тем, что позволяет выполнить практически любые запросы к ИБ, и, если даже система прав 1С (в том числе RLS) настроена достаточно жёстко, позволяет пользователю получить много "лишней" информации и заставить сервер выполнять такой запрос, который отнимет все ресурсы системы.

Рекомендация: отчет "Консоль отчетов" использовать только для администраторов ИБ.

Использование полноэкранного режима (режима рабочего стола)

Одним из эффективных способов организации специализированных интерфейсов с ограниченным доступом к функционалу программы является полноэкранный режим основной (и, возможно, единственной) формы, используемого интерфейса. При этом не возникает вопросов по доступности, например, меню "Файл" и все действия пользователя ограничиваются возможностями используемой формы. Подробнее см. "Особенности реализации режима рабочего стола" на диске ИТС.

Резервное копирование

Резервное копирование для клиент-серверной версии 1С можно выполнять двумя способами: выгрузка данных в файл с расширением dt и создание резервных копий средствами SQL. У первого способа достаточно много недостатков: требуется монопольный доступ, само создание копии происходит значительно дольше, в некоторых случаях (при нарушении структуры ИБ) создание архива невозможно, но есть одно преимущество – минимальный размер архива. Для резервного копирования SQL всё наоборот: создание копии происходит в фоновом режиме средствами SQL сервера, за счет простой структуры и отсутствия сжатия - это очень быстрый процесс, и, пока физическая целостность БД SQL не нарушена, резервное копирование выполняется, но размер копии совпадает с истинным размером ИБ в развёрнутом состоянии (сжатие не производится). За счет дополнительных преимуществ системы резервного копирования MS SQL, целесообразнее использовать именно её (допускается 3 вида резервных копий: полная, дифференциальная, копия журнала транзакций; есть возможность создать регулярно выполняемые задания; быстро развёртываестся резервная копия и система резервного копирования; реализована возможность предсказать размер требуемого дискового пространства и пр.). Основными моментами организации резервного копирования с точки зрения безопасности системы являются:

Необходимость выбора места хранения резервных копий таким образом, чтобы они не были доступны пользователям.
Необходимость хранения резервных копий на физическом удалении от сервера MS SQL (на случай стихийных бедствий, пожаров, нападения и
т.п.)
Возможность дать права на запуск резервного

Книга знаний