Как создать бронебойную систему кибербезопасности на базе 1С

Данный документ разработан экспертами ГК ИНТАЛЕВ для специалистов в области корпоративных информационных систем и кибербезопасности с целью проверки и помощи в доработке мер по созданию действительно безопасной информационной системы на базе 1С и «ИНТАЛЕВ: Корпоративный менеджмент».

Документ разработан для специалистов в области корпоративных информационных систем и кибербезопасности с целью проверки и помощи в доработке мер по созданию действительно безопасной информационной системы на базе 1С и КМ. 

Задачами системы кибербезопасности являются:

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

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

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

Все настройки безопасности начинаются с базового системного уровня доступа к серверам и заканчиваются “тонкими” настройками доступа к разным элементам данных.

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

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

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

 

Перечислим основные шаги проверки и доработки кибербезопасности в виде “чеклиста”:

 

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

  • Доступ к учетной записи администратора СУБД (базы данных). Необходимо закрыть всем, кроме системного администратора (или администратора базы данных в случае выделенного специалиста). Для создаваемых баз следует выделять своих локальных пользователей с минимально необходимыми правами для работы с ними из 1С, а не работать из приложений 1С с разными БД под одним логином (тем более не использовать логин системного администратора).

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

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

  • Доступ к администрированию служб MS IIS, в случае использования WEB-служб. Необходимо закрыть всем, кроме системного администратора. Кроме того, сайт рекомендуется использовать с протоколом SSL (https://) и с проверкой подлинности обычной, windows или другой, отличной от анонимной.

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

Также полезно использовать виртуальные системы для изолированной работы пользователей в терминальной среде.

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

Требования к паролям для входа в 1С должны соответствовать общекорпоративной политики и быть достаточно высокими.

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

  • Доступ в 1С:Конфигуратор (и любой доступ к действиям с конфигурацией). Необходимо закрыть всем права администрирования системы, администрирования данных и обновления конфигураций, кроме специалиста, занятого поддержкой/обновлением 1С. Также следует убедиться, что к подобным административным функциям, выполняемым обычно через 1С:Конфигуратор, отсутствует доступ и в режиме 1С:Предприятие (зависит от реализованной функциональности в конфигурации и настроек ролей. Например, доступ к выгрузке/загрузке конфигурации 1С и её применению к базе данных и т.д). Поскольку зачастую доработки в 1С неизбежны, при выполнении изменений в конфигурации следует удостовериться, что такие изменения не меняют задуманную разработчиками логику работы, и в т.ч. не изменяют правила работы системы безопасности в конфигурации. Мы не рекомендуем вмешиваться в логику работы системы разграничения прав доступа и всего что с ней связано.

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

  • Доступ в 1С:Предприятие с одним из данных прав:

    • Запуск любых внешних обработок и отчетов. И в целом открытие любых внешних файлов из 1С:Предприятие.

    • Запуск отчетов и обработок в самой конфигурации, в которых на программном уровне могут обходиться правила разграничения доступа к данным. В частности, разные “универсальные” отчеты, позволяющие просмотреть все данные выбранного объекта (например, универсальный просмотр регистров), и “универсальные” обработки добавления/редактирования/удаления данных (например, замена объектов). В особых случаях (особенно когда конфигурация дорабатывается) подобные функции могут быть реализованы также в формах справочников, документов и других объектов.

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

    • Открытие пункта меню “Все функции”. Прочие функции, которые не нужны для рядовых пользователей.

    • Запуск функций из пункта меню Стандартные: управление итогами, проведение и изменение последовательности документов, установка и использование расширений, управление полнотекстовым поиском и пр.

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

  • Доступ по ролям (к разделам конфигурации). Следует настроить для пользователей такие роли, чтобы они могли видеть и выполнять только необходимые им функции. Это касается предустановленных в конфигурации ролей как для КМ, так и для конфигурации, с которой объединен продукт. В частности:

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

    • “управленческим” пользователям следует сократить или полностью убрать доступ к бухгалтерским, кадровым и иным данным из “типовой” конфигурации (с учетом особенностей “типовой” конфигурации может требоваться базовая или иная роль в ней для запуска объединенной конфигурации).

    • доступ к настройке бизнес-модели в КМ следует закрыть всем, кроме специалистов, ответственных за настройку и развитие модели.

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

  • Доступ к настройке администрирования прав к разным объектам в КМ. Следует закрыть всем, кроме специалистов, ответственных за настройку прав доступа в КМ. Помимо указания роли “Администратор системы безопасности”, для гибкого разграничения настройки прав к разным элементам в КМ можно настроить разных администраторов безопасности для разных объектов, т.е. определить круг администраторов для каждого объекта, кто будет иметь право регулировать доступ других пользователей именно к данному объекту.

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

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

Доступ к объекту может регулироваться впрямую через указание прав на него для каждой роли в КМ (прямая безопасность), а также доступ может зависеть от доступа к другим объектам, которые используются в качестве реквизита исходного объекта (производная или косвенная безопасность, с учетом всех правил применения). В случае косвенной безопасности можно полностью скрывать в списках объекты, у которых есть недоступные реквизиты, а также в отчетах, можно скрывать проводки с недоступным значением, а также записи в других управленческих регистрах.

Для запуска и доступа к бизнес-процессам используется также иерархия пользователей.

Определяется порядок закрытия доступа на изменение к данным по сценариям и периодам.

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

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

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

Средствами КМ, помимо разграничения доступа к его объектам (как описано в предыдущем пункте), можно гибко разграничивать доступ к видимым реквизитам в списке, а также скрывать реквизиты ограниченного доступа в отчетах.

Например, для недопущения утечек информации о персональной информации физических лиц, в их списках может выводиться только СНИЛС или иной код клиента, что отдельно представляет мало ценности, даже если будет скопировано недоброжелателем. А вот персональная данная о клиенте (ФИО, телефон и т.д.) выводится только в его карточке. В самом списке (и/или отчете по нему) по нужным полям организуется возможность поиска по ключевым полям (скажем, телефон или ФИО), однако просмотр всех детальных реквизитов возможен только в карточке, а не списке. Таким образом, чтобы получить доступ к персональной информации о конкретном клиенте, пользователю необходимо будет открыть нужную карточку — а это может быть или полностью запрещено, или ограничено только доступными ему клиентами благодаря настройкам безопасности из предыдущего пункта. Кроме того, даже в случае полного доступа ко всему списку клиентов, реально просмотреть их данные будет возможно только при открытии карточки, что затрудняет утечку данных о множестве клиентов. И даже в случае доступности информации о физлицах в отчетах, пользователь не сможет вывести там недоступные ему реквизиты.

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

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

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

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

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

  • Доступ к печати и копированию в буфер. Этот пункт является развитием предыдущего и касается распространенной возможности утечки данных. Для ограничения доступа к печати данных в КМ настраиваются отчеты или доступные макеты, общие или в зависимости от статуса объекта (а доступ к статусам, и значит доступным их печатным формам настраивается в соответствии с предыдущим пунктом).

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

  • Доступ к данным в КМ из внешних систем. В случае, если в организации используются другие программы, которые имеют доступ к данным из 1С (КМ), то следует аналогично и ограничить доступ пользователям к этим приложениям и внутри них. Это могут быть другие приложения КМ и 1С, средства бизнес-аналитики данных и т.д. Каналы обмена данными с ними также должны быть надежно защищены от утечек и вмешательства.

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

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

 

Типовой шаблон распределения прав в зависимости от роли пользователя

 

Роль

Доступ в 1С:Конфигуратор

Доступ к настройке прав/ролей в 1С:Предприятие

Доступ к настройке разграничения прав доступа к элементам в КМ

Доступ к настройке модели КМ

Специалист по поддержке 1С

+

Администратор прав доступа

+

Только на разрешенные для администрирования объекты

+

Только на разрешенные для администрирования объекты

Администратор Архива

Администратор бизнес-процессов

Настройщик модели

+

Обычный пользователь

 

 

Бизнес-процессы на страже кибербезопасности

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

Вот примерный перечень таких бизнес-процессов:

  1. Создание нового пользователя.

  2. Перевод пользователя с должности на должность.

  3. Удаление пользователя.

  4. Заявка на изменение прав доступа для роли/пользователя.

  5. Изменение бизнес-логики (заявки на новые требования, изменения требований).

  6. Журнал обращений (заявки с вопросами и проблемами работы информационной системы).

  7. Оповещение/обучение пользователей о новом функционале.

  8. Согласование и оповещение о перерывах и сервисно-профилактических работах в информационной базе.

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

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

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

22 Comments

  1. LexSeIch

    Грамотно расписано. На практике будет тяжелее настраивать. Есть еще ограничения физического доступа к оборудованию серверов и сети. Хранение и утилизация бэкапов. Уничтожение данных при замене оборудования…

    Reply
  2. Synoecium

    бронебойная это которая броню пробивает? 🙂

    Reply
  3. SaschaL

    Написано мощно, но как на практике это реализовать???

    тут много подводных камней в жизни найдется, хотя многое из написанного не лишено здравого смысла. Явно это где то работает уже.

    Reply
  4. Gilev.Vyacheslav
    всем, кроме системного администратора.

    начну с простого вопроса: если я не доверяю (как руководитель) админу в удаленном офисе, как мне обеспечить безопасность и от него тоже?

    Reply
  5. avgyr77

    Сисадимну это не нужно . все штатными средствами делается .без разных Кулибиных

    Reply
  6. vano-ekt

    (4) посадить на цепь, отобрать все гаджеты

    Reply
  7. vano-ekt

    а потом хитропопый менеджер розничной точки берет, подменяет файл обмена РБД и через Выполнить() делает на центральном сервере, что захочет

    Reply
  8. lefthander

    (4)Уволить и принять того кому доверяете. Или все делать самому. 🙂

    Reply
  9. rozer

    (7) вроде как давно БСП шный обмен правила загрузки используются свои а не те которые в файле … вроде как для безопасности от такого и сделали

    Reply
  10. herfis

    Тю, надеялся на сисадминскую магию, а тут какая-то лабуда одинэсная 🙂

    В тему:

    — Шеф, у нас дыра в безопасности!

    — Ну хоть что-то у нас в безопасности…

    Reply
  11. mkalimulin

    (2) Нет. Это система с пробитой в нужных местах броней.

    Reply
  12. protexprotex

    (4) Уволить админа 🙂

    Reply
  13. protexprotex

    Я тут все над своим админом год измывался — он мне не давал по rdp запускать сеанс с рабочим столом wind-ы для 1С — ки — так я написал обработку по запуску explorer — и рабочий стол запускался. А он, бедный, все пытался понять как это? 🙂

    Reply
  14. Арчибальд

    Создать можно что угодно. Надо-то, чтоб работало… Процитирую себя (О защите…):

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

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

    Reply
  15. alex_sh2008

    (4)Для таких целей еще в 20 веке придумали делегирование прав доступа, когда в каждом филиале у каждого админа есть свои права доступа ко всей сетевой инфраструктуры.

    Reply
  16. Арчибальд

    (0) Черт побери, сразу не обратил внимания. Это ж не исследование, а просто инструкция к своему продукту. Не айс.

    Reply
  17. Gilev.Vyacheslav

    (4) я так понимаю у автора в методичке нет пункта на этот случай )))

    но мы не гордые, время есть, подождем ответ

    Reply
  18. Gilev.Vyacheslav

    (15) и чо?

    Reply
  19. teller

    (1) что тут особенного, типовые решения , посмотри например pcidss

    Reply
  20. teller

    (4)

    если я не доверяю (как руководитель) админу в удаленном офисе, как мне обеспечить безопасность и от него тоже?

    — системного администратора контролируют офицеры безопасности (Security Manager) 🙂

    статья написана одним из них , наверно инталев отправлял на курсы безопасников ( чувствуется шаблон )

    Reply
  21. PerlAmutor

    (7)

    через Выполнить()

    Или все-таки через «Вычислить()»?

    Reply
  22. Светлый ум

    +1 взяли на вооружен

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *