Всем привет! Меня зовут Дима, и последние пару лет я работаю в качестве бизнес-партнёра по информационной безопасности в Ozon Tech. До этого успел на протяжении почти 10 лет поработать в банке и разного рода финтехах на позициях от стажёра и инженера по информационной безопасности до бизнес-партнёра.
Продукты 1С так или иначе на разных этапах карьерного пути бегло попадались в моём поле зрения, и в какой-то момент захотелось собрать воедино хотя бы часть всего того неочевидного, с чем мне уже довелось столкнуться там в контексте информационной безопасности.

Коротко о важном

• Читая статью, важно помнить — любая внедряемая система требует необходимости уметь её «готовить», и продукт 1С не исключение.

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

• В статье не будет охватываться раздел пентеста платформы 1С, а также связанной с этим эксплуатации уязвимостей — эта тематика не нова, и на просторах «Хабра» (и не только) уже давно можно найти отличные публикации.

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

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

Адаптируемся к новой реальности

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

Говоря об отечественных программных продуктах для бизнеса, мало кому, пожалуй, с ходу придёт на ум что-то, кроме «1С:Предприятие». Вполне логично, ведь данный программный продукт представляет собой почти классическое клиент-серверное приложение с базой. Это довольно многофункциональный комбайн/конструктор (да называйте как угодно), позволяющий сейчас почти любому бизнесу реализовать в том или ином виде необходимый процесс (с доработками или прямо из коробки — уже не суть важно).

Краткий ликбез

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

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

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

2. Конфигурация — прикладное решение, разработанное на языке 1С для решения конкретных задач. Именно конфигурация создаёт различия между теми же «1С:Управление торговлей» и «1С:Зарплата и управление персоналом». Она даёт возможность использовать их в разных сценариях. Конфигурации, разработанные непосредственно 1С, именуются как типовые. *! Закинем тут первый якорь на будущее: при должных знаниях и умениях конфигурации можно редактировать или вообще создавать с нуля, кастомизируя продукт под свои нужды по типу конструктора.

3. Информационная база — место хранения данных, созданное на основе указанных в конфигурации установок. Благодаря платформе 1С представляет собой логически целостную систему. *! А тут закинем сразу же второй якорь, тоже на будущее: информационная база может быть представлена как файловая, так и как клиент-серверная.

4. Конфигуратор — встроенная в платформу 1С среда разработки. Можно сказать, что это IDE (интегрированная среда разработки).

5. Пользовательский интерфейс — проще говоря, способы взаимодействия пользователя системой:
   a. Толстый клиент. Основная часть данных обрабатывается локально у пользователя на компьютере. Подключение осуществляется напрямую к кластеру серверов по протоколу TCP/IP или файловой базе; требует установки.
   b. Тонкий клиент. Вся работа с данными осуществляется удалённо на сервере. Подключение осуществляется двумя способами: напрямую к кластеру серверов по протоколу TCP/IP либо же сначала по http/https к веб-серверу и только затем к кластеру серверов; тоже требует установки.
   c. Веб-клиент. Вся работа с данными осуществляется удалённо на сервере. Подключение осуществляется сначала по http/https к веб-серверу и только затем к кластеру серверов; не требует установки.
   d. Мобильный клиент. Аналог тонкого клиента, но только уже для мобильных устройств.

Реальность наступила

Есть внедрённая платформа «1С:Предприятие» с разнообразными вариациями конфигураций: бизнес как-то когда-то выстроил свои процессы вокруг этой платформы. Этап с базовым харденингом вроде даже был сделан (само собой, это утверждение необходимо подвергнуть сомнению и перепроверять). А что дальше: наступила безопасность?

Реальность порождает вопросы

1. Бизнес динамичен, а раз система сейчас обслуживает какие-то бизнес-процессы, то есть все шансы, что, когда этот процесс поменяется или появится новый, систему потребуется адаптировать = дорабатывать. Доработка системы непременно порождает вопросы:
   • А как система дорабатывается под нужды бизнеса?
   • Разработка внешняя или внутренняя?
   • Что из себя представляет цикл разработки?
   • Какие инструменты разработки используются?

2. Любая бизнес-система почти всегда не существует в вакууме и в рамках своей жизнедеятельности обменивается данными с другими системами. Логично было бы заинтересоваться:
   • А с чем система интегрируется?
   • Есть ли какие-то внешние интеграции?
   • С помощью каких каналов происходит обмен между системами?
   • Что и зачем передается/получается в рамках обменов?

3. Любая бизнес-система почти всегда подразумевает к ней доступ пользователей, а там, где есть доступ, должны быть определены и следующие правила:
   • Как и откуда можно получить доступ к системе?
   • Каким образом пользователи получают доступ в систему?
   • А флоу получения доступа к системе единый для всех пользователей?

4. Получив доступ, какие бизнес-процессы осуществляются: что и зачем в системе делают пользователи? Зачастую самые каверзные вопросы могут быть примерно такими:
   • А все ли обмены данными покрываются интеграциями или же есть ручные процессы?
   • А есть ли какие-то бизнес-процессы, не предусмотренные изначально системой, но выполняемые в ней «руками» по запросу пользователей на периодической основе?

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

Время «отличительных» историй

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

Погружаемся — стадии страха безопасника:

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

Испуг
Вся разработка ведётся с использованием стандартного локального конфигуратора 1С со всеми его ограничениями вроде отсутствия интегрированных инструментов контроля версий, полноценного CI/CD и прочих инструментов, к которым многие уже так привыкли.

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

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

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

На какие мысли может натолкнуть такой процесс:

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

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

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

• На случай невозможности разрыва связности конфигурации и данных предусмотреть один из вариантов:

  • Обрезка/минимизация всех реальных критичных данных в копии базы. Но тут надо обязательно быть внимательными и учесть, что этот способ может не затронуть документы (их придётся отдельно довольно точечно и аккуратно вычищать, чтобы не поломать никакие внутренние взаимосвязи).

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

  • Генерация синтетики на основе реальных данных — инструментарий в виде постклон-скриптов с заложенной логикой генерации случайных данных по формату входных; но также придётся вычищать документы.

  • Использовать golden data set для заливки данных в базу — сложный и дорогой в поддержке способ, но при этом самый действенный в условиях интеграций и необходимости консистентности данных в рамках всего тестового контура.

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

Бонус — всё везде и сразу

С процессом разработки разобрались. Поправили его. Система функционирует. Что может «выстрелить в колено» дальше?

Интеграции

• DCOM — прямое подключение баз 1С между собой. По возможности стоит избегать этого способа, так как по факту этот механизм несёт в себе риски того, что позволяет создавать/выполнять/уничтожать на удалённом хосте объекты, зачастую из-под учётных записей с довольно широкими правами на уровне системы.

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

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

• Файловые шары/ftp/sftp позволяет читать/писать в/из указанных источников файлы с последующей их обработкой на стороне 1С.

• Самописные коннекторы — простор для фантазии, и заранее сложно даже сказать, что там может быть.

А если что-то из интеграций вышло наружу — в Интернет? Данные только отдаются или извне что-то загружается: откуда/зачем/как и, в общем-то, каким образом эти загрузки проверяются?

Процессы работы пользователей

Не стоит также забывать и про довольно классические, но не всегда очевидные вещи:

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

• Выгрузки. Кто/что/как/куда/зачем может выгрузить? А есть ли контроль того, куда/что/кем выгружается?

• Загрузки. Кто/что/как/куда/зачем может загрузить? Есть ли какая-то проверка загружаемых файлов?

• Внешние обработки. Включены ли они? Для чего? У кого? Как контролируются? Кто имеет возможность их загружать/изменять/запускать и как вообще они попадают в систему? А используются ли какие-то внешние обработки от сторонних партнёров (ЭДО, например), кто/как их поддерживает/проверяет?

Вместо выводов

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