Списки доступа и режим обслуживания

Access Lists и режим обслуживания позволяют явно управлять двумя аспектами сервиса: кто может к нему обращаться и должен ли он принимать клиентский трафик во время плановых работ. Используйте эти аудируемые механизмы вместо временных изменений DNS, удаления Routes или недокументированных исключений межсетевого экрана.

Владелец сервиса определяет аудиторию и окно обслуживания. Ответственный за безопасность проверяет переиспользуемую политику доступа и порядок обращения с учётными данными. Оператор применяет изменение и подтверждает результат. Успех означает, что разрешённые клиенты сохранили доступ, запрещённые стабильно блокируются, а режим обслуживания намеренно возвращает 503, не теряя имя хоста, TLS и конфигурацию Route.

Списки доступа объединяют правила по IP-адресам и необязательную базовую HTTP-аутентификацию. Применяйте самый узкий список, который решает задачу, и проверяйте запросы как от разрешённого, так и от запрещённого клиента. Считайте сохранённые секреты базовой аутентификации учётными данными и меняйте их при изменении состава пользователей.

Режим обслуживания доступен для включённых управляемых Routes, которые не используют необработанную конфигурацию. Он сохраняет виртуальный хост HTTP/HTTPS, возвращает HTTP 503, приостанавливает управляемые проверки состояния и передаёт состояние обслуживания в оповещения и на страницы состояния.

Используйте режим обслуживания для запланированных работ, заметных клиентам. Не имитируйте обслуживание удалением Route, отключением TLS или перенаправлением на фиктивную целевую службу: такие действия уничтожают полезное состояние и усложняют восстановление.

Перед выходом из режима обслуживания убедитесь, что целевая служба работоспособна, миграции завершены, а зависимые базы данных и Secure Links готовы.

Сценарий работы со списком доступа

1. Определите минимальный набор разрешающих или запрещающих правил для нужной аудитории.
2. Добавляйте базовую HTTP-аутентификацию, только если клиент может безопасно хранить и менять учётные данные.
3. Сначала подключите список к тестовому Route или имени хоста с низким риском.
4. Из сети вне хоста nginx проверьте один разрешённый и один запрещённый адрес.
5. Откройте журналы доступа nginx и убедитесь, что решение приняла ожидаемая политика.
6. Подключайте политику к другим Routes только после однозначного результата проверки.

Изменение переиспользуемого Access List затрагивает каждый подключённый Route. Перед редактированием общей политики проверьте связанные с ней ресурсы. Если одному приложению нужна другая граница доступа, создайте отдельный список.

Безопасное включение обслуживания

Перед включением режима обслуживания:

• убедитесь, что Route управляемый и включён;
• зафиксируйте текущее состояние и активный Deployment;
• опубликуйте инцидент на странице состояния, если клиенты должны заметить изменение;
• убедитесь, что у операторов остаётся административный путь, не заблокированный Route приложения;
• заранее определите проверку, которая подтвердит завершение работ.

Gateway сохраняет виртуальный хост и поведение TLS, одновременно возвращая 503. Поэтому мониторинг и коммуникация с клиентами отражают намеренное состояние, а DNS и сертификаты не приходится менять без необходимости.

Выход и проверка

1. Проверьте целевую службу напрямую или через её управляемую проверку состояния.
2. Убедитесь, что привязки баз данных, миграции и зависимые службы готовы.
3. Отключите режим обслуживания.
4. Выполните внешний запрос к каноническому имени хоста.
5. Проверьте код ответа, ожидаемое тело, TLS, перенаправления и WebSocket, если он используется.
6. Закройте инцидент на странице состояния только после успешной внешней проверки.

Если Route остаётся недоступен, снова включите режим обслуживания вместо последовательного переключения несвязанных настроек. Определите неисправный уровень с помощью раздела Диагностика Ingress.

Применение политики и безопасность изменений

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

Базовая аутентификация дополняет сетевую политику, но не заменяет TLS. Используйте её только с HTTPS Routes, храните созданные учётные данные через поддерживаемый механизм секретов и передавайте их вне журналов приложения и тикетов. Удаление пользователя из общей учётной записи требует смены данных для всех остальных пользователей. Если важен независимый отзыв доступа, создавайте отдельные списки.

Перед изменением общего Access List запишите все подключённые Routes и текущее поведение разрешённого и запрещённого запросов. Внесите изменение один раз, дождитесь подтверждения от nginx и повторите обе проверки. Если валидация или применение завершились ошибкой, сохраните последнюю подтверждённую политику и исправьте новую ревизию. Не отсоединяйте контроль доступа от Routes в рабочей среде.

Аварийное восстановление

Access List может закрыть операторам доступ к приложению, но не должен блокировать административный путь Gateway, если этот путь не был намеренно помещён за той же политикой. Если доступ потеряли все ожидаемые клиенты, сначала найдите в журналах доступа исходный адрес запроса и проверьте настройку доверенного прокси. Этот сигнал указывает на уровень политики доступа, поэтому не расширяйте разрешённый диапазон вслепую.

Если сервис нужно восстановить немедленно, верните прежний заведомо исправный список или подключите узкий аварийный список с коротким сроком использования. Не заменяйте его неограниченным публичным доступом без явного принятия риска владельцем инцидента. После восстановления удалите временные правила, замените аварийные учётные данные и проверьте каждый Route, который использовал исходный список.