8. Защита приложений

Рекомендации по защите приложения от роботной активностиРекомендации по защите приложения от роботной активности

8.1 Используется Yandex SmartCaptcha8.1 Используется Yandex SmartCaptcha

Для снижения рисков, связанных с автоматизированными атаками на приложения, рекомендуем использовать сервис Yandex SmartCaptcha. Сервис проверяет запросы пользователей своими ML-алгоритмами и показывает задание только тем пользователям, запросы которых посчитал подозрительными. При этом на странице необязательно размещать кнопку Я не робот.

Инструкции и решения по выполнению:

Инструкция по созданию капчи в Yandex SmartCaptcha.

Рекомендации по построению безопасного пайплайнаРекомендации по построению безопасного пайплайна

Yandex Cloud позволяет клиентам выстроить соответствие разрабатываемого ПО по всем уровням Supply-chain Levels for Software Artifacts (SLSA), при соблюдении инструкций в данном разделе. При использовании Yandex Managed Service for GitLab, клиент автоматически достигает соответствия до 2 уровня SLSA включительно.

8.2 Docker-образы сканируются при загрузке в Yandex Container Registry8.2 Docker-образы сканируются при загрузке в Yandex Container Registry

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

Инструкции и решения по выполнению:

Инструкция по сканированию Docker-образа при загрузке.

8.3 Выполняется периодическое сканирование Docker-образов, хранящихся в Container Registry8.3 Выполняется периодическое сканирование Docker-образов, хранящихся в Container Registry

Сканирование Docker-образов по расписанию представляет собой автоматизированный процесс проверки контейнерных образов на наличие уязвимостей и соответствие стандартам безопасности. Такое сканирование выполняется регулярно и автоматически, что обеспечивает консистентность проверки образов на наличие уязвимостей. Это позволяет поддерживать высокий уровень безопасности в долгосрочной перспективе. После завершения сканирования отчеты содержат краткое описание обнаруженных уязвимостей и проблем, помогая определять приоритеты и устранять риски безопасности в контейнерных приложениях.

Рекомендуем настроить расписание сканирования не реже, чем раз в неделю.

Инструкции и решения по выполнению:

Инструкция по сканированию Docker-образа по расписанию.

8.4 Контейнерные образы, используемые в продакшн-среде, имеют последнюю дату сканирования не позднее недели8.4 Контейнерные образы, используемые в продакшн-среде, имеют последнюю дату сканирования не позднее недели

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

export ORG_ID=<ID_организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for REGISTRY_ID in $(yc container registry list --folder-id $FOLDER_ID --format=json | jq -r '.[].id');
do for IMAGE_ID in $(yc container image list --registry-id $REGISTRY_ID --format=json | jq -r '.[].id';)
do LAST_SCAN_DATE=$(yc container image get-last-scan-result --image-id $IMAGE_ID --format=json 2>/dev/null | jq -r '.scanned_at');
[ ! -z "$LAST_SCAN_DATE" ] && [ $(date --date "$LAST_SCAN_DATE" +'%s') -lt $(date --date '7 days ago' +'%s') ] && echo "Regitry ID - $REGISTRY_ID, Image ID - $IMAGE_ID, Last scan date - $LAST_SCAN_DATE"
done;
done;
done;
done

8.5 При сборке артефактов применяются аттестации8.5 При сборке артефактов применяются аттестации

Аттестации применяются при сборке артефактов, чтобы обеспечить безопасную и поддающуюся проверке запись о происхождении артефакта, его целостности и соответствии политикам безопасности SBOM. Это помогает обеспечить надежность артефакта на протяжении всего жизненного цикла. SBOM необходим для обеспечения безопасности цепочки поставок, управления уязвимостями, соответствия требованиям, оценки рисков, прозрачности и эффективного реагирования на инциденты.

При использовании Managed Service for GitLab процесс применения аттестаций становится проще, потому что сервис имеет функцию генерации provenance attestation. SBOM может быть сгенерирован с использованием стороннего ПО syft.

Инструкции и решения по выполнению:

Инструкция от Gitlab по аттестации артефактов.

8.6 Обеспечивается целостность артефактов8.6 Обеспечивается целостность артефактов

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

Инструкции и решения по выполнению:

Артефакты в рамках пайплайна можно подписывать с помощью стороннего ПО Cosign для подписи артефактов, образов и in-to-to аттестаций, чтобы в дальнейшем загрузить их в Yandex Container Registry.

С помощью специальной сборки утилиты Cosign сохраняйте созданную ключевую пару электронной подписи в сервисе Yandex Key Management Service, подписывайте файлы и артефакты закрытым ключом этой ключевой пары и проверяйте электронную подпись с помощью ее открытого ключа.

Подробнее см. в разделе Подпись и проверка Docker-образов Container Registry в Yandex Managed Service for Kubernetes.

8.7 Выполняется проверка подлинности артефактов при развертывании8.7 Выполняется проверка подлинности артефактов при развертывании

Чтобы обеспечить надежность, безопасность и совместимость приложений в Managed Service for Kubernetes, сервисе для автоматического масштабирования и развертывания приложений, необходимо свести к минимуму риск возникновения проблем, уязвимостей и сбоев во время развертывания и выполнения. Для этого используется подпись и проверка подписи в Managed Service for Kubernetes с помощью Cosign и Kyverno.

Инструкции и решения по выполнению:

Инструкция по настройке подписи артефактов.

8.8 Применяются защищенные шаблоны безопасного пайплайна8.8 Применяются защищенные шаблоны безопасного пайплайна

При работе с Managed Service for GitLab убедитесь, что вы применяете встроенные механизмы безопасности GitLab для защиты вашего пайплайна. Доступны следующие варианты использования пайплайна в ваших проектах:

• Создание пайплайна в отдельном проекте и подключение его к другим проектам с помощью функции include. Доступно для всех типов лицензий.
• Использование механизма Compliance framework and pipeline, который будет выполняться в любом проекте группы. Механизм доступен для типа лицензии Ultimate.
• Копирование секции пайплайна в файлы .gitlab-ci.yml ваших проектов.

8.9 Используется профиль безопасности Yandex Smart Web Security8.9 Используется профиль безопасности Yandex Smart Web Security

Yandex Smart Web Security — сервис для защиты от DDoS-атак и ботов на прикладном уровне L7 сетевой модели OSI. Smart Web Security подключается к Yandex Application Load Balancer.

Функциональность сервиса сводится к проверке HTTP-запросов к защищаемому ресурсу на соответствие правилам, заданным в профиле безопасности. В зависимости от результатов проверки запросы пропускаются на защищаемый ресурс, блокируются или отправляются в сервис Yandex SmartCaptcha для дополнительной верификации.

Инструкции и решения по выполнению:

Создание профиля безопасности и подключение его к виртуальному хосту L7-балансировщика.

8.10 Используется Web Application Firewall8.10 Используется Web Application Firewall

Для снижения рисков, связанных с веб-атаками, рекомендуем использовать Yandex Smart Web Security Web Application Firewall (WAF). Web Application Firewall анализирует входящие HTTP-запросы к веб-приложению по предварительно настроенным правилам. На основе результатов анализа к HTTP-запросам применяются определенные действия.

Вы можете управлять межсетевым экраном веб-приложений с помощью профиля WAF, который подключается к профилю безопасности Smart Web Security в виде отдельного правила.

Инструкции и решения по выполнению:

Создание профиля WAF и подключение его к профилю безопасности Smart Web Security.

8.11 Используется Advanced Rate Limiter8.11 Используется Advanced Rate Limiter

Advanced Rate Limiter (ARL) — модуль для контроля и ограничения нагрузки на веб-приложения. Модуль позволяет установить лимит на количество HTTP-запросов за определенный промежуток времени. Все запросы сверх лимита будут блокироваться. Можно установить как единый лимит на весь трафик, так и настраивать отдельные лимиты для сегментирования запросов по определенным параметрам. Запросы для лимитов можно считать по одному или объединять в группы по заданному признаку.

Профиль ARL необходимо подключить к профилю безопасности Smart Web Security.

Инструкции и решения по выполнению:

Создание профиля ARL и подключение его к профилю безопасности Smart Web Security.

8.12 Настроены правила ревью кода8.12 Настроены правила ревью кода

Yandex Managed Service for GitLab позволяет гибко настраивать обязательные правила ревью кода, прежде чем этот код может быть добавлен в целевую ветку проекта. Функциональность является альтернативой встроенному в GitLab Enterprise Edition инструменту Approval Rules и доступна вне зависимости от версии GitLab.

Если в инстансе GitLab включены правила ревью кода, Managed Service for GitLab анализирует подтверждения от ревьюеров на соответствие заданным правилам. Если подтверждений недостаточно, в мерж-реквесте создается техническая дискуссия, блокирующая его интеграцию в целевую ветку. При изменении мерж-реквеста в дискуссии создается или обновляется комментарий с текущим статусом соответствия правилам. Когда все необходимые подтверждения получены, дискуссия закрывается.

Если закрыть техническую дискуссию вручную, она будет создана заново. В случае интеграции мерж-реквеста в обход заданных правил пользователи с ролью Maintainer и выше получат уведомление на электронную почту о нарушении установленного процесса ревью кода.

Инструкции и решения по выполнению:

Активация правил ревью кода в инстансе GitLab.