Когда веб-интерфейс не решает всех проблем: почему сетевая связность критична для инфраструктурных проектов
При внедрении инфраструктурного решения часто складывается впечатление, что всё сводится к одному простому шагу: предоставить доступ к веб-интерфейсу.
На первый-третий рассчитайсь! Сервер – раз. Администратор – два. URL – три!
Открыт порт HTTPS 443 – значит, можно приступать к запуску.
На практике для решений, взаимодействующих с Linux-каталогом, такой подход напоминает попытку бить крапиву палкой. Веб-интерфейс – это лишь точка управления. Само решение не существует изолированно: ему необходимо обращаться к контроллерам домена, LDAP-каталогу, Kerberos/KDC, DNS, NTP. И это не рекомендации, а обязательные сетевые соединения, без которых сервис не функционирует – даже если страница в браузере загружается.
Именно поэтому при согласовании с отделом информационной безопасности (ИБ) важно предоставлять не запрос «дайте доступ к серверу, сколько не жалко», а схему сетевых взаимодействий.
### Реальная история
Проект – Linux-каталог на 600 пользователей. Крайний срок – конец квартала. Мы выполнили всё: Linux-каталог развёрнут, тестирование пройдено, дата запуска утверждена, всё готово.
За день до старта звонит ИБ: «А где схема сетевых взаимодействий?». Схемы нет. Я думал: ну HTTPS же открыли – чего ещё нужно?
Как оказалось – нужно всё остальное. И вот почему.
Формально доступ к веб-интерфейсу есть. Администратор может войти, ввести логин и пароль. Но само решение не способно выполнить ни одной задачи. В каталог ему не попасть. LDAPS не согласован. Kerberos – только в наших мечтах. DNS – «ну он же работает», но в заявке отсутствует...
Я сижу и просто смотрю на экран. Консоль открыта. Пользователей добавить невозможно.
Итог – запуск перенесён на две недели, а отпуск в Гагры летит ко всем чертям. Не из-за продукта. И не из-за архитектуры каталога. А из-за того, что схема сетевых взаимодействий появилась у ИБ за 24 часа до старта.
Эта история не является исключением. Вопрос о сетевой связности, как правило, возникает уже после того, как внедрение считается завершённым – и именно тогда выясняется, что согласован только верхний слой, а доменные сервисы остались за рамками.
Подтверждением того, насколько это сложная задача, служит официальная документация ALD Pro и FreeIPA. Там матрица сетевой связанности для одного домена занимает несколько страниц и включает десятки портов по TCP и UDP только для репликации между контроллерами.
### Почему веб-интерфейс – это ещё не вся система
Веб-интерфейс нужен, чтобы администратор мог управлять решением: открыть консоль, запустить операцию, проверить статус, скачать отчёт, настроить параметры.
Но если решение работает с каталогом, оно должно взаимодействовать не только с браузером администратора. Ему необходима связность с доменными сервисами.
Типовая логика выглядит следующим образом:
- рабочее место администратора подключается к серверу решения по HTTPS; - сервер решения обращается к LDAP-каталогу по LDAPS (или LDAP + StartTLS в зависимости от конфигурации); - для доменной аутентификации используется Kerberos; - для корректного поиска контроллеров и сервисов требуется DNS; - для Kerberos критична синхронизация времени через NTP; - в момент первичной настройки на сервере решения запускается установщик, которому необходимы права root (через sudo или напрямую).
Если согласован только HTTPS, возникает абсурдная ситуация: дверь в консоль открыта, но сама консоль не может выполнить ни одну задачу. Это напоминает историю с одним рок-концертом в Москве – кажется, несколько музыкантов не прошли паспортный контроль и просто не попали на сцену. Зал полный, билеты проданы, свет настроен. Только играть почти некому. Если кто помнит, что за концерт – напишите в комментариях, а то я подзабыл.
С внедрением примерно та же история. Веб-интерфейс открыт, страница загружается, пользователи ждут. Только каталог недоступен – потому что нужные порты не согласованы.
### Что именно забывают согласовать
#### LDAPS / LDAP + StartTLS
LDAP-каталог – это источник данных об учётных записях, группах, атрибутах, политиках и связях между объектами. Без защищённого канала к нему решение либо не соответствует требованиям ИБ, либо не вписывается в целевую архитектуру.
В большинстве современных Linux-каталогов по умолчанию используется либо LDAPS на порту 636, либо LDAP + StartTLS на порту 389. ALD Pro (построен на базе FreeIPA / 389 Directory Server) поддерживает оба варианта: внешние клиенты работают через 389/TCP с обязательным StartTLS или через 636/TCP с LDAPS. Конкретный вариант зависит от конфигурации конкретного внедрения – это стоит уточнять заранее, а не выяснять в момент первого подключения.
Типовая ошибка: согласовать доступ к веб-интерфейсу, но забыть, что сервер решения должен обращаться к контроллерам домена по защищённому каналу LDAP. Почему по защищённому? А вы когда-нибудь диктовали три цифры с задней стороны карты сотруднику банка по телефону? З – Защита!
#### Kerberos: порты 88 и 464
В доменной инфраструктуре Kerberos отвечает за аутентификацию. Если решение использует доменные учётные записи, взаимодействие с KDC становится обязательной частью архитектуры.
Если Kerberos не согласован, симптомы могут проявляться неочевидно: бесконечный запрос пароля, ошибка получения билета, вход зависает без внятного сообщения. Проблема при этом не в логине, не в пароле и не в продукте – а в том, что сетевая связность с KDC попросту не разрешена. Это для пользователя как вставить карту в неисправный банкомат. И карты нет, и денег нет, и в метро не пускают.
Порт 464 (kpasswd) часто не попадает в первоначальную заявку, потому что Kerberos в упрощённых схемах обычно сворачивают до одного пункта: «Kerberos 88». Но 464 нужен не в редких сценариях – он задействуется каждый раз, когда пользователь меняет пароль или администратор сбрасывает учётные данные в домене. Без него смена паролей перестаёт работать незаметно: билеты выдаются, вход работает, но операция смены пароля падает с невнятной ошибкой. В матрице портов его лучше вынести отдельной строкой и поставить этап «Эксплуатация», а не «по требованию».
#### DNS
DNS часто воспринимают как фон: «ну он же у нас работает». Как тот навигатор, который уверенно ведёт вас в болото. Но для доменной инфраструктуры это не фон – это один из ключевых компонентов. Сервер решения должен корректно находить контроллеры домена по имени. Прямые и обратные записи тоже могут оказаться важны.
Типичный симптом пропущенного DNS: каталог есть, контроллеры доступны по IP, но подключение нестабильно, или отдельные операции падают с неочевидными ошибками. И только потом выясняется, что проблема была не в LDAP и не в Kerberos, а в разрешении имён.
#### NTP
Синхронизация времени звучит тривиально. До тех пор, пока не ломается Kerberos.
Если расхождение времени между участниками доменной инфраструктуры превышает допустимый порог (по умолчанию в Kerberos это 5 минут), KDC начинает отказывать в выдаче билетов. Для пользователя это выглядит как ошибка аутентификации. Для администратора – как расследование на вечер пятницы. В субботу утром выясняется, что на одном сервере, который не трогали с 2019 года, отстают часы на 6 минут.
NTP лучше сразу включать в схему взаимодействий, даже если кажется, что «время и так настроено».
#### SSH: права на запуск установщика
Отдельный случай, который легко неправильно трактовать.
В момент первичной настройки на самом сервере решения запускается скрипт ipa-client-install (или его аналог в ALD Pro). Он взаимодействует с контроллером домена по протоколам Kerberos/RPC – SSH-подключения к контроллеру для этого не требуется.
Но скрипту нужны права root на том сервере, где он выполняется. Получить их можно по-разному:
- ввести пароль root, если он задан - использовать sudo с паролем (если администратор домена добавлен в локальную группу wheel) - использовать sudo без пароля, если политики безопасности это разрешают
Проблема в том, что по умолчанию доменный администратор не входит в локальную группу wheel на клиентской машине. Без этого установщик просто не запустится.
Для специалиста по ИБ вопрос про sudo без пароля — один из первых. Объяснение простое: установщик должен выполнить от имени root ряд действий (записать keytab сервиса, настроить SSSD). Сделать это без поднятия привилегий технически невозможно. После завершения настройки доступ можно и нужно отозвать: убрать пользователя из wheel или ограничить правило sudo конкретными командами.
Это не постоянная рабочая связность и не «доступ пользователей к продукту». Это разовое служебное действие на этапе установки.
### Схема – это язык разговора с ИБ
Схема сетевых взаимодействий нужна не для красоты в проектной документации. Она отвечает на вопросы, которые ИБ всё равно задаст:
- какие хосты взаимодействуют между собой; - по каким протоколам и портам; - на каком этапе это нужно – постоянно или только при настройке; - что произойдёт, если конкретный доступ не согласовать.
Отдельный вопрос, который ИБ задаёт почти всегда: нужны ли соединения в обратном направлении – от контроллера домена к серверу решения? Для описанных взаимодействий ответ однозначный: нет. LDAPS, Kerberos, DNS, NTP – во всех случаях инициатор соединения это сервер решения, контроллер домена только отвечает. Исключение – SSH в момент первичной настройки, но и там подключение идёт от сервера решения к контроллеру, не наоборот. Это стоит явно указать в сопроводительном письме к схеме: ИБ не будет переспрашивать, а согласование пройдёт быстрее.
Без этих ответов согласование превращается в длинную переписку: «а зачем вам этот порт?», «почему это не было в заявке?», «кто источник, кто назначение?», «это постоянно или только на установку?». Таможенники на финской границе и те добрее.
Именно поэтому схема должна появляться не накануне запуска, а на этапе проектирования.
### Матрица портов: минимальный рабочий формат
Одной схемы обычно недостаточно. Рядом с ней нужна матрица портов – таблица, которая позволяет ИБ быстро сопоставить каждый доступ с конкретным обоснованием. Как меню в японском ресторане: сначала непонятно, а потом втягиваетесь.
| Источник | Назначение | Протокол / порт | Этап | Зачем нужно | |---|---|---|---|---| | Рабочее место администратора | Сервер решения | HTTPS 443 | Эксплуатация | Доступ к веб-интерфейсу | | Сервер решения | Контроллер домена | LDAPS 636 | Эксплуатация | Защищённая работа с объектами каталога | | Сервер решения | Контроллер домена | LDAP 389 + StartTLS | Эксплуатация | Альтернатива LDAPS – зависит от конфигурации | | Сервер решения | Kerberos / KDC | TCP/UDP 88 | Эксплуатация | Доменная аутентификация и получение билетов | | Сервер решения | Kerberos / kpasswd | TCP/UDP 464 | Эксплуатация | Смена и сброс паролей пользователей домена | | Сервер решения | DNS | TCP/UDP 53 | Эксплуатация | Разрешение имён контроллеров и сервисов | | Сервер решения | NTP-сервер | UDP 123 | Эксплуатация | Синхронизация времени для Kerberos |
Это не универсальная матрица для любой инфраструктуры. В реальном проекте она зависит от конкретного продукта, доменной архитектуры, требований ИБ и сегментации сети. Но принцип один: не просто «откройте порт», а источник, назначение, протокол, этап и назначение взаимодействия.
### Для справки: полная инфраструктурная матрица ALD Pro
Матрица выше – это минимум для конкретного внедряемого решения. Но если параллельно согласовывается сетевая связность для всей инфраструктуры Linux-каталога (репликация между контроллерами, мониторинг, логирование, репозитории, установка ОС), картина выглядит значительно шире.
| Источник | Назначение | Порты / протоколы | Регламент | Описание | |---|---|---|---|---| | Контроллер домена | Контроллер домена | TCP: 53, 80, 88, 135, 139, 389, 443, 445, 464, 631, 636, 749, 953, 4505, 4506, 5001, 5432, 6379, 8000, 8008, 9789, 24224, 49152–65535 / UDP: 53, 88, 123, 323, 464, 631, 15000 | Регулярно | Репликация данных служб каталогов | | Все в пределах сайта | Контроллер домена | TCP: 53, 80, 88, 135, 139, 389, 443, 445, 464, 631, 636, 749, 4505, 4506, 5001, 5432, 6379, 8000, 8008, 9789, 24224, 30000 / UDP: 53, 88, 123, 137, 138, 323, 464, 631 | Регулярно | Запрос к контроллерам домена и серверам DNS для аутентификации. Запрос и чтение конфигураций | | Все в пределах сайта | Сервер мониторинга | TCP: 80, 443, 3000, 10050, 10051 | Регулярно | Данные метрик мониторинга | | Серверы репозиториев | Серверы репозиториев | TCP: 22, 5432 | Регулярно | Репликация репозиториев ПО | | Все в пределах сайта | Установка ОС по сети / репозитории ПО | TCP: 21, 80, 443, 5432 / UDP: 21, 67, 68, 69 | По запросу | Запрос параметров установки ОС. Получение установочных пакетов | | Все в пределах сайта | Сервер логирования | TCP: 80, 443, 5432, 24224 | По запросу | Сбор логов в центральное хранилище | | Сервер мониторинга | Сервер логирования | TCP: 22 | Регулярно | Сбор логов мо