Портал и 152-ФЗ: двенадцать вопросов службы безопасности и что из них решает разработчик

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

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

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

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

Ответ «это техника, проверяется так-то» заканчивается проверкой, ответ «это договор» уходит юристу и не держит проект. А на правовой вопрос технический аргумент не отвечает — и согласование вязнет.

Список ролей пишется за полчаса, матрица прав — за несколько дней, и разница обнаруживается на приёмке. Матрица — таблица: по вертикали типы объектов (заявка, документ, сообщение, карточка контрагента), по горизонтали роли, в клетках четыре отметки — видит, создаёт, меняет, закрывает. Пустая клетка тоже решение.

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

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

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

На такую проверку мы закладываем день, срок зависит от объёма: развернуть копию недельной давности в изолированной среде и показать на ней конкретную запись. На ней несколько раз выяснялось, что копия базы есть, а копий загруженных пользователями файлов нет.

Шифрование удобно разделить на три разговора. Канал — между браузером и сервером, сервером и учётной системой, приложением и бэкендом — обязателен всегда. Хранилище — база и файлы; важен не факт, а где лежат ключи и кто ими управляет. Отдельные поля — когда шифруют конкретные значения, а доступ к ним требует своего права.

В приложении для «Центра сопровождения бизнеса» — компании, которая ведёт бухгалтерский учёт и сопровождает организации разных форм собственности, — вход устроен через биометрию, включая Face ID, а данные хранятся в зашифрованном виде. Финансовые операции идут через интеграцию с API с контролем транзакций в реальном времени, плюс синхронизация с бухгалтерскими системами. Важна не технология, а принцип: чем меньше мест, где данные переносят руками, тем меньше поверхностей для вопросов.

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

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

Проверяемая часть такая. Именные записи сотрудников студии отключены — с датой и записью в журнале. Ключи и пароли интеграций сменены вашей стороной, а не «обещано сменить». Рабочие копии базы, отладочные выгрузки и переписка со скриншотами — удалены или переданы вам с письменным подтверждением. Отдельно — резервные копии у подрядчика: их судьба описывается заранее.

И честная граница: срок удаления, формат подтверждения и ответственность — предмет договора, а не настройки системы. Техника делает удаление возможным и проверяемым; обязанность удалить формулирует ваш юрист по таблице, где описано, что технически где лежит.

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

Содержание текста, перечень целей и основания обработки — не наша зона. Формулировки даёт ваш юрист, и мы просим об одном: получить их до вёрстки форм.

Парный вопрос — путь к удалению. Безопасность спрашивает не «есть ли кнопка», а можно ли выполнить обращение за понятный срок и чем подтверждается результат. Обычно юрист просит часть данных сохранить — перечень и основание даёт он. Правильный ответ не «мы всё удалим», а список: это удаляется, это обезличивается, это сохраняется.

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

Что сделать дальше без нашего участия. Соберите три документа — они закроют больше половины разговора с безопасностью. Перечень полей, которые портал собирает, с целью по каждому: после инвентаризации часть полей обычно исчезает. Матрицу прав таблицей объектов и ролей. Решение по площадке — с ответом, рассматривается ли ваш контур.

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