Чек-лист усиления защиты

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

Начните с границ, компрометация которых затрагивает всю установку: доступ к хосту Gateway, идентичности администраторов, ключи шифрования и PKI, PostgreSQL, Redis, идентичность Relay и хранилище резервных копий. Затем усиливайте роли управляемых нод, рабочие нагрузки, поставщиков и автоматизацию.

• Своевременно устанавливайте исправления на хосты Gateway и демонов и по возможности выделяйте их под соответствующие роли.
• Ограничьте доступ к PostgreSQL и Redis приватной сетью приложения.
• Открывайте только порты HTTPS и Relay, необходимые развёртыванию.
• Требуйте MFA от администраторов и сводите их количество к минимуму.
• Храните главные ключи и резервные копии вне хоста Gateway.
• Используйте служебные учётные данные с областью ресурсов и короткими интервалами ротации.
• Предпочитайте неизменяемые дайджесты образов и выделенные Build Workers.
• Запрещайте привязки каталогов хоста, привилегированный режим и доступ к устройствам, если их не требует явно поддерживаемый процесс.
• Не публикуйте управляемые базы данных без необходимости и используйте идентичности привязок.
• Проверяйте продление сертификатов и сохраняйте системную PKI, используемую для внутреннего транспорта.
• При необходимости отправляйте события аудита в независимо управляемый SIEM.
• Регулярно проверяйте интеграции источников, учётные данные реестра, клиентов OAuth, токены и активные сеансы.
• После инцидентов удаляйте временный режим обслуживания, отладочный доступ и ручные изменения хоста.

Не публикуйте снимки экрана, пакеты для поддержки или журналы, пока из них не удалены секреты, внутренние адреса, имена клиентов и URL репозиториев.

Плоскость управления

• Запускайте Gateway на выделенной виртуальной машине или хосте и ограничивайте прямой доступ к оболочке и Docker.
• Сохраняйте PostgreSQL, Redis, внутренний gRPC и ядро Gateway Inference в приватных сетях.
• Защищайте .env, ключи шифрования, ключи PKI, загруженные артефакты и идентичность Relay строгими правами владельца и резервными копиями.
• Используйте HTTPS на каноническом публичном URL и проверяйте работу файлов cookie, WebSocket, OAuth и прокси.
• Отключайте неиспользуемые способы аутентификации и интеграции.

Управляемые ноды

• Используйте одну идентичность регистрации на каждую роль хоста и никогда не копируйте сертификаты демонов между хостами.
• По возможности ограничивайте исходящий трафик адресами Gateway, Relay и необходимых поставщиков.
• Защищайте модули systemd, конфигурацию, корни доверия обновлений, сокеты среды выполнения и локальное хранилище.
• Изолируйте роли Ingress, Build Worker, Database и Relay в соответствии с их риском.
• Настройте предупреждения об устаревшем времени последней связи, снижении возможностей, нехватке места на диске и несовместимости обновлений.

Рабочие нагрузки и сборки

• Предпочитайте образы, закреплённые по дайджесту, и проверяйте источник, журналы сборки, политику уязвимостей и границы происхождения.
• Выполняйте Git-сборки только на выделенных Build Workers.
• Используйте управляемые тома вместо привязок каталогов хоста.
• Не предоставляйте привилегированный режим, произвольные устройства, сеть хоста или доступ к его файловой системе без явно поддерживаемого требования.
• Храните секреты среды выполнения и Build Secrets в предназначенных для них отдельных зашифрованных хранилищах.

Данные и приватные подключения

• По умолчанию не публикуйте управляемые базы данных.
• Используйте отдельную идентичность привязки для каждой связи приложения и проверяйте, что учётные данные владельца не попадают в конфигурацию рабочей нагрузки.
• Защищайте сети привязок, принадлежащие Gateway, и службы приёма соединений, принадлежащие демонам, от пользовательских операций жизненного цикла.
• Создавайте резервные копии данных приложений средствами движков и проверяйте восстановление отдельно от восстановления Gateway.
• Не отключайте прямой TLS базы данных, если только не задокументировано намеренное исключение для приватной сети.

Операционная уверенность

По установленному расписанию проверяйте состав администраторов, области групп, токены, клиентов OAuth, интеграции источников, соединители DNS, учётные данные SMTP, адреса SIEM и активные сеансы. Проверяйте ожидаемые отказы с помощью идентичностей без административных прав.

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

Управление исключениями

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

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

Проверка и восстановление

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

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

Сохраняйте способ восстановления, который не зависит от ремонтируемого компонента. Резервные ключи должны быть доступны при потере хоста Gateway; доступ администратора должен восстанавливаться при недоступности OIDC или электронной почты; резервные копии движков должны восстанавливаться при недоступной контура управления. Храните свидетельства и пересматривайте их по установленному расписанию.