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

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

Переполнение стека

Переполнение стека - это когда вы использовали больше памяти для стека, чем предполагалось использовать в вашей программе. Во встроенных системах у вас может быть только 256 байт для стека, и если каждая функция занимает 32 байта, тогда вы можете иметь только вызовы функций 8 функции функции 2 с функцией глубокой функции 1, которая вызывает функцию 3, которая вызывает функцию 4.... кто звонит функция 8, которая вызывает функцию 9, но функция 9 перезаписывает память за пределами стека. Это может перезаписать память, код и т.д.

Многие программисты совершают эту ошибку, вызывая функцию A, которая затем вызывает функцию B, которая затем вызывает функцию C, которая затем вызывает функцию A. Она может работать большую часть времени, но только один раз неправильный ввод вызовет ее что круг навсегда, пока компьютер не узнает, что стек переполнен.

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

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

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

Встроенные системы

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

  • Запретить рекурсию и циклы - соблюдение политики и тестирования
  • Держите код и стек далеко друг от друга (код во флэш-памяти, стек в ОЗУ и никогда не будет соответствовать друг другу)
  • Поместите защитные полосы вокруг стека - пустую область памяти, которую вы заполняете магическим числом (обычно это программа прерывания, но здесь есть много вариантов), а сотни или тысячи раз в секунду вы смотрите на защитные полосы чтобы убедиться, что они не были перезаписаны.
  • Использовать защиту памяти (т.е. не выполнять в стеке, не читать или писать непосредственно за стек)
  • Прерывания не вызывают вторичные функции - они устанавливают флаги, копируют данные и позволяют приложению заботиться о его обработке (в противном случае вы можете получить 8 в глубине вашего дерева вызовов функций, иметь прерывание, а затем выйти еще несколько функции внутри прерывания, вызывающие выброс). У вас несколько деревьев вызовов - одно для основных процессов и по одному для каждого прерывания. Если ваши прерывания могут прервать друг друга... ну, есть драконы...

Языки и системы высокого уровня

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

  • Уменьшите локальное хранилище переменных (локальные переменные хранятся в стеке), хотя компиляторы довольно умны в этом отношении и иногда помещают больших кусков в кучу, если ваше дерево вызовов является мелким)
  • Избегайте или строго ограничивайте рекурсию
  • Не прерывайте свои программы слишком далеко на меньшие и меньшие функции - даже без учета локальных переменных каждый вызов функции потребляет до 64 байтов в стеке (32-битный процессор, сохраняя половину регистров процессора, флаги и т.д.).
  • Держите дерево вызовов неглубоким (аналогично приведенному выше описанию)

Веб-серверы

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

"Руководство программиста по Informix® DataBlade™ API" доступно для загрузки в . Раздел "Managing Stack Space" описывает создание пользовательских функций (UDR). Данная статья предоставляет дополнительную информацию и советы по отладке.

Нижеприведенная информация справедлива вне зависимости от того, выполняется ли UDR на определенном пользователем виртуальном процессоре (VP), или же на CPU VP. Стек нити может быть перемещен на определенный пользователем виртуальный процессор непосредственно перед выполнением UDR.

Стек какого размера выделяется для UDR?

Размер стека, доступного для UDR, зависит от того, как UDR была создана:

    с помощью модификатора STACK, который позволяет UDR использовать свой специально выделенный стек,

    без модификатора STACK, что означает, что UDR будет использовать стек, выделяемый сервером, совместно с нитью, выполняющей запрос. Размер стека в данном случае будет определяться значением параметра STACKSIZE в файле конфигурации onconfig.

Модификатор STACK

Выражения СREATE PROCEDURE или CREATE FUNCTION имеют опциональный модификатор STACK, который позволяет Вам указать размер пространства стека в байтах, который необходим для выполнения UDR.

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

Если величина STACK меньше, чем значение параметра STACKSIZE в файле onconfig (см. следующий раздел), то размер выделяемого для UDR стека будет автоматически округляться до величины STACKSIZE.

Параметр конфигурации STACKSIZE

Файл конфигурации onconfig включает в себя параметр STACKSIZE, который определяет размер стека по-умолчанию для пользовательских нитей.

Если Вы не указываете STACK при создании UDR, сервер не выделяет дополнительное пространство стека для выполнения этой UDR. Вместо этого UDR использует пространство стека, выделенное для выполнения запроса. Доступный размер стека будет зависеть от накладных расходов на выполнение функции на уровне SQL.

Стек для нити выделяется единожды для конкретной нити, выполняющей запрос. Быстродействие выше, когда UDR делит один стек с нитью, так как сервер не тратит ресурсов на выделение дополнительного стека для каждого вызова UDR. С другой стороны, если размер используемого UDR стека приближается к значению STACKSIZE, это может вызвать переполнение стека при вызове функции в составе сложного запроса (в этом случае для выполнения UDR будет доступно меньше пространства стека).

Следует помнить, что не стоит устанавливать завышенное значение STACKSIZE, так как это затронет все пользовательские нити.

Когда необходимо управлять размером стека?

YВы должны управлять пространством стека если UDR выполняет рекурсивные вызовы или если UDR требует большего пространства стека, чем доступно по-умолчанию в стеке нити запроса (STACKSIZE).

Есть два способа увеличения стека для выполнения UDR:

    Указать модификатор STACK при создании UDR.

    Использовать mi_call() для выполнения рекурсивных вызовов (см. пример в "Руководстве программиста по Informix DataBlade API").

Если Вы не указываете размер через STACK, и если Вы не используете mi_call() для увеличения текущего стека, и если при этом UDR делает что-то, что требует большого пространства стека, то это вызовет переполнение стека.

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

Что делать, если что-то идет не так?

Наблюдение за использованием стека

Цель наблюдения - идентификация конкретной UDR, которая вызывает переполнение стека, чтобы Вы могли изменить значение STACK специально для конкретной UDR.

    Наблюдение использования стека с помощью команды "onstat -g sts"

    Наблюдение за сессией, выполняющей запрос SQL, с помощью "onstat -g ses session_id"

После идентификации запроса SQL, который заканчивается переполнением стека, следует определить использование стека путем раздельного выполнения запросов с UDR, которые входят в состав оригинального запроса.

Вы можете динамически устанавливать значение STACK для UDR. Например:

alter function MyFoo (lvarchar,lvarchar) with (add stack=131072);

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

Увеличение STACKSIZE

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

Если увеличение STACKSIZE не помогло, скорее всего проблема в повреждении памяти. Вот несколько предложений:

    Включите memory scribble и проверку пулов памяти. Раздел "Debugging Problems" в статье Memory Allocation for UDRs объясняет, как это сделать.

    Пересмотрите использование mi_lvarchar . Особое внимание следует уделить местам, где mi_lvarchar передается функции, которая ожидает получить нуль-терминированная строку в качестве аргумента.

    Сократите количество CPU (или пользовательских) VP до одного, чтобы воспроизвести проблему быстрее.

mi_print_stack() -- Solaris

Informix Dynamic Server для OC Solaris включает функцию mi_print_stack(), которая может быть вызвана в UDR. По-умолчанию эта функция сохраняет фрейм стека в следующий файл:

/tmp/default.stack

Вы не можете изменить имя файла вывода, но можно изменить его расположение изменив значение переменной окружения DBTEMP. Убедитесь, что в директорию $DBTEMP разрешена запись пользователю informix. Любые ошибки, возникающие при выполнении mi_print_stack() выводятся в $MSGPATH.

Данная функция доступна только для OC Solaris.

Глоссарий

Термины и сокращения, используемые в данной статье:

UDR User-Defined Routine
VP Virtual Processor

Стек программы - это специальная области памяти, организованная по принципу очереди LIFO (Last in, first out - последним пришел, первым ушел). Название "стек" произошло из-за аналогии принципа его построения со стопкой (англ. stack) тарелок - можно класть тарелки друг на друга (метод добавления в стек, "заталкивание", "push"), а затем забирать их, начиная с верхней (метод получения значения из стека, "выталкивание", "pop"). Стек программы также называют стек вызовов, стек выполнения, машинным стеком (чтобы не путать его со "стеком" - абстрактной структурой данных).

Для чего нужен стек? Он позволяет удобно организовать вызов подпрограмм. При вызове функция получает некоторые аргументы; также она должна где-то хранить свои локальные переменные. Кроме того, надо учесть, что одна функция может вызвать другую функцию, которой тоже надо передавать параметры и хранить свои переменные. Используя стек, при передаче параметров нужно просто положить их в стек, тогда вызываемая функция сможет их оттуда "вытолкнуть" и использовать. Локальные переменные тоже можно хранить там же - в начале своего кода функция выделяет часть памяти стека, при возврате управления - очищает и освобождает. Программисты на высокоуровневых языках обычно не задумываются о таких вещах - весь необходимый рутинный код за них генерирует компилятор.

Последствия ошибки

Теперь мы подошли почти вплотную к проблеме. В абстрактном виде стек представляет собой бесконечное хранилище, в которое можно бесконечно добавлять новые элементы. К сожалению, в нашем мире все конечно - и память под стек не исключение. Что будет, если она закончится, когда в стек заталкиваются аргументы функции? Или функция выделяет память под свои переменные?

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

Чтобы быть совсем точным, следует отметить, что подобное описание событий верно лишь для компиляторов, компилирующих в "родной" (native) код. В управляемых языках у виртуальной машины есть свой стек для управляемых программ, за состоянием которого гораздо проще следить, и можно даже позволить себе при возникновении переполнения передать программе исключение. В языках Си и Си++ на подобную "роскошь" рассчитывать не приходится.

Причины ошибки

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

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

Однако динамическая память является довольно медленной в плане выделения и освобождения (поскольку этим занимается операционная система), кроме того, при прямом доступе приходится вручную выделять её и освобождать. Память же в стеке выделяется очень быстро (по сути, надо лишь изменить значение одного регистра), кроме того, у объектов, выделенных в стеке, автоматически вызываются деструкторы при возврате управления функцией и очистке стека. Разумеется, тут же возникает желание получить память из стека. Поэтому третий путь к переполнению - самостоятельное выделение в стеке памяти программистом. Специально для этой цели библиотека языка Си предоставляет функцию alloca. Интересно заметить, что если у функции для выделения динамической памяти malloc есть свой "близнец" для её освобождения free, то у функции alloca его нет - память освобождается автоматически после возврата управления функцией. Возможно, это только осложняет ситуацию - ведь до выхода из функции освободить память не получится. Даже несмотря на то, что согласно man-странице "функция alloca зависит от машины и компилятора; во многих системах ее реализация проблематична и содержит много ошибок; ее использование очень несерьезно и не одобряется" - она все равно используется.

Примеры

В качестве примера рассмотрим код для рекурсивного поиска файлов, расположенный на MSDN:

Void DirSearch(String* sDir) { try { // Find the subfolders in the folder that is passed in. String* d = Directory::GetDirectories(sDir); int numDirs = d->get_Length(); for (int i=0; i < numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->Text); int numFiles = f->get_Length(); for (int j=0; j < numFiles; j++) { listBox1->Items->Add(f[j]); } DirSearch(d[i]); } } catch (System::Exception* e) { MessageBox::Show(e->Message); } }

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

Пример второго подхода, взятый из вопроса "Почему происходит переполнение стека?" с сайта под названием Stack Overflow (сайт является сборником вопросов и ответов на любые программистские темы, а не только по переполнению стека, как может показаться):

#define W 1000 #define H 1000 #define MAX 100000 //... int main() { int image; float dtr; initImg(image,dtr); return 0; }

Как видно, в функции main выделяется память в стеке под массивы типов int и float по миллиону элементов каждый, что в сумме дает чуть менее 8 мегабайт. Если учесть, что по умолчанию Visual C++ резервирует под стек лишь 1 мегабайт, то ответ становится очевидным.

А вот пример, взятый из GitHub-репозитория проекта Flash-плеера Lightspark:

DefineSoundTag::DefineSoundTag(/* ... */) { // ... unsigned int soundDataLength = h.getLength()-7; unsigned char *tmp = (unsigned char *)alloca(soundDataLength); // ... }

Можно надеятся, что h.getLength()-7 не будет слишком большим числом, чтобы на следующей строчке не произошло переполнения. Но стоит ли сэкономленное на выделении памяти время "потенциального" вылета программы?

Итог

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

Библиографический список

  • Э. Таненбаум. Архитектура компьютера.
  • Wikipedia. Stack overflow.
  • Stack Overflow. Stack overflow C++.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

  4. Сравнительно небольшой возраст платформы.

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

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

Соблюдайте общие правила настройки безопасности.

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

  • Доступ к серверам физически ограничен и обеспечена их бесперебойная работа:
    • серверное оборудование отвечает требованиям надёжности, замена неисправного серверного оборудования отлажена, для особо критичных участков используются схемы с дублированием аппаратного обеспечения (RAID, питание от нескольких источников, несколько каналов связи и т.п.);
    • серверы находятся в запираемом помещении, причем это помещение открывается только на время работ, которые не могут быть выполнены удалённо;
    • право открывать помещение серверов есть только у одного-двух человек, на случай экстренной необходимости разработана система оповещения ответственных лиц;
    • обеспечено бесперебойное электропитание серверов
    • обеспечен нормальный климатический режим работы оборудования;
    • в помещении серверов есть пожарная сигнализация, нет вероятности затопления (особенно касается первых и последних этажей);
  • Настройки сети и информационной инфраструктуры предприятия выполнены корректно:
    • на всех серверах установлены и настроены брандмауэры;
    • все пользователи и компьютеры авторизованы в сети, пароли достаточно сложны, чтобы их нельзя было подобрать;
    • у операторов системы достаточно прав для нормальной работы с ней, но нет прав на административные действия;
    • на всех компьютерах сети установлены и включены антивирусные средства;
    • желательно, чтобы пользователи (кроме администраторов сети) не обладали административными правами на клиентских рабочих местах;
    • доступ в Интернет и к съёмным носителям информации должен быть регламентирован и ограничен;
    • системный аудит событий безопасности должен быть настроен;
  • Решены основные организационные вопросы:
    • пользователи обладают достаточной квалификацией для работы с 1С и аппаратными средствами;
    • пользователи извещены об ответственности за нарушение правил эксплуатации;
    • назначены материально ответственные на каждый материальный элемент информационной системы;
    • все системные блоки опломбированы и закрыты;
    • особое внимание уделите инструктажу и контролю над уборщиками помещений, строителями и электриками. Эти лица могут по неосторожности нанести ущерб, который не сопоставимо больше умышленного вреда, причинённого недобросовестным пользователем системы.

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

  • MS SQL Server, сервер приложений и клиентская часть работают на разных компьютерах, серверные приложения работают под правами специально созданных пользователей Windows;
  • Для MS SQL Server
    • установлен режим смешанной авторизации
    • пользователи MS SQL, входящие в роль serveradmin, не участвуют в работе 1С,
    • для каждой ИБ 1С создан отдельный пользователь MS SQL, не имеющий привилегированного доступа к серверу,
    • пользователь MS SQL одной ИБ не имеет доступа к другим ИБ;
  • Пользователи не имеют непосредственного доступа к файлам сервера приложений и сервера MS SQL
  • Рабочие места операторов оснащены ОС Windows 2000/XP (не Windows 95/98/Me)

Не пренебрегайте рекомендациями разработчиков системы и чтением документации. На дисках ИТС в разделе "Методические рекомендации" публикуются важные материалы по настройке системы. Особое внимание обратите на следующие статьи:

  1. Особенности работы приложений с сервером 1С:Предприятия
  2. Размещение данных 1С:Предприятия 8.0
  3. Обновление 1С:Предприятия 8.0 пользователями Microsoft Windows без прав администратора
  4. Редактирование списка пользователей от лица пользователя, не имеющего административных прав
  5. Настройка параметров брандмауэра Windows XP SP2 для работы SQL Server 2000 и SQL Server Desktop Engine (MSDE)
  6. Настройка параметров COM+ Windows XP SP2 для работы сервера 1С:Предприятия 8.0
  7. Настройка параметров брандмауэра Windows XP SP2 для работы сервера 1С:Предприятия 8.0
  8. Настройка параметров брандмауэра Windows XP SP2 для работы HASP License Manager
  9. Создание резервной копии информационной базы средствами SQL Server 2000
  10. Вопросы установки и настройки 1C:Предприятия 8.0 в варианте "клиент-сервер" (одна из важнейших статей)
  11. Особенности настройки Windows Server 2003 при установке сервера 1С:Предприятия 8.0
  12. Регулирование доступа пользователей к информационной базе в клиент-серверном варианте (одна из важнейших статей)
  13. Сервер 1С:Предприятия и SQL-сервер
  14. Детализированная процедура установки 1С:Предприятия 8.0 в варианте "клиент-сервер" (одна из важнейших статей)
  15. Использование встроенного языка на сервере 1С:Предприятия

Но, читая документацию, критически относитесь к полученной информации, например, в статье "Вопросы установки и настройки 1C:Предприятия 8.0 в варианте "клиент-сервер"" не совсем точно описаны права, которые требуются пользователю USER1CV8SERVER. На приведённый список ниже будут встречаться ссылки, так, например [ИТС1] означает статью "Особенности работы приложений с сервером 1С:Предприятия". Все ссылки на статьи даны на последний на момент написания выпуск ИТС (январь 2006 г.)

Используйте для пользователей возможности авторизации совмещённой с авторизацией Windows

Из двух возможных режимов авторизации пользователей: встроенная 1С и совмещённая с авторизацией ОС Windows – по возможности следует выбрать совмещённую авторизацию. Это позволит пользователям не путаться с несколькими паролями при работе, но при этом не понизит уровень безопасности системы. Однако, даже для пользователей, использующих только авторизацию Windows, крайне желательно при создании задать пароль, и только после этого отключить авторизацию 1С для данного пользователя. Для обеспечения восстановления системы в случае разрушения структуры Active Directory необходимо оставить хотя бы одного пользователя, который может войти в систему, используя авторизацию 1С.

Создавая роли прикладного решения, не добавляйте прав "про запас"

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

Проводите регулярный просмотр журналов регистрации и протоколов работы системы

По возможности регламентируйте и автоматизируйте просмотр журналов регистрации и протоколов работы системы. При правильной настройке и регулярном просмотре журналов (с фильтрацией только по важным событиям) можно своевременно обнаружить несанкционированные действия или даже предотвратить их на этапе подготовки.

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

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

Внимание! описание уязвимости

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

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

Вся информация о списке пользователей данной ИБ и доступных им ролях в ней хранится в таблице Params в базе данных MS SQL (см. [ИТС2]). Взглянув на структуру и содержимое этой таблицы, становится очевидным, что вся информация о пользователях хранится в записи, со значением поля 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.


  • настроить безопасность 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С:Предприятия на терминальном сервере.

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

Сложность реализации данного требования приводит зачастую к возможности запустить на сервере терминалов "лишний" сеанс 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"

Небольшое отступление об автоматическом росте размера файла данных. По умолчанию для создаваемых баз данных размеры файлов увеличиваются с шагом 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.НеВосстанавливать);

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

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

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

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

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

Функция ЗашифроватьСтрокуDES(НезашифрованнаяСтрока, Пароль)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Эта константа из CryptoAPI


МеханизмШифрования.Content = НезашифрованнаяСтрока;
МеханизмШифрования.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С, но позволим себе сделать некоторые предварительные выводы. Конечно, идеальной данную платформу назвать нельзя – в ней, как и во многих других есть свои проблемы организации защищённой системы. Но это ни в коем случае не означает, что эти проблемы нельзя обойти, наоборот, почти все недостатки могут быть ликвидированы при правильной разработке, внедрении и использовании системы. Большинство проблем возникает из-за недостаточной проработки конкретного прикладного решения и среды его выполнения. Например, типовые решения без внесения значительных изменений просто не предполагают создание защищённой в достаточной мере системы.

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

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

14.04.2016 Версия 3.22 Изменен интерфейс, исправлены ошибки при переносе регистров, изменен порядок переноса организации и учетной политики. Платформа 8.3.7.2027 БП 3.0.43.174
17.03.2016 Версия 3.24 Исправлены замеченные ошибки. Платформа 8.3.8.1747 БП 3.0.43.241
16.06.2016 Версия 3.26 Исправлены замеченные ошибки. Платформа 8.3.8.2088 БП 3.0.44.123
16.10.2016 Версия 4.0.1.2 Исправлен перенос хранилища значения, изменён перенос учетной политики для релизов 3.44.*. Платформа 8.3.9.1818 БП 3.0.44.164.
19.04.2017 Версия 4.0.2.7 Изменен алгоритм переноса связанных со справочниками регистров, исправлены замеченные ошибки, исправлен перенос с перезаписью ссылок.
29.05.2017 Версия 4.0.4.5 Изменен перенос движений, добавлен просмотр движений перенесенных документов, что-то ещё....
30.05.2017 Версия 4.0.4.6 Исправлена ошибка при заполнении списка существующих в источнике справочников (спасибо shoy)
17.06.2017 Версия 4.0.5.1 Изменен алгоритм переноса движений.
19.07.2017 Версия 4.0.5.4 Изменен перенос КИ из БП 2.0. Неожиданно, прошёл перенос из УТ 10.3 у Smilegm, в этой версии чуть поправлен перенос для такой ситуации)))
10.08.2017 Версия 4.0.5.5 Исправлены ошибки при переносе из БП 2.0
19.09.2017 Версия 4.4.5.7 Исправлена проверка подключения для 3.0.52.*
28.11.2017 Версия 4.4.5.9 Исправлены замеченные ошибки
06.12.2017 Версия 5.2.0.4 Переработан алгоритм поиска ссылок. Добавлены процедуры переноса из БП 1.6, жёсткой привязки к БП больше нет - спокойно можно использовать для переноса данных "почти" одинаковых конфигураций. Все замечания постараюсь оперативно исправить.
08.12.2017 Версия 5.2.1.3 Добавлен алгоритм переноса ведомостей на выплату зарплаты из БП.2.0 в БП 3.0. Включены изменения для обмена между одинаковыми конфигурациями.
19.12.2017 Версия 5.2.2.2 Скорректирован перенос независимых регистров сведений для справочников, которые есть в измерениях этих регистров.

06.12.2017 Новая версия обработки 5.2.0.4. Из значимых изменений - возможность переноса из БП 1.6 в БП 3.0. Главное изменение - управление поиском ссылок справочников - в прежних версиях поиск был по ГУИД, а этой версии можно включить поиск "По реквизитам":

17.01.2018 Версия 5.2.2.3 Исправлены -замеченные ошибки подчинённых справочников и периодических регистров сведений.

19.07.2018 Версия 5.2.2.8 Исправлены замеченные ошибки.

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

21.12.2015 г. Вышла платформа 8.3.7.1805 и БП 3.0.43.29, соответственно и новая версия обработки 3.1:-) (описание ниже). Новый функционал - возможность сравнения остатков и оборотов между двумя базами БП (по всем счетам, если планы счетов совпадают, или по отдельным совпадающим счетам бух.учета, с аналитикой или без).
03.01.2016 г. Версия 3.5 - изменен механизм подключения к базе источнику - приведен в соответствие с БСП 2.3.2.43. Исправлены мелкие недочеты. Платформа 8.3.7.1845, БП 3.0.43.50
16.02.2016 г. Версия 3.6 - Добавлен флаг "Установить ручную корректировку" для документов, перенесённых с движениями. Исправлен перенос движений - документы, с датой меньше начала периода переносятся без движений. Платформа 8.3.7.1917, БП 3.0.43.116
22.03.2016 г. Версия 3.10 - Добавлен флаг "Всегда перезаписывать ссылки" для обязательной перезаписи ссылочных объектов (существенно снижается скорость переноса, но иногда необходимо). Добавлена закладка "Подготовка", на которой можно настроить соответствие планов счетов источника и приемника (на ровне кодов счета) и перенос констант. Платформа 8.3.7.1970, БП 3.0.43.148

03.04.2016 Версия 3.11 Изменено заполнение списка существующих в источнике документов: было заполнение по движениям по плану счетов, сделано просто по ссылкам за период, так же как в //сайт/public/509628/

Обработка предназначена для переноса данных за любой период аналогично "Выгрузка загрузка MXL" с ИТС, только без использования XML, JSON и пр. промежуточных файлов - обмен из базы в базу через COM. В версии старше 3.10 используется подключение по алгоритму из БСП, в котором предусморена регистрация comcntr.dll (если "разрещит" ОС), так же различные сообщения, когда устаановить соединение невозможно, например - "Информационная база находится в процессе обновления" и т.п. Добавлена проверка выбора в качестве источника ИБ приёмника - выдается предупреждение.

Может быть использована для:

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

2. Переноса документов за любой выбранных период.

3. Переноса всеё информации из "поломатой" ИБ, если она запускается в режиме 1С:Предприятия, а выгрузка данных или запуск Конфигуратора невозможны.

Особенность обработки - ИБ приёмника и источника могут быть различны перенос из 2.0 в 3.0 - редакции разные, но перенос работает!!! Несовпадающие реквизиты игнорируются, или для них нужно задать алгоритмы переноса.

Замечание: Конвертация данных НЕ ИСПОЛЬЗУЕТСЯ! И не спрашивайте почему!!! Для особо въедливых - БП 3.0 меняется чуть не каждый день, правила переноса поддерживать в актуальном состоянии уже нет никаких сил - тут всё проще:-).

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

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

При переносе организации переносится учетная политика, и "сопутствующие" регистры сведений. Поэтому при первом выборе организации в источнике, до появления её в приёмнике пройдёт какое-то врем.

Планы счетов источника и приёмника должны быть одинаковыми, никакие различающиеся счета в версиях 2.* в приёмник не переносятся, настройку соответствие счетов и аналитики планируется включит в дальнейшем. Счета переносятся по кодам, не найденные в приёмнике НЕ СОЗДАЮТСЯ!!!

Остальные объекты переносятся по внутренним идентификаторам (ГУИД), поэтому следует обратить внимание на некоторые ключевые справочники, например - Валюты.

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

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

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

С версии 3.22 интерфейс изменен, теперь все подготовительные операции выведены на закладки и доступны всегда


Важно обязательно проверит соответствие Плана счетов источника и приёмника и обязательно указать соответствие счетов.

Предопределённые элементы справочников удалять не нужно - они переносятся по идентификаторам конфигурации (не ГУИД).

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

При обмене с 2.0 часть реквизитов (например, контактная информация) переносится по встроенному в обработку алгоритму, т.к. для 2.0 и 3.0 они хранятся по-разному. Аналогичная ситуация с рядом документов (например, Корректировка долга).

Списко типов объектов может быть заполнен по разному в версии 3.22 это вынесено в подменю, изменения прописаны на картинке:

Есть упрощение использования обработки - можно не подбирать справочники для обмена, а просто заполнить список типов в приёмнике только теми типами справочников, у которых есть хотя бы одна запись в источнике.

В обработку встроен макет, в котором перечислены справочники, которые переносить из источника в приёмник не нужно (макет "Исключить из переноса"). В этот макет можно добавить (удалить) любые справочники. Если переносить всю НСИ не нужно - достаточно перенести документы, получить список которых можно так же без подбора типов, просто заполнить всеми документами источника, по которым существуют проводки.

Предусмотрен перенос документов с движениями, для обменов 3.0 в 3.0 и соответствии планов счетов отрабатывает один в один, при обмене 2.0 в 3.0 возможны ошибки, поэтому рекомендуется перенести документы без движений, и потом просто перепровести их в приемнике. При переносе документов с движениями устанавливается флаг «Ручная корректировка».

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

Если обработку планируется использовать для постоянного обмена - её можно зарегистрировать в ИБ приёмника (кнопка "Зарегистрировать"). Для "одноразовых" переносов можно просто использовать через Файл - Открыть.

21.12.2015 - Версия 3.1 платформа 8.3.7.1805 и БП 3.0.43.29 (версия 2.15 для 3.0.43.* не работает - конфигурацию достаточно сильно изменили).

Изменено:

Диалог выбора варианта подключения, флаг Клиент-сервер доступен всегда, в зависимости от его устновки доступен или выбор папки файловой базы, или поля с именем базы на сервере и именем самого сервера (исправлена ошибка диалога версии 2.15)

- НОВЫЙ ФУНКЦИОНАЛ: Механизм сверки остатков и оборотов между базами источника и приёмника в разной степени детализации:


Выбор вариантов сверки думаю понятен из рисунка:


Есть различия в использовании в тонком и толстом клиенте - в толстом сразу выводится окно сравнения файлов:


В тонком же клиенте не стал извращаться с программным нажиманием кнопок, предлагаю простой вариант вывода окна сравнения:


Сравнение в тонком клиенте, ИМХО, более удобно, т.к. имеет кнопки навигации по различиям, что при больших объемах таблиц удобней, чем прокрутка мышью:

22.03.2016 г. Версия 3.10 - Добавлен флаг "Всегда перезаписывать ссылки" для обязательной перезаписи ссылочных объектов (существенно снижается скорость переноса, но иногда необходимо). Добавлена закладка "Подготовка", на которой можно настроить соответствие планов счетов источника и приемника (на ровне кодов счета) и перенос констант. Платформа 8.3.7.1970, БП 3.0.43.148

- НОВЫЙ ФУНКЦИОНАЛ: Перед переносом документов рекомендуется проверить план счетов, на предметсоответствия в источнике и приёмнике, а так же соответствие устновленных констант.

Для этого добавлены закладка "Подготовка" в которой можно установить эти соответствия:


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

Для проверки и переноса соответствия установленных констант используется соотвествующая таблица:

Заполняем, если нужно - переносим. Переносятся только отмеченные флагом константы...




Close