Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

П32. CodeScoring offline architecture

Цель

Зафиксировать фактическую архитектуру offline/on-premise-инсталляции CodeScoring в контуре Организации и доказать одно главное свойство: при работе в изолированном сегменте инсталляция не делает неучтённых внешних соединений, а база знаний об уязвимостях обновляется через контролируемый offline-пакет, а не «само из интернета». Проверяемый результат — карта компонентов развёртывания (приложение, PostgreSQL, Redis, том анализа), список сетевых потоков и подтверждённый способ доставки обновлений БДУ/NVD/OSV без выхода в сеть.

Команда или действие

Это не сканер-практика, а инфраструктурная приёмка. Действия — наблюдаемые и воспроизводимые:

# 1) Какие контейнеры подняты и какие порты они слушают (Docker Compose-вариант)
docker compose ps
docker compose config --services

# 2) PostgreSQL и Redis как сервисы данных (версии из требований: PG >= 15.x, Redis >= 7.0)
docker compose exec db psql -U postgres -c "select version();"

# 3) Том анализа — где хранятся исходники/артефакты проектов
docker volume ls
docker volume inspect <analysis-root-volume>

# 4) Главная проверка изоляции: реальные внешние соединения инсталляции
sudo ss -tunp | grep -vE '127\.0\.0\.1|::1|<внутренние-подсети>'
# или непрерывно во время одного полного скана:
sudo tcpdump -ni any 'not net <внутренние-подсети> and not port 22' -c 200

Для Kubernetes-варианта аналогично: kubectl get pods,svc -n codescoring, а изоляцию проверяют через NetworkPolicy и egress-логи.

Что именно считается «offline» Offline-режим CodeScoring подразумевает локальную базу-индекс (CodeScoring Index) с резервом диска от 300 ГБ под неё и дальнейшие обновления. Обновления знаний об уязвимостях приходят не из публичного интернета продакшен-сервера, а отдельным бандлом, который заносят в контур руками или через контролируемый шлюз. Задача практики — увидеть это в трафике, а не поверить документации на слово.

Что вы должны увидеть

docker compose ps показывает связку сервисов — ориентир по составу:

NAME                    SERVICE     STATUS      PORTS
codescoring-app-1       app         running     0.0.0.0:443->8443/tcp
codescoring-db-1        db          running     5432/tcp
codescoring-redis-1     redis       running     6379/tcp
codescoring-worker-1    worker      running

Главный критерий — пустой или объяснимый список внешних соединений. На ss/tcpdump во время полного скана не должно быть исходящих сессий на публичные адреса обогащения (никаких обращений к внешним vuln-фидам в реальном времени). Допустимый ориентир:

# Хорошо: только внутренние адреса контура и зеркало обновлений
ESTAB  app -> db:5432
ESTAB  app -> redis:6379
# Подозрительно: исходящее на публичный IP во время скана
ESTAB  app -> 140.82.x.x:443   <-- разобрать: что это и почему

База знаний после загрузки offline-бандла должна показывать свежую дату обновления в интерфейсе/служебном эндпоинте, а скан реального проекта — находить уязвимости из локальной базы, а не возвращать пусто.

Если не получилось

Критерий зачёта

Предъявить преподавателю: (1) схему развёртывания — какие сервисы, порты, том анализа, БД (docker compose ps / kubectl get); (2) доказательство изоляции — фрагмент ss/tcpdump, снятый во время полного скана, с пометкой, что внешних соединений к публичным фидам нет либо они объяснены; (3) подтверждённый способ обновления базы знаний offline-бандлом с зафиксированной датой. Гейт — none: практика готовит исходные данные для управленческого решения on-premise vs Offline, а не блокирует сборку.

Нормативная связка