Требования к конфигурации виртуальной среды

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

Yandex Cloud

Улучшена

Обновлена 28 апреля 2025 г.

3. Безопасная конфигурация виртуальной среды

3. Безопасная конфигурация виртуальной среды

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

Общее

3.1 Используется антивирусная защита

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

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

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

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

Установите антивирусное решение в соответствии с инструкциями поставщика.

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

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

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

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

Примечание

Согласно стандарту PCI DSS, доступ к виртуальной машине через серийную консоль считается «неконсольным» (non-console), и Yandex Cloud применяет для него шифрование TLS.

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

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

Проверка через CLI

В консоли управления выберите каталог, ВМ которого хотите проверить.
В списке сервисов выберите Compute Cloud.
Откройте настройки всех необходимых ВМ.
В блоке Доступ найдите параметр Дополнительно.
Опция Доступ к серийной консоли должна быть отключена.
Если у всех ВМ опция отключена, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

Найдите ВМ с включенным доступом к серийной консоли:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do echo "VM_ID: " && yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."serial-port-enable"=="1")' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----"
done;
done;
done

Если VM_ID напротив FOLDER_ID указано пустое значение, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

3.3 Используется эталонный образ для развертывания ВМ

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

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

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

Проверка через CLI

В консоли управления выберите каталог, ВМ которого хотите проверить.
В списке сервисов выберите Compute Cloud.
Перейдите на вкладку Диски.
Откройте настройки всех дисков.
В блоке Источник найдите параметр Идентификатор.
Если во всех дисках отображается ID вашего эталонного образа, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

Выполните команду для поиска дисков ВМ, которые не имеют ID вашего эталонного образа:

export ORG_ID=<ID организации>
export IMAGE_ID=<id вашего эталонного образа>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for DISK_ID in $(yc compute disk list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do echo "DISK_ID: " && yc compute disk get --id=$DISK_ID \
--format=json | jq -r --arg IMAGE_ID $IMAGE_ID '. | select(."source_image_id"==$IMAGE_ID | not)' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----"
done;
done;
done

Если DISK_ID напротив FOLDER_ID указано пустое значение, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

В файлах конфигураций Terraform не рекомендуется указывать приватную информацию: пароли, секреты, персональные данные, данные платежных систем и др. Вместо этого необходимо использовать сервисы для хранения и использования в конфигурации секретов, например: HashiCorpVault из Cloud Marketplace или Lockbox (для передачи секретов в целевой объект без использования Terraform).

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

Указывать для приватной информации параметр sensitive = true, чтобы отключить ее вывод в консоль при выполнении команд terraform plan, terraform apply.
Использовать terraformremotestate. Рекомендуется загружать состояние Terraform в Object Storage, а также настроить блокировку конфигурации с помощью Managed Service for YDB для предотвращения одновременного редактирования администраторами.
Использовать механизм передачи секретов в Terraform через env вместо plaintext либо использовать встроенную возможность KeyManagementService по шифрованию данных в Terraform с помощью отдельного файла с приватными данными. Подробнее о данной технике.

Об обеспечении безопасности Object Storage читайте ниже в подразделе Object Storage.

Примечание

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

Проверяйте ваши Terraform-манифесты с помощью Checkov с поддержкой Yandex Cloud.

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

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

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

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

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

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

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

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

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

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

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

Убедитесь, что критические ВМ имеют подписанные идентификационные документы.

3.6 Учтены принципы защиты от атак по побочным каналам (side-chanel)

Для наилучшей защиты от атак по побочным каналам процессора (так называемым атакам side-channel на уровне CPU, например, Spectre или Meltdown) необходимо:

Использовать полноядерные виртуальные машины, то есть виртуальные машины с долей ядра CPU в 100 процентов.
Устанавливать обновления операционной системы и ядра, которые обеспечивают защиту от атак с использованием побочных каналов (например, Kernelpage-tableisolation для Linux, приложения, собранные с Retpoline).

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

Подробнее о защите от side-channel-атак в облачных окружениях.

3.7 Сотрудники, работающие с Yandex Cloud, имеют сертификат Yandex Cloud Certified Security Specialist

Сертификационный экзамен Yandex Cloud Certified Security Specialist предназначен для оценки компетенций пользователей платформы Yandex Cloud, которые выполняют задачи по обеспечению информационной безопасности и защите облачных систем.

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

Перейдите на описание проверяемых компетенций экзамена на звание Yandex Cloud Certified Security Specialist.
Изучите материалы, которые помогут пройти экзамен.
Заполните форму для записи на прохождение экзамена.

Yandex Object Storage

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

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

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

Проверка через CLI

В консоли управления выберите облако или каталог, бакеты которого вы хотите проверить.
В списке сервисов выберите Object Storage.
Нажмите на три точки напротив каждого бакета и проверьте ACL бакета на наличие allUsers и allAuthenticatedUsers.
Зайдите внутрь бакета и проверьте ACL на каждый объект бакета на наличие allUsers и allAuthenticatedUsers.
Проверьте, что в разделе Доступ на чтение объектов включен параметр Публичный. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Настройте awscli на работу с облаком.

Выполните команду для ACL бакета на наличие allUsers, allAuthenticatedUsers:

aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-acl  <имя вашего бакета>

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

Если публичный доступ включен, удалите его либо контролируйте (осознанно выдавайте для публичных данных).

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

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

Примеры Bucket Policy:

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

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

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

Проверка через CLI

В консоли управления выберите облако или каталог, политики доступа которых вы хотите проверить.
В списке сервисов выберите Object Storage.
Перейдите в раздел Политика доступа.
Убедитесь, что как минимум одна политика включена. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Настройте awscli на работу с облаком.
Выполните команду для ACL бакета на проверку наличия allUsers, allAuthenticatedUsers:
```
aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-policy --bucket <имя вашего бакета>
```

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

Включите необходимую политику.

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

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

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

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

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

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

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

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

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

Проверка через CLI

В консоли управления выберите облако или каталог, бакеты которых вы хотите проверить.
В списке сервисов выберите Object Storage.
Откройте настройки всех бакетов.
Перейдите во вкладку Версионирование и убедитесь, что оно включено. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Настройте awscli на работу с облаком.

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

aws --endpoint https://storage.yandexcloud.net \
s3api get-bucket-versioning \
--bucket <имя вашего бакета>

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

aws --endpoint-url=https://storage.yandexcloud.net/ \
s3api get-object-lock-configuration \
--bucket <имя вашего бакета>

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

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

3.11 В Object Storage включен механизм логирования действий с бакетом

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

При этом будут записываться именно логи data-plane c объектами: PUT, DELETE, GET, POST, OPTIONS, HEAD.

Запись данных логов, кроме событий чтения объектов из бакета, можно запросить в Audit Trails. В сервисе Monitoring с помощью метрики traffic можно увидеть объем исходящего трафика из бакета. В будущем все логи будут записываться в Audit Trails.

Дополнительно возможен анализ логов Object Storage при помощи DataLens. Подробнее в статье Анализ логов Object Storage при помощи DataLens.

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

Проверить включен ли механизм логирования можно только через Terraform/API согласно инструкции.

3.12 В Object Storage настроено управление кросс-доменными запросами (CORS)

При необходимости кросс-доменных запросов к объектам в бакетах клиенту необходимо настроить политику Cross-origin resource sharing (CORS) в соответствии с требованиями ИБ компании клиента. Подробнее в разделе CORS-конфигурация бакетов документации Object Storage.

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

В консоли управления выберите облако или каталог, бакеты которых вы хотите проверить.
В списке сервисов выберите Object Storage.
Откройте настройки всех бакетов.
Перейдите во вкладку CORS — конфигурация должна быть настроена. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

Настройте CORS.

3.13 Для получения временных ключей доступа к Object Storage используется Yandex Security Token Service

Yandex Security Token Service — компонент сервиса Yandex Identity and Access Management для получения временных ключей доступа, совместимых с AWS S3 API.

Временные ключи доступа в качестве способа аутентификации поддерживаются только в сервисе Yandex Object Storage.

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

Временный ключ доступа создается на основе статического ключа, но в отличие от него имеет ограниченные время жизни и права доступа. Права доступа и время жизни задаются для каждого временного ключа индивидуально. Максимальное время жизни ключа — 12 часов.

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

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

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

Создайте временный ключ доступа с помощью Security Token Service.

3.14 Для единичных случаев доступа к отдельным объектам в непубличных бакетах Object Storage генерируются подписанные URL

В Object Storage реализовано несколько механизмов для управления доступом к ресурсам. Алгоритм взаимодействия этих механизмов см. в разделе Обзор способов управления доступом в Object Storage.

С помощью подписанных URL произвольный пользователь интернета может выполнять в Object Storage различные операции, например:

скачать объект;
загрузить объект;
создать бакет.

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

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

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

Составьте и передайте нужному пользователю подписанный URL.

Managed Services for Databases

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

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

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

Проверка через CLI

Проверка наличия SG на управляемых базах данных

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

Выполните команду для поиска managed postgres без SG:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for DB_ID in $(yc managed-postgresql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-postgresql cluster get --id=$DB_ID --format=json | jq -r '. | select(.security_group_ids | not)' | jq -r '.id' 
done;
done;
done

Если выдается пустая строка, то рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Выполните команду для поиска managed SQL без SG:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.security_group_ids | not)' | jq -r '.id' 
done;
done;
done

Если выдается пустая строка, то рекомендация выполняется. Если нет, перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

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

Проверка через CLI

В консоли управления выберите облако или каталог, в которых вы хотите проверить базы данных.
В списке сервисов выберите сервис(ы), где находятся управляемые базы данных.
В настройках объектов перейдите во вкладку Хосты.
Если в параметрах каждого объекта отключена опция Публичный доступ, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

Выполните команду для поиска кластеров управляемых БД с публичным адресом:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql hosts list --cluster-id=$DB_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.cluster_id' 
done;
done;
done

Если выдается пустая строка, рекомендация выполняется. Если нет, перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

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

Проверка через CLI

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

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.deletion_protection | not)' | jq -r '.id' 
done;
done;
done

Если выдается пустая строка, то рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

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

Проверка через CLI

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

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.config.access.data_lens)' | jq -r '.id' 
done;
done;
done

Если выдается пустая строка, то рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

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

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

Проверка через CLI

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

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

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

Bash

export ORG_ID=<ID_организации>

# MySQL
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '. | select(.config.access.web_sql)' | jq -r '.id' 
done;
done

# PostgreSQL
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do yc managed-postgresql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '. | select(.config.access.web_sql)' | jq -r '.id' 
done;
done

# ClickHouse
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do yc managed-clickhouse cluster list --folder-id=$FOLDER_ID --format=json | jq -r '. | select(.config.access.web_sql)' | jq -r '.id' 
done;
done

# Redis
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do yc managed-redis cluster list --folder-id=$FOLDER_ID --format=json | jq -r '. | select(.config.access.web_sql)' | jq -r '.id' 
done;
done

# MongoDB
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do yc managed-mongodb cluster list --folder-id=$FOLDER_ID --format=json | jq -r '. | select(.config.access.web_sql)' | jq -r '.id' 
done;
done

PowerShell

$ORG_ID = "<ID_организации>"

$Clouds = yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | ConvertFrom-Json | Select @{n="CloudID";e={$_.id}}, created_at, @{n="CloudName";e={$_.name}}, organization_id

$MDBClusters = @()

foreach ($Cloud in $Clouds) {
    $Folders = yc resource-manager folder list --cloud-id $Cloud.CloudID --format=json | ConvertFrom-Json

    foreach($Folder in $Folders) {
        # Getting Postgre
        $MDBName = "Managed PostgreSQL"
        $MDBClusters += yc managed-postgresql cluster list --folder-id $Folder.id --format=json | ConvertFrom-Json | where {$_.config.access.web_sql -eq $True} | Select @{n="CloudID";e={$Cloud.CloudID}}, @{n="CloudName";e={$Cloud.CloudName}}, @{n="FolderID";e={$Folder.id}}, @{n="FolderName";e={$Folder.name}}, @{n="MDB";e={$MDBName}}, @{n="ClusterID";e={$_.id}}, @{n="ClusterName";e={$_.name}}, @{n="ClusterEnv";e={$_.environment}}, @{n="ClusterStatus";e={$_.status}}, network_id, health, @{n="WebSQLAccess";e={$_.config.access.web_sql}}

        # Getting MySQL
        $MDBName = "Managed MySQL"
        $MDBClusters += yc managed-mysql cluster list --folder-id $Folder.id --format=json | ConvertFrom-Json | where {$_.config.access.web_sql -eq $True} | Select @{n="CloudID";e={$Cloud.CloudID}}, @{n="CloudName";e={$Cloud.CloudName}}, @{n="FolderID";e={$Folder.id}}, @{n="FolderName";e={$Folder.name}}, @{n="MDB";e={$MDBName}}, @{n="ClusterID";e={$_.id}}, @{n="ClusterName";e={$_.name}}, @{n="ClusterEnv";e={$_.environment}}, @{n="ClusterStatus";e={$_.status}}, network_id, health, @{n="WebSQLAccess";e={$_.config.access.web_sql}}

        # Getting ClickHouse
        $MDBName = "Managed ClickHouse"
        $MDBClusters += yc managed-clickhouse cluster list --folder-id $Folder.id --format=json | ConvertFrom-Json | where {$_.config.access.web_sql -eq $True} | Select @{n="CloudID";e={$Cloud.CloudID}}, @{n="CloudName";e={$Cloud.CloudName}}, @{n="FolderID";e={$Folder.id}}, @{n="FolderName";e={$Folder.name}}, @{n="MDB";e={$MDBName}}, @{n="ClusterID";e={$_.id}}, @{n="ClusterName";e={$_.name}}, @{n="ClusterEnv";e={$_.environment}}, @{n="ClusterStatus";e={$_.status}}, network_id, health, @{n="WebSQLAccess";e={$_.config.access.web_sql}} 

        # Getting Redis
        $MDBName = "Managed Redis"
        $MDBClusters += yc managed-redis cluster list --folder-id $Folder.id --format=json | ConvertFrom-Json | where {$_.config.access.web_sql -eq $True} | Select @{n="CloudID";e={$Cloud.CloudID}}, @{n="CloudName";e={$Cloud.CloudName}}, @{n="FolderID";e={$Folder.id}}, @{n="FolderName";e={$Folder.name}}, @{n="MDB";e={$MDBName}}, @{n="ClusterID";e={$_.id}}, @{n="ClusterName";e={$_.name}}, @{n="ClusterEnv";e={$_.environment}}, @{n="ClusterStatus";e={$_.status}}, network_id, health, @{n="WebSQLAccess";e={$_.config.access.web_sql}} 

        # Getting MongoDB
        $MDBName = "Managed MongoDB"
        $MDBClusters += yc managed-mongodb cluster list --folder-id $Folder.id --format=json | ConvertFrom-Json | where {$_.config.access.web_sql -eq $True} | Select @{n="CloudID";e={$Cloud.CloudID}}, @{n="CloudName";e={$Cloud.CloudName}}, @{n="FolderID";e={$Folder.id}}, @{n="FolderName";e={$Folder.name}}, @{n="MDB";e={$MDBName}}, @{n="ClusterID";e={$_.id}}, @{n="ClusterName";e={$_.name}}, @{n="ClusterEnv";e={$_.environment}}, @{n="ClusterStatus";e={$_.status}}, network_id, health, @{n="WebSQLAccess";e={$_.config.access.web_sql}} 
    }
}

$MDBClusters

Если выдается пустая строка, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

Yandex Cloud Functions

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

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

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

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

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

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

Для функций, контейнеров и API-шлюзов, которые находятся в одном облаке, можно указать только одну сеть.

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

Проверка через CLI

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

Выполните команду для поиска всех облачных функций, для которых не заданы настройки сети в VPC:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for VER in $(yc serverless function version list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc serverless function version get $VER --format=json | jq -r '. | select(.connectivity.network_id | not)' | jq -r '.id' 
done;
done;
done

Если выдается пустая строка, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

Дополнительную информацию об отслеживании версий функций см. в разделе Резервное копирование в Cloud Functions.

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

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

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

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

Не храните секреты и чувствительные данные в коде функции и переменных окружения. Для хранения и ротации секретов используйте сервис Yandex Lockbox. Передать секрет Yandex Lockbox в функцию можно в переменной окружения.

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

lockbox.payloadViewer на секрет;
kms.keys.encrypterDecrypter на ключ шифрования, если секрет создан с использованием ключа шифрования Yandex Key Management Service.

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

При передаче секретов создается новая версия функции. В существующую версию функции передать секреты нельзя.

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

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

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

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

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

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

3.22 Учтены особенности синхронизации времени в Cloud Functions

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

3.23 Учтены особенности управления заголовками в Cloud Functions

Если функция вызывается для обработки HTTP-запроса, то возвращаемый результат должен представлять собой JSON-документ, содержащий код ответа HTTP, заголовки ответа и содержимое ответа. Cloud Functions автоматически обработает этот JSON, и пользователь получит данные в виде стандартного HTTP-ответа. Клиенту необходимо самостоятельно управлять заголовками ответа в соответствии с требованиями регуляторов и модели угроз. Инструкцию по обработке HTTP-запроса см. в статье Вызов функции в Cloud Functions документации Cloud Functions.

Вы можете запускать функцию с указанием строкового query-параметра ?integration=raw. При использовании такой формы вызова функция не может анализировать и задавать HTTP-заголовки:

Содержимое тела HTTPS-запроса передается первым аргументом (без преобразования в JSON-структуру).
Содержимое тела HTTPS-ответа совпадает с ответом функции (без преобразования и проверки структуры), HTTP-статус ответа: 200.

Запрос должен представлять собой JSON-структуру, которая содержит:

httpMethod — HTTP-метод: DELETE, GET, HEAD, OPTIONS, PATCH, POST или PUT.
headers — словарь строк, содержащий HTTP-заголовки запроса и их значения. Если один и тот же заголовок передан несколько раз, словарь содержит последнее переданное значение.
multiValueHeaders — словарь, содержащий HTTP-заголовки запроса и списки с их значениями. Он содержит те же ключи, что и словарь headers, но, если какой-либо заголовок повторялся несколько раз, список для него будет содержать все переданные значения для данного заголовка. Если заголовок был передан всего один раз, он включается в этот словарь, и список для него будет содержать только одно значение.
queryStringParameters — словарь, содержащий параметры запроса. Если один и тот же параметр указан несколько раз, словарь содержит последнее указанное значение.
multiValueQueryStringParameters — словарь, содержащий для каждого параметра запроса список со всеми указанными значениями. Если один и тот же параметр указан несколько раз, словарь содержит все указанные значения.
requestContext — контекст запроса.

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

Managed Service for YDB

3.24 Учтены рекомендации по работе с конфиденциальными данными в YDB

Запрещается в качестве названий базы данных, таблиц, столбцов, директорий и т.д. использовать конфиденциальные данные. Запрещается отправлять критичные данные (например данные платежных карт) в Managed Service for YDB (как Dedicated, так и Serverless) в открытом виде. Перед отправкой данных их необходимо шифровать на уровне приложения, для чего можно воспользоваться сервисом KMS или любым другим способом, соответствующим стандарту регуляторов. Если срок хранения данных известен заранее, рекомендуется настроить функцию Time To Live.

3.25 Учтены рекомендации по защите от sql-инъекций YDB

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

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

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

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

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

Проверка через CLI

В консоли управления выберите облако или каталог, в которых вы хотите проверить базу данных.
В списке сервисов выберите Managed Service for YDB.
Откройте все базы данных.
В настройках базы данных перейдите во вкладку Сеть.
Если в параметрах каждого объекта отключена опция Публичные IP-адреса, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

Выполните команду для поиска кластеров управляемых БД с публичным адресом:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql hosts list --cluster-id=$DB_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.cluster_id' 
done;
done;
done

Если выдается пустая строка, то рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

3.27 Учтены рекомендации по резервному копированию YDB

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

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

Yandex Container Registry

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

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

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

Проверка через CLI

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

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

Выполните команду для поиска CR без фильтров по IP:

Bash

export ORG_ID=<ID_организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for CR in $(yc container registry list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc container registry list-ip-permissions --id=$CR --format=json | jq -r '.[] | select(.ip)' | jq -r '.action' && echo $CR "IF ACTION PULL/PUSH exist before CR then OK"
done;
done;
done

PowerShell

$ORG_ID = "<ID_организации>"

$Clouds = yc resource-manager cloud list --organization-id $ORG_ID --format=json | ConvertFrom-Json | Select @{n="CloudID";e={$_.id}}, created_at, @{n="CloudName";e={$_.name}}, organization_id

$CRIPPermissions = @()

foreach ($Cloud in $Clouds) {
  $Folders = yc resource-manager folder list --cloud-id $Cloud.CloudID --format=json | ConvertFrom-Json

  foreach($Folder in $Folders) {
    $CRList = yc container registry list --folder-id $Folder.id --format=json | ConvertFrom-Json

    if($CRList) {
      foreach($CR in $CRList) {
        $IPPermissions = yc container registry list-ip-permissions --id $CR.id --format=json | ConvertFrom-Json

        if($IPPermissions) {
          $CRIPPermissions += $CR | Select @{n="CloudID";e={$Cloud.CloudID}}, @{n="CloudName";e={$Cloud.CloudName}}, @{n="FolderID";e={$Folder.id}}, @{n="FolderName";e={$Folder.name}}, @{n="CRID";e={$_.id}}, @{n="CRName";e={$_.name}}, @{n="CRStatus";e={$_.status}},@{n="Lables";e={$_.labels}},@{n="IPPermissionsList";e={$IPPermissions}}
        }
      }
    }
  }
}

$CRIPPermissions

Если перед каждым ID registry выдается PULL/PUSH, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

Задайте конкретные адреса для доступа к реестрам.

3.29 Выполнены требования к защите приложений в Yandex Container Registry

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Убедитесь, что выполняется подписание артефактов при сборке приложения.

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

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

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

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

Yandex Container Solution

3.30 Не используются привилегированные контейнеры в Yandex Container Solution

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

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

Проверка через CLI

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

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

Выполните команду для поиска CR без фильтров по IP:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."docker-container-declaration")| .metadata."docker-container-declaration" | match("privileged: true") | .string' && echo $VM_ID
done;
done;
done

Если перед каждым ID ВМ отсутствует privileged: true, то рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

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

При использовании технологий certificatepinning следует учитывать, что сервис Let’sEncrypt выдает сертификаты со сроком действия в 90 дней.

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

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

Проверка через CLI

В консоли управления выберите облако или каталог, в которых необходимо проверить ВМ.
В списке сервисов выберите Yandex Certificate Manager.
Зайдите в настройки каждого сертификата и найдите параметр Дата окончания.
Если в параметре указано, что сертификат проживет еще как минимум 30 дней, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```

Найдите все сертификаты вашей организации с датой окончания:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for CERT_ID in $(yc certificate-manager certificate list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc certificate-manager certificate get --id $CERT_ID --format=json | jq -r '. | "Date of the end " + .not_after + " --- Cert_ID " + .id'
done;
done;
done

Если перед каждым ID ВМ отсутствует privileged: true, то рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

Yandex Managed Service for GitLab

3.32 Выполняются рекомендации по настройке безопасности инстанса GitLab

Рекомендации представлены здесь.

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

Необходимо проверить вручную.

3.33 Выполнены требования к защите приложений в GitLab

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

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

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

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

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

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

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

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

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

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

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

3.34 Используются рекомендации по безопасности Yandex Managed Service for Kubernetes

Вы можете ознакомиться с рекомендациями в разделе Требования к безопасности Kubernetes.

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

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

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

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

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

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

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

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

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

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

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

Выполните проверку вручную.

3.37 Внешние сканирования безопасности выполняются по правилам Yandex Cloud

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

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

Выполните проверку вручную.

3.38 Выстроен процесс обновлений безопасности

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

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

Резервное копирование

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

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

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

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

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

Yandex API Gateway

API-шлюз — это интерфейс взаимодействия с сервисами внутри Yandex Cloud или в интернете. Шлюз задается декларативно при помощи спецификации по стандарту OpenAPI 3.0.

3.40 Настроено управление доступом в API Gateway

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

Все операции в Yandex Cloud проверяются в сервисе Yandex Identity and Access Management. Если у субъекта нет необходимых разрешений, сервис вернет ошибку.

Убедитесь, что пользователь Yandex Cloud имеет доступ к ресурсам сервиса API Gateway (API-шлюза). Для этого у него должны быть нужные роли. Назначать роли на API-шлюз могут пользователи, у которых есть роль api-gateway.admin или одна из следующих ролей:

admin;
resource-manager.admin;
organization-manager.admin;
resource-manager.clouds.owner;
organization-manager.organizations.owner.

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

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

Роль на API-шлюз можно назначить также через Yandex Cloud CLI или API.

Подробнее о том какие роли действуют в сервисе API Gateway см. в разделе Какие роли действуют в сервисе.

3.41 Настроено сетевое взаимодействие в API Gateway

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

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

Облачная сеть должна соответствовать следующим условиям:

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

Примечание

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

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

Примечание

Для функций, контейнеров и API-шлюзов, которые находятся в одном облаке, можно указать только одну сеть.

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

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

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

Если API-шлюзу не требуется доступ к ресурсам из указанной облачной сети, удалите ее из настроек шлюза. Подробнее см.в статье Изменить API-шлюз.

3.42 Учтены рекомендации по использованию своих доменов

Сервис API Gateway интегрирован с системой управления доменами сервиса Certificate Manager.

Если вы используете в сервисе API Gateway свои домены с подтвержденными правами при обращении к API:

Регулярно проверяйте актуальность TLS-сертификата, привязанного к домену.
Используйте для работы протокол TLS версии 1.2 или выше.
Используйте дополнительные механизмы защиты: системы обнаружения вторжений и защиты от DDoS-атак.

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

Выполните проверку вручную версии протокола TLS и актуальность сертификата TLS-соединения.

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

3.43 Учтены рекомендации по использованию протокола WebSocket

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

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

Рекомендуется подключаться к API-шлюзу по протоколу WebSocket используя:

Протокол TLS версии 1.2 или выше, регулярно проверяя актуальность сертификата TLS-соединения.
Механизмы аутентификации и авторизации, предусмотренные спецификацией OpenAPI 3.0.
Расширения спецификации API-шлюза, с помощью которых вы можете усилить безопасность виртуальной среды.

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

В консоли управления выберите каталог, в котором находится API-шлюз.
В списке сервисов выберите API Gateway.
Выберите в списке нужный API-шлюз.
Настройте интеграции в OpenAPI-спецификации, используя операции: x-yc-apigateway-websocket-message, x-yc-apigateway-websocket-connect или x-yc-apigateway-websocket-disconnect.

Подробнее см. в статье Работа с API-шлюзом по протоколу WebSocket.

3.44 Настроено взаимодействие API-шлюза с сервисами

Убедитесь, что в сервисе API Gateway спецификация дополнена расширениями, усиливающими безопасность.

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

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

3.45 Безопасность API-шлюза усилена расширениями

В расширении x-yc-apigateway:smartWebSecurity использованы правила профиля безопасности Yandex Smart Web Security с условиями для применения определенных действий к HTTP-запросам, приходящим к защищаемому ресурсу:

Базовые правила блокируют нежелательный трафик.
Правило Smart Protection для всего трафика дает наиболее полную и прозрачную защиту.
Advanced Rate Limiter устанавливает ограничения на количество запросов, снижая нагрузку на веб-приложения и защищает бэкенд от исчерпания ресурсов.
Профиль WAF анализирует входящие HTTP-запросы к веб-приложению по предварительно настроенным правилам, защищая от DoS/DDoS-атак.

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

В консоли управления выберите каталог, в котором находится API-шлюз.
В списке сервисов выберите API Gateway.
Выберите в списке нужный API-шлюз.
Убедитесь, что в блоке Спецификация использовано расширение x-yc-apigateway:smartWebSecurity, которое защищает API-шлюз и с ним ваше приложение, функцию или контейнер от DDoS-атак, на основе правил профиля безопасности Yandex Smart Web Security.

3.46 Настроена авторизация в API-шлюзе

Рекомендуется использовать стандартные механизмы аутентификации и авторизации API Gateway, предусмотренные спецификацией OpenAPI 3.0. На данный момент доступна авторизация с помощью функции и с помощью JWT.

Авторизация с помощью функции Cloud Functions. Для авторизации HTTP-запроса API Gateway вызывает x-yc-apigateway-authorizer:function расширение, в настоящее время поддержаны три типа: HTTP Basic, HTTP Bearer и API Key.
Авторизация с помощью JWT. Для авторизации HTTP-запроса API Gateway валидирует токен, а также проверяет его подпись при помощи публичных ключей: поддержаны адрес, место, поля, тело, время, режим кеширования и время хранения кеша.

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

В консоли управления выберите каталог, в котором находится API-шлюз.
В списке сервисов выберите API Gateway.
Выберите в списке нужный API-шлюз.
Убедитесь, что в блоке Спецификация настроены расширения x-yc-apigateway-authorizer:jwt или x-yc-apigateway-authorizer:function.

3.47 Использован контекст авторизации

Рекомендуется использовать контекст авторизации в запросе внутри поля requestContext.authorizer. Это позволит сохранить целостность данных и предотвратить несанкционированный доступ.

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

Убедитесь, что в настройках спецификации API-шлюза при использовании расширения x-yc-apigateway-authorizer:function настроен контекст авторизации.

3.48 Использовано логирование сервиса

Рекомендуется включать механизм логирования при создании API-шлюза. Подробнее см. в статье Записать логи в журнал выполнения в API Gateway.

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

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

Для анализа работы API-шлюза используйте аудитные логи, которые передаются в сервис Yandex Audit Trails.

Требования к конфигурации виртуальной среды

3. Безопасная конфигурация виртуальной среды3. Безопасная конфигурация виртуальной среды

ОбщееОбщее

3.1 Используется антивирусная защита3.1 Используется антивирусная защита

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

3.3 Используется эталонный образ для развертывания ВМ3.3 Используется эталонный образ для развертывания ВМ

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

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

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

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

3.6 Учтены принципы защиты от атак по побочным каналам (side-chanel)3.6 Учтены принципы защиты от атак по побочным каналам (side-chanel)

3.7 Сотрудники, работающие с Yandex Cloud, имеют сертификат Yandex Cloud Certified Security Specialist3.7 Сотрудники, работающие с Yandex Cloud, имеют сертификат Yandex Cloud Certified Security Specialist

Yandex Object StorageYandex Object Storage

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

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

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

3.11 В Object Storage включен механизм логирования действий с бакетом3.11 В Object Storage включен механизм логирования действий с бакетом

3.12 В Object Storage настроено управление кросс-доменными запросами (CORS)3.12 В Object Storage настроено управление кросс-доменными запросами (CORS)

Managed Services for DatabasesManaged Services for Databases

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

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

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

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

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

Yandex Cloud FunctionsYandex Cloud Functions

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

3.22 Учтены особенности синхронизации времени в Cloud Functions3.22 Учтены особенности синхронизации времени в Cloud Functions

3.23 Учтены особенности управления заголовками в Cloud Functions3.23 Учтены особенности управления заголовками в Cloud Functions

Managed Service for YDBManaged Service for YDB

3.24 Учтены рекомендации по работе с конфиденциальными данными в YDB3.24 Учтены рекомендации по работе с конфиденциальными данными в YDB

3.25 Учтены рекомендации по защите от sql-инъекций YDB3.25 Учтены рекомендации по защите от sql-инъекций YDB

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

3.27 Учтены рекомендации по резервному копированию YDB3.27 Учтены рекомендации по резервному копированию YDB

Yandex Container RegistryYandex Container Registry

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

3.29 Выполнены требования к защите приложений в Yandex Container Registry3.29 Выполнены требования к защите приложений в Yandex Container Registry

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

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

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

Yandex Container SolutionYandex Container Solution

3.30 Не используются привилегированные контейнеры в Yandex Container Solution3.30 Не используются привилегированные контейнеры в Yandex Container Solution

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

Yandex Managed Service for GitLabYandex Managed Service for GitLab

3.32 Выполняются рекомендации по настройке безопасности инстанса GitLab3.32 Выполняются рекомендации по настройке безопасности инстанса GitLab

3.33 Выполнены требования к защите приложений в GitLab3.33 Выполнены требования к защите приложений в GitLab

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

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

3.34 Используются рекомендации по безопасности Yandex Managed Service for Kubernetes3.34 Используются рекомендации по безопасности Yandex Managed Service for Kubernetes

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

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

3.37 Внешние сканирования безопасности выполняются по правилам Yandex Cloud3.37 Внешние сканирования безопасности выполняются по правилам Yandex Cloud

3.38 Выстроен процесс обновлений безопасности3.38 Выстроен процесс обновлений безопасности

Резервное копированиеРезервное копирование

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

Yandex API GatewayYandex API Gateway

3.40 Настроено управление доступом в API Gateway3.40 Настроено управление доступом в API Gateway

3.41 Настроено сетевое взаимодействие в API Gateway3.41 Настроено сетевое взаимодействие в API Gateway

3.42 Учтены рекомендации по использованию своих доменов3.42 Учтены рекомендации по использованию своих доменов

3.43 Учтены рекомендации по использованию протокола WebSocket3.43 Учтены рекомендации по использованию протокола WebSocket

3.44 Настроено взаимодействие API-шлюза с сервисами {yandex-cloud}3.44 Настроено взаимодействие API-шлюза с сервисами

3.45 Безопасность API-шлюза усилена расширениями3.45 Безопасность API-шлюза усилена расширениями

3.46 Настроена авторизация в API-шлюзе3.46 Настроена авторизация в API-шлюзе

3.47 Использован контекст авторизации3.47 Использован контекст авторизации

3.48 Использовано логирование сервиса3.48 Использовано логирование сервиса

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

3. Безопасная конфигурация виртуальной среды

Общее

3.1 Используется антивирусная защита

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

3.3 Используется эталонный образ для развертывания ВМ

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

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

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

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

3.6 Учтены принципы защиты от атак по побочным каналам (side-chanel)

3.7 Сотрудники, работающие с Yandex Cloud, имеют сертификат Yandex Cloud Certified Security Specialist

Yandex Object Storage

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

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

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

3.11 В Object Storage включен механизм логирования действий с бакетом

3.12 В Object Storage настроено управление кросс-доменными запросами (CORS)

Managed Services for Databases

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

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

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

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

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

Yandex Cloud Functions

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

3.22 Учтены особенности синхронизации времени в Cloud Functions

3.23 Учтены особенности управления заголовками в Cloud Functions

Managed Service for YDB

3.24 Учтены рекомендации по работе с конфиденциальными данными в YDB

3.25 Учтены рекомендации по защите от sql-инъекций YDB

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

3.27 Учтены рекомендации по резервному копированию YDB

Yandex Container Registry

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

3.29 Выполнены требования к защите приложений в Yandex Container Registry

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

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

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

Yandex Container Solution

3.30 Не используются привилегированные контейнеры в Yandex Container Solution

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

Yandex Managed Service for GitLab

3.32 Выполняются рекомендации по настройке безопасности инстанса GitLab

3.33 Выполнены требования к защите приложений в GitLab

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

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

3.34 Используются рекомендации по безопасности Yandex Managed Service for Kubernetes

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

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

3.37 Внешние сканирования безопасности выполняются по правилам Yandex Cloud

3.38 Выстроен процесс обновлений безопасности

Резервное копирование

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

Yandex API Gateway

3.40 Настроено управление доступом в API Gateway

3.41 Настроено сетевое взаимодействие в API Gateway

3.42 Учтены рекомендации по использованию своих доменов

3.43 Учтены рекомендации по использованию протокола WebSocket

3.44 Настроено взаимодействие API-шлюза с сервисами

3.45 Безопасность API-шлюза усилена расширениями

3.46 Настроена авторизация в API-шлюзе

3.47 Использован контекст авторизации

3.48 Использовано логирование сервиса