Гостиница: Wi-Fi для гостей с авторизацией и хранением логов — что требует закон

MAATRIX

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

Что вообще требует закон, когда вы даёте гостям доступ в интернет

Сразу оговорка, важная для всей статьи: конкретные нормы — кого именно они касаются, что именно нужно хранить и какой срок — сильно различаются по странам и меняются со временем, и здесь мы их не приводим и не выдумываем. Это не юридическая консультация. Но общий принцип стоит понимать: предоставление публичного доступа в интернет — в том числе гостевого Wi-Fi в отеле, хостеле, кафе при гостинице — во многих юрисдикциях подпадает под регулирование, касающееся идентификации пользователей и хранения логов доступа. Формулировки разные: где-то это требования к операторам связи и похожим на них сервисам, где-то — более общие нормы про защиту прав потребителей и расследование инцидентов, где-то отдельно регулируется just сама раздача Wi-Fi в общественных местах.

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

Почему пароль на ресепшене — это не авторизация

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

Проблема не в том, что пароль слабый. Проблема в том, что по такой схеме сеть в принципе не различает, кто есть кто. Все устройства всех гостей сидят в одной сети с одинаковыми правами, и если в логах роутера и остаётся что-то полезное (MAC-адреса, IP, время подключения), связать эту запись с конкретным человеком в конкретном номере невозможно — только вручную сверяя время выезда/заезда, и то приблизительно. Если случается что-то, требующее ответа «кто это был» — жалоба на харассмент через мессенджер с гостиничного Wi-Fi, скачивание чего-то незаконного, DDoS с вашей сети наружу — у гостиницы просто нет данных, чтобы ответить.

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

Как выглядит нормальная схема: авторизация по номеру комнаты

Правильная модель для гостиницы — captive portal, то есть страница авторизации, на которую браузер гостя перенаправляется автоматически при первом подключении к Wi-Fi, до того как дать доступ в интернет. Гость вводит номер комнаты и фамилию (или код, выданный при заселении) — и получает доступ на срок своего проживания. Технически это не какая-то экзотика, а стандартная функция, которая есть в нескольких вариантах — от встроенной в роутер до полностью самостоятельной.

Для большинства гостиниц на 10–80 номеров разумный выбор — второй вариант: CoovaChilli плюс FreeRADIUS на отдельном небольшом сервере, к которому точки доступа подключаются как NAS-клиенты RADIUS. Роутер или контроллер точек доступа остаётся простым, а вся логика авторизации, база гостей и логи accounting живут в одном месте, которое вы полностью контролируете.

Почему не облачный сервис гостевого Wi-Fi

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

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

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

Свой сервер снимает все три проблемы разом. Вы точно знаете, в каком дата-центре и в какой стране физически лежат ваши логи (это важно, если у вас, скажем, требования по локализации данных или вы работаете в юрисдикции ЕС/Великобритании). Вы сами определяете срок хранения и политику доступа. И вы можете за пять минут выгрузить нужный лог по запросу, а не писать в поддержку вендора и ждать.

Практическая схема на своём VPS

Для гостиницы среднего размера отдельный физический сервер в серверной — избыточно: достаточно небольшого VPS, на котором крутится FreeRADIUS плюс приём логов от точек доступа или капчал-портала. Разберём минимальный рабочий каркас.

FreeRADIUS хранит базу гостей (номер комнаты + пароль или код, действительные на период проживания) и ведёт accounting — то есть фиксирует факт начала и конца сессии, объём трафика, MAC-адрес устройства. В конфиге radiusd.conf accounting-модуль обычно уже включён по умолчанию, важно только явно настроить формат и путь для detail-лога:

# /etc/freeradius/3.0/mods-available/detail.log
detail {
    filename = /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d
    header = "%t"
    permissions = 0600
}

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

Точки доступа или контроллер (если у вас единая система вроде Ubiquiti UniFi или что-то на базе OpenWrt) настраиваются как NAS-клиенты RADIUS — им указывается адрес вашего VPS и общий секрет:

# /etc/freeradius/3.0/clients.conf
client ap_lobby {
    ipaddr = 10.0.10.5
    secret = <shared-secret>
    shortname = ap-lobby
}

Привязка авторизации к номеру комнаты делается на уровне базы пользователей FreeRADIUS: при заселении гостя администратор (вручную или через небольшой скрипт, интегрированный с вашей PMS) создаёт учётную запись вида room214 с паролем, действительным до даты выезда. Дата выезда может быть реализована как Expiration атрибут в профиле пользователя — тогда доступ автоматически отключается, и не нужно вручную чистить базу за администратором, который забыл это сделать.

Если у вас уже есть система бронирования с API, логичный следующий шаг — синхронизировать список активных броней с базой RADIUS автоматически, ночным заданием по cron: выгрузка списка заселённых номеров, создание/продление учётных записей, отзыв доступа для выехавших. Это отдельная интеграция под конкретную PMS, и в рамках этой статьи мы её не расписываем в деталях — но сама идея (номер комнаты = учётная запись с ограниченным сроком жизни) реализуема практически с любым PMS, у которого вообще есть какой-то способ выгрузить список текущих гостей.

Хранение и ротация логов

Логи accounting быстро накапливаются, и если их не ротировать, диск на VPS рано или поздно закончится в самый неподходящий момент. Настраивается это стандартным logrotate:

# /etc/logrotate.d/radius-accounting
/var/log/radius/radacct/*/detail-* {
    daily
    rotate 400
    compress
    delaycompress
    missingok
    notifempty
    create 0600 radius radius
}

Число rotate 400 здесь — не рекомендация конкретного срока хранения, а просто пример: логротейт хранит последние N ротированных файлов, а какой именно срок хранения вам нужен по факту (и по закону в вашей юрисдикции) — решать вместе с юристом, а не подбирать наугад из статьи в интернете. Технически проще сразу заложить конфигурируемый срок и автоматическое удаление устаревших файлов, чем потом вручную чистить диск раз в год, когда он заполнится под завязку. Мы отдельно разбирали, как ротация логов реально экономит место на диске и какие тут есть подводные камни — см. ротация логов, чтобы не забивался диск.

Сколько места закладывать под диск — вопрос конкретной нагрузки, и точную цифру для вашей гостиницы даст только собственное наблюдение за первый месяц работы. Ориентировочно: одна запись accounting в детальном логе FreeRADIUS занимает от нескольких сотен байт до пары килобайт в зависимости от того, сколько атрибутов вы логируете. Для гостиницы на 50 номеров с оборотом гостей и переподключениями устройств в течение дня это на практике совсем небольшой объём — заметно меньше, чем логи веб-сервера с активным трафиком. Так что для VPS с диском от 40–80 ГБ вопрос места под логи гостевого Wi-Fi обычно не встаёт годами, если он не единственная нагрузка на сервере.

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

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

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