Yandex Security Deck |

Статья создана

Yandex Cloud

Обновлена 22 сентября 2026 г.

Открыть в Markdown

Cloud Security Posture Management (CSPM)

Cloud Security Posture Management (CSPM)

Правила для проверки конфигурации облачных ресурсов.

API-ключи для сервисов AI Studio должны иметь ограничение срока действия

kind	severity	ID
automatic	medium	ai.api-key-rotation

Описание

Как работает правило: проверяется, что ключи API-ключи, созданные для работы в AI Studio, имеют установленный срок действия.

Yandex Cloud позволяет задавать срок действия API-ключей, но максимальное время жизни должно определяться организационной политикой.

Рекомендуемое время жизни по умолчанию — 90 дней для обычных систем и 30 дней для высокорисковых ИИ-систем и ИИ-агентов. Статические ключи доступа, совместимые с AWS API, и авторизованные ключи могут не иметь ограничение срока действия, заданное на сервере, поэтому для них требуется ручная или автоматизированная ротация по параметру createdAt и удаление неиспользуемых ключей.

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

Получите все типы ключей для каждого сервисного аккаунта, который используется в компонентах AI, MCP, DataSphere:
```
yc iam api-key list --service-account-id <sa-id> --format json 
```
Если у полученных ключей не задано значение в поле expires at, срок действия не ограничен.
Перевыпустите ключи без ограничения срока действия и обязательно задайте срок действия.

API-ключи для сервисов AI Studio должны иметь ограниченные области действия

kind	severity	ID
automatic	medium	ai.api-key-scopes

Описание

Как работает правило: проверяются API-ключи с заданными областями действия в AI Studio, выводится список ключей с обширным областями действия.

Область действия API-ключа должна соответствовать минимально необходимому действию. Если при создании API-ключа через CLI/API/Terraform вы не указываете область действия, применяется широкий набор областей по умолчанию. Такой ключ часто получает доступ не только к операциям в ИИ-сервисах, но и к Monitoring, Search API, Serverless Functions/Containers invoke.

Область действия API-ключа нельзя изменить после создания; решение — перевыпуск ключа с минимальным набором областей действия и удаление старого ключа после миграции потребителей.

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

Получите API-ключи сервисного аккаунта:
```
yc iam api-key list --service-account-id <sa-id> --format json 
```
Для каждого ключа получите детали:
```
yc iam api-key get --id <key-id> --format json 
```
Список областей действия API-ключа, созданного через CLI/API/Terraform без указания областей: yc.ai.imageGeneration.execute, yc.ai.languageModels.execute, yc.ai.speechkitStt.execute, yc.ai.speechkitTts.execute, yc.ai.translate.execute, yc.ai.vision.execute, yc.monitoring.manage, yc.search-api.execute, yc.serverless.containers.invoke, yc.serverless.functions.invoke.

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

Минимальные рекомендуемые профили:
- Text generation only: yc.ai.languageModels.execute
- Image generation only: yc.ai.imageGeneration.execute
- Speech-to-text only: yc.ai.speechkitStt.execute
- Text-to-speech only: yc.ai.speechkitTts.execute
- Translate only: yc.ai.translate.execute
- Vision/OCR only: yc.ai.vision.execute
- MCP invoke only: yc.serverless.mcpGateways.invoke
- Workflow execution only: yc.serverless.workflows.execute
Дополнительные доступные области действия, которые не должны появляться без явной необходимости: yc.monitoring.manage, yc.monitoring.read, yc.search-api.execute, yc.serverless.functions.invoke, yc.serverless.containers.invoke, yc.serverless.workflows.execute, yc.serverless.mcpGateways.invoke, yc.logging.write, yc.datasphere.community-projects.manageResource, yc.speech-sense.use и другие области действия из актуального справочника API-ключей.
Если вы создали ключ через интерфейс AI Studio, не полагайтесь на источник создания. Всегда проверяйте фактические области действия ключа.

Перевыпустите ключ с минимальным набором областей:

yc iam api-key create --service-account-id <sa-id> --scopes <scope1>,<scope2> --expires-at <iso8601>

Обновите потребителей, затем удалите старый ключ:
```
yc iam api-key delete --id <old-key-id> 
```
В Terraform используйте актуальный атрибут scopes = [...]. Не используйте lifecycle.ignore_changes для областей, если цель контроля — обнаруживать и исправлять drift.

У сервисных аккаунтов сервиса Yandex DataSphere должны отсутствовать критичные роли

kind	severity	ID
automatic	medium	ai.datasphere-sa-privileges

Описание

Как работает правило: проверяется, что у сервисных аккаунтов, привязанных к сообществам или проектам Yandex DataSphere, нет ролей выше editor.

В DataSphere пользовательский ML-код, задания и операции с DataSphere Notebook могут выполняться от имени сервисного аккаунта или сервисного агент проекта или сообщества, поэтому для них требуется строго соблюдать принцип минимальных привилегий. Особенно опасны роли, позволяющие управлять сервисом Yandex Identity and Access Management, сервисными аккаунтами, секретами, ключами шифрования, объектными хранилищами, виртуальными машинами и сетями или ИИ-ресурсами.

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

Получите список проектов и сообществ DataSphere:
```
yc datasphere community list --format json yc datasphere project list --community-id <id> --format json 
```
Если команды CLI недоступны в вашей версии, используйте REST API или выгрузку через UI:
- Список сообществ
- Список проектов
Для каждого проекта или сообщества определите связанный сервисный аккаунт или агент. Если поле недоступно через CLI/API, посмотрите в интерфейсе Datasphere.
Проверьте выданные доступы этих сервисных аккаунтов с помощью Модуля диагностики доступов (CIEM).
Актуальные роли DataSphere, которые нужно сверять со справочником ролей Yandex Identity and Access Management перед запуском сканера: datasphere.community-projects.viewer, datasphere.community-projects.developer, datasphere.community-projects.editor, datasphere.community-projects.admin, datasphere.communities.viewer, datasphere.communities.developer, datasphere.communities.editor, datasphere.communities.admin.
Если конкретная роль отсутствует в tenant или справочнике, сканер не должен прекращать задание; логируйте role not found / not applicable.
Запрещенные роли для среды выполнения/сервисных аккаунтов в DataSphere без исключения: admin, editor, resource-manager.clouds.owner, resource-manager.admin, iam.serviceAccounts.admin, iam.serviceAccounts.tokenCreator, lockbox.admin, lockbox.editor, kms.admin, kms.editor, storage.admin, compute.admin, vpc.admin, datasphere.communities.admin, datasphere.communities.editor, datasphere.community-projects.admin, datasphere.community-projects.editor, ai.admin, ai.editor, ai.models.admin, ai.models.editor, любые ненужные *.admin / *.editor.
Разрешайте только минимальные роли к реально используемым ресурсам, например:
- storage.viewer / upload-роли только на конкретный бакет;
- lockbox.payloadViewer только на конкретный секрет;
- ai.models.user или конкретные ai.*.user роли, если проект реально вызывает модели;
- минимальные роли на логирование и мониторинг только при необходимости.
Решение: удалить широкие роли, создать отдельный сервисный аккаунт для проекта или сообщества, назначить минимальные роли на минимальном списке ресурсов, провести повторное сканирование.

Для разных инструментов, агентов и MCP-серверов должны использоваться разные сервисные аккаунты

kind	severity	ID
automatic	low	ai.mcp-sa-duplicate

Описание

Как работает правило: проверяются сервисные аккаунты, назначенные на MCP-сервер, Cloud Functions, Workflows. Если один сервисный аккаунт назначен на более чем один объект, правило считается нарушенным.

Сервисный аккаунт должен соответствовать одной границе безопасности. Не всегда обязательно следовать принципу «один сервисный аккаунт строго на один ресурс»: допустимо использовать один аккаунт внутри одного утвержденного логического агента, если MCP Gateway, функция Cloud Functions и Workflow являются частью одной границы безопасности, имеют одного владельца, одну классификацию данных и одинаковый набор минимальных доступов. Но общий сервисный аккаунт между независимыми агентами, MCP Gateway, проектами DataSphere или Tools создает избыточный потенциальный ущерб. Development, staging и production должны использовать разные сервисные аккаунты.

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

Получите инвентаризацию всех компонентных типов: MCP Gateway, Functions, Containers, Workflows, проектов и сообществ DataSphere, AI Assistants, agent wrappers.
Для каждого ресурса сохраните type, id, name, folderId, owner, dataClass, environment, serviceAccountId.
Для Serverles-ресурсов получите сервисные аккаунты:
```
yc serverless mcp-gateway get --name <name> --format json 
```
Используйте разные сервисные аккаунты для разных инструментов, агентов и MCP-серверов. Рекомендуется выдавать точечные роли для сервисного аккаунта при работе с MCP-серверами, например serverless.mcpGateways.viewer.

Не используйте сервисные аккаунты с высокими привилегиями для MCP-серверов, функций и рабочих процессов

kind	severity	ID
automatic	high	ai.mcp-sa-privileges

Описание

Как работает правило: у сервисных аккаунтов проверяется наличие прав выше роли editor, назначенных на MCP-серверы, функции и рабочие процессы, реализующие Tools или отдельных шагов таких рабочих процессов.

Через компрометацию сервисного аккаунта, от имени которого выполняется агентский workload, злоумышленник может получить доступ за пределы одного Tool или Gateway.

Для MCP-серверов и агентских workloads особенно опасны роли управления сервисом Yandex Identity and Access Management, сервисными аккаунтами, секретами Lockbox, ключами KMS, контейнерами Serverless, объектными хранилищами, и роль organization-manager.

Примитивные роли admin и editor недопустимы для сервисного аккаунта, от имени которого выполняется агентский workload, без исключения. Роли чтения viewer и auditor не всегда административные, но могут приводить к утечке данных и требуют отдельного обоснования необходимости .

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

Получите инвентаризацию MCP Gateway, Functions, Containers и Workflows.
Для каждого ресурса определите serviceAccountId:
```
yc serverless function get --name <name> --format json 
```
Отзовите доступы с помощью Модуля диагностики доступов (CIEM).

К публичным MCP-серверам не следует подключать непубличные функции, workflows и Tools, требующие авторизации

kind	severity	ID
automatic	medium	ai.public-mcp-tools

Описание

Как работает правило: проверяется, что привязанные к MCP-серверу функции, workflows и Tools являются публичными.

Это сценарий, в котором может быть реализована уязвимость Confused Deputy и в котором может произойти злоупотребление прокси (proxy abuse): внешний субъект использует публичный MCP Gateway как посредника для вызова внутреннего Tool.

Риск возникает даже если сам Tool не публичен напрямую: достаточно, что публичный Gateway имеет сервисный аккаунт с доступом с доступом, который позволяет обращаться к внутреннему Tool.

Контроль связан с OWASP MCP07:2025 Insufficient Authentication & Authorization и рисками избыточных полномочий.

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

Найдите публичные MCP Gateway, используя проверку по правилу Используйте публичные MCP-серверы только при необходимости.

Получите список Tools публичного Gateway:

yc serverless mcp-gateway get --name <gateway-name> --format json

Используйте публичные MCP-серверы только при необходимости

kind	severity	ID
automatic	medium	ai.public-mcp

Описание

Как работает правило: проверятся, является ли публичным созданный MCP-сервер

MCP Gateway должен быть приватным по умолчанию. Публичный доступ расширяет поверхность атаки и создает риск несанкционированного вызова Tools и агентской логики. Особенно опасна привязка к публичной группе allUsers с ролью serverless.mcpGateways.anonymousInvoker, так как она разрешает анонимный вызов MCP Gateway.

Доступ на группу allAuthenticatedUsers с ролью, позволяющей вызывать ресурс или сервис, также считается публичным, хотя и требует аутентификации в Yandex Cloud.

Контроль соответствует OWASP MCP07:2025 Insufficient Authentication & Authorization.

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

Получите список MCP Gateway:

yc serverless mcp-gateway list --format json

Для каждого Gateway проверьте доступ на публичную группу:
```
yc serverless mcp-gateway list-access-bindings --name <name> --format json 
```

Не выдавайте привилегированные роли в ИИ-сервисах системным группам и группам с большим количеством субъектов

kind	severity	ID
automatic	medium	ai.system-groups

Описание

Как работает правило: проверяется наличие системных групп в организации.

Привилегированные AI- и MCP-роли должны выдаваться узким группам только при условии, что они действительно нужны для выполнения конкретной задачи. Особенно опасны ai.admin, ai.editor, роли для управления моделями, датасетами, AI Assistant, MCP Gateway и роли для модерации ответов моделей.

Публичные и системные группы для таких ролей недопустимы. Для ролей чтения viewer и auditor и ролей *userриск ниже, но широкая выдача все равно требует пересмотра.

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

Получите привязки доступа организации:

yc organization-manager organization list-access-bindings --id <org-id> --format json

Также проверьте привязки на уровне каталога и облака, если AI- и MCP-роли назначаются ниже уровня организации.
Роли критичного и высокого уровня риска для широких групп: ai.admin, ai.editor, ai.models.admin, ai.models.editor, ai.datasets.admin, ai.datasets.editor, ai.guardrails.admin, ai.guardrails.editor, ai.assistants.admin, ai.assistants.editor, serverless.mcpGateways.admin, serverless.mcpGateways.editor.
Роли среднего риска и потенциально опасные роли для широких групп: ai.viewer, ai.auditor, ai.models.user, ai.models.viewer, ai.datasets.user, ai.datasets.viewer, ai.guardrails.user, ai.guardrails.viewer, ai.assistants.user, ai.assistants.viewer, ai.languageModels.user, ai.imageGeneration.user, ai.translate.user, ai.vision.user, ai.speechkit-stt.user, ai.speechkit-tts.user, ai.playground.user, serverless.mcpGateways.invoker.
Перед внедрением в конкретном тенанте сверяйте имена ролей с актуальным справочником ролей. Если роль отсутствует в тенанте, сканер не должен прекращать задание; он должен выдавать сообщение role not found / not applicable.

Для групп получите состав:

yc organization-manager group list-members --group-id <id> --format json

Публичные и системные группы allUsers, allAuthenticatedUsers всегда нарушение для привилегированных ролей.
Порог широкой группы — параметр стандарта:
- по умолчанию: больше 50 уникальных идентичностей, привязанных к человеку (human subjects);
- для ролей высокого риска ai.admin, ai.editor, ai.models.admin, ai.models.editor, serverless.mcpGateways.admin, serverless.mcpGateways.editor — больше 10 идентичностей, привязанных к человеку (human subjects).
Решение: создайте узкую группу с владельцем, процессом одобрения выдачи прав и регулярным пересмотром доступов, перенесите роль на эту группу, удалите назначение прав с широкой группы или публичной группы.

Секреты, используемые MCP Gateway и Tools, рекомендуется хранить в сервисе Yandex Lockbox

kind	severity	ID
automatic	medium	ai.tool-secrets

Описание

Как работает правило: если в окружении есть ресурсы AI Studio, проверяется, что токены для подключения к Tools хранятся в сервисе Yandex Lockbox.

Секреты, используемые MCP Gateway и Tools, должны храниться в Yandex Lockbox.

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

Для Cloud Functions и Serverless Containers следует использовать штатную передачу секретов в runtime-конфигурацию, чтобы в версии функции или ревизии контейнера хранилась ссылка на секрет, а не значение.

Для Workflows секреты не должны передаваться через входные параметры; workflow должен получать содержимое секрета runtime-доступом к Lockbox или через поддерживаемую безопасную интеграцию.

Для внешних HTTP Tools заголовок не должен храниться в незашифрованном виде в конфигурации MCP Gateway.

Контроль соответствует риску OWASP MCP01:2025 Token Mismanagement and Secret Exposure.

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

Получите список MCP Gateway и прикрепленных Tools:
```
yc serverless mcp-gateway list --format json; 
```

Для каждого Gateway выполните:

yc serverless mcp-gateway get --name <gateway-name> --format json

Парольная политика соответствует требованиям стандарта PCI DSS 4.0

kind	severity	ID
automatic	low	access.password-policy.pci-dss

Описание

Как работает правило: правило автоматически проверяет, что парольная политика, заданная для пользователей пула, соответствует следующим требованиям:

новые пароли не должны быть похожи на предыдущие;
минимальная длина пароля — 12 символов, пароль содержит цифры, строчные и заглавные буквы;
срок жизни пароля — не более 90 дней;
количество неудачных попыток ввода пароля до блокировки — не более 6;
количество старых паролей, которые нельзя ввести заново при смене пароля — не более 4;
продолжительность блокировки — минимум 30 минут.

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

Парольная политика снижает эти риски. В Yandex Cloud существуют определенные рекомендации к парольной политике.

Парольная политика стандарта PCI DSS устанавливает требования к паролям пользователей:

Минимальная длина: 12 символов. Содержит буквы и цифры. Рекомендуются спецсимволы, заглавные и строчные буквы.
Требование 8.2.4: пользователи должны менять пароли минимум раз в 90 дней. При этом, если используется MFA, частая смена не обязательна.
Требование 8.2.5: новый пароль не должен совпадать с последними 4 паролями.
Требование 8.2.6: при первом входе или сбросе пароля пользователь обязан сменить временный пароль.

Дополнительные требования:

Требование 8.1.6: блокировка после 6 неудачных попыток входа. Длительность блокировки: минимум — 30 минут или до разблокировки администратором.
Требование 8.1.8: автоматический выход после 15 минут неактивности.
Требование 8.3: многофакторная аутентификация (MFA) обязательна для всех удаленных доступов к CDE (Cardholder Data Environment) и обязательна для административных доступов.

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

Войдите в сервис Yandex Identity Hub с учетной записью администратора или владельца организации.
На панели слева нажмите Пулы пользователей и выберите нужный пул пользователей.
Перейдите на вкладку Обзор → Парольная политика → Настроить политику.
В блоке Сложность пароля:
- В поле Обязательные выберите типы символов, которые должны использоваться в пароле, активируя следующие опции:
  - Строчные буквы латинского алфавита;
  - Заглавные буквы латинского алфавита;
  - Цифры.
- В поле Минимальная длина задайте минимальное число символов в пароле — 12 символов.
В блоке Уникальность пароля в поле Проверка пароля при необходимости включите опцию Нельзя использовать пароль из базы распространенных паролей. Это защитит пользователей от установки паролей, которые легко подбираются по словарю.
В блоке Срок жизни пароля задайте максимальный срок жизни пароля — не более 90 дней.
В блоке Защита пароля от подбора задайте:
- Количество неудачных попыток ввода пароля до блокировки — не более 6.
- Интервал для подсчета неудачных попыток в минутах.
- Продолжительность блокировки в минутах — минимум 30 минут.

Администратор облака получает уведомление в случае компрометации секретов его облака

kind	severity	ID
automatic	information	crypto.leaked-secrets-detection

Описание

Как работает правило: проверяется, что в окружении включен набор требований Базовые требования модуля Обнаружение угроз и правило Облачный секрет обнаружен в открытом доступе не добавлено в исключения.

Модуль Обнаружение угроз (TD) анализирует события аудита, фиксируемые в инфраструктуре клиента и регистрируемые с помощью сервиса Yandex Audit Trails. Позволяет в автоматическом режиме обнаруживать подозрительную активность и уведомлять пользователя об обнаруженных угрозах.

В набор требований модуля входит проверка Облачный секрет обнаружен в открытом доступе. Эта проверка направлена на выявление случаев, когда обнаруживаются утечки учетных данных в облаке, таких как API-ключи, токены, ключи доступа, OAuth-токены и другие секреты, связанные с IAM (Identity and Access Management).
Учетные данные, такие как ключи доступа или токены, предоставляют прямой доступ к ресурсам облака, и их попадание в публичные или ненадежные источники (например, в репозитории кода, логи или на сторонние сайты) может привести к компрометации безопасности, несанкционированному доступу и потере контроля над инфраструктурой.

Правило срабатывает при обнаружении утечки секретов в системе мониторинга, определяя тип утекшего секрета (например, IAM-токен, API-ключ, ключ доступа сервисного аккаунта, секрет из Lockbox и др.), и указывает, к какому сервисному аккаунту он привязан. Также фиксируется URL, на котором был обнаружен секрет.

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

Включите проверку по требованиям Базовые требования модуля Обнаружение угроз:

Перейдите в сервис Security Deck.
На панели слева выберите Окружение и в открывшемся окне выберите нужное окружение Security Deck.
Нажмите кнопку Параметры окружения.
Перейдите на вкладку Модули контроля.
Раскройте список стандартов для модуля Обнаружение угроз (TD).

Совет

Если модуля нет в списке, обратитесь к менеджеру за доступом.
Включите опцию Базовые требования модуля Обнаружение угроз.

Кластеры Kubernetes проверяются на соответствие требованиям CIS

kind	severity	ID
automatic	information	k8s.cis

Описание

Как работает правило: проверяется, что включен набор правил CIS Benchmark для Kubernetes, если в области контроля модуля Контроль Kubernetes (KSPM) есть кластеры и узлы Kubernetes.

Набор правил CIS Benchmark для Kubernetes — это один из стандартов безопасности модуля KSPM, которые можно подключить к окружению Security Deck. Он реализует рекомендации международного стандарта CIS Kubernetes Benchmark и содержит правила проверки безопасной конфигурации компонента kubelet на рабочих узлах кластера.

Kubelet имеет широкие полномочия (управление подами, доступ к секретам, логам, exec в контейнеры), поэтому его небезопасная конфигурация — один из самых опасных векторов повышения привилегий в кластере.

Правила набора помогают обнаруживать ключевые классы угроз:

несанкционированный доступ к API kubelet;
аутентификация по сертификатам между apiserver и kubelet;
ротация сертификатов;
права доступа к конфигурационным файлам (kubelet.conf, config.yaml, файл службы);
режим авторизации и разрешение kubelet управлять iptables.

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

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

Включите проверку по требованиям CIS Benchmark для Kubernetes:

Перейдите в сервис Security Deck.
На панели слева выберите Окружение и в открывшемся окне выберите нужное окружение Security Deck.
Нажмите кнопку Параметры окружения.
Перейдите на вкладку Модули контроля.
Раскройте список стандартов для модуля Контроль Kubernetes (KSPM).
Включите опцию Требования стандарта CIS Benchmark™ для Kubernetes.

Кластер Managed Kubernetes является региональным

kind	severity	ID
automatic	medium	k8s.disallow-k8s-not-regional

Описание

Как работает правило: проверяется, что кластер Managed Kubernetes является региональным.

Региональный кластер Kubernetes — это кластер, в котором управляющие узлы и рабочие узлы распределены по нескольким зонам доступности в рамках одного географического региона.

Региональный кластер соответствует требованиям информационной безопасности:

Обеспечение непрерывности бизнеса.
Выполнение требований регуляторов (Compliance) ГОСТ Р 57580, 152-ФЗ.

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

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

Создайте отдельную облачную сеть для кластера. Не используйте сеть совместно с другими сервисами.
Создайте по одной подсети в каждой из трех зон доступности: ru-central1-a, ru-central1-b и ru-central1-d. Разместите мастер и группы узлов в этих подсетях.
Используйте непересекающиеся диапазоны IP-адресов для подсетей, подов и сервисов. Заранее спланируйте адресное пространство с учетом роста кластера.
Настройте группы безопасности до создания кластера. Разрешите только необходимый трафик: между мастером и узлами, между узлами, от балансировщиков нагрузки.
Если кластеру не требуется доступ в интернет, создайте его без публичного IP-адреса и настройте доступ через NAT-шлюз или Yandex Cloud Interconnect.

Исходящий доступ в интернет контролируется

kind	severity	ID
automatic	information	network.check-outgoing-internet-connection

Описание

Как работает правило: правило обеспечивает инвентаризацию ресурсов с внешними сетевыми доступами через внешний IP-адрес в настройках ВМ или при наличии NAT-Gateway.

Контроль исходящего (egress) трафика — это одна из фундаментальных мер сетевой безопасности. Она помогает предотвратить утечку данных и использование вашей инфраструктуры для атак на другие сервисы и системы, снижает риски разделяемого IP-адреса. Без контроля исходящего трафика нет видимости того, куда и какие данные уходят из инфраструктуры. Это делает невозможным обнаружение аномалий и расследование инцидентов безопасности.

Риски при невыполнении:

Использование инфраструктуры для атак — скомпрометированная ВМ может стать источником DDoS, сканирования портов и перебора паролей на внешние ресурсы.
Утечка данных (Data Exfiltration) — без ограничений egress-трафика вредоносное ПО или инсайдер беспрепятственно выгружает данные наружу.
C2-коммуникации — вредоносное ПО устанавливает канал управления через неконтролируемый исходящий трафик.
Нарушение модели угроз в изолированных средах — несанкционированное создание публичного IP или NAT-шлюза полностью разрушает изоляцию защищенной среды.
Риск разделяемого IP (Egress NAT) — общий пул адресов может привести к попаданию в блок-листы из-за действий других арендаторов.
Отсутствие аудита — невозможность расследования инцидентов и несоответствие требованиям регуляторов.

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

В случае наличия публичных адресов на ВМ убедитесь, что они необходимы. В противном случае удалите внешний IP-адрес в настройках ВМ.
В случае наличия NAT-Gateway убедитесь, что он необходим. В противном случае удалите его.
Чтобы удалить публичный IP-адрес с ВМ:

Перейдите в сервис Compute Cloud.
Выберите виртуальную машину.
В секции Сеть в правом верхнем углу блока нужного сетевого интерфейса нажмите на значок ... и выберите Отвязать публичный IP-адрес.
В открывшемся окне нажмите кнопку Удалить.

Чтобы удалить NAT-шлюз:

Перед удалением NAT-шлюза отвяжите его от всех таблиц маршрутизации, в которых он используется.
Перейдите в сервис Virtual Private Cloud.
На панели слева выберите Шлюзы.
Нажмите на значок ... в строке с именем нужного NAT-шлюза и выберите Удалить.
В открывшемся окне нажмите кнопку Удалить.

Настроено реагирование на события безопасности

kind	severity	ID
automatic	medium	o11y.audit-trails-reactions

Описание

Как работает правило: правило проверяет, что в окружении Security Deck включен модуль Обнаружение угроз (TD).

Риски при невыполнении правила:

Без уведомлений организация не узнает своевременно об угрозах в реальном времени в используемых сервисах. Это увеличивает время реакции на угрозу и повышает вероятность успешной эксплуатации уязвимости злоумышленником.
Аномальная активность (например, несанкционированные операции с ресурсами) может остаться незамеченной. Инцидент развивается без реагирования, что увеличивает масштаб ущерба.

Модуль Обнаружение угроз (TD) представляет собой первую линию реагирования на инциденты безопасности в облачной инфраструктуре пользователя в Yandex Security Deck. Позволяет в автоматическом режиме обнаруживать подозрительную активность и уведомлять пользователя об обнаруженных угрозах.

Модуль Обнаружение угроз анализирует события аудита, фиксируемые в инфраструктуре клиента и регистрируемые с помощью сервиса Yandex Audit Trails.

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

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

Включите модуль Обнаружение угроз (TD) при создании окружения в Security Deck. Подробнее в инструкции.

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

Настроена двухфакторная аутентификация для всех локальных пользователей

kind	severity	ID
automatic	high	access.userpool-mfa

Описание

Как работает правило: проверяется, что двухфакторная аутентификация (2FA) включена для пула пользователей или организации.

Риски при невыполнении правила:

Компрометация пароля предоставляет полный доступ к облаку.
Риски утечки и потери данных: кража конфиденциальных данных, шифрование данных с целью вымогательства и т. д.
Риски для инфраструктуры: удаление виртуальных машин и дисков без возможности восстановления, изменение DNS-записей для перенаправления трафика и т. д.
Риски, связанные с сервисом Identity and Access Management, и использованием сервисных аккаунтов: создание новых пользователей с правами администраторов, кража API-ключей и сервисных аккаунтов, получение долгосрочного скрытого доступа.

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

Настройте двухфакторную аутентификацию для всех локальных пользователей в сервисе Yandex Identity Hub.

Двухфакторная аутентификация дает возможность повысить степень защищенности учетных записей пользователей за счет использования в процессе аутентификации в дополнение к паролю еще одного фактора — одноразового кода (в приложении-аутентификаторе по стандарту TOTP или в SMS) или средства аутентификации по стандарту WebAuthn (FIDO2).

Требования многофакторной аутентификации, применяемые к пользователям, настраиваются в политиках MFA:

Создайте политику MFA в интерфейсе Yandex Identity Hub в Cloud Center.
Добавьте в целевые группы этой политики всех пользователей пула.

Выполняется периодическая ротация ключей сервисных аккаунтов

kind	severity	ID
automatic	high	iam.sa-key-rotation

Описание

В Yandex Cloud поддерживаются следующие ключи доступа, которые могут быть созданы для сервисных аккаунтов:

IAM-токены — действуют 12 часов;
API-ключи — можно выбрать любой срок действия;
авторизованные ключи — не имеют срока действия;
статические ключи доступа, совместимые с AWS API, — не имеют срока действия.

Ключи без срока действия требуется ротировать самостоятельно — удалять и создавать новые. Дату создания можно проверить в свойствах ключа. Рекомендуется ротировать ключи как минимум раз в 90 дней.

На данном контроле проверяется последняя дата обновления. В случаях, когда невозможно определить последнюю дату обновления (например, при первом запуске CSPM), рекомендуется отметить выполнение контроля вручную.

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

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

Для ротации ключей в зависимости от их типа воспользуйтесь инструкцией.

Дата последней аутентификации сервисного аккаунта не превышает 90 дней

kind	severity	ID
automatic	medium	iam.unused-service-account

Описание

Как работает правило: отслеживается дата последней аутентификации сервисного аккаунта и выводятся аккаунты, которые аутентифицировались более 90 дней назад.

Риски при невыполнении правила:

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

Сервисный аккаунт — аккаунт, от имени которого программы могут управлять ресурсами в Yandex Cloud. Сервисный аккаунт служит для выполнения запросов от имени приложения.

Важно отслеживать дату последней аутентификации сервисных аккаунтов. Без этого невозможно обнаружить, что сервисный аккаунт используется неожиданно — в нерабочее время, из нетипичного источника или после того, как приложение было выведено из эксплуатации.

Особенную опасность представляют неиспользуемые сервисные аккаунты с повышенными привилегиями. Неактивный аккаунт с широкими правами — готовый вектор атаки при компрометации его ключа.

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

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

Следуйте принципу минимальных привилегий при назначении прав доступа сервисным аккаунтам.
Проводите регулярный аудит прав доступа через модуль диагностики доступа (CIEM) для выявления неактивных сервисных аккаунтов с избыточными правами.
Храните ключи сервисных аккаунтов в Yandex Lockbox, а не в коде или переменных окружения.

Дата последнего использования ключей доступа не превышает 90 дней

kind	severity	ID
automatic	medium	iam.unused-key

Описание

Как работает правило: правило выводит ключи доступа Yandex Identity and Access Management, которые последний раз были использованы более 90 дней назад.

Риски при невыполнении правила:

Бессрочный несанкционированный доступ.
Невозможность обнаружить компрометацию без мониторинга.
Утечка через метаданные ВМ.
Расширение привилегий через сервисный аккаунт.

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

Yandex Cloud отображает дату и время последней аутентификации сервисного аккаунта и последнего использования каждого ключа. Неиспользуемый ключ не генерирует активности — его компрометация и тайное использование злоумышленником могут оставаться необнаруженными.

Статические ключи попадают в метаданные виртуальных машин — в поле user-data. Неиспользуемый ключ, забытый в метаданных, остается рабочим вектором атаки.

Если сервисный аккаунт назначен на ВМ, злоумышленник может получить его токен через сервис метаданных изнутри машины. Статический ключ такого аккаунта, оставшийся неиспользуемым и неротируемым, предоставляет аналогичный доступ без необходимости компрометировать саму ВМ.

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

Обновляйте статические ключи не реже одного раза в 90 дней.
Удаляйте ключи, которые не используются.
Храните статические ключи в секретах Yandex Lockbox, а не в коде, конфигурационных файлах или переменных окружения.
Используйте имперсонацию вместо статических ключей там, где это возможно — она не требует генерации долгоживущих учетных данных.
По возможности следует использовать временные токены через Yandex Security Token Service (STS) вместо статических ключей. В отличие от них временные токены имеют ограниченные время жизни и права доступа. Права доступа и время жизни задаются для каждого временного ключа индивидуально.

Учетные записи Яндекс ID используются только в исключительных случаях

kind	severity	ID
automatic	medium	yid-organization

Описание

Как работает правило: правило считается нарушенным, если в организации была обнаружена хотя бы одна учетная запись Яндекс ID.

Риски при невыполнении правила:

К учетным записям Яндекс ID невозможно применить политики безопасности. К ним относятся отзыв и блокирование аккаунтов, ограничение количества неуспешных попыток входа, парольные политики и т. д.
Невозможность централизованного отзыва доступа при увольнении сотрудника. При увольнении сотрудника его аккаунт Яндекс ID продолжает существовать независимо от организации.
Неуправляемое время жизни сессии. Долгоживущая сессия на скомпрометированной рабочей станции позволяет злоумышленнику действовать от имени пользователя без повторной аутентификации.
Утечка OAuth-токена. OAuth-токен аккаунта Яндекс ID действует 1 год.

Федеративные учетные записи использовать безопаснее, чем учетные записи Яндекс ID.

Использование федерации удостоверений — наиболее правильный подход к снижению рисков, связанных с несанкционированным доступом:

Корпоративные политики безопасности (парольные политики, блокировка, 2FA) применяются централизованно и принудительно.
Жизненный цикл аккаунта управляется в IdP: увольнение сотрудника автоматически прекращает доступ к Yandex Cloud.
Время жизни сессии ограничено на уровне организации.
Привилегированные роли назначаются аккаунтам, защищенным корпоративными средствами мониторинга и контроля устройств.
Аудит и реагирование на инциденты выполняются в единой корпоративной системе, а не разрознено по личным аккаунтам сотрудников.

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

Удалите из вашей организации все учетные записи Яндекс ID, кроме случаев из списка допустимых исключений. Для всех оставшихся аккаунтов Яндекс ID настройте двухфакторную аутентификацию (2FA).

Список допустимых исключений:

Учетная запись с правами billing.accounts.owner (технически на текущий момент эту роль может иметь только учетная запись Яндекс ID).
Учетная запись с правами organization-manager.organizations.owner и resource-manager.clouds.owner, если вы используете ее только для аварийного применения. Например, когда сломалась настройка федерации. При необходимости можно удалить привилегированный аккаунт на Яндексе с ролью organization-manager.organizations.owner из организации.
Внешние учетные записи, например, контрагентов или подрядчиков, которые по каким-либо причинам вы не можете завести в вашей федерации.

Только уполномоченные администраторы управляют членством в группах пользователей

kind	severity	ID
manual	high	access.user-groups-access

Описание

Как работает правило:

Данная проверка выявляет случаи, в которых пользователь получает такие права:

Пользователю назначена роль organization-manager.groups.memberAdmin на организацию.
Пользователю назначена роль organization-manager.groups.memberAdmin на конкретную группу как на ресурс.
Пользователю назначена роль organization-manager.organizations.owner или admin или другая привилегированная роль на всю организацию.
Пользователю назначена роль admin или editor на конкретную группу как на ресурс (нерекомендованный сценарий).

Риски при невыполнении правила: если неуполномоченные пользователи могут управлять членством в группах, они могут добавить себя или других в группы с привилегированными ролями в облаке. Это форма повышения привилегий — злоумышленник, получивший доступ к аккаунту с правами управления группами, может незаметно предоставить себе доступ к любому ресурсу, на который у группы есть права, не изменяя напрямую привязки ролей IAM.

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

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

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

В интерфейсе Cloud Center на панели слева выберите Группы и в открывшемся списке нажмите на строку с нужной группой.
Перейдите на вкладку Права доступа к группе и включите опцию Наследуемые роли.
Воспользуйтесь инструкциями по отзыву роли на организацию или на группу пользователей, чтобы отозвать права у неуполномоченных учетных записей.

Сервисным аккаунтам назначены минимальные привилегии на уровне организации

kind	severity	ID
automatic	information	access.sa-privileges-org-roles

Описание

Как работает правило:

Правило обнаруживает сервисные аккаунты со следующими ролями в пределах организации:

admin
editor
resource-manager.clouds.owner

Риски при невыполнении правила: сервисный аккаунт с ролями admin или editor на уровне организации может изменять политики доступа, создавать и удалять ресурсы, управлять другими сервисными аккаунтами во всей организации. При компрометации ключа такого аккаунта — например, при утечке в репозиторий или файл логов — злоумышленник получает административный доступ ко всей организации, что может привести к полному захвату облачной среды.

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

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

Отзовите избыточные доступы у сервисного аккаунта с помощью сервиса Security Deck.
Отзовите избыточные права у сервисного аккаунта с помощью сервиса IAM.

Сервисным аккаунтам назначены минимальные привилегии на уровне сервиса

kind	severity	ID
automatic	information	access.sa-privileges-service-roles

Описание

Как работает правило:

Правило обнаруживает сервисные аккаунты со следующими ролями в пределах сервисов:

compute.admin
storage.admin
iam.serviceAccounts.admin
vpc.admin
k8s.admin
lockbox.admin
kms.admin

Риски при невыполнении правила: сервисные аккаунты с ролями уровня admin на критичных сервисах могут выполнять любые операции в этих сервисах. Скомпрометированный ключ такого аккаунта даёт злоумышленнику возможность читать все секреты из Lockbox, расшифровывать данные ключами KMS, изменять сетевые конфигурации или захватить кластеры Kubernetes — в зависимости от назначенных ролей. Ограничение сервисных аккаунтов минимально необходимыми ролями снижает ущерб от компрометации ключа.

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

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

Отзовите избыточные доступы у сервисного аккаунта с помощью сервиса Security Deck.
Отзовите избыточные права у сервисного аккаунта с помощью сервиса IAM.

Привилегированные роли назначены только доверенным администраторам

kind	severity	ID
manual	medium	access.check-privileged-roles

Описание

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

Ручная проверка

Правило автоматически находит аккаунты, которым назначены следующие роли:

billing.accounts.owner;
admin, назначенная на платежный аккаунт;
organization-manager.organizations.owner;
organization-manager.admin;
resource-manager.clouds.owner;
admin, editor, назначенные на организацию;
admin, editor, назначенные на облако;
admin, editor, назначенные на каталог;
resource-manager.clouds.editor.

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

Роль billing.accounts.owner автоматически выдается при создании платежного аккаунта. Любой пользователь с ролью billing.accounts.owner может удалить эту роль у создателя платежного аккаунта и изменить владельца. Роль позволяет выполнять любые действия с платежным аккаунтом.

Роль billing.accounts.owner может быть назначена только аккаунту Яндекс ID. Аккаунт с ролью billing.accounts.owner используется при настройке способов оплаты и подключении облаков.

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

Наиболее правильным подходом можно считать отказ от регулярного использования данного аккаунта:

Используйте его только при первоначальной настройке и внесении изменений.
На время активного использования данного аккаунта включите двухфакторную аутентификацию (2FA) в Яндекс ID.
Затем, если вы не используете способ оплаты банковской картой (доступный только для данной роли), назначьте данному аккаунту сложный пароль (сгенерированный с помощью специализированного ПО), отключите 2FA и не используйте этот аккаунт без необходимости.
После каждого использования меняйте пароль на сгенерированный заново.

Отключить 2FA рекомендуется только для этого аккаунта и в случае, если аккаунт не «закреплен» за конкретным сотрудником. Эта мера нужна, чтобы избежать привязки критически важного аккаунта к личному устройству.

Для управления платежным аккаунтом назначьте роль admin или editor на платежный аккаунт выделенному сотруднику организации с федеративным аккаунтом.

Для просмотра платежных данных назначьте роль viewer на платежный аккаунт выделенному сотруднику организации с федеративным аккаунтом.

Роль organization-manager.organizations.owner по умолчанию получает владелец организации — пользователь, который ее создал. Роль дает возможность назначать владельцев организации, а также пользоваться всеми полномочиями администратора.

Роль resource-manager.clouds.owner автоматически выдается при создании первого облака в организации. Пользователь с этой ролью может выполнять любые операции с облаком и ресурсами в нем, а также выдавать доступ к облаку другим пользователям: назначать роли и отзывать их.

Назначайте роль resource-manager.clouds.owner и organization-manager.organizations.owner одному или нескольким сотрудникам организации с федеративным аккаунтом. Аккаунту Яндекс ID, с которым создано облако, назначьте сложный пароль и используйте только в случае крайней необходимости, например при поломке федерации.

Федеративный аккаунт с одной из привилегированных ролей, указанных выше, необходимо всесторонне защитить:

Включите двухфакторную аутентификацию.
Запретите аутентификацию с устройств, не управляемых организацией.
Настройте мониторинг попыток входа и задайте пороги предупреждений.

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

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

Проверьте права доступа на сервис Yandex Cloud Billing:

Перейдите в сервис Yandex Cloud Billing.
На панели слева выберите Управление доступом.
Проверьте, кому назначены роли: billing.accounts.owner, admin.

Проверьте права доступа на организацию:

Перейдите в сервис Yandex Identity Hub.
На панели слева выберите Права доступа.
Проверьте кому назначены роли: admin, organization-manager.organizations.owner, organization-manager.admin, resource-manager.clouds.owner.

Проверьте права доступа на облако и каталог:

В консоли управления выберите облако или каталог, в которых необходимо проверить права доступа.
Перейдите на вкладку Права доступа.
Проверьте кому назначены роли: admin, editor , resource-manager.clouds.owner, resource-manager.clouds.editor.

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

На ресурсах используются метки

kind	severity	ID
manual	information	o11y.labeled-resources

Описание

Как работает правило: проверяется наличие меток на уровне каталогов и выводится список каталогов без меток.

Метка — это пара ключ-значение в формате <имя_метки>=<значение_метки>. Вы можете использовать метки для разделения ресурсов на логические группы и для отслеживания потоков данных и обозначения критичности ресурсов для управления привилегиями.

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

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

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

Вы можете добавить, удалить или изменить метку ресурса с помощью консоли управления, командной строки Yandex Cloud и Terraform. Подробнее читайте в Инструкции по управлению метками.

В Yandex Object Storage используются политики доступа (Bucket Policy)

kind	severity	ID
manual	high	access.bucket-access-policy

Описание

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

Риски при невыполнении правила: без политик доступа невозможно применить сетевые или контекстные ограничения на уровне Object Storage. Скомпрометированные учётные данные дают неограниченный доступ к бакету с любого адреса, и нет слоя запрета, который блокировал бы доступ с недоверенных IP-адресов или предотвращал случайные записи из неавторизованных источников.

Политики доступа описывают, кто и при каких условиях может выполнять операции с бакетом и объектами в нём. По сравнению с ролями Identity and Access Management политики позволяют задавать более тонкие правила — ограничивать доступ по IP-адресу источника, HTTP-referer, префиксу объекта или конкретным действиям.

Примеры полезных политик:

разрешить скачивание объектов только из указанного диапазона IP-адресов;
запретить скачивание с конкретного IP-адреса;
выдать каждому пользователю полный доступ только к определённому префиксу в бакете;
выдать сервисному аккаунту доступ только к папке с именем, равным его идентификатору.

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

Для каждого бакета без политики решите, нужна ли она:

Если бакет внутренний и роли Identity and Access Management уже дают нужный доступ, политика не требуется — создайте исключение и отметьте, что нарушение правила проверено вручную.
Если бакету полезны дополнительные условия (ограничения по IP-адресам, доступ по префиксу, deny-правила), настройте политику доступа — отталкивайтесь от одного из готовых примеров в документации.
После применения убедитесь, что легитимные клиенты по-прежнему работают, а случаи, которые политика должна блокировать, действительно блокируются.

Внимание

При данном контроле не проверяются автоматически доступы при модификации ролей в IAM или при указании публичного доступа через anonymous_access_flags. Требуется ручная проверка.

Проверка доступа к ресурсам Object Storage происходит на трех уровнях:

Порядок проверки:

Если запрос прошел проверку IAM, к нему применяется проверка политики доступа.
Проверка правил политики доступа происходит в следующем порядке:
- Если запрос подошел хотя бы под одно из правил Deny, то доступ будет запрещен.
- Если запрос подошел хотя бы под одно из правил Allow, то доступ будет разрешен.
- Если запрос не подошел ни под одно из правил, то доступ будет запрещен.
Если запрос не прошел проверку IAM или политики доступа, то применяется проверка доступа через ACL объекта.

В сервисе IAM бакет наследует такие же права доступа, как у каталога и облака, в котором он находится. Подробнее об этом читайте в разделе Наследование прав доступа к бакету публичными группами Yandex Cloud. Поэтому рекомендуется выдавать только минимально необходимые роли на определенные бакеты или объекты сервиса Object Storage.

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

ACL позволяет предоставить доступ к объекту в обход проверок IAM и политик доступа. Рекомендуем установить строгие ACL на бакеты.

Пример безопасной конфигурации Object Storage: Terraform

Права на управление ключами в KMS выданы уполномоченным пользователям

kind	severity	ID
manual	medium	access.kms-keys-access

Описание

Как работает правило:

Правило проверяет права доступа к ключам сервиса Yandex Key Management Service (KMS) и выводит список всех пользователей, которым назначены следующие роли:

admin, editor, kms.admin, kms.editor или kms.keys.encrypterDecrypter на организацию, облака или каталоги;
kms.keys.encrypterDecrypter или kms.editor на ключи KMS.

Риски при невыполнении правила: избыточные права к ключам KMS означают, что скомпрометированный аккаунт или сервисный аккаунт может расшифровать любые данные, защищённые ключами KMS в организации, а не только те, к которым у него есть легитимный доступ. Это подрывает смысл шифрования данных в состоянии покоя (at rest) — злоумышленник, получивший доступ к такому аккаунту, может читать все зашифрованные данные, не взламывая само шифрование.

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

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

При выдаче прав доступа к ключам сервиса Yandex Key Management Service (KMS) рекомендуется следовать следующим принципам:

Для доступа к сервису Key Management Service необходимо использовать IAM-токен.
В случае автоматизации работы с KMS рекомендуется создать сервисный аккаунт и выполнять команды и скрипты от его имени. Если вы используете виртуальные машины, получите IAM-токен для сервисного аккаунта через механизм назначения сервисного аккаунта виртуальной машине. Другие способы получения IAM-токена для сервисного аккаунта приведены в статье Получение IAM-токена для сервисного аккаунта документации Yandex Identity and Access Management.
Рекомендуется выдавать пользователям и сервисным аккаунтам гранулярные доступы на конкретные ключи сервиса KMS. Подробнее в статье Управление доступом в Key Management Service документации KMS.

Подробнее о мерах безопасности при управлении доступом читайте в статье Аутентификация и управление доступом.

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

kind	severity	ID
manual	medium	appsec.registry-recently-scan

Описание

Базы уязвимостей (CVE) пополняются постоянно: базовый образ, который месяц назад сканировался чисто, сегодня может иметь несколько известных уязвимостей — просто потому, что появились новые.

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

Yandex Container Registry умеет запускать сканирование автоматически по расписанию.

Риски при невыполнении правила: Без регулярного повторного сканирования продуктивные нагрузки могут запускать образы с известными уязвимостями, опубликованными после последнего сканирования — давая злоумышленникам возможность эксплуатировать их до обнаружения.

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

Для каждого реестра, используемого в продуктиве:

Включите сканирование по расписанию для всех Docker-образов в реестре с частотой не реже одного раза в неделю.
После сканирования проверяйте результаты и пересобирайте затронутые образы с обновлёнными базовыми слоями.
Встройте сканирование в CI/CD, чтобы ловить новые уязвимости и на этапе сборки.

Нет доступа к API Kubernetes

kind	severity	ID
automatic	medium	k8s.api-security

Описание

Как работает правило: проверяется только наличие внешних IP-адресов, назначенных кластерам Kubernetes.

Не рекомендуется открывать доступ к API Kubernetes из интернета. В случае необходимости используйте средства межсетевого экранирования, например, группы безопасности.

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

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

Рекомендуется использовать кластеры Kubernetes без доступа из интернета. О том, как создать такой кластер, читайте в разделе Создание и настройка кластера Kubernetes без доступа в интернет.

Если доступ к кластеру из интернета необходим, используйте средства межсетевого экранирования:

Настройте для кластера группы безопасности.
Используйте инструменты для настройки network policy с помощью плагинов Calico (базовый) или Cilium CNI (продвинутый) в Yandex Cloud, применяя правило default deny для входящего и исходящего трафика по умолчанию и разрешая явно только необходимый трафик.
Выделите отдельный кластер Kubernetes для конечных точек, которые взаимодействуют с интернетом, либо отдельные группы узлов (с помощью механизмов: Taints and Tolerations + Node affinity). Таким образом, выделяется сегмент DMZ, и в случае компрометации узлов из интернета поверхность атаки ограничится.
Используйте ресурс Ingress, чтобы организовать входящий сетевой доступ к рабочим нагрузкам по протоколу HTTP/HTTPS. В Yandex Cloud вы можете использовать как минимум два варианта Ingress-контроллера:
- Ingress-контроллер NGINX.
- Ingress-контроллер Yandex Application Load Balancer.

В Managed Service for Kubernetes® используется безопасная конфигурация

kind	severity	ID
manual	medium	k8s.secure-configuration

Описание

Ручная проверка

Проверьте, что у вас внедрены процессы контроля групп узлов.

В Managed Service for Kubernetes пользователь управляет всеми настройками групп узлов, настройками мастера — только частично. Пользователь отвечает за безопасность всего кластера.

Для безопасной конфигурации Kubernetes, включая конфигурацию узлов, существует стандарт CIS Kubernetes Benchmark. В Yandex Cloud группы узлов Kubernetes по умолчанию разворачиваются с конфигурацией, которая соответствует стандарту CIS Kubernetes Benchmark.

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

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

С помощью инструмента kube-bench проверьте конфигурацию группы узлов по стандарту CIS Kubernetes Benchmark. Инструмент официально поддерживает группы узлов Yandex Cloud.
Starboard Operator — это бесплатный инструмент, который позволяет автоматизировать сканирование образов на уязвимости и проверку конфигурации на соответствие CIS Kubernetes Benchmark. Starboard Operator поддерживает интеграцию с kube-bench и используется для его автоматического запуска.

Для кластера и группы узлов используются отдельные сервисные аккаунты

kind	severity	ID
manual	high	k8s.access

Описание

Кластер в Managed Service for Kubernetes использует два сервисных аккаунта:

Сервисный аккаунт кластера — от его имени Managed Service for Kubernetes управляет узлами кластера, подсетями для Pod и Service, дисками, балансировщиками, шифрует и расшифровывает секреты.
Сервисный аккаунт группы узлов — от его имени узлы аутентифицируются в Container Registry при скачивании образов. Для других реестров роли этому сервисному аккаунту назначать не нужно.

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

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

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

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

Не выдавайте сервисным аккаунтам широкий набор разрешений. Вместо этого используйте два отдельных сервисных аккаунта для кластера:

Создайте сервисный аккаунт для кластера и выдайте ему роли, необходимые для управления кластером.
Создайте отдельный сервисный аккаунт для группы узлов и выдайте ему только роль container-registry.images.puller на тех реестрах, из которых кластер скачивает образы.
Для существующего кластера с одним общим сервисным аккаунтом создайте недостающий и переключите кластер или группу узлов на него через обновление кластера или обновление группы узлов.

Подробнее об управлении доступом в Managed Service for Kubernetes — в документации по безопасности сервиса.

Выполняется мониторинг событий безопасности инстанса Yandex Managed Service for GitLab

kind	severity	ID
automatic	medium	o11y.gitlab-audited

Описание

Правило проверяет, настроен ли сбор логов инстанса Managed Service for GitLab.

Основным инструментом сбора логов является сервис Yandex Audit Trails. Сервис позволяет собирать аудитные логи о происходящих с ресурсами Yandex Cloud событиях и загружать эти логи в бакет Object Storage или лог-группу Cloud Logging для дальнейшего анализа или экспорта.

Аудитные логи сервиса Managed Service for GitLab относятся к событиям уровня конфигурации, которые включают создание, удаление или изменение инстанса, события запусков и другое. Подробнее в справочнике Audit Trails.

Риски при невыполнении правила: Без сбора аудитных логов для GitLab события, важные с точки зрения безопасности, — такие как создание, изменение или удаление инстанса — не фиксируются. Это делает невозможным обнаружение несанкционированных изменений инстанса GitLab, расследование инцидентов или подтверждение соответствия требованиям управления изменениями.

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

Настройте сбор логов с помощью сервиса Yandex Audit Trails:

Сервис Yandex Audit Trails работает в штатном режиме

kind	severity	ID
automatic	medium	o11y.audit-trails-no-errors

Описание

Проверка состояния сервиса Yandex Audit Trails позволяет своевременно выявлять сбои в сборе аудитных логов, что критически важно для обеспечения непрерывного мониторинга безопасности и соответствия требованиям аудита. Недоступность или ошибка в работе Audit Trails может привести к потере данных об операциях в облаке, что снижает прозрачность и увеличивает риски возникновения необнаруженных инцидентов.

Проверка выводит список трейлов Audit Trails в статусе Error в пределах организации.

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

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

Если трейл перешел в статус Error, временно создайте новый трейл с аналогичной областью сбора аудитных логов и подходящим объектом назначения. Это позволит предотвратить прекращение сбора аудитных логов и потерю данных. Подробнее читайте в разделе Создание трейла для загрузки аудитных логов.

Создав новый трейл, вы можете самостоятельно или с помощью службы технической поддержки Yandex Cloud приступить к восстановлению работоспособности существующего трейла в состоянии Error.

Используется политика безопасности Kubernetes

kind	severity	ID
automatic	high	k8s.kspm

Описание

Контроль Kubernetes (KSPM) — это инструмент, позволяющий обеспечивать безопасность использования контейнеризованных приложений.

Модуль KSPM автоматически обнаруживает все имеющиеся в заданном окружении кластеры Kubernetes и контейнеры и устанавливает в них компоненты защиты в соответствии с заданной конфигурацией. Защита новых кластеров включается автоматически, без ручного поиска и установки компонентов.

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

Конфигурация KSPM задается при создании окружения и может включать проверку соответствия кластеров следующим стандартам:

Kubernetes Pod Security Standards (Restricted) — стандарт содержит элементы управления безопасностью на основе ограниченного профиля Kubernetes Pod Security Standards (PSS) Restricted profile. Ограниченный профиль является наиболее безопасным и обеспечивает наивысший уровень обнаружения атак на основе контейнеров. Он применяет строгие политики безопасности, которые могут потребовать модификации приложений для соответствия. Ограниченный профиль рекомендуется для критически важных с точки зрения безопасности приложений и сред, где требуется максимальная безопасность.
Kubernetes Pod Security Standards (Baseline) — стандарт содержит элементы управления безопасностью на основе базового профиля стандартов безопасности Kubernetes Pod Security Standards (PSS) Baseline profile. Базовый профиль разработан для легкого внедрения и предоставляет общие лучшие практики безопасности контейнеров. Он предотвращает наиболее распространенные проблемы безопасности контейнеров, сохраняя совместимость с большинством приложений. Базовый профиль является хорошей отправной точкой для организаций, которые только начинают работать с безопасностью контейнеров.
Microsoft Threat Matrix for Kubernetes — стандарт содержит элементы управления безопасностью на основе Microsoft Threat Matrix for Kubernetes — фреймворка, который помогает командам безопасности понимать и защищаться от угроз, специфичных для сред Kubernetes. Он предоставляет комплексный взгляд на техники атак и оборонительные стратегии, адаптированные для платформ оркестрации контейнеров.
CIS Kubernetes Benchmark — стандарт содержит рекомендации CIS Kubernetes Benchmark для безопасной настройки компонентов на рабочих узлах Kubernetes. Включает только автоматические проверки из раздела 4 Worker Nodes.

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

Используйте модуль Контроля Kubernetes для защиты кластеров и контейнеров Kubernetes в окружении:

Создайте сервисный аккаунт, от имени которого модуль KSPM будет просматривать информацию о кластерах Managed Service for Kubernetes, устанавливать в них необходимые компоненты и выполнять проверки.
Назначьте сервисному аккаунту роль security-deck.worker на организацию, облако или каталог.
Создайте окружение Security Deck, указав облака и каталоги, в которых вы хотите контролировать безопасность кластеров, а также отраслевые стандарты и нормативные акты, на соответствие которым будут проверяться выбранные ресурсы.
На странице созданного окружения нажмите Параметры окружения и перейдите на вкладку Контроль Kubernetes®.
В блоке Область действия контроля выберите облака, каталоги или кластеры в пределах ресурсов окружения, в которых будет производиться контроль за соблюдением правил безопасности Kubernetes.
Нажмите Сохранить и подтвердите действие.

Подробнее читайте в разделе Активировать модуль KSPM.

В федерации настроено сопоставление групп пользователей

kind	severity	ID
automatic	low	access.user-groups-mapping

Описание

Как работает правило: проверяется, что в каждой SAML-федерации настроено сопоставление групп.

Риски при невыполнении правила: без настройки сопоставления групп необходимо назначать каждому пользователю права доступа вручную, что повышает риск ошибок конфигурации и избыточного предоставления привилегий. Пользователи, покинувшие группу в поставщике удостоверений, могут бессрочно сохранять доступ к Yandex Cloud, создавая «осиротевшие» права (orphaned permissions), которые могут быть использованы злоумышленниками.

Для организаций, в которых много участников, одинаковые права доступа к ресурсам Yandex Cloud могут потребоваться сразу нескольким пользователям. В этом случае роли и доступы эффективнее выдавать не персонально, а для группы.

Если вы используете группы пользователей в вашем поставщике удостоверений или собираетесь это сделать, настройте сопоставление групп пользователей между поставщиком удостоверений и Yandex Identity Hub. Пользователи в группах поставщика удостоверений будут иметь права доступа к ресурсам Yandex Cloud из сопоставленных групп в Identity Hub.

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

Настройте сопоставление групп пользователей между поставщиком удостоверений и Yandex Identity Hub.

Только доверенные администраторы имеют доступ к сервисным аккаунтам

kind	severity	ID
manual	information	access.privileged-sa-access

Описание

Как работает правило: правило автоматически обнаруживает все аккаунты, которым назначены права доступа к сервисным аккаунтам.

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

Следуйте принципу минимальных привилегий при выдаче доступа к сервисному аккаунту как к ресурсу: при наличии у пользователя прав на сервисный аккаунт у него также появляется доступ и ко всем правам этого сервисного аккаунта. Назначайте права на использование и управление сервисными аккаунтами минимальному кругу доверенных пользователей.

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

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

Проверьте права доступа, назначенные к сервисным аккаунтам. Если в списке находятся только доверенные администраторы, рекомендация выполняется. Если нет, то воспользуйтесь инструкцией, чтобы отозвать избыточные права с помощью сервиса Identity and Access Management.

Чтобы централизованно управлять доступом, используйте Модуль диагностики доступов (CIEM). Для этого воспользуйтесь инструкциями:

Настроен ACL по IP-адресам для Yandex Container Registry

kind	severity	ID
automatic	medium	access.acl-container-registry

Описание

Риски при невыполнении правила: без управления доступом по IP-адресам утечка токена сервисного аккаунта позволяет злоумышленнику из любой точки скачать образы (раскрыв состав инфраструктуры) или загрузить подменённые образы в реестр, что может скомпрометировать все нагрузки, использующие эти образы.

Реестр в Yandex Container Registry по умолчанию доступен с любого IP-адреса. Таким образом, любой, у кого есть действительные учётные данные, может скачивать или загружать образы откуда угодно из интернета.

Управление доступом по IP позволяет ограничить операции pull и push в реестре конкретным списком IP-адресов или CIDR-диапазонов. Это добавляет сетевую границу поверх защиты, которую предоставляет сервис Identity and Access Management: даже если токен сервисного аккаунта утечёт, злоумышленник вне разрешённых IP-адресов не сможет ни скачать образы (и узнать, что запущено у вас в инфраструктуре), ни загрузить подменённые.

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

Ограничьте доступ к реестру известными диапазонами IP-адресов:

Определите политику доступа для скачивания и загрузки образов — обычно это исходящие IP кластера (NAT-шлюз), пулы раннеров CI/CD и небольшой круг адресов администраторов.
Назначьте IP-разрешения на реестре для действий PULL и PUSH, перечислив только эти диапазоны.
После сохранения убедитесь, что с не разрешённого IP операции pull и push не проходят, а с разрешённого — работают.

Подробнее в документации Container Registry.

Отсутствует публичный доступ к бакету Object Storage

kind	severity	ID
manual	medium	access.bucket-public-access

Описание

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

Бакет в Object Storage становится публично доступным, если выполнено одно из условий: роль IAM выдана системной публичной группе (All users / All authenticated users), в ACL бакета или объекта есть запись allUsers / allAuthenticatedUsers, политика доступа разрешает доступ без аутентификации или на самом бакете включён анонимный доступ.

Проверка доступа к ресурсам Object Storage происходит на трех уровнях:

Порядок проверки:

Если запрос прошел проверку IAM, к нему применяется проверка политики доступа.
Проверка правил политики доступа происходит в следующем порядке:
- Если запрос подошел хотя бы под одно из правил Deny, то доступ будет запрещен.
- Если запрос подошел хотя бы под одно из правил Allow, то доступ будет разрешен.
- Если запрос не подошел ни под одно из правил, то доступ будет запрещен.
Если запрос не прошел проверку IAM или политики доступа, то применяется проверка доступа через ACL объекта.

Пример безопасной конфигурации Object Storage: Terraform.

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

Для каждого бакета выполните следующее:

Если публичный доступ не нужен, уберите его: отзовите роли у публичных групп, удалите allUsers / allAuthenticatedUsers из ACL бакета и объектов, отредактируйте или удалите политику доступа, отключите anonymous_access_flags.
Если бакет действительно должен быть публичным (например, для хостинга статического сайта), задокументируйте это и выдайте максимально узкий доступ — только на чтение и только на тех префиксах, которые должны быть открыты.
Для разовой выдачи отдельных объектов из непубличного бакета используйте подписанные ссылки (pre-signed URL), а не открывайте весь бакет.
Для бакетов, в которых могут оказаться чувствительные данные, используйте модуль контроля данных (DSPM) сервиса Security Deck, чтобы сканировать бакет на обнаружение чувствительных данных.

На управляемых БД выключен доступ из консоли управления

kind	severity	ID
automatic	low	access.db-console-access

Описание

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

Доступ к БД из консоли управления может потребоваться для отправки SQL-запросов в БД и визуализации структуры данных.

Рекомендуется включать такой доступ только в случае необходимости, так как он увеличивает риски ИБ. В штатном режиме используйте стандартное подключение к БД под пользователем БД.

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

В консоли управления выберите облако или каталог, в которых вы хотите выключить доступ из консоли.
В списке сервисов выберите сервис(ы), где находятся управляемые базы данных.
В настройках объектов перейдите на вкладку Дополнительные настройки.
В параметрах объекта выключите опцию Доступ из консоли.

Выключена настройка доступа из DataLens без необходимости

kind	severity	ID
automatic	low	access.db-datalens-access

Описание

Риски при невыполнении правила: Включение доступа DataLens к базам данных с критичными данными без необходимости расширяет поверхность атаки. При компрометации аккаунта DataLens злоумышленник может напрямую запрашивать чувствительные данные из БД. Лишние интеграции также усложняют аудит доступа и увеличивают количество путей для утечки данных.

Не следует без необходимости включать доступ к базам данных c критичными данными из консоли управления, DataLens и других сервисов. Доступ из DataLens может потребоваться для анализа и визуализации данных. Эти доступы осуществляются через служебную сеть Yandex Cloud, с аутентификацией и использованием шифрования TLS. Включить и отключить доступы из DataLens или других сервисов можно в настройках кластера или при его создании, в блоке дополнительных настроек.

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

В консоли управления выберите облако или каталог, в которых вы хотите выключить доступ из DataLens.
В списке сервисов выберите сервис(ы), где находятся управляемые базы данных.
В настройках объектов перейдите на вкладку Дополнительные настройки.
В параметрах объекта отключите опцию Доступ из DataLens.

Для API-ключей сервисных аккаунтов заданы минимально необходимые области действия

kind	severity	ID
automatic	medium	access.defined-key-scopes

Описание

Как работает правило: Правило автоматически обнаруживает API-ключи, у которых отсутствует заданная область действия.

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

Область действия — совокупность разрешенных сервисному аккаунту действий с ресурсами сервиса. В сервисе может быть больше одной области действия. API-ключ с заданными областями действия нельзя использовать в других сервисах или областях действия.

Области действия ограничивают применение API-ключей в дополнение к собственным правам доступа сервисного аккаунта. Настройка ограничений области и срока действия позволяет снизить риск несанкционированного использования ключей. Задавайте для API-ключей только те области действия, которые действительно необходимы.

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

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

Создайте API-ключ с заданной областью действия. Для этого:

В консоли управления на панели сверху выберите каталог, которому принадлежит сервисный аккаунт.
Перейдите в сервис Identity and Access Management.
На панели слева выберите Сервисные аккаунты.
Выберите сервисный аккаунт, для которого вы хотите создать API-ключ. При необходимости создайте новый сервисный аккаунт.
На панели сверху нажмите кнопку Создать новый ключ и выберите пункт Создать API-ключ.
Задайте описание ключа, чтобы потом было проще найти его в консоли управления.
В поле Область действия выберите одну или несколько областей действия.
(Опционально) Укажите Срок действия.
Нажмите кнопку Создать.
Сохраните идентификатор и секретный ключ.

Настроена федерация удостоверений (Single Sign-On, SSO)

kind	severity	ID
automatic	information	access.idp

Описание

Как работает правило: Правило проверяет, настроено ли централизованное управление идентификацией (федерация или пулы пользователей) в организации.

Риски при невыполнении правила: бывшие сотрудники могут сохранить доступ к ресурсам облака, корпоративные политики безопасности (сложность паролей, 2FA) не применяются единообразно, и отсутствует централизованный аудит событий доступа, что затрудняет обнаружение несанкционированного доступа.

В Yandex Cloud есть два способа централизованно управлять учётными записями пользователей:

Федерация удостоверений (внешний IdP) для входа в Yandex Cloud по Single Sign-On (SSO). Если в компании уже есть система управления пользователями и доступами (Active Directory, Google Workspace, Keycloak), её можно использовать для аутентификации сотрудников в Yandex Identity Hub — не нужно заводить отдельный аккаунт в Яндексе на каждого сотрудника, и парольные политики и политики 2FA компании продолжают действовать.
Пулы пользователей для централизованного управления локальными учётными записями в ваших доменах, с контролем настроек аутентификации и данных аккаунта.

Без централизованного управления учётными записями сотрудники используют личные аккаунты Яндекс ID для доступа к ресурсам облака. При таком подходе отзыв доступа при увольнении приходится делать вручную, парольные политики и 2FA нельзя применить централизованно, и компании сложно отследить, у кого на самом деле есть активный доступ.

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

Настройте централизованное управление учётными записями в организации:

Если в вашей компании есть система управления пользователями и доступом, настройте SAML-совместимую федерацию удостоверений с вашим IdP — так вы сможете настроить систему единого входа (Single Sign-On, SSO) и наследование политик аккаунтов компании.
Для учётных записей, которые не входят в корпоративный IdP (например, партнёры, подрядчики), используйте пулы пользователей.
Включите сопоставление групп между IdP и Identity Hub — тогда роли будут выдаваться по группам IdP, а не по отдельным учётным записям.

Используются сервисные роли вместо примитивных: admin, editor, viewer

kind	severity	ID
manual	medium	access.min-privileges

Описание

Риски при невыполнении правила: примитивные роли, такие как editor или admin, предоставляют широкие права на все облачные сервисы. При компрометации аккаунта с такой ролью злоумышленник получает возможность изменять и удалять ресурсы, читать секреты и менять политики доступа во всём облаке или каталоге — значительно шире того, что аккаунту нужно на самом деле. Использование сервисных ролей ограничивает радиус поражения при компрометации учётных данных.

Ручная проверка

Данное правило требует ручной проверки. После подтверждения необходимости наличия широких прав отметьте выполнение проверки вручную.

Принцип минимальных привилегий призывает назначать минимально необходимые для работы роли. Не рекомендуется использовать примитивные роли admin, editor и viewer, действующие во всех сервисах, так как это противоречит принципу минимальных привилегий. Для более избирательного управления доступом и реализации принципа минимальных привилегий используйте сервисные роли, которые содержат разрешения только для определенного типа ресурсов в указанном сервисе. Со списком всех сервисных ролей можно ознакомиться в справочнике ролей Yandex Cloud.

Используйте роль auditor без возможности доступа к данным везде, где это возможно.

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

Проанализируйте найденные учетные записи с назначенными примитивными ролями admin, editor и viewer и замените их на сервисные гранулярные роли в соответствии с вашей матрицей ролей.

Чтобы просмотреть полный список доступов субъекта, воспользуйтесь инструкцией.

Для подключения к виртуальной машине используется OS Login

kind	severity	ID
automatic	low	access.os-login-onto-hosts.vm

Описание

Риски при невыполнении правила: без OS Login доступ к ВМ предоставляется через SSH-ключи, распределяемые вручную и не привязанные к IAM-идентификаторам. При увольнении сотрудника или компрометации ключа нет централизованного способа отозвать доступ — ключ нужно вручную удалять с каждой ВМ. Неуправляемые SSH-ключи могут существовать бесконечно долго, предоставляя бывшим сотрудникам или злоумышленникам постоянный доступ к виртуальным машинам.

OS Login — это удобный способ управления подключениями к виртуальным машинам по SSH через CLI или через стандартный SSH-клиент c SSH-сертификатом или SSH-ключом, предварительно добавленным в профиль OS Login пользователя организации или сервисного аккаунта в Yandex Identity Hub.

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

Так можно легко управлять доступом к виртуальным машинам, назначая пользователю или сервисному аккаунту необходимые роли. Если у пользователя или сервисного аккаунта отозвать роли, он потеряет доступ ко всем виртуальным машинам, для которых включен доступ по OS Login.

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

Включите доступ по OS Login на уровне организации.
Настройте доступ по OS Login на существующей виртуальной машине.
Подключитесь к виртуальной машине по OS Login.

На ресурсах в организации отсутствует публичный доступ

kind	severity	ID
manual	high	access.public-access

Описание

Как работает правило: правило проверяет наличие открытого доступа на публичные группы All authenticated users и All users в пределах организации, облака или каталога.

Риски при невыполнении правила: публичный доступ к ресурсам открывает их всем пользователям интернета или всем пользователям Yandex Cloud, что ведёт к утечкам данных, несанкционированным изменениям и нарушениям требований соответствия — особенно если ресурс содержит чувствительные или персональные данные.

В Yandex Cloud можно предоставить публичный доступ к ресурсу, назначив роль одной из системных публичных групп:

All authenticated users — все пользователи, прошедшие аутентификацию. Сюда входят все пользователи и сервисные аккаунты Yandex Cloud — как из ваших облаков, так и из облаков других пользователей.
All users — любой пользователь, аутентификация не требуется.

Публичный доступ — частая причина утечек данных и несанкционированных изменений, потому что открывает ресурс гораздо более широкой аудитории, чем обычно предполагается. Его стоит оставлять только на ресурсах, которые сознательно сделаны публичными, — например, на бакете Object Storage с раздачей статического сайта.

Важно

All users сейчас работает только в Object Storage (при управлении доступом через ACL), Container Registry и Cloud Functions. В остальных сервисах назначение роли группе All users эквивалентно назначению роли группе All authenticated users.

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

Найдите все роли, выданные группам All users и All authenticated users, — полный список доступен в модуле диагностики доступа (CIEM) сервиса Security Deck.

Для каждого ресурса, на который выдана такая роль, выполните следующее:

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

Сервисным аккаунтам назначены минимальные привилегии

kind	severity	ID
manual	high	access.sa-privileges

Описание

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

Ручная проверка

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

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

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

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

Посмотрите полный список доступов сервисного аккаунта с помощью сервиса Yandex Security Deck.
Отзовите избыточные доступы у сервисного аккаунта с помощью сервиса Security Deck.
Удалите избыточные права у сервисного аккаунта с помощью сервиса IAM.

Использование серийной консоли контролируется либо отсутствует

kind	severity	ID
automatic	medium	access.serial-console

Описание

Риски при невыполнении правила: включённый доступ к серийной консоли может привести к утечке чувствительных данных через вывод консоли, позволить неавторизованным пользователям подключиться к ОС ВМ и перехватить сессию — при этом такие действия не оставляют следов в стандартных журналах доступа.

По умолчанию доступ к серийной консоли виртуальной машины в Yandex Compute Cloud отключён. Серийная консоль — это низкоуровневое подключение к ОС: через неё видны логи загрузки, системные сообщения и можно войти в систему локально.

Когда доступ включён, появляются риски:

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

Подробнее в разделе Начало работы с серийной консолью документации Yandex Compute Cloud.

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

Для каждой ВМ с включённым доступом к серийной консоли решите, нужен ли он:

Если нет, отключите доступ на ВМ.
Если доступ должен остаться, выдавайте роль compute.editor или compute.admin только узкому кругу администраторов, которым она реально нужна; используйте стойкий пароль для локального входа в ОС и регулярно его меняйте; убедитесь, что в вывод консоли не попадают секреты; после работы в консоли управления выйдите из Yandex Cloud или закройте вкладку браузера, чтобы завершить сессию.

В Yandex Application Load Balancer используется HTTPS

kind	severity	ID
automatic	high	appsec.alb-https

Описание

Риски при невыполнении правила: без HTTPS весь трафик между пользователями и балансировщиком передаётся в открытом виде, что позволяет перехватить или подменить учётные данные, токены сессий и персональные данные любому, у кого есть доступ к сети (атаки MITM).

Сервис Application Load Balancer поддерживает как HTTP-, так и HTTPS-обработчики. При использовании HTTP-обработчика трафик между клиентами и балансировщиком передаётся в открытом виде — любой, у кого есть доступ к сети по пути, может прочитать или изменить запросы и ответы, в том числе учётные данные, cookie сессии и персональные данные.

Шифрование веб-трафика по TLS — отраслевой стандарт: современные браузеры помечают сайты на чистом HTTP как небезопасные, ограничивают на них работу функций вроде аутентификации и геолокации и постепенно отказываются от поддержки HTTP для новых API.

Для любого сервиса, который работает с пользовательскими данными или аутентификацией, используйте HTTPS-обработчик с TLS-сертификатом из Certificate Manager.

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

Настройте HTTPS-обработчик на балансировщике:

Добавьте TLS-сертификат в Certificate Manager — выпустите через Let's Encrypt или загрузите собственный.
Добавьте HTTPS-обработчик на балансировщик по инструкции по терминации TLS.
Если HTTP-обработчик нужен только для перенаправления на HTTPS, настройте перенаправление с HTTP на HTTPS. В противном случае удалите его.

API-шлюзы используют протокол HTTPS и собственные домены

kind	severity	ID
automatic	medium	appsec.api-gateway-https

Описание

Сервис Yandex API Gateway обеспечивает безопасное подключение по протоколу HTTPS. Вы можете привязать собственный домен и загрузить собственный сертификат безопасности для доступа к вашему API-шлюзу по протоколу HTTPS.

Риски при невыполнении правила: Без HTTPS трафик между клиентом и API-шлюзом передаётся в незашифрованном виде, что позволяет злоумышленникам перехватывать данные через атаки MITM и раскрывает конфиденциальную информацию: персональные данные, платёжную информацию, токены аутентификации и пароли.

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

В консоли управления выберите каталог, в котором находится нужный API-шлюз.
Перейдите в сервис API Gateway и в открывшемся окне нажмите на строку с нужным API-шлюзом.
В меню слева выберите Домены и нажмите кнопку Подключить.
В открывшемся окне выберите TLS-сертификат и укажите соответствующее этому сертификату доменное имя.
Нажмите кнопку Подключить.

В Yandex Cloud CDN используется HTTPS и собственный SSL-сертификат

kind	severity	ID
automatic	low	appsec.cdn-https

Описание

Сервис Cloud CDN использует два участка, на которых пользовательский трафик может идти в открытом виде: от клиента до edge-узла CDN и от edge-узла до источника. Если на каком-либо из этих участков используется HTTP, трафик между пользователями и источником (в том числе cookie аутентификации и другие чувствительные данные) можно прочитать или изменить из любой сети по пути.

Шифрование веб-трафика по TLS — отраслевой стандарт: современные браузеры помечают сайты на чистом HTTP как небезопасные и ограничивают на них работу функций вроде аутентификации и геолокации. Для CDN-ресурса рекомендуется включать HTTPS на обоих участках — от клиента до edge и от edge до источника — с TLS-сертификатом из Certificate Manager.

Риски при невыполнении правила: Без HTTPS на участках CDN cookie аутентификации, токены сессий и другие чувствительные данные, передаваемые между пользователями и источником, могут быть перехвачены или подменены злоумышленниками с доступом к сети, что открывает возможность для перехвата сессий и кражи данных.

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

Настройте HTTPS на CDN-ресурсе:

Добавьте TLS-сертификат в Certificate Manager — выпустите через Let's Encrypt или загрузите собственный.
Включите HTTPS на CDN-ресурсе и выберите сертификат.
Настройте подключение CDN к источнику по HTTPS и включите перенаправление с HTTP на HTTPS для клиентского трафика.

Используется защита от DDoS-атак на уровне приложений (L7)

kind	severity	ID
automatic	high	appsec.ddos-protection.l7

Описание

Ручная проверка

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

В Yandex Cloud существует базовая и расширенная защита от DDoS-атак, а также защита на прикладном уровне с помощью сервиса Yandex Smart Web Security. Необходимо убедиться, что у вас используется как минимум базовая защита.

Yandex Smart Web Security — сервис для защиты от DDoS-атак и ботов на прикладном уровне L7 сетевой модели OSI. Smart Web Security подключается к Yandex Application Load Balancer. Функциональность сервиса сводится к проверке HTTP-запросов к защищаемому ресурсу на соответствие правилам, заданным в профиле безопасности. В зависимости от результатов проверки запросы пропускаются на защищаемый ресурс, блокируются или отправляются в сервис Yandex SmartCaptcha для дополнительной верификации.
Yandex DDoS Protection — это компонент сервиса Virtual Private Cloud для защиты облачных ресурсов от DDoS-атак. DDoS Protection предоставляется в партнерстве с Curator. Вы можете включать его самостоятельно на внешний IP-адрес через инструменты управления облаком. Работает до уровня L4 модели OSI.
Расширенная защита от DDoS-атак — работает на уровнях L3, L4 и L7 модели OSI. Вы также можете отслеживать показатели нагрузки, параметры атак и подключить Solidwall WAF в личном кабинете Curator. Чтобы включить расширенную защиту, обратитесь к вашему менеджеру или в техническую поддержку.

Риски при невыполнении правила: Без защиты от DDoS-атак на уровне L7 атаки на прикладном уровне могут исчерпать ресурсы бэкенда, вызывая сбои в работе сервиса даже при наличии защиты на сетевом уровне. Злоумышленники могут организовывать HTTP-флуд или атаки типа slow-loris, которые обходят защиту L3/L4 и делают веб-приложения недоступными для легитимных пользователей.

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

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

Как создать профиль безопасности Smart Web Security
Вебинар Защита от DDoS в Yandex Cloud

Используется защита от DDoS-атак на сетевом уровне (L3)

kind	severity	ID
automatic	high	appsec.ddos-protection.l3

Описание

Как работает правило: Правило проверяет, что на публичных IP включён сервис Yandex DDoS Protection. Если вы используете стороннее решение защиты от DDoS, отметьте правило выполненным вручную.

Совет

Проверка контролирует, что включён сервис Yandex DDoS Protection. Если вы используете стороннее решение защиты от DDoS, отметьте правило выполненным вручную.

Без защиты от DDoS на уровнях L3/L4 публичный IP виртуальной машины или сетевого балансировщика полностью открыт объёмным атакам: злоумышленник может насытить канал или исчерпать ресурсы нагрузки, просто отправив достаточно трафика.

Yandex DDoS Protection — функция Virtual Private Cloud, которая защищает облачные ресурсы от таких атак на уровнях L3 и L4 модели OSI. При включённой защите Yandex Cloud непрерывно анализирует входящий трафик на защищаемый IP, обнаруживает аномалии и отсекает нежелательный трафик, когда его объём угрожает нагрузке.

Есть также расширенная защита от DDoS — она работает на уровнях L3, L4 и L7 и даёт доступ к детальным метрикам атак и нагрузки.

Риски при невыполнении правила: Без защиты от DDoS на уровнях L3/L4 объёмная атака может насытить сетевой канал или исчерпать ресурсы нагрузки, что приведёт к полной недоступности сервиса и потенциальным финансовым потерям.

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

Включите базовую защиту от DDoS на каждом публичном IP, который не должен быть открыт объёмным атакам:

При создании ВМ или резервировании публичного IP выберите опцию Защита от DDoS-атак — см. Включение DDoS Protection.
Для нагрузок со строгими требованиями к доступности подключите расширенную защиту или обратитесь в техническую поддержку.

При создании реестра в Yandex Container Registry по умолчанию оставляйте безопасные настройки реестра

kind	severity	ID
automatic	medium	appsec.periodic-scan

Описание

Yandex Container Registry умеет сканировать Docker-образы на уязвимости и при загрузке, и по расписанию. По умолчанию оба режима включены, повторное сканирование выполняется раз в 7 дней с возможностью переключения на ежедневное.

Без повторного сканирования образ, прошедший проверку при загрузке, со временем может стать уязвимым — когда в одном из его слоёв найдут новый CVE, — а кластер продолжит его запускать. Настройки по умолчанию рассчитаны именно на этот случай; отключать их стоит только сознательно.

Риски при невыполнении правила: Без планового повторного сканирования образы, которые были чистыми при загрузке, могут незаметно стать уязвимыми по мере публикации новых CVE, а кластер продолжит их запускать — оставляя известные уязвимости необнаруженными и неустранёнными в продуктиве.

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

Убедитесь, что на каждом реестре включены опции (Container Registry → реестр → Настройки → Автоматическое сканирование):

Сканировать Docker-образы при загрузке — сканирует каждый образ при загрузке.
Сканировать все Docker-образы в реестре — периодически пересканирует уже загруженные образы. Минимальная частота — раз в неделю; для продуктивных реестров переключайтесь на ежедневную.

Подробнее — в разделах Сканер уязвимостей и Сканирование Docker-образа документации Container Registry.

Используется Advanced Rate Limiter

kind	severity	ID
automatic	medium	appsec.use-arl

Описание

Ручная проверка

Данным правилом проверяют только встроенные средства защиты информации в Yandex Cloud. Если используется наложенное средство защиты, просьба вручную отметить правило выполненным.

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

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

Риски при невыполнении правила: Без ограничения частоты запросов веб-приложение уязвимо для атак типа HTTP-флуд и злоупотребления API, которые могут исчерпать ресурсы бэкенда и привести к отказу в обслуживании. Злоумышленники также могут использовать неограниченный доступ для перебора учётных данных или автоматизированного сбора данных.

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

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

Используется Yandex SmartCaptcha

kind	severity	ID
automatic	low	appsec.use-smartcaptcha

Описание

Публичные веб-формы — входа, регистрации, восстановления пароля, отправки комментариев, поиска — типичная цель автоматизированных атак: боты регистрируют поддельные учётные записи, подбирают пароли, выкачивают контент, отправляют спам.

Yandex SmartCaptcha защищает формы от таких запросов. Сервис оценивает каждый запрос ML-моделями и показывает задание только подозрительным клиентам, поэтому большинство реальных пользователей не сталкиваются с проверкой «Я не робот».

Риски при невыполнении правила: Без защиты CAPTCHA публичные веб-формы уязвимы для автоматизированных атак ботов — подстановки учётных данных, перебора аккаунтов, спам-рассылок и выкачивания контента — что может привести к захвату аккаунтов, злоупотреблению сервисом и краже данных.

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

Добавьте SmartCaptcha на публичные формы, которые могут использовать боты:

Создайте SmartCaptcha и встройте клиентский виджет в форму.
На сервере проверяйте токен SmartCaptcha до обработки формы.
Следите за статистикой SmartCaptcha и подстраивайте режим капчи под долю трафика, которой выдаётся проверка.

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

kind	severity	ID
automatic	high	appsec.use-sws

Описание

Как работает правило: проверяются только встроенные средства защиты информации в Yandex Cloud. Если используется наложенное средство защиты, просьба вручную отметить правило выполненным.

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

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

Риски при невыполнении правила: Без Smart Web Security веб-приложения подвержены DDoS-атакам на уровне L7, бот-трафику и веб-эксплойтам (таким как SQL-инъекции и XSS), которые могут нарушить доступность приложения и целостность данных. Незащищённые эндпоинты являются основной целью для автоматизированных инструментов атак.

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

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

Используется Web Application Firewall

kind	severity	ID
automatic	medium	appsec.use-waf

Описание

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

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

Риски при невыполнении правила: Без WAF веб-приложения уязвимы для атак из списка OWASP Top 10, включая SQL-инъекции, межсайтовый скриптинг (XSS) и удалённое выполнение кода. Эти атаки могут привести к утечке данных, захвату учётных записей и полной компрометации приложения.

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

Создайте и подключите профиль WAF к профилю безопасности Smart Web Security. Предварительно рекомендуется настроить и протестировать базовые правила и правила Smart Protection в профиле безопасности.

Создайте профиль WAF.
Настройте набор правил WAF.
Добавьте правило-исключение в профиль WAF.
Подключите профиль WAF к профилю безопасности.

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

kind	severity	ID
manual	medium	appsec.secure-registry

Описание

Без автоматического сканирования уязвимостей каждый новый Docker-образ, загружаемый в реестр, попадает в инвентарь непроверенным: уязвимые базовые слои и компоненты, случайно попавший вредоносный код и устаревшие зависимости — всё это доходит до кластера как ни в чём не бывало.

Container Registry умеет сканировать образы автоматически при загрузке и показывать результаты в отчёте о сканировании — это самый быстрый способ узнать о проблеме до того, как образ окажется в продуктиве.

Риски при невыполнении правила: Без автоматического сканирования при загрузке уязвимые образы, вредоносный код и устаревшие зависимости могут незаметно попасть в продуктивные кластеры — где их могут эксплуатировать до того, как кто-то это заметит.

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

Включите сканирование при загрузке для каждого реестра:

В консоли управления откройте настройки реестра (Container Registry → реестр → Настройки).
В блоке Автоматическое сканирование включите опцию Сканировать Docker-образы при загрузке.
Просмотрите результаты сканирования последних образов и устраните найденные уязвимости до их выкатки.

На новых реестрах опция включена по умолчанию — оставьте её включённой.

На ВМ отключено получение IAM-токена через сервис метаданных в формате AWS IMDSv1

kind	severity	ID
automatic	high	aws-token

Описание

В виртуальных машинах Yandex Compute Cloud доступен сервис метаданных, предоставляющий сведения об их работе в следующих форматах:

Google Compute Engine (поддерживаются не все поля).
Amazon EC2 (поддерживаются не все поля).

Формат Amazon EC2 Instance Metadata Service version 1 (IMDSv1) имеет ряд недостатков. Наиболее критичный из них — это риск компрометации токена сервисного аккаунта через сервис метаданных с помощью SSRF-атаки. Подробности в официальном блоге AWS.

Риски при невыполнении правила: Если IMDSv1 включён, уязвимость SSRF в любом приложении, работающем на ВМ, может позволить злоумышленнику похитить IAM-токен сервисного аккаунта из эндпоинта метаданных. Получив этот токен, злоумышленник приобретает все права сервисного аккаунта, что потенциально открывает возможности для горизонтального перемещения, утечки данных или полного захвата облачного аккаунта.

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

Чтобы получить IAM-токен сервисного аккаунта изнутри ВМ, рекомендуется использовать метаданные в формате Google Compute Engine.

Обязательно отключайте возможность получения IAM-токена через сервис метаданных в формате IMDSv1.

У обнаруженных ВМ в блоке metadata_options установите для параметра aws_v1_http_token значение DISABLED:

yc compute instance update <идентификатор_или_имя_ВМ> \
  --metadata-options aws-v1-http-token=DISABLED

Используется Cloud Backup или механизм snapshot по расписанию

kind	severity	ID
automatic	high	backup.compute-disks

Описание

Как работает правило: выводится список виртуальных машин, на которых не настроены политики резервирования.

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

В Yandex Cloud есть два способа делать резервные копии дисков ВМ:

Cloud Backup — управляемый сервис резервного копирования с политиками, правилами хранения и возможностью восстановления на другую ВМ.
Снимки дисков по расписанию — встроенная функция Compute Cloud, которая периодически создаёт снимки дисков.

Риски при невыполнении правила: Без резервных копий любое событие потери данных — случайное удаление, шифровальщик, сбой оборудования или неудачное обновление — приводит к безвозвратной потере данных и длительному простою без возможности восстановить предыдущее состояние.

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

Настройте резервное копирование для ВМ:

Для продуктивных нагрузок активируйте Cloud Backup и привяжите ВМ к политике с подходящим сроком хранения по вашим требованиям к восстановлению.
Для прочих ВМ настройте расписание снимков для дисков и подберите частоту и срок хранения под то, как часто меняются данные.
Периодически проверяйте, что из резервной копии действительно можно восстановиться — непроверенная резервная копия — это не резервная копия.

Срок действия сертификата Yandex Certificate Manager составляет как минимум 30 дней

kind	severity	ID
automatic	medium	crypto.certificate-validity

Описание

Сервис Yandex Certificate Manager позволяет управлять TLS-сертификатами для API-шлюзов сервиса API Gateway, а также для сайтов и бакетов в Object Storage. Сервис Application Load Balancer интегрирован с Certificate Manager для хранения и установки сертификатов. Рекомендуется использовать Certificate Manager для получения и автоматической ротации сертификатов.

При работе с TLS в приложении рекомендуется ограничивать список доверенных корневых сертификатов (root CA).

При использовании технологий certificate pinning следует учитывать, что сервис Let's Encrypt выдает сертификаты со сроком действия в 90 дней.

Риски при невыполнении правила: Истёкший TLS-сертификат приводит к тому, что браузеры и клиенты отображают предупреждения безопасности или полностью отказываются от подключения, что влечёт недоступность сервиса. Просроченные сертификаты также свидетельствуют о нарушении гигиены безопасности и могут указывать на более широкие сбои в управлении сертификатами, потенциально оставляя сервисы уязвимыми для атак типа «человек посередине».

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

Обновите сертификат либо настройте автоматическое обновление.

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

Для ключей KMS включена защита от удаления

kind	severity	ID
automatic	high	crypto.keys-deletion-protection

Описание

Ключ в сервисе Key Management Service — это вход к данным, которые он шифрует: потерять ключ — потерять данные, зашифрованные им, без возможности восстановить.

Для ключей, защищающих критичные для бизнеса данные — зашифрованные бакеты Object Storage, etcd кластера Managed Service for Kubernetes, секреты в Lockbox — случайное удаление является одной из самых разрушительных операций. Защита от удаления заставляет вызов удаления падать, пока её явно не снимут, и даёт время заметить и остановить ошибочное действие.

Риски при невыполнении правила: Случайное или намеренное удаление ключа KMS безвозвратно уничтожает все данные, зашифрованные им — включая бакеты Object Storage, состояние кластера Kubernetes и секреты Lockbox — без возможности восстановления.

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

Включите защиту от удаления для каждого ключа KMS, который шифрует данные, потерять которые недопустимо:

В консоли управления откройте настройки ключа (KMS → ключ → Редактировать).
Включите защиту от удаления.
Ограничьте круг тех, кто может снять флаг — для отключения защиты достаточно роли kms.editor, поэтому проверяйте, у кого она есть, через модуль диагностики доступа (CIEM) сервиса Security Deck.
Удаление ключа делайте только в рамках запланированного изменения — сначала подтвердите его с владельцем данных, потом снимите защиту и удалите.

Ключи Key Management Service хранятся в аппаратном модуле безопасности (HSM)

kind	severity	ID
manual	medium	crypto.keys-hsm

Описание

В продакшн-среде рекомендуется использовать отдельные ключи, все криптооперации с которыми будут выполняться только внутри специализированного аппаратного устройства. Подробнее см. статью Аппаратный модуль безопасности (HSM).

Чтобы использовать HSM, при создании ключа выберите тип алгоритма HSM. Все операции с этим ключом будут выполняться внутри HSM, дополнительные действия не требуются.

Рекомендуется использовать HSM для ключей KMS, это увеличивает уровень безопасности.

Ключи, защищённые HSM, обеспечивают аппаратную изоляцию, гарантируя, что криптографические операции не могут выполняться за пределами защищённого аппаратного периметра.

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

Установите 'AES-256 HSM' в качестве алгоритма шифрования для ключей KMS.

Для KMS-ключей включена ротация

kind	severity	ID
automatic	high	crypto.keys-rotation

Описание

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

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

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

Ключи для сервисов, которые только обрабатывают данные (Message Queue, Cloud Functions). Настраивайте автоматическую ротацию с периодом больше, чем длительность обработки одного объекта данных. Старые версии можно выводить из обращения, как только обработка данных, которые ими защищены, завершена.
Ключи для сервисов, которые хранят данные (управляемые БД, зашифрованные диски, Object Storage). Используйте ручную ротацию или автоматическую с периодом, согласованным с вашими сроками хранения данных. Старые версии стоит выводить только после того, как все данные, зашифрованные ими, перешифрованы или удалены — уничтожение версии, за которой ещё стоят данные, делает эти данные невосстановимыми.

Примечание

deletionProtection на ключе защищает ключ целиком, но не защищает его отдельные версии. Срок хранения версий планируйте отдельно.

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

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

Для каждого продуктивного ключа KMS:

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

Подробнее о версиях ключей — в документации KMS.

Используется шифрование дисков и снимков виртуальных машин

kind	severity	ID
automatic	medium	crypto.managed-vm-kms

Описание

По умолчанию все данные на дисках Yandex Compute Cloud шифруются на уровне базы данных хранилища с помощью системного ключа. Это позволяет защитить данные от компрометации в случае физической кражи дисков из дата-центров Yandex Cloud.

Рекомендуем также использовать шифрование дисков и снимков дисков с помощью пользовательских симметричных ключей Yandex Key Management Service. Такой подход позволяет:

Защищаться от потенциальных угроз нарушения изоляции и компрометации данных на уровне виртуальной инфраструктуры.
Контролировать шифрование и жизненный цикл ключей KMS, а также управлять ими. Подробнее см. в разделе Управление ключами.
Повысить уровень контроля доступа к данным на диске за счет необходимости прав на ключ KMS. Подробнее см. в разделе Настройка прав доступа к симметричному ключу шифрования.
Отслеживать операции шифрования и расшифрования вашим ключом KMS с помощью сервиса Yandex Audit Trails. Подробнее см. в разделе Аудит использования ключей.

Вы можете зашифровать диски следующих типов:

сетевой SSD-диск (network-ssd)
сетевой HDD-диск (network-hdd)
нереплицируемый SSD-диск (network-ssd-nonreplicated)
сверхбыстрое сетевое хранилище с тремя репликами (SSD) (network-ssd-io-m3)

Риски при невыполнении правила: Без шифрования с управляемым пользователем ключом KMS у вас нет контроля над тем, кто может расшифровать данные диска на уровне инфраструктуры. Управляемые пользователем ключи позволяют отозвать доступ к данным путём отключения ключа и отслеживать все криптографические операции через Audit Trails.

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

Зашифруйте диск виртуальной машины Yandex Compute Cloud.

В организации используется Yandex Lockbox для безопасного хранения секретов

kind	severity	ID
automatic	low	crypto.secrets-lockbox

Описание

Критичные данные и секреты доступа — токены аутентификации, API-ключи, ключи шифрования, пароли к БД — нельзя хранить в открытом виде в коде, в названиях и описаниях ресурсов, в метаданных ВМ и в подобных местах. Любой, у кого есть доступ к исходному коду, консоли управления или метаданным ВМ, получает доступ и к этим секретам.

Yandex Lockbox — управляемое хранилище секретов. Он хранит секреты в зашифрованном виде ключом из сервиса Key Management Service, отдаёт их только авторизованным учётным записям и записывает каждое обращение в Audit Trails.

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

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

Уберите секреты из кода, конфигурации и метаданных в Lockbox:

Создайте в Lockbox секрет для каждого учётного данных или чувствительного значения, которое используют ваши нагрузки.
Выдайте доступ к секрету только тому сервисному аккаунту нагрузки, которому он действительно нужен — используйте роль lockbox.payloadViewer.
Читайте секреты в нагрузке напрямую из Lockbox — например, на ВМ через SDK или CLI, а в Managed Service for Kubernetes — через External Secrets Operator с поддержкой Yandex Lockbox.
Удалите секрет из исходного места (код, конфиг, метаданные) и ротируйте его — старое значение нужно считать утёкшим.

Подробнее: документация Lockbox.

Примечание

При работе в Terraform заполняйте содержимое секрета Lockbox скриптом, а не значением прямо в манифесте. Иначе значение секрета попадёт ещё и в файл .tfstate.

Для инвентаризации секретов в ваших хранилищах данных воспользуйтесь сервисом DSPM.

Для Serverless Containers и Cloud Functions используются секреты Lockbox

kind	severity	ID
automatic	medium	crypto.secrets-serverless

Описание

При работе с Serverless Containers или Cloud Functions часто возникает необходимость использовать секрет (токен, пароль и т. д.).

Если указать секретную информацию в переменных окружения, она может быть доступна для просмотра любому пользователю облака с правами на просмотр и использование функции и влечет за собой риски ИБ.

Рекомендуется использовать для этих целей интеграцию Serverless с Lockbox. Вы можете указать конкретный секрет из сервиса Yandex Lockbox и сервисный аккаунт с правами на данный секрет для использования его в функции или контейнере.

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

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

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

Удалите секретные данные из env и воспользуйтесь функционалом интеграции с Lockbox:

В Yandex Object Storage включено шифрование данных at rest с ключом KMS

kind	severity	ID
automatic	medium	data.object-storage-encryption

Описание

По умолчанию Object Storage шифрует данные at rest сервисным ключом — прозрачно для пользователя.

Для бакетов с чувствительными данными — персональными, платёжными, интеллектуальной собственностью — стоит использовать серверное шифрование ключом, которым управляете вы сами, из Key Management Service. При таком подходе бакет не сможет расшифровать свои объекты без доступа к вашему ключу KMS, и это даёт дополнительный уровень контроля: лишение доступа к ключу фактически закрывает доступ к данным даже пользователям облака с правами на бакет.

Риски при невыполнении правила: Без шифрования с управляемым пользователем ключом KMS вы не можете отозвать доступ к данным бакета независимо от прав IAM. При неправильной настройке контроля доступа к бакету или компрометации привилегированного аккаунта данные будут доступны в открытом виде. Управляемое шифрование добавляет второй независимый уровень контроля доступа — ключ KMS — который можно отозвать или проверить отдельно.

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

Включите серверное шифрование вашим ключом KMS для бакетов с чувствительными данными:

Создайте симметричный ключ KMS в том же каталоге, что и бакет.
Включите шифрование бакета этим ключом — для новых бакетов при создании, для существующих через настройки бакета.
Ограничьте доступ к ключу так, чтобы роль kms.keys.encrypterDecrypter на нём была только у тех нагрузок, которым действительно нужно читать бакет.
Зафиксируйте операционные последствия: ротация или отключение ключа меняет круг тех, кто может читать бакет.

В Yandex Object Storage включено HTTPS для хостинга статического сайта

kind	severity	ID
automatic	high	data.storage-https

Описание

Object Storage поддерживает безопасное подключение по протоколу HTTPS. Вы можете загрузить собственный сертификат безопасности, если к сайту в Object Storage требуется доступ по протоколу HTTPS. Также доступна интеграция с сервисом Certificate Manager. См. инструкции в документации Object Storage:

При работе с сервисом Object Storage необходимо убедиться, что в клиенте отключена поддержка протоколов TLS ниже версии 1.2. При помощи политики (bucket policy) aws:securetransport необходимо проверить, что для бакета настроен запрет на работу без протокола TLS.

Риски при невыполнении правила: Без HTTPS данные, передаваемые между пользователями и статическим сайтом, отправляются в открытом виде, что делает их уязвимыми для перехвата и атак типа «человек посередине». Чувствительный контент, токены сессий или данные форм могут быть перехвачены сетевыми злоумышленниками. Современные браузеры также предупреждают пользователей о сайтах, работающих только по HTTP, или блокируют их, снижая доверие и доступность.

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

Включите доступ по HTTPS, если бакет используется для хостинга статического сайта.

Включена настройка защиты от удаления (deletion protection)

kind	severity	ID
automatic	low	db.db-deletion-protection

Описание

Все сервисы управляемых баз данных в Yandex Cloud поддерживают флаг deletion_protection на уровне кластера. Когда он включён, попытки удалить кластер — через консоль управления, CLI, API или Terraform — отклоняются, пока флаг не будет снят.

Защита от удаления страхует от опасной ошибки — случайного удаления кластера вместе с данными и конфигурацией. Флаг защищает только от удаления самого кластера: пользователь с правами уровня editor всё равно может подключиться к кластеру и сделать DROP данных внутри, поэтому защита от удаления не заменяет аккуратное управление доступом и резервное копирование.

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

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

Включайте защиту от удаления на каждом продуктивном кластере БД:

В консоли управления откройте настройки кластера соответствующего сервиса управляемых баз данных.
В разделе Дополнительные настройки включите опцию Защита от удаления.
Задокументируйте, кто имеет право снимать флаг (например, только участники команды платформы), и проверяйте это через модуль диагностики доступа (CIEM) сервиса Security Deck.
Убедитесь, что срок хранения резервных копий покрывает ваши требования к восстановлению — защита от удаления не заменяет резервное копирование.

Таймаут жизни cookie в федерации меньше 6 часов

kind	severity	ID
manual	high	cookie-timeout.organization

Описание

Ограничение срока действия cookie — ключевая мера безопасности веб‑приложений, поскольку оно существенно сокращает риски, связанные с компрометацией пользовательских сессий. Короткий таймаут минимизирует потенциальный ущерб в случае кражи cookie (например, через атаки типа XSS или MITM), а также ограничивает время возможного использования перехваченных данных злоумышленником.

Кроме того, автоматическое завершение сессий по истечении заданного периода (например, через 6 часов) предотвращает неавторизованный доступ, если пользователь забыл выйти из аккаунта на чужом устройстве или если его устройство было скомпрометировано.

Риски при невыполнении правила: Долгоживущие сессионные cookie дают злоумышленникам расширенное окно для использования украденных учётных данных — скомпрометированный cookie из XSS- или MITM-атаки может использоваться часами или днями, обеспечивая длительный несанкционированный доступ к ресурсам облака.

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

В настройках федерации удостоверений необходимо убедиться, что значение параметра Время жизни cookie меньше либо равно 6 часов. Это необходимо, чтобы минимизировать риск компрометации рабочих станций пользователей облака.

Задайте значение параметра Время жизни cookie равным 6 часам (21600 секундам) или меньше.

Доступ к компонентам Kubernetes ограничен по IP-адресам, портам и протоколам

kind	severity	ID
automatic	medium	k8s.network-firewall-scope

Описание

Рекомендуется использовать группы безопасности, чтобы настроить безопасный доступ к компонентам кластеров Kubernetes по принципу минимальных привилегий. Для доступа к компонентам кластера открывайте только необходимые порты по необходимым сетевым протоколам и только для доверенных IP-адресов.

Риски при невыполнении правила: Без должным образом настроенных групп безопасности компоненты кластера Kubernetes — API-сервер, порты узлов и внутренние сервисы — могут быть доступны из нежелательных источников. Это увеличивает поверхность атаки и может позволить злоумышленнику, закрепившемуся в сети, добраться до компонентов кластера, которые не должны быть доступны.

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

Создайте группу безопасности и настройте ее для применения в кластере Kubernetes.

При настройке руководствуйтесь ключевыми принципами настройки групп безопасности для кластеров Kubernetes:

Не используйте правила безопасности с широкими правилами доступа:
- Диапазон портов: 0-65535.
- Протокол: Любой.
- Источник: CIDR.
- CIDR-блоки: IPv4 0.0.0.0/0 или IPv6 ::/0 (доступ открыт с любых адресов).
Создавайте отдельные группы безопасности для:
- мастеров Kubernetes;
- узлов Kubernetes;
- балансировщиков нагрузки и Ingress-контроллеров;
- баз данных и бэкендов;
- бастионных хостов.
В правилах безопасности используйте ссылки на другие группы безопасности вместо IP-адресов ресурсов (в поле Источник/Назначение выбирайте Группы безопасности вместо CIDR). Это позволит сохранить сетевой доступ при изменении IP-адресов ресурсов.
Ограничьте исходящий трафик. Рекомендуется явно задавать диапазоны IP-адресов, портов и протоколы назначения в правилах безопасности для исходящего трафика.
Включите логирование работы кластеров Kubernetes.
Активируйте Flow Logs Kubernetes для мониторинга трафика.

Настроен сбор аудитных логов для расследований инцидентов

kind	severity	ID
manual	high	k8s.network-policy

Описание

Как работает правило: данное правило требует ручной проверки настройки сбора аудитных логов.

События, доступные пользователю в рамках сервиса Managed Service for Kubernetes, можно разделить на следующие уровни:

события Kubernetes API (Kubernetes Audit logging);
события узлов Kubernetes;
события подов Kubernetes;
метрики Kubernetes;
Flow logs Kubernetes.

Подробнее о настройке сбора событий аудита на разных уровнях см. в разделе Сбор, мониторинг и анализ аудитных логов Managed Service for Kubernetes.

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

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

Managed Service for Kubernetes предоставляет возможность проводить аудит текущей ролевой модели в сервисе. Для этого в консоли управления откройте страницу кластера Kubernetes и перейдите на вкладку Управление доступом.

Также можно использовать:

KubiScan.
Krane.
Аудитные логи Yandex Audit Trails.

На управляемых базах данных не назначен публичный IP-адрес

kind	severity	ID
automatic	medium	network.db-ip

Описание

Управляемые базы данных в Yandex Cloud можно создавать с публичным IP — хостом, доступным напрямую из интернета. С публичным IP база слушает подключения с любого адреса; между злоумышленником и данными остаются только её группа безопасности и аутентификация в самой СУБД.

В большинстве случаев серверы приложений и база работают в одной облачной сети, и публичный IP базе не нужен. Он уместен только тогда, когда к базе действительно нужно обращаться вне Yandex Cloud, и даже тогда доступ должен быть жёстко ограничен на сетевом уровне.

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

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

Для каждой управляемой базы с публичным IP:

Если доступ извне не нужен, удалите публичный IP, чтобы база была доступна только из облачной сети.
Если доступ извне нужен, привяжите группу безопасности, разрешающую трафик только с небольшого списка доверенных диапазонов IP и только на порт базы.
Убедитесь, что база использует TLS для клиентских подключений, а аутентификация — стойкие пароли или, где это поддерживается, сертификаты.

На управляемых базах данных назначена группа безопасности

kind	severity	ID
automatic	high	network.db-security-group

Описание

Управляемую базу в Yandex Cloud можно создать без группы безопасности. Без неё сетевой доступ к базе определяется группой безопасности сети по умолчанию, а та обычно разрешает весь трафик — добраться до порта базы может любой ресурс в облачной сети (и любой адрес из интернета, если у базы публичный IP).

Даже при стойкой аутентификации в самой СУБД ничем не ограниченная сетевая открытость подставляет базу под сканирование, подбор паролей и эксплуатацию любой будущей уязвимости. Группа безопасности сужает эту открытость до известного списка клиентов.

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

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

Привяжите группу безопасности к каждой управляемой базе:

Создайте группу безопасности, разрешающую трафик только с тех диапазонов IP или других групп безопасности, откуда базе действительно нужно принимать подключения (обычно: Pod или ВМ приложения, BI-инструменты, административный bastion).
Привяжите группу к базе — для существующего кластера через сетевые настройки, для нового — при создании.
Убедитесь, что правило покрывает только порт базы (например, 5432 для PostgreSQL, 3306 для MySQL) и нужный протокол.

Для баз с данными PCI DSS или персональными данными дополнительно ограничьте доступ только диапазонами IP доверенных сетей — не оставляйте базу доступной из интернета.

Для объектов облака используется межсетевой экран или группы безопасности

kind	severity	ID
automatic	high	network.firewall

Описание

Как работает правило: при данном контроле автоматически проверяется, что на каждом подключенном к ВМ сетевом интерфейсе есть дополнительные назначенные группы безопасности, кроме группы безопасности по умолчанию. Если используется наложенный межсетевой экран, просьба вручную отметить контроль выполненным.

Встроенный механизм групп безопасности позволяет управлять доступом ВМ к ресурсам и группами безопасности Yandex Cloud или ресурсам в интернете. Группа безопасности — это набор правил для входящего и исходящего трафика, который можно назначить на сетевой интерфейс ВМ. Группы безопасности работают как stateful firewall, то есть отслеживают состояние сессий: если правило разрешает создать сессию, ответный трафик будет автоматически разрешен. Инструкцию по настройке групп безопасности см. в разделе Создать группу безопасности. Указать группу безопасности можно в настройках ВМ.

Группы безопасности могут использоваться для защиты:

ВМ
Управляемых баз данных
Балансировщиков нагрузки Yandex Application Load Balancer
Кластеров Yandex Managed Service for Kubernetes®

Вы можете управлять сетевым доступом без групп безопасности, например с помощью отдельной ВМ — межсетевой экран на основе образа NGFW из Yandex Cloud Marketplace либо своего собственного образа. Использование NGFW может быть критично для тех клиентов, которым необходима следующая функциональность:

Составление логов сетевых соединений
Потоковый анализ трафика на предмет зловредного контента
Обнаружение сетевых атак по сигнатурам
Другая функциональность классических NGFW-решений

Убедитесь, что в ваших облаках используется что-либо из списка:

Группы безопасности на каждом объекте облака
Отдельная ВМ NGFW из Cloud Marketplace
Принцип BYOI, например собственный образ диска

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

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

Примените группы безопасности на все объекты, на которых группа отсутствует.
Для применения группы безопасности с помощью Terraform используйте настройку групп безопасности (dev/stage/prod) с помощью Terraform.
Для использования NGFW установите на ВМ межсетевой экран (NGFW): Check Point.
Инструкция по использованию UserGate NGFW в облаке.
NGFW в режиме active-passive.

В группах безопасности отсутствует правило с чрезмерно широкими правами доступа

kind	severity	ID
automatic	medium	network.network-firewall-scope

Описание

В группе безопасности существует возможность открыть сетевой доступ для абсолютно всех IP-адресов интернета и также по всем диапазонам портов. Опасное правило выглядит следующим образом:

Диапазон портов: 0-65535 или пусто
Протокол: любой или TCP/UDP
Источник: CIDR
CIDR-блоки: 0.0.0.0/0 (доступ со всех адресов) или ::/0 (ipv6)

Важно

Если диапазон портов не указан, считается, что доступ предоставляется по всем портам (0-65535).

Открывать сетевой доступ необходимо только по тем портам, которые требуются для работы вашего приложения, и для тех адресов, с которых необходимо подключаться к вашим объектам.

Риски при невыполнении правила: Чрезмерно широкое правило группы безопасности открывает все сервисы, работающие на ВМ или ресурсе, для всего интернета. Злоумышленники могут сканировать и эксплуатировать любой открытый порт — включая административные интерфейсы, базы данных или внутренние API — без необходимости обходить какие-либо сетевые средства контроля. Это одна из наиболее распространённых причин инцидентов безопасности в облаке.

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

Удалите опасное правило в каждой группе безопасности или отредактируйте его, указав доверенные IP-адреса.

В Virtual Private Cloud создана группа безопасности и не используется группа безопасности по умолчанию

kind	severity	ID
automatic	medium	network.network-firewall

Описание

Группа безопасности в Virtual Private Cloud управляет входящим и исходящим сетевым трафиком для облачных объектов, к которым она привязана: виртуальных машин, кластеров Managed Service for Kubernetes, балансировщиков, управляемых баз данных.

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

Для реальных нагрузок создавайте собственные группы безопасности с явными правилами — например, только HTTP/HTTPS для веб-сервера или только SSH с bastion-хоста — и привязывайте их к объектам сети. К одному объекту можно привязать до пяти групп безопасности.

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

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

Для каждой облачной сети:

Создайте группу безопасности с правилами, разрешающими только те протоколы, порты и адреса источников, которые действительно нужны нагрузке.
Привяжите эту группу к виртуальным машинам, кластерам Kubernetes, управляемым базам данных и другим объектам в сети — это переопределяет для них группу по умолчанию.
В правилах используйте ссылки на другие группы безопасности, а не жёстко прописанные IP-адреса (в поле Источник/Назначение выбирайте Группа безопасности вместо CIDR) — так правила доступа продолжают работать при смене IP-адресов.

Serverless Containers/Cloud Functions использует внутреннюю сеть VPC

kind	severity	ID
manual	information	network.serverless-uses-vpc

Описание

По умолчанию функция запускается в изолированной IPv4-сети с включенным NAT-шлюзом. Поэтому из функции доступны только публичные IPv4-адреса. Возможности закрепить адрес нет.

Сетевое взаимодействие между двумя функциями, а также между функциями и пользовательскими ресурсами ограничено:

Входящие соединения не поддерживаются. Например, нельзя обратиться по сети к внутренним компонентам функции, даже если известен IP-адрес ее экземпляра.
Исходящие соединения поддерживаются по протоколам TCP, UDP и ICMP. Например, функция может получить доступ к виртуальной машине Yandex Compute Cloud или базе данных Yandex Managed Service for YDB в сети пользователя.
Функция выполняется кросс-зонально: для запуска функции нельзя явным образом задать подсеть или выбрать зону доступности.

Если необходимо, в настройках функции можно указать облачную сеть. В этом случае:

Функция будет выполняться в указанной облачной сети.
Во время выполнения функция получит IP-адрес в соответствующей подсети и доступ ко всем ресурсам сети.
Функция будет иметь доступ не только в интернет, но и к пользовательским ресурсам, которые находятся в указанной сети, например, базам данных, виртуальным машинам и т.п.
Функция будет иметь IP-адрес в диапазоне 198.19.0.0/16 при доступе к пользовательским ресурсам.
Для функций, контейнеров и API-шлюзов, которые находятся в одном облаке, можно указать только одну сеть.

Риски при невыполнении правила: Без интеграции с VPC бессерверные функции могут обращаться только к публичным интернет-эндпоинтам — они не могут достичь приватных облачных ресурсов, таких как управляемые базы данных, внутренние ВМ или приватные API-эндпоинты, без открытия этих ресурсов в интернет. Это может вынуждать команды делать внутренние ресурсы публично доступными, увеличивая общую поверхность атаки.

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

В консоли управления выберите облако или каталог, в которых хотите проверить функции.
Перейдите в сервис Cloud Functions.
Откройте функцию.
В настройках объектов перейдите на вкладку Редактирование версии функции.
В поле Сеть выберите нужную облачную сеть.
Нажмите Сохранить изменения.

Публичный доступ отсутствует для YDB

kind	severity	ID
automatic	low	network.ydb-public

Описание

Примечание

Правило не проверяет базы данных, работающие в режиме Serverless.

У Yandex Managed Service for YDB есть два режима:

Dedicated — база разворачивается в вашей VPC. По умолчанию доступна только из облачной сети; публичный эндпоинт можно включить, но это не обязательно.
Serverless — база всегда доступна из интернета (сервис сам управляет маршрутизацией и масштабом). Для serverless-баз публичный эндпоинт — часть модели сервиса и его нельзя отключить.

Для Dedicated-баз выставление эндпоинта в интернет без явной причины — лишняя площадь атаки. Для Serverless-баз публичный эндпоинт нужно учитывать при моделировании угроз: контроль доступа держится полностью на аутентификации и авторизации в самой базе.

Подробнее — в разделе Режимы работы Serverless и Dedicated документации Managed Service for YDB.

Риски при невыполнении правила: Публично доступный эндпоинт Dedicated YDB может стать целью атак методом перебора, эксплуатации уязвимостей или атак типа «отказ в обслуживании» напрямую из интернета. Без сетевых ограничений база данных полностью полагается на собственные механизмы аутентификации, которых может быть недостаточно при слабых или утёкших учётных данных.

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

Для Dedicated-баз:

Отключите публичный эндпоинт, если он не нужен; обращайтесь к базе только из VPC.
Если публичный эндпоинт должен остаться включённым, относитесь к базе как к публично доступной нагрузке — ограничивайте доступ на уровне базы и следите за событиями аутентификации.

Для Serverless-баз:

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

Включен сервис Yandex Audit Trails на уровне организации

kind	severity	ID
automatic	high	o11y.audit-trails

Описание

Yandex Audit Trails — основной инструмент сбора аудитных логов Yandex Cloud. Сервис записывает, что происходит с ресурсами облака, и выгружает логи в бакет Object Storage или лог-группу Cloud Logging для дальнейшего анализа или экспорта.

Audit Trails различает два типа событий:

События уровня конфигурации — действия с конфигурацией облака: создание, изменение, удаление компонентов инфраструктуры, пользователей, политик. Пишутся по умолчанию, как только создан трейл.
События уровня сервисов — действия с данными и ресурсами внутри сервисов (например, обращения к объектам в бакете). По умолчанию не пишутся; включаются отдельно для каждого сервиса.

Audit Trails можно включить на уровне каталога, облака или организации. Рекомендуется включать его на уровне всей организации: это даёт единый централизованный поток логов по всей организации — как правило, в отдельное облако безопасности, — на что рассчитаны большинство схем мониторинга и compliance.

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

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

Включите Audit Trails на уровне организации:

Создайте трейл на уровне организации и выберите приёмник — бакет Object Storage, лог-группу Cloud Logging или поток Yandex Data Streams.
Для сервисов, где важны события уровня сервисов (IAM, KMS, Lockbox, Object Storage, Managed Service for Kubernetes, управляемые БД), включите сбор data-событий на трейле.
Перенаправьте приёмник в вашу SIEM или другую систему мониторинга — см. правило «События Yandex Audit Trails экспортируются в SIEM-систему».
Настройте мониторинг состояния самого трейла (статус Error, разрывы в событиях) — см. правило «Сервис Yandex Audit Trails работает в штатном режиме».

Список важных событий безопасности, которые стоит искать в аудитных логах, — в библиотеке решений на GitHub.

Отслеживаются события уровня сервисов

kind	severity	ID
manual	medium	o11y.data-plane-events

Описание

Как работает правило:

Правило проверяет, что отлеживаются события следующих сервисов:

Yandex Identity and Access Management — создание и удаление сервисных аккаунтов, назначение ролей, выдача и отзыв прав доступа, создание и удаление ключей и другие события.
Yandex Certificate Manager — создание, обновление и удаление SSL-сертификатов, импорт сертификатов, привязка к ресурсам.
Yandex Key Management Service — создание, ротация и удаление ключей шифрования, изменение прав доступа к ключам.
Yandex Lockbox — создание, изменение и удаление секретов, управление версиями секретов.
Yandex Managed MySQL и Yandex Managed PostgreSQL — создание, изменение и удаление баз данных и пользователей, выдача и отзыв прав доступа.

Аудитный лог событий уровня сервисов — это запись в виде JSON-объекта о событиях, которые произошли с ресурсами Yandex Cloud. Отслеживание событий уровня сервисов упрощает сбор дополнительных событий с облачных сервисов, что позволяет эффективнее реагировать на инциденты безопасности в облаках. Кроме того, отслеживание событий уровня сервисов помогает обеспечить соответствие вашей облачной инфраструктуры нормативным правовым актам и отраслевым стандартам. Например, вы можете отслеживать получение сотрудниками доступа к конфиденциальным данным, хранящимся в бакетах.

Включать сбор аудитных логов уровня сервисов нужно отдельно для каждого из поддерживаемых сервисов.

Риски при невыполнении правила: Без мониторинга событий уровня сервисов действия с чувствительными данными — например, чтение секретов из Lockbox, обращение к объектам в Object Storage или выполнение запросов к управляемым базам данных — невидимы в аудитных логах. Это делает невозможным обнаружение утечки данных, несанкционированного доступа к чувствительным ресурсам или внутренних угроз, действующих на уровне данных.

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

Рекомендуется выбирать опцию Получать все события для сервисов Yandex Identity and Access Management и Yandex Cloud DNS, а также для следующих сервисов, если эти сервисы используются:

В Object Storage включена функция «Блокировка версии объекта» (object lock)

kind	severity	ID
manual	medium	s3.used-object-lock

Описание

Object Lock в Object Storage запрещает удалять и перезаписывать версии объекта в течение заданного срока. Даже учётная запись с полными правами на бакет не сможет удалить заблокированную версию, пока блокировка не истечёт.

Для бакетов, в которых лежат данные, которые нельзя удалять — аудитные логи, финансовая отчётность, доказательная база, неизменяемые резервные копии, — именно Object Lock делает данные устойчивыми к ошибкам оператора, вредоносным действиям скомпрометированной учётной записи и ransomware, который пытается перезаписать версии.

Для работы Object Lock у бакета должно быть включено версионирование, потому что блокировка применяется к конкретной версии объекта.

Сроки хранения определяются требованиями вашей информационной безопасности: например, PCI DSS требует хранить аудитные логи не менее года, при этом минимум три месяца — в немедленном доступе.

Риски при невыполнении правила: Без Object Lock аудитные логи, финансовая отчётность и другие неизменяемые данные могут быть удалены или перезаписаны — будь то по ошибке оператора, скомпрометированной учётной записью или программой-вымогателем. Это подрывает целостность аудитных следов, делает криминалистическое расследование невозможным после инцидента и может привести к несоответствию нормативным требованиям, предписывающим защищённое от изменений хранение логов.

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

Для каждого бакета, данные которого нужно защитить от удаления:

Включите версионирование бакета.
Включите Object Lock и выберите тип блокировки по умолчанию (GOVERNANCE или COMPLIANCE) и срок, соответствующие вашим требованиям безопасности.
По желанию настройте правила жизненного цикла, чтобы автоматически менять класс хранения и убирать истёкшие неактуальные версии.

Доступ по управляющим портам открыт только для доверенных IP-адресов

kind	severity	ID
automatic	medium	trusted-ip

Описание

Как работает правило: выводится список всех групп безопасности, в которых присутствуют широкие правила доступа по управляющим портам:

Диапазон портов: 22, 3389 или 21.
Протокол: TCP.
Источник: CIDR.
CIDR блоки: IPv4 0.0.0.0/0 или IPv6 ::/0 (доступ открыт с любых адресов).

Доступ к вашей облачной инфраструктуре по управляющим портам рекомендуется разрешать только для доверенных IP-адресов.

Риски при невыполнении правила: Разрешение доступа по SSH (порт 22), RDP (порт 3389) или FTP (порт 21) с любого IP-адреса подвергает облачную инфраструктуру атакам методом перебора, подстановки учётных данных и эксплуатации уязвимостей в сервисах удалённого доступа. Злоумышленники постоянно сканируют интернет в поисках открытых управляющих портов и пытаются получить несанкционированный доступ. Одна скомпрометированная ВМ может стать точкой опоры для горизонтального перемещения по всей облачной среде.

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

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

Если такой доступ открыт для широкого диапазона адресов, уточните доверенные IP-адреса в соответствующих правилах доступа:

В консоли управления выберите каталог, в котором находится нужная группа безопасности.
Перейдите в сервис Virtual Private Cloud.
На панели слева выберите Группы безопасности и в открывшемся списке нажмите на строку с нужной группой безопасности.
В правом верхнем углу экрана нажмите Редактировать.
В блоке Правила в строке с правилом, разрешающим доступ по управляющим портам для широкого диапазона адресов, нажмите значок ... и выберите Редактировать.
В поле CIDR блоки укажите только доверенный адрес, для которого будет разрешен доступ. Например: 198.51.100.17/32.

Чтобы добавить в правило несколько доверенных адресов, воспользуйтесь кнопкой Добавить CIDR.
Нажмите Сохранить, чтобы сохранить настройки правила.
Нажмите Сохранить, чтобы сохранить настройки группы безопасности.

Доступ к компонентам Kubernetes по управляющим портам открыт только для доверенных IP-адресов

kind	severity	ID
automatic	medium	trusted-ip-k8s

Описание

Диапазон портов: 22, 3389 или 21.
Протокол: TCP.
Источник: CIDR.
CIDR-блоки: IPv4 0.0.0.0/0 или IPv6 ::/0 (доступ открыт с любых адресов).

Доступ по управляющим портам к компонентам Kubernetes в вашей облачной инфраструктуре рекомендуется разрешать только для доверенных IP-адресов.

Риски при невыполнении правила: Разрешение доступа по SSH (порт 22), RDP (порт 3389) или FTP (порт 21) с любого IP-адреса подвергает узлы Kubernetes и компоненты кластера атакам методом перебора, подстановки учётных данных и эксплуатации уязвимостей в сервисах удалённого доступа. Злоумышленники могут сканировать интернет в поисках открытых управляющих портов и пытаться получить несанкционированный доступ к инфраструктуре кластера.

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

Убедитесь, что в ваших группах безопасности в правилах доступа к компонентам Kubernetes по управляющим портам разрешен доступ только для доверенных IP-адресов.

В консоли управления выберите каталог, в котором находится нужная группа безопасности.
Перейдите в сервис Virtual Private Cloud.
На панели слева выберите Группы безопасности и в открывшемся списке нажмите на строку с нужной группой безопасности.
В правом верхнем углу экрана нажмите Редактировать.
В блоке Правила в строке с правилом, разрешающим доступ по управляющим портам для широкого диапазона адресов, нажмите значок ... и выберите Редактировать.
В поле CIDR блоки укажите только доверенный адрес, для которого будет разрешен доступ. Например: 198.51.100.17/32.

Чтобы добавить в правило несколько доверенных адресов, воспользуйтесь кнопкой Добавить CIDR.
Нажмите Сохранить, чтобы сохранить настройки правила.
Нажмите Сохранить, чтобы сохранить настройки группы безопасности.

Cloud Security Posture Management (CSPM)Cloud Security Posture Management (CSPM)

API-ключи для сервисов AI Studio должны иметь ограничение срока действияAPI-ключи для сервисов AI Studio должны иметь ограничение срока действия

ОписаниеОписание

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

API-ключи для сервисов AI Studio должны иметь ограниченные области действияAPI-ключи для сервисов AI Studio должны иметь ограниченные области действия

ОписаниеОписание

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

У сервисных аккаунтов сервиса Yandex DataSphere должны отсутствовать критичные ролиУ сервисных аккаунтов сервиса Yandex DataSphere должны отсутствовать критичные роли

ОписаниеОписание

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

ОписаниеОписание

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

ОписаниеОписание

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

ОписаниеОписание

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

Используйте публичные MCP-серверы только при необходимостиИспользуйте публичные MCP-серверы только при необходимости

ОписаниеОписание

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

ОписаниеОписание

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

Секреты, используемые MCP Gateway и Tools, рекомендуется хранить в сервисе Yandex LockboxСекреты, используемые MCP Gateway и Tools, рекомендуется хранить в сервисе Yandex Lockbox

ОписаниеОписание

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

Парольная политика соответствует требованиям стандарта PCI DSS 4.0Парольная политика соответствует требованиям стандарта PCI DSS 4.0

ОписаниеОписание

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

ОписаниеОписание

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

Кластеры Kubernetes проверяются на соответствие требованиям CISКластеры Kubernetes проверяются на соответствие требованиям CIS

ОписаниеОписание

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

Кластер Managed Kubernetes является региональнымКластер Managed Kubernetes является региональным

ОписаниеОписание

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

Исходящий доступ в интернет контролируетсяИсходящий доступ в интернет контролируется

ОписаниеОписание

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

Настроено реагирование на события безопасностиНастроено реагирование на события безопасности

ОписаниеОписание

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

Настроена двухфакторная аутентификация для всех локальных пользователейНастроена двухфакторная аутентификация для всех локальных пользователей

ОписаниеОписание

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

Выполняется периодическая ротация ключей сервисных аккаунтовВыполняется периодическая ротация ключей сервисных аккаунтов

ОписаниеОписание

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

Дата последней аутентификации сервисного аккаунта не превышает 90 днейДата последней аутентификации сервисного аккаунта не превышает 90 дней

ОписаниеОписание

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

Дата последнего использования ключей доступа не превышает 90 днейДата последнего использования ключей доступа не превышает 90 дней

ОписаниеОписание

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

Учетные записи Яндекс ID используются только в исключительных случаяхУчетные записи Яндекс ID используются только в исключительных случаях

ОписаниеОписание

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

ОписаниеОписание

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

Сервисным аккаунтам назначены минимальные привилегии на уровне организацииСервисным аккаунтам назначены минимальные привилегии на уровне организации

ОписаниеОписание

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

Сервисным аккаунтам назначены минимальные привилегии на уровне сервисаСервисным аккаунтам назначены минимальные привилегии на уровне сервиса

ОписаниеОписание

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

Привилегированные роли назначены только доверенным администраторамПривилегированные роли назначены только доверенным администраторам

ОписаниеОписание

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

На ресурсах используются меткиНа ресурсах используются метки

ОписаниеОписание

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

В Yandex Object Storage используются политики доступа (Bucket Policy)В Yandex Object Storage используются политики доступа (Bucket Policy)

ОписаниеОписание

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

Права на управление ключами в KMS выданы уполномоченным пользователямПрава на управление ключами в KMS выданы уполномоченным пользователям

ОписаниеОписание

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

ОписаниеОписание

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

Нет доступа к API KubernetesНет доступа к API Kubernetes

ОписаниеОписание

Cloud Security Posture Management (CSPM)

API-ключи для сервисов AI Studio должны иметь ограничение срока действия

Описание

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

API-ключи для сервисов AI Studio должны иметь ограниченные области действия

Описание

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

У сервисных аккаунтов сервиса Yandex DataSphere должны отсутствовать критичные роли

Описание

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

Описание

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

Описание

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

Описание

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

Используйте публичные MCP-серверы только при необходимости

Описание

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

Описание

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

Секреты, используемые MCP Gateway и Tools, рекомендуется хранить в сервисе Yandex Lockbox

Описание

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

Парольная политика соответствует требованиям стандарта PCI DSS 4.0

Описание

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

Описание

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

Кластеры Kubernetes проверяются на соответствие требованиям CIS

Описание

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

Кластер Managed Kubernetes является региональным

Описание

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

Исходящий доступ в интернет контролируется

Описание

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

Настроено реагирование на события безопасности

Описание

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

Настроена двухфакторная аутентификация для всех локальных пользователей

Описание

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

Выполняется периодическая ротация ключей сервисных аккаунтов

Описание

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

Дата последней аутентификации сервисного аккаунта не превышает 90 дней

Описание

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

Дата последнего использования ключей доступа не превышает 90 дней

Описание

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

Учетные записи Яндекс ID используются только в исключительных случаях

Описание

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

Описание

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

Сервисным аккаунтам назначены минимальные привилегии на уровне организации

Описание

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

Сервисным аккаунтам назначены минимальные привилегии на уровне сервиса

Описание

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

Привилегированные роли назначены только доверенным администраторам

Описание

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

На ресурсах используются метки

Описание

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

В Yandex Object Storage используются политики доступа (Bucket Policy)

Описание

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

Права на управление ключами в KMS выданы уполномоченным пользователям

Описание

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

Описание

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

Нет доступа к API Kubernetes

Описание