Yandex Cloud
Поиск
Связаться с намиПопробовать бесплатно
  • Истории успеха
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
  • Marketplace
    • Доступны в регионе
    • Инфраструктура и сеть
    • Платформа данных
    • Искусственный интеллект
    • Безопасность
    • Инструменты DevOps
    • Бессерверные вычисления
    • Управление ресурсами
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Партнёрская программа
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Калькулятор цен
    • Тарифы
    • Акции и free tier
  • Истории успеха
  • Документация
  • Блог
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ТОО «Облачные Сервисы Казахстан»
Yandex Security Deck
  • Правила тарификации
    • Обзор
    • Все правила
    • CSPM
  • Аудитные логи Audit Trails
  • История изменений

В этой статье:

  • CSPM — Cloud Security Posture Management
  • Настроен ACL по IP адресам для Yandex Container Registry
  • Отсутствует публичный доступ к бакету Object Storage
  • На управляемых БД выключен доступ из консоли управления
  • Выключена настройка доступа из DataLens без необходимости
  • Для API-ключей сервисных аккаунтов заданы минимально необходимые области действия
  • Используются сервисные роли вместо примитивных: admin, editor, viewer
  • Для подключения к виртуальной машине используется OS Login
  • На ресурсах в организации отсутствует публичный доступ
  • Сервисным аккаунтам назначены минимальные привилегии
  • Использование серийной консоли контролируется либо отсутствует
  • Настроена федерация удостоверений (Single Sign-On, SSO)
  • Выполняется сканирование уязвимостей на уровне облачных IP-адресов
  • В Yandex Application Load Balancer используется HTTPS
  • В Yandex API Gateway используется HTTPS и собственный домен
  • В Yandex Cloud CDN используется HTTPS и собственный SSL-сертификат
  • Используется защита от DDoS атак на уровне приложений (L7)
  • Docker-образы сканируются при загрузке в Container Registry
  • При создании реестра в Yandex Container Registry по умолчанию оставляйте безопасные настройки реестра
  • Используется Advanced Rate Limiter
  • Используется Yandex SmartCaptcha
  • Используется профиль безопасности Yandex Smart Web Security
  • Используется Web Application Firewall
  • Используется Cloud Backup или механизм snapshot по расписанию
  • Срок действия сертификата Yandex Certificate Manager составляет как минимум 30 дней
  • Используется шифрование данных на уровне приложения
  • Для ключей KMS включена защита от удаления
  • Ключи Key Management Service хранятся в аппаратном модуле безопасности (HSM)
  • Для KMS ключей включена ротация
  • Используется шифрование дисков и снимков виртуальных машин
  • Выполняется периодическая ротация ключей сервисных аккаунтов
  • При работе Container Optimized Image используется шифрование секретов
  • В организации используется Yandex Lockbox для безопасного хранения секретов
  • Для Serverless Containers и Cloud Functions используются секреты Lockbox
  • В Yandex Object Storage включено шифрование данных at rest с ключом KMS
  • В Yandex Object Storage включено HTTPS для хостинга статического сайта
  • Включена настройка защиты от удаления (deletion protection)
  • Настроен сбор аудитных логов Kubernetes для расследований инцидентов
  • Настроено резервное копирование Kubernetes
  • Managed Service for Kubernetes используется безопасная конфигурация
  • Используется одна из трех последних версий Kubernetes и ведется мониторинг обновлений
  • На управляемых базах данных назначена Группа безопасности
  • На управляемых базах данных не назначен публичный IP-адрес
  • Используется защита от DDoS атак на уровне сети (L3)
  • Для объектов облака используется межсетевой экран или группы безопасности
  • В группах безопасности отсутствует слишком широкое правило доступа
  • В Virtual Private Cloud создана группа безопасности и не используется группа безопасности по умолчанию
  • Запросы DNS не передаются в сторонние рекурсивные резолверы
  • Публичный доступ отсутствует для YDB
  • Выполняется сбор аудитных логов с уровня приложений
  • Включен сервис Yandex Audit Trails на уровне организации
  • События Yandex Audit Trails экспортируются в SIEM-системы
  • Выполняется сбор аудитных логов с уровня ОС
  • Администратор облака имеет инструкцию по действиям в случае компрометации секретов его облака
  • Контактные данные ответственного за организацию актуальны
  • Выполняется контроль целостности
  1. Справочник правил
  2. CSPM
Статья создана
Yandex Cloud
Обновлена 24 февраля 2026 г.
  • CSPM — Cloud Security Posture Management
    • Настроен ACL по IP адресам для Yandex Container Registry
    • Отсутствует публичный доступ к бакету Object Storage
    • На управляемых БД выключен доступ из консоли управления
    • Выключена настройка доступа из DataLens без необходимости
    • Для API-ключей сервисных аккаунтов заданы минимально необходимые области действия
    • Используются сервисные роли вместо примитивных: admin, editor, viewer
    • Для подключения к виртуальной машине используется OS Login
    • На ресурсах в организации отсутствует публичный доступ
    • Сервисным аккаунтам назначены минимальные привилегии
    • Использование серийной консоли контролируется либо отсутствует
    • Настроена федерация удостоверений (Single Sign-On, SSO)
    • Выполняется сканирование уязвимостей на уровне облачных IP-адресов
    • В Yandex Application Load Balancer используется HTTPS
    • В Yandex API Gateway используется HTTPS и собственный домен
    • В Yandex Cloud CDN используется HTTPS и собственный SSL-сертификат
    • Используется защита от DDoS атак на уровне приложений (L7)
    • Docker-образы сканируются при загрузке в Container Registry
    • При создании реестра в Yandex Container Registry по умолчанию оставляйте безопасные настройки реестра
    • Используется Advanced Rate Limiter
    • Используется Yandex SmartCaptcha
    • Используется профиль безопасности Yandex Smart Web Security
    • Используется Web Application Firewall
    • Используется Cloud Backup или механизм snapshot по расписанию
    • Срок действия сертификата Yandex Certificate Manager составляет как минимум 30 дней
    • Используется шифрование данных на уровне приложения
    • Для ключей KMS включена защита от удаления
    • Ключи Key Management Service хранятся в аппаратном модуле безопасности (HSM)
    • Для KMS ключей включена ротация
    • Используется шифрование дисков и снимков виртуальных машин
    • Выполняется периодическая ротация ключей сервисных аккаунтов
    • При работе Container Optimized Image используется шифрование секретов
    • В организации используется Yandex Lockbox для безопасного хранения секретов
    • Для Serverless Containers и Cloud Functions используются секреты Lockbox
    • В Yandex Object Storage включено шифрование данных at rest с ключом KMS
    • В Yandex Object Storage включено HTTPS для хостинга статического сайта
    • Включена настройка защиты от удаления (deletion protection)
    • Настроен сбор аудитных логов Kubernetes для расследований инцидентов
    • Настроено резервное копирование Kubernetes
    • Managed Service for Kubernetes используется безопасная конфигурация
    • Используется одна из трех последних версий Kubernetes и ведется мониторинг обновлений
    • На управляемых базах данных назначена Группа безопасности
    • На управляемых базах данных не назначен публичный IP-адрес
    • Используется защита от DDoS атак на уровне сети (L3)
    • Для объектов облака используется межсетевой экран или группы безопасности
    • В группах безопасности отсутствует слишком широкое правило доступа
    • В Virtual Private Cloud создана группа безопасности и не используется группа безопасности по умолчанию
    • Запросы DNS не передаются в сторонние рекурсивные резолверы
    • Публичный доступ отсутствует для YDB
    • Выполняется сбор аудитных логов с уровня приложений
    • Включен сервис Yandex Audit Trails на уровне организации
    • События Yandex Audit Trails экспортируются в SIEM-системы
    • Выполняется сбор аудитных логов с уровня ОС
    • Администратор облака имеет инструкцию по действиям в случае компрометации секретов его облака
    • Контактные данные ответственного за организацию актуальны
    • Выполняется контроль целостности

CSPM — Cloud Security Posture ManagementCSPM — Cloud Security Posture Management

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

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

kind

severity

ID

automatic

medium

access.acl-container-registry

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

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

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

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

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

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

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

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

kind

severity

ID

manual

medium

access.bucket-public-access

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

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

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

Внимание

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

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

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

  • проверки сервиса IAM
  • политики доступа (bucketpolicy)
  • списки управления доступом (ACL)

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

  1. Если запрос прошел проверку IAM, к нему применяется проверка политики доступа.
  2. Проверка правил политики доступа происходит в следующем порядке:
    1. Если запрос подошел хотя бы под одно из правил Deny, то доступ будет запрещен.
    2. Если запрос подошел хотя бы под одно из правил Allow, то доступ будет разрешен.
    3. Если запрос не подошел ни под одно из правил, то доступ будет запрещен.
  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-запросов в БД и визуализации структуры данных.

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

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

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

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

kind

severity

ID

automatic

low

access.db-datalens-access

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

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

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

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

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

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

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

kind

severity

ID

manual

medium

access.defined-key-scopes

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

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

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

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

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

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

Используются сервисные роли вместо примитивных: admin, editor, viewerИспользуются сервисные роли вместо примитивных: 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Для подключения к виртуальной машине используется 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.

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

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

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

kind

severity

ID

manual

high

access.public-access

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

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

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

В 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

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

kind

severity

ID

manual

medium

access.uses-federation

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

Для централизованного управления учетными данными используйте SAML-совместимые федерации удостоверений. С помощью федераций удостоверений компания может настроить Single Sign-On-аутентификацию в Yandex Cloud через свой сервер IdP. При таком подходе сотрудники имеют возможность использовать свои корпоративные аккаунты, на которые распространяются политики безопасности компании, такие как:

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

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

Совет

Используйте федеративные аккаунты вместо аккаунтов Яндекс ID, где это возможно. Помните, что для управления федерацией существует отдельная роль organization-manager.federations.admin.

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

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

Рекомендации и готовые решения:

  • Инструкция по настройке SAML-совместимой федерации удостоверений
  • Инструкция по настройке SAML-совместимой федерации с KeyCloak

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

kind

severity

ID

manual

medium

active.ip-vulnerability-scan

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

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

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

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

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

Примеры бесплатных сетевых сканеров:

  • Nmap
  • OpenVAS
  • OWASP ZAP

Пример бесплатного сканера, который работает в виде агента на хостах: Wazuh. Wazuh может также использоваться в качестве системы обнаружения вторжений (host-based intrusion detection system — IDS).

Вы также можете воспользоваться решением из Cloud Marketplace.

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

  • Примеры бесплатных сетевых сканеров: Nmap, OpenVAS, OWASP ZAP
  • Пример бесплатного сканера, который работает в виде агента на хостах: Wazuh
  • Вы также можете воспользоваться решением из Cloud Marketplace

В Yandex Application Load Balancer используется HTTPSВ 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 обработчик согласно инструкции

В Yandex API Gateway используется HTTPS и собственный доменВ Yandex API Gateway используется HTTPS и собственный домен

kind

severity

ID

automatic

medium

appsec.api-gateway-https

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

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

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

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

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

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

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

kind

severity

ID

automatic

low

appsec.cdn-https

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

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

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

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

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

  • Подключите сертификат и HTTPS согласно инструкции

Используется защита от DDoS атак на уровне приложений (L7)Используется защита от 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. Чтобы включить расширенную защиту, обратитесь к вашему менеджеру или в техническую поддержку.

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

  • Инструкция по созданию профиля безопасности Smart Web Security
  • Вебинар: Защита от DDoS в Yandex Cloud

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

kind

severity

ID

automatic

high

appsec.periodic-scan

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

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

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

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

  • автоматически выполняется сканирование Docker-образов при их загрузке в реестр;

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

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

  1. В консоли управления выберите каталог, которому принадлежит реестр с Docker-образами.

  2. Выберите реестр в сервисе Container Registry.

  3. Перейдите на вкладку Сканер уязвимостей и нажмите кнопку Изменить настройки.

  4. Убедитесь, что сканирование Docker-образов по расписанию включено и оно проходит не реже, чем раз в неделю.

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

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

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

kind

severity

ID

automatic

medium

appsec.upload-policy

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

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

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

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

  • автоматически выполняется сканирование Docker-образов при их загрузке в реестр;

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

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

  • В консоли управления выберите каталог, в котором будет создан реестр.
  • В списке сервисов выберите Container Registry.
  • Нажмите кнопку Создать реестр.
  • В поле Имя введите имя реестра. Требования к имени:
    • длина — от 2 до 63 символов;
    • может содержать строчные буквы латинского алфавита, цифры и дефисы;
    • первый символ — буква, последний — не дефис.
  • В блоке Автоматическое сканирование:
    • Оставьте включенной опцию Сканировать Docker-образы при загрузке, чтобы сканировать Docker-образы при загрузке в репозиторий.
    • Оставьте включенной опцию Сканировать все Docker-образы в реестре, при необходимости настройте периодичность сканирования.
  • Нажмите кнопку Создать реестр.

Используется Advanced Rate LimiterИспользуется 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Используется Yandex SmartCaptcha

kind

severity

ID

automatic

low

appsec.use-smartcaptcha

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

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

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

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

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

  • Сервис Yandex SmartCaptcha

Используется профиль безопасности Yandex Smart Web SecurityИспользуется профиль безопасности 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 для дополнительной верификации.

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

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

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

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

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

kind

severity

ID

automatic

medium

appsec.use-waf

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

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

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

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

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

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

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

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

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

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

kind

severity

ID

automatic

high

compute.snapshot

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

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

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

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

  • снимков по расписанию;
  • сервиса Cloud Backup.

Проверка в консоли управления:

  1. В консоли управления выберите облако или каталог, в которых необходимо проверить ВМ.
  2. В списке сервисов выберите Compute Cloud.
  3. Убедитесь, что на ВМ настроена политика снимков по расписанию.
  4. В списке сервисов выберите Cloud Backup.
  5. Убедитесь, что он включен.

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

  • Рекомендуется активировать сервис Yandex Cloud Backup: https://yandex.cloud/ru/docs/backup/operations/activate-service

Срок действия сертификата Yandex Certificate Manager составляет как минимум 30 днейСрок действия сертификата 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 дней.

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

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

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

kind

severity

ID

manual

medium

crypto.data.application-encryption

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

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

Если шифрование на уровне приложения внедрено, отметьте проверку как выполненная.

Для шифрования данных на уровне приложения (client-side encryption) перед их отправкой в бакет Yandex Object Storage вы можете использовать следующие подходы:

  • Интеграция Object Storage с сервисом Key Management Service для шифрования данных на уровне приложения (client-side encryption). Подробнее смотрите в разделе «Рекомендуемые криптографические библиотеки».

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

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

Для шифрования данных на уровне приложения (client-side encryption) рекомендуется использовать следующие библиотеки:

  • AWS Encryption SDK и его интеграцию с KMS: https://yandex.cloud/ru/docs/kms/tutorials/encrypt/aws-encryption-sdk
  • Google Tink и ее интеграцию с KMS: https://yandex.cloud/ru/docs/kms/tutorials/encrypt/google-tink
  • SDK Yandex Cloud вместе с любой другой криптографической библиотекой, совместимой с PCI DSS или другими стандартами, применяемыми в вашей компании: https://yandex.cloud/ru/docs/kms/tutorials/encrypt/sdk

Сравнение библиотек представлено в разделе Какой способ шифрования выбрать документации KMS: https://yandex.cloud/ru/docs/kms/tutorials/encrypt

Для ключей KMS включена защита от удаленияДля ключей 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)Ключи 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 ключей включена ротацияДля KMS ключей включена ротация

kind

severity

ID

automatic

high

crypto.keys-rotation

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

  • Установите период ротации для ключей

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

kind

severity

ID

manual

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), рекомендуется отметить выполнение контроля вручную.

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

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

При работе Container Optimized Image используется шифрование секретовПри работе Container Optimized Image используется шифрование секретов

kind

severity

ID

automatic

high

crypto.secrets-coi

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

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

Данный контроль автоматически проверяет шифрование секретов в конфигурациях Container Optimized Image.

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

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

  • Шифрование секретов в Terraform для передачи на ВМ с Container Optimized Image: https://github.com/yandex-cloud-examples/yc-encrypt-coi-secrets
  • Другие рекомендации по безопасному использованию Terraform см. в статье Безопасная конфигурация: Terraform: https://yandex.cloud/ru/docs/security/standard/virtualenv-safe-config#tf-using

В организации используется Yandex Lockbox для безопасного хранения секретовВ организации используется 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Для 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В 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 для хостинга статического сайтаВ 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:

  • Настройка HTTPS
  • Бакет

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

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

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

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

kind

severity

ID

automatic

low

db.db-deletion-protection

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

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

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

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

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

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

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

kind

severity

ID

manual

high

k8s.audit-logs

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

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

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

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

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

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

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

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

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

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

Настроено резервное копирование KubernetesНастроено резервное копирование Kubernetes

kind

severity

ID

manual

high

k8s.backup

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

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

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

Для обеспечения непрерывности работы и защиты данных рекомендуется использовать резервное копирование в Managed Service for Kubernetes, поскольку оно позволяет быстро восстановить работу сервиса без потери данных и времени на восстановление после сбоя или аварии. Данные в кластерах Kubernetes надежно хранятся и реплицируются в инфраструктуре Yandex Cloud. Однако в любой момент вы можете сделать резервные копии данных из групп узлов кластеров Kubernetes и хранить их в Yandex Object Storage или другом хранилище.

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

  • Вы можете создавать резервные копии данных из групп узлов кластера Kubernetes с помощью инструмента Velero. Этот инструмент поддерживает работу с дисками Yandex Cloud с помощью CSI-драйвера Kubernetes, и позволяет создавать моментальные снимки дисков томов.
  • При работе с Velero, установленным вручную, вы можете использовать nfs, emptyDir, локальный или любой другой тип тома, в котором нет встроенной поддержки моментальных снимков. Чтобы использовать такой тип тома, задействуйте плагин restic при установке Velero. Velero, установленный из Cloud Marketplace, плагин restic не включает.
  • Инструкция по резервному копированию кластера Kubernetes в Object Storage: https://yandex.cloud/ru/docs/managed-kubernetes/tutorials/kubernetes-backup#backup

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

kind

severity

ID

manual

medium

k8s.kubernetes-safe-config

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

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

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

В 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 и используется для его автоматического запуска.

Используется одна из трех последних версий Kubernetes и ведется мониторинг обновленийИспользуется одна из трех последних версий Kubernetes и ведется мониторинг обновлений

kind

severity

ID

manual

medium

k8s.version-update

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

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

Данное правило требует ручной проверки версии Kubernetes и мониторинга обновлений.

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

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

  • проверьте, что настройки обновлений соответствуют стандартам ИБ;

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

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

  • Инструкция как обновить кластер автоматически
  • Инструкция как обновить кластер вручную

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

kind

severity

ID

automatic

high

network.db-ip

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

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

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

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

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

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

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

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

kind

severity

ID

automatic

medium

network.db-security-group

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

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

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

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

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

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

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

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

kind

severity

ID

automatic

high

network.ddos-protection.l3

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

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

Данный контроль автоматически проверяет наличие защиты от DDoS атак на уровне сети (L3).

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

Если используется наложенный сервис защиты от 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 в Yandex Cloud

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

kind

severity

ID

automatic

high

network.firewall

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

kind

severity

ID

automatic

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 создана группа безопасности и не используется группа безопасности по умолчаниюВ 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 с ограниченными правилами доступа, чтобы ее можно было назначать на облачные объекты.

Запросы DNS не передаются в сторонние рекурсивные резолверыЗапросы DNS не передаются в сторонние рекурсивные резолверы

kind

severity

ID

manual

low

network.recursive-dns-resolvers

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

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

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

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

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

  • Обратитесь в службу технической поддержки

Публичный доступ отсутствует для YDBПубличный доступ отсутствует для 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
  • При настройке доступа к БД следует использовать принцип минимальных привилегий.

Выполняется сбор аудитных логов с уровня приложенийВыполняется сбор аудитных логов с уровня приложений

kind

severity

ID

manual

medium

o11y.application-logs-audited

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

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

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

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

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

  • Включите сбор аудитных логов в используемых неуправляемых СУБД:
    • Включите протоколирование всех действий аутентификации (успешных и неудачных)
    • Активируйте логирование операций изменения данных (INSERT, UPDATE, DELETE)
    • Настройте регистрацию операций изменения схемы (ALTER, CREATE, DROP)
    • Фиксируйте изменения разрешений и привилегий
    • Настройте события для отслеживания запросов

Включен сервис Yandex Audit Trails на уровне организацииВключен сервис 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 на уровне всей организации — это позволит централизованно собирать аудитные логи, например, в отдельное облако безопасности

События Yandex Audit Trails экспортируются в SIEM-системыСобытия Yandex Audit Trails экспортируются в SIEM-системы

kind

severity

ID

manual

medium

o11y.logs-exported-to-siem

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

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

Убедитесь, что аудитные логи из Yandex Audit Trails экспортируются для анализа в SIEM-систему либо анализируются в облаке одним из способов. и отметьте проверку как выполненная.

Решения для экспорта аудитных логов Yandex Cloud подготовлены для следующих SIEM-систем:

  • ArcSight — Сбор, мониторинг и анализ аудитных логов во SIEM ArcSight

  • Splunk — Сбор, мониторинг и анализ аудитных логов в SIEM Splunk

  • MaxPatrol SIEM — Сбор, мониторинг и анализ аудитных логов в MaxPatrol SIEM

  • Wazuh — Сбор, мониторинг и анализ аудитных логов в Wazuh

  • KUMA — Сбор, мониторинг и анализ аудитных логов в KUMA

Для настройки экспорта в любые SIEM подходят утилиты GeeseFS или s3fs. Они позволяют смонтировать бакет Yandex Object Storage как локальный диск виртуальной машины. Далее на ВМ необходимо установить коннектор для SIEM и настроить вычитывание JSON-файлов из бакета. Либо утилиты совместимые с AWS Kinesis datastreams в случае, если вы направляете аудитные логи в Yandex Data Streams.

Вы также можете анализировать аудитные логи вручную, если у вас отсутствует SIEM-система, с помощью поиска событий Yandex Cloud в Yandex Query, Cloud Logging или Object Storage.

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

  • Для настройки экспорта в любые SIEM подходят утилиты GeeseFS или s3fs. Они позволяют смонтировать бакет Yandex Object Storage как локальный диск виртуальной машины. Далее на ВМ необходимо установить коннектор для SIEM и настроить вычитывание JSON-файлов из бакета. Либо утилиты совместимые с AWS Kinesis datastreams в случае, если вы направляете аудитные логи в Yandex Data Streams.

  • Вы также можете анализировать аудитные логи вручную, если у вас отсутствует SIEM-система, с помощью поиска событий Yandex Cloud в Yandex Query, Cloud Logging или Object Storage: https://yandex.cloud/ru/docs/audit-trails/tutorials/search-events-audit-logs/

Выполняется сбор аудитных логов с уровня ОСВыполняется сбор аудитных логов с уровня ОС

kind

severity

ID

manual

high

o11y.os-logs-audited

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

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

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

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

Для сбора стандартных событий, которые генерирует ОС, и их экспорта в SIEM-систему клиента существуют бесплатные инструменты, такие как:

  • Osquery
  • Filebeat (ELK)
  • Wazuh

Дополнительные опции генерации событий возможно реализовать с помощью утилиты Auditd для Linux, Sysmon для Windows.

Системные метрики Linux (процессор, память, диск) можно собирать с помощью компонента Unified Agent сервиса Monitoring.

Также события ОС возможно экспортировать в Cloud Logging с помощью плагина Fluent bit либо в Data Streams.

Для описания событий, которые нужно искать в логах, рекомендуем использовать формат Sigma, поддерживаемый популярными SIEM-системами. Репозиторий Sigma содержит библиотеку событий, описанных в этом формате.

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

Дополнительно рекомендуется повысить уровень логирования внутри виртуальных машин как минимум до VERBOSE.

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

  • Для сбора стандартных событий, которые генерирует ОС, и их экспорта в SIEM-систему клиента существуют бесплатные инструменты, такие как:
    • Osquery
    • Filebeat (ELK)
    • Wazuh
  • Дополнительные опции генерации событий возможно реализовать с помощью утилиты Auditd для Linux, Sysmon для Windows
  • Системные метрики Linux можно собирать с помощью компонента Unified Agent сервиса Monitoring
  • Также события ОС возможно экспортировать в Cloud Logging с помощью плагина Fluent bit
  • Для описания событий, которые нужно искать в логах, рекомендуем использовать формат Sigma
  • Чтобы получать точную хронологию событий уровня ОС и приложений, настройте синхронизацию часов
  • Дополнительно рекомендуется повысить уровень логирования внутри виртуальных машин как минимум до VERBOSE

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

kind

severity

ID

manual

information

procedure.admin-secrets-leak-mitigation

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

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

Выполните рекомендации и отметьте проверку как выполненная.

В Yandex Cloud по умолчанию для всех включен Secret Scanning Service.
Он обнаруживает облачные структурированные секреты в открытом доступе в следующих источниках:

  • в публичных репозиториях Github;
  • в поисковом индексе Яндекса;
  • в Helm-чартах Kubernetes маркетплейса.

Список облачных секретов для обнаружения:

  • Yandex Cloud Session Cookie;
  • Yandex Cloud IAM token;
  • Yandex Cloud API Key;
  • Yandex Passport OAuth token;
  • Yandex Cloud AWS API compatible Access Secret;
  • Yandex Cloud SmartCaptcha Server Key;
  • Lockbox структурированные секреты.

Сервис автоматически уведомляет клиента о найденном секрете, который относится к его инфраструктуре:

  • по электронной почте;
  • с помощью событий Yandex Audit Trails.

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

  • Убедитесь, что:
    • Контактные данные ответственного за организацию актуальны
    • Включен сервис Yandex Audit Trails на уровне организации
    • Администратор ознакомлен с инструкцией по действиям при компрометации секретов

Контактные данные ответственного за организацию актуальныКонтактные данные ответственного за организацию актуальны

kind

severity

ID

manual

low

procedure.organization-contacts

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

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

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

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

Например, если со стороны облака были обнаружены аномальные активности в организации клиента или облачные ключи IAM становятся доступными во внешних репозиториях GitHub, клиенту будет направлено оповещение. Эта возможность реализована с помощью участия Yandex Cloud в программе Github Secret scanning partner program, а также анализа секретов в поиске Яндекса. В случае компрометации ключей в публичном репозитории удалите секрет из репозитория, его истории и отзовите ключи.

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

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

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

Укажите актуальные контактные данные по инструкции.

Выполняется контроль целостностиВыполняется контроль целостности

kind

severity

ID

manual

low

runtime.vm-environment-integrity

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

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

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

Контроль целостности файлов

Множество стандартов по ИБ требуют выполнения контроля целостности критичных файлов. Для этого можно использовать бесплатные host-based решения:

  • Wazuh
  • Osquery

В маркетплейсе облака также доступны платные решения — например, Kaspersky Security.

Контроль целостности среды запуска ВМ

В целях контроля среды запуска ВМ (например, доступ из ВМ к защищенному репозиторию только при запуске в облаке Yandex Cloud CLI) вы можете использовать механизм Идентификационного документа. При создании ВМ формируется идентификационный документ (identity document), в котором хранятся сведения о самой ВМ: идентификаторы ВМ, продукта Yandex Cloud Marketplace, образа диска и т.д. Такой документ подписывается сертификатом Yandex Cloud. Сам документ и его подпись доступны процессам в ВМ через сервис метаданных, что позволяет процессам в виртуальной машине гарантированно идентифицировать среду запуска ВМ, образ диска и т.д. для ограничения доступа к контролируемым ресурсам.

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

  • Соберите данные об использовании лучших практик безопасности Terraform из разных точек.

Была ли статья полезна?

Предыдущая
Все правила
Следующая
Аутентификация
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ТОО «Облачные Сервисы Казахстан»