Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Эта статья посвящена обзору актуальных юридических требований в сфере публичных беспроводных сетей и обзору способов технической реализации таких сетей в 2026–2027 годах.

Написать эту статью меня побудили три вещи. Во‑первых, постоянный запрос от коллег и от владельцев различных объектов, на которых действует публичный Wi‑Fi, на актуальные законодательные требования к публичным сетям. Тут удивляться не приходится: законодательство постоянно докручивается, и требуется быть в курсе. Во‑вторых, некоторая смена поведения злоумышленников. И наконец, в‑третьих, многократный всплеск спроса на услуги по построению публичного Wi‑Fi, с которым мы столкнулись летом 2026 года. В этой статье я постараюсь актуализировать информацию о публичных беспроводных сетях и рассмотрю два вопроса: юридические требования и технические способы реализации.

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

Эти требования впервые были введены ещё в 2014 году и с тех пор в какой‑то мере исполнялись. Говоря «в какой‑то», я имею в виду, что у крупных сетей общепита или крупных гостиниц всё было сделано в соответствии с законодательством, но существовал огромный сегмент, который совершенно не заморачивался с этими требованиями. Часто это небольшие кафе, небольшие туристические объекты типа гостевых домов, усадеб, отдельных коттеджей и так далее. Часто они оформлены как ИП, а иногда могут и просто принадлежать физическому лицу без какого‑то должного юридического оформления. И конечно, там везде есть Wi‑Fi для клиентов. Обычно это может быть простой тариф для физического лица, который приходит в обычный бытовой роутер, а ключ для авторизации в Wi‑Fi сети напечатан на бумажке, приклеенной где‑то на стене в коридоре. И который, конечно же, никогда не меняется.

По субъективным ощущениям внимание к этому сегменту у ответственных органов значительно увеличилось в последнее время. И это увеличение стало ответом на действия злоумышленников. Наши коллеги из турбизнеса рассказывали об участившихся случаях, когда злоумышленники использовали посредников, заселяющихся в такой отель, подключающихся к Wi‑Fi без авторизации и запускающих у себя что‑то типа прокси для злоумышленника. Цель таких действий вполне понятна — сокрытие следов различных незаконных проделок.

Найти концы после такого инцидента, как правило, очень сложно. Нужно будет каким‑то образом понять, кому из гостей принадлежало скомпрометированное устройство. Это сложно сделать, когда личность гостя установлена при заселении, но авторизация клиентского устройства в беспроводной сети проведена с нарушением требований. Но часто бывает ещё хуже. Например, есть такие объекты размещения, где можно остановиться на ночёвку, рассчитаться наличными, и у тебя даже не спросят паспорт. Обращение к провайдеру также ничего не даст. Много устройств, как правило, за NAT роутера, MAC‑адрес устройства скорее всего вымышленный. И провайдера обвинить также нельзя: он по сути просто предоставляет интернет по тарифу для физического лица без авторизации в беспроводной сети.

Как должен быть организован публичный Wi‑Fi — базовые требования

Итак, как же должен быть организован публичный Wi‑Fi. Начнём с юридических аспектов. Ключевой документ здесь — Постановление Правительства РФ № 758 от 31 июля 2014 года, которое ввело обязательную идентификацию пользователей и их оборудования (MAC‑адресов) при организации точек коллективного доступа. Это требование работает в связке с 152-ФЗ «О персональных данных» и уточняющим Постановлением № 801 от 12 августа 2014 года, которое определило порядок хранения сведений. Позднее правила были дополнительно зафиксированы в Постановлении № 2607 от 31 декабря 2021 года (Правила оказания телематических услуг связи).

Под действие этих требований подпадают все точки, доступные неограниченному кругу лиц: кафе, рестораны, отели, торговые центры, библиотеки, МФЦ, АЗС. Домашние и корпоративные сети, где круг пользователей заранее определён, под эти правила не попадают.

Три легальных способа идентификации

Закон признаёт легальными только три способа идентификации.

• По документу, удостоверяющему личность (паспорт, водительское удостоверение). На практике в отелях это чаще всего реализуется через выдачу разового логина и пароля или PIN‑кода на стойке администратора.

• По номеру мобильного телефона — через SMS с одноразовым кодом или через звонок. Это самый распространённый вариант: пользователь попадает на страницу авторизации (captive portal), вводит номер, получает код и подтверждает его.

• Через учётную запись на портале «Госуслуги» (ЕСИА). Оператор получает идентификатор пользователя без номера телефона, но для этого нужна подтверждённая учётная запись, поэтому для иностранных гостей без российского гражданства этот путь закрыт.

Важно обратить внимание, что авторизация через социальные сети (VK, Одноклассники и тому подобное) законным способом идентификации не является. Роскомнадзор в своих разъяснениях прямо указывает на три легальных варианта, и соцсетей среди них нет. Вроде бы в 2026 году должны были расширить идентификацию на основе банковских карт, но это не точно.

Что и сколько нужно хранить

Оператор (или владелец сети, выполняющий его функции) обязан хранить связку из идентификатора пользователя, MAC‑адреса устройства и времени сессии. По Постановлению № 801 срок хранения составляет 6 месяцев. В некоторых практических руководствах и рекомендациях юристов встречается и ориентир в 12 месяцев — но это уже не законодательное требование, а «запас» для гарантированного соблюдения закона. Система должна уметь хранить данные как минимум в течение установленного законом срока, а лучше — с запасом.

Не только идентификация — фильтрация и защита детей

Помимо идентификации, публичная Wi‑Fi‑сеть должна обеспечивать ограничение доступа к информации, распространение которой в РФ запрещено (ст. 15.1 149-ФЗ «Об информации»). Как правило, это делается на стороне оператора связи, который автоматически выгружает реестр запрещённых ресурсов и фильтрует трафик.

Отдельное требование — 436-ФЗ «О защите детей от информации, причиняющей вред их здоровью и развитию». Если сеть доступна в местах, где бывают дети (а гостиничный холл или номерной фонд с семейным размещением — это как раз такой случай), доступ к определённым категориям контента должен быть ограничен.

Уведомление Роскомнадзора и договор с оператором

Поскольку при авторизации вы так или иначе обрабатываете персональные данные гостей (номер телефона, данные документа или идентификатор ЕСИА), гостиница выступает оператором персональных данных. По 152-ФЗ это означает обязанность иметь политику обработки ПДн, уведомлять Роскомнадзор и защищать данные от утечек. Кроме того, на практике распространена модель, при которой между бизнесом и оператором связи заключается договор об идентификации пользователей: оператор берёт на себя функции идентификации и хранения данных, а бизнес предоставляет ему список лиц, использующих оборудование для выхода в интернет (п. 22 Правил, утв. Постановлением № 2607).

С 26 июля 2026 года действует новая редакция 152-ФЗ «О персональных данных». Требования касаются того, что, например, гостиница собирает при авторизации (номер телефона, данные документа, идентификатор ЕСИА). Внутренние документы — политика конфиденциальности, согласия — стоит привести в соответствие с актуальными требованиями. На странице авторизации должна быть политика обработки ПДн и явная галочка согласия, а не «молчаливое» согласие. То есть вариант типа «подключаясь к беспроводной сети, вы даёте согласие на обработку перс. данных» уже не подойдёт.

Практические способы создания публичной сети

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

Вариант 1 — всё сделает оператор связи

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

Самая низкая цена на рынке — от 800 ₽ за одно устройство и до 3–5 тыс. руб. по верхней границе. Минусы связаны с более высокой ценой и необходимостью платить каждый месяц.

Вариант 2 — свои роутеры и облачный портал авторизации

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

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

Оборудование. Простые роутеры и точки доступа тут уже не подойдут, нужно оборудование, которое умеет работать с captive portal. Это могут быть MikroTik (например, hAP ac², RB4011) или Keenetic (Giga, Ultra) или множество других моделей. Ориентировочная стоимость MikroTik — от 5 до 30 тыс. рублей в зависимости от модели, у Keenetic цены самые разные.

Сервисы. Таких сервисов много. Например, WiFly или Global Hotspot поддерживают разные модели роутеров MikroTik и Keenetic «из коробки», авторизация по SMS, звонку, Госуслугам. Тарифы — от 1800 ₽ в месяц. И за эту сумму, как правило, можно использовать любое количество точек доступа.

Схема работы. Гость подключается к Wi‑Fi → роутер перенаправляет его на страницу облачного портала → гость проходит идентификацию → портал даёт роутеру разрешение на доступ. Логи сессий, как правило, хранятся на стороне сервиса, что снимает с вас часть нагрузки по 152-ФЗ.

Вариант 3 — полностью своё решение на базе контроллера беспроводной сети

Этот вариант подразумевает самую высокую стоимость оборудования при инсталляции, но и потом самый низкий ежемесячный платёж, который будет связан с оплатой SMS‑шлюза. Поскольку изначально в условиях задачи мы говорим о небольших отелях и гостевых домах, то и решение здесь будет соответствующее. В качестве примера я выбрал TP‑Link серии Omada — это оборудование SOHO‑сегмента.

Важно: встроенный портал Omada — это конструктор страницы авторизации и механизм перенаправления, но не «коробочное» решение под ключ. Вам всё равно потребуется настроить интеграцию с SMS‑шлюзом и обеспечить соблюдение 152-ФЗ при обработке номеров телефонов гостей. Это решение для тех, кто готов нести техническую и юридическую ответственность самостоятельно.

Сеть Omada строится вокруг трёх компонентов: контроллера, точек доступа и, опционально, PoE‑коммутатора для питания точек.

Шаг 1 — выбор и установка оборудования

Контроллер — «мозг» сети. Именно он управляет Captive Portal и хранит настройки авторизации. Для гостиницы есть два основных варианта:

• OC200 — настольный контроллер с двумя портами 10/100 Мбит/с, питанием через PoE (802.3 af) или Micro‑USB. Управляет до 100 точками доступа Omada, 20 коммутаторами и 10 роутерами. Ориентировочная цена — около 15 тыс. руб. Для небольшого отеля (до 20–30 номеров) этого достаточно, но Fast Ethernet на портах может стать узким местом при активном трафике.

• OC300 — стоечный контроллер с двумя гигабитными портами и USB 3.0 для резервного копирования. Управляет до 500 точками доступа, 100 коммутаторами и 100 роутерами. Ориентировочная цена — от 24 590 ₽ до 42 200 ₽ в зависимости от продавца. Для среднего и крупного отеля это более производительный и масштабируемый выбор.

Существует и программный контроллер Omada — бесплатное приложение, которое можно развернуть на собственном сервере или виртуальной машине. Это вариант для тех, у кого уже есть серверная инфраструктура и IT‑специалист, готовый её обслуживать. Важно: при использовании Captive Portal контроллер должен быть постоянно онлайн, иначе портал перестанет работать.

Точки доступа. Для гостиницы критичны два фактора: форм‑фактор (чтобы точки не портили интерьер) и поддержка современных стандартов Wi‑Fi. Вот несколько подходящих моделей:

Для номеров обычно оптимальны настенные модели (EAP235-Wall или EAP655-Wall), для лобби и конференц‑залов — потолочные EAP660 HD. Все они поддерживают роуминг и централизованное управление через контроллер, что важно для бесшовного переключения гостей между точками доступа.

Шаг 2 — настройка Captive Portal

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

1. Гостевую сеть, естественно, создаём открытую, чтобы к ней могли подключаться гости. И обязательно ставим галочку напротив пункта изоляции клиентов в сети.

2. Теперь для сети нужно создать свой портал авторизации. Встроенный портал Omada поддерживает несколько вариантов:

   • No Authentication — только страница приветствия (не подходит для соблюдения законодательства), но удобно крутить рекламу и не пускать в интернет ?.

   • Simple Password — единый пароль для всех (также не является легальной идентификацией).

   • Voucher — коды, которые можно распечатать и выдавать на стойке администратора (это один из легальных способов идентификации по документу, если вы фиксируете, кому выдан ваучер).

   • SMS — гость вводит номер телефона и получает код по SMS.

   • External RADIUS Server — делегирование авторизации внешнему серверу (например, облачному порталу).

   • External Portal Server — перенаправление на внешний портал авторизации.

3. Для гостиницы базовый сценарий — SMS. Однако здесь есть важный нюанс: встроенный SMS‑метод Omada требует подключения внешнего SMS‑шлюза для фактической отправки сообщений. В контроллере вы настраиваете параметры подключения к шлюзу (URL, ключи API), и портал начинает отправлять коды через него. Без этого шага SMS‑авторизация работать не будет.

Кстати, вариант с ваучерами не лишён смысла, если там, где будет заселение, нет связи. Частая история для удалённых мест размещения, например в Горном Алтае. Гость хочет заселиться на базу и подключиться к Wi‑Fi, для авторизации ему нужно получить SMS или принять звонок, но у его сотового оператора совсем нет покрытия.

Интеграция с SMS‑шлюзом или облачным порталом. На практике большинство отелей не настраивают прямой шлюз вручную, а используют готовые российские сервисы, которые уже интегрированы с Omada. Это снимает необходимость самостоятельно писать запросы к API и хранить логи. Это умеют делать те же самые сервисы, которые были перечислены в прошлом шаге. Но можно пойти ещё дальше или всё же подсоединить SMS‑шлюз.

Шаг 3 — безопасность и соответствие требованиям

Настроенный портал — это только начало. Для соответствия 152-ФЗ и базовым требованиям к публичным сетям необходимо продумать несколько моментов, которые встроенный портал Omada не решает «из коробки»:

• Хранение логов. Контроллер Omada хранит сессии, но для гарантированного соответствия требованиям по срокам и составу данных (IP, MAC, время сессии, объём трафика) надёжнее использовать внешний сервис или настроить экспорт логов на отдельный сервер. При самостоятельной реализации вы обязаны обеспечить хранение этих данных и их предоставление по запросу.

• Согласие на обработку персональных данных. На странице портала должна быть ссылка на политику конфиденциальности и механизм получения согласия гостя на обработку его номера телефона. Это требование 152-ФЗ, и его нужно реализовать на уровне HTML‑шаблона страницы.

• Фильтрация контента. Встроенный портал Omada не выполняет фильтрацию запрещённых ресурсов. Если вы не используете внешний сервис, который берёт это на себя, вам потребуется отдельное решение для фильтрации трафика (например, на уровне шлюза или DNS).

Вариант 4 — гибридное решение Ternex

Ещё стоит упомянуть некоторый гибридный вариант, который часто используется в Сибири. Это решение Ternex. Это одноимённая прошивка на основе OpenWrt и контроллер беспроводной сети с функцией Captive Portal в облаке. Плюсами является то, что оборудование можно выбрать самое разное. В том числе роутеры, которые изначально не умеют работать с контроллером, но, поставив прошивку, они получают функционал для работы с контроллером. Контроллер позволяет видеть все роутеры и точки доступа и управлять ими, находится в облаке, там же есть разные способы авторизации, в том числе и по SMS.

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

Заключение

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

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