Портал детского сада: личный кабинет, закрытые альбомы, 152-ФЗ

Разработка портала детского сада: где ломается доступ

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

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

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

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

Итог: система формально есть, а управляемыми остаются только витрина — права, сроки жизни ссылок и контур хранения живут отдельно от неё. Разбираем, как это закрывается в разработке портала детского сада: доступ выдаётся ролью и группой, ссылка имеет срок и отзывается, а персональные данные детей хранятся в одном контуре с журналом обращений.

Эффект внедрения: публикация, нагрузка, ручные операции

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

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

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

Альбомы детей — особая категория данных, поэтому доступ строится на сертифицированных средствах защиты (КриптоПро) и разграничении прав на уровне отдельных записей, а не только на входе в кабинет. Класс отказов «портал недоступен в час пик» перестал воспроизводиться: нагрузка распределяется, публикация не зависит от администратора, а уведомления доходят без ручной рассылки.

Сравнение вариантов: готовое решение, модуль, сервис

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

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

Этапы работы: от обследования до передачи в эксплуатацию

Портал детского сада отличается от обычного сайта: почти весь контент — персональные данные детей, а состав ролей меняется каждый год. Идём не от макета, а от модели доступа, требования 152-ФЗ проверяем на каждом шаге. Ниже — последовательность работы.

1. Обследование ролей и групп. Фиксируем роли — родитель и второй родитель, воспитатель, методист, заведующая, администратор — и для каждой список разделов и допустимых действий. Отдельно проговариваем переходы: приём в группу, перевод, выпуск, временный доступ родственника.
2. Схема данных портала. Связываем карточку ребёнка, группу, учётную запись родителя, альбом и согласие на съёмку. Схема задаёт правила заранее: при переводе ребёнка доступ переезжает вместе с ним, а не правится администратором вручную.
3. Настройка закрытых разделов. Права проверяем на серверной стороне по каждой записи, а не скрытием кнопок в браузере. Альбом отдаётся только родителям детей этой группы, прямая ссылка на файл не работает в обход портала.
4. Проверка под нагрузкой. Прогоняем пиковые сценарии: массовый вход родителей утром, публикацию альбома на несколько сотен снимков, рассылку уведомлений. Смотрим время отклика и поведение при одновременных запросах.
5. Передача в эксплуатацию. Отдаём администраторам инструкции по выдаче и отзыву доступов, настройки резервного копирования и журнал действий сотрудников, регламент на случай увольнения или смены воспитателя.

Что остаётся у заказчика: конфигурация, схемы, регламенты

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

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

Документацию ведём вместе с кодом: при изменении прав или появлении нового раздела инструкция обновляется в том же релизе. Через год портал не окажется «ничьим» — новый администратор или другой подрядчик разберётся по переданным схемам.

Кейс: убрали ручную выдачу доступов и обзвон родителей

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

Что изменили

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

Метрики до и после

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

Что делать, если у сада уже есть сайт и облачный диск?

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

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

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

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

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

Вопросы по доступам, хранению данных и нагрузке

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

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

Выдержит ли портал пиковые дни?

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

Можно ли разместить портал на своих серверах?

Да. Разворачиваем в вашем контуре, если данные не должны покидать инфраструктуру сада или управляющей компании. Резервные копии идут по расписанию, восстановление проверяем на тестовом стенде, обновления ставим с возможностью отката к предыдущей версии.

Обсудим задачу: вернёмся с оценкой и планом работ

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

• Перечень ролей: что каждая видит, что может менять, кому доступ закрыт.
• Состав разделов первой версии: личный кабинет, закрытые альбомы, объявления, документы, заявки — и что переносим на следующий этап.
• Как сейчас выдаются, хранятся и отзываются согласия на обработку персональных данных.
• Кто администрирует портал и как быстро закрывается доступ, когда сотрудник уходит.
• Есть ли действующий сайт и домен, куда планируется размещать данные и резервные копии.
• Ориентир по срокам запуска — например, к началу учебного сезона.

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