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

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

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

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

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

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

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

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

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

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

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