Мы разрабатываем мобильные приложения для детских садов, которые становятся основным каналом связи между воспитателями и родителями. Фотографии дня, объявления, меню, отметки посещаемости, платежи за питание — технически это несложно, но есть жёсткое требование, которое определяет всю архитектуру: персональные данные детей. Ключевая задача — не просто создать удобное приложение, а гарантировать полную защиту данных в соответствии с 152-ФЗ и GDPR.
Более 5 лет мы создаём решения для образовательных учреждений и накопили 20+ проектов. Каждый этап разработки включает аудит безопасности. По опыту, 95% родителей начинают использовать приложение ежедневно, а воспитатели сокращают время на бумажные отчёты на 70%. Согласно Федеральному закону № 152-ФЗ, обработка биометрических данных требует отдельного согласия, поэтому мы закладываем это в архитектуру с самого начала.
Что входит в разработку мобильного приложения для детского сада?
Стандартное приложение включает ленту событий, меню, отметки посещаемости, платежи и push-уведомления. Но каждое решение мы адаптируем под конкретный сад: число групп, требования к отчётам, интеграцию с бухгалтерией.
Как защитить персональные данные детей? — разработка мобильного приложения
Фото ребёнка — биометрические данные в части лица, персональные данные в части идентификации. Хранить их нельзя без явного согласия родителя. На практике это означает:
- Согласие на обработку — отдельная форма с перечнем данных и целью. Не галочка при регистрации.
- Фотографии группы публикуются только в «закрытый» канал для родителей конкретной группы, а не всего сада.
- S3 bucket с фотографиями должен быть закрытым, доступ — только через presigned URLs с TTL 1 час, не через публичные ссылки.
- Удаление данных по запросу родителя (право на забвение) — реализовано на уровне backend.
Если проигнорировать эти правила, первая жалоба в Роскомнадзор создаст проблемы саду, а не разработчику.
Как мы реализуем безопасность?
Мы используем Flutter для кросс-платформенной разработки — это сокращает время и стоимость. Firebase Security Rules обеспечивают доступ только аутентифицированным пользователям в рамках их роли. Firebase Authentication с входом по номеру телефона (OTP) удобен для родителей: не нужно помнить пароль. Firestore обеспечивает реалтайм-синхронизацию сообщений и объявлений без WebSocket. Firebase Storage для фото с серверными правилами — доступ только если request.auth.uid принадлежит к группе ребёнка. Push-уведомления — FCM с topic-подпиской на группу: воспитатель отправляет одно сообщение, все родители группы получают пуш. Без необходимости перебирать токены вручную.
Пример настройки Security Rules для Firestore
match /groups/{groupId}/posts/{postId} { allow read: if request.auth.uid in resource.data.memberIds; } Эти правила гарантируют, что родитель видит только посты своей группы. Администратор получает отдельный claim.
| Компонент | Технология | Назначение |
|---|---|---|
| Frontend | Flutter (Dart) | Мобильное приложение |
| Auth | Firebase Auth (OTP) | Вход по номеру телефона |
| Realtime | Firestore | Лента, мессенджер |
| Storage | Firebase Storage (presigned URLs) | Фотографии |
| Push | FCM (topic) | Уведомления |
| Payments | СБП / ЮKassa | Оплата питания |
Функциональное ядро
Роли: администратор сада, воспитатель группы, родитель. Каждая роль видит только свои данные — RBAC обязателен.
Воспитатель отмечает посещаемость — простой UI, но логика важна: отметка за прошедшую дату должна требовать подтверждения или быть ограничена (нельзя ставить посещение «задним числом» дальше 3 дней). Оплата питания: интеграция с банком через СБП или ЮKassa, квитанции в PDF через pdf пакет Flutter или серверная генерация.
Лента событий — это не социальная сеть. Нет лайков, нет комментариев от других родителей (дети — не Instagram-контент). Только фото + текст от воспитателя, реакции родителя (прочитано/не прочитано).
Сроки и бюджет
Стоимость разработки рассчитывается индивидуально, но ориентировочные сроки:
| Этап | Срок |
|---|---|
| MVP (посещаемость, лента, пуши, роли) | 8–12 недель |
| MVP + платежи, меню, отчёты | 14–18 недель |
| Полная версия с аналитикой | от 16 недель |
Flutter-приложение обходится дешевле нативных из-за одной кодовой базы, а Firebase сокращает время backend-разработки в 2 раза по сравнению с собственным сервером.
Как спроектировать RBAC без излишней сложности?
Используем вложенную структуру данных: каждому пользователю (родителю) присваивается список groupIds. Воспитатель имеет доступ к группам, где он назначен. Администратор — ко всем. В Firestore security rules проверка выглядит так:
match /groups/{groupId}/posts/{postId} { allow read: if request.auth.uid in resource.data.memberIds; } Это масштабируется до сотен групп без лага. Для более сложных сценариев (например, доступ к отчётам только бухгалтеру) используем кастомные claims в Firebase.
Пошаговый план внедрения RBAC в приложении
- Анализ ролей — определите, кто имеет доступ к данным (администратор, воспитатель, родитель, бухгалтер).
- Проектирование groups — в Firestore создаём коллекцию groups с массивом memberIds.
- Аутентификация — настройте Firebase Auth с номером телефона.
- Security Rules — пишите правила для каждой коллекции, проверяя
request.auth.uid in resource.data.memberIds. - Тестирование — проверьте, что воспитатель не видит данные чужой группы.
Закажите консультацию по вашему проекту — мы покажем, как это работает за 30 минут. Свяжитесь с нами для бесплатной консультации по архитектуре вашего проекта. Мы гарантируем соблюдение 152-ФЗ и GDPR, опыт подтверждён 20+ успешными проектами. Получите консультацию — оценим проект бесплатно и предложим оптимальное решение.