Как мы забыли согласовать порты и просрочили запуск важного проекта

При внедрении инфраструктурного решения часто кажется, что всё сводится к одному простому действию: открыть доступ к веб-интерфейсу.

На первый-третий расчитайсь! Сервер – рас. Администратор – два. 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;
- в момент первичной настройки решение подключается к контроллеру домена по SSH и выполняет служебные действия.

Если согласован только 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: только на этапе первичной настройки

SSH – отдельный случай, который легко неправильно трактовать.

В момент первичной настройки решение подключается к контроллеру домена по SSH под учётной записью администратора домена (или служебной учётной записью) и выполняет служебные действия – например, применяет конфигурацию или регистрирует сервис. Для этого администратор домена должен входить в группу wheel и иметь разрешение на переход под root без пароля через sudo.

Для специалиста по ИБ это обычно первый вопрос: зачем sudo без пароля, и не является ли это дырой? Вопрос логичный, вызывает примерно столько же эмоций, сколько у бухгалтера строка отчётности «прочие расходы в 4 миллиона». Объяснение простое: в момент первичной настройки установщик должен выполнить от имени root ряд действий на контроллере домена – например, записать keytab-файл сервиса или настроить SSSD. Сделать это иначе, не поднимая привилегии, технически невозможно. После завершения настройки этот доступ можно и нужно отозвать: убрать пользователя из wheel или ограничить правило в sudoers конкретными командами.

Это не постоянная рабочая связность и не «доступ пользователей к продукту». Это разовое служебное взаимодействие на этапе установки.

На схеме SSH стоит обозначать отдельно с пометкой «первичная настройка». В матрице портов – добавить комментарий, в каком именно сценарии и когда он требуется.

Схема – это язык разговора с ИБ

Схема сетевых взаимодействий нужна не для красоты в проектной документации. Она отвечает на вопросы, которые ИБ всё равно задаст:

- какие хосты взаимодействуют между собой;
- по каким протоколам и портам;
- на каком этапе это нужно – постоянно или только при настройке;
- что произойдёт, если конкретный доступ не согласовать.

Отдельный вопрос, который ИБ задаёт почти всегда: нужны ли соединения в обратном направлении – от контроллера домена к серверу решения? Для описанных взаимодействий ответ однозначный: нет. LDAPS, Kerberos, DNS, NTP – во всех случаях инициатор соединения это сервер решения, контроллер домена только отвечает. Исключение – SSH в момент первичной настройки, но и там подключение идёт от сервера решения к контроллеру, не наоборот. Это стоит явно указать в сопроводительном письме к схеме: ИБ не будет переспрашивать, а согласование пройдёт быстрее.

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

Именно поэтому схема должна появляться не накануне запуска, а на этапе проектирования.

Матрица портов: минимальный рабочий формат

Одной схемы обычно недостаточно. Рядом с ней нужна матрица портов – таблица, которая позволяет ИБ быстро сопоставить каждый доступ с конкретным обоснованием. Как меню в японском ресторане: сначала непонятно, а потом втягиваетесь.

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

Для справки: полная инфраструктурная матрица ALD Pro

Матрица выше – это минимум для конкретного внедряемого решения. Но если параллельно согласовывается сетевая связность для всей инфраструктуры Linux-каталога (репликация между контроллерами, мониторинг, логирование, репозитории, установка ОС), картина выглядит значительно шире.

Эта матрица честно и доступно показывает, почему «список портов» нельзя собрать на ходу: только для репликации между контроллерами домена задействовано несколько десятков портов по TCP и UDP.

Когда инфраструктура сложнее: несколько площадок и доменов

В небольшом внедрении схема выглядит просто: рабочее место, сервер решения, один-два контроллера домена, DNS, Kerberos, NTP.

В реальной корпоративной инфраструктуре появляются дополнительные слои:

- несколько площадок и ЦОД;
- несколько контроллеров домена с репликацией;
- разные сетевые зоны и правила маршрутизации между ними;
- доверительные отношения с существующим доменом;
- отдельные серверы мониторинга, логирования, репозиториев.

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

Что лучше принести на согласование с ИБ

Хороший комплект для согласования выглядит так:

1. Краткое описание решения и его роли в инфраструктуре.
2. Схема сетевых взаимодействий.
3. Матрица портов с обоснованием каждого взаимодействия.
4. Разделение доступов по этапам: первичная настройка, эксплуатация, сопровождение.
5. Комментарии по обязательным и опциональным взаимодействиям.
6. Описание последствий, если конкретный доступ не будет разрешён.

Хорошая новость: минимальный вариант такого комплекта – это именно то, что показано в этой статье. Схема сетевых взаимодействий, матрица портов с этапами и обоснованием, пояснение по SSH – всё это можно взять как шаблон и адаптировать под конкретный продукт и инфраструктуру.

Формулировка «откройте доступ к серверу» здесь не работает – она слишком общая.

Точнее говорить так:

Для нормальной работы нужна сетевая связность между сервером решения, контроллерами домена и доменными сервисами. HTTPS нужен для доступа администратора к веб-интерфейсу. Для работы решения с каталогом дополнительно требуются LDAPS (или LDAP + StartTLS), Kerberos, DNS, NTP и SSH на этапе первичной настройки.

Вывод

В инфраструктурных проектах веб-интерфейс – это только верхний слой.

Если решение работает с Linux-каталогом, оно зависит от сетевой связности с доменными сервисами. Открыть HTTPS к консоли – ещё не значит подготовить продукт к работе.

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

Иначе запуск может сорваться не из-за продукта, не из-за каталога и не из-за ИБ – а из-за простой организационной ошибки: архитектуру сетевых взаимодействий принесли на согласование слишком поздно.

ИБ вам не враг, а друг и товарищ! Просто в схеме «сначала внедрение, потом согласование» всегда проигрывает тот, кто перепутал порядок.

Больше про российский ИТ без простоев – в телеграм-канале.