Документация / Руководство по установке / Эксплуатация
Безопасная конфигурация
Что настроить при установке и проверять при эксплуатации: TLS, адреса и cookie Core, учётная запись администратора, секреты и их смена, сетевые ограничения, изоляция сканирования, исходящие соединения.
TLS
- TLS терминирует внешний прокси площадки. Сертификаты для имён Core и Radar выпускает площадка.
- Внутри кластера компоненты общаются по HTTP. Ограничьте этот трафик сетевыми политиками - см. Сеть и доступ.
- Задайте
DOMAINCore сhttps://. Тогда Core ставит cookie с признаком Secure, а адрес попадает вCSRF_TRUSTED_ORIGINS. Сhttp://cookie уходят и по незашифрованному соединению. - Radar поддерживает TLS к Redis:
REDIS_SSL=True, проверка сертификата -REDIS_SSL_CERT_REQS=True. Параметров TLS для PostgreSQL в Core нет: изолируйте соединения с базами сетью.
Флаги, которые ослабляют проверку сертификатов
Включайте их только на время отладки.
| Где | Флаг | Что ослабляет |
|---|---|---|
| Core: "Radar" → "Настройки" | "Проверять SSL" выключено | проверку сертификата Radar |
| Воркер Radar | HTTP_SSL_SKIP_VERIFY=True |
проверку сертификата Core при отправке отчётов |
| Core, Radar | BROKER_SSL_SKIP_VERIFY=True |
проверку сертификата брокера |
| Radar | REDIS_SSL_CERT_REQS=False |
проверку сертификата Redis |
| Core: интеграции с системами контроля версий | "Проверять SSL сертификат" выключено | проверку сертификата GitLab, GitHub, Bitbucket, Azure Repos |
| Core: уведомления, LLM | "Проверять SSL" выключено | проверку сертификата получателя |
| Core: DefectDojo | "Самоподписанный SSL" | принимается самоподписанный сертификат DefectDojo |
| Core: SSO | "Использовать самоподписанный сертификат" | принимается самоподписанный сертификат провайдера |
| Security checker | ASOC_INSECURE=1 |
проверку сертификата Core из CI |
Адреса, cookie и сессии Core
| Настройка | Рекомендация | Почему |
|---|---|---|
ALLOWED_HOSTS |
перечислите имена Core: внешнее, внутреннее для Radar, имя для проб | по умолчанию * - Core отвечает на любой Host |
CORS_ORIGIN_WHITELIST |
оставьте пустым, если интерфейс Core открывают только с его адреса | кросс-доменные запросы к /api/ разрешаются только перечисленным origin |
DEBUG |
не задавайте | режим отладки выключен, пока переменная не равна 1 или True |
DJANGO_SECRET_KEY |
задайте случайное значение | по умолчанию стоит известная заглушка |
Вход пользователей Core:
- токен доступа живёт 15 минут, токен обновления - 1 день; при обновлении выдаётся новый, старый попадает в чёрный список;
- токены передаются только в cookie
accessиrefreshс HttpOnly и SameSite=Lax; заголовокAuthorization: Bearerдля входа пользователя Core не принимает; - API-токен пользователя передаётся заголовком
Authorization: Token; сменить его - "Профиль" → "Токен аутентификации API" → "Ротировать"; - длина пароля - от 8 до 128 символов.
Учётная запись администратора
- Задайте
ADMIN_PASSWORDв секрете или смените сгенерированный пароль после первого входа: "Профиль" → "Изменить пароль". - Сгенерированный пароль печатается в журнал Job подготовки базы. Удалите журнал или ограничьте к нему доступ.
- Права в меню Core выдаются ролью: первый администратор получает роль
superuserс полным доступом. Остальным пользователям назначайте роли с минимальными правами - см. Роли и права. - Когда у пользователя отзывают доступ у провайдера SSO, снимите его роли в Core или заблокируйте пользователя - см. Вход через SSO.
Секреты
Хранение
- Секреты хранятся в Kubernetes Secrets и попадают в поды переменными окружения. Отдельное хранилище секретов не требуется.
- Включите шифрование etcd (encryption at rest) и настройте RBAC без wildcard-доступа к secrets.
- Копия секретов передаётся владельцу площадки при установке. Журналы установки и выгрузки секретов - такой же чувствительный материал, как сами секреты.
- Core хранит секреты интеграций в своей базе зашифрованными парой
JWT_PRIVATE_KEYиJWT_PUBLIC_KEY. Radar хранит пароли реестров зашифрованнымиDOCKER_ENCRYPTION_TOKEN, а токен доступа - bcrypt-хешем. - Интерфейс и API не возвращают сохранённые секреты: вместо значения - признак, что оно задано.
Генерация
| Секрет | Как получить |
|---|---|
DJANGO_SECRET_KEY |
openssl rand -hex 32 |
| Пароли PostgreSQL, RabbitMQ, Redis | openssl rand -hex 16 |
JWT_PRIVATE_KEY, JWT_PUBLIC_KEY |
RSA 2048 - см. Формат PEM-ключей |
DOCKER_ENCRYPTION_TOKEN |
openssl rand -hex 16 - ровно 32 символа |
ACCESS_TOKEN |
создаётся в интерфейсе Radar - см. Первичная настройка |
ADMIN_PASSWORD |
по своей парольной политике |
Ротация секретов
| Секрет | Что затронет смена | Как менять |
|---|---|---|
| Пароль PostgreSQL | все процессы Core или Radar | смените пароль в PostgreSQL и в секрете, перезапустите процессы |
| Пароль RabbitMQ | процессы, которые используют брокер | смените пароль в брокере и в AMQP_HOST_STRING, перезапустите процессы |
| Пароль Redis | Radar back и воркеры | смените пароль в Redis и в REDIS_PASSWORD, перезапустите |
| Пара JWT | все сохранённые секреты интеграций Core и все сессии пользователей | не меняйте без необходимости. После смены заново введите токен Radar, SSH-ключ, учётные данные реестров, систем контроля версий, Jira, DefectDojo, SSO, уведомлений, LLM, секреты облачных ассетов |
DOCKER_ENCRYPTION_TOKEN |
пароли в "Уч. Данные Docker" | после смены введите пароли заново |
| Токен Radar | Radar back, воркеры, настройки Radar в Core | токен хранится в трёх местах: хеш в базе Radar, ACCESS_TOKEN в секрете Radar, "Токен доступа" в Core. Меняется во всех трёх одновременно, с перезапуском Radar back и воркеров. Токен в интерфейсе Radar создаётся один раз - смену выполняет команда SecurityFlow |
| API-токен пользователя Core | CI и скрипты с этим токеном; сканы, запущенные от имени пользователя | "Ротировать" в профиле. Radar отправляет отчёты в Core с API-токеном того, кто запустил аудит. Не ротируйте токен, пока идут ваши сканы |
| SSH-ключ для репозиториев | клонирование во всех пайплайнах | замените ключ в системе контроля версий и в Core: "Radar" → "Настройки" → "Приватный SSH ключ" |
Сеть и доступ
- Radar. В Radar нет пользователей и ролей: интерфейс и API открывает один общий токен. Документация API Radar (
/api/v1/docs,/api/v1/redoc,/api/v1/openapi.json) открыта без входа. Ограничьте сетевой доступ к Radar администраторами платформы и Core. - Администрирование Django. Фронт Core проксирует
/admin/на бэкенд. Откройте/admin/на внешнем прокси только для сети администраторов: через администрирование Django, в частности, блокируют пользователей. - Базы, брокеры, Redis. Доступ к PostgreSQL - только из пространств Core и Radar. Доступ к RabbitMQ Core - только из пространства Core, к RabbitMQ Radar и Redis - только из пространства Radar.
- Узлы scan. Исходящий трафик - к системам контроля версий, реестру образов, Core и, если используются DAST и проверки периметра, к целям сканирования.
- Сервер лицензий. Исходящий HTTPS из кластера только до
securityflow.ru:443.
Матрица потоков - Сетевое взаимодействие.
Изоляция сканирования
Контейнер сканера получает код репозитория и секреты пайплайна. Поэтому сканирование отделено от остальной платформы.
- Выделенные узлы. Воркеры сканирования работают только на узлах scan с taint
dedicated=scanners:NoSchedule. - Привилегии. Привилегированный только контейнер Docker-in-Docker в поде воркера. Radar back и фронты работают без привилегий.
- Контейнеры джоб. Джобы работают внутри Docker пода воркера, в сетевом пространстве пода. CPU и память джоб ограничивает limit пода воркера.
- Выделенный Docker. Подключайте воркер только к своему Docker. Ежедневная очистка удаляет все неиспользуемые тома демона, а не только тома Radar - см. Очистка Radar.
- Доверенные образы. Каждый контейнер джобы получает все переменные пайплайна, включая скрытые:
PORTAL_TOKEN,PRIVATE_SSH_KEY,DOCKER_REGISTRY_PASSWORD,CLOUD_KEY_SECRET. Скрытые переменные маскируются только в логе. Подключайте только проверенные образы сканеров из своего реестра. - Видимые переменные. Значения видимых переменных выводятся в лог джобы. Секреты передавайте только скрытыми переменными. Для доступа к репозиториям используйте SSH-ключ из настроек Radar, а не токен в адресе репозитория.
- Ключ хоста системы контроля версий. Code Downloader не хранит ключи хостов между запусками. Чтобы ключ хоста вашей системы контроля версий проверялся, добавьте его запись
known_hostsв "Команду запуска" Code Downloader.
Исходящие соединения
| Куда | Когда | Как ограничить |
|---|---|---|
securityflow.ru:443 |
активация и сверка лицензии | разрешите только этот адрес |
Docker Hub, образ alpine |
воркер читает отчёт и артефакты служебным образом | UTILITY_IMAGE из своего реестра |
gitlab.com:22, github.com:22 |
Code Downloader при каждом запуске | измените "Команду запуска" джобы |
| Внешние сервисы сканеров: Snyk, Vulners, облачные API, LLM-провайдеры; базы и правила Trivy, Nuclei, Semgrep | только у джоб, которые их используют | не включайте такие джобы в последовательности, подготовьте базы и правила в реестре площадки или разрешите адреса явно |
| Jira, системы контроля версий, OIDC, адреса уведомлений | при включённых интеграциях | разрешайте адреса по списку интеграций |
Подробнее - Закрытый контур.