Вуз разрабатывает ПО: как выполнить требования 152-ФЗ
Университет, создающий собственное программное обеспечение, играет две роли одновременно: он оператор персональных данных студентов и преподавателей и разработчик информационной системы, которая эти данные обрабатывает. Каждая роль несёт свои обязательства — и они накладываются друг на друга.
Содержание
- Двойная роль вуза: оператор и разработчик ИСПДн
- Типичные продукты вузов и риски каждого
- ИСПДн вуза и уровни защищённости (ПП РФ № 1119)
- Модель угроз по приказу ФСТЭК № 21
- Согласие студентов и абитуриентов
- Договоры поручения с подрядчиками
- Open Source и облачные API: лицензии и DPA
- Локализация данных: серверы в РФ и трансграничная передача
- Аккредитация, РКН, ФСТЭК: кто и что проверяет
- Чек-лист вуза-разработчика: 10 пунктов
1. Двойная роль вуза: оператор и разработчик ИСПДн
Большинство требований 152-ФЗ адресованы операторам персональных данных — тем, кто определяет цели и средства обработки. Вуз является оператором ПДн с момента первого контакта с абитуриентом: заявление на поступление, анкета, личное дело — всё это персональные данные, требующие правовой основы для обработки.
Когда тот же вуз начинает разрабатывать собственные информационные системы — LMS, личный кабинет студента, электронную зачётку — он становится ещё и разработчиком информационной системы персональных данных (ИСПДн). Здесь к обязательствам оператора добавляются требования к проектированию и защите самой системы.
Как оператор вуз обязан:
- Получать согласие на обработку ПДн
- Публиковать политику обработки ПДн
- Подать уведомление в РКН
- Назначить ответственного
- Обеспечить права субъектов (доступ, исправление, удаление)
- Оформить договоры поручения с обработчиками
Как разработчик ИСПДн вуз обязан:
- Определить уровень защищённости (УЗ) системы
- Разработать модель угроз
- Реализовать технические меры защиты (приказ ФСТЭК № 21)
- Провести оценку эффективности мер
- Вести журналы событий и доступа
- Документировать архитектурные решения по безопасности
Подробнее о правовом режиме обработки данных в российском праве — на нашей странице «Россия / 152-ФЗ».
2. Типичные продукты вузов и риски каждого
Современный университет разрабатывает или эксплуатирует целый зоопарк IT-систем. У каждой — свой профиль персональных данных и своя зона риска с точки зрения 152-ФЗ.
LMS / портал дистанционного обучения
Онлайн-приёмная комиссия
Электронная зачётка / успеваемость
Мобильное приложение для студентов
Научные порталы и репозитории
Alumni-сервисы и выпускники
Рейтинговые и репутационные системы
Системы контроля доступа (СКУД)
3. ИСПДн вуза и уровни защищённости по ПП РФ № 1119
Постановление Правительства РФ № 1119 от 01.11.2012 устанавливает четыре уровня защищённости (УЗ) информационных систем персональных данных. Уровень определяется пересечением двух факторов: категории данных и числа субъектов в системе.
| Уровень | Когда применяется | Типичный сценарий в вузе |
|---|---|---|
| УЗ-1 | Специальные категории (здоровье, биометрия) + актуальные угрозы 1-го типа (уязвимости в системном ПО) | СКУД с биометрией + угрозы 1-го типа — редко для обычного вуза |
| УЗ-2 | Специальные категории, угрозы 2-го типа; или иные ПДн > 100 000 субъектов, угрозы 1-го типа | Медицинский факультет с историями болезней студентов |
| УЗ-3 | Специальные категории < 100 000 субъектов, угрозы 3-го типа; или иные ПДн любого масштаба, угрозы 2-го типа | Большинство ИСПДн средних и крупных вузов: личные дела, оценки, СКУД без биометрии |
| УЗ-4 | Иные ПДн < 100 000 субъектов, угрозы 3-го типа | Небольшие административные системы, alumni-сервисы |
Для определения актуального типа угроз необходима модель угроз (см. раздел 4). На практике большинство вузовских ИСПДн попадают в УЗ-3, если только в системе нет медицинских данных или биометрии.
Три основных типа ПДн, с которыми работает вуз:
Общедоступные ПДн
ФИО в публичных рейтингах, данные на официальном сайте — только с согласия субъекта на публикацию.
Иные (обычные) ПДн
Личные дела, оценки, контакты, паспортные данные — основная масса. УЗ-3 или УЗ-4.
Специальные категории
Здоровье (медфакультет, справки), биометрия (СКУД, видео с распознаванием). УЗ-2 или УЗ-3.
4. Модель угроз по приказу ФСТЭК № 21: влияние на архитектуру
Приказ ФСТЭК России № 21 от 18.02.2013 устанавливает состав и содержание мер по обеспечению безопасности ПДн при их обработке в ИСПДн. Для каждого уровня защищённости — свой набор обязательных мер.
Модель угроз — не формальный документ «для галочки». Это аналитический инструмент, который напрямую влияет на архитектурные решения при разработке системы. Именно поэтому её нужно составлять до начала разработки, а не после.
Что входит в модель угроз (Методика ФСТЭК 2021)
- Описание системы: архитектура, компоненты, потоки данных, точки подключения, пользователи и их роли.
- Нарушитель: внешний злоумышленник, внутренний сотрудник, привилегированный пользователь — для каждого свой потенциал и вектор атаки.
- Актуальные угрозы: из банка данных угроз ФСТЭК (bdu.fstec.ru) — выбираются те, которые реализуемы в данной среде функционирования.
- Уязвимости: программные, конфигурационные, организационные — с оценкой вероятности эксплуатации.
- Итоговый вывод: тип угроз (1, 2 или 3) → уровень защищённости → набор мер защиты.
Конкретные технические меры, которые вытекают из требований ФСТЭК № 21 и напрямую влияют на разработку:
Шифрование
Данные в транзите (TLS 1.2+), данные в покое (шифрование БД или отдельных полей). При УЗ-1 — ГОСТ-алгоритмы.
Разграничение доступа
RBAC или ABAC. Студент видит только свои данные. Преподаватель — только свой поток. Минимум привилегий.
Логирование событий
Журнал доступа к ПДн, изменений, экспорта данных. Срок хранения логов — минимум 1 год, для УЗ-1 — 3 года.
Антивирус и патчи
Средства антивирусной защиты на серверах. Регулярное обновление ОС и компонентов без уязвимостей CVE высокого риска.
Резервное копирование
Регулярные бэкапы с проверкой восстановления. Хранение резервных копий отдельно от основной базы.
Управление сессиями
Тайм-аут сессии, ограничение одновременных входов, двухфакторная аутентификация для привилегированных ролей.
5. Согласие студентов и абитуриентов: нюансы для каждой категории
Правовые основания для обработки ПДн в вузе разнообразны: договор об оказании образовательных услуг, законный интерес, исполнение требований закона, и — в ряде случаев — согласие субъекта. Именно согласие требует наиболее тщательного оформления.
| Категория субъекта | Кто даёт согласие | Нюансы |
|---|---|---|
| Студенты 18+ | Сам студент | Полная дееспособность. Отдельное согласие для каждой ИСПДн с чувствительными данными (биометрия, здоровье). |
| Студенты до 18 лет | Законный представитель (родитель, опекун) | Характерно для СПО, первых курсов. Позиция РКН: согласие родителя до 18 лет. Студент может подписать дополнительно. |
| Абитуриенты 18+ | Сам абитуриент | Согласие при подаче документов — отдельным документом. Не может быть пунктом в заявлении на зачисление. |
| Абитуриенты до 18 лет | Законный представитель | При подаче через Госуслуги — особая ситуация (см. ниже). |
| Преподаватели / сотрудники | Сотрудник | Основание — трудовой договор (ст. 86–88 ТК РФ). Согласие нужно только сверх трудовых обязательств: публикация фото, alumni-данные. |
| Выпускники (alumni) | Выпускник | Трудовые/договорные отношения прекращены. Для alumni-сервисов нужно новое самостоятельное согласие. |
Абитуриент подаёт документы через Госуслуги (ЕПГУ): кто оператор?
Порядка 70% абитуриентов подают документы через портал Госуслуги. Это создаёт правовую неопределённость: данные поступают от ЕПГУ, а не напрямую от абитуриента.
Позиция РКН: при получении данных через ЕПГУ согласие гражданина считается выраженным в рамках регистрации на портале. Однако вуз становится самостоятельным оператором с момента получения данных. Если вуз обрабатывает данные сверх переданных (добавляет в собственные ИСПДн) — нужно собственное согласие.
Если вуз разрабатывает интеграцию с ЕПГУ — необходимо оформить соглашение об информационном взаимодействии, в котором чётко разграничена ответственность за обработку данных.
Требования к форме согласия — те же, что для любого оператора: конкретные цели, перечень данных, срок, право отзыва, собственноручная или КЭП подпись. Подробнее — в нашем материале о compliance для образовательных учреждений.
6. Договоры поручения с подрядчиками: NDA — не замена
Вуз, разрабатывающий ПО, почти всегда привлекает внешних подрядчиков: команды разработки, облачные хостинги, сервисы рассылок, аналитические платформы. В каждом случае, когда подрядчик имеет доступ к персональным данным вуза, необходимо оформлять договор поручения обработки ПДн по ст. 6 ч. 3 152-ФЗ.
Типичные подрядчики вузовских IT-проектов:
- Перечень поручаемых действий с ПДн (хранение, обработка, передача)
- Цели обработки — строго в соответствии с целями оператора
- Обязанность соблюдать конфиденциальность
- Технические и организационные меры по обеспечению безопасности
- Право оператора проверять выполнение условий поручения
- Обязанность уничтожить данные по окончании поручения
7. Open Source компоненты и облачные API: лицензии и DPA
Вузовские разработчики активно используют open source. Это разумно — но несёт два отдельных слоя обязательств: лицензионный (что можно делать с кодом) и privacy (что происходит с данными пользователей через этот код).
Moodle (GNU GPL v3)
- Можно использовать, модифицировать, распространять.
- Если вуз распространяет модифицированную версию (продаёт, передаёт другим вузам) — обязан открыть исходный код.
- Если используете только для себя — GPL-обязательства по раскрытию кода не возникают.
- Moodle обрабатывает ПДн студентов — нужна конфигурация с локальным хостингом, а не облачный moodle.com.
Apache / MIT / BSD компоненты
- Разрешительные лицензии — минимальные обязательства: сохранить уведомление об авторских правах.
- Privacy-риски возникают не от лицензии, а от функционала: сбор телеметрии, запросы к внешним серверам.
- Проверяйте все npm/pip/composer-зависимости на наличие телеметрии и запросов к внешним серверам.
- Используйте
npm audit, OWASP Dependency-Check для выявления уязвимостей в зависимостях.
Применение облачных API — отдельная зона внимания. Каждый API, которому передаются данные пользователей, является обработчиком персональных данных:
| Сервис / API | Privacy статус | Что требуется |
|---|---|---|
| Яндекс.Облако / Yandex Cloud | РФ ✓ | Договор поручения обработки ПДн. Данные в РФ — локализация соблюдается. |
| VK Cloud / Mail.ru Cloud | РФ ✓ | Договор поручения. Серверы в РФ. |
| Google Workspace for Education | DPA нужен | Data Processing Amendment в Admin Console. Проверить регион хранения данных (Data Residency). |
| Microsoft Azure / MS 365 Education | DPA нужен | Microsoft DPA в MPSA/Enterprise Agreement. Указать российский регион хранения. |
| AWS (Amazon Web Services) | Трансграничная передача | DPA (AWS GDPR/DPA) + согласие субъектов на трансграничную передачу или ст. 12 152-ФЗ. Или использовать только российские регионы (нет у AWS) — проблема. |
| OpenAI API / Anthropic API | Трансграничная передача | Не передавать ПДн в запросах без анонимизации. DPA у OpenAI есть, но данные — в США. |
Лицензионные вопросы при разработке вузовского ПО — часть более широкой темы правовой охраны программ для ЭВМ. Если вуз планирует регистрировать собственные разработки или передавать права — полезно ознакомиться с нашим разделом IT-право и регистрация ПО, а также с материалом о лицензионных соглашениях.
8. Локализация данных: серверы в РФ и трансграничная передача
Статья 18.1 152-ФЗ требует, чтобы первичная запись персональных данных граждан Российской Федерации производилась в базах данных, расположенных на территории России. Для вуза это означает: основная база студентов, преподавателей и абитуриентов должна физически находиться на серверах в РФ.
Как правильно реализовать требование локализации в архитектуре ИСПДн
- Собственные серверы в дата-центре в РФ — наиболее очевидное решение. Крупные вузы (МГУ, СПбГУ, МФТИ) имеют собственную инфраструктуру.
- Российский облачный провайдер (Yandex Cloud, VK Cloud, Selectel, Ростелеком-ЦОД) — данные хранятся в РФ, договор поручения с провайдером закрывает 152-ФЗ.
- AWS / Azure / GCP с российским регионом — проблема: у AWS и GCP нет регионов в РФ. Azure имел, но инфраструктура изменилась. Актуальный статус нужно проверять у провайдера.
- Зеркальная база в РФ — если основная система международная (например, SAP в международном вузе), первичная запись должна идти в российскую БД, а затем реплицироваться. Не наоборот.
Когда возникает трансграничная передача
- Данные физически уходят на серверы за рубежом
- Иностранный подрядчик (разработчик, аналитик) удалённо работает с боевой базой
- Публикация в международные научные базы (Scopus, Web of Science)
- Международные образовательные партнёрства с обменом данными студентов
Как легально передать данные за рубеж
- Согласие субъекта на трансграничную передачу (ст. 12 ч. 1) — явное и отдельное
- Страна-получатель в списке «адекватных» государств РКН — без дополнительных условий
- Уведомление РКН о трансграничной передаче и получение разрешения (ст. 12 ч. 3–4 в ред. 2022)
- Обезличивание данных до передачи (GDPR-аналог pseudonymization)
Полный комплекс документов для соблюдения требований 152-ФЗ в образовательных организациях — на странице юридической упаковки.
9. Аккредитация, РКН, ФСТЭК: кто и что проверяет
Вуз находится в поле зрения нескольких регуляторов одновременно. Важно понимать, что проверяет каждый из них и как это соотносится с разработкой ПО.
Роскомнадзор (РКН)
Основание: 152-ФЗ- Политика обработки ПДн на сайте
- Согласия субъектов, уведомление в реестре
- Договоры поручения с вендорами
- Локализация данных граждан РФ
- Реагирование на инциденты (уведомление в 24 ч.)
- Права субъектов и ответы на запросы
ФСТЭК России
Основание: Приказы № 17, № 21- Уровень защищённости ИСПДн
- Модель угроз (Методика ФСТЭК 2021)
- Технические меры защиты информации
- Аттестация ГИС (если вуз работает с гос.системами)
- Использование сертифицированных СЗИ
Рособрнадзор
Основание: 273-ФЗ «Об образовании»- Образовательная деятельность, лицензия, аккредитация
- Качество образовательных программ
- Электронное обучение и ДОТ (дистанционные технологии)
- При использовании ДОТ — требования к защите доступа к образовательным ресурсам
ФСБ России
Основание: криптография- При использовании СКЗИ (криптографических средств) в ИСПДн высокого уровня
- Лицензирование деятельности по разработке СКЗИ (если вуз разрабатывает шифрование)
- Ввоз / вывоз СКЗИ
Когда вузовское ПО становится ГИС и что это меняет
Если вузовская система подключается к государственным информационным системам (ФРДО — реестр документов об образовании, ФИС ГИА, ЕПГУ) или сама является ГИС по решению уполномоченного органа — применяется Приказ ФСТЭК № 17, а не № 21. Требования строже: обязательная аттестация системы, сертифицированные средства защиты, согласование с ФСТЭК.
Для большинства внутренних вузовских систем (LMS, электронная зачётка) достаточно № 21. Как только система начинает интегрироваться с государственными реестрами — необходимо уточнять статус системы у ФСТЭК или привлекать аккредитованную организацию по ИБ.
10. Чек-лист вуза-разработчика: 10 пунктов
Если вы только начинаете приводить вузовские IT-системы в соответствие с 152-ФЗ, используйте этот список как дорожную карту:
Полную документацию по каждому из пунктов для образовательных организаций мы разрабатываем в рамках услуги юридической упаковки. Специфика вузов — в отдельном разделе для образовательных учреждений.
Часто задаваемые вопросы
Приведите вузовские IT-системы в соответствие с 152-ФЗ
Разработаем полный compliance-пакет для вуза-разработчика: от модели угроз и технического задания по ИБ до договоров поручения с подрядчиками и согласий для студентов и абитуриентов.
Работаем с государственными и частными вузами, колледжами, EdTech-платформами. Ответим в течение рабочего дня.