Защита сервера 1С начинается с сетевых правил и ролей

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

С чего начинать аудит доступа к серверу 1С

Я начинаю не с установки «средств защиты», а с карты доступа: где находятся сервер кластера, рабочие места, веб-сервер и база данных; какие группы пользователей подключаются; кто администрирует платформу и кто отвечает за конфигурацию. Для небольшой организации эта схема помещается на одном листе. На нём отмечаю источник каждого соединения и его назначение. Если никто не может объяснить, зачем правило межсетевого экрана существует, его нельзя автоматически считать нужным или безопасным: сначала выясняем владельца и проверяем зависимые подключения.

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

• Зафиксировать узлы и назначения соединений.
• Сверить пользователей и административные учётные записи.
• Проверить каждое внешнее правило доступа.

Какие порты использует кластер 1С и кому их открывать

В стандартной конфигурации платформы используются TCP-порт 1540 для агента сервера, 1541 для менеджера кластера и диапазон 1560–1591 для рабочих процессов. Это не означает, что каждый порт надо выставить в интернет или открыть для всей офисной сети. Реальная схема зависит от того, где работают клиент, сервер кластера и процессы 1С, а также от настроек конкретного экземпляра. Стандартный диапазон — отправная точка для проверки, не готовый универсальный набор правил. Если порт или диапазон меняли, сверяйте правила с конфигурацией работающего сервера и сетевой схемой.

Я задаю для каждого разрешения три вопроса: от какого источника идёт соединение, к какому узлу оно направлено и какому компоненту нужно. Затем оставляю только подтверждённые маршруты между нужными сегментами. Административный доступ выделяю отдельно от клиентского; правила фиксирую так, чтобы следующий специалист понимал их смысл. Диапазон рабочих процессов нельзя подменять одним номером без проверки: клиент может обращаться не только к менеджеру кластера. И не меняйте порты на работающем сервере в надежде «спрятать» его: документация платформы описывает для смены портов создание нового экземпляра и перенос баз, а не горячую правку параметров.

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

• 1540/TCP — агент сервера.
• 1541/TCP — менеджер кластера.
• 1560–1591/TCP — рабочие процессы по умолчанию.
• Разрешайте соединения только тем источникам, которым они требуются.

Как разделить учётные записи и права администратора

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

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

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

Как назначать роли и ограничивать доступ к данным

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

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

• Составьте матрицу «сотрудник — задача — нужное право».
• Проверьте ограничения на записи и поля, если они используются.
• Тестируйте каждое изменение под отдельной учётной записью.

Как защитить веб-публикацию и интеграции 1С

Веб-публикация — отдельная точка входа, и её нужно проверять независимо от портов кластера. Официальная документация 1С не рекомендует HTTP для коммерческой базы, доступной через интернет, и настоятельно рекомендует HTTPS. Сертификат TLS устанавливают и привязывают на веб-сервере, после чего проверяют имя узла, срок действия и цепочку доверия на клиентских устройствах. Не называйте сертификат «защитой веб-сервиса»: он шифрует транспорт между клиентом и веб-сервером, но сам по себе не выдаёт и не ограничивает права пользователя.

Дальше я проверяю, какие публикации действительно нужны, кому они доступны, какая аутентификация используется и какие методы интеграции включены. Разрешения на каталог публикации и модули расширения веб-сервера должны соответствовать выбранной платформе и способу размещения; переносить инструкцию для IIS на Apache или наоборот нельзя. Ограничение источников по IP применяйте только если адреса интеграции стабильны и это не ломает штатный сценарий. Для внешнего сервиса нужны отдельные учётные данные и минимально необходимые операции. После изменения публикации проверьте вход, отказ в доступе постороннему пользователю и работу каждой интеграции; одна зелёная страница в браузере ничего не говорит о полноте проверки. Для интеграции я отдельно записываю владельца, назначение и способ отзыва учётных данных. Секреты нельзя хранить в тексте заявки или общем файле без контроля доступа. Когда меняется подрядчик или схема обмена, старую связку отключают после проверки зависимостей, а не оставляют «до следующего раза». Это небольшая дисциплина, зато через полгода не приходится гадать, какой забытый обмен всё ещё имеет доступ к данным.

• Инвентаризируйте опубликованные базы и интеграции.
• Для внешней веб-публикации настройте HTTPS с актуальным TLS-сертификатом.
• Проверьте права веб-сервера и доступ к каждому опубликованному ресурсу.

Что проверять после изменений и как не потерять базу

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

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

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

Частые вопросы