Все правила Yandex Security Deck

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

Yandex Cloud

Обновлена 30 апреля 2026 г.

CSPM — Cloud Security Posture Management
KSPM — Kubernetes® Security Posture Management

На этой странице представлен полный список правил безопасности, используемых в Security Deck.

CSPM — Cloud Security Posture Management

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

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

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

Описание

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

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

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

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

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

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

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

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

Описание

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

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

admin
editor
resource-manager.clouds.owner

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

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

Отзовите избыточные доступы у сервисного аккаунта с помощью сервиса 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

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

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

Отзовите избыточные доступы у сервисного аккаунта с помощью сервиса 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

Описание

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

Правило автоматически находит бакеты, в которых не настроены политики доступа.

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

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

Примеры Bucket Policy:

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

Рекомендуется убедиться, что в вашем бакете Object Storage используется как минимум одна политика.

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

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

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

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

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

Описание

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

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

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

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

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

Для доступа к сервису Yandex 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

Описание

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

Автоматизировать этот процесс можно с помощью настройки расписания.

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

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

Автоматизируйте сканирование Docker-образа на наличие уязвимостей с помощью настройки расписания.

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

kind	severity	ID
automatic	medium	k8s.api-security

Описание

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

Примечание

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

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

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

Рекомендуется использовать кластеры 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 управляет узлами кластера, подсетями для подов и сервисов, дисками, балансировками нагрузки, а также шифрует и дешифрует секреты.
Сервисный аккаунт группы узлов — от имени этого сервисного аккаунта узлы кластера Managed Service for Kubernetes аутентифицируются в Yandex Container Registry или в Yandex Cloud Registry. Для других container registry роли сервисному аккаунту назначать не требуется.

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

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

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

Сервисные роли Managed Service for Kubernetes (доступ к Yandex Cloud API): позволяют управлять кластерами и группами узлов (например, создать кластер, создать/редактировать/удалить группу узлов и т.д.).
Сервисные роли для доступа к Kubernetes API: позволяют управлять ресурсами кластера через Kubernetes API (например, стандартные действия с Kubernetes: создание, удаление, просмотр пространств имен, работа с подами, deployments, создание ролей и т.д.). Доступны только базовые глобальные роли на уровне всего кластера: k8s.cluster-api.cluster-admin, k8s.cluster-api.editor и k8s.cluster-api.viewer.
Примитивные роли: глобальные примитивные роли IAM, которые содержат в себе сервисные роли (например, примитивная роль admin содержит в себе и сервисную административную роль и административную роль для доступа к Kubernetes API).
Стандартные роли Kubernetes: внутри самого кластера Kubernetes доступно создание ролей и кластерных ролей средствами Kubernetes. Таким образом можно управлять доступом учетных записей IAM на уровне пространства имен. Для назначения IAM ролей на уровне пространства имен возможно вручную создавать объекты RoleBinding в необходимом пространстве имен, указывая в поле subjects name идентификатор IAM пользователя облака.

Выполняется мониторинг событий безопасности инстанса 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.

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

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

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

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

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

Описание

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

Проверка выводит список трейлов Audit Trails в статусе 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.

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

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

Описание

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

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

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

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

Описание

Примечание

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

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

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

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

Регулярно проводится аудит прав доступа пользователей и сервисных аккаунтов с использованием Yandex Security Deck CIEM

kind	severity	ID
manual	information	access.check-bindings

Описание

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

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

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

Модуль диагностики доступов или CIEM (Cloud Infrastructure Entitlement Management) — это инструмент, позволяющий централизованно просматривать полный список доступов субъектов: пользователей, сервисных аккаунтов, групп пользователей, системных групп и публичных групп к ресурсам организации. Этот инструмент также позволяет легко отзывать у субъектов лишние доступы.

Подробнее см. в разделе Модуль диагностики доступов (CIEM).

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

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

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки ACL на экземплярах Container Registry.

Доступ к вашему Container Registry рекомендуется ограничить до конкретных IP-адресов.

В консоли управления выберите облако или каталог, в которых необходимо проверить реестр.
В списке сервисов выберите Container Registry.
В настройках конкретного реестра перейдите во вкладку Доступ для IP-адресов.
Если в параметрах указаны конкретные адреса для доступа, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

В консоли управления выберите облако или каталог, в которых нужно проверить ВМ.
В списке сервисов выберите Compute Cloud.
Зайдите в настройки конкретной ВМ c ContainerOptimizedImage.
В блоке Настройки Docker-контейнера отключите параметр Привилегированный режим.

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

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

Описание

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

Рекомендуется назначать минимальные роли на бакет с помощью IAM и дополнять или детализировать их с помощью BucketPolicy (например, для ограничения доступа к бакету по IP-адресам, выдачи гранулярных прав на объекты и т.д.).
Если публичный доступ необходим - рекомендуется использовать DSPM для контроля наличия чувствительных данных в бакетах.

Проверка публичных IP-адресов виртуальных машин

kind	severity	ID
manual	medium	access.compute-public-ip

Описание

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

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

Виртуальные машины с публичными IP-адресами доступны из интернета. Рекомендуется использовать публичные IP-адреса только для ресурсов, которым требуется прямой доступ из интернета (например, для NAT-инстансов или бастион-хостов). Для остальных ресурсов рекомендуется использовать приватные IP-адреса и организовывать доступ через VPN или бастион-хосты.

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

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

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

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

Описание

Автоматическая проверка

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

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

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

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

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

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

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

Описание

Автоматическая проверка

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

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

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

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

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

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

Описание

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

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

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

Больше информации: https://yandex.cloud/ru/docs/security/standard/authentication#api-key-scopes

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

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

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

kind	severity	ID
manual	medium	access.min-privileges

Описание

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

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

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

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

Проанализируйте найденные учетные записи с назначенными примитивными ролями admin, editor и viewer и замените их на роль auditor или сервисные гранулярные роли в соответствии с вашей матрицей ролей: https://yandex.cloud/ru/docs/iam/roles-reference
Чтобы просмотреть полный список доступов субъекта, воспользуйтесь инструкцией: https://yandex.cloud/ru/docs/security-deck/operations/ciem/view-permissions

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

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

Описание

Автоматическая проверка

Данный контроль автоматически проверяет использование OS Login на виртуальных машинах и узлах Kubernetes.

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

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

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

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

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

kind	severity	ID
manual	high	access.public-access

Описание

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

В Yandex Cloud существует возможность предоставлять публичный доступ на ресурсы. Публичный доступ предоставляется путем назначения прав доступа для публичных групп (All authenticated users, All users).

Описание публичных групп:

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

Важно

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

Убедитесь, что на ваши ресурсы — облака, каталоги, бакеты и т.д., не предоставлен публичный доступ для этих групп.

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

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

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

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.

При работе с серийной консолью:

Убедитесь, что критичные данные не попадают в вывод серийной консоли.
При включенном доступе к серийной консоли по SSH убедитесь, что работа с учетными данными и пароль для локального входа в операционную систему соответствуют стандартам регуляторов. Например, в инфраструктуре для хранения данных платежных карт пароль должен соответствовать требованиям стандарта PCI DSS: содержать как буквы, так и цифры, иметь длину не менее 7 символов и меняться не реже чем каждые 90 дней.
Не рекомендуется использовать доступ к серийной консоли без крайней необходимости.

Оцените риск включения доступа через серийную консоль, учитывая следующие факторы:

ВМ будет доступна для управления из интернета даже в случае отсутствия внешнего IP-адреса.
Получить доступ к серийной консоли ВМ из консоли управления Yandex Cloud сможет пользователь, успешно аутентифицированный в консоли управления Yandex Cloud при наличии должных прав на ВМ. Доступ к серийной консоли ВМ из клиентского приложения SSH (например, Putty) или CLI также возможен путем аутентификации через SSH-ключ. В связи с этим необходимо тщательно контролировать SSH-ключ и завершать веб-сессию для снижения рисков ее перехвата.
Сессия будет доступна одновременно всем пользователям, имеющим право доступа к серийной консоли.
Действия одного пользователя будут видны другим пользователям, если в это время они смотрят вывод серийной консоли.
Незавершенная сессия может быть использована другим пользователем.

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

Не забывайте отключать доступ после работы с серийной консолью.

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

Рекомендуется отключить доступ к серийной консоли: https://yandex.cloud/ru/docs/compute/operations/serial-console/disable

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

kind	severity	ID
automatic	high	appsec.alb-https

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки HTTPS-обработчика на Application Load Balancer.

Сервис Application Load Balancer поддерживает HTTPS-обработчик с загрузкой сертификата из Certificate Manager. См. описание настройки обработчика в документации Yandex Application Load Balancer.

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

Включите HTTPS обработчик согласно инструкции

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

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

Описание

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

Без использования протокола HTTPS трафик между клиентом и API-шлюзом передается в незашифрованном виде, что ведет к следующим рискам:

злоумышленники могут перехватывать данные, например, через атаки типа MITM (Man-in-the-Middle);
при передаче в открытом виде могут оказаться раскрыты конфиденциальные данные: персональные данные, платежная информация, токены аутентификации, пароли и т.п.

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

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

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

kind	severity	ID
automatic	low	appsec.cdn-https

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки HTTPS и SSL-сертификатов на ресурсах CDN.

Cloud CDN поддерживает безопасное подключение по протоколу HTTPS к источникам. Также вы можете загрузить собственный сертификат безопасности для доступа к вашему CDN-ресурсу по протоколу HTTPS.

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

Подключите сертификат и 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-атак — работает на 3, 4 и 7 уровнях модели OSI. Вы также можете отслеживать показатели нагрузки, параметры атак и подключить Solidwall WAF в личном кабинете Curator. Чтобы включить расширенную защиту, обратитесь к вашему менеджеру или в техническую поддержку.

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

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

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

Описание

Автоматическая проверка

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

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

Yandex DDoS Protection — это компонент сервиса VPC для защиты облачных ресурсов от DDoS-атак. DDoS Protection предоставляется в партнерстве с Curator. Работает до уровня L4 модели OSI.

Активация сервиса Yandex DDoS Protection для ВМ или сетевых балансировщиков позволит вам эффективно бороться с атаками, направленными на исчерпание емкости канала и вычислительных ресурсов ваших ВМ.

Для предотвращения таких атак сервис DDoS Protection:

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

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

kind	severity	ID
automatic	high	appsec.periodic-scan

Описание

Автоматическая проверка

Данный контроль автоматически проверяет политики сканирования Docker-образов в Container Registry.

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

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

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

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

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

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

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

kind	severity	ID
automatic	medium	appsec.use-arl

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки Advanced Rate Limiter.

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

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

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

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

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

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

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

kind	severity	ID
automatic	low	appsec.use-smartcaptcha

Описание

Автоматическая проверка

Данный контроль автоматически проверяет использование Yandex SmartCaptcha в приложениях.

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

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

Сервис Yandex SmartCaptcha

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

kind	severity	ID
automatic	high	appsec.use-sws

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки профиля безопасности Yandex Smart Web Security.

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

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

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

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

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

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

kind	severity	ID
automatic	medium	appsec.use-waf

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки Web Application Firewall.

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

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

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

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

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

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

kind	severity	ID
manual	medium	appsec.secure-registry

Описание

Отсутствие контроля новых Docker-образов приводит к рискам, связанным со следующими факторами:

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

Автоматическое сканирование на уязвимости при добавлении новых образов в Container Registry позволит снизить эти риски.

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

В консоли управления выберите каталог, в котором будет создан реестр.
Перейдите в сервис Container Registry.
Нажмите кнопку Создать реестр.
В поле Имя введите имя реестра. Требования к имени:
- длина — от 3 до 63 символов;
- может содержать строчные буквы латинского алфавита, цифры и дефисы;
- первый символ — буква, последний — не дефис.
В блоке Автоматическое сканирование:
- Оставьте включенной опцию Сканировать Docker-образы при загрузке, чтобы сканировать Docker-образы при загрузке в репозиторий.
- Оставьте включенной опцию Сканировать все 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.

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

Чтобы получить 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

Описание

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

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

В облаке существует два способа резервировать виртуальные машины:

с помощью механизма снимков по расписанию;
сервиса Cloud Backup.

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

Резервное копирование в Yandex Compute Cloud включает создание снимков дисков, подключённых к виртуальным машинам (ВМ), и использование сервиса Yandex Cloud Backup.

Cloud Backup — сервис для создания резервных копий и восстановления ресурсов Yandex Cloud и данных на них.

Подключить к Cloud Backup вы можете как новую виртуальную машину Yandex Compute Cloud непосредственно при ее создании, так и уже существующую виртуальную машину с запущенными и настроенными приложениями, ресурсами, данными и т.д.

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

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

kind	severity	ID
automatic	medium	crypto.certificate-validity

Описание

Автоматическая проверка

Данный контроль автоматически проверяет сроки действия сертификатов в Yandex Certificate Manager.

Сервис 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 дней.

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

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

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

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

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки защиты от удаления ключей KMS.

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

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

Установите защиту от удаления: https://yandex.cloud/ru/docs/kms/operations/key#update

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

kind	severity	ID
manual	medium	crypto.keys-hsm

Описание

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

Данное правило требует ручной проверки настроек хранения ключей в HSM.

В продакшн-среде рекомендуется использовать отдельные ключи, все крипто-операции с которыми будут выполняться только внутри специализированного аппаратного устройства. Подробнее см. статью Аппаратный модуль безопасности (HSM)[https://yandex.cloud/ru/docs/kms/concepts/hsm].

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

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

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

Установите алгоритм шифрования для ключей KMS «AES-256 HSM»: https://yandex.cloud/ru/docs/kms/operations/symmetric-encryption

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

kind	severity	ID
automatic	high	crypto.keys-rotation

Описание

Автоматическая проверка

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

Для повышения безопасности инфраструктуры рекомендуется разделить ключи шифрования на две группы:

Ключи для сервисов, которые обрабатывают критичные данные, но не хранят их. Например, Message Queue, Cloud Functions.
Ключи для сервисов, которые хранят критичные данные. Например, Managed Services for Databases.

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

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

Безопасным значением для AES-GCM является шифрование 4 294 967 296 (= 2³²) блоков. После достижения этого количества шифрованных блоков необходимо создать новую версию ключа шифрования данных. Подробнее про режим работы AES-GCM см. в материалах NIST.

Примечание

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

Подробнее о ротации ключей см. в разделе Версия ключа документации 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)

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

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

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

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

Описание

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

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

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

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

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

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

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

kind	severity	ID
automatic	low	crypto.secrets-lockbox

Описание

Автоматическая проверка

Данный контроль автоматически проверяет использование Yandex Lockbox для хранения секретов.

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

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

Примечание

При работе в Terraform рекомендуем заполнять содержимое секрета скриптом. В таком случае содержимое не останется в файле .tfstate.

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

Инструкции по работе с сервисом см. в документации Lockbox: https://yandex.cloud/ru/docs/lockbox

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

kind	severity	ID
automatic	medium	crypto.secrets-serverless

Описание

Автоматическая проверка

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

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

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

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

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

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

Удалите секретные данные из env и воспользуйтесь функционалом интеграции с Lockbox:
- Передать секреты Yandex Lockbox в контейнер: https://yandex.cloud/ru/docs/serverless-containers/operations/lockbox-secret-transmit
- Передать секреты Yandex Lockbox в функцию: https://yandex.cloud/ru/docs/functions/operations/function/lockbox-secret-transmit

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

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

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки шифрования на бакетах Object Storage.

Для защиты критичных данных в Yandex Object Storage рекомендуется использовать шифрование бакета на стороне сервера с помощью ключей Yandex Key Management Service (server-side encryption). Такое шифрование защищает от случайной или намеренной публикации содержимого бакета в интернете. Подробнее см. в разделе Шифрование документации Object Storage.

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

Рекомендуется включить шифрование данных для бакетов с критическими данными: https://yandex.cloud/ru/docs/tutorials/security/server-side-encryption

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

kind	severity	ID
automatic	high	data.storage-https

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки HTTPS на статических сайтах Object Storage.

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

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

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

Включите доступ по HTTPS, если бакет используется для хостинга статического сайта: https://yandex.cloud/ru/docs/storage/operations/hosting/certificate

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

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

Описание

Автоматическая проверка

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

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

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

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

kind	severity	ID
manual	high	cookie-timeout.organization

Описание

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

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

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

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

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

kind	severity	ID
manual	medium	k8s.kubernetes-safe-config

Описание

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

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

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

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

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

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

Описание

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

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

Создайте группу безопасности и настройте ее для применения в кластере 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.

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

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

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

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

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

kind	severity	ID
manual	high	iam.group-membership-admin

Описание

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

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

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

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

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

kind	severity	ID
automatic	high	network.db-ip

Описание

Автоматическая проверка

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

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

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

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

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

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

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

Описание

Автоматическая проверка

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

Назначение публичного IP-адреса на управляемую базу данных повышает риски ИБ. Рекомендуется не назначать внешний IP-адрес без крайней необходимости.

Удалите публичный доступ, если он не требуется.

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

Рекомендуется удалить IP адрес привязанный к базе данных: https://yandex.cloud/ru/docs/vpc/operations/address-delete

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

kind	severity	ID
automatic	high	network.firewall

Описание

Автоматическая проверка

Данный контроль автоматически проверяет наличие групп безопасности для следующих типов ресурсов:
enum <resource-type>

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

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

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

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

Вы можете управлять сетевым доступом без групп безопасности, например, с помощью отдельной ВМ — межсетевой экран на основе образа 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	high	network.network-firewall-scope

Описание

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

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

Важно

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

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

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

Удалите опасное правило в каждой группе безопасности или отредактируйте, указав доверенные IP-адреса: https://yandex.cloud/ru/docs/vpc/operations/security-group-create

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

kind	severity	ID
automatic	medium	network.network-firewall

Описание

Автоматическая проверка

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

Группа безопасности (Security Group, SG) — это ресурс, который создается на уровне облачной сети. После создания группа безопасности может использоваться в сервисах Yandex Cloud для разграничения сетевого доступа объекта, к которому она применяется.

Группа безопасности по умолчанию (Default Security Group, DSG) создается автоматически при создании новой облачной сети. Группа безопасности по умолчанию обладает следующими свойствами:

В новой сети будет разрешать весь сетевой трафик в обоих направлениях — исходящий (egress) и входящий (ingress).
Действует для трафика, проходящего через все подсети в сети, где она создана.
Работает лишь в том случае, если на объект еще явно не назначена группа безопасности.
Ее невозможно удалить, она автоматически удаляется вместе с удалением сети.

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

Злоумышленники могут получить доступ к ресурсам через публичные интерфейсы.
Неконтролируемый трафик повышает уязвимость к DDoS-атакам и сканированию портов.
DSG активна только до тех пор, пока вы не назначите объекту другую группу безопасности.

(Рекомендуем создать](https://yandex.cloud/ru/docs/vpc/operations/security-group-create) собственную группу безопасности с правилами, которые явно разрешают только нужный трафик (например, HTTP/HTTPS для веб-серверов или SSH для администрирования), и назначить созданную группу на облачные объекты (виртуальные машины, кластеры Kubernetes и т.д.), чтобы переопределить DSG.

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

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

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

Создайте группу безопасности в каждой Virtual Private Cloud с ограниченными правилами доступа, чтобы ее можно было назначать на облачные объекты.

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-шлюзов, которые находятся в одном облаке, можно указать только одну сеть.

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

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

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

kind	severity	ID
automatic	low	network.ydb-public

Описание

Автоматическая проверка

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

При работе с базой данных в режиме Dedicated рекомендуется использовать ее внутри VPC и не открывать к ней доступ из интернета. В режиме Serverless база данных является доступной из интернета, что необходимо учитывать, в частности, при моделировании угроз при построении инфраструктуры. Подробнее о режимах работы см. в разделе Режимы работы Serverless и Dedicated документации Managed Service for YDB.

При настройке доступа к БД следует использовать принцип минимальных привилегий.

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

Подробнее о режимах работы см. в разделе Режимы работы Serverless и Dedicated документации Managed Service for YDB
При настройке доступа к БД следует использовать принцип минимальных привилегий.

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

kind	severity	ID
automatic	high	o11y.audit-trails

Описание

Автоматическая проверка

Данный контроль автоматически проверяет настройки сервиса Yandex Audit Trails на уровне организации.

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

Аудитные логи Audit Trails могут содержать два разных типа событий: события уровня конфигурации и события уровня сервисов.

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

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

Для сбора метрик, анализа некоторых событий уровня Yandex Cloud и настройки оповещений рекомендуется использовать сервис Yandex Monitoring. С его помощью возможно отслеживать, например, резкое возрастание нагрузки на Compute Cloud, RPS сервиса Application Load Balancer, значительные изменения в статистике событий сервиса Identity and Access Management.

Кроме того, Monitoring можно применять для мониторинга работоспособности самого сервиса Audit Trails и мониторинга событий безопасности. Выгрузка метрик в SIEM-систему возможна через API, см. инструкцию.

Решение: Мониторинг Audit Trails и событий безопасности с помощью Monitoring

Аудитные логи возможно экспортировать в лог-группу Cloud Logging или Data Streams и в SIEM-систему клиента для анализа информации о событиях и инцидентах.

Список важных событий уровня Yandex Cloud для поиска в аудитных логах:

Решение: поиск важных событий безопасности в аудитных логах

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

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

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

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

Описание

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

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

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

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

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

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

Описание

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

Версионирование бакета — это возможность хранить историю версий объекта. Каждая версия является полной копией объекта и занимает соответствующий объем в Object Storage. С помощью управления версиями вы можете защитить ваши данные как от непреднамеренных действий пользователя, так и от сбоев приложений.

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

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

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

Настройка версионирования описана в статье Версионирование бакета документации Object Storage.

Настройка жизненного цикла описана в статьях Жизненные циклы объектов в бакете и Конфигурация жизненных циклов объектов в бакете документации Object Storage.

Также для защиты версий объекта от удаления необходимо использовать object lock. Подробнее про типы блокировок и как их включить читайте в документации.

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

kind	severity	ID
automatic	medium	trusted-ip

Описание

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

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

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

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

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

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

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

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

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

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

kind	severity	ID
automatic	medium	trusted-ip-k8s

Описание

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

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

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

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

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

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

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

KSPM — Kubernetes® Security Posture Management

Правила для проверки конфигурации кластеров Kubernetes.

Установлены строгие разрешения для файла службы Kubelet

kind	severity	ID
HostSecurity	Medium	host-security.kubelet-service-file-perm-600

Описание

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

Владелец файла службы Kubelet указан как root:root

kind	severity	ID
HostSecurity	Medium	host-security.kubelet-service-file-owner-root

Описание

Файл службы kubelet управляет различными параметрами, которые определяют поведение службы kubelet на рабочем узле.
Вы должны установить владельца файла для поддержания целостности.
Файл должен принадлежать владельцу, указанному как root:root.

Установлены строгие разрешения для файла конфигурации kubeconfig

kind	severity	ID
HostSecurity	Medium	host-security.kubelet-conf-600

Описание

Файл kubelet.conf является файлом kubeconfig для узла. Файл управляет различными параметрами, которые определяют поведение и идентификацию рабочего узла.
Вы должны ограничить разрешения на файл для поддержания целостности.
Файл должен быть доступен для записи только администраторам системы.

Владелец файла конфигурации kubeconfig указан как root:root

kind	severity	ID
HostSecurity	Medium	host-security.kubelet-conf-owner-root

Описание

Файл kubelet.conf является файлом kubeconfig для узла. Файл управляет различными параметрами, которые определяют поведение и идентификацию рабочего узла.
Вы должны установить владельца файла для поддержания целостности.
Файл должен принадлежать владельцу, указанному как root:root.

Установлены строгие разрешения для файла конфигурации Kubelet

kind	severity	ID
HostSecurity	Medium	host-security.kubelet-config-permissions-600

Описание

Если kubelet ссылается на файл конфигурации с аргументом --config, убедитесь, что этот файл имеет разрешения со значением 600 или более строгие.
Kubelet считывает различные параметры, включая настройки безопасности, из файла конфигурации, указанного аргументом --config.
Если этот файл указан, вы должны ограничить его разрешения для поддержания целостности файла.
Файл должен быть доступен для записи только администраторам системы.

Владелец файла конфигурации kubelet указан как root:root

kind	severity	ID
HostSecurity	Medium	host-security.kubelet-config-owner-root

Описание

Если kubelet ссылается на файл конфигурации с аргументом --config, убедитесь, что этот файл принадлежит root:root.
Kubelet считывает различные параметры, включая настройки безопасности, из файла конфигурации, указанного аргументом --config.
Если этот файл указан, вы должны ограничить его разрешения для поддержания целостности файла.
Файл должен принадлежать владельцу, указанному как root:root.

Отключены запросы от анонимных пользователей к серверу Kubelet

kind	severity	ID
HostSecurity	Medium	host-security.anonymous-auth-false

Описание

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

Разрешены только явно авторизованные запросы к серверу Kubelet

kind	severity	ID
HostSecurity	Medium	host-security.auth-mode-not-always-allow

Описание

Не разрешайте все запросы. Включите явную авторизацию.
Агенты Kubelet по умолчанию разрешают все аутентифицированные запросы (даже анонимные) без необходимости явных проверок авторизации с сервера apiserver.
Вы должны ограничить это поведение и разрешить только явно авторизованные запросы.

Включена аутентификация Kubelet с использованием сертификатов

kind	severity	ID
HostSecurity	Medium	host-security.client-ca-file-set

Описание

Включите аутентификацию Kubelet с использованием сертификатов.
Соединения от apiserver к kubelet используются для получения логов для подов, подключения (через kubectl) к запущенным подам и использования функциональности перенаправления портов kubelet.
Эти соединения завершаются на конечной точке HTTPS kubelet.
По умолчанию apiserver не проверяет сертификат обслуживания kubelet, что делает соединение уязвимым для атак типа «человек посередине» и небезопасным для работы через ненадежные и/или публичные сети.
Включение аутентификации сертификатов Kubelet гарантирует, что apiserver может аутентифицировать Kubelet перед отправкой любых запросов.

Kubelet разрешено управлять iptables

kind	severity	ID
HostSecurity	Medium	host-security.make-iptables-util-chains-true

Описание

Разрешите Kubelet управлять iptables.
Kubelet может автоматически управлять необходимыми изменениями в iptables в зависимости от того, как вы выбираете сетевые параметры для подов.
Рекомендуется разрешить kubelet управлять изменениями в iptables.
Это гарантирует, что конфигурация iptables остается синхронизированной с конфигурацией сети подов.
Ручная настройка iptables с динамическими изменениями конфигурации сети подов может помешать связи между подами/контейнерами и внешним миром.
Ваши правила iptables могут быть слишком ограничительными или слишком открытыми.

Включена ротация клиентских сертификатов Kubelet

kind	severity	ID
HostSecurity	Medium	host-security.rotate-certs-not-false

Описание

Включите ротацию клиентских сертификатов kubelet.
Параметр --rotate-certificates запускает ротацию клиентских сертификатов kubelet, создавая новые CSR по мере истечения срока действия существующих учетных данных.
Эта автоматическая периодическая ротация гарантирует отсутствие простоев из-за просроченных сертификатов и, таким образом, решает проблему доступности в триаде безопасности CIA.
Примечание: Эта рекомендация применяется только в том случае, если вы разрешаете kubelet получать сертификаты с сервера API.
Если сертификаты kubelet поступают от внешнего инструмента (например, Vault), вам необходимо настроить ротацию самостоятельно.
Примечание: Эта функция также требует, чтобы шлюз RotateKubeletClientCertificate был включен (включен по умолчанию начиная с Kubernetes v1.7)

Все правила Yandex Security Deck

CSPM — Cloud Security Posture ManagementCSPM — Cloud Security Posture Management

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РекомендацииРекомендации

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

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

РекомендацииРекомендации

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

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

РекомендацииРекомендации

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

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

РекомендацииРекомендации

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

РекомендацииРекомендации

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

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

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

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

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

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

Проверка публичных IP-адресов виртуальных машин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CSPM — Cloud Security Posture Management

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

Рекомендации

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

Описание

Рекомендации

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

Описание

Рекомендации

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

Описание

Рекомендации

Описание

Рекомендации

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

Описание

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

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

Описание

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

Описание

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

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

Описание

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

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

Описание

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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

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

Описание

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