Сэкономили на облаке под 1С: ДО — заложили бюджет на штраф. Разбираем 152-ФЗ при работе с 1С

Привет, Хабр! На связи Егор Сапун, я руковожу направлением сертификации инфраструктуры Рег.облака. На моем опыте, при миграции 1С:Документооборота в облако часто рассуждают так: возьмем обычный сервер в российском дата-центре — этого хватит для 152-ФЗ. Звучит логично: пара тысяч рублей в месяц за виртуалку, сервер в РФ, требование локализации формально закрыто. Но в жизни этого не хватает, а с 30 мая 2025 года цена ошибки кратно увеличилась.

После поправок 420-ФЗ оборотные штрафы за утечку персональных данных составляют от 1 до 3 % годовой выручки, но не менее 20 млн руб. (для биометрии и специальных категорий — не менее 25 млн руб.); потолок для повторных инцидентов — 500 млн руб. На этом фоне «экономия» на защищенной инфраструктуре превращается в риск, который не покрывается никаким SLA.

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

Навигация по тексту

• Почему 1С:Документооборот — это ИСПДн, и где именно в нем лежат данные

• Что закон требует на самом деле — и в каком порядке

• Как определить свой УЗ и почему платформа 1С меняет арифметику

• Зоны ответственности: что закрывает провайдер, а что пользователь

• 5 ошибок при переносе 1С:Документооборота в облако

• Чек-лист перед переносом 1С:Документооборота

• И немного про деньги

Почему 1С:Документооборот — это ИСПДн, и где именно в нем лежат данные

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

Для инженера важнее другое: в 1С:Документообороте персональные данные лежат не только в таблице СУБД. Места, про которые забывают чаще всего:

• Тома хранения файлов.
  Вложения обычно вынесены в тома на диске, а не в базу. Защищать и шифровать нужно и СУБД, и файловые тома.

• Индекс полнотекстового поиска.
  Он содержит фрагменты тех же документов.

• Журнал регистрации.
  В нем — кто, что и когда делал; это тоже персональные данные.

• Каналы интеграции.
  Встроенная почта, обмен с ЭДО, веб- и тонкий клиент через интернет — это точки, где данные покидают периметр.

• Резервные копии и тестовые базы.
  Самый частый способ потерять ПДн — это не взлом, а тестовая среда. Кто-то снял дамп с продуктива, развернул на ноутбуке или соседнем сервере, чтобы посмотреть баг, и забыл удалить. В дампе — реальные ФИО, паспорта, договоры, и вся защита, которую вы построили вокруг боевой системы, на эту копию не распространяется.

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

Требования идут цепочкой, и проходить ее нужно по шагам:

• 152-ФЗ — определяет, кто оператор и какие обязанности на нём лежат.

• 242-ФЗ — собирать, хранить и обрабатывать данные граждан России на территории России. Это и закрывает российский ЦОД.

• Постановление Правительства № 1119 — задаёт четыре уровня защищенности: от УЗ-4 (низший) до УЗ-1 (высший).

• Приказ ФСТЭК № 21 — конкретные организационные и технические меры под каждый уровень.

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

Скажу пару слов про аттестацию, потому что вокруг нее много путаницы. Аттестация обязательна для ГИС — государственных информационных систем — и для систем, где это прямо установлено нормативно или условиями взаимодействия с госсистемой. Для обычной ИСПДн аттестация, как правило, не обязательна. Но «не обязательна» не значит «не нужно ничего делать»: меры и требования ровно те же, выполнять их всё равно придется. Разница в том, кто проверяет результат.

Есть два пути. Первый — оценка эффективности своими силами: организация сама готовит документы, процессы и регламенты, реализует меры и подаёт документы регулятору. Второй — аттестация: к проверке привлекается сторонний аудитор с лицензией ФСТЭК, и он подтверждает соответствие официально. По объему работы — одно и то же, отличается только формат подтверждения.

И тут важная развилка. Если у вас не свой ЦОД, а арендованная инфраструктура, аттестованное облако — практически единственный способ законно работать с ПДн: на обычном публичном облаке нельзя обеспечить требования к ЦОДу, гипервизорам и виртуализации. Но и это только фундамент: гостевая ОС, права в 1С и организационная документация всё равно на вас.

Как определить свой УЗ и почему платформа 1С меняет арифметику

Уровень защищенности зависит от трех вещей: тип актуальных угроз (1, 2 или 3), категория данных (специальные, биометрические, иные, общедоступные) и объем (данные сотрудников или нет, до 100 тыс. субъектов или больше).

Ключевой момент про угрозы. Угрозы 1 и 2 типа — это закладки и недекларированные возможности в системном и прикладном ПО. Использование сертифицированного ФСТЭК ПО может снизить актуальность этих угроз, но не автоматически. Тип актуальных угроз определяется в модели угроз с учетом всех компонентов ИСПДн — системного и прикладного ПО, применяемых СЗИ, окружения. По совокупности этих факторов специалист по ИБ и определяет итоговый тип угроз. Сертифицированная платформа — один из факторов в этой оценке, а не автоматический «понижатель УЗ».

У платформы 1С есть защищенный программный комплекс — ЗПК «1С:Предприятие 8.3z», сертифицированный ФСТЭК и пригодный для ИСПДн вплоть до УЗ-1. Обычная сборка такого статуса не имеет. Это не значит, что её нельзя использовать в ИСПДн — можно, если применяемые СЗИ митигируют соответствующие угрозы и это закреплено в модели угроз. Но при прочих равных сертифицированная платформа упрощает обоснование и сокращает список дополнительных мер.

Возможные расклады по УЗ — в таблице ниже. Но это всего лишь ориентир — точную классификацию закрепляет специалист по ИБ актом на основании модели угроз.

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

Зоны ответственности: что закрывает провайдер, а что пользователь

Это центральная часть. Соответствие 152-ФЗ — всегда совместная работа. Обычное облако не предназначено для работы с персональными данными с точки зрения 152-ФЗ и приказа ФСТЭК № 21: в нем не декларируется реализация необходимых мер по 21-му приказу. Базовый набор мер защиты в обычном облаке есть, но он другого характера: изоляция окружений между пользователями, ограничение доступа к менеджмент-узлам платформы. Сети при этом сегментированы — но не по требованиям 21-го приказа. Сертифицированных СЗИ для ИСПДн на обычном облаке нет. 

Для наглядности разложим приказ № 21 по слоям и владельцам:

• Инфраструктура (провайдер защищенного облака): физическая защита ЦОД, защита среды виртуализации, сегментация и изоляция сетей, межсетевой экран периметра, обнаружение вторжений, защита каналов администрирования, сертифицированные ФСТЭК и ФСБ средства. Это то, чего у обычного облака нет, а у защищённого — есть из коробки.

• Гостевая ОС виртуальной машины (вы): средство защиты от несанкционированного доступа, антивирус, своевременные обновления, регистрация событий, ограничение запускаемого ПО.

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

• Организационный слой (вы): модель угроз, акт определения УЗ, политика обработки, согласия субъектов, назначение ответственного, регистрация в реестре операторов Роскомнадзора, регламент реагирования на инциденты, договор-поручение с провайдером по статье 6 152-ФЗ.

Защищенное облако 152-ФЗ обеспечивает меры защиты по 21-му приказу на инфраструктурном слое, и это подтверждается документально — аттестатом или актом самооценки. На основании этого документа провайдер берет на себя часть обработки персональных данных (в частности, хранение) и подписывает с оператором договор-поручение по ст. 6 152-ФЗ. На обычном публичном облаке такого подтверждения нет — соответственно, и поручение там подписать нельзя.

5 ошибок при переносе 1С:Документооборота в облако, из-за которых не пройти оценку эффективности

Несколько типичных ошибок, которые видно при разборе реальных внедрений:

1. Защитили СУБД, но забыли про тома хранения файлов.
   Платформа 1С по умолчанию хранит вложения не в базе, а в томах хранения файлов — это отдельная директория файловой системы, путь к которой задается в конфигураторе. pg_dump или mysqldump эти файлы не захватывает: в дампе только метаданные документов, а сами PDF/DOCX/сканы паспортов лежат рядом, в томе. Если шифрование настроено только на datadir СУБД, тома уезжают в бэкап в открытом виде. Защищать и контролировать доступ нужно отдельно к каждой директории томов, и они должны попадать в тот же контур, что и БД.

2. Бэкапы 1С в стороннее объектное хранилище.
   Классический сценарий: настроили выгрузку дампа в S3 за пределами защищенного контура — потому что «там дешевле и удобнее версионирование». Юридически это не «передача ПДн третьим лицам», а взаимодействие со сторонней системой, и оно требует трёх вещей одновременно. Первое — защищённый канал связи между источником и хранилищем. Второе — на принимающей площадке должны быть реализованы меры защиты под ваш УЗ (то есть это тоже должен быть аттестованный контур или контур с актом самооценки). Третье — если хранилище у другого провайдера, с ним подписывается отдельный договор-поручение по статье 6 152-ФЗ. Если хотя бы одно условие не выполнено, бэкапу не место за пределами вашего защищенного контура.

3. Не описали все компоненты ПО ИСПДн в проектной документации. Весь перечень системного и прикладного ПО, входящего в ИСПДн, должен быть описан на этапе проектирования: версия платформы 1С, СУБД, ОС, агенты мониторинга, антивирус, СЗИ от НСД, все интеграции. От этого зависит модель угроз и итоговый УЗ — например, выбор между сертифицированной платформой ЗПК «1С:Предприятие 8.3z» и обычной сборкой меняет набор мер защиты. Если на оценке эффективности всплывает «забытый» компонент, модель угроз и акт УЗ переделываются, иногда с подъемом уровня защищенности и докупкой средств.

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

Общий принцип такой: на этапе проектирования описывается весь периметр ИСПДн — все компоненты ПО, все места хранения ПДн (включая журналы и индексы), все направления передачи (бэкапы, демо-базы, SIEM, интеграции). Всё, что выходит за периметр, требует тех же трех вещей, что и бэкапы: защищённый канал, меры защиты под ваш УЗ на принимающей стороне и договор-поручение, если она у другого провайдера.

Чтобы было понятно, как это выглядит в жизни, разберу на нашем сегменте. Защищенный сегмент Рег.облака под 152-ФЗ изолирован от остального облака, имеет аттестат соответствия по УЗ-1 и построен на средствах защиты, сертифицированных ФСТЭК и ФСБ. На такой инфраструктуре договор-поручение подписывается, и оператор получает закрытый инфраструктурный слой плюс юридическое оформление обработки. На обычном публичном облаке этого нет — и не по злому умыслу провайдера, а потому что инфраструктура изначально не проектировалась под требования 21-го приказа и хранение персональных данных. 

Чек-лист перед переносом 1С:Документооборота в облако

• Проинвентаризируйте, где в системе лежат ПДн: СУБД, тома файлов, индекс поиска, журнал регистрации, каналы интеграции, бэкапы, тестовые базы.

• Посчитайте, сколько у вас субъектов и к каким категориям относятся данные.

• Постройте модель угроз — в ней определяются типы актуальных угроз. На основании модели запишите в отдельном акте уровень защищенности.

• Проверьте в модели угроз, как использование ЗПК «1С:Предприятие 8.3z» повлияет на актуальные типы угроз и итоговый УЗ. Если эффект подтверждается, ставьте сертифицированную платформу до закупки лицензий.

• Спросите у провайдера, какие меры защиты он закрывает на своей стороне и что остается на вас. Обычно провайдер берет на себя ЦОД, виртуализацию и управление инфраструктурой — все остальное на вас. Если у провайдера есть аттестат или акт самооценки по приказу № 21, отдельно сверять его СЗИ не нужно.

• Подпишите с провайдером договор-поручение по статье 6 152-ФЗ.

• Закройте свои слои: СЗИ от НСД или сертифицированная ОС (она заменяет часть мер вместо отдельной СЗИ), антивирус на гостевой ОС, разграничение прав и журналирование в 1С, защита томов хранения файлов.

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

• Соберите остальной пакет проектной документации, без которого не пройти оценку эффективности: политика обработки ПДн, политика ИБ, регламенты управления доступом, реагирования на инциденты, резервного копирования и восстановления, формы согласий субъектов. Зарегистрируйтесь в реестре операторов Роскомнадзора.

И немного про деньги

Аренда защищенной инфраструктуры под 1С:Документооборот — это десятки тысяч рублей в месяц. Оборотный штраф за утечку начинается с 20 млн руб. и доходит до 3 % годовой выручки. Сравнивать нужно эти два числа, а не «обычный VPS» и «защищенный сегмент».

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

Самые дорогие ошибки случаются не на шифровании, а на берегу: неверно нарисовали периметр ИСПДн, не описали все ПО в проектной документации, неправильно посчитали УЗ. Начинать стоит с этого, а не с выбора тарифа. Если эта статья сэкономит вам один такой разговор с аудиторами — считаю, что цель достигнута.