Вопросы безопасности системы 1С:Предприятие 8.0 (клиент-серверный вариант)

09:29 / 10 февраля, 2006

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

Введение

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С.

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

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

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

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

Рисунок 1

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 приводит к следующему эффекту:

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

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

т. к. система не находит список пользователей, то можно запустить конфигуратор без авторизации;

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

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.

USER (злоумышленно) обеспечивает существование фиктивного временного сервера MS SQL на одной из рабочих станций в сети. Здесь есть 2 основные возможности:
- USER является локальным администратором WS и устанавливает MS SQL Server
- USER обеспечивает доступ к серверу на дополнительном ПК, например на ноутбуке или вне локальной сети.
Фиктивный сервер MS SQL назовём EXTERN.
USER обладает достаточными полномочиями для создания БД SQL на EXTERN.
Внимание! Пользователь создаёт пустую ИБ 1С, использующую в качестве хранилища данных EXTERN, и регистрирует её на сервере приложений 1С SRV2.
Пользователь создаёт в полученной ИБ конфигурацию особого вида, содержащую серверные модули. Данные модули будут исполняться на 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С на клиенте терминального доступа. Разрешайте эти возможности только для лиц имеющих административные права.

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

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

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

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

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

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

При входе в терминальный режим не запускается стандартное меню "Пуск" Windows или оно в значительной мере ограничено политикой безопасности и настройками меню "Программы". Как предельный вариант ограничений – использовать запуск 1С вместо запуска Explorer (возможно, сразу с ключами командной строки, определяющими ИБ). При использовании ICA лучше использовать seamles mode.
Пользователь не может запустить окно "Запуск программы" (рис 5.). Это можно сделать из меню "Пуск" или нажав Win+R или из диспетчера задач. Также необходимо проверить невозможность запустить приложение "CMD" путём запуска ярлыка.
Диспетчер задач недоступен (ни по 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С есть специальный параметр в наборе прав роли "Интерактивное открытие внешних обработок", но полностью проблему это не снимает – для полного решения надо достаточно сильно сузить круг пользователей, которые могут управлять внешними печатными формами, регламентными отчетами и другими штатными возможностями типовых решений реализованных с использованием внешних обработок. Например, по умолчанию в УПП у всех основных ролей пользователей есть возможность работы со справочником дополнительных печатных форм, а это, по сути, возможность использования любых внешних обработок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для более подробного ознакомления обратитесь к документации MS SQL.

Шифрование данных

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

Можно выделить несколько основных этапов обработки информации, которые можно защитить:

Передача данных между клиентской частью системы и сервером приложений
Передача данных между сервером приложений и MS SQL Server
Данные, хранящиеся на MS SQL Server (файлы данных на физическом диске)
Шифрование данных, хранящихся в ИБ
Внешние данные (по отношению к ИБ)

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

Общие сведения о криптографической защите сетевых соединений при использовании протокола TCP/IP.

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

Средства IPSec обеспечивают шифрование передаваемых данных при помощи алгоритмов DES и 3DES, а также проверку целостности при помощи хеш-функций MD5 или SHA1. IPSec может функционировать в двух режимах: режим транспорта и туннельный режим. Режим транспорта лучше подходит для защиты соединений в локальной сети. Туннельный режим может использоваться для организации VPN-соединений между отдельными сегментами сети или защиты удалённого подключения к локальной сети по открытым каналам данных.

Основными преимуществами такого подхода являются:

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

Однако у данного подхода есть ограничения и недостатки:

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

Детальное описание внедрения средств IPSec выходит за рамки данной статьи и требует понимания основных принципов функционирования протокола IP. Для того чтобы правильно настроить защиту соединений ознакомьтесь с соответствующей документацией.

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

Шифрование данных при передаче между клиентской частью системы и сервером приложений.

Кроме шифрования на уровне сетевого протокола, возможно шифрование данных на уровне протокола COM+, что упомянуто в статье "Регулирование доступа пользователей к информационной базе в клиент-серверном варианте" ИТС. Для реализации необходимо в "Службы компонентов" (Component Services) установить для приложения 1CV8 установить уровень проверки подлинности (Authentication level for calls) "Секретность пакетов" (Packet Privacy). При установке данного режима выполняется проверка подлинности пакета и его шифрование, включая данные, а также удостоверение и подпись отправителя.

Шифрование данных при передаче между сервером приложений и MS SQL Server

MS SQL Server предоставляет следующие средства для шифрования данных:

Возможно использование Secure Sockets Layer (SSL) при передаче данных между сервером приложений и MS SQL Server.
При использовании сетевой библиотеки Multiprotocol используется шифрование данных на уровне RPC. Это потенциально более слабое шифрование, чем при использовании SSL.
Если используется протокол обмена Shared Memory (это происходит, если сервер приложений и MS SQL Server расположены на одном компьютере), то шифрование не используется в любом случае.

Для того чтобы установить необходимость шифрования всех передаваемых данных для определённого сервера MS SQL необходимо воспользоваться утилитой "Server Network Utility". Запустите её и на закладке "General" установите флажок "Force protocol encryption". Метод шифрования выбирается в зависимости от используемого клиентским приложением (т.е. сервером приложения 1С). Для использования SSL необходимо правильно настроить службу выдачи сертификатов в сети.

Для того чтобы установить необходимость шифрования всех передаваемых данных для определённого сервера приложений необходимо воспользоваться утилитой "Client Network Utility" (обычно расположенной в "C:\WINNT\system32\cliconfg.exe"). Как и в предыдущем случае, на закладке "General" установите флажок "Force protocol encryption".

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

Для того чтобы более полно защитить соединение между сервером приложений и MS SQL Server при использовании протокола TCP/IP можно порекомендовать несколько изменений настроек, предлагаемых по умолчанию.

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

Сервером MS SQL и сервером приложений должен использоваться один и тот же порт.
При использовании брандмауэров, этот порт должен быть разрешён.
Нельзя устанавливать порт, который может использоваться другими приложениями на сервере MS SQL. Для справки можно воспользоваться http://www.ise.edu/in-notes/iana/assignments/port-numbers (адрес взят из SQL Server Books Online).
При использовании нескольких экземпляров службы MS SQL Server, для настройки обязательно ознакомьтесь с документацией MS SQL (раздел "Configuring Network Connections").

Во-вторых, в настройках протокола TCP/IP на сервере MS SQL можно установить флажок "Hide server", запрещающий ответы на широковещательные запросы данному экземпляру службы MS SQL Server.

Шифрование данных MS SQL, хранящихся на диске

Есть достаточно большой выбор программных и аппаратных средств для шифрования данных, расположенных на локальном диске (это и штатная возможность Windows использовать EFS, и использование ключей eToken, и программы сторонних производителей типа Jetico Bestcrypt или PGPDisk). Одной из основных задач, выполняемой этими средствами является защита данных при утрате носителя (например, при краже сервера). Стоит особенно отметить, что Microsoft не рекомендует хранить базы MS SQL на зашифрованных носителях, и это вполне обосновано. Основной проблемой при этом является существенное падение производительности и возможные проблемы надёжности от сбоев. Вторым фактором, осложняющим жизнь администратору системы, является необходимость обеспечить доступность всех файлов базы данных на момент первого обращения службы MS SQL к ним (т.е. желательно, чтобы при подключении шифрованного носителя были исключены интерактивные действия).

Для того чтобы избежать заметного падения производительности системы можно воспользоваться возможностью MS SQL создавать базы данных в нескольких файлах. Конечно, в этом случае база данных MS SQL не должна создаваться сервером 1С при создании информационной базы, а должна быть создана отдельно. Пример сценария на TSQL c комментариями приведён ниже:

USE master
GO
-- Создать базу данных SomeData,
CREATE DATABASE SomeData 
-- данные которой целиком расположена в группе файлов (filegroup) PRIMARY.
ON PRIMARY 
-- Основной файл данных расположен на зашифрованном носителе (логический диск E:)
-- и имеет начальный размер 100 МБ, может быть автоматически увеличен до 200 МБ с 
-- шагом 20 Мб
  ( NAME = SomeData1,
    FILENAME = 'E:\SomeData1.mdf',
    SIZE = 100MB,
    MAXSIZE = 200,
    FILEGROWTH = 2),
-- Второй файл данных расположен на незашифрованном носителе (логический диск С:)
-- и имеет начальный размер 100 МБ, может быть автоматически увеличен до предела 
-- дискового пространства с шагом 5% от текущего объёма файла (округляется до 64 Кб)
  ( NAME = SomeData2,
    FILENAME = 'c:\program files\microsoft sql server\mssql\data\SomeData2.ndf',
    SIZE = 100MB,
    MAXSIZE = UNLIMITED,
    FILEGROWTH = 5%)
LOG ON 
-- Хотя лог транзакций можно было также разделить на части, делать этого не стоит,
-- т.к. этот файл изменяется гораздо чаще и регулярно очищается (например при 
-- создании резервной копии БД). 
  ( NAME = SomeDatalog,
    FILENAME = 'c:\program files\microsoft sql server\mssql\data\SomeData.ldf',
    SIZE = 10MB,
    MAXSIZE = UNLIMITED,
    FILEGROWTH = 10)
GO
-- Лучше сразу отдать владение базой данных пользователю, от имени которого 
-- будет подключаться 1С. Для этого нам необходимо текущей базой объявить 
-- только что созданную,
USE SomeData
GO
-- и выполнить процедуру sp_changedbowner
EXEC sp_changedbowner @loginame = 'SomeData_dbowner'

GO

Небольшое отступление об автоматическом росте размера файла данных. По умолчанию для создаваемых баз данных размеры файлов увеличиваются с шагом 10% от текущего размера файла. Это вполне приемлемое решение для небольших баз данных, но не очень хорошее для больших: при размере базы, например, 20 ГБ файл должен разом увеличиться на 2 ГБ. Хотя это событие будет происходить достаточно редко, оно может длиться несколько десятков секунд (все другие транзакции в это время фактически простаивают), что, при возникновении его во время активной работы с базой данных, может послужить причиной некоторых сбоев. Вторым негативным следствием пропорционального приращения, которое проявляется при почти полностью заполненном дисковом пространстве, является вероятность преждевременного сбоя из-за недостатка свободного места. Например, если раздел диска объёмом 40 ГБ полностью отдан под одну базу данных (точнее, под один файл этой базы), то критическим размером файла базы данных при котором необходимо срочно (очень срочно, вплоть до прерывания нормальной работы пользователей) реорганизовать хранение информации, является размер файла данных 35 ГБ. При установленном размере приращения 10-20 МБ можно продолжать работу до достижения 39 ГБ.

Поэтому, хотя в приведённом листинге задано увеличение размера одного из файлов базы данных с шагом 5%, при больших размерах БД лучше установить фиксированное приращение 10-20 МБ. При установке значений шага роста размера файлов базы данных необходимо учесть, что до достижения одним из файлов файловой группы максимального размера, действует правило: файлы одной файловой группы увеличиваются все одновременно, когда все они будут заполнены полностью. Таким образом, в приведённом примере, когда файл SomeData1.mdf достигнет своего максимального размера 200 МБ, файл SomeData2.ndf будет размером около 1,1 ГБ.

После создания такой базы данных, если даже её незащищённые файлы SomeData2.ndf и SomeData.ldf станут доступны злоумышленнику, восстановить истинное состояние базы данных будет крайне затруднительно – данные (в том числе и информация о логической структуре базы данных) будут разбросаны по нескольким файлам, причем ключевая информация (о том, например, какие файлы составляют эту базу данных) будет находиться в зашифрованном файле.

Конечно, если используется хранение файлов базы данных с использованием криптографических средств, то резервное копирование (хотя бы этих файлов) не должно вестись на нешифруемый носитель. Для обеспечения архивации отдельных файлов базы данных следует пользоваться соответствующим синтаксисом команды "BACKUP DATABASE". Обратите внимание, что, несмотря на возможность защиты резервной копии базы данных паролем (опции "PASSWORD = " и "MEDIAPASSWORD = " команды "BACKUP DATABASE"), такая резервная копия не становится зашифрованной!

Шифрование данных сервера приложений и клиентской части, хранящихся на дисках

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

Шифрование данных встроенными средствами 1С.

Штатные возможности по использованию шифрования в 1С сводятся к использованию объектов работы с Zip-файлами с параметрами шифрования. Доступны следующие режимы шифрования: алгоритм AES c ключом 128, 192 или 256 бит и морально устаревший алгоритм, использовавшийся изначально в архиваторе Zip. Файлы Zip, зашифрованные при помощи AES не читаются многими архиваторами (WinRAR, 7zip). Для формирования файла, содержащего зашифрованные данные, необходимо указать пароль и алгоритм шифрования. Простейший пример функций шифрования-дешифрования, основанные на этой возможности приведён ниже:

Функция ЗашифроватьДанные(Данные, Пароль, МетодШифрования = Неопределено) Экспорт

    // Внимание! Корректность переданных параметров не отслеживается

    // Запишем данные во временный файл. Вообще-то далеко не любые данные можно так сохранить.
    ИмяВременногоФайла = ПолучитьИмяВременногоФайла();
    ЗначениеВФайл(ИмяВременногоФайла, Данные);
 
    // Запишем временные данные в архив
    ИмяВременногоФайлаАрхива = ПолучитьИмяВременногоФайла("zip");
    Зип = Новый ЗаписьZipФайла(ИмяВременногоФайлаАрхива, Пароль, , , ,МетодШифрования);
    Зип.Добавить(ИмяВременногоФайла);
    Зип.Записать();
 
    // Считываем данные из полученного архива в оперативную память
    ЗашифрованныеДанные = Новый ХранилищеЗначения(Новый ДвоичныеДанные(ИмяВременногоФайлаАрхива));

    // Временные файлы – удаляем
    УдалитьФайлы(ИмяВременногоФайла);
    УдалитьФайлы(ИмяВременногоФайлаАрхива);

    // Возвращаемое значение можно сохранить в поле базы данных типа "ХранилищеЗначения"
    Возврат ЗашифрованныеДанные;

КонецФункции

Функция РасшифроватьДанные(ЗашифрованныеДанные, Пароль) Экспорт

    // Внимание! Корректность переданных параметров не отслеживается

    // Записываем переданное значение в файл
    ИмяВременногоФайлаАрхива = ПолучитьИмяВременногоФайла("zip");
    ДвоичныеДанныеАрхива = ЗашифрованныеДанные.Получить();
    ДвоичныеДанныеАрхива.Записать(ИмяВременногоФайлаАрхива);

    // Извлекаем первый файл только что записанного архива
    ИмяВременногоФайла = ПолучитьИмяВременногоФайла();
    Зип = Новый ЧтениеZipФайла(ИмяВременногоФайлаАрхива, Пароль);
    Зип.Извлечь(Зип.Элементы[0], ИмяВременногоФайла, РежимВосстановленияПутейФайловZIP.НеВосстанавливать);

    // Считываем записанный файл
    Данные = ЗначениеИзФайла(ИмяВременногоФайла + "\" + Зип.Элементы[0].Имя);

    // Удаляем временные файлы
    УдалитьФайлы(ИмяВременногоФайла);
    УдалитьФайлы(ИмяВременногоФайлаАрхива);

    Возврат Данные;

КонецФункции

Конечно, такой способ нельзя назвать идеальным – данные записываются во временную папку в открытом виде, производительность метода, прямо скажем, хуже некуда, хранение в базе данных требует чрезвычайно много места, но это единственный способ, который основывается только на встроенных механизмах платформы. К тому же у него есть преимущество перед многими другими методами – этот метод одновременно с шифрацией выполняет упаковку данных. Если требуется реализовать шифрование без тех недостатков, которые есть у данного метода, то необходимо либо реализовать их во внешней компоненте, либо обратиться к существующим библиотекам через создание COM-объектов, например, используя Microsoft CryptoAPI. В качестве примера приведём функции шифрования/дешифрования строки на основании полученного пароля.

Функция ЗашифроватьСтрокуDES(НезашифрованнаяСтрока, Пароль)
 
    //Внимание! Параметры не проверяются!

    CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Эта константа из CryptoAPI
 
    МеханизмШифрования = Новый COMОбъект("CAPICOM.EncryptedData");
    МеханизмШифрования.Content = НезашифрованнаяСтрока;
    МеханизмШифрования.SetSecret(Пароль);
    МеханизмШифрования.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
    ЗашифрованнаяСтрока = МеханизмШифрования.Encrypt();
   
    Возврат ЗашифрованнаяСтрока;

КонецФункции // ЗашифроватьСтрокуDES()
 
Функция РасшифроватьСтрокуDES(ЗашифрованнаяСтрока, Пароль)
 
    //Внимание! Параметры не проверяются!
 
    МеханизмШифрования = Новый COMОбъект("CAPICOM.EncryptedData");
    МеханизмШифрования.SetSecret(Пароль);
    Попытка
        МеханизмШифрования.Decrypt(ЗашифрованнаяСтрока);
    Исключение
        // Неверный пароль!;
        Возврат Неопределено;
    КонецПопытки;
 
    Возврат МеханизмШифрования.Content;

КонецФункции // РасшифроватьСтрокуDES()

Учтите, что при передаче пустого значения в качестве строки или пароля в эти функции возникнет сообщение об ошибке. Строка, полученная при помощи такой процедуры шифрования несколько длиннее оригинала. Специфика этого шифрования такова, что если зашифровать строку два раза, то полученные строки НЕ будут идентичны.

Основные ошибки при использовании криптографических средств.

При использовании криптографических средств очень часто допускаются одни и те же ошибки:

Недооценка падения производительности при использовании криптографии.

Криптография – задача, которая требует достаточно большого количества вычислений (особенно для таких алгоритмов, как DES, 3DES, ГОСТ, PGP). И даже в случае использования производительных и оптимизированных алгоритмов (RC5, RC6, AES) никуда не деться от лишней передачи данных в памяти и вычислительной обработки. А это почти сводит на нет возможности многих серверных компонент (RAID-массивы, сетевые адаптеры). При использовании аппаратного шифрования или аппаратного получения ключа для шифрования возникает дополнительное возможное узкое место в производительности: скорость передачи данных между дополнительным устройством и памятью (причём производительность такого устройства может не играть решающей роли). При использовании шифрования небольших объёмов данных (например, почтового сообщения) возрастание вычислительной нагрузки на систему не столь заметно, но в случае тотального шифрования всего и вся это может очень сильно сказаться на производительности системы в целом.

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

На текущий момент возможности техники таковы, что ключ длиной 40-48 бит может быть подобран силами небольшой организации, а ключ длиной 56-64 бит – силами крупной организации. Т.е. должны использоваться алгоритмы, использующие ключ хотя бы 96 или 128 бит. Но большинство ключей генерируются при помощи хеш-алгоритмов (SHA-1 и т.п.) на основании паролей вводимых пользователем. В этом случае может не спасти и ключ длиной 1024 бита. Во-первых, зачастую используется легко подбираемый пароль. Факторами, облегчающими подбор, являются: использование только одного регистра букв; использование слов, имён и выражений в паролях; использование известных дат, дней рождений и т.п.; использование "шаблонов" при генерации паролей (например, 3 буквы, затем 2 цифры, затем 3 буквы во всей организации). Хороший пароль должен представлять собой достаточно случайную последовательность букв обоих регистров, цифр и знаков препинания. Пароли, вводимые с клавиатуры длиной до 7-8 символов даже при соблюдении этих правил могут быть подобраны за разумное время, поэтому лучше, чтобы пароль был как минимум 11-13 символов. Идеальным решением является отказ от генерации ключа по паролю, например, использование различных смарт-карт и т.п., но в этом случае необходимо предусмотреть возможность защиты от потери носителя ключа шифрования.

Ненадёжное хранение ключей и паролей.

Типичными примерами этой ошибки являются:

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

Зачем делать бронированную дверь, если ключ от неё лежит под ковриком у двери?

Передача изначально зашифрованных данных в небезопасную среду.

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

Использование криптографических средств не по назначению

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

Общие рекомендации по использованию криптографических средств

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

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

Заключение

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

Компания SoftKey – это уникальный сервис для покупателей, разработчиков, дилеров и аффилиат–партнеров. Кроме того, это один из лучших Интернет-магазинов ПО в России, Украине, Казахстане, который предлагает покупателям широкий ассортимент, множество способов оплаты, оперативную (часто мгновенную) обработку заказа, отслеживание процесса выполнения заказа в персональном разделе.

Speshuric

Хакеры ненавидят этот канал!

Спойлер: мы раскрываем их любимые трюки

Расстройте их планы — подпишитесь