Пройти всех пользователей иб 1с 8. Настройка списка пользователей. Шифрование данных при передаче между сервером приложений и MS SQL Server

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

Проблемы информационной безопасности постоянно усугубляются процессами проникновения во все сферы общества технических средств обработки и передачи данных, особо остро данная проблема стоит в области финансовых учетных систем. Наиболее популярной системой бухгалтерского учета, ведения продаж, CRM процессов в России является система 1С Предприятие.

Рассмотрим потенциальные угрозы безопасности при использовании программы 1С.

	Использование 1С с базами в файловом формате. Файловые базы 1С являются наиболее уязвимые к физическому воздействию. Связано это с особенностями архитектуры такого типа баз – необходимостью держать открытыми (с полным доступом) все файлы конфигурации и самих файловых баз для всех пользователей операционной системы. В результате, любой пользователь, имеющий право работать в файловой базе 1С, теоретически может скопировать или даже удалить информационную базу 1С двумя кликами мышки.
	Использование 1С с базами в СУБД формате. Данный тип проблем возникает, если в качестве хранилища баз 1С используется СУБД (PosgreSQL, MS SQL), а в качестве промежуточной службы связи 1С и СУБД используется сервер 1С предприятия. Такой пример – во многих компаниях практикуется доработка конфигураций 1С под свои нужды. В процессе доработки, в условиях проектной «суеты», постоянных испытаний нового доработанного функционала – ответственные специалисты зачастую пренебрегают правилами сетевой безопасности. В результате, некоторые личности, которые имеют прямой доступ к базе данных СУБД или имеют права администратора на сервере 1С Предприятие, пусть даже на временный тестовый период – могут либо сделать резервную копию на внешние ресурсы, либо вовсе удалить базу данных в СУБД.
	Открытость и доступность серверного оборудования. При наличии несанкционированного доступа к серверному оборудованию сотрудники компании или третьи лица могут использовать этот доступ для кражи или порчи информации. Проще говоря – если злоумышленник получает доступ непосредственно к корпусу и консоли сервера 1с – круг его возможностей расширяется в десятки раз.
	Риски кражи, утечки персональных данных. Под актуальными угрозами безопасности персональных данных здесь понимается совокупность условий и факторов, создающих актуальную опасность несанкционированного, в том числе случайного, доступа к персональным данным при их обработке в информационной системе, например, ответственными сотрудниками, операторами ПК, бухгалтерией и т.д. Результатом этого могут стать уничтожение, изменение, блокирование, копирование, предоставление, распространение персональных данных, а также иные неправомерные действия ответственных лиц.
	Сетевая безопасность. Информационная система предприятия, построенная с нарушением ГОСТ, требований к безопасности, рекомендаций, либо не имеющая надлежащей ИТ-поддержки – изобилует дырами, вирусным и шпионским программным обеспечением, множеством бэкдоров (несанкционированных доступов во внутреннюю сеть), что напрямую влияет на сохранность корпоративных данных в 1С. Это приводит к легкому доступу злоумышленника к коммерчески значимой информации. К примеру, свободный доступ к резервным копиям, отсутствие пароля на архивы с резервными копиями злоумышленник может использовать в корыстных целях. Не говоря уже об элементарном повреждении базы 1С вирусной активностью.
	Взаимосвязь 1С с внешними объектами. Еще одной потенциальной угрозой является необходимость (а иногда и специальная маркетинговая особенность) учетной базы 1С связываться с «внешним миром». Выгрузки/загрузки клиент-банков, обмен информацией с филиалами, регулярная синхронизация с корпоративными сайтами, порталами, другими программами сдачи отчетности, управления клиентами и продажами и многое другое. Поскольку в данной области 1С не приветствуются соблюдения стандартов безопасности и унифицированности сетевого обмена информации – утечка вполне реальна на любом отрезке пути ее следования. В результате потребностей в нестандартных доработках автоматизации процессов или сокращения бюджета на необходимые меры по защите трафика – в учетной системе мгновенно растет количество уязвимостей, дыр, небезопасных соединений, открытых портов, легкодоступных файлов обмена в незашифрованном виде и т.д. Можно смело представить себе, к чему это может привести – начиная от элементарного вывода из строя базы 1С на определенное время, заканчивая подделкой платежного поручения на несколько миллионов.

Что можно предложить для решения подобных проблем?

1. При работе с файловыми базами 1С обязательно внедрить ряд мер по обеспечению безопасности баз:

Используя разграничения доступа NTFS, дать необходимые права только тем пользователям, которые работают с этой базой, тем самым обезопасив базу от кражи или порчи недобросовестными сотрудниками или злоумышленником;
Всегда использовать авторизацию Windows для входа на рабочие станции пользователей и доступ к сетевым ресурсам;
Использовать шифрованные диски или шифрованные папки, которые позволят сохранить конфиденциальную информацию даже при выносе базы 1С;
Установить политику автоматической блокировки экрана, а также провести обучение пользователей для разъяснения необходимости блокировки профиля;
Разграничение прав доступа на уровне 1С позволит пользователям получать доступ только к той информации, на которую они имеют соответствующие права;
Необходимо разрешить запуск конфигуратора 1С только тем сотрудникам, которым он необходим.

2. При работе с СУБД базами 1С требуется обратить внимание на следующие рекомендации:

Учетные данные для подключения к СУБД не должны иметь административных прав;
Необходимо разграничивать права доступа к базам СУБД, например, создавать для каждой информационной базы свою учетную запись, что позволит минимизировать потерю данных при взломе одной из учетных записей;
Рекомендуется ограничить физический и удаленный доступ к серверам баз данных и 1С предприятия;
Рекомендуется использовать шифрование для баз данных, это позволит сохранить конфиденциальные данные, даже если злоумышленник получит физический доступ к файлам СУБД;
Также одним из важных решений является шифрование либо установка пароля на резервные копии данных;
Обязательным является создание администраторов кластера 1С, а также сервера 1С, так как по умолчанию если не созданы пользователи, полный доступ к информационным базам абсолютно все пользователи системы.

3. Требования к обеспечению физической безопасности серверного оборудования:
(согласно ГОСТ Р ИСО/МЭК ТО – 13335)

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

4. Конфиденциальность персональных данных. Основной целью при организации защиты персональных данных является нейтрализация актуальных угроз в информационной системе, определенных Федеральным законом от 27.07.2006 № 152-ФЗ «О персональных данных» , перечнем государственных стандартов и требований международных сертификаций по ИТ-безопасности (ГОСТ Р ИСО/МЭК 13335 2-5, ISO 27001) . Достигается это путем ограничения доступа к информации по ее типам, разграничение доступа к информации по ролям пользователей, структурирование процесса обработки и хранения информации.
Вот ряд ключевых положений:

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

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

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

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

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

Системная интеграция. Консалтинг

2009 г.

Cекция "Модернизация управленческих и финансово-экономических механизмов на разных уровнях системы образования с использованием технологий "1С""

"25. Методы и средства обеспечения информационной безопасности в системе «1С:Предприятие 8.1»" (Хорев П.Б., Российский государственный социальный университет (РГСУ), Москва)

Презентация

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

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

идентификация и аутентификация пользователей информационных систем и активизированных ими процессов;
авторизация субъектов (определение прав доступа субъекта к объекту с конфиденциальной информацией);
аудит событий, имеющих отношение к безопасности информационной системы.

В настоящем докладе будут рассмотрены методы и средства обеспечения информационной безопасности, имеющиеся в системе «1С:Предприятие 8.1».

Администратор базы данных в системе «1С:Предприятие 8.1» может создать и затем редактировать список пользователей, которым разрешена работа с системой. При добавлении нового пользователя (первоначально список пользователей пуст) указывается следующие свойства создаваемой учетной записи (на вкладке «Основные») :

имя, под которым пользователь будет зарегистрирован в системе;
полное имя (целесообразно использовать это свойство для задания фамилии, имени и отчества, должности и названия подразделения сотрудника организации, в которой используется система);
признак аутентификации «1С:Предприятия» (при установке данного «флажка» при попытке входа пользователя в систему «1С:Предприятие» его идентификация и аутентификация будут производиться средствами самой системы);
пароль пользователя, ввод которого потребуется для его идентификации средствами системы «1С:Предприятие»:
подтверждение пароля пользователя (требуется для исключения возможности ошибки при вводе пароля, т.к. символы пароля при вводе заменяются символами *);
признак запрещения пользователю изменять свой пароль при его аутентификации средствами «1С:Предприятие»;
признак отображения имени пользователя в списке при попытке входа в систему и его аутентификации средствами «1С:Предприятие»;
признак аутентификации Windows (при включении этого «Флажка» при попытке входа пользователя в систему «1С:Предприятие» будет определено имя, под которым выполняется сеанс работы с операционной системой Microsoft Windows, и в списке пользователей системы «1Спредприятие» ищется имя, которому соответствует имя «текущего» пользователя Windows);
имя пользователя операционной системы Windows, с которым связан данный пользователь системы «1С:Предприятие» при использовании аутентификации средствами операционной системы Windows (имя может быть задано в формате \\имя домена\имя учетной записи пользователя или выбрано с помощью соответствующей кнопки из списка локальных и глобальных учетных записей, известных на данном компьютере ).

Администратор базы данных может с помощью настроек параметров информационной базы установить минимальную длину паролей пользователей системы (если установлен «флажок» «Проверка сложности паролей пользователей», то минимальная длина паролей не может быть меньше 7 символов) и потребовать, чтобы пароли пользователей удовлетворяли условиям сложности, соответствующим требованиям к сложности паролей пользователей Windows (дополнительно пароль не должен являться последовательностью символов).

Наиболее безопасным способом аутентификации пользователей при их входе в систему «1С:Предприятие» будет объединение аутентификации средствами «1С:Предприятие» и средствами Windows. При этом целесообразно снятие флажка «Показывать в списке выбора» в группе свойств аутентификации «1С:Предприятие», а в параметрах безопасности Windows включить требования минимальной длины и сложности паролей, ограничения их максимального срока действия, неповторяемости паролей и их минимального срока действия и установить пороговое значение счетчика неудачных попыток входа в Windows.

Для принудительного отображения диалога аутентификации пользователя средствами «1С:Предприятие» (если включен «флажок» аутентификации Windows) необходимо использовать при запуске «1С:Предприятия» параметр командной строки /WA+ .

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

Роль в системе «1С:Предприятие» представляет собой набор прав доступа к различным объектам базы данных. Обычно роли создаются для отдельных должностных обязанностей, а каждому пользователю системы может быть назначена одна или несколько ролей. Если пользователю назначены несколько ролей, то предоставление доступа ему к объекту базы данных будет произведено следующим образом :

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

Для создания и редактирования ролей используется конфигуратор системы «1С:Предприятие». В процессе создания конфигурации создается набор типовых ролей, которые затем могут быть отредактированы.

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

В системе «1С:Предприятие» различают два типа прав - основные и интерактивные. Основные права проверяются при любом обращении к объектам информационной системы. Проверка интерактивных прав производится при выполнении интерактивных операций (например, просмотре и редактировании данных в форме).

Система «1С:Предриятие» допускает проверку прав доступа средствами встроенного языка. Например, при добавлении новых команд к форме разработчик должен дополнительно предусмотреть проверку наличия у пользователя соответствующих интерактивных прав.

При редактировании роли необходимо учитывать наследование (иерархию) прав: при отмене «родительского» («старшего») права отменяются и его «дочерние» («младшие») права, а при установке «дочернего» права устанавливается и его «родительское» право. Например, при отмене права «Просмотр» отменяется и право «Редактирование» соответствующего объекта.

С помощью флажка «Устанавливать права для новых объектов» можно обеспечить для редактируемой роли автоматическую установку прав доступа к новым (добавляемым впоследствии) объектам конфигурации.

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

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

Для удобства администрирования в системе «1С:Предприятие» предусмотрено окно просмотра и редактирования всех ролей, созданных в данной конфигурации. Если для некоторой роли необходимо отменить или установить все права доступа к выбранному объекту, то можно использовать флажок в строке «Все права» для столбца с именем редактируемой роли. Если для некоторого права доступа необходимо отменить или установить его во всех ролях, то можно использовать флажок в строке с именем соответствующего права для столбца «Все роли».

Для разграничения доступа к объектам базы данных на уровне отдельных полей и записей в системе «1С:Предприятие» предусмотрен механизм ограничения доступа к данным (использования прав на чтение, добавление, изменение и удаление этих объектов). Для права чтения возможна установка нескольких ограничений на доступ, а для остальных указанных прав - только одного ограничения.

Для каждого ограничения доступа к данным по праву чтения возможен выбор поля, по значению которого будет проверяться условие ограничения доступа, или указание «Прочие поля», что обеспечит проверку выполнения условия ля каждого поля.

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

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

После определения структуры главного меню в создаваемый интерфейс могут быть добавлены одна или несколько панелей инструментов. Эти панели могут быть расположены вверху, внизу, слева и справа в окне программы «1С:Предприятие».

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

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

Литература

Радченко М.Г. «1С:Предприятие 8.1. Практическое пособие разработчика. Примеры и типовые приемы. М.: ООО «1С-Паблишинг», СПб: Питер, 2007.
1С:Предприятие 8.1. Конфигурирование и администрирование. М.: Фирма «1С», 2007.

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

Введение

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С, она встречается во многих серверных продуктах большинства вендоров. Лишь в последние годы внимание к этим проблемам значительно возросло.
Недостаточно высокая средняя квалификация разработчиков и администраторов систем, доставшаяся в наследство от предыдущей версии.

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

Среди продуктов сходной направленности и целей использования это одно из самых молодых решений. Функциональность платформы более-менее устоялась менее года назад. При этом каждый релиз платформы, начиная в 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С:Предприятия 8.0
Обновление 1С:Предприятия 8.0 пользователями Microsoft Windows без прав администратора
Редактирование списка пользователей от лица пользователя, не имеющего административных прав
Настройка параметров брандмауэра Windows XP SP2 для работы SQL Server 2000 и SQL Server Desktop Engine (MSDE)
Настройка параметров COM+ Windows XP SP2 для работы сервера 1С:Предприятия 8.0
Настройка параметров брандмауэра Windows XP SP2 для работы сервера 1С:Предприятия 8.0
Настройка параметров брандмауэра Windows XP SP2 для работы HASP License Manager
Создание резервной копии информационной базы средствами SQL Server 2000
Вопросы установки и настройки 1C:Предприятия 8.0 в варианте "клиент-сервер" (одна из важнейших статей)
Особенности настройки Windows Server 2003 при установке сервера 1С:Предприятия 8.0
Регулирование доступа пользователей к информационной базе в клиент-серверном варианте (одна из важнейших статей)
Сервер 1С:Предприятия и SQL-сервер
Детализированная процедура установки 1С:Предприятия 8.0 в варианте "клиент-сервер" (одна из важнейших статей)
Использование встроенного языка на сервере 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С, но позволим себе сделать некоторые предварительные выводы. Конечно, идеальной данную платформу назвать нельзя – в ней, как и во многих других есть свои проблемы организации защищённой системы. Но это ни в коем случае не означает, что эти проблемы нельзя обойти, наоборот, почти все недостатки могут быть ликвидированы при правильной разработке, внедрении и использовании системы. Большинство проблем возникает из-за недостаточной проработки конкретного прикладного решения и среды его выполнения. Например, типовые решения без внесения значительных изменений просто не предполагают создание защищённой в достаточной мере системы.

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

УПРАВЛЕНИЕ ИНФОРМАЦИОННОЙ БАЗОЙ (ИБ)

Написать эту статью меня заставили 3 обстоятельства: общение со знакомыми бухгалтерами, статья главного бухгалтера, сборник анекдотов.

Моя знакомая работает главным бухгалтером и хорошо владеет 1С. Но недавно она перешла в новую организацию, где нет специалиста по информационным технологиям (ИТ) и стала задавать мне вопросы типа «Хочу работать в программе дома, как ее перенести на домашний компьютер?».

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

Во-вторых, запомнилась не так давно опубликованная статья «Зачем бухгалтеру Инфостарт?» . Автор Алла (bux 2).

Третье обстоятельство - сборник далеко не новых анекдотов «Инструкция для бухгалтерш по общению с программистом 1с» . На самом деле эти истории анекдотами можно назвать с большой натяжкой, это реальные истории каждого специалиста ИТ, связанного с бухгалтерией.

Если внимательно проанализировать эти анекдоты, то невольно приходишь к выводу, что конфликт происходит в пограничной сфере ответственности, которая не закреплена не за прикладным пользователем, ни за специалистом ИТ.

Сейчас на сайте «Инфостарт» зарегистрировано более 80000 пользователей. Маловероятно, что это все программисты 1С, скорее всего это «продвинутые» пользователи, у которых возникли проблемы при эксплуатации систем 1С.

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

Программисты 1С, которые самовлюбленно занимаются соревнованием в рейтинге
«Продвинутые» пользователи, которые ищут более совершенный инструментарий для работы с 1С
Новички, которые столкнулись с проблемами при эксплуатации 1С и ищут ответы на вопрос «Что делать?»

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

Если проанализировать наиболее «рейтинговые» статьи, то видно, что успехом пользуются довольно простые статьи по общим вопросам управления ИБ. Эти вопросы понятны специалистам ИТ, но для прикладных пользователей 1С являются чуть ли не откровением.

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

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

Типичное малое предприятие. Пользователи 1С: директор; бухгалтер, он же главный; секретарь, она же начальник ОК; несколько менеджеров (почему-то так называют специалистов по продаже).

Каждый пользователь «ведет» свою часть ИБ, а за всю базу в целом никто не отвечает. И когда возникают проблемы, спросить нес кого. Как у Райкина «Я лично пришивал пуговицы. К пуговицам вопросы есть? Нет, пришиты насмерть, не оторвешь!». А в целом за костюмчик никто не отвечает.

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

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

Системныйадминистратор с гневом отверг предложение, программист 1С гордо заявил, что он «кодирует», а не разгребает мусор за юзерами. Короче, на обычном предприятии нет специалиста, который отвечает за целостность информации в ИБ. Эту должность определить сложно, условно ее можно назвать что-то типа «Управляющий ИБ».

Эти функции иные, чем у администратора. Фирма 1С дает следующее определение задачам администрирования:

Установка и обновление системы
Ведение списка пользователей
Настройка прав доступа на основе механизма ролей
Мониторинг действий пользователей и системных событий
Резервное копирование
Тестирование и исправление информационной базы
Установка региональных настроек
Обновление конфигураций
Загрузка и выгрузка информационной базы данных в файл
Ведение и настройка журнала регистрации

Собственно говоря, этому посвящена глава «Администрирование» в документации 1С «Конфигурирование и администрирование».

Реально этих задач администрирования недостаточно для бесперебойной работы базы данных. Необходимы более широкие и разнообразные действия для «правильного» функционирования БД. «Управлением базой данных» гораздо шире понятия «администрирование».

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

В целом функции управления ИБ сводятся к тому, чтобы ИБ была «правильной».Проблемы «правильности» БД существовали всегда.

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

В ней не должно быть помеченных к удалению объектов. Все помеченные объекты должны удаляться
В базе данные не должно быть непроведенных документов
При перепроведении документов за любой период результаты не должны изменяться

Управление базой данных и должно приводить к этим результатам. Для бесперебойной работы с базой данных необходимо в стандартных конфигурациях 1С выполнять следующие действия (на примере ЗУП):

1. Резервное копирование
  - Копии всех БД необходимо делать ежедневно в конце каждого дня. При этом можно «затирать» копии предыдущего дня;
  - Копии БД необходимо перед обновлением. Желательно эти копии сохранять под уникальными именами
  - В обязательном порядке необходимо сохранить копии БД после закрытия месяца, также под уникальными именами.

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

1. Еженедельно проверять справочники на наличие дубликатов. При возникновении дубликатов - удалять их. Как удалять дубликаты
2. Еженедельно удалять помеченные к удалению объекты. Если объекты не удаляются, значит, на эти объекты есть ссылки. Необходимо выяснить, кто и почему пометил их на удаление. При необходимости эти объекты необходимо восстановить. Удаление можно производить с помощью универсальных обработок //сайт/blogs/1313/ Перед регламентной отчетностью - Технологический контроль
3. Экспресс-анализ БД //сайт/public/21332/
4. В конце месяца после закрытия месяца запретить доступ к данным

Может быть посоветуете что-нибудь из своего опыта?