English

Блокировать вредоносные компоненты через OSA Proxy¶

Контекст¶

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

OSA Proxy — это прокси-сервис CodeScoring, который перехватывает запросы пакетных менеджеров к удалённым репозиториям, проверяет компоненты и при необходимости блокирует их. В этом сценарии он разворачивается перед JFrog Artifactory, чтобы внутренний PyPI-репозиторий получал только те пакеты, которые прошли проверку по политикам безопасности.

Что получится¶

После прохождения сценария:

OSA Proxy будет развернут и настроен для PyPI в режиме strict;
JFrog Artifactory начнет получать пакеты через OSA Proxy, а не напрямую из внешнего источника;
блокирующая политика на этапе proxy будет останавливать вредоносные компоненты по условию Зависимость опасна;
результат проверки можно будет увидеть в разделе OSA -> Запросы.

Требования¶

Перед началом убедитесь, что есть:

хост или стенд, на котором можно развернуть OSA Proxy;
доступ к Docker или Kubernetes и образу OSA Proxy для выбранного способа установки;
доступ к application.yml OSA Proxy и возможность перезапустить сервис после изменения конфигурации;
JFrog Artifactory с удалённым PyPI-репозиторием, который можно перенастроить;
лицензия CodeScoring, в которой включен модуль OSA;
доступ в CodeScoring с правами на создание политик и просмотр данных OSA;
тестовый пакетный поток, на котором можно проверить работу схемы до её включения для всех команд.

Шаги¶

Шаг 1. Разверните OSA Proxy¶

Если сервис ещё не установлен, сначала нужно поднять его в отдельном окружении. Для первой проверки достаточно варианта с Docker.

Пример запуска OSA Proxy в Docker

docker run -d \
-p 8080:8080 \
-e SPRING_CONFIG_ADDITIONAL_LOCATION=file:/app/config/ \
-v /path/to/your/config/application.yml:/app/config/application.yml \
--name cs-proxy \
<registry-address>/cs-proxy:<tag>

Если используется Kubernetes, удобнее сразу развернуть сервис через Helm Chart. Оба варианта установки описаны в документации по развертыванию OSA Proxy.

После установки сервис должен быть доступен по своему URL и готов к загрузке конфигурации.

Шаг 2. Настройте OSA Proxy для PyPI и включите строгий режим¶

Теперь нужно включить такой режим работы, при котором непросканированные и запрещённые компоненты не будут проходить дальше во внутренний менеджер репозиториев.

Пример конфигурации OSA Proxy для PyPI

codescoring:
  host: https://codescoring.example.com
  token: <token>
  work-mode: strict
  enable-status-line: true
  block-status-code: 403

pypi:
  enabled: true
  repository:
    - name: internet-pypi
      scan-manifest: true
      scan-package: true
      url-encoded-config: true
      registry: https://pypi.org
      packages-registry: https://files.pythonhosted.org

Что важно в этой конфигурации:

work-mode: strict запрещает загрузку непросканированных компонентов;
scan-manifest: true позволяет убирать запрещённые версии из ответа Simple API;
scan-package: true включает проверку архивов пакетов;
enable-status-line: true помогает быстрее понимать причину блокировки при диагностике;
url-encoded-config: true нужен для сценария, где OSA Proxy получает контекст внутреннего репозитория через URL.

После сохранения application.yml перезапустите OSA Proxy.

Строгий режим лучше включать поэтапно

Новые запросы начнут фильтроваться сразу, но пакеты, которые уже успели попасть в кэш JFrog Artifactory раньше, сами не исчезнут. Поэтому безопаснее сначала проверить схему на отдельном удалённом репозитории и только потом переводить основной поток в strict.

Шаг 3. Поставьте OSA Proxy перед JFrog Artifactory¶

Теперь нужно сделать так, чтобы удалённый PyPI-репозиторий в JFrog Artifactory больше не обращался напрямую во внешний источник и получал пакеты только через OSA Proxy.

Откройте в JFrog Artifactory раздел Administration -> Repositories -> Remote.
Найдите удалённый PyPI-репозиторий, через который команды получают внешние Python-пакеты.
В поле URL укажите адрес OSA Proxy вместо прямого адреса PyPI.
Если удалённый репозиторий в JFrog Artifactory обращается напрямую во внешний PyPI, передайте OSA Proxy контекст внутреннего репозитория через Base64-параметры и используйте URL такого вида:
```
https://osaproxy.example.com/internet-pypi/eyJyZXBvTWFuYWdlckhvc3QiOiJodHRwczovL3B5cGkub3JnL3NpbXBsZSIsInJlcG9OYW1lIjoiaW50ZXJuZXQtcHlwaSJ9
```
В этом примере в строке Base64 закодирован такой JSON:
```
{"repoManagerHost":"https://pypi.org/simple","repoName":"internet-pypi"}
```
OSA Proxy использует эти параметры, чтобы понять, к какому внутреннему репозиторию относится запрос и какие политики к нему применять.
В дополнительных настройках JFrog Artifactory включите флаг Bypass HEAD requests.
Сохраните изменения.

После этого новые запросы к внешнему PyPI начнут проходить через OSA Proxy.

Шаг 4. Создайте блокирующую политику для вредоносных компонентов¶

Теперь нужно задать правило, которое будет срабатывать на этапе proxy и запрещать компонент, если он попадает под критерий Зависимость опасна.

Перейдите в Настройки -> Политики.
Нажмите Создать.
Заполните основные поля:
- Название — например, Опасная зависимость на этапе proxy;
- Этапы — proxy;
- Компоненты OSA — Пакеты;
- Активно — включите;
- Блокер — включите.
Если правило должно действовать только для одного канала поставки, выберите нужный репозиторий. Если защита нужна для всех прокси-репозиториев, оставьте это поле пустым.
Добавьте условие:
- Зависимость опасна.
Нажмите Создать.

Блокирующую политику лучше сначала проверять на пилотном репозитории

На этапе proxy блокер влияет не на отчет, а на сам факт получения компонента. Если правило сразу повесить на основной репозиторий без пилотной проверки, можно внезапно остановить привычные запросы команд разработки и сборок.

После сохранения OSA Proxy сможет применять это правило к новым запросам на получение пакетов.

Шаг 5. Проверьте, что клиент больше не видит запрещённые версии¶

В этой проверке удобнее смотреть не на установку конкретного пакета, а на то, какой ответ получает клиент от индекса пакетов после фильтрации версий.

В этом примере клиент запрашивает список доступных версий requests через OSA Proxy и получает уже отфильтрованный ответ Simple API. Если опасной версии нет в ответе, пакетный менеджер не сможет выбрать её для установки.

Шаг 6. Проверьте результат в `OSA -> Запросы`¶

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

Перейдите в раздел OSA -> Запросы.
Откройте вкладку Пакеты.
Найдите запрос, выполненный через пилотный PyPI-репозиторий.
Проверьте, что в списке видны:
- название пакета;
- режим работы;
- статус блокировки;
- дата запроса;
- инициатор запроса.

После этого уже можно проверить не только поведение клиента, но и то, что событие сохранилось в самой платформе.

Результат¶

Сценарий можно считать завершённым, если:

OSA Proxy развернут и работает в режиме strict для PyPI-источника;
JFrog Artifactory получает пакеты через OSA Proxy;
в CodeScoring создана активная блокирующая политика на этапе proxy с условием Зависимость опасна;
клиент получает отфильтрованный ответ индекса, а в OSA -> Запросы видно зафиксированный запрос и его статус.

После этого вредоносные и запрещённые компоненты можно останавливать ещё до того, как они окажутся во внутреннем репозитории и станут доступны командам разработки.

Что дальше¶

Страница была полезна?