Настройка RLS в 1С:ERP 2026: ограничение прав, аудит и шифрование данных

Коротко: При консолидации данных в 1С:ERP 2026 ключевыми механизмами безопасности становятся RLS на уровне записей с динамическими ограничениями, расширенный журнал регистрации с фильтрацией по 30+ событиям, шифрование межфирменных потоков через TLS 1.3 и КриптоПро CSP 5.0, а также сегментация прав по организациям через профили групп доступа. Внедрение полного контура занимает 80–160 часов и снижает риски утечек на 70–85%.
RLS в 1С:ERP 2026 настраивают через профили групп доступа: список организаций пользователя хранят в индексированном регистре сведений, а условие в шаблоне ограничений пишут через «ВЫБРАТЬ РАЗРЕШЕННЫЕ» без глубокой вложенности подзапросов. Аудит собирают в журнале регистрации и выгружают наружу — в SIEM или лог-коллектор, чтобы записи нельзя было подчистить из базы. Внешние каналы (обмены, публикации, файловые выгрузки) закрывают TLS и сертифицированным криптопровайдером. Обязательный финальный шаг — прогон под тестовыми пользователями: чаще всего ограничения протекают в отчётах, навигационных ссылках и в коде с привилегированным режимом.
RLS в 1С:ERP 2026 включается через профили групп доступа: список доступных организаций хранят в регистре сведений с индексом по пользователю, а условие в шаблоне ограничений пишут через «ВЫБРАТЬ РАЗРЕШЕННЫЕ» с одним уровнем подзапроса. Аудит собирают в журнале регистрации и выгружают наружу — в SIEM или лог-коллектор, чтобы записи нельзя было подчистить изнутри базы. Обмены, публикации и файловые выгрузки закрывают TLS и сертифицированным криптопровайдером (КриптоПро CSP, ViPNet CSP). Готовую настройку обязательно прогоняют под тестовыми пользователями: отчёты, навигационные ссылки и привилегированный режим в доработках обходят RLS чаще всего.
Быстрый ответ — три контура защиты данных в 1С:ERP 2026:
- Ограничение прав (RLS) — динамические ограничения на уровне записей: пользователь видит только данные своей организации; настраивается через профили групп доступа.
- Аудит — расширенный журнал регистрации с фильтрацией по 30+ типам событий и выгрузкой в SIEM для контроля критичных операций.
- Шифрование — межфирменные потоки и файловые выгрузки закрываются TLS 1.3 и сертифицированным КриптоПро CSP 5.0.
Почему консолидация в 1С:ERP 2026 требует нового подхода к безопасности?
Современные холдинги объединяют в одной информационной базе 1С:ERP десятки юридических лиц, обособленных подразделений и обслуживающих компаний. По данным внутренних аудитов крупных внедрений, к 2026 году средний размер консолидированной базы вырос до 2,5–4 ТБ, а число активных пользователей в одном кластере достигает 800–1500 человек. Это создаёт принципиально новую модель угроз: утечка одного документа может скомпрометировать сразу несколько юридических лиц холдинга.
Регуляторное давление также усилилось. Требования ФЗ-152 «О персональных данных», приказ ФСТЭК №21 и постановление правительства №1119 теперь напрямую распространяются на учётные системы холдингов. При проверках Роскомнадзора в 2024–2025 годах основные претензии касались именно отсутствия разграничения доступа между организациями и неполного журналирования действий пользователей.
Какие риски возникают при объединении баз?
- Горизонтальное расширение доступа — бухгалтер дочерней компании видит платежи материнской структуры
- Утечка через выгрузки — типовые отчёты СКД позволяют выгрузить весь массив данных в Excel
- Компрометация служебных учёток — RPA-роботы и интеграции часто работают с правами «Полные права»
- Отсутствие следов — стандартный журнал регистрации фиксирует только базовые события
- Передача данных между серверами — межфирменные обмены идут в открытом виде
Как правильно настроить RLS при консолидации?
Row-Level Security (ограничение доступа на уровне записей) — фундамент безопасности в консолидированных базах. В 1С:ERP 2026 механизм RLS реализуется через профили групп доступа и условия в шаблонах. Главное правило: RLS должен быть многомерным, то есть учитывать не только организацию, но и подразделение, склад, контрагента, статью ДДС и проект.
Что изменилось в RLS в редакции 2026?
В новой редакции усовершенствован механизм функциональных опций для RLS — теперь можно динамически отключать ограничения для отдельных регламентных заданий без снижения общей защищённости. Также добавлена возможность кэширования значений ограничений на стороне сервера, что снизило накладные расходы RLS на производительность с 25–40% до 8–15%.
// Пример настройки RLS через шаблон для документа "РеализацияТоваровУслуг"
// Условие в шаблоне ограничений доступа
Процедура УстановитьУсловиеRLS(ПрофильГруппыДоступа) Экспорт
ТекстУсловия = "
|ВЫБРАТЬ РАЗРЕШЕННЫЕ
| РеализацияТоваровУслуг.Ссылка
|ИЗ
| Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
|ГДЕ
| РеализацияТоваровУслуг.Организация В
| (ВЫБРАТЬ ОрганизацииПользователя.Организация
| ИЗ РегистрСведений.ДоступныеОрганизацииПользователей КАК ОрганизацииПользователя
| ГДЕ ОрганизацииПользователя.Пользователь = &ТекущийПользователь)
| И ВЫБОР
| КОГДА &ОграничениеПоПодразделению
| ТОГДА РеализацияТоваровУслуг.Подразделение В (&ДоступныеПодразделения)
| ИНАЧЕ ИСТИНА
| КОНЕЦ";
ПрофильГруппыДоступа.УстановитьТекстУсловия(ТекстУсловия);
КонецПроцедурыКак избежать падения производительности?
Главная ошибка при внедрении RLS — добавление сложных подзапросов с соединениями по таблицам с миллионами записей. Рекомендации из практики внедрений:
- Используйте регистр сведений
ДоступныеОрганизацииПользователейс индексированием по полю «Пользователь» - Не вкладывайте более двух уровней подзапросов в условие RLS
- Применяйте функциональные опции для отключения RLS в фоновых заданиях обмена
- Кэшируйте список доступных организаций в параметрах сеанса
- Замеряйте время выполнения типовых отчётов до и после внедрения RLS
Что нового в журнале аудита 1С:ERP 2026?
Журнал регистрации в 2026 году получил серьёзное развитие. Теперь поддерживается экспорт в формате JSON для интеграции с SIEM-системами (MaxPatrol, Ankey SIEM, KUMA), фильтрация по 40+ типам событий и автоматическое архивирование с шифрованием. Размер журнала перестал быть «бутылочным горлышком» — реализована ротация и сжатие.
Какие события обязательно нужно журналировать?
| Категория | Событие | Критичность |
|---|---|---|
| Доступ | Вход/выход пользователя | Средняя |
| Доступ | Неудачные попытки входа (более 3) | Высокая |
| Данные | Изменение проведённых документов закрытых периодов | Критическая |
| Данные | Удаление помеченных объектов | Высокая |
| Конфигурация | Изменение прав пользователей | Критическая |
| Экспорт | Выгрузка отчётов с объёмом более 1000 строк | Высокая |
| Интеграция | Подключения через COM/HTTP/Web-сервисы | Средняя |
// Программная запись расширенного события в журнал аудита
Процедура ЗаписатьСобытиеАудита(ИмяСобытия, Уровень, Объект, ДополнительныеДанные = Неопределено)
ДанныеСобытия = Новый Структура;
ДанныеСобытия.Вставить("Пользователь", ПользователиИнформационнойБазы.ТекущийПользователь());
ДанныеСобытия.Вставить("КомпьютерКлиента", ПараметрыСеанса.КомпьютерПользователя);
ДанныеСобытия.Вставить("IPАдрес", ПараметрыСеанса.IPАдресКлиента);
ДанныеСобытия.Вставить("ВремяСобытия", ТекущаяУниверсальнаяДата());
Если ДополнительныеДанные <> Неопределено Тогда
ДанныеСобытия.Вставить("Контекст", ДополнительныеДанные);
КонецЕсли;
// Сериализация в JSON для совместимости с SIEM
ЗаписьJSON = Новый ЗаписьJSON;
ПараметрыJSON = Новый ПараметрыЗаписиJSON(ПереносСтрокJSON.Авто, Символы.Таб);
ЗаписьJSON.УстановитьСтроку(ПараметрыJSON);
ЗаписатьJSON(ЗаписьJSON, ДанныеСобытия);
КомментарийСобытия = ЗаписьJSON.Закрыть();
ЗаписьЖурналаРегистрации(
ИмяСобытия,
Уровень,
Объект.Метаданные(),
Объект,
КомментарийСобытия
);
КонецПроцедурыКак настроить интеграцию с SIEM?
Современный подход — не хранить журнал только внутри 1С, а передавать события в реальном времени во внешнюю систему мониторинга. Это решает три задачи: защита журнала от модификации администратором 1С, корреляция событий с другими системами (AD, межсетевой экран, СКУД), долгосрочное хранение (3–5 лет) без раздувания базы 1С.
Типовая схема интеграции: регламентное задание каждые 5 минут читает новые записи журнала через ВыгрузитьЖурналРегистрации(), преобразует в формат CEF или Syslog, отправляет на коллектор по TCP/TLS. Если требуется глубокая кастомизация механизма, имеет смысл привлечь специалистов для задач по 1С:ERP.
Как организовать шифрование межфирменных потоков?
При консолидации данных между базами разных юрлиц или между распределёнными узлами РИБ возникает проблема защиты канала. По умолчанию обмены через планы обмена, HTTP-сервисы или КД 3.0 передают данные в открытом виде. В 2026 году отраслевой стандарт — обязательное шифрование на двух уровнях: транспортном (TLS 1.3) и прикладном (XML Encryption или подпись через КриптоПро).
Какие протоколы использовать?
- TLS 1.3 — для всех HTTP/HTTPS-обменов между серверами 1С, обязательная проверка сертификатов
- КриптоПро CSP 5.0 — для подписи и шифрования по ГОСТ 34.10-2018 при обмене с госорганами и контрагентами
- VPN IPSec — для соединения территориально распределённых офисов
- SFTP — для файловых обменов между организациями холдинга
// Шифрование пакета обмена перед отправкой между организациями
Функция ЗашифроватьПакетОбмена(ДанныеXML, СертификатПолучателя)
МенеджерКриптографии = Новый МенеджерКриптографии("Infotecs Cryptographic Service Provider");
МенеджерКриптографии.АлгоритмШифрования = "ГОСТ Р 34.12-2015 Кузнечик";
ДвоичныеДанные = ПолучитьДвоичныеДанныеИзСтроки(ДанныеXML);
Попытка
ЗашифрованныеДанные = МенеджерКриптографии.Зашифровать(
ДвоичныеДанные,
СертификатПолучателя
);
Исключение
ЗаписьЖурналаРегистрации(
"Обмен.ШифрованиеПакета",
УровеньЖурналаРегистрации.Ошибка,
,
,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке())
);
ВызватьИсключение;
КонецПопытки;
Возврат Base64Строка(ЗашифрованныеДанные);
КонецФункцииКак защитить файловые выгрузки?
Отдельный класс рисков — экспорт данных в Excel и CSV. Пользователь с правом на чтение может выгрузить весь регистр накопления и унести его на флешке. Контрмеры:
- Запрет сохранения отчётов на локальный диск через настройку «Сохранение результата отчёта»
- Watermarking — наложение водяных знаков с ФИО пользователя и датой на печатные формы
- DLP-интеграция — передача метаданных выгрузок в систему предотвращения утечек
- Контроль объёма — алерт при выгрузке более 1000 строк за раз
- Шифрование файлов выгрузки сертификатом получателя
Какие практики работают в реальных проектах?
Кейс 1: Холдинг с 12 юрлицами
Производственный холдинг с консолидированной базой 1С:ERP 3,2 ТБ внедрил трёхуровневую модель доступа: матрица «организация × подразделение × роль». Использовали 47 профилей групп доступа вместо стандартных 18. Время отклика типовых отчётов выросло на 12%, но риск пересечения данных между юрлицами снизился до нуля. Аналогичный подход применим и для проектов 1С:Бухгалтерия на Кодерион при объединении нескольких юрлиц.
Кейс 2: Сеть из 80 филиалов
Розничная сеть с РИБ из 80 узлов перевела все обмены на HTTPS с двусторонней аутентификацией по сертификатам. Каждый филиал получил собственный сертификат с привязкой к коду. Попытки несанкционированного подключения (3–5 в месяц) теперь автоматически блокируются на уровне сервера приложений.
Кейс 3: Интеграция с банком
Компания с оборотом 8 млрд руб/год внедрила сквозное шифрование платежных поручений от момента создания в 1С до отправки в банк через DirectBank. Каждый документ подписывается двумя сертификатами (бухгалтер + директор), шифруется сертификатом банка, передаётся по TLS 1.3. Время на отправку платежей выросло с 3 до 7 минут, но риск подделки исключён.
Безопасность — это не разовый проект, а непрерывный процесс. RLS, аудит и шифрование должны пересматриваться раз в квартал вместе с изменениями оргструктуры холдинга.
Сколько стоит внедрить полный контур безопасности?
По данным проектов 2024–2025 годов, ориентировочные трудозатраты на внедрение комплексной защиты данных в консолидированной базе 1С:ERP:
| Этап | Часы | Стоимость (руб) |
|---|---|---|
| Аудит текущей модели прав | 20–40 | 60 000–160 000 |
| Проектирование матрицы доступа | 30–60 | 90 000–240 000 |
| Настройка RLS и профилей | 40–80 | 120 000–320 000 |
| Внедрение расширенного аудита | 20–40 | 60 000–160 000 |
| Интеграция с SIEM | 40–80 | 120 000–320 000 |
| Шифрование обменов | 30–60 | 90 000–240 000 |
| Тестирование и документация | 20–40 | 60 000–160 000 |
Итого: 200–400 часов работы с бюджетом 600 000 – 1 600 000 рублей в зависимости от сложности и количества организаций. Подобрать команду можно через найти разработчика 1С или разместить проект на фриланс 1С.
С чего начать защиту данных в 1С:ERP: чек-лист на 2026 год
Если полный контур безопасности данных в 1С:ERP ещё не выстроен, начните с шагов, которые дают максимальное снижение рисков при минимальных трудозатратах:
- Инвентаризация прав — выгрузите текущую матрицу ролей и профилей групп доступа, отметьте учётки с «Полными правами» (особенно RPA-роботов и интеграции).
- Базовый RLS по организациям — включите разграничение доступа между юрлицами: это закрывает самую частую претензию проверок.
- Журналирование критичных событий — настройте аудит входов, изменения прав, выгрузок и проведения документов на крупные суммы.
- Шифрование внешних каналов — переведите межфирменные обмены и публикации на TLS 1.3, подключите сертифицированный криптопровайдер.
- Регламент пересмотра — закрепите ежеквартальную ревизию матрицы прав и ежемесячный отчёт о неиспользуемых ролях.
Такой порядок закрывает большинство типовых нарушений уже в первые недели, не дожидаясь полного 80–160-часового внедрения.
Как проверить, что RLS действительно работает: прогон за один вечер
Настройка RLS в 1С:ERP 2026 заканчивается не сохранением профиля, а проверкой под тестовыми пользователями. Ограничения регулярно протекают там, где их не ждут: в отчётах, в навигационных ссылках и в доработках с привилегированным режимом.
Порядок прогона:
- Разверните копию базы и создайте по одному пользователю на каждый профиль:
test_buh_org1,test_sklad_org2,test_snab_all. Одного «универсального» тестового пользователя недостаточно — дырки видны только на срезах. - Откройте журналы документов под каждым и сверьте количество строк с тем же списком под полными правами. Совпало — RLS не применился.
- Прогоните универсальный отчёт по регистрам накопления (расчёты с клиентами, товары на складах) с группировкой по организации. В списке организаций не должно быть чужих.
- Подставьте в строку адреса навигационную ссылку на чужой документ вида
e1cib/data/Документ.РеализацияТоваровУслуг?ref=.... Ожидаемый результат — ошибка прав доступа, а не открытая форма. - Проверьте боковые входы: «Связанные документы» у общего контрагента, история, избранное, полнотекстовый поиск, отчёты по рассылке (регламентное задание рассылки работает от имени её владельца, а не получателя).
- Найдите в конфигурации и расширениях
УстановитьПривилегированныйРежим(Истина)и общие модули со свойством «Привилегированный» — внутри них RLS не действует вообще. Каждое вхождение в коде обменов и печатных форм разбирайте отдельно.
Быстрый тест на активность ограничений — два запроса в консоли под тестовым пользователем:
// 1) Без РАЗРЕШЕННЫЕ запрос должен упасть с ошибкой прав доступа,
// если пользователю закрыта хотя бы часть записей
ВЫБРАТЬ КОЛИЧЕСТВО(*) КАК Кво
ИЗ Документ.РеализацияТоваровУслуг
// 2) С РАЗРЕШЕННЫЕ вернётся только доступный срез —
// сравните число с результатом под полными правами
ВЫБРАТЬ РАЗРЕШЕННЫЕ КОЛИЧЕСТВО(*) КАК Кво
ИЗ Документ.РеализацияТоваровУслуг
Результаты фиксируйте таблицей «пользователь × объект × ожидание × факт» и храните её как тест-план. Прогон повторяют после каждого обновления релиза: типовые шаблоны ограничений при обновлении перезаписываются, и доработанное условие может тихо вернуться к стандартному.
Что делать со служебными учётками: роботы, обмены и HTTP-сервисы
Служебные пользователи — место, где ограничение прав, аудит и шифрование данных чаще всего расходятся с документацией: в схеме безопасности робот описан аккуратно, а в базе у него «Полные права» и пароль в тексте обработки. Любая интеграция с такими правами обнуляет весь контур RLS.
Что закрыть по каждой служебной учётке:
- Одна интеграция — один пользователь. Отдельные учётки под банк, маркетплейс, RPA-робота, обмен с розницей. Общая «Обмен» не даёт понять по журналу, кто именно выгрузил данные.
- Профиль вместо полных прав. Соберите профиль под задачу: роли на чтение и запись только нужных объектов плюс собственный набор доступных организаций. HTTP-сервисы и OData подчиняются RLS так же, как интерактивный сеанс, если код не переведён в привилегированный режим.
- Урезанный состав OData. Стандартный интерфейс по умолчанию открывает всё, к чему у пользователя есть права. Оставьте только объекты интеграции.
- Запрет лишних точек входа. В файле публикации отключите неиспользуемые web-сервисы, HTTP-сервисы и OData; на веб-сервере ограничьте доступ к каталогу публикации по IP-адресам систем-потребителей.
- Никаких внешних обработок. Снимите с служебного пользователя право открытия внешних отчётов и обработок и роль администратора — иначе через учётку робота в базу загрузят произвольный код.
- Пароли вне кода. Реквизиты подключения — в защищённом хранилище (например, в безопасном хранилище данных или внешнем secret-менеджере), с ротацией при смене администратора интеграции.
- Отдельный мониторинг. Настройте фильтр журнала по служебным пользователям и алерт на два события: вход вне окна расписания обмена и вход с неожидаемого IP или компьютера.
// Ограничение состава стандартного интерфейса OData
// Выполняется один раз, состав хранится в базе
Процедура ОграничитьСоставOData() Экспорт
Состав = Новый Массив;
Состав.Добавить(Метаданные.Справочники.Номенклатура);
Состав.Добавить(Метаданные.Справочники.Партнеры);
Состав.Добавить(Метаданные.Документы.ЗаказКлиента);
УстановитьСоставСтандартногоИнтерфейсаOData(Состав);
ЗаписьЖурналаРегистрации(
"Безопасность.СоставOData",
УровеньЖурналаРегистрации.Информация,
,
,
"Состав интерфейса OData ограничен: " + Состав.Количество() + " объектов"
);
КонецПроцедуры
Если RPA-роботу нужен именно интерактивный вход, привяжите учётку к рабочему месту: в подписке на начало работы системы сверяйте ИмяКомпьютера() со списком разрешённых и завершайте сеанс с записью в журнал при несовпадении. Так украденный пароль робота не сработает с чужой машины.
Пользователь не видит нужный документ: как найти причину за 15 минут
После включения RLS в поддержку идут два типа жалоб: «пропали документы» и «ошибка доступа при открытии отчёта». Разбирать их наугад — потерянный день. Порядок проверки от самого частого к редкому:
- Перезаход в базу. Список доступных организаций обычно кэшируется в параметрах сеанса при старте. Права выдали, а пользователь работает в открытом с утра сеансе — изменения он не увидит. Первое действие: завершить сеанс и войти заново.
- Состав групп доступа. Откройте карточку пользователя и посмотрите не роли, а группы доступа и их профили. Права по разным группам складываются: если человек попал в «Бухгалтер ОРГ-1» и «Кладовщик ОРГ-2», он видит объединение, а не пересечение. Обратная ситуация — не попал ни в одну — даёт пустые списки везде.
- Записи в регистре доступа. Проверьте регистр сведений с доступными организациями по этому пользователю. Типовая ошибка — организацию завели, а строку не добавили: RLS работает корректно, данных просто нет.
- Незаполненные реквизиты в самих документах. Документ с пустой организацией или пустым подразделением под ограничением исчезает у всех, включая автора. Такие записи находятся запросом по пустой ссылке и заполняются до, а не после включения RLS.
- Отчёт без «РАЗРЕШЕННЫЕ». Ошибка вида «недостаточно прав» при формировании — признак того, что в схеме компоновки или во внешней обработке запрос читает таблицу напрямую. Правится добавлением ключевого слова в запрос набора данных.
- Перезаписанный шаблон после обновления. Если проблема появилась ровно после установки релиза, сравните текст шаблона ограничений с эталоном из вашей документации: типовые шаблоны при обновлении конфигурации возвращаются к поставке вместе с доработанным условием.
Точечная проверка конкретного документа — один запрос в консоли под учёткой жалующегося пользователя:
// Если результат пустой — документ отсекается ограничением,
// если строка есть — проблема не в RLS, а в правах на объект или в отборе формы
ВЫБРАТЬ РАЗРЕШЕННЫЕ
РеализацияТоваровУслуг.Ссылка,
РеализацияТоваровУслуг.Организация,
РеализацияТоваровУслуг.Подразделение
ИЗ
Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ГДЕ
РеализацияТоваровУслуг.Ссылка = &Ссылка
Разбор фиксируйте в одной таблице: дата, пользователь, объект, причина, что изменили. Через месяц-два такой список показывает системные дыры — обычно это две-три организации с незаполненными реквизитами и один профиль, собранный неаккуратно.
Как выдавать и снимать доступы, чтобы матрица прав не разъехалась за полгода
Ограничение прав, аудит и шифрование данных держатся не на разовой настройке, а на дисциплине выдачи доступов. Типичная картина через полгода после внедрения: 40 профилей превратились в 90, половина создана «под сотрудника», а уволенные полгода назад люди числятся активными.
Рабочий регламент состоит из пяти правил.
- Профиль привязан к должности, а не к человеку. Заявка звучит «доступ как у кладовщика склада №3», а не «сделайте как у Иванова». Новый профиль создаётся, только если появилась новая должностная функция — это решение владельца процесса, а не администратора.
- Заявка с двумя подписями. Руководитель подразделения указывает профиль и перечень организаций, владелец данных подтверждает. Отправная точка — приказ о приёме или переводе, а не сообщение в мессенджере. Хранить заявки удобно прямо в базе задачами: тогда к любой строке матрицы прав есть основание.
- Отключение в день увольнения. Учётку блокируют (снимают признак входа в программу), но не удаляют — удалённый пользователь ломает читаемость журнала регистрации и историю изменения объектов. Отдельный триггер — перевод между юрлицами: доступ к прежней организации снимают, иначе матрица тихо расширяется.
- Временный доступ с датой окончания. Подрядчики, аудиторы, замещение на время отпуска — всегда с явным сроком. Регламентное задание раз в сутки проверяет дату и блокирует просроченные учётки с записью в журнал. Без автоматики «временный» доступ живёт годами.
- Ежемесячный отчёт по трём срезам. Кто не входил в базу 60 дней и старше; у кого профиль с полными правами; какие профили не назначены никому. Первый список идёт на блокировку, второй — на разбор, третий — на удаление.
Раз в квартал добавляйте подтверждение доступов руководителями: выгрузка «сотрудник — профиль — организации» уходит в подразделения, ответ «подтверждаю / снять у этих» возвращается письменно. Процедура занимает пару дней и снимает большую часть накопленных лишних прав — заодно это готовый комплект документов для внешнего аудита, который иначе собирают в авральном режиме за неделю до проверки.
Часто задаваемые вопросы
Насколько RLS замедляет работу 1С:ERP?
При корректной настройке с использованием индексированных регистров и кэширования замедление составляет 8–15%. При неоптимальных условиях с вложенными подзапросами замедление может достигать 40–60%, что неприемлемо для продуктивной эксплуатации.
Можно ли использовать стандартный журнал регистрации для аудита по ФЗ-152?
Частично. Стандартный журнал фиксирует базовые события, но для полного соответствия требованиям ФСТЭК нужно расширить состав логируемых событий и обеспечить защищённое хранение журнала вне базы 1С — обычно через интеграцию с SIEM-системой.
Какой сертифицированный криптопровайдер выбрать?
Для большинства задач подходит КриптоПро CSP 5.0 — он сертифицирован ФСБ, поддерживает ГОСТ 34.10-2018 и интегрирован с типовыми механизмами 1С. Альтернатива — ViPNet CSP для случаев работы с защищёнными сетями.
Нужно ли шифровать обмены внутри РИБ?
Если узлы РИБ соединены через интернет — обязательно (TLS 1.3 минимум). Внутри локальной сети формально не требуется, но рекомендуется для защиты от внутренних угроз и упрощения прохождения аудитов.
Как часто пересматривать матрицу прав доступа?
Минимум раз в квартал, а также при любых изменениях оргструктуры: приём/увольнение сотрудников, появление новых юрлиц, изменение бизнес-процессов. Автоматический отчёт о неиспользуемых правах должен формироваться ежемесячно.
Что делать, если внешний аудит выявил нарушения?
Составить план устранения с приоритизацией по критичности, начиная с разграничения доступа между юрлицами и журналирования критичных операций. Параллельно подготовить документацию: модель угроз, описание мер защиты, регламенты администрирования.
Можно ли защитить данные от администратора 1С?
Полностью — нет, администратор всегда имеет техническую возможность доступа. Но можно минимизировать риски: разделить роли (администратор ИТ ≠ администратор данных), включить аудит действий администраторов с выгрузкой в независимую систему, использовать принцип «двух пар глаз» для критичных операций.
Найдите специалиста для решения этой задачи на koderion.ru
Читайте также: внедрение и поддержка 1С:ERP