Частный садик: трансляция камер родителям без публичного облака и лишних глаз

MAATRIX

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

Почему это не обычная задача «поставить камеры»

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

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

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

Как обычно устроена трансляция через публичный облачный видеосервис — и где там дыра

Типичная схема, которую предлагают облачные сервисы видеонаблюдения: камера регистрируется в личном кабинете производителя или интегратора, поток уходит на серверы сервиса, оттуда раздаётся по ссылке или через приложение с логином. Садику предлагают «просто дать ссылку родителям» или завести всем аккаунты в приложении — быстро, действительно works out of the box, и именно поэтому так часто выбирают.

Слабые места такой схемы для случая с детьми:

• Общая инфраструктура. Ваш поток физически хранится и передаётся через те же серверы, что и потоки тысяч других клиентов сервиса — от складов до частных квартир. Разграничение доступа между клиентами — это код и настройки сервиса, а не что-то, что вы контролируете или можете проверить.
• Ссылки, которые живут дольше, чем должны. Многие сервисы выдают ссылку на просмотр, которая не привязана жёстко к конкретному родителю и не имеет внятного срока действия. Такая ссылка легко пересылается, забывается открытой на чужом устройстве, остаётся рабочей и после того, как ребёнок перешёл в другую группу или ушёл из садика.
• Непрозрачное хранение записей. Если сервис не просто транслирует, а ещё и архивирует — вы часто не знаете точно, сколько хранится архив, где физически лежат серверы и кто из сотрудников сервиса технически имеет доступ к просмотру записей.
• Аккаунт как точка входа. Приложение с логином/паролем — это ещё один аккаунт, который можно скомпрометировать: слабый пароль у одного из родителей, переиспользованный с другого сервиса, — и доступ к трансляции группы получает кто-то посторонний, а садик об этом даже не узнает.

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

Архитектура: от камеры до экрана родителя

Идея не в том, чтобы «программировать видеонаблюдение с нуля» — это делают готовые открытые компоненты, собранные в одну цепочку, которую садик арендует и полностью контролирует сам, без промежуточного облачного сервиса как отдельного игрока с собственным доступом к данным:

1. Камеры в группе — обычные IP-камеры с поддержкой RTSP (Hikvision, Dahua, TP-Link, Reolink и подобные — почти любая современная модель это умеет). Камеры остаются в локальной сети садика, не смотрят напрямую в интернет.
2. Туннель до сервера. Небольшой роутер или мини-ПК в садике поднимает VPN-туннель (WireGuard) до арендованного VPS. Поток с камер уходит на сервер без публичного порта, открытого наружу из сети садика.
3. Медиасервер на VPS принимает RTSP-потоки и раздаёт их дальше в браузер — обычно через HLS или WebRTC, потому что RTSP браузеры напрямую не понимают.
4. Слой доступа перед медиасервером проверяет, кто смотрит: у каждой семьи — свой уникальный признак доступа, а не общая ссылка на всю группу, с ограничением по времени и без возможности угадать чужой.
5. Экран у родителя — просто веб-страница по HTTPS, без установки стороннего приложения и без создания аккаунта у третьей компании.

Для шага 3 разумный выбор — MediaMTX (бывший rtsp-simple-server): один бинарник, открытый исходный код, умеет принимать RTSP с камер и отдавать HLS и WebRTC без сборки инфраструктуры вокруг FFmpeg вручную.

Пример mediamtx.yml с отдельным путём на каждую камеру группы:

paths:
  gruppa1_kamera1:
    source: rtsp://cam-user:cam-pass@192.168.10.11:554/stream1
  gruppa1_kamera2:
    source: rtsp://cam-user:cam-pass@192.168.10.12:554/stream1
  gruppa2_kamera1:
    source: rtsp://cam-user:cam-pass@192.168.10.21:554/stream1

hls: yes
hlsAddress: :8888
webrtc: yes
webrtcAddress: :8889

Камеры со стороны сервера видны только через WireGuard-туннель, поэтому в конфиге можно использовать «внутренние» адреса из туннельной сети (например, 10.8.0.x), а не реальные локальные IP камер, торчащие наружу.

Сам туннель на стороне садика (пример для мини-ПК на Linux, поднимающего WireGuard-клиент до VPS):

sudo apt install wireguard
sudo wg-quick up wg0

где wg0.conf содержит ключи и адрес сервера как единственный маршрут для трафика камер — так поток вообще не идёт в открытый интернет между садиком и вашим сервером.

На самом VPS открытым наружу остаётся только HTTPS-порт (443), через который отдаётся уже готовый веб-плеер, а не сырой RTSP или необработанный HLS-эндпойнт медиасервера. Порты MediaMTX (8888, 8889) слушают только на внутреннем интерфейсе и наружу не публикуются — это делает файрвол:

ufw default deny incoming
ufw allow 443/tcp
ufw allow from 10.8.0.0/24
ufw enable

Доступ строго по семьям, а не по общей ссылке на группу

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

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

server {
    listen 443 ssl;
    server_name video.вашсадик.ru;

    location /watch/ {
        auth_request /verify;
        proxy_pass http://127.0.0.1:8888/;
    }

    location = /verify {
        internal;
        proxy_pass http://127.0.0.1:4000/verify;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }
}

Небольшое приложение на 127.0.0.1:4000 (Node.js или Python, буквально 50–80 строк) хранит таблицу «токен → семья → группа → срок действия» и решает, пускать запрос дальше или нет. Токен выдаётся администратором садика при зачислении ребёнка — не по email-рассылке, а лично, например в личном кабинете родителя или QR-кодом при заключении договора.

Важные правила для такой таблицы:

• Токен привязан к группе, а не ко всему саду — родитель видит камеры только той группы, где его ребёнок.
• Срок действия равен периоду посещения. Ребёнок перешёл в другую группу или покинул сад — токен деактивируется в тот же день, а не «когда вспомнят».
• Возможность выдать доступ второму члену семьи отдельным токеном, а не пересылкой одного и того же — так при необходимости можно отозвать доступ одному человеку, не трогая остальных.
• Лог обращений — кто и когда заходил под каким токеном, чтобы при подозрении на утечку было что проверить, а не гадать.

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

Хранить запись или только показывать поток вживую

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

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

Если архив всё же нужен (например, для разбора конкретной ситуации по запросу администрации или для расследования инцидента), стоит явно ограничить:

Пример простой задачи автоочистки архива старше 7 дней:

0 3 * * * find /var/lib/mediamtx/records -type f -mtime +7 -delete

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

Что сад должен сделать организационно, помимо технической части

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

• Информированное согласие родителей. Прежде чем ставить камеры и давать доступ, у сада должно быть чёткое понимание (и в идеале — письменная фиксация с родителями), что видео с детьми записывается или транслируется, кому и на каких условиях доступно. Это не техническая, а юридическая и этическая часть — за формулировками имеет смысл обращаться к юристу, который знает актуальные требования именно в вашей юрисдикции; общие ориентиры про персональные данные и видеонаблюдение можно посмотреть в статье «Видеонаблюдение и закон: где проходит граница» и в разборе 152-ФЗ и где законно держать сервер с персональными данными — но это справочные материалы, а не замена консультации с юристом под вашу конкретную ситуацию.
• Физическое размещение камер. Камеры направляют на общую игровую и рабочую зону группы, но не на зоны переодевания, туалет, тихий час крупным планом — это отдельная граница приватности внутри самой съёмки, независимо от того, куда потом уходит видео.
• Доступ персонала сада к серверу. Список тех, у кого есть административный доступ (SSH-ключи, пароль от панели токенов), должен быть маленьким и известным поимённо — точно так же, как список тех, у кого есть ключи от группы.
• План на случай инцидента. Если подозревается, что доступ получил кто-то посторонний — заранее понятно, кто отзывает токены, кто оповещает родителей и в какие сроки. Отсутствие плана — это отдельный риск сам по себе, не менее реальный, чем дыра в конфигурации сервера.
• Регулярный аудит списка токенов. Раз в месяц-два стоит сверять таблицу «токен → семья» со списком реально зачисленных детей — дети выпускаются из сада, переходят между группами, и «протухшие» токены иначе накапливаются незаметно.

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

Частые вопросы